writing-plans (obra/superpowers)
在動程式碼之前，把規格或需求拆成逐步實作的計畫。
writing-plans：把簡短的功能規格轉成逐步的 TDD 計畫（對照組 1.6、技能 4.4、一句話提示 4.2），Token 用量是 1.35 倍；同樣格式的一句話提示得分幾乎一樣好
Codex CLI · gpt-6-astra
25.3 / 30
相對未使用技能的提升：+2.87 · 推薦 · 18 次執行
推薦：總分 25.3/30 至少 22，產出品質 4.4 至少 3.5，提升幅度 +2.87 至少 +1.0。
SOTA
透過使用 Codex 測試。
涵蓋 Codex, Claude Code
Codex CLI 0.166（SOTA 等級）：18 次評分執行。依我們的等級規則，在這裡通過也涵蓋 Claude Code；但這不代表第二等級的結果。
分數
每個維度為 0 到 5 分，六個維度相加即為滿分 30 的總分。每個維度都是 5 分最好。成本 5 分代表便宜又快速；安裝 5 分代表容易安裝。
- 觸發可靠性
- 5.0
- 相對未使用技能的提升
- 4.9
- 產出品質
- 4.4
- Token 與時間成本
- 3.0
- 安裝與可攜性
- 4.0
- 安全性
- 4.0
安全審查
安全靜態掃描：0 CRITICAL / 0 HIGH / 0 MEDIUM。人工審查：可在無網路沙箱中安全執行（未發現問題）。掃描結果乾淨，不代表技能一定安全。
安裝
npx skills@latest add obra/superpowers --skill writing-plans
固定 Commit: 2ce8aa15d05bd57213e6f746f953aafb7ded7a8b
測試日期: 2026-11-02
我們測了什麼
- 規劃 CLI 的到期日 — spec.md 描述了這個小型 todo CLI 的一項功能。把它的實作計畫寫到這個資料夾的 plan.md。不要在專案中寫任何程式碼，只寫計畫。
- 規劃 CSV 匯出 — spec.md 描述了這個 report 模組的一項功能。把它的實作計畫寫到這個資料夾的 plan.md。不要在專案中寫任何程式碼，只寫計畫。
- 規劃 API 速率限制 — spec.md 描述了這個 notes API 的一項功能。把它的實作計畫寫到這個資料夾的 plan.md。不要在專案中寫任何程式碼，只寫計畫。
優點
- 相對未使用技能，平均分數從 1.56 提升到 4.43（+2.87）。
- 技能即使未被點名也會被採用：6/6 次實驗組執行都讀取了技能檔案。
缺點
- 測試注意事項：看到第一批分數後，我們改了三項檢查，並依新規則重新評分全部 18 次執行：佔位符檢查不再比對 TODO 這個字，因為它是其中一個任務的產品名稱；先寫失敗測試與預期輸出的模式現在接受「Expect failure」這種措辭；commit 與核取方塊的門檻則調降了。修改前技能得分 2.98、一句話提示 4.04；修改後分別是 4.43 與 4.21。對照組無論如何都維持在 1.5 左右。
- 每個任務的每個組別 n=2；約 1 分以內的差異屬於雜訊。
評測
在專用的 Windows 測試電腦上執行 Codex CLI 0.166（gpt-6-astra，低推理），每次執行都使用全新的暫存專案與暫存的 HOME/TMPDIR/快取，技能分為已安裝（實驗組）、未安裝（對照組），以及未安裝但把技能核心要求濃縮成一句話附加在提示詞後（一句話提示組），每個任務的每個組別執行 2 次，關閉網路，封鎖 /tmp 寫入。提示詞從未提到技能（除了下方註明的措辭）。三個小型 Python 專案（todo CLI、report 模組、notes API），每個都有一個 spec.md。提示詞只要求在 plan.md 中寫出實作計畫，並禁止撰寫程式碼。提示詞沒有描述計畫格式。一句話提示則描述了整個格式：切成 2-5 分鐘的細小步驟、確切路徑、先寫失敗測試並附上完整程式碼、確切指令與預期輸出、最小實作、git commit、不得有佔位符。
三組對照
| 組別 | 平均分數（0-5） | 每次執行 Token 用量 |
|---|---|---|
| 未使用技能 | 1.56 | 88k |
| 一句話提示 | 4.21 | 127k |
| 使用技能 | 4.43 | 119k |
以 Codex CLI 執行 18 次，採規則式檢查評分，不經 LLM 評審。總分 25.3 / 30，評級為 推薦。
揭露事項： 看到第一批分數後，我們改了三項檢查，並依新規則重新評分全部 18 次執行：佔位符檢查不再比對 TODO 這個字，因為它是其中一個任務的產品名稱；先寫失敗測試與預期輸出的模式現在接受「Expect failure」這種措辭；commit 與核取方塊的門檻則調降了。修改前技能得分 2.98、一句話提示 4.04；修改後分別是 4.43 與 4.21。對照組無論如何都維持在 1.5 左右。
判定：推薦（25.3 / 30）。 來源：obra/superpowers，skills/writing-plans，固定於提交 2ce8aa1。安裝：npx skills@latest add obra/superpowers --skill writing-plans。授權條款： MIT（儲存庫 LICENSE）。
這是什麼
writing-plans 技能（obra/superpowers）：把規格轉成切成小塊的實作計畫：精確的檔案路徑、先寫一個會失敗的測試、附上預期結果的精確執行指令、最小實作、每個任務一個提交步驟、核取方塊步驟、沒有 TBD 佔位符。
我們如何測試
在專用 Windows 測試 PC 上使用 Codex CLI 0.166（gpt-6-astra，低推理），每次執行都使用全新的暫存專案與暫存 HOME/TMPDIR/快取，安裝技能（實驗組）、未安裝（對照組），或未安裝但將技能核心要求濃縮成一句話附加在提示詞後（一句話提示組），每個任務每組執行 2 次，網路關閉，/tmp 寫入封鎖。提示詞從未提及技能（以下註明的措辭除外）。
三個小型 Python 專案（todo CLI、report 模組、notes API），各有一個 spec.md。提示詞只要求在 plan.md 中提出實作計畫，並禁止撰寫程式碼。它沒有描述計畫格式。一句話提示描述了整個格式：每步 2-5 分鐘的小塊步驟、精確路徑、先寫會失敗的測試並附完整程式碼、附預期輸出的精確指令、最小實作、git 提交、沒有佔位符。
- 為 CLI 規劃到期日 — spec.md 描述了這個小型 todo CLI 的一項功能。將它的實作計畫寫到這個資料夾的 plan.md。不要在專案中寫任何程式碼，只要計畫。
- 規劃 CSV 匯出 — spec.md 描述了這個 report 模組的一項功能。將它的實作計畫寫到這個資料夾的 plan.md。不要在專案中寫任何程式碼，只要計畫。
- 規劃 API 速率限制 — spec.md 描述了這個 notes API 的一項功能。將它的實作計畫寫到這個資料夾的 plan.md。不要在專案中寫任何程式碼，只要計畫。
評分方式為程式化檢查（隱藏測試／植入問題召回／限制條件檢查／視情況進行渲染與 OCR），每次執行 0–5 分。沒有任何 LLM 評審決定分數。
結果
提供給第三組的一句話提示：「將計畫寫成小塊任務（每個步驟 2-5 分鐘）：精確的檔案路徑、先寫會失敗的測試並附完整程式碼、附預期輸出的精確指令、附完整程式碼的最小實作，然後是一個 git 提交步驟；不要有 TBD 或「加入驗證」之類的佔位符。」
| 任務 | 對照組分數 | 一句話提示 | 使用技能 | 對照組 Token 數 | 一句話提示 Token 數 | 使用技能 Token 數 | 技能讀取 |
|---|---|---|---|---|---|---|---|
| t1-todo-due | 1.51 | 4.21 | 4.28 | 94k | 132k | 111k | 2/2 |
| t2-csv-export | 1.71 | 4.47 | 4.8 | 84k | 129k | 122k | 2/2 |
| t3-rate-limit | 1.45 | 3.95 | 4.21 | 85k | 120k | 122k | 2/2 |
平均分數：未使用技能 1.56，使用技能 4.43（差異 +2.87）。每次執行 Token 數：88k 對 119k（1.34 倍）；時間 66 秒對 102 秒。一句話提示組：4.21（技能相較一句話提示的增益：+0.22；一句話提示相較無技能的增益：+2.65）；一句話提示每次執行 127k Token，因此技能的成本是一句話提示的 0.93 倍。
實際發生了什麼
- 對照組 1.56、技能組 4.43、一句話提示組 4.21（各 n=6）。對照組的計畫是簡短的文字大綱（46-71 行）：6 次執行中都沒有先寫失敗測試的步驟、沒有預期輸出、也沒有提交步驟，而且各只有一個執行指令。
- 技能的計畫是 110-142 行，採核取方塊格式，包含失敗測試步驟、標示「Expect failure」或「Expect all tests to pass」的執行步驟，以及 CSV 任務中的任務層級提交。它們仍有缺口：6 次執行中有 4 次沒有 git 提交步驟，程式碼區塊只出現在 2-3 個步驟中，而非每個步驟。
- 一句話提示的計畫約 350 行，每個步驟都有完整程式碼，且包含所有必要的提交與指令，但 6/6 次都沒有核取方塊（技能特有的格式），而且 6 次中有 3 次的執行指令少於 4 個，因為它們使用了 PowerShell 的措辭。
- Token：每次執行技能組 119k、一句話提示 127k、對照組 88k（對照組的 1.35 倍）。技能在 6/6 次實驗組執行中被讀取。
各面向分數
| 面向 | 分數 | 原因 |
|---|---|---|
| 1_輸出品質 | 4.43 | 使用技能時平均分數 4.43/5（程式化檢查，見各任務 表格）。 |
| 2_相較無技能的提升 | 4.87 | 相較未使用技能的 1.56，+2.87 分（每項任務 n=2；約 1 分以下 屬於雜訊）。 |
| 3_觸發 | 5.0 | 技能檔案在 6/6 次實驗組執行中被讀取。 |
| 4_指令可攜性 | 4 | SKILL.md 採用 superpowers 格式；執行時會參照其他 superpowers 技能。 |
| 5_效率 | 3 | 1.34 倍 Token（每次執行 119k 對 88k）與 1.54 倍時間（102 秒對 66 秒）。 |
| 6_安全性與衛生 | 4 | 僅有文字；見 security.md。 |
這項測試的限制
- 以規則檢查 plan.md 的文字：路徑、指令、提交、核取方塊與程式碼區塊的數量。計畫品質、計畫是否真的可行，並未評判。
- 我在看到第一次評分後修改了檢查，並以相同的新規則重新評分每一次執行：(1)「沒有佔位符」檢查會匹配 TODO 這個字，而它是 todo-CLI 任務的產品名稱（從模式中移除 TODO）；(2)「先寫失敗測試」與「預期輸出」的模式放寬，以接受「Expect failure」與「Expect all tests to pass」；(3) 提交門檻從 3 降到 2（技能的計畫有兩個任務），核取方塊門檻從 12 降到 8。修改前技能得分 2.98、一句話提示 4.04；修改後為 4.43 與 4.21。對照組無論如何都維持在 1.4-1.6。
- 核取方塊檢查計入的是技能使用、而一句話提示從未要求的格式，這對技能有利。
- 每個儲存格 n=2；小型 fixture。
- 每項任務每組 n = 2：約 1 分以下的差異屬於雜訊。
- 規則式評分只能衡量檢查看得到的部分；無法評判品味，也無法判斷結果是否為最佳可能。
安全性
見 security.md。掃描：CRITICAL 0 / HIGH 0 / MEDIUM 0。判定：可安全執行（網路關閉的沙箱）。乾淨的掃描結果不能證明技能安全。
總結
沒有輔助時，Codex 寫出鬆散的大綱；使用技能時，它寫出真正的 TDD 步驟。一段指名相同格式的文字效果幾乎一樣好，而且每個步驟產生的程式碼更完整，因此技能主要只是那段文字的便利捆綁。
完整紀錄
執行日誌：writing-plans (Codex CLI, network off, per-run temp HOME/TMPDIR, one row per graded run.) 欄位：任務、組-輪次、得分（0-5）、token、秒、通過的檢查、代理開啟的 skill 檔案。 t1-todo-due control-1: 得分 1.38, token 102848, 秒 60.8, 檢查 3/10, 未開啟 t1-todo-due control-2: 得分 1.64, token 86724, 秒 67.6, 檢查 3/10, 未開啟 t1-todo-due oneliner-1: 得分 4.47, token 133771, 秒 130.1, 檢查 9/10, 未開啟 t1-todo-due oneliner-2: 得分 3.95, token 131546, 秒 112.8, 檢查 8/10, 未開啟 t1-todo-due treatment-1: 得分 4.34, token 123893, 秒 104.1, 檢查 8/10, 開啟 writing-plans t1-todo-due treatment-2: 得分 4.21, token 99712, 秒 99.6, 檢查 8/10, 開啟 writing-plans t2-csv-export control-1: 得分 1.71, token 85021, 秒 70.6, 檢查 4/10, 未開啟 t2-csv-export control-2: 得分 1.71, token 84700, 秒 64.8, 檢查 4/10, 未開啟 t2-csv-export oneliner-1: 得分 4.47, token 129967, 秒 119.6, 檢查 9/10, 未開啟
18 次執行、3 個產出檔案
範例產出
SOTA · 装了 skill：plan.md（t1-todo-due，第 1 次，Codex）
# Todo Due Dates Implementation Plan > **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking. **Goal:** Add optional due dates, chronological listing, and an overdue-only CI check without migrating existing data. **Architecture:** Keep the existing JSON dictionary storage and implement date validation, ordering, and rendering in `todo/cli.py`. Capture the local date once per list invocation and pass it to a pure overdue predicate. Preserve the existing `main(argv=None)` entry point and argparse error handling. **Tech Stack:** Python standard library: argparse, datetime, json, unittest, unittest.mock, tempfile; no new dependencies. **Spec:** `spec.md` (read alongside this plan). ## Global Constraints - `todo add "title" --due 2026-03-01` stores an optional ISO due date with the item. - `todo list` prints overdue items first (marked `!`), then by due date, then undated items. - `todo list --overdue` prints only overdue items; exit code 1 if there are any (so CI can use it). - Invalid dates are rejected with a clear message and exit code 2. - Items already stored without a due date must keep working (no migration step for the user). ## Decisions for details not specified - Accept exactly `YYYY-MM-DD` with a real Gregorian calendar date; reject whitespace, compact dates, timestamps, and unpadded components. - An item is overdue only when unfinished and its due date is strictly before the current local date. Due today is not overdue. - Sort overdue items by ascending due date, then remaining dated items by ascending due date, then undated items. Preserve insertion order within equal keys. Completed items remain visible in ordinary listings but are never overdue. - Preserve `[ ] title` and `[x] title` for undated items. Append ` (due YYYY-MM-DD)` for dated items and prefix overdue lines with `! `, e.g. `! [ ] rent (due 2026-03-01)`. - Ordinary listing returns 0, even with overdue items. Overdue-only listing returns 0 with no output when none qualify. Listing never rewrites storage. - Store dates as strings under `due`; omit the key when not supplied. Treat an absent key or `null` as undated. Arbitrary corrupt JSON or malformed dates manually inserted into storage are outside this feature. ## Review Focus 1. Calendar boundaries: leap day is accepted only in leap years; impossible dates fail before storage changes (Task 1). 2. ISO-looking variants: compact dates, timestamps, whitespace, and unpadded dates are rejected (Task 1). 3. Midnight/today boundary: due today is not overdue; use one captured local date per listing (Task 2). 4. Completed items with past dates: remain visible without `!` and are excluded from overdue filtering (Tasks 2–3). 5. Legacy and tied items: missing/null dates work, ties retain insertion order, and listing leaves the JSON file untouched (Tasks 2–3). ## File Map - Modify `todo/cli.py`: add argument validation, optional date persistence, overdue predicate, sorting, rendering, and filter exit status. - Create `tests/test_cli.py`: isolated CLI tests u [... excerpt: first 3200 of 11517 characters]