菜单
Write a specification covering objectives, structure, code style, testing, and boundaries before writing any code. Use when starting a new project, feature, or significant change. The spec becomes the source of truth for all implementation decisions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | spec-driven-development |
| description | Write a specification covering objectives, structure, code style, testing, and boundaries before writing any code. Use when starting a new project, feature, or significant change. The spec becomes the source of truth for all implementation decisions. |
Write the spec before the code. A spec defines what you're building, how it should behave, and where the boundaries are. Without one, you discover requirements mid-implementation — leading to rework, scope creep, and ambiguous "done" criteria.
When NOT to use: Bug fixes with clear reproduction steps, small refactors, or tasks where the spec already exists (jump to planning-and-task-breakdown).
Answer in 1-2 sentences:
OBJECTIVE: What are we building and why?
TRIGGER: What prompted this work? (issue, user feedback, tech debt)
Don't write a paragraph. If you can't state the objective concisely, use the idea-refine skill first.
Use this template. Every section is required — mark sections as "N/A" if truly not applicable, but justify why.
# Spec: [Feature Name]
## 1. Objective
[1-2 sentences. What problem does this solve and for whom?]
## 2. Background
[Context needed to understand the problem. Prior art, current behavior, why now.]
## 3. Requirements
### Functional Requirements
- FR-1: [The system shall...]
- FR-2: [The system shall...]
- FR-3: [The system shall...]
### Non-Functional Requirements
- NFR-1: [Performance: Response time < Xms for Y operation]
- NFR-2: [Security: All inputs validated, auth required]
- NFR-3: [Accessibility: WCAG 2.2 AA compliance]
## 4. Design
### Architecture
[High-level approach. Which modules/services are involved?
Include an ASCII diagram if helpful.]
### API / Interface
[Public interfaces this feature exposes or consumes.
Method signatures, REST endpoints, event payloads.]
### Data Model
[New tables, columns, or schema changes.
Include types, constraints, and relationships.]
### Key Decisions
[Architecture decisions with rationale.
Format: Decision → Rationale → Alternatives considered]
## 5. Scope
### In Scope
- [What's included]
### Out of Scope
- [What's explicitly excluded and why]
### Future Considerations
- [Things intentionally deferred — may be built later]
## 6. Testing Strategy
- Unit: [What to test at the unit level]
- Integration: [What to test across boundaries]
- E2E: [Critical user paths to verify]
- Edge cases: [Known edge cases to cover]
## 7. Rollout Plan
- Feature flag: [Yes/No — flag name]
- Migration: [Database changes, data backfill]
- Rollback: [How to undo if something goes wrong]
## 8. Open Questions
- [ ] [Unresolved question 1]
- [ ] [Unresolved question 2]
## 9. Acceptance Criteria
- [ ] [Criteria 1 — verifiable with evidence]
- [ ] [Criteria 2 — verifiable with evidence]
- [ ] [Criteria 3 — verifiable with evidence]
Before proceeding to implementation, verify:
Share the spec with stakeholders. Resolve open questions. Only then proceed to planning-and-task-breakdown.
| Feature Size | Spec Depth | Typical Length |
|---|---|---|
| Small (1-2 days) | Requirements + Acceptance Criteria are enough | 1 page |
| Medium (3-5 days) | Full spec, lighter on architecture | 2-3 pages |
| Large (1-2 weeks) | Full spec with detailed design section | 3-5 pages |
| XL (2+ weeks) | Break into smaller specs. No single spec should cover 2+ weeks of work. | Multiple docs |
| Rationalization | Reality |
|---|---|
| "I'll figure it out as I go" | Figuring it out while coding means rewriting when assumptions prove wrong. A 1-hour spec saves days of rework. |
| "The requirements are obvious" | Obvious to you. Write them down so they're obvious to everyone — including future you. |
| "Specs slow us down" | Specs front-load the thinking. The total time (spec + build) is almost always less than (build + rework + miscommunication). |
| "I'll write the spec after I build it" | That's documentation, not a spec. The spec's value is in forcing decisions before code exists. |
| "This is too small for a spec" | If it's truly small, the spec takes 15 minutes. If the spec takes longer, it wasn't small. |
After completing the spec:
Full WCAG 2.2 AA accessibility audit procedure. Goes beyond the reference checklist with step-by-step testing methodology, tooling, and remediation guidance.
Design a RESTful API from requirements. Use when creating a new API, adding endpoints, or restructuring an existing API. Produces endpoint specifications, schemas, and implementation guidance.
Assess system architecture, identify risks and bottlenecks, document decisions with ADRs. Covers modular monolith, microservices, event-driven, and serverless patterns.
Shift Left quality gates, feature flag pipelines, and deployment automation. Use when setting up or modifying build and deploy pipelines, or when establishing quality gates for a project.
Perform a thorough code review with structured feedback. Use when reviewing pull requests, code submissions, or when you want a quality check on your code. Covers correctness, security, performance, readability, and maintainability.
Reduce complexity while preserving exact behavior. Use when code works but is harder to read or maintain than it should be. Applies Chesterton's Fence — understand the code before simplifying it.