skills/cc-switch-dev-workflow/references/knowledge-base/sources/2026-03-06-spec-driven-workflow.md

Source Digest: 2026-03-06 Spec-Driven Workflow

Purpose

提炼 20260306-基于规范编程的开发模式与工作流.md 中关于 Spec 驱动开发、技能体系、CLAUDE.md、调研与任务拆分的长期规则。

When to Use

• 需要定义项目级设计哲学和 CLAUDE.md 时
• 需要解释为什么 Spec 是代码之前的单一真相源时
• 需要确定会议、调研、Spec、Code 的标准链路时

Inputs

• 20260306-基于规范编程的开发模式与工作流.md

Outputs

• 可复用规则集
• 背景性信息分层
• 与其他来源的冲突说明

Primary Agent/Model

GPT-5.4 Pro xhigh

Secondary Agent/Model

Claude Opus 4.6

Required Skills

• spec-tasking
• spec-reviewing
• ralphy-initializing

Steps

1. 提取文档中的不变原则。
2. 区分“流程规则”和“历史背景”。
3. 将能执行的规则映射到 workflow、playbook 和模板。
4. 将策略性、可变化内容转移到 ADR。

Exit Criteria

• 本文档中的规则已被至少一个正式页面复用
• 背景故事没有混入 SOP 主文

Failure Recovery

• 如果某条说法与技能规则冲突，以技能规则为准并记录到 ADR

Related Templates

• ../templates/claude-md-template.md
• ../templates/spec-template.md
• ../templates/todo-yaml-template.md

Core Conclusions

• Spec 是代码之前的单一真相源，需求变化时先改 Spec，再改代码。
• CLAUDE.md 是项目执行说明的核心文件，必须承载设计哲学、技能索引、边界和质量标准。
• 会议纪要不能原样喂给模型，必须先清洗，只保留当前项目相关决策。
• 参考仓库要经过筛选，前端优先 TypeScript 实现，且要有近年更新与足够社区信号。
• 调研、Spec 审查和人工判断占大头，代码实施只占整体时间的一部分。
• 任务标题必须自包含，至少说明 Action + Where + Reference，否则 Ralphy 循环会偏航。
• 技能不是“提示词收藏夹”，而是团队最佳实践的标准化封装，能显著提升稳定性。

Reusable Rules

• 新项目先建 .meetings/、.references/、CLAUDE.md、SPECS/，再谈实施。
• 每个项目都要有明确的设计哲学，不接受“让模型随机发挥”。
• 调研报告和 Spec 要模块化拆分，便于独立生成、独立审查、独立对齐。
• SPECS/ 使用编号和分域组织，不按写作顺序组织。
• 每实现 4 个小任务做一次重构，结束后再做一次更大的收敛。

Background Only

• 对大型团队培训 TDD/敏捷的背景讨论
• 对未来客户端形态、自我学习能力的愿景描述
• 对不同语言 skill 包数量的示例性说明

Conflict Notes

• 本文强调 CLAUDE.md 和技能驱动，但没有提供统一的 7 阶段骨架；骨架以 workflow.zip 为准。
• 本文提到的某些 skill 名称与 skills.zip 中实际命名略有差异；正式文档统一以 skills.zip 为准。

Traceability Targets

• foundations/spec-driven-development.md
• foundations/human-agent-boundaries.md
• workflows/stage-0-setup.md
• playbooks/new-project-from-scaffold.md