35 lines
3.2 KiB
Markdown
35 lines
3.2 KiB
Markdown
---
|
|
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_{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 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.
|