用途：为现有单体系统或新系统产出可落地的微服务分解设计，而非抽象架构图。核心方法基于领域驱动设计（DDD）：先识别限界上下文，再从中推导服务边界，并给出通信模式（同步/异步、事件/RPC）、数据归属规则，以及单体拆分时的务实迁移计划。同时纳入康威定律，要求包含组织对齐章节。
必要输入：系统或领域描述、当前架构（单体/部分服务/全新）、团队结构、性能与扩展性要求、迁移约束、集成点；若拆分单体，还需代码库规模、当前最痛的改动点、耦合摩擦所在。
主要产出：领域分析（核心域与子域分类：核心/支撑/通用）、限界上下文图（ASCII，标注关系类型）、服务清单（含团队归属、技术栈、优先级）、服务间通信模式决策矩阵与事件目录、数据归属矩阵、API 契约边界、Strangler Fig 迁移计划（分阶段、依赖、成功标准、回滚方案）、组织对齐（康威定律）、风险登记册。
使用方式：作为 Claude 技能调用，按模板逐节填写；技能会先索要缺失输入。质量检查要求上下文图为 ASCII 图、每个服务有唯一团队负责人、每个数据实体有唯一归属服务、通信决策说明同步/异步理由、迁移计划含阶段与成功标准。
限制与反模式：不得在完成领域分析前定义服务边界；不得让多个团队共同拥有一个服务；不得默认全部用同步 REST；无明确理由不得一个上下文拆多个服务；未部署分布式追踪前不得开始迁移。具体收费、平台支持与安装方式暂未提供。