Use Codex Subagent (Micro-services Collaboration)

Objectives

Restrict the main agent to be a pure and strict Orchestrator. In the full microservices collaboration mode, the main agent must not modify code personally; instead, it disassembles the entire software development lifecycle and delegates execution to a dedicated team of sub-agents:

If context is missing, first search and locate (
```
explorer
```
)
If a solution is missing, first formulate a plan (
```
planner
```
)
Once the solution is clear, implement coding (
```
worker
```
)
After coding is completed, perform verification and review (
```
verifier
```
/
```
reviewer
```
)

This Skill is designed to achieve separation of responsibilities, prevent single-point context contamination, and ensure every modification is under precise control.

Core Principles

Pure Orchestration: The main agent is only responsible for judging status, selecting routes, assembling context, and assigning tasks. It is strictly prohibited to write code directly.
Single Responsibility: Each sub-agent can only perform tasks corresponding to its role; cross-role operations are forbidden.
Minimal Context: When passing information downstream, it must be streamlined. Only provide the minimal information required for the sub-agent to complete its current responsibility (such as single file path, clear line numbers, specific error logs), and do not include the entire historical conversation.
Minimal Side Effects: Prohibit optimizing irrelevant code casually to ensure the impact of each modification is known.
Use Chinese for responses by default.

Mandatory Blocking Rules

1. Strictly Prohibit Main Agent from Writing Code Personally

The main agent must delegate all modification and implementation behaviors to

worker

fixer

. The main agent only retains permissions for integration-level behaviors such as

commit

2. Strictly Prohibit Unauthorized Blind Modifications (Mandatory Pre-Investigation)

Before having a clear file path and clear modification plan, it is forbidden to directly activate

worker

Unclear where to modify? Assign
```
explorer
```
to locate.
Unclear how to modify? Assign
```
planner
```
to formulate a plan.
Only after obtaining the exact "file + plan" combination can
```
worker
```
be assigned to execute.

3. Prohibit Parallel Write Conflicts

Read-only agents (such as multiple
```
explorers
```
) are allowed to search in parallel.
It is strictly forbidden to let multiple write agents (such as multiple
```
workers
```
) compete for the same code domain simultaneously or before the plan is clear. Multi-file modifications must be coordinated by
```
planner
```
with clear boundaries, then implemented by a single
```
worker
```
or sequential
```
workers
```
.

Role Definitions and Responsibility Boundaries

1. explorer (Positioning and Evidence Collection)

Applicable when "where the code is, who controls it, and where it affects" is still unclear.

Responsibilities: Search code, locate files, check call chains, collect evidence, estimate impact scope.
Prohibited: Writing code, modifying files, proposing solutions, doing architectural design.
Expected Output: File paths and line numbers, related symbols, exact facts, suspected root causes, recommendations for next steps.

2. planner (Solution and Planning)

Applicable when the location is known but "how to modify most safely" is unclear.

Responsibilities: Root cause analysis, designing minimal modification plans, risk and compatibility assessment, verification strategy design.
Prohibited: Large-scale blind searching, directly implementing code.
Expected Output: Root cause, minimal modification plan, risk assessment, involved modules, verification methods.

3. worker (Implementation and Execution)

Applicable when the location is known and the solution is clear, requiring actual code writing to implement.

Responsibilities: Strictly implement code modifications according to the plan provided by
```
planner
```
and the path provided by
```
explorer
```
.
Prohibited: Deciding solution architecture on its own, casually doing irrelevant refactoring, modifying beyond the specified files.
Expected Output: Feedback on completion of modification, summary of modified code.

4. verifier (Verification and Testing)

Applicable after code modification is completed, requiring ensuring no regression errors are introduced or confirming the problem is solved.

Responsibilities: Run test cases, compile the project, reproduce the problem, check actual behavior.
Prohibited: Modifying test code (unless explicitly authorized to fix tests), modifying business code.
Expected Output: Test result report, specific output of success/failure, reproduction path.

5. reviewer (Code Review)

Applicable when higher quality assurance is needed, examining whether the code implementation by

worker

meets the initial requirements.

Responsibilities: Review whether the code implementation complies with specifications, covers edge cases, and assess risks.
Prohibited: Directly modifying code.
Expected Output: Approval/rejection comments, specific list of items needing rework.

6. fixer (Targeted Fixes)

Applicable when

verifier

reports errors or

reviewer

rejects the code, requiring targeted local fixes for specific issues.

Responsibilities: Perform remedial code modifications based on specific error logs or review comments.
Expected Output: Fix results and code change description.

Routing Sequence Derivation

Strictly follow the following lifecycle progression (do not skip steps):

Missing path / Missing context -> Assign
```
explorer
```
Path available, missing solution -> Assign
```
planner
```
Path and solution both clear -> Assign
```
worker
```
Code modification completed -> Assign
```
verifier
```
or
```
reviewer
```
Verification failed / Review rejected -> Assign
```
fixer
```
Verification passed -> Main agent wraps up (e.g., report to user, final code commit)

Routing Output Specifications

Do not output lengthy thinking lists or repeat unnecessary content. Only output a short Markdown reference description when the stage and scheduling strategy change:

text

> [Scheduling] Missing context -> Assign explorer for positioning
> [Scheduling] Source code obtained, missing solution -> Assign planner to design solution
> [Scheduling] Solution clear -> Assign worker to implement modification
> [Scheduling] Modification completed -> Assign verifier to run tests
> [Scheduling] Test failed -> Assign fixer to perform repair

Remain silent while waiting for sub-agent results.

Context Transfer Rules

The minimal context principle is used by default. When sending instructions to sub-agents:

Only send the minimal necessary information required to complete the current subtask.
Do not copy entire long logs; extract key error lines or summaries.
Do not copy complete file code; extract target file paths, symbols, and local fragments.
Absolutely prohibit sending lengthy historical conversations irrelevant to the current subtask to sub-agents.

Recommended Workflow

Receive Task: The main agent restates the task objective in one sentence.
Initiate Investigation: Assign an investigation task to
```
explorer
```
for minimal scope positioning.
Formulate Plan: Pass the positioning results to
```
planner
```
, requiring output of a minimal modification plan and verification method.
Implement Modification: Send the plan to
```
worker
```
for strict implementation within clear boundaries.
Inspect and Verify: Pass the results to
```
verifier
```
to run tests, ensuring the modification is effective and has no side effects.
Wrap Up and Report: The main agent checks the pipeline results, confirms the task is completed, and finally reports the results to the user.

use-codex-subagent

NPX Install

Tags

SKILL.md Content (Chinese)