This Skill provides the caller with recommendations for multi-Agent division of labor, execution, and quality checks. The host coordinator is responsible for role boundaries, process, and final delivery; in Meta_Kim, the Router, cross-component state machine, and final acceptance remain the responsibility of Meta_Kim, and this package does not take over these responsibilities.
Core Understanding (Iron Rules): Agent Teams is a "parallel processing + result aggregation" pattern, not a way to expand the context window of a single agent. Each teammate is an independent execution unit with its own independent context, capable of processing large amounts of information in parallel, but ultimately the results need to be aggregated and compressed before being returned to the main session.
Cross-Platform Compatibility Layer (newly added, does not replace the original process)
This Skill's complete 6-phase workflow, on-demand capability resolution, Agent → Skill delegation pattern, quality control, and fault handling rules are still retained. The differences among the four platforms only affect "what tools are used to execute," not "whether these phases are executed."
First identify the current platform, then map the following abstract actions to the platform's native capabilities. Do not promise on non-Claude Code platforms that Task、TeamCreate、SendMessage or Skill(...) definitely exist; and do not skip phases 0-5 just because the platform tool names are different.
| Abstract Action | Claude Code | Codex | OpenClaw | Cursor |
|---|---|---|---|---|
| Invoke Skill | Skill(skill="name", args="...") or slash skill |
Read and follow the local skill instructions; only call it "invocation" when the host exposes a skill tool | Read and follow openclaw/skills or global skill; execute according to OpenClaw's current tools |
Read and follow .cursor/skills or global skill; execute according to Cursor's current agent capabilities |
| Launch an independent Subagent | Use the host's currently exposed Agent / Task, carrying at least the required prompt, and provide according to the current schema subagent_type、description/name and boundaries |
Use the native spawn schema currently exposed by the host (see profiles below) | workspace / agent scheduling capability; if unavailable, execute in phases on the main thread | background agent / agent mode; if unavailable, execute in phases on the main thread |
| Form an Agent Team | Use when the host exposes TeamCreate + Agent / Task(team_name) |
Concurrently invoke multiple host-native spawn calls in the same round, with the main thread aggregating; do not pretend to have a shared team bus | Use when team / workspace capabilities exist; otherwise use multiple tasks or the main thread | Use when background agents / team-like workflow exist; otherwise use multiple tasks or the main thread |
| Member communication/progress | SendMessage or Agent/Task result |
Subtask result reporting; communicate mid-process only when the host exposes agent I/O | Platform messages/logs; when unavailable, use phased text reports | IDE/agent logs; when unavailable, use phased text reports |
| Planning file | planning-with-files skill |
Use if a local skill/tool exists; otherwise use an inline plan or the platform's planning tool | Use if a local planning skill exists; otherwise maintain a visible plan record | Use if a local planning skill exists; otherwise maintain a visible plan record |
Platform Adaptation Bottom Line：
- When writing plans, use abstract action names; when executing, use the current platform's real tool names.
- Claude Code uses the host's currently exposed
Agent/Task; only when the host actually exposesTeamCreate/SendMessageonly then commit to shared team semantics. Do not copy Codex parameters into Claude Code. - Codex should base its choice on the tool schema and permissions actually exposed by the current host, then select a matching profile; it must not guess parameters based solely on product name or version. Only report that an agent has been started when the tool call succeeds and returns an Agent identifier.
- OpenClaw/Cursor's team capabilities may come from project plugins, workspace, or IDE capabilities; probe first, then commit.
- If the platform does not support true parallelism or team communication, explicitly downgrade to "main-thread phased execution," but still carry out the governance process for phases 0-5.
Codex host profiles (thin adaptation)
The current host schema takes precedence over the known examples below. First read the tool names, required fields, optional fields, return identifiers, concurrency and communication permissions; submit only the fields allowed by the current schema. When the host does not expose a tool, do not guess its name, and do not implement an execution engine yourself for adaptation.agent_type、model、reasoning_effort may be hidden by feature flags; even if exposed, follow the host's selection/inheritance rules and do not override automatically.
- codex-v1: the known upstream namespace is
multi_agent_v1.spawn_agent, tasks usemessageoritems, historical inheritance uses booleanfork_context；agent_typeis available only when the current schema exposes it and allows selection. - codex-v2: the known upstream top-level
spawn_agentrequirestask_nameandmessage, historical inheritance uses stringfork_turns（none、allor a positive integer string); you cannot pass it V1'sfork_context。 - codex-v2-limited: the tool name and required fields are the same as V2, but the host may hide
agent_type、model、reasoning_effort; do not copy optional fields from other profiles. - no-capability: when there is no available spawn, or permissions do not allow concurrency, explicitly adopt main-thread phased execution, still retaining phases 0-5; you must not report true parallelism, team communication, or sub-agent success. Communication tools must also be probed separately.
The following minimal call examples only demonstrate the static protocol and do not promise that a real host has been tested. The test fixtures verify consistency between the documentation and the known schema; when a new host schema differs, treat on-site findings as authoritative and record the differences.
{"tool":"multi_agent_v1.spawn_agent","arguments":{"message":"Review the bounded task and return evidence.","fork_context":false}}
{"tool":"spawn_agent","arguments":{"task_name":"review_task","message":"Review the bounded task and return evidence.","fork_turns":"none"}}
{"tool":"spawn_agent","arguments":{"task_name":"review_task","message":"Review the bounded task and return evidence."}}
{"tool":null,"arguments":null,"mode":"sequential","parallel":false}
References:OpenAI Codex schema snapshot(verified 2026-10-02, V1/V2 coexist with field toggles);Agent Skills format specification(custom versions are placed in metadata.version, package facts are based on capability.json ).
Applicable vs Not Applicable
| Applicable | Not Applicable |
|---|---|
| Cross-file refactoring, multi-dimensional review | Small single-file changes |
| Large-scale code generation, parallel processing | Simple Q&A, linear sequential tasks |
| Complex tasks requiring multi-role collaboration | Tasks that a single agent can complete |
Boundary handling: when user input is vague, first guide them to clarify the task before deciding; when the task is too simple, proactively suggest using a single agent rather than forming a team.
Iron rules for user visibility
- Output a plan before each phase starts, and output results after completion
- Sub-agents execute in the background, but progress must be reported to the user
- The task decomposition plan must be confirmed by the user before execution; if the host platform or project instructions require direct execution, explain the default assumptions adopted
- Notify immediately on failure:
❌ [角色名] 失败: [原因], providing retry/skip/terminate options - After everything is complete, output a summary report (see the format in Phase 5), and state the platform tools actually used and any fallback paths
Scenario Decision Tree
Execution Order: First execute Phase 0 and Phase 1 (mandatory), then choose a scenario based on task complexity (affecting Phases 2-5).
| Question | Path |
|---|---|
| Q0: Did Phase 1 find an existing provider (Agent / Skill / Tool) that can fully solve the task? | Yes → Scenario 2 / No → Q1 |
| Q1: Task complexity? | Simple (1-2 steps) → Scenario 1 / Medium (3-5 steps) → Scenario 3 / Complex (6+ steps) → Q2 |
| Q2: Is clear team division of labor needed? | Yes → Scenario 4 / No → Scenario 5 |
- When the user directly specifies a scenario number, skip the decision tree and execute directly
- When no scenario is specified, useScenario 3 (Plan + Review)
- Note: Phase 0 (planning) and Phase 1 (local capability discovery) are prerequisite steps for all scenarios; external
find-skillsis only triggered when there is an actual gap in local capabilities
5 Major Orchestration Scenarios
| # | Scenario | Applicable Conditions | Core Strategy |
|---|---|---|---|
| 1 | Prompt Enhancement | Simple task, 1-2 steps | Optimize a single agent's prompt; no splitting, no team formation |
| 2 | Direct Provider Reuse | The task can be fully solved by a single existing Agent / Skill / Tool | Directly bind the discovered provider; no external search or Agent Teams formation needed |
| 3 | Plan + Review | Medium/complex tasks (default） | Produce a plan → user confirmation → parallel execution → Review acceptance |
| 4 | Lead-Member | Clear team division of labor needed | Leader coordinates and assigns; Members execute in parallel, collaborating via TaskList |
| 5 | Composite Orchestration | Complex tasks with no fixed pattern | Dynamically combine the above scenarios, switching strategies by phase |
Model Division of Labor(common to all scenarios): allocate by task complexity through the model selection capabilities supported by the platform; Claude Code can allocate via the Task tool's model parameter —opusfor complex reasoning,haikufor simple tasks,sonnetfor routine tasks. When the platform does not support model selection, do not hard-code model commitments.
Collaboration Modes
| Mode | Communication Method | Applicable Scenarios | Claude Code Startup Method | Codex Startup Method | OpenClaw / Cursor Startup Method |
|---|---|---|---|---|---|
| Subagent | Sub-agent → one-way reporting to the main coordinator | Parallel independent tasks | The host's current Agent / Task |
Current host-native spawn schema | Platform agent/background/workspace capabilities; if unavailable, execute in the main thread by phase |
| Agent Team | Members can communicate bidirectionally (SendMessage) | Complex tasks requiring collaboration | TeamCreate + Agent / Task(team_name)(only when exposed by the host) |
Multiple host-native spawn calls + main thread coordination; interact midway only when the host exposes agent I/O | Platform team/workspace/background-agent capabilities; otherwise fall back |
Selection principle: use a Subagent when tasks have no dependencies between them (simple and efficient); use an Agent Team when tasks require coordination (more capable but higher cost). If the current platform does not have a true team bus, it can only be called "multiple independent subagents + main-thread aggregation" and must not be disguised as bidirectional collaboration between members.
6-phase workflow (including mandatory planning and on-demand capability discovery)
Important note: Phase 0 and Phase 1 aremandatory prerequisite steps for all scenarios; scenario selection (1-5) only affects how Phases 2-5 are executed.
Phase 0: Planning Setup[Hard requirement - mandatory for all scenarios]
Prefer using the current platform's Skill tool to invoke planning-with-files：
Skill(skill="planning-with-files")
Cross-platform adaptation:
- Claude Code: prefer using
Skill(skill="planning-with-files") - Codex: use it if a local skill/tool is available; otherwise use the platform planning tool or an inline plan, and explicitly state that no planning files were created
- OpenClaw/Cursor: use it if a local planning skill is available; otherwise maintain a platform-visible plan record
This will create three core files in the project directory (when planning-with-files is available):
task_plan.md- task plan and phase trackingfindings.md- research findings and knowledge accumulationprogress.md- execution log and progress record
Key rules(to be followed after the planning files are created):
- Read task_plan.md before the start of each phase, and update the status after completion
- Immediately save findings to findings.md after every 2 search/browse operations
- All errors must be recorded in the "Errors Encountered" table in task_plan.md
- Escalate to the user after 3 failures
Iron rule: complex tasks must not be executed without a plan. If the platform does not have planning-with-files, an equivalent plan record or inline plan must still be used, and the planning phase must not be skipped.
Phase 1: Task analysis + capability discovery (Discovery)[Hard requirement - mandatory for all scenarios]
Question before executing:
- When requirements are unreasonable, proactively challenge assumptions and suggest better solutions
- Distinguish between "must be done now" and "can be done later", and exclude non-core scope
- When a task is too large, suggest a smarter starting point
- Describe the required capability first, then match agent / skill / tool, avoiding name-first scheduling
Output a task overview:
| Field | Content |
|---|---|
| Task objective | [one-sentence description] |
| Expected result | [specific deliverable] |
| Acceptance criteria | [quantifiable pass conditions] |
| Scope definition | [must-have vs add-later] |
| Current platform | [Claude Code / Codex / OpenClaw / Cursor / Unknown] |
| Estimated number of Agents | [determined by the task DAG, conflict boundaries, and host concurrency capability; do not hard-code a number] |
| Selected scenario | [scenario number + name] |
| Collaboration mode | [Subagent/Agent Team/Degraded] |
Capability resolution chain (stop on hit; not a fallback ritual that must run every time)：
- Local multi-type capability scan: read the Agents, Skills, Tools, Commands, MCP, and capability index visible to the current runtime. As long as an existing specialized provider covers the subtask, bind that provider and stop searching.
- External capability search (only for genuine gaps): Only when all local relevant providers cannot cover it, and the capability is worth reusing or installing, call
find-skillsor the platform-equivalent search. Installation still requires user/host authorization. - Runtime native binding: Claude Code binds the selected owner to
Agent/Task; Codex writes it into a boundedmessage, then invokes it according to the current host's native spawn schema. - Last resort degradation: Only when the host Agent surface is missing, permissions are blocked, or no usable owner remains after complete discovery, is explicit degraded mode allowed. Generic temporary Subagents are used only when project policy permits; phased execution on the main thread is used only for explicit degradation and must not masquerade as normal orchestration.
Iron rule: Not finding an "exactly matching Skill" does not mean capability failure. When an existing Agent, Tool, Command, or MCP can complete the task, you must not continue external search, nor call it a fallback.
find-skillsWhen there is no installation result, you also must not mark a subsequently successful native Agent invocation as a fallback.
Phase 2: Team formation
Output the team blueprint:
| No. | Role | Responsibility | Model | ownerAgent / subagent_type | Capability Binding | Platform tool/degradation |
|---|---|---|---|---|---|---|
| 1 | [role name] | [specific responsibility] | [opus/sonnet/haiku/platform default] | [discovered owner] | [Agent / Skill / Tool / Command / MCP] | [Claude Agent/Task, Codex spawn_agent, other native surface, or explicit degraded] |
Note: The last two columns indicate the matched professional provider/capability, and the tool actually used on the current platform or the evidence-backed degradation path.
Phase 3: Parallel execution
- Skill task: Use the current platform's Skill invocation mechanism to invoke a locally installed skill; Claude Code example:
Skill(skill="skill-name", args="任务描述") - Agent task: Use the current platform's native subagent tool; Claude Code uses the host-exposed
Agent/Task, Codex uses the native spawn schema exposed by the current host (see profiles below) - In hybrid orchestration, skills and subagents can run in parallel; when the platform does not support parallelism, execute sequentially by phase and explain the degradation
- After each agent/skill completes, report:
✅ [角色名] 完成: [一句话结果] - When encountering problems, give the user options instead of silently choosing one yourself
Agent → Skill delegation(3 modes for a subagent to invoke a skill):
Whether the selected professional owner can continue to invoke Skillin Claude Code depends on the current Agent/Task schema and tool permissions; other platforms likewise must first confirm whether the host grants the subagent equivalent skill/tool permissions. Do not replace an existing professional owner with general-purpose。
| Mode | Flow | Applicable scenario |
|---|---|---|
| Coordinator direct invocation | Coordinator → Skill(skill="name") or platform-equivalent invocation → result |
Single-step Skill task, no parallelism needed |
| Delegated invocation | Coordinator → subagent prompt="Please use /skill-name to complete X" → subagent → Skill/tool or inline execution → report | Multiple Skills in parallel, or a Skill takes a long time |
| Team member invocation | team/subagents → assign tasks → member → Skill/tool or inline execution → report | Complex tasks requiring coordination among members |
Key points of delegated invocation: In the Task/subagent prompt, specify the Skill name and parameters to be invoked; only promise automatic invocation when the platform supports the skill tool, otherwise execute inline according to the Skill documentation and explain.
Phase 4: Quality gatekeeping & product polishing
Acceptance check: Check item by item against the acceptance criteria from Phase 1.
Product polishing(not only functionally complete, but also excellent user experience):
- Boundary handling: whether abnormal inputs, null values, and extreme cases are covered
- Professionalism: whether naming conventions, code style, and error messages are friendly
- Completeness: whether documentation, configuration instructions, and usage examples are complete
- Platform honesty: whether the actually invoked tools and degradation behavior are accurately stated
All passed → proceed to Phase 5. Not passed → send back for revision, up to 2 rounds; if still not passed, notify the user for manual intervention.
Phase 5: Result delivery & deployment handover
Output execution report:
| Item | Content |
|---|---|
| Total tasks | X, succeeded Y, failed Z |
| Actual platform tools | Which real tools were used / whether degraded |
| Results of each Agent | [Role]: [Status] - [Key output] |
| Summary conclusion | [Final conclusion synthesizing all results] |
| Follow-up suggestions | [Improvement directions not currently covered but worth doing] |
Deployment handover(provided as needed):
- How to run: startup commands, environment requirements, configuration instructions
- Verification steps: a checklist of operations the user can verify themselves
- Known limitations: boundaries and constraints of the current version
Execution bottom line
[Hard standards]： 0. Mandatory use of planning-with-files or a platform-equivalent planning mechanism: Any complex task must first create/maintain task_plan.md, findings.md, progress.md, or explicitly state that a platform-equivalent planning record is used
- Mandatory stop upon capability hit: Use local multi-type providers directly upon a hit; search externally only for real capability gaps; explicitly degrade only for real host/permission/owner gaps
[Other principles]:
2. Goals first, organizational structure second—when the task is unclear, clarify first, then decide whether to form a team
3. Team size is determined by the task DAG, conflict boundaries, and host concurrency capability; do not hardcode a uniform upper limit
4. Key milestones must have quality gates and rollback points
5. Do not assume any external tool is available by default; verify local multi-type capabilities first,find-skills verify/invoke only when there is a real gap
6. Browser windows are independent by default and do not share context
7. Cost is only a constraint, not a fixed promise—do not make unrealistic cost estimates
8. Dangerous operations and large-scale changes must first obtain user confirmation or comply with the host platform's approval rules
9. Do not promise capabilities the platform does not have; especially do not directly promise Claude Code's TeamCreate
Fault handling
| Fault type | Handling strategy |
|---|---|
| Agent execution failed | Notify the user and provide retry/skip/terminate/degrade options |
| Skill unavailable | First check whether existing Agent/Tool/Command/MCP already covers it; only search externally for genuine capability gaps, and only explicitly degrade when the actual execution surface is missing |
| Platform tool missing | Switch to a tool available on that platform and clearly explain the degradation path |
| Model timeout | Adjust task complexity or split into smaller subtasks |
| Quality does not meet standards | Send back for revision for at most 2 rounds; if it still does not pass, involve a human |
| Context overflow | Split into smaller subtasks and execute in batches |