菜单
Orchestrate multi-phase workflows with parallel and sequential stages. Research, plan, implement, verify — each phase produces filesystem artifacts consumed by the next. Use when task decomposes into stages that would overflow a single agent's context.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | phases |
| description | Orchestrate multi-phase workflows with parallel and sequential stages. Research, plan, implement, verify — each phase produces filesystem artifacts consumed by the next. Use when task decomposes into stages that would overflow a single agent's context. |
| disable-model-invocation | false |
Use when: task decomposes into research/plan/implement/verify stages, context would overflow with full problem, want debuggable intermediate artifacts. Always dispatch via general-purpose agents with prompt files, never Explore/Plan agents.
Orchestrate via filesystem artifacts. No agent-to-agent communication. Foreman reads/writes the "message bus" (docs/).
Good parallel tasks (per Simon Willison):
Bad parallel tasks:
[Research] PARALLEL -> docs/reports/*.md
[Planning] SEQUENTIAL -> docs/plans/*.md (reads reports/)
[Implementation] PARALLEL -> src/* (reads plans/)
[Verification] SEQUENTIAL -> test results
[Integration] SEQUENTIAL -> final assembly
docs/
├── reports/ # Research output (consumed by planners)
├── plans/ # Planning output (consumed by implementers)
└── notes/ # Decisions, context, working docs
You are a [ROLE] agent.
INPUT: Read [FILE_PATHS]
TASK: [SPECIFIC_TASK]
OUTPUT: Write findings to [OUTPUT_PATH]
Constraints:
- Stay focused on [DOMAIN]
- Do not implement outside your scope
- Note blockers/dependencies for foreman
[Research Phase] - PARALLEL
├── Domain A Research -> docs/reports/domain-a.md
├── Domain B Research -> docs/reports/domain-b.md
└── Domain C Research -> docs/reports/domain-c.md
│
v
[Planning Phase] - SEQUENTIAL
└── Planner (reads all reports) -> docs/plans/implementation-plan.md
│
v
[Implementation Phase] - PARALLEL where possible
├── Module A -> src/module_a/
├── Module B -> src/module_b/
└── Tests -> tests/
│
v
[Integration Phase] - SEQUENTIAL
└── Integration (final assembly, testing)
Multi-hypothesis research campaign protocol. Use for open-ended optimization goals ("make X faster", "improve the metric") where several candidate ideas compete for a limited budget. Triages ideas cheaply, confirms survivors with full preregistered experiments, and keeps a committed ledger so dead ideas stay dead.
Controlled benchmark experiment protocol for solver, performance, routing, and optimization work. Use when testing a hypothesis against metrics, comparing implementations, or deciding whether to promote or abandon a benchmark-driven change.
Coordination-only protocol. You dispatch subagents, you do not execute code. Restricts tools to Read, Write (prompts/ and notes- only), Agent, Glob, Grep. Use when orchestrating multi-agent work.
Four-role sequential pipeline for complex, high-risk changes. Scout surveys the codebase, Coder implements with TDD, Analyst finds problems, Verifier gates the merge. Use for large refactors, architectural shifts, and interdependent multi-phase work.
Background knowledge for writing and launching subagent prompts. Covers prompt file conventions, worker identity declarations, batch dispatch patterns, and parallel swarm safety. Auto-invocable when dispatching agents.
Deletion-first fixed-point protocol for refactors, cleanup, migrations, and architectural convergence. Use when replacing old surfaces, removing helper debt, shrinking code, moving ownership boundaries, or auditing every symbol in a slice.