| name | split-task |
| description | 把一个较大的 A2C-SMCP Epic / Story / GitHub Issue（或 Jira / CNB Issue）科学拆成多个可独立交付的子任务，输出含依赖图与集成回归守护的拆分方案，并在对应平台用 sub-issue 能力下单。A2C 特有：涉及协议的拆分强制「协议先行」——协议子任务置于依赖图根，代码仓库子任务 blocked-by 它。当用户说「拆分这个任务」「把 Epic 拆成子任务」「分解 Story」「给个切刀方案」时触发。 |
| argument-hint | <GitHub Issue URL/编号 | Jira Key | CNB Issue | 设计文档路径 | 自由描述> |
Split Task — A2C-SMCP Epic/Story 科学拆分
把一个较大 Epic/Story/Issue 切成职责清晰、可独立追踪的子任务清单，并在原平台用 sub-issue 能力落地。
层级化硬约束（按 Phase 0.5 识别选用）：
- PR 边界（Epic → Story / Issue）：每子任务单独 merge 后 main 可消费（编译 / 测试 / 业务行为不破）
- Story 内分解（Story → Sub-task）：默认同上；仅在编译期/类型期耦合（Protocol/interface/type signature、Rust trait 等）必要打包时可豁免中间态破坏——PR 显式标注「Story 边界前禁单独 merge」，依赖图末端 sub-task 必须把 main 拉回可消费
软指标 + 必要打包：单 sub-task ~200 LOC 参考；逻辑边界 > 行数；运行时耦合的原子单元保留打包，宁可大不引入 Optional default / 临时兼容层等过渡债。
A2C 跨仓天性：A2C-SMCP 的 Epic 常天然跨仓（协议 + python-sdk + rust-sdk + 客户端）。拆分对象往往不是单仓，依赖图跨仓库，且受协议先行（见 Phase 0.6）与跨 SDK 一致性（见 Phase 6）两条 A2C 铁律约束。
与其他 skill 的关系
| Skill | 角色 | 衔接 |
|---|
split-task（本 skill） | 事前拆：把大 Epic/Story/Issue 切成子任务 | 输出平台原生 sub-issue 编号列表 + 跨仓依赖图 |
add-feature | 单 Story 端到端实现（含协议先行门控） | 对每个 feature 型子任务单独驱动；协议子任务必走它 |
fix-issue | 单 Issue 修复 | 对每个修复型子任务单独驱动 |
organize-github-issues | 事后归档 | 全部子任务 merge 后做最终结构梳理 |
add-feature Step 1.1 规模评估判定为大型（跨多仓/多协议线）时，应先调用 split-task 完成方法论级拆分，再回流 add-feature 驱动每个子项。
前置依赖
按拆分对象所在平台启用对应能力，启动时检查可用性，缺失则停止并提示：
| 平台 | 依赖 | 关键操作 |
|---|
| GitHub（A2C 主平台） | gh CLI（CLAUDE.md 强制用 gh，非 GitHub MCP） | gh issue view --json 读；gh issue create 建；gh api graphql 的 addSubIssue 关联原生 sub-issue |
| Jira | Atlassian MCP | getJiraIssue / createJiraIssue(issueType=Sub-task, parent=) / createIssueLink |
| CNB | CNB MCP | cnb_get_issue / cnb_create_issue（无 sub-issue API，body 标 Parent: #<n> + sub-task label） |
gh issue view 若报 projectCards 弃用错误，一律带 --json 字段查询规避。
Phase 0：输入识别
| 输入形式 | 处理 |
|---|
GitHub Issue URL / owner/repo#N | gh issue view <N> --repo <owner/repo> --json title,body,milestone,labels 拉详情；记录 owner/repo |
| Jira Key | getJiraIssue 拉详情；记录 project key |
| CNB Issue | cnb_get_issue 拉详情；记录 repo path |
| 设计文档路径 | Read 文件；AskUserQuestion 询问落地平台与父级 Issue |
| 自由描述 | AskUserQuestion 确认归属仓库、落地平台、是否已有父 Issue |
| 未提供 | 引导用户给出拆分对象 |
准出：拆分对象 scope 清晰（目标产物 / 影响模块 / 关键约束），落地平台与父 Issue 已确定。
Phase 0.5：识别拆分层级
| 拆分对象 | 子产物 | 硬约束 |
|---|
| Epic | Story / Issue | main 可消费（强） |
| Story / Issue | Sub-task | 同上；编译期/类型期耦合可豁免中间态，末端 sub-task 拉回 main 可消费 |
Phase 0.6：协议先行归属判定（A2C 铁律，强制）
判定拆分对象是否触及协议（A2C 事件/数据结构/错误码/房间模型，或 OASP 命名空间事件）：
| 结论 | 拆分含义 |
|---|
| 涉及协议 | 必须切出一个协议子任务（落 a2c-smcp-protocol 或 oasp-protocol），置于依赖图根；所有代码仓库子任务（python-sdk / rust-sdk / office4ai / 客户端）blocked-by 它。协议子任务由 /add-feature 驱动（协议评审 → 合并 → 发布），发布前禁止任何代码子任务 merge。 |
| 不涉及协议 | 纯代码拆分，按标准 main 可消费约束 |
硬门控：协议子任务的"完成"判据是协议已发布（非仅 main 可消费）。这替换了该根节点的 Phase 3 判据。参见 skills/add-feature/SKILL.md 协议先行门控。
Phase 1：改动地形勘察
目标：搞清 scope 内会动多少地——A2C 场景先定跨仓范围，再逐仓勘察。
- 跨仓范围：本次改动落哪些仓库（协议 / python-sdk / rust-sdk / office4ai / ide4ai / 客户端）
- 受影响文件清单：每仓 grep 关键符号 / 模块路径
- 模块归属：每个文件落到哪个 layer / crate
- 依赖追踪：上游 caller / 下游 callee / 跨 SDK 共享的协议数据结构
按项目类型：参见 {baseDir}/resources/<project>.md 的「模块边界识别」章节
准出：跨仓地形图清晰（受影响仓库 + 文件 + 模块 + 依赖）。
Phase 2：候选切分识别
目标：按职责轴画切刀候选。每条切刀线写明：职责描述（一句话）、范围（文件清单）、粗估 LOC、所属仓库。
A2C 切刀启发：
- 协议单独成刀：任何协议变更切成独立子任务，置根（Phase 0.6）
- 沿仓库/层切：python-sdk（agent/computer/server）、rust-sdk（crate 边界）、office4ai（OASP 双路径）各成刀
- 跨 SDK 平行切：同一协议变更的 python-sdk 与 rust-sdk 实现是平行子任务（都 blocked-by 协议）
- 沿职责切：数据结构 vs 行为新增 vs 测试守护
准出：候选切刀清单，每刀职责单一、可一句话描述、标明所属仓库。
Phase 3：切刀验证（"main 状态可消费"测试）
目标：检验每条切刀线单独 merge 后其所在 repo 的 main 是否仍可消费。决刀位的硬门槛。
协议根子任务用 Phase 0.6 判据（协议已发布）替代本表；代码子任务用下表。Story 内分解仅编译期/类型期耦合可豁免中间态破坏，末端 sub-task 必须拉回。
| 检查项 | 通过条件 |
|---|
| 编译 | 无类型错误（mypy / cargo check）、无未定义引用 |
| 测试 | 现有测试全过，新增测试对应通过 |
| 业务行为 | 关键链路不破（手测或冒烟） |
| 不引入临时债 | 无 Optional default / 临时兼容层 / 半修中间态 |
| 未超前于协议 | 代码子任务不实现尚未发布的协议语义（A2C） |
任何一项不通过 → 撤回此刀，与相邻 sub-task 合并成更大原子单元。
准出：每个保留 sub-task 通过其 repo 的 main 可消费验证。
Phase 4：三轴平衡评估
| 轴 | 评估问题 |
|---|
| 可观察性 | 该 sub-task 自带验证手段？验证范围与改动匹配？ |
| 可维护性 | 改动单一模块/crate？依赖明确？ |
| 独立性 | 能与其他 sub-task 并行开发？是否需串行？ |
低分项需说明理由（如协议→SDK 的串行顺序）或调整切刀。
Phase 5：依赖图绘制（A2C 跨仓）
ASCII 画出 blocks / blocked-by，协议子任务在根，跨 SDK 实现平行：
[协议] a2c-smcp-protocol 事件新增 ──┬──→ [python-sdk] computer 实现 ─┐
(add-feature 发布后解锁) └──→ [rust-sdk] smcp-computer 实现 ┼─→ [集成] 跨 SDK 序列化兼容守护
[客户端] tfrobot-client 适配 ─┘
标注每个 sub-task 所属仓库、可否并行 ship、关键路径长度。准出：跨仓依赖图 + 并行路径已明确。
Phase 6：集成测试 sub-task 设计（依赖图末端）
目标：纯测试子任务，零生产风险，守护任何单 sub-task 都无法独立守护的跨边界能力回归。放依赖图末端、单独成刀、不混功能改动。
A2C 必守不变量（与项目专属清单叠加）：
- 跨 SDK 序列化兼容：python-sdk 与 rust-sdk 对同一协议结构的序列化/反序列化互通（跨语言 round-trip）
- 协议 conformance：实现严格符合已发布协议规范（事件名/字段/错误码）
按项目类型：参见 {baseDir}/resources/<project>.md 的「关键架构能力守护清单」章节
覆盖完整性核验（必勾，与 Phase 3 并列硬门槛）
任何一项未勾 → 末端 sub-task 范围必须扩，或回 Phase 2 重新切。
准出：集成测试 sub-task 验收清单已列出，覆盖完整性核验全勾。
Phase 7：用户确认 + 平台落地 sub-issue
7.1 输出最终拆分方案
## 拆分方案
### 拆分理念 [为什么这么切，含"为什么不再细拆 X"]
### Sub-task 清单
#### 1. [仓库] 标题
- 目标 / 范围（文件清单）/ 预估 LOC / 测试 / 依赖(blocked-by、blocks) / 可独立 ship / 验收
### 依赖图 [ASCII]
### 总 LOC 估算 [符合软指标 / 承认必要打包]
AskUserQuestion 确认方案，用户可逐项调整。未确认前不在任何平台创建子项。
7.2 按平台原生 sub-issue 能力下单
| 平台 | 落地步骤 |
|---|
| GitHub 同仓子项 | 1) gh issue create --repo <owner/repo> --title ... --body ...；2) 取父子 node id：gh issue view <n> --json id；3) gh api graphql -f query='mutation($p:ID!,$c:ID!){addSubIssue(input:{issueId:$p,subIssueId:$c}){clientMutationId}}' -f p=<父id> -f c=<子id> 关联原生 sub-issue |
| GitHub 跨仓子项（A2C Epic 跨仓） | 原生 sub-issue 跨仓支持有限——用 Milestone 归集 + 子 Issue body 写 Part of <owner/repo>#<父号> + 父 Issue 追加 ## Sub-tasks 任务清单反向索引（与 add-feature Step 1.3 父子检测方式对齐） |
| Jira | createJiraIssue(issueType=Sub-task, parent=<父 Key>)；createIssueLink 补 blocks 关系 |
| CNB | cnb_create_issue(body 顶写 Parent: #<父号>) + cnb_set_issue_labels 加 sub-task + 父 Issue 追加任务清单 |
完成后输出子项编号列表 + 跨仓依赖图，供 add-feature / fix-issue 接力。
关键决策点（必须与用户对齐）
| 决策点 | Phase | 问题 |
|---|
| 输入 scope | 0 | 拆分对象与落地平台是否确定？ |
| 协议先行 | 0.6 | 是否涉及协议？协议子任务是否置根？ |
| 拆分层级 | 0.5 | 拆 Story 还是 Sub-task？适用哪套硬约束？ |
| main 可消费 | 3 | 哪些刀必须撤回打包？ |
| 拆分方案 | 7 | 最终 sub-task 清单是否可下单？ |
反模式
| 反模式 | 正确做法 |
|---|
| 涉及协议却不置协议子任务于根 | Phase 0.6 强制协议先行，协议子任务在依赖图根 |
| 代码子任务超前实现未发布协议 | 代码 blocked-by 协议发布，Phase 3 明确禁超前 |
| python-sdk 改了 rust-sdk 不同步 | 跨 SDK 平行子任务 + 末端跨 SDK 序列化兼容守护 |
| 凭行数硬切，破 main | 用「main 可消费」硬约束验证每刀 |
| Sub-task 层硬套「main 可消费」过度打包 | Phase 0.5 层级化约束 + Story 边界守护 |
| 为达小 PR 引入 Optional default / 兼容层 | 承认必要打包，宁可大不引入过渡债 |
| 漏集成回归 | 末端单独留集成测试 sub-task |
| 用 GitHub MCP 建子项 | 按 CLAUDE.md 用 gh CLI + gh api graphql addSubIssue |
| 跳过用户确认直接建子项 | 方案确认后才下单 |
