jiantw83andClaude Opus 5
62fd2a6022
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
39 lines
3.6 KiB
Markdown
39 lines
3.6 KiB
Markdown
---
|
|
name: plan
|
|
description: SDLC planning stage. Gate on capability tags enforced in code by sdlc-gate (plan requires reasoning-max, verified against the transcript's actual model id), pick or create a plan from PLAN_CONTENTS, then run a decision tree until goal, scope, and feasibility reach consensus. Produce user stories into wiki page PLAN_{HASH}. Logic only - never write code or modify files. Use when the user wants to start or refine a plan; not for analysis or implementation.
|
|
---
|
|
|
|
# plan
|
|
|
|
Goal: create or extend the wiki plan page `PLAN_{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 `PLAN_{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 plan`. 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. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` and list the plans whose status is the literal 「未分析」 (not analyzed), with names and HASH.
|
|
3. Let the user choose per `jsc-ask:ask` rules: **extend an existing plan** (list the not-analyzed plans as options) or **create a new plan**. State the impact scope on every option.
|
|
4. **Keep questioning until consensus** — rules in `references/consensus.md`, which is the single authority for both planning and analysis. Cover all three items:
|
|
- Goal: the problem to solve and the criteria for success.
|
|
- Scope: what is included, what is excluded, which repositories are involved.
|
|
- Feasibility: whether the system architecture and data sources support the goal.
|
|
|
|
**One round is never enough**: every answer must produce the next question, derived from what that answer just exposed. Consensus needs both conditions from `references/consensus.md` — no remaining unknown that would change the output, **and** the user's explicit confirmation of the summary you read back. Never fill a gap with your own assumption, and never move on to user stories while any item is still open.
|
|
5. Turn the consensus into **user stories** (the zh-TW pattern 「身為⋯⋯我想要⋯⋯以便⋯⋯」), one per line.
|
|
6. Apply `templates/plan-page.md` to create or update the plan page, and write it back via `jsc-gitea:wiki`. The page content is Traditional Chinese, exactly as the template dictates.
|
|
7. If the plan page is new, add it to `PLAN_CONTENTS` using the entry format of `templates/plan-contents.md`, with status set to the literal 「未分析」.
|
|
|
|
## Hard limits
|
|
|
|
- Never output a code snippet.
|
|
- Never modify any file in the working directory.
|
|
- Never skip the decision tree and assume requirements.
|
|
- Never stop questioning after one round; consensus is reached only under `references/consensus.md`, and the user says so.
|