sdlc/skills/analyze/SKILL.md

name, description

name

description

analyze

SDLC analysis stage. Gate on model capability tags, pick a plan from PLAN_CONTENTS, analyze user stories against the current state (working directory plus REPO_{HASH} inventory for reuse). Run WBS to produce numbered work packages, estimate them with CPM, split each into TDD todos, and write wiki page ANALYZE_{yyyyMMdd}_{HHmmss}_{HASH}. Logic only - never write code or modify files. Use after planning and before implementation.

analyze — 分析

目標：產出或補充 WIKI 分析頁 ANALYZE_{yyyyMMdd}_{HHmmss}_{HASH}。 本技能是純邏輯階段：不可以出現任何程式碼，也禁止修改任何檔案。

{HASH} = {owner}/{repo} 的 SHA-1 前 8 碼、大寫。 所有 wiki 讀寫一律經由 jsc-gitea:wiki。

流程

1. 模型能力檢查：依 jsc-cli:models 的能力標籤確認目前模型具備「分析」能力。不適合就阻擋流程，並告知使用者建議改用的模型。
2. 經由 jsc-gitea:wiki 讀取 PLAN_CONTENTS 的未分析計畫（名稱與 HASH），並讀取 ANALYZE_CONTENTS 的既有分析。
3. 依 jsc-ask:ask 規則讓使用者選擇：補充既有分析或分析新計畫。每個選項標明影響範圍。
4. 搭配現況，依 jsc-ask:ask 決策樹逐條分析計畫頁的使用者故事，直到補全所有疑慮；只要還沒達成共識就繼續詢問。現況定義：
   1. 工作目錄的所有檔案。
   2. 盡量複用既有方法或端點：
      • 優先查 REPO_{HASH} 盤點頁。若功能與端點不存在，或紀錄的 commit sha 與目前不同，就重新盤點。
      • 重新盤點必須以 sub agent 執行：分析該存取庫的功能與端點，加上目前 commit sha，套用 templates/repo-page.md 寫回 REPO_{HASH}，並依 templates/repo-contents.md 更新 REPO_CONTENTS。
      • 對候選的複用目標，先確認檔案路徑與方法名稱，再分析邏輯是否符合需求。
5. 執行工作分解結構（WBS）：把使用者故事拆成工作包，每個工作包給編號（WP-01、WP-02 依序遞增）並標明相依關係。
6. 以**關鍵路徑法（CPM）**估算每個工作包的工時與天數，標出關鍵路徑。
7. 以**測試驅動開發（TDD）**把每個工作包拆解成多個待辦事項，格式 [ ]（未完成）/ [x]（完成），每項為一個垂直切片（一個接縫、一個測試、一個最小實作）；接縫與反模式見 references/tdd.md。
8. 套用 templates/analyze-page.md 產生或更新分析頁，經由 jsc-gitea:wiki 寫回。
9. 若是新的分析頁：依 templates/analyze-contents.md 加入 ANALYZE_CONTENTS，並把 PLAN_CONTENTS 對應計畫的狀態改為「已分析」。

禁止事項

• 不可輸出任何程式碼片段（檔案路徑與方法名稱可以）。
• 不可修改工作目錄的任何檔案。