jiantw83andClaude Fable 5
2705771c20
What：plan、analyze、implement、maintain 四個 SKILL.md 的第一步從單純的能力標籤檢查，改為「模型閘門與階段上鎖」三段流程：先以 jsc-cli/tools/model-config.sh get {stage} 解析該階段的指定模型鏈，鏈上第一個當前 CLI 可用的模型即為必用模型；沒有設定指定模型時才退回 jsc-cli:models 的能力標籤檢查。閘門通過後執行 jsc-hooks/hooks/sdlc-gate.sh lock {stage} {current-model} 寫入鎖檔，並以 sdlc-gate.sh report 驗證。
Why：原本只驗能力標籤，同一標籤下模型可任意替換，階段中途換模型也無人攔阻，導致產出品質與可重現性不穩定。改為指定模型鏈優先可讓團隊明確指派每階段用哪個模型，標籤備援則保留未設定時的彈性；上鎖後由 hook 在每次 prompt 強制檢查，階段內換模型會被擋下。
How：每個技能的步驟一拆成三小步（解析模型鏈、驗證當前模型、上鎖並驗證鎖檔），各小步附完成條件；maintain 另加第四小步，明確規定只在換階段時重跑閘門，維護階段內跨專案不重複驗證。frontmatter description 同步更新。鎖定自 plan 起手生效，直到下一階段（如 analyze）的閘門重新上鎖前，強制沿用同一模型。
Who：jsc-sdlc 的 plan／analyze／implement／maintain 四個技能，及依賴其閘門行為的 jsc-hooks sdlc-gate hook。
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
38 lines
4.0 KiB
Markdown
38 lines
4.0 KiB
Markdown
---
|
|
name: analyze
|
|
description: SDLC analysis stage. Gate on the designated model (model-config) or capability tags, lock the model for the stage via sdlc-gate, 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_{HASH}. Logic only - never write code or modify files. Use after planning and before implementation.
|
|
---
|
|
|
|
# analyze
|
|
|
|
Goal: create or extend the wiki analysis page `ANALYZE_{HASH}`.
|
|
This skill is a **logic-only** stage: never output code, and **never modify any file**.
|
|
|
|
`{HASH}` = the shared wiki hash for `{owner}/{repo}`: take the first 8 uppercase hex chars of its SHA-1. If the first char is a digit, or `A`/`B`/`C`, replace it with `H` and keep the next 7 chars.
|
|
All wiki reads and writes go through `jsc-gitea:wiki`.
|
|
|
|
## Steps
|
|
|
|
1. **Model gate and stage lock**:
|
|
1. Resolve the analyze stage's designated model chain: run `jsc-cli/tools/model-config.sh get analyze`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (analysis requires the reasoning-high tag).
|
|
2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate.
|
|
3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock analyze {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`.
|
|
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.
|