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