sdlc/skills/analyze/SKILL.md

name, description

name

description

analyze

SDLC analysis stage. Gate on capability tags enforced in code by sdlc-gate (analyze requires reasoning-max, verified against the transcript's actual model id), confirm the source branch with the user, pick a plan from PLAN_CONTENTS, analyze user stories against the current state (working directory plus REPO_{HASH} inventory for reuse). Run WBS with handover work packages ranked first (spec before implementation), estimate them with CPM, split each into TDD todos, and write wiki page ANALYZE_{HASH} with real sample data. 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} used to build the ANALYZE_{HASH} page name, computed by jsc-gitea/tools/hash-id (see jsc-gitea:wiki). All wiki reads and writes go through jsc-gitea:wiki.

Steps

1. Model gate and stage lock (capability tags, enforced in code — never self-assessed):
   1. Run jsc-cli/tools/model-tags.sh sync to refresh $JSC_HOME/model-tags.tsv from jsc-cli/references/model-tags.md.
   2. Run jsc-hooks/hooks/sdlc-gate.sh lock analyze. The script reads the actual model id from the transcript, compares it against this stage's required tags (reasoning-max), and locks the stage only when they match.
   3. Never claim a capability tag you have not verified with that script, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run unlock to get past the gate; only the user may decide that.
   4. Exit 0 means the stage is locked. From now until the next stage's gate runs, the sdlc-gate hook blocks every prompt whose model stops satisfying the tags.
2. Confirm the source branch — the branch whose code counts as the current state:
   1. Report the working directory's current branch, plus the remote branches available (git branch -r) and whether the working tree is clean.
   2. Ask per jsc-ask:ask rules which branch the analysis reads from; state the impact scope on every option (analysing the wrong branch produces work packages for code that does not exist).
   3. When the chosen branch is not the current one, stop and ask the user to switch. This stage never switches branches, never stashes, and never touches the working tree — see /jsc-shared:spec-git-safety.
   4. Record the confirmed branch and its head sha on the analysis page. Completion condition: the user has confirmed the branch explicitly; never infer it from the current checkout alone.
3. Read PLAN_CONTENTS via jsc-gitea:wiki for plans whose status is the literal 「未分析」 (name and HASH), and read ANALYZE_CONTENTS for existing analyses.
4. 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.
5. 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, on the branch confirmed in step 2.
   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.
6. Run a Work Breakdown Structure (WBS): split the user stories into work packages, number them sequentially (WP-01, WP-02, ...) and mark dependencies.
7. Rank handover work packages first — see 「交接優先」 below. Spec-shaped packages ship before implementation-shaped ones.
8. Estimate every work package's effort in hours and days with the Critical Path Method (CPM), and mark the critical path.
9. 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.
10. 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.
11. 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 「已分析」.

交接優先（handover first）

A work package is a handover package when someone else — another person, another CLI, another team — has to act on its output. Interfaces, schemas, spec documents, acceptance criteria and sample payloads are handover output; endpoint bodies and UI wiring are not.

• Mark every work package as 交接 是 / 否 in the WBS table.
• Order handover packages before implementation packages, so the receiving side gets the spec while implementation is still open. Implementation packages are the backup queue (實作候補): they are still numbered, estimated and kept on the page, just ranked later.
• Dependencies still win: never place a package before one it depends on. Within the same dependency level, handover packages come first.
• Do not merge a spec and its implementation into one package — that removes the ability to hand the spec over early. Split them.

範例資料（sample data）

Every sample value on the analysis page — request and response payloads, field values, config snippets, test fixtures — follows this order:

1. Real data first. Take values from an actual source: the database schema and rows, a real API response, an existing config or fixture file, logs. Record where each sample came from in the WBS table's 資料來源 column (for example 真實：dbo.Member).
2. Only when no source exists, derive the value by reasoning from the surrounding logic — and label it as inferred (for example 推論：無來源), so the receiving side knows it is unverified.
3. Never invent a plausible-looking value and present it as real, and never leave the origin of a sample unstated.
4. Real data goes on the page as structure and format only: field names, types, shapes. Never copy personal data onto the wiki — mask any personal identifier, and prefer describing the format over pasting the value.

Hard limits

• Never output a code snippet (file paths and method names are allowed).
• Never modify any file in the working directory.
• Never switch, create or clean branches in this stage; ask the user to do it.