spec-flow
Spec-driven development workflow. Interactive phase-by-phase confirmation from proposal to implementation. Trigger: 'spec-flow', 'spec mode', 'need a plan', 'structured development', 'write a spec', 'feature spec', 'technical spec', '需求文档', '技术方案', '任务拆解', '规格驱动', '写个方案', '做个规划', '结构化开发', 'plan this feature', 'break this down', 'design doc'. Creates .spec-flow/ directory with proposal, requirements, design, and tasks.
git clone https://github.com/echoVic/spec-flow
git clone --depth=1 https://github.com/echoVic/spec-flow ~/.claude/skills/echovic-spec-flow-spec-flow
SKILL.mdSpec-Flow - Structured Development Workflow
Structured workflow for complex feature development. Creates living documentation that guides implementation and serves as team reference.
Core Principles
- One phase at a time — NEVER generate documents for subsequent phases in advance
- Mandatory confirmation — After each phase, STOP and wait for user confirmation
- User-driven progression — Only proceed when user says "continue"/"ok"/"next"/"继续"/"好"
Parameters
| 参数 | 说明 |
|---|---|
| 跳过逐阶段确认,一次性生成所有文档(最后整体确认) |
| 跳过 Design 阶段(简单功能,架构显而易见时) |
Language Rule
所有生成的 .md 文件必须使用中文。
Interaction Rules
Load
references/interaction-rules.md for detailed confirmation templates and prohibited behaviors.
Five-Phase Workflow
Copy this checklist and check off items as you complete them:
Spec-Flow Progress:
-
Phase 0: Initialize ⚠️ REQUIRED
- 0.1 Run
or createscripts/init-spec-flow.sh <feature-name>.spec-flow/active/<feature>/ - 0.2 Check if
exists — if so, read for project context.spec-flow/steering/ - 0.3 问自己:这个功能的核心价值是什么?用一句话能说清吗?
- 0.1 Run
-
Phase 1: Proposal ⚠️ REQUIRED
- 1.1 Create
using.spec-flow/active/<feature>/proposal.mdtemplates/proposal.md.template - 1.2 包含:Background, Goals, Non-Goals, Scope, Risks, Open Questions
- 1.3 问自己:有没有隐含的需求没写出来?
- 1.4 问自己:Non-Goals 是否足够明确?能防止 scope creep 吗?
- 1.5 ⏸️ 确认节点 — 等待用户确认后继续
- 1.1 Create
-
Phase 2: Requirements
- 2.1 Create
using.spec-flow/active/<feature>/requirements.mdtemplates/requirements.md.template - 2.2 Load
— 使用 EARS 格式编写需求references/ears-format.md - 2.3 包含:FR-xxx 功能需求, NFR-xxx 非功能需求, AC-xxx 验收标准
- 2.4 问自己:每条需求都是可测试的吗?
- 2.5 问自己:边界情况覆盖了吗?错误场景呢?
- 2.6 ⏸️ 确认节点 — 等待用户确认后继续
- 2.1 Create
-
Phase 3: Design(除非
)--skip-design- 3.1 Create
using.spec-flow/active/<feature>/design.mdtemplates/design.md.template - 3.2 包含:Architecture (Mermaid), Components, API, Data Model, Error Handling
- 3.3 问自己:这个设计能满足所有 requirements 吗?逐条对照
- 3.4 问自己:有没有更简单的方案?过度设计了吗?
- 3.5 ⏸️ 确认节点 — 等待用户确认后继续
- 3.1 Create
-
Phase 4: Tasks
- 4.1 Create
using.spec-flow/active/<feature>/tasks.mdtemplates/tasks.md.template - 4.2 Load
— 遵循任务拆解规范references/task-decomposition.md - 4.3 每个任务:1-2 tool calls 可完成,标注复杂度 Low/Medium/High
- 4.4 分组:Setup → Implementation → Testing → Documentation
- 4.5 问自己:任务之间的依赖关系对吗?有没有可以并行的?
- 4.6 ⏸️ 确认节点 — 等待用户确认后继续
- 4.1 Create
-
Phase 5: Implementation
- 5.1 Load
— 确认执行模式references/execution-modes.md - 5.2 默认 Step Mode(逐任务确认),用户可切换 Batch/Phase Mode
- 5.3 每个任务执行前:读 tasks.md → 检查依赖 → 读 design.md
- 5.4 每个任务执行后:更新 tasks.md 状态(
→- [ ]
)- [x] - 5.5 全部完成后:归档到
.spec-flow/archive/
- 5.1 Load
Directory Structure
.spec-flow/ ├── steering/ # 全局项目上下文(可选) │ ├── constitution.md │ ├── product.md │ ├── tech.md │ └── structure.md ├── active/ # 进行中 │ └── <feature>/ │ ├── proposal.md │ ├── requirements.md │ ├── design.md │ └── tasks.md └── archive/ # 已完成
Steering Documents (Optional)
| Document | Purpose | Template |
|---|---|---|
| 项目治理原则 | |
| 产品愿景、目标用户 | |
| 技术栈、约束 | |
| 代码组织、命名规范 | |
Phase Transitions
| From | To | Condition |
|---|---|---|
| Proposal | Requirements | Proposal approved, questions resolved |
| Requirements | Design | Requirements complete, testable |
| Requirements | Tasks | , simple feature |
| Design | Tasks | Design approved |
| Tasks | Implementation | Tasks confirmed |
| Implementation | Done | All tasks complete → archive |
Compatibility
Works with any AI agent that supports Skills format: Claude Code, Blade, OpenClaw, Cursor, Windsurf, etc.