From zenbu-powers
規劃複雜功能與重構的劇本：重述需求、研究風險、審視缺口、澄清疑點、建立分階段實作計劃。 定義完整的計劃輸出格式（含資料流分析、錯誤處理登記表、失敗模式登記表）、檢查清單與範本。 由 planner agent 載入使用；也可在即將進行跨多檔案改動、重大架構調整或複雜重構前主動引用。
npx claudepluginhub zenbuapps/zenbu-powers --plugin zenbu-powersThis skill uses the workspace's default tool permissions.
提供建立完整實作計劃所需的流程、輸出格式與檢查清單。供 `@zenbu-powers:planner` agent 執行規劃任務時載入。
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Checks Next.js compilation errors using a running Turbopack dev server after code edits. Fixes actionable issues before reporting complete. Replaces `next build`.
Guides code writing, review, and refactoring with Karpathy-inspired rules to avoid overcomplication, ensure simplicity, surgical changes, and verifiable success criteria.
Share bugs, ideas, or general feedback.
提供建立完整實作計劃所需的流程、輸出格式與檢查清單。供 @zenbu-powers:planner agent 執行規劃任務時載入。
在開始規劃之前，必須先完成：
CLAUDE.md（如存在），瞭解專案指引、架構、建構指令與命名慣例.claude/rules/*.md（如存在）./specs/*、./specs/**/erm.dbml（如存在），瞭解 SKILL、Spec、資料模型等src/、inc/、app/），掌握架構風格⚠️ 若無法讀取相關檔案，應明確告知使用者缺少哪些資訊，再繼續規劃。
分析請求，以清楚的語言重述需求：正在建構什麼、服務對象是誰、成功的樣子是什麼。
規劃之前，主動搜尋：
列出已找到的風險及其來源，標記哪些在需求中尚未處理。
若未找到特定風險，備註「未發現額外已知風險」並繼續。
逐一檢查下列項目，未解決的項目將成為澄清問題：
依 clarify-loop skill 的規則進行澄清，本 skill 不重新定義提問格式。
規劃場景的推薦參數：
BATCH_SIZE = 1（選擇題），每題附推薦選項與理由MAX_QUESTIONS_PER_ROUND = 6非平凡流程必須建立以下內容：
INPUT ──▶ VALIDATION ──▶ TRANSFORM ──▶ PERSIST ──▶ OUTPUT
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
[nil?] [invalid?] [exception?] [conflict?] [stale?]
[empty?] [too long?] [timeout?] [dup key?] [partial?]
目的：列出每個階段的 shadow path（nil / empty / error），確保所有分支都有處理。
| 方法/路徑 | 可能失敗原因 | 錯誤類型 | 處理方式 | 使用者可見? |
|---|
規則：「處理方式=無」且「使用者可見?=靜默」= CRITICAL GAP，必須在實作前解決。
| 程式碼路徑 | 失敗模式 | 已處理? | 有測試? | 使用者可見? | 恢復路徑 |
|---|
注意：REDUCTION 模式下，以上三個區塊可精簡為僅列出 critical path。
將實作拆解為各階段，每個階段包含：
# 實作計劃：[功能名稱]
## 概述
[2-3 句摘要，說明要建構什麼與為什麼]
## 需求重述
[清楚重述正在建構的內容]
## 已知風險（來自研究）
- 風險：[描述] — 緩解措施：[策略]
## 架構變更
- [變更 1：檔案路徑與說明]
- [變更 2：檔案路徑與說明]
## 資料流分析
### [流程名稱]
```
INPUT ──▶ VALIDATION ──▶ TRANSFORM ──▶ PERSIST ──▶ OUTPUT
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
[nil?] [invalid?] [exception?] [conflict?] [stale?]
[empty?] [too long?] [timeout?] [dup key?] [partial?]
```
## 錯誤處理登記表
| 方法/路徑 | 可能失敗原因 | 錯誤類型 | 處理方式 | 使用者可見? |
| --------- | ------------ | -------- | -------- | ----------- |
| | | | | |
## 失敗模式登記表
| 程式碼路徑 | 失敗模式 | 已處理? | 有測試? | 使用者可見? | 恢復路徑 |
| ---------- | -------- | ------- | ------- | ----------- | -------- |
| | | | | | |
## 實作步驟
### 第一階段：[階段名稱]
1. **[步驟名稱]**（檔案：path/to/file.ts）
- 行動：要執行的具體操作
- 原因：此步驟的理由
- 依賴：無 / 需要步驟 X
- 風險：低 / 中 / 高
### 第二階段：[階段名稱]
...
## 測試策略
- 單元測試：[待測試的檔案]
- 整合測試：[待測試的流程與預期行為]
- E2E 測試：[待測試的使用者旅程]
- 測試執行指令：[對應的測試命令]
- 關鍵邊界情況：[需要覆蓋的邊界條件]
## 依賴項目
[外部工具、服務、函式庫]
## 風險與緩解措施
- **高**：[風險描述] — [緩解方法]
- **中**：[風險描述] — [緩解方法]
- **低**：[風險描述] — [緩解方法]
## 錯誤處理策略
[從步驟 4 選定的方法，以及如何應用於此任務]
## 限制條件
[此計劃不會做的事；邊界；禁止的做法]
## 成功標準
- [ ] 標準 1
- [ ] 標準 2
## 預估複雜度：高 / 中 / 低
當功能規模較大時，拆解為可獨立交付的階段：
每個階段都應可獨立合併。避免所有階段都完成才能運作的計劃。
對於涉及全專案重構、批次檔案修改或多階段流水線的任務，計劃必須包含：
.progress.json 並從最後一個檢查點恢復，跳過已完成項目npm test、phpunit、eslint）；驗證失敗則阻止下一批執行計劃呈現前，應自我檢查下列警示訊號：
記住：好的計劃是具體的、可執行的，並且同時考量主要流程與邊界情況。最好的計劃能讓人有信心地進行漸進式實作。
| 名稱 | 用途 |
|---|---|
/clarify-loop | 澄清疑點時依此 skill 的規則提問 |
@zenbu-powers:planner | 載入此 skill 執行規劃任務；規劃完成後交接給 tdd-coordinator |
@zenbu-powers:tdd-coordinator | 計劃完成後接手執行 TDD 流程（Red → Green → Refactor） |