# 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/claude-md-template.md)
- [`../templates/spec-template.md`](../templates/spec-template.md)
- [`../templates/todo-yaml-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`