菜单
Use after the user approves a spec.html to write or refine the corresponding plan.html. Second stage of the four-stage spec-driven workflow. Plan answers HOW the spec becomes code; respects architecture.md. Still no code execution.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Stage 5 of the spec-driven workflow — archive a shipped feature. Run this only once every task in the feature's tasks.md has shipped AND you are satisfied the work is done (typically after review, and when PR is ready to open). It promotes any durable insight into the live reference specs, then deletes the spec folder. It never writes an archive summary file. Invoke explicitly; it is not auto-chained from feature-implement.
Orchestrate the full implementation of a feature's tasks.md end to end. A supervisor agent loops over every uncompleted task, spawning an implement sub-agent then a review sub-agent, triaging the review findings with its own judgement — auto-approving the evident fixes and escalating only genuinely structuring decisions to the user via AskUserQuestion — applying the fixes, and continuing to the next task. Use when you want to drive a whole feature with minimal human intervention, surfacing only the decisions that genuinely need you.
Use to execute a single task from an approved tasks.md. Fourth stage of the four-stage spec-driven workflow. Reads spec.html, plan.html, tasks.md, then implements one task at a time, respecting constitution gates.
Use when the user wants to start a new feature in this repo. Walks the agent through writing specs/features/<feature-name>/spec.html — the first stage of the four-stage spec-driven workflow (specify → plan → tasks → implement). Read-only on code. May also draft plan.html in the same pass when the kickoff is design-rich.
Use after the user approves a plan.html to break it into ordered, independently-shippable tasks. Third stage of the four-stage spec-driven workflow. Output is tasks.md; still no code execution.
Review the last commit for complexity, dead code, missed invariants, test quality, and broader code quality opportunities. Returns a numbered findings list for discussion — does not implement fixes. Use after task-implement completes a task.
| name | spec-plan |
| description | Use after the user approves a spec.html to write or refine the corresponding plan.html. Second stage of the four-stage spec-driven workflow. Plan answers HOW the spec becomes code; respects architecture.md. Still no code execution. |
You are about to write or refine a plan for a feature whose spec is approved. Do NOT write any code yet. The output is specs/features/<feature-name>/plan.html — either created fresh, or refined in place if a draft already exists (e.g. when spec-specify produced one because the kickoff was design-rich).
Confirm which feature with the user. The corresponding specs/features/<feature-name>/spec.html must exist and be approved.
Check whether plan.html already exists.
architecture.md or constitution.md, (d) implementation-level content that drifted into the spec and should move down to the plan. Surface this delta as a punch list to the user before editing. Apply changes via Edit, preserving the existing structure. Use AskUserQuestion for any material decision the existing plan doesn't settle.Read specs/architecture.md and specs/constitution.md. The plan must respect both. If the plan requires deviating from architecture, the deviation is called out explicitly with rationale.
Save the file at specs/features/<feature-name>/plan.html.
Tell the user the plan is ready and wait for their review. Do not proceed to tasks.
The plan is a single self-contained .html file — same rules as the spec (see spec-specify):
<style> block from the template. No per-element class=, no Tailwind / Bootstrap / React / CDN.<style> block, no external stylesheet, no <script src=…>. Renders with no network.<details>/<summary> — no JavaScript.<svg> for a module / data-flow diagram instead of an ASCII sketch when a diagram helps.When refining an existing draft (Process step 2), preserve this structure and edit in place.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title><Feature title> — Implementation plan</title>
<style>
body { font-family: system-ui, -apple-system, sans-serif; line-height: 1.6;
max-width: 52rem; margin: 2rem auto; padding: 0 1.2rem; color: #1a1a1a; }
h1 { border-bottom: 2px solid #e0e0e0; padding-bottom: .3rem; }
h2 { margin-top: 2rem; }
.status { color: #666; font-size: .9rem; }
table { border-collapse: collapse; width: 100%; margin: 1rem 0; }
th, td { border: 1px solid #ccc; padding: .4rem .6rem; text-align: left; vertical-align: top; }
th { background: #f5f5f5; }
code { background: #f4f4f4; padding: .1rem .35rem; border-radius: 3px; font-size: .9em; }
details { margin: .6rem 0; border: 1px solid #e0e0e0; border-radius: 6px; padding: .4rem .8rem; }
summary { cursor: pointer; font-weight: 600; }
</style>
</head>
<body>
<h1><Feature title> — Implementation plan</h1>
<p class="status">Status: Plan — under review · <YYYY-MM-DD> · Spec: <a href="spec.html">spec.html</a></p>
<section>
<h2>1. Approach</h2>
<p>One- or two-paragraph summary of how the spec becomes code. Name the key abstractions or files.
An inline <code><svg></code> module / data-flow diagram goes here when it helps.</p>
</section>
<section>
<h2>2. Affected modules</h2>
<table>
<thead><tr><th>Module / file</th><th>Change type</th><th>Note</th></tr></thead>
<tbody>
<tr><td><code>efootprint/...</code></td><td>new / modified</td><td>...</td></tr>
</tbody>
</table>
</section>
<section>
<h2>3. Cross-cutting concerns</h2>
<ul>
<li><strong>Tests:</strong> what test layers (unit / integration / e2e) are affected, and what the new coverage looks like at a glance.</li>
<li><strong>Migrations:</strong> if JSON schema or DB schema change, identify the migration path.</li>
<li><strong>Docs:</strong> what spec files (<code>architecture.md</code>, <code>conventions.md</code>) need to follow.</li>
</ul>
</section>
<section>
<h2>4. Risks</h2>
<ul>
<li>Risk 1 — what could go wrong, mitigation.</li>
<li>Risk 2 — ...</li>
</ul>
</section>
<section>
<h2>5. Alternatives considered</h2>
<ul>
<li>Alternative A — why rejected.</li>
<li>Alternative B — why rejected.</li>
</ul>
</section>
<section>
<h2>6. Constitutional notes</h2>
<p>If the plan touches anything mentioned in constitution §1–§4, note it here. If anything in §4
is being relaxed, that's a constitutional amendment — stop and use <code>update-constitution</code> first.</p>
</section>
<section>
<h2>7. Open questions</h2>
<ul><li>Should be resolved before tasks are emitted.</li></ul>
</section>
</body>
</html>
Tell the user:
spec-tasks.