易组织起来。

于是就有了 cleanddd-skills。

cleanddd-skills 包含哪些内容

cleanddd-skills 主体由四个部分组成：

• cleanddd-requirements-analysis
• cleanddd-modeling
• cleanddd-dotnet-init
• cleanddd-dotnet-coding

这四个部分分别处理四类事情：

• requirements-analysis 负责把需求整理成结构化描述。
• modeling 负责把结构化需求描述转换成系统模型结构。
• dotnet-init 负责在需要时，根据模型结果初始化新的工程骨架。
• dotnet-coding 负责在需求、模型和工程结构已经明确的基础上继续完成实现。

如果是新工程，通常会按完整链路使用：

requirements-analysis -> modeling -> dotnet-init -> dotnet-coding

如果已经有工程，可以直接使用：

requirements-analysis -> modeling -> dotnet-coding

cleanddd-skills 的重点，不在于把四个 skill 摆在那里，而在于把实践 CleanDDD 的过程组织成一条前后连续的流程。

requirements-analysis

cleanddd-requirements-analysis 只处理需求本身，不进入建模，也不进入代码。

这一部分的任务，是把原始需求整理成后面能继续使用的结构化描述。通常会涉及这些内容：

• 干系人是谁
• 业务对象有哪些
• 每条需求归属于哪个对象
• 哪些是动作，哪些是状态，哪些是约束
• 哪些触发会引出后续行为
• 哪些依赖关系是显性的，哪些关系藏在描述背后

这一部分体现的 CleanDDD 实践重点很明确：先用业务语言把问题说明白，再进入模型语言。

如果需求阶段还是散乱的自然语言，后面的建模就很容易依赖临时理解。
而 requirements-analysis 做的，就是把这些输入先整理成适合建模的形式。

这一部分的产出，不是为了写一份好看的文档，而是为了给 modeling 提供明确输入。

modeling

cleanddd-modeling 接在 requirements-analysis 后面，负责把结构化需求描述继续转换成系统模型结构。

这一部分通常会整理出：

• 聚合
• 命令
• 事件
• 查询
• API Endpoint
• 定时任务

这一部分的工作重点，不是解释术语，而是确定结构和归属。

哪些行为进入哪个聚合。
哪些变化表达为命令。
哪些变化表达为事件。
哪些操作只是查询。
哪些能力通过 Endpoint 对外暴露。
哪些行为适合异步或周期性处理。

这一部分体现的 CleanDDD 实践重点主要包括：

• 先确定边界，再进入实现
• 命令、事件、查询各有各的位置
• 模型作为需求和实现之间的中间结构
• 规则尽量由对应模型负责

如果没有 modeling 这一层，需求很容易直接进入代码，系统后面会越来越像流程拼装。
有了这一步，后续工程结构和代码实现就有了清楚依据。

dotnet-init

cleanddd-dotnet-init 是可选步骤，用于新工程初始化。

如果准备从零开始创建一个新的 .NET / NetCorePal 工程，这一步就会使用。
如果工程已经存在，这一步可以跳过，直接进入 cleanddd-dotnet-coding。

这一部分处理的内容，重点不是普通意义上的“起项目”，而是根据前面的模型结果初始化工程骨架。通常会包括：

• 使用 NetCorePal Template 初始化项目
• 确定解决方案和工程结构
• 确定基础技术选项
• 为后续聚合、命令、事件、查询、Endpoint 等实现准备对应位置

这一部分体现的 CleanDDD 实践重点是：模型不只停留在描述里，还要继续进入工程结构。

NetCorePal 在这里承担的是承载角色。
前面的 requirements-analysis 和 modeling 更偏分析和设计，到了 dotnet-init，NetCorePal 开始把这些结果带到实际工程里。

如果是新项目，这一步很自然；如果是已有项目，就不需要额外做一次初始化。

dotnet-coding

cleanddd-dotnet-coding 进入的是实现阶段。

这一部分不是单纯“写代码”，而是根据前面的需求结果、模型结果以及现有工程结构，继续完成实际实现。通常会覆盖：

• 聚合实现
• 命令处理
• 查询处理
• 领域事件
• API Endpoint
• 仓储
• 配置
• 测试

这一部分体现的 CleanDDD 实践重点，是让实现继续保持和需求、模型、工程结构的一致性。

也就是说，这里写的不是一段孤立代码，而是：

• 对应前面的需求整理结果
• 对应前面的模型结构
• 对应现有工程骨架
• 对应 NetCorePal 的实现方式

如果是已有工程，在 requirements-analysis 和 modeling 完成之后，可以直接进入 dotnet-coding。
如果是新工程，dotnet-coding 则接在 dotnet-init 后面继续往下实现。

如何使用

cleanddd-skills 的安装和使用说明，项目 README 里已经写得很清楚：

https://github.com/netcorepal/cleanddd-skills/blob/main/README.md

README 给出的使用步骤如下。

先克隆代码到本地：

git clone https://github.com/netcorepal/cleanddd-skills.git
cd cleanddd-skills

然后运行安装脚本，将 skills 同步到当前用户的全局目录。

Windows PowerShell：

./scripts/install-skills.ps1

macOS/Linux：

chmod +x scripts/install-skills.sh
./scripts/install-skills.sh

安装完成之后，就可以和 Agent 对话，并按顺序使用这些 skills：

• 需求拆解：调用 cleanddd-requirements-analysis，生成结构化需求与事件流
• 领域建模：调用 cleanddd-modeling，基于上一步输出生成聚合、命令、查询、事件、Endpoint 设计
• 项目初始化：调用 cleanddd-dotnet-init，用模板创建项目骨架
• 代码实现：调用 cleanddd-dotnet-coding，基于模型生成代码骨架或具体实现

README 里还给了几句可以直接发给 Agent 的示例提示词：

• “请先用 cleanddd-requirements-analysis 拆解 XXX 需求，给出表格化输出，然后用 cleanddd-modeling 生成模型设计。”
• “使用 cleanddd-dotnet-init 创建一个包含 RabbitMQ 和 MySql 的 CleanDDD 项目。”
• “基于上述模型，实现代码骨架。”

脚本会将仓库内 skills/ 目录下的技能逐个同步到目标目录，如果已有同名技能，会先删除后再复制，以保证版本一致。

cleanddd-skills 和 NetCorePal 的关系