---
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.