# Zc Spec Driven Development

> 规格驱动开发

- Skill: `zmice/zc-spec-driven-development` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zmice/zc-spec-driven-development`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zmice/zc-spec-driven-development/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zmice (https://skillmd.com/u/zmice)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zmice/zc-spec-driven-development

---


# 规格驱动开发

## 何时使用

- 启动新项目或新功能
- 需求不完整、存在歧义或只有模糊想法
- 变更会影响多个文件、模块或接口边界
- 需要先把“完成标准”说清楚再进入实现

不适用于单行修复、拼写修改或完全自包含的小改动。

## 输入前提

- 已知道当前要解决的大致问题
- 愿意先澄清假设，而不是边写边猜
- 接受规格会成为后续计划、实现和审查的共同事实来源

## 执行步骤

1. 先列出假设，显式暴露你准备默认成立的前提
2. 把模糊需求重写成具体、可验证的成功标准
3. 编写结构化规格，至少覆盖：
   - Objective
   - Commands
   - Project Structure
   - Code Style
   - Testing Strategy
   - Boundaries
4. 标记开放问题和风险点；低风险且可验证、可回退的假设写明验证路径后继续
5. 只有问题会改变架构路线、外部契约、数据或安全边界、不可逆操作，或与用户目标冲突时等待人类确认；规格可执行后进入 `planning-and-task-breakdown`

## 成功标准

- 规格能清楚回答“做什么、为什么做、怎么判定完成”
- 假设和边界是显式的，而不是藏在正文里
- 成功标准是可测试的，不是感受性描述
- 人类可以基于规格明确批准或驳回高风险路线；低风险任务无需形式化确认也能安全推进

## 相关原则

- 先澄清假设，再写规格
- 规格先于实现，不接受“先写后补”
- 范围边界必须写出来，不能靠默契

## 与其他技能的衔接

- 与 `engineering-principles` 配合，约束规格阶段的工作方式
- 规格确认后交给 `planning-and-task-breakdown`
- 实现阶段由 `incremental-implementation` 和 `test-driven-development` 消费规格