// 大任务的主动拆解与多 thread 并行编排。 Use when: 任务涉及 2+ 个独立可交付子任务，需要不同猫参与、不同 thread 并行推进。 Not for: 单一任务（直接做）、已有 thread 之间的被动协调（用 cross-thread-sync）、单 session 内 subagent 并行（CLI 内置能力）。 Output: 子 thread 创建 + 选猫 + 各 thread 交付 + 主 thread 汇聚报告。
AI 图片生成：原生 tool call（Codex/Antigravity）或浏览器自动化（Gemini/ChatGPT）。 Use when: 需要 AI 生成概念图、UI 参考、像素画素材、完整 PPT 页面、复杂架构图、信息图或视觉 mock。 Not for: 已有图片的展示（用 media_gallery rich block）、硬要求可编辑/native text 的 PPT/图表（用 PPT/HTML 管线）。 Output: 生成图片自动发布，或作为完整视觉 mock / 图像素材进入后续交付。
PPT 制作全链路：内容分析 → 分页规划 → 低保真 MD → imagegen 精美图。 架构猫写低保真 MD（ASCII art 结构图 + 视觉指引），imagegen 猫逐页出精美图。 Use when: 做 PPT、做演示文稿、做 slide、帮朋友做 PPT、画架构图、画技术蓝图。 Not for: 纯代码开发（用 worktree/tdd）、纯文档写作（直接写）。 Output: 低保真 MD + AI 原生精美图（raster PNG）。
处理 reviewer 反馈：Red→Green 修复 + 技术论证（禁止表演性同意）。 Use when: 收到 review 结果、reviewer 提了 P1/P2、需要处理反馈。 Not for: 发 review 请求（用 request-review）、自检（用 quality-gate）。 Output: 逐项修复确认 + reviewer 放行。
向跨家族 peer-reviewer 发送 review 请求（含五件套）。 Use when: 自检通过后准备请其他猫 review。 Not for: 收到 review 结果（用 receive-review）、自检（用 quality-gate）。 Output: Review 请求信（存档到 review-notes/）。
创建 Git worktree 隔离开发环境，含 Redis 6398 安全配置。 Use when: 开始任何代码修改、新功能开发、bug fix。 Not for: 纯文档修改（≤5 行）、不涉及代码的讨论。 Output: 隔离的 worktree + 正确的 Redis/环境配置。
铲屎官健康提醒：三猫撒娇打断 hyperfocus。 Use when: hook 触发提醒、用户输入 /hyperfocus-brake。 Not for: 正常工作流程、非铲屎官用户。 Output: 三猫温柔提醒 + typed check-in。
| name | thread-orchestration |
| description | 大任务的主动拆解与多 thread 并行编排。 Use when: 任务涉及 2+ 个独立可交付子任务，需要不同猫参与、不同 thread 并行推进。 Not for: 单一任务（直接做）、已有 thread 之间的被动协调（用 cross-thread-sync）、单 session 内 subagent 并行（CLI 内置能力）。 Output: 子 thread 创建 + 选猫 + 各 thread 交付 + 主 thread 汇聚报告。 |
| triggers | ["拆任务","分 thread","并行推进","开多个 thread","thread orchestration","任务分解"] |
核心理念：一个 thread 对应一个独立可交付的工作单元。主 thread 是指挥部，子 thread 是战场。
任务可以拆成多个独立子任务？
→ 子任务之间有代码依赖？ → 串行（先完成依赖项）
→ 子任务独立？ → 本 skill：开 thread 并行推进
只有一个任务？ → 不需要本 skill，直接做
判定标准：两个子任务能否由不同猫在不同 worktree 里同时做？能 → 独立。
拆解时明确每个子任务的：
重要：cat 不直接创建 thread。 调用 cat_cafe_propose_thread 创建一个提议卡片，等用户在 source thread 里点"批准"，后端才真正创建 thread。
→ cat_cafe_propose_thread(
title: "简洁描述任务目标",
reason: "为什么这个子任务值得自己一个 thread（必填）",
preferredCats: ["执行猫", "review猫"]
)
返回值：{ proposalId, status: "pending" } —— 不是 threadId。Thread 还未存在，不要尝试 cross_post 到一个尚未批准的 proposal。
命名规则：[优先级/批次] 动词 + 对象
提议后：继续主 thread 的工作，等用户批准。批准后用户会在新 thread 里出现，此时再 cross_post 给被分配的猫。
| 任务性质 | 适合的猫 | 理由 |
|---|---|---|
| 代码实现 | 架构猫（自己）或快速编码猫 | 产出代码 |
| 代码 Review | Maine Coon系（审查专长） | 跨家族 review |
| UI/体验/文案 | Siamese系（审美专长） | 设计视角 |
| 架构决策 | Ragdoll Opus 4.5 / Maine Coon GPT | 深度思考 |
| 确定性执行 | 狸花猫 | 零信任验证 |
铁律：同一子任务的实现和 review 不能是同一只猫（no self-review）。
用户批准 proposal 后，新 thread 出现在 sidebar。此时在新 thread 里发任务描述 + 分工提议。必须包含主 thread ID，这是子 thread 识别归属的唯一可靠来源：
→ cat_cafe_cross_post_message(
threadId: "<sub_thread_id>",
content: "## 主 Thread\nID: <main_thread_id>\n标题: <main_thread_title>\n\n## 任务描述\n...\n## 分工提议\n...\n\n⚠️ 完成后请回报主 thread，不要回报其他 thread\n@codex 请确认"
)
铁律：每个子 thread 的第一条消息必须包含 ## 主 Thread header，后续猫进入子 thread 时可据此定位汇报目标。
每个 thread 的代码改动应使用独立 worktree，避免文件冲突。
thread 内的执行遵循已有 skill：
tddquality-gaterequest-review + cross-cat-handoff（五件套）receive-review加速手段：thread 内可用 CLI 内置的 subagent 并行模式加速实现，但 review 必须由其他猫完成。
铁律：子 thread 达到里程碑时，必须立刻通知主 thread 并等待确认。
子 thread 完成开发 + 自检后，不要直接 commit，而是：
→ cat_cafe_cross_post_message(
threadId: "<main_thread_id>", ← 从第一条消息的 ## 主 Thread 获取
content: "## [子任务名] — 待确认 commit\n\n| 子项 | 状态 | 关键产出 |\n|------|------|---------|\n| ... | ✅ | 一句话 |\n\n验证：测试 X/X pass, lint 0 errors\n请确认是否 commit + push"
)
等主 thread 确认后再 commit。 主 thread 可能会要求修改后再 commit。
如果有串行依赖（B 依赖 A），主 thread 确认 A commit 后：
A 完成 → 通知主 thread → 确认 commit → A merge
↓
主 thread 通知 B → B 拉 main → B 开工
所有子 thread 完成后，主 thread 汇总：
## 编排汇总
| 子 Thread | 任务 | 状态 | PR |
|-----------|------|------|----|
| thread-xxx | ... | ✅ merged | #xx |
| thread-yyy | ... | ✅ merged | #yy |
下一步：[无 / 集成测试 / 部署]
不要让 team lead 自己去子 thread 查进度。
| 场景 | 处理 |
|---|---|
| 子任务完全独立 | 并行，各自 worktree |
| B 依赖 A 的产出 | A 先做，A merge 到 main 后 B 从 main 拉 |
| A 和 B 改同一文件 | 不要并行！串行处理，或重新拆分 scope |
| 多个 thread 都要改共享状态 | 走 cross-thread-sync 的 Claim 协议 |
拆解 → 提议 thread → 等用户批准 → 选猫(含主 Thread ID) → 并行执行 → 待 commit 通知 → 确认 → 串行触发 → 汇总
主 thread = 指挥部（拆 + 提议 + 确认 + 收）
子 thread = 战场（做 + review + 等确认）— 仅在用户批准 proposal 后存在
Proposal = 卡片（cat 提议 → 用户审核/编辑/批准 → 后端创建 thread）
第一条消息 = 必须含 ## 主 Thread（ID + 标题）
Worktree = 隔离（不冲突）
汇报 = 及时 + 等确认（不让 team lead 追，也不越权 commit）
| 错误 | 后果 | 修法 |
|---|---|---|
| 在主 thread 里直接改代码 | 子 thread 看不到过程，审计困难 | 代码改动必须在子 thread + worktree |
| 子 thread 完成不通知主 thread | team lead 要自己查 | 完成/阻塞时立刻 cross-post 回主 thread |
| 多 thread 在同一 worktree 改代码 | 文件冲突 | 每个 thread 用独立 worktree |
| 只拉同家族猫 | 缺少多元视角 | 按任务性质跨家族选猫 |
| 拆得太细（1 个小文件 = 1 个 thread） | 编排开销 > 收益 | 相关小任务合并到同一 thread |
| 忘记在子 thread 发任务描述 | 被拉的猫不知道干啥 | 建 thread 后立刻发 scope + 分工 |
| 子 thread 第一条消息没写主 Thread ID | 猫汇报到错误的 thread | 第一条消息必须含 ## 主 Thread header |
| 子 thread 完成直接 commit 不等确认 | team lead 失去控制权 | 待 commit 时通知主 thread 等确认 |
| 把 propose 返回的 proposalId 当成 threadId 用 | cross_post 到不存在的 thread | propose 不创建 thread，只有 user 批准后才有 threadId。等批准事件再发首条消息 |
| 提议一个 proposal 后立刻假设 thread 存在 | 后续操作全失败 | 必须等用户在 proposal 卡片上点"批准"。批准前继续主 thread 工作 |
| Skill | 层级 | 方向 | 核心区别 |
|---|---|---|---|
| thread-orchestration | 跨 thread | 主动拆解 → 分发 → 汇聚 | 全生命周期编排 |
| CLI subagent 并行 | session 内 | subagent 并行（CLI 内置） | 不涉及 thread、不涉及其他猫 |
cross-thread-sync | 跨 thread | 被动发现 → 通知 → 协调 | 响应式，不主动建 thread |
cross-cat-handoff | 猫对猫 | 一次性交接 | 点对点，不涉及多 thread 编排 |
worktree → tddquality-gaterequest-reviewmerge-gatecross-thread-sync