Ddd workflow
Skill BoltDoggy/doc-driven-development.skills/skills/ddd-workflow
文档驱动开发（DDD）工作流——当用户提出任何涉及代码变更的请求时，此技能必须立即触发。触发场景包括但不限于：'加功能'、'改代码'、'实现 X'、'新增'、'修改'、'重构'、'开发'、'修 bug'、'优化'、'升级'、'改进'、'添加'、'调整'、'写代码'等。即使请求看起来只是简单的代码修改，也必须先检查项目文档状态。技能强制'先文档后代码'原则：新功能必须经过'需求→设计→确认→实现'完整流程；Bug 修复和小改动至少需要更新相关文档；即使用户明确要求跳过流程，也必须先修复过时的文档。此外，在项目首次使用时，技能会自动初始化 DDD 文档结构（创建 docs/ 目录和 CLAUDE.md）。如果你的回答涉及生成任何代码或修改文件，请立即检查是否应触发此技能。From its SKILL.md
npx -y skills add BoltDoggy/doc-driven-development.skills --skill ddd-workflowAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.8 KB, as published. Nobody here has run it
DDD 工作流：文档驱动开发
为什么先文档后代码
每次改代码时，文档是理解"为什么这么做"的唯一持久记录。先更新文档再改代码，能确保：
- 你和 Claude 对需求的理解在动手前就对齐了
- 设计决策被明确记录下来，不会在几周后被遗忘
- 新人加入项目时有据可查
- 不会出现"代码改了但文档永远停留在半年前"的局面
核心不变的规则：任何代码变更前，必须检查并更新相关文档。区别只在于流程的详略程度。
第一步：判断项目状态
用 Bash 快速检查文件是否存在：
test -f CLAUDE.md && echo "exists" || echo "missing"
test -d docs && echo "exists" || echo "missing"
- 如果
CLAUDE.md和docs/两者都不存在 → 先执行「项目初始化」（见下文），初始化完成后按请求类型走对应模式。 - 如果 至少一个存在 → 直接按请求类型选择工作模式。
第二步：选择工作模式
判断规则
| 请求特征 | 适用模式 |
|---|---|
| 新功能、新模块、新页面、新 API、架构调整、接口变更、重大重构 | 模式 A：完整 DDD |
| Bug 修复、性能优化、小范围改动、配置调整、依赖升级 | 模式 B：轻量 DDD |
| 用户明确说"别写文档了"、"直接改"、"跳过流程"、"别废话" | 模式 C：仅同步文档 |
如果不确定，默认走模式 A。
模式 A：完整 DDD（新功能 / 架构变更）
严格按以下顺序执行，禁止跳过。
① 更新或创建需求文档
- 路径：
docs/requirements/core-features.md - 如果文件不存在，参照模板创建
- 必须回答：解决什么问题？目标用户是谁？P0/P1 功能？明确不做什么？验收标准？
- 不可在需求文档中提及编程语言、框架、库等实现细节
② 用户确认需求
- 使用
AskUserQuestion询问用户「需求文档是否已确认？」 - 用户必须明确回复"确认"或给出修改意见
- 在获得确认前，禁止进入设计阶段
③ 更新或创建设计文档
- 路径：
docs/design/下对应文档（如overall-architecture.md） - 设计必须能追溯到需求文档的对应条目
- 必须涵盖：架构、模块划分、接口定义、数据模型、错误处理、技术取舍
- 如果涉及在多个可行方案中选择，必须在
docs/adr/下创建 ADR
④ 用户确认设计
- 使用
AskUserQuestion询问用户「设计文档是否已确认？」 - 获得确认后才允许进入实现阶段
⑤ 按文档实现
- 生成代码时严格与已确认的设计保持一致
- 如果实现中发现冲突，优先更新文档（经用户确认）再同步代码
⑥ 一致性校验
- 检查代码与设计文档是否一致
- 有偏差则修复文档或代码，确保二者对齐
模式 B：轻量 DDD（Bug 修复 / 小改动 / 优化）
① 审查并更新相关文档
- 用
grep或find快速定位docs/下与被修改部分相关的文档 - 确认以下类型的过时内容并修复：
- 描述了已被修改或不再存在的功能
- 接口签名、参数、返回值已变更
- 架构图或模块描述已过时
- 验收标准不再适用
- 如果是新增简单功能（如加一个字段），在对应文档中补充记录即可，不需新建文档
② 简要告知用户
- 简要说明你更新了哪些文档、为什么
- 确认用户无异议后进入实现
- 不需要正式的
AskUserQuestion，口头确认即可
③ 实现并同步
- 按更新后的文档描述修改代码
- 完成后告知用户文档已同步
模式 C：仅同步文档（用户拒绝流程 / 极微小改动）
适用于用户明确要求跳过流程，或改动极小（如修正拼写错误、变量重命名）。
① 扫描并修复过时文档
- 检查
docs/下与本次修改相关的所有文档 - 修复不准确的内容：过时的描述、参数、返回值、示例等
- 不创建新文档章节，只修复已有内容
- 如果发现没有文档覆盖本次修改的部分，补一句简要说明即可
② 实现
- 直接实现用户的请求
- 不需要额外的文档确认步骤
项目初始化
仅在 CLAUDE.md 和 docs/ 均不存在时执行。此流程为项目建立 DDD 基础结构。
详细操作步骤见
references/initialization.md
初始化完成后，回到当前请求，选择对应的工作模式继续执行。
文档模板
详见
references/templates.md
包含以下模板：
- 需求文档：
docs/requirements/core-features.md - 设计文档：
docs/design/overall-architecture.md - ADR：
docs/adr/YYYY-MM-DD-title.md
已初始化项目的目录结构
docs/
├── requirements/
│ └── core-features.md
├── design/
│ └── overall-architecture.md
├── adr/
│ └── (按需创建)
├── api/
│ └── (按需创建)
CLAUDE.md