docs(sdlc): translate SKILL.md into English per guidelines
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
+23
-23
@@ -3,32 +3,32 @@ name: analyze
|
||||
description: 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 — 分析
|
||||
# analyze
|
||||
|
||||
目標:產出或補充 WIKI 分析頁 `ANALYZE_{yyyyMMdd}_{HHmmss}_{HASH}`。
|
||||
本技能是**純邏輯**階段:不可以出現任何程式碼,也**禁止修改任何檔案**。
|
||||
Goal: create or extend the wiki analysis page `ANALYZE_{yyyyMMdd}_{HHmmss}_{HASH}`.
|
||||
This skill is a **logic-only** stage: never output code, and **never modify any file**.
|
||||
|
||||
`{HASH}` = `{owner}/{repo}` 的 SHA-1 前 8 碼、大寫。
|
||||
所有 wiki 讀寫一律經由 `jsc-gitea:wiki`。
|
||||
`{HASH}` = first 8 chars of the SHA-1 of `{owner}/{repo}`, uppercase.
|
||||
All wiki reads and writes go through `jsc-gitea:wiki`.
|
||||
|
||||
## 流程
|
||||
## Steps
|
||||
|
||||
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` 對應計畫的狀態改為「已分析」。
|
||||
1. **Model capability gate**: check the capability tags from `jsc-cli:models` and confirm the current model qualifies for analysis. If not, block the flow and tell the user which model to switch to.
|
||||
2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` for plans whose status is the literal 「未分析」 (name and HASH), and read `ANALYZE_CONTENTS` for existing analyses.
|
||||
3. Let the user choose per `jsc-ask:ask` rules: **extend an existing analysis** or **analyze a new plan**. State the impact scope on every option.
|
||||
4. Analyze the plan page's user stories one by one against the **current state**, questioning via the `jsc-ask:ask` decision tree until no doubt remains; keep asking while consensus is missing. Current state means:
|
||||
1. Every file in the working directory.
|
||||
2. **Reuse existing methods and endpoints whenever possible**:
|
||||
- Check the `REPO_{HASH}` inventory page first. Re-inventory when the feature or endpoint is missing, or when the recorded commit sha differs from the current one.
|
||||
- Re-inventory **MUST run as a sub agent**: analyze the repository's features and endpoints, attach the current commit sha, write back to `REPO_{HASH}` with `templates/repo-page.md`, and update `REPO_CONTENTS` per `templates/repo-contents.md`.
|
||||
- For each reuse candidate, confirm the file path and method name first, then analyze whether its logic fits the requirement.
|
||||
5. Run a **Work Breakdown Structure (WBS)**: split the user stories into work packages, number them sequentially (`WP-01`, `WP-02`, ...) and mark dependencies.
|
||||
6. Estimate every work package's effort in hours and days with the **Critical Path Method (CPM)**, and mark the critical path.
|
||||
7. Split every work package into todos with **Test-Driven Development (TDD)**, formatted `[ ]` (open) / `[x]` (done). Each todo is one vertical slice: one seam, one test, one minimal implementation. Seams and anti-patterns: `references/tdd.md`.
|
||||
8. Apply `templates/analyze-page.md` to create or update the analysis page and write it back via `jsc-gitea:wiki`. The page content is Traditional Chinese, exactly as the template dictates.
|
||||
9. If the analysis page is new: add it to `ANALYZE_CONTENTS` per `templates/analyze-contents.md`, and flip the plan's status in `PLAN_CONTENTS` to the literal 「已分析」.
|
||||
|
||||
## 禁止事項
|
||||
## Hard limits
|
||||
|
||||
- 不可輸出任何程式碼片段(檔案路徑與方法名稱可以)。
|
||||
- 不可修改工作目錄的任何檔案。
|
||||
- Never output a code snippet (file paths and method names are allowed).
|
||||
- Never modify any file in the working directory.
|
||||
|
||||
Reference in New Issue
Block a user