القائمة
Six-question diagnostic framework for G0 pre-check — validate product direction before development starts
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Initialize new project with CLAUDE.md, .knowledge/ structure, company rules, and git
Generate a development plan with task breakdown and section 10 tracking tables
L1 Code Review SOP — 強制規範對照 + 審核決策，不得跳過任何 checkpoint
Merge sprint branch to base branch, tag release, and clean up branches
Mark a task as done after L1 review passes
Boss dispatches tasks — auto-create .tasks/ files and record in dev-plan
| name | product-diagnosis |
| description | Six-question diagnostic framework for G0 pre-check — validate product direction before development starts |
| allowed-tools | Read, Glob, Grep |
在開發啟動前，用六問框架診斷產品方向，確保 G0 提案品質。
/product-diagnosis <project-name>
$ARGUMENTS: 專案名稱或描述（可選，若不提供則詢問）依序回答以下六個問題，每個問題必須有明確結論：
我們要解決的問題，用戶真的有感嗎？
| 檢查項 | 說明 |
|---|---|
| 痛點來源 | 這個問題從哪裡來的？（用戶回饋 / 數據異常 / 老闆直覺 / 競品觀察） |
| 頻率 | 這個問題多常發生？（每天 / 每週 / 偶爾） |
| 嚴重度 | 不解決會怎樣？（流失用戶 / 降低效率 / 無影響） |
| 現有替代方案 | 用戶現在怎麼解決？成本高嗎？ |
結論: [ ] 問題真實存在且值得解決 / [ ] 問題存在但優先級低 / [ ] 問題不成立
這個功能是給誰用的？他們的使用場景是什麼？
| 檢查項 | 說明 |
|---|---|
| 用戶角色 | 老闆 / Agent / 兩者皆是 |
| 使用頻率 | 每天 / 每週 / 每個 Sprint / 一次性 |
| 技術水平 | 需要理解底層原理嗎？ |
| 關鍵場景 | 描述 1-2 個最核心的使用場景 |
結論: [ ] 用戶輪廓清晰 / [ ] 需要進一步釐清
我們提出的解法，是不是最簡單有效的？
| 檢查項 | 說明 |
|---|---|
| 複雜度 vs 價值 | 實作成本和帶來的價值成比例嗎？ |
| 有沒有更簡單的做法 | 能用現有功能組合解決嗎？能用 Skill/Hook 而非新 IPC 嗎？ |
| 技術可行性 | 在當前架構下可行嗎？需要大改架構嗎？ |
| 邊界情況 | 有沒有明顯的 edge case 會讓方案崩潰？ |
結論: [ ] 解法合理 / [ ] 有更好的替代方案 / [ ] 技術上有風險
這個任務的邊界在哪裡？什麼做、什麼不做？
| 檢查項 | 說明 |
|---|---|
| 必做（Must Have） | 列出核心功能點 |
| 不做（Out of Scope） | 明確排除哪些功能 |
| 驗收標準 | 怎麼判斷「做完了」？ |
| 依賴 | 需要其他任務先完成嗎？ |
結論: [ ] 範圍清晰可執行 / [ ] 範圍過大需拆分 / [ ] 範圍模糊需釐清
這個功能和現有架構一致嗎？會破壞什麼嗎？
讀取以下文件進行比對：
.knowledge/architecture.md — 系統架構.knowledge/coding-standards.md — 編碼規範.knowledge/postmortem-log.md — 是否有相關踩坑紀錄| 檢查項 | 說明 |
|---|---|
| IPC 四方同步 | 新增 IPC 通道是否遵守四方同步規則？ |
| 資料流向 | 資料從哪來到哪去？有沒有繞過正規路徑？ |
| 命名規範 | 新增的命名是否符合現有慣例？ |
| 歷史教訓 | postmortem-log 中有沒有相關的踩坑紀錄？ |
結論: [ ] 符合架構 / [ ] 需要小幅調整 / [ ] 需要架構決策（提交老闆）
最壞的情況是什麼？我們能承受嗎？
| 風險類型 | 評估 |
|---|---|
| 時間風險 | 能在 1 個 Sprint 內完成嗎？ |
| 技術風險 | 有沒有不確定的技術難題？ |
| 回歸風險 | 會不會破壞現有功能？ |
| 維護風險 | 未來維護成本高嗎？ |
結論: [ ] 風險可控 / [ ] 中等風險需監控 / [ ] 高風險建議延後
完成六問後，輸出以下摘要：
# 產品診斷報告
**專案**: {project-name}
**診斷日期**: {today}
**診斷人**: Tech Lead
## 診斷摘要
| # | 診斷問題 | 結論 | 備註 |
|---|---------|------|------|
| Q1 | 問題存在嗎？ | {結論} | {一句話說明} |
| Q2 | 目標用戶是誰？ | {結論} | {一句話說明} |
| Q3 | 解法合理嗎？ | {結論} | {一句話說明} |
| Q4 | 範圍明確嗎？ | {結論} | {一句話說明} |
| Q5 | 符合架構嗎？ | {結論} | {一句話說明} |
| Q6 | 風險可控嗎？ | {結論} | {一句話說明} |
## 總體建議
[ ] 建議通過 G0，可進入開發
[ ] 建議修改後再提交 G0（附修改建議）
[ ] 建議暫緩（附原因）
[ ] 建議取消（附原因）
## 修改建議（若有）
{具體的修改建議}