用途：把 DDD 战术建模成果映射为 OpenSpec 结构化规范，衔接领域建模与工程实现，形成业务模型与代码实现的单一事实来源。使用时机为战术建模（Stage III）完成、模型验证（Stage IV）通过并准备进入开发阶段。
输入要求：必需包括问题空间定义（ddd-scope）、子域分类与核心域声明（ddd-subdomains）、上下文目录与 ADR（ddd-contexts）、上下文映射与集成模式（ddd-context-map）、聚合目录与不变量（ddd-aggregates）、领域交互定义（领域事件、领域服务、仓储接口、工厂，来自 ddd-domain-interactions）；可选为发现阶段事件流与边界线索（ddd-discover）、模型验证报告（ddd-model-review）。映射逻辑须遵循 ddd-openspec-mapping.md 标准。
主要流程：在 openspec/changes/<change-id>/ 下初始化变更集并生成 .openspec.yaml；生成 proposal.md（Why 来自 ddd-scope，What Changes 写 Capabilities 并按子域分类组织优先级，Impact 列受影响能力与聚合变更，Goals 定义成功标准）；按限界上下文在 specs/<bounded-context>/<capability>/spec.md 建立规范文件，禁止扁平 specs/domain-model/；按映射方向编写 Requirement（对应命令与领域服务，Scenario 不超过 5 个且不跨聚合根）与 Scenario（对应聚合行为与不变量，用 Given/When/Then，领域事件写入 Then/And，只描述业务规则不渗入数据库、HTTP、ORM、缓存等技术细节）；校验通用语言词汇表；撰写 design.md 整合集成模式与协作机制；按依赖顺序拆解 tasks.md 并关联 Requirement/Scenario 作为验收标准。
输出：proposal.md、design.md、按能力组织的 specs/ 目录、tasks.md。校验清单覆盖目录结构、粒度、业务规则优先、术语一致性、事件驱动范式（Outbox、幂等键、一次事务仅修改一个聚合）、迭代节奏、任务可执行性与中英文排版。
回溯触发：Scenario 出现歧义或冲突回溯 ddd-aggregates 或 ddd-domain-interactions；集成模式难以表达回溯 ddd-context-map；技术细节无法移除先重写再回溯；单 Requirement 超 5 个 Scenario 或跨聚合根回溯拆分；术语未收录回溯 ddd-contexts。
限制：本文档未提供该 Skill 的安装命令、收费与价格、支持平台及具体运行效果等信息。