writing-planslisted

# 撰寫計畫 ## 總覽 撰寫全面的實作計畫，並假設工程師對我們的程式碼庫零上下文、品味存疑。記錄他們需要知道的一切：每個任務要動哪些檔案、程式碼、測試、��能需要查閱的文件、如何測試。把整個計畫拆成小塊任務交給他們。DRY。YAGNI。TDD。頻繁 commit。 假設他們是熟練的開發者，但對我們的工具組或問題領域幾乎一無所知。假設他們不太懂好的測試設計。 **開始時宣告：** 「我正使用 writing-plans 技能來建立實作計畫。」 **上下文：** 如果在隔離的 worktree 中工作，它應該已在執行時透過 `superpowers:using-git-worktrees` 技能建立。 **計畫儲存位置：** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md` - （使用者對計畫位置的偏好會覆蓋這個預設） ## 範圍檢查 如果規格���蓋多個獨立的子系統，它應該在腦力激盪時被拆成子專案規格。如果沒有，建議把它拆成多份獨立計畫 —— 每個子系統一份。每份計畫應該要能獨立產出可運作、可測試的軟體。 ## 檔案結構 在定義任務之前，先規劃哪些檔案會被建立或修改，以及每個檔案負責什麼。分解的決策在這裡鎖定。 - 設計邊界清楚、介面定義良好的單元。每個檔案應該有單一清楚的職責。 - 你對能同時放進上下文的程式碼思考得最好，而檔案越聚焦，你的編輯就越可靠。偏好較小、聚焦的檔案，勝過塞太多事的巨型檔案。 - 一起變更的檔案應該住在一起。���職責拆分，而不是依技術層拆分。 - 在既有程式碼庫中，遵循既有模式。如果程式碼庫使用大型檔案，不要單方面重構 —— 但如果你正在修改的檔案已經長到難以掌控，把拆分寫進計畫是合理的。 這個結構支撐任務的分解。每個任務應該產出自足的變更，且可以獨立理解。 ## 任務尺寸調校 一個任務是承載自己的測試循環、並值得一個全新審查者關卡的最小單位。在劃分任務邊界時：把設定、配置、脚手架與文件步驟併入需要這些產物的任務；只有在審查者可以有意義地否決一個任務、同時核准其鄰居任務的地方才拆分。每個任務都以一個可獨立測試的產物結束。 ## 小塊任務粒度 **每個步驟是單一動作（2-5 分鐘）：** - 「撰寫失敗的測試」- 步驟 - 「執行它以確認它失敗」- 步驟 - 「撰寫能讓測試通過的最小程式碼」- 步驟 - 「執行測試並確認它們通過」- 步驟 - 「Commit」- 步驟 ## 計畫文件標頭 **每份計畫都必須以此標頭開始：** ```markdown # [Feature Name] 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:** [One sentence describing what this builds] **Architecture:** [2-3 sentences about approach] **Tech Stack:** [Key technolog