一键在 Manus 中运行任何 Skill

orchestration-playbook

星标4

分支0

更新时间2026年4月24日 23:04

MCC 主动性手册：Claude 遇任务时查'该派什么 agent / 激活什么 skill / 该不该并行'。触发：Claude 自己看到一个新任务但不确定是该硬干、该派 agent、该激活 skill、还是该并行——立即激活本 skill 查 playbook。与 help 分工：help 是用户导航（用户问'我在哪'激活）；本 skill 是 Claude 编排参考（Claude 自己查'该派什么'激活）。

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

18811184907

18811184907/mcc

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Orchestration Playbook · Claude 编排手册

MCC 的执行哲学落地到具体选择。不对用户可见——这是 Claude 自己接手任务时查的 playbook：

"该派 agent 还是硬干？" → 查 A 节
"该激活哪个 skill？" → 查 B 节
"该不该并行？怎么并行？" → 查 C 节
"任务多大才启动完整流程？" → 查 D 节

A · 意图 → Agent 派发速查 {#a}

遇到用户意图或场景关键词，主动委派下列 agent（不要等用户说"帮我派"）：

用户意图 / 场景关键词	派的 agent	备注
修 bug / 排查 / 性能慢 / 报错	`debugger`	`/fix-bug` 的 Phase 2 主 agent
新功能规划 / 设计 API / 拆解大任务	`planner`	`/plan` 的主 agent
写完 >50 行改动	`code-reviewer`（+ `security-reviewer` 并行）	不等用户说 review
安全敏感代码（auth / 加密 / 用户输入 / DB 查询）	`security-reviewer`	即使没问
扫代码里的静默失败 / 吞掉的异常	`silent-failure-hunter`	code-reviewer 通过后补一刀
慢 / 延迟高 / bundle 大 / Core Web Vitals	`performance-engineer`	主动，不等
DB 查询慢 / N+1 / schema 设计	`database-optimizer`
架构决策 / 服务边界 / 技术栈选型	`backend-architect`
LLM / RAG / Agent 编排	`ai-engineer`
Prompt 优化	`prompt-engineer`
向量 DB / embedding	`vector-database-engineer`
React / Next.js / 前端 UI	`frontend-developer`
FastAPI 高性能	`fastapi-pro`
Python 实现	`python-pro`
TS 类型系统 / 泛型 / decorator	`typescript-pro`
JS 异步 / Promise / event loop	`javascript-pro`
补测试到 80% 覆盖	`test-automator`
死代码 / 重复 / 重构清理	`refactor-cleaner`
在写代码前扫现有模式	`code-explorer`	只读探索

B · 场景 → Skill 激活速查 {#b}

遇到下列关键词 / 场景，主动激活对应 skill（不等用户说"帮我用 xxx skill"）：

场景	Skill
开工前心里没底 / "我真的要这么做吗"	`confidence-check`（5 维度 ≥90% 才动手）
要写新 feature / 修 bug	`tdd-workflow`（先写失败测试）
交付前 / 合并前 / "验证一下"	`verification-loop`（6 阶段 gate）
做架构决策 / 技术选型落盘	`architecture-decision-records`（产出 ADR）
方向分歧 / 两方案选不出	`party-mode`（并行 4 视角辩论）
审代码 / 收 review 反馈	`code-review-workflow`（两端）
修完 bug / 完成 refactor 后	`continuous-learning-v2`（沉淀 learned skill）
用户说"建个 skill / 提炼约定"	`writing-skills`
多独立问题并行处理	`dispatching-parallel-agents`
写 E2E 测试 / Playwright	`e2e-testing`
开始新 feature 需隔离开发	`using-git-worktrees`
分支做完要合入	`finishing-a-development-branch`
执行已有 plan 的 task 链	`subagent-driven-development`
写代码前做产品验证	`product-lens`
用户问"我在哪 / 下一步"	`help`（纯用户导航）
用户说"我刚 clone / 不熟这个项目 / 怎么接手 / 从哪开始"（已有项目）	`/onboard` 命令 + `project-onboarding` skill（4 阶段深度接手）
大项目（>1k 文件）反复操作想省 token	`/index-repo` 命令（PROJECT_INDEX，2K 投入省 50K/session）
全新空项目 / 想要轻量 CLAUDE.md	`/init` 命令（轻量模式，已有项目会建议改用 /onboard）
涉及证据驱动	`confidence-check` skill（5 维度评估）
涉及 SOLID / 代码风格	`coding-standards` skill（Python + TS 带示例）
涉及架构取舍 / 可逆性	`architecture-decision-records` skill（产出 ADR）
涉及风险管理	`planner` agent 的 Risks & Mitigations 段 + `security-reviewer` agent
写/改代码时想找规范示例	`coding-standards`（Python + TS 示例）

C · 并行决策（Q1-Q4） {#c}

每次接手任务第 1 秒自问：

Q1 能拆 2+ 独立子任务？ → fan-out 并行（同一条 message 多个 Task call）
Q2 多视角给不同答案？ → party-mode 辩论
Q3 有时序依赖？ → 接力（A→B→C，每步主 session 整合）
Q4 任务很小？ → 直接做，不派 agent

3 种最常用并行组合（熟记）：

代码审查 → code-reviewer + security-reviewer 并行（大改动加 silent-failure-hunter + performance-engineer）
Bug 盲诊 → debugger + performance-engineer 并行（涉数据加 database-optimizer）
架构规划 → planner + 栈相关 domain agent 并行（后端 / 前端 / AI 按栈选）

完整 10+ 场景组合 + 4 种协作模式 + 合流 4 动作 + 成本控制 → dispatching-parallel-agents skill。

D · 任务规模 → 流程深度 {#d}

小改动（<30 行 / typo / 文案）：直接做，不启流程。别 confidence-check、别 TDD、别 review——否则"一件小事连串调 skill"。
中等单元（一组件 / 一 endpoint / 一算法）：TDD + review 就够（tdd-workflow → 实现 → code-review-workflow）。
较大单元（完整页面 / 子系统 / PR 改 10+ 文件）：完整流程：confidence-check → /plan → /implement（带 subagent-driven-development）→ /review → verification-loop → /pr。

并行派发必须可视化（v1.9 新增 · 让用户看到真并行）

每次并行派 2+ agent 时，assistant message 必须输出以下可视化格式，然后紧跟 Task tool call：

派发前：

⚡ 并行派发 N agent（fan-out / 预计 ~X min）
   ├─ agent1  用途一句话
   ├─ agent2  用途一句话
   └─ agent3  用途一句话

返回后合流：

✓ N agent 全部返回（耗时 X.X min）
   ├─ agent1  X.X min → N findings
   └─ ...

合流整合：
  CRITICAL (n): ...
  HIGH (n): ...

完整模板 + 理由见 dispatching-parallel-agents skill 的"派发可视化模板"章节。

禁止：不说就派（用户看不到并行证据，怀疑"你是不是只派了 1 个"）。

禁止

❌ 等用户敲 slash 命令才激活能力（用户不知道你有什么）
❌ 一件小事连串调 skill（改 typo 不要先 confidence-check）
❌ 忽略 agent 直接在会话里硬写（上下文污染，丢失 subagent 隔离优势）
❌ 多 agent 并行时把某 agent 的 full report 直接贴给用户（主 session 做摘要）
❌ 并行派发不加可视化文本（见上节）

底线

MCC 的执行哲学：用户少敲，Claude 多主动。本 playbook 是这个哲学的具体落地手册，遇不确定时查它。

同仓库更多 Skills

同仓库

codex-audit

18811184907/mcc

Claude 用 codex CLI 做差异化对抗审查 + Layer 2 二审 + auto-fix 全链路。**v2.8.0 起流式 streaming**：codex 思考过程实时事件流（onEvent 回调每个 thread.started / item.completed / turn.completed），idle-timeout（90s 没新事件才算卡死）替代固定 totalTimeout。runCodexAudit 是 async，要 await。三层架构：Layer 1 codex (OpenAI) 流式产 finding → Layer 2 finding-validator subagent (Claude fresh) 独立复现 → Layer 3 通过自动 Edit 修不询问用户。触发：/plan 完成 / /implement 大改动 / /review 3 路并行 / /pr 4 路 PR 预检。codex 是不同模型 = 不同盲区，跟 Claude 互补不替代。**全自动 — 用户从不需要手动管 codex**。

2026-04-304

user-vault

18811184907/mcc

Claude 自动接管用户级跨项目敏感配置（personal API key / 个人 PAT / git 全局身份 / 跨项目 SSH host）。触发：用户提到跨项目通用 secret、或 project-vault 检测到条目应提升到用户级、或用户问'跨项目共用 secret 放哪'。写 ~/.claude/USER_VAULT.md，hook 自动 sync 到 .user-env.{sh,ps1} + git --global + ~/.ssh/config。与 project-vault 分工：本 skill 跨项目，project-vault 单项目。

2026-04-294

claudemd-sync

18811184907/mcc

Claude 主动沉淀用户跨项目偏好到 ~/.claude/CLAUDE.md，post-hook 自动 commit+push 到 dotfiles repo 跨设备同步。触发：用户说'记下这个偏好 / 沉淀到 CLAUDE.md / 把这个习惯加进去'、用户连续多次重复同样反馈（'又忘了'）、或做了跨项目通用决策（'以后所有项目都用 zod'）。仅追加不覆盖。与 continuous-learning-v2 分工：本 skill 主动显式沉淀偏好，learning-v2 被动观察行为。

2026-04-294

database-schema-doc

18811184907/mcc

Claude 自动维护 docs/SCHEMA.md。触发：用户提到表结构（'加 users 表，字段 email/password'）、写改 ORM 模型（Prisma/SQLAlchemy/TypeORM）、写改 migration SQL、或问'数据库表结构在哪'。不存在自动建（从 ORM 抽骨架），存在直接 Edit 加表/字段；业务含义缺失填 '_TODO_' 占位。与 architecture-decision-records 分工：本 skill 记结构现状，ADR 记选型决策（如选 Postgres）。

2026-04-294

dev-changelog

18811184907/mcc

Claude 自动维护开发实时流水日志 docs/CHANGELOG-DEV.md，记**正在发生**的需求/进度/坑/下一步。触发：用户讲新需求或改主意（◇）、Claude 完成 ≥30 行或跨文件改动（✓）、遇 blocker（⚠）、决定下一步（→）。与 git log（已落盘代码）/ ADR（终态决策）/ SCHEMA（结构）/ mistakes（bug 根因）分工——本 skill 记进行中状态。每条 ≤5 行倒序。

2026-04-294

project-vault

18811184907/mcc

Claude 自动接管项目级敏感配置（API key / DB 密码 / 部署 IP / SSH / token）。触发：用户在对话里说出任何 secret 或 IP、或代码里硬编 secret、或问 '.env 怎么放 / token 存哪'。写 .claude/PROJECT_VAULT.md，hook 自动 sync 到 .env.local + .env.example + ~/.ssh/config + SECRETS-INDEX.md，强制 .gitignore。与 user-vault 分工：本 skill 单项目，跨项目用 user-vault。

2026-04-294

name

orchestration-playbook

description

Orchestration Playbook · Claude 编排手册

MCC 的执行哲学落地到具体选择。不对用户可见——这是 Claude 自己接手任务时查的 playbook：

"该派 agent 还是硬干？" → 查 A 节
"该激活哪个 skill？" → 查 B 节
"该不该并行？怎么并行？" → 查 C 节
"任务多大才启动完整流程？" → 查 D 节

A · 意图 → Agent 派发速查 {#a}

遇到用户意图或场景关键词，主动委派下列 agent（不要等用户说"帮我派"）：

用户意图 / 场景关键词	派的 agent	备注
修 bug / 排查 / 性能慢 / 报错	`debugger`	`/fix-bug` 的 Phase 2 主 agent
新功能规划 / 设计 API / 拆解大任务	`planner`	`/plan` 的主 agent
写完 >50 行改动	`code-reviewer`（+ `security-reviewer` 并行）	不等用户说 review
安全敏感代码（auth / 加密 / 用户输入 / DB 查询）	`security-reviewer`	即使没问
扫代码里的静默失败 / 吞掉的异常	`silent-failure-hunter`	code-reviewer 通过后补一刀
慢 / 延迟高 / bundle 大 / Core Web Vitals	`performance-engineer`	主动，不等
DB 查询慢 / N+1 / schema 设计	`database-optimizer`
架构决策 / 服务边界 / 技术栈选型	`backend-architect`
LLM / RAG / Agent 编排	`ai-engineer`
Prompt 优化	`prompt-engineer`
向量 DB / embedding	`vector-database-engineer`
React / Next.js / 前端 UI	`frontend-developer`
FastAPI 高性能	`fastapi-pro`
Python 实现	`python-pro`
TS 类型系统 / 泛型 / decorator	`typescript-pro`
JS 异步 / Promise / event loop	`javascript-pro`
补测试到 80% 覆盖	`test-automator`
死代码 / 重复 / 重构清理	`refactor-cleaner`
在写代码前扫现有模式	`code-explorer`	只读探索

B · 场景 → Skill 激活速查 {#b}

遇到下列关键词 / 场景，主动激活对应 skill（不等用户说"帮我用 xxx skill"）：

场景	Skill
开工前心里没底 / "我真的要这么做吗"	`confidence-check`（5 维度 ≥90% 才动手）
要写新 feature / 修 bug	`tdd-workflow`（先写失败测试）
交付前 / 合并前 / "验证一下"	`verification-loop`（6 阶段 gate）
做架构决策 / 技术选型落盘	`architecture-decision-records`（产出 ADR）
方向分歧 / 两方案选不出	`party-mode`（并行 4 视角辩论）
审代码 / 收 review 反馈	`code-review-workflow`（两端）
修完 bug / 完成 refactor 后	`continuous-learning-v2`（沉淀 learned skill）
用户说"建个 skill / 提炼约定"	`writing-skills`
多独立问题并行处理	`dispatching-parallel-agents`
写 E2E 测试 / Playwright	`e2e-testing`
开始新 feature 需隔离开发	`using-git-worktrees`
分支做完要合入	`finishing-a-development-branch`
执行已有 plan 的 task 链	`subagent-driven-development`
写代码前做产品验证	`product-lens`
用户问"我在哪 / 下一步"	`help`（纯用户导航）
用户说"我刚 clone / 不熟这个项目 / 怎么接手 / 从哪开始"（已有项目）	`/onboard` 命令 + `project-onboarding` skill（4 阶段深度接手）
大项目（>1k 文件）反复操作想省 token	`/index-repo` 命令（PROJECT_INDEX，2K 投入省 50K/session）
全新空项目 / 想要轻量 CLAUDE.md	`/init` 命令（轻量模式，已有项目会建议改用 /onboard）
涉及证据驱动	`confidence-check` skill（5 维度评估）
涉及 SOLID / 代码风格	`coding-standards` skill（Python + TS 带示例）
涉及架构取舍 / 可逆性	`architecture-decision-records` skill（产出 ADR）
涉及风险管理	`planner` agent 的 Risks & Mitigations 段 + `security-reviewer` agent
写/改代码时想找规范示例	`coding-standards`（Python + TS 示例）

C · 并行决策（Q1-Q4） {#c}

每次接手任务第 1 秒自问：

Q1 能拆 2+ 独立子任务？ → fan-out 并行（同一条 message 多个 Task call）
Q2 多视角给不同答案？ → party-mode 辩论
Q3 有时序依赖？ → 接力（A→B→C，每步主 session 整合）
Q4 任务很小？ → 直接做，不派 agent

3 种最常用并行组合（熟记）：

代码审查 → code-reviewer + security-reviewer 并行（大改动加 silent-failure-hunter + performance-engineer）
Bug 盲诊 → debugger + performance-engineer 并行（涉数据加 database-optimizer）
架构规划 → planner + 栈相关 domain agent 并行（后端 / 前端 / AI 按栈选）

完整 10+ 场景组合 + 4 种协作模式 + 合流 4 动作 + 成本控制 → dispatching-parallel-agents skill。

D · 任务规模 → 流程深度 {#d}

小改动（<30 行 / typo / 文案）：直接做，不启流程。别 confidence-check、别 TDD、别 review——否则"一件小事连串调 skill"。
中等单元（一组件 / 一 endpoint / 一算法）：TDD + review 就够（tdd-workflow → 实现 → code-review-workflow）。
较大单元（完整页面 / 子系统 / PR 改 10+ 文件）：完整流程：confidence-check → /plan → /implement（带 subagent-driven-development）→ /review → verification-loop → /pr。

并行派发必须可视化（v1.9 新增 · 让用户看到真并行）

每次并行派 2+ agent 时，assistant message 必须输出以下可视化格式，然后紧跟 Task tool call：

派发前：

⚡ 并行派发 N agent（fan-out / 预计 ~X min）
   ├─ agent1  用途一句话
   ├─ agent2  用途一句话
   └─ agent3  用途一句话

返回后合流：

✓ N agent 全部返回（耗时 X.X min）
   ├─ agent1  X.X min → N findings
   └─ ...

合流整合：
  CRITICAL (n): ...
  HIGH (n): ...

完整模板 + 理由见 dispatching-parallel-agents skill 的"派发可视化模板"章节。

禁止：不说就派（用户看不到并行证据，怀疑"你是不是只派了 1 个"）。

禁止

❌ 等用户敲 slash 命令才激活能力（用户不知道你有什么）
❌ 一件小事连串调 skill（改 typo 不要先 confidence-check）
❌ 忽略 agent 直接在会话里硬写（上下文污染，丢失 subagent 隔离优势）
❌ 多 agent 并行时把某 agent 的 full report 直接贴给用户（主 session 做摘要）
❌ 并行派发不加可视化文本（见上节）

底线

MCC 的执行哲学：用户少敲，Claude 多主动。本 playbook 是这个哲学的具体落地手册，遇不确定时查它。