菜单
Use when starting a new feature, when requirements are unclear, when asked to write code without a clear spec, or before any non-trivial implementation. Do NOT use for trivial bug fixes or one-line changes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | spec-driven-development |
| description | Use when starting a new feature, when requirements are unclear, when asked to write code without a clear spec, or before any non-trivial implementation. Do NOT use for trivial bug fixes or one-line changes. |
gh issue create with label idea and present the issue URL to the user for approval.Problem Statement — from the user's perspective.
Solution — from the user's perspective. What changes, what stays the same.
User Stories — "As a <actor>, I want <feature>, so that <benefit>." Long numbered list.
Implementation Decisions — describe decisions, not implementation. No file paths or code snippets:
Testing Decisions — what makes a good test (external behaviour only), which modules will be tested, prior art in the codebase.
Out of Scope — explicitly excluded items.
| Rationalization | Reality |
|---|---|
| "This is simple, I don't need a spec" | Simple tasks need short specs, not no specs. A three-line spec with acceptance criteria is fine. |
| "I'll write the spec after I code it" | That's documentation, not specification. The spec's value is forcing clarity before code. |
| "The user already told me what to do" | Users describe symptoms, not solutions. A spec exposes gaps and contradictions. |
| "Writing a spec is too slow" | The time saved in prevented rework dwarfs the spec-writing time. Measured. |
Use when you have a spec or PRD that needs decomposing into small, verifiable implementation tasks. Use before any build cycle to ensure tasks are thin vertical slices with clear acceptance criteria.
Use when reviewing codebase architecture for refactoring opportunities, surfacing shallow modules, or proposing deepening refactors. Identifies architectural friction and produces GitHub issues with the ops-triage labeling scheme. Supports interactive (human approval) and auto (CI/headless) modes — auto mode files every surviving candidate directly and writes a step-summary report.
Use when reviewing a pull request or code change before merge. Use for the five-axis evaluation (correctness, readability, architecture, security, performance), exposure × impact severity classification, AC coverage verification, and the `## Automated review` comment. Use in both human and CI mode — the methodology is identical; only the inputs and agent invocation differ.
Use when working in a Next.js 15 App Router project — editing app/, src/app/, components/, server actions, or route handlers. Enforces project conventions for queries, mutations, and data fetching.
Use when editing *.ts or *.tsx files in this project. Enforces TypeScript conventions including Zod-derived types, Prisma type patterns, type-only imports, and shared constant extraction.
Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyse network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be configured.