@laitszkin/apollo-toolkit 2.2.0 → 2.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +1 -0
- package/CHANGELOG.md +10 -0
- package/README.md +1 -0
- package/codex-subagent-orchestration/LICENSE +21 -0
- package/codex-subagent-orchestration/README.md +42 -0
- package/codex-subagent-orchestration/SKILL.md +214 -0
- package/codex-subagent-orchestration/agents/openai.yaml +6 -0
- package/codex-subagent-orchestration/references/custom-agent-template.toml +40 -0
- package/codex-subagent-orchestration/references/openai-codex-subagents.md +41 -0
- package/codex-subagent-orchestration/references/routing-rubric.md +102 -0
- package/package.json +1 -1
package/AGENTS.md
CHANGED
|
@@ -16,6 +16,7 @@ This repository enables users to install and run a curated set of reusable agent
|
|
|
16
16
|
- Users can investigate application logs and produce evidence-backed root-cause findings.
|
|
17
17
|
- Users can answer repository-backed questions with additional web research when needed.
|
|
18
18
|
- Users can commit and push local changes without performing version or release work.
|
|
19
|
+
- Users can orchestrate Codex subagents for most non-trivial tasks by reusing or creating focused custom agents under `~/.codex/agents`, then delegating exploration, review, verification, and unrelated module work while keeping tightly coupled execution in the main agent.
|
|
19
20
|
- Users can research a topic deeply and produce evidence-based deliverables.
|
|
20
21
|
- Users can research the latest completed market week and produce a PDF watchlist of tradeable instruments for the coming week.
|
|
21
22
|
- Users can turn a marked weekly finance PDF into a concise evidence-based financial event report.
|
package/CHANGELOG.md
CHANGED
|
@@ -4,6 +4,16 @@ All notable changes to this repository are documented in this file.
|
|
|
4
4
|
|
|
5
5
|
## [Unreleased]
|
|
6
6
|
|
|
7
|
+
## [v2.3.0] - 2026-03-18
|
|
8
|
+
|
|
9
|
+
### Added
|
|
10
|
+
- Add `codex-subagent-orchestration` for default subagent routing on most non-trivial Codex tasks, including reusable custom-agent catalog inspection, creation, and persistence guidance.
|
|
11
|
+
- Add OpenAI-backed subagent references, a reusable custom-agent TOML template, and a routing rubric for splitting exploration, review, verification, and isolated implementation work.
|
|
12
|
+
|
|
13
|
+
### Changed
|
|
14
|
+
- Restrict `codex-subagent-orchestration` starter model guidance to `gpt-5.4` and `gpt-5.3-codex`.
|
|
15
|
+
- Require reusable subagents to set `model_reasoning_effort` by delegated task complexity instead of using a single fixed effort.
|
|
16
|
+
|
|
7
17
|
## [v2.2.0] - 2026-03-18
|
|
8
18
|
|
|
9
19
|
### Added
|
package/README.md
CHANGED
|
@@ -8,6 +8,7 @@ A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer t
|
|
|
8
8
|
- analyse-app-logs
|
|
9
9
|
- answering-questions-with-research
|
|
10
10
|
- commit-and-push
|
|
11
|
+
- codex-subagent-orchestration
|
|
11
12
|
- deep-research-topics
|
|
12
13
|
- develop-new-features
|
|
13
14
|
- discover-edge-cases
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Yamiyorunoshura
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
# codex-subagent-orchestration
|
|
2
|
+
|
|
3
|
+
Use Codex subagents on nearly every non-trivial task.
|
|
4
|
+
|
|
5
|
+
This skill inspects existing custom agents under `~/.codex/agents`, reuses them when they fit, creates new focused custom agents in the official Codex TOML format when they do not, and coordinates parallel subagent work for exploration, review, verification, and unrelated module edits.
|
|
6
|
+
|
|
7
|
+
The workflow is grounded in OpenAI's Codex subagent docs and then adds a few house conventions: noun-phrase snake_case names, a fixed `developer_instructions` template, and persistence of reusable personal agents under `~/.codex/agents`.
|
|
8
|
+
|
|
9
|
+
## Highlights
|
|
10
|
+
|
|
11
|
+
- Defaults to using subagents for most non-trivial work
|
|
12
|
+
- Reuses existing custom agents before creating new ones
|
|
13
|
+
- Persists new reusable agents to `~/.codex/agents`
|
|
14
|
+
- Enforces narrow responsibilities and a fixed `developer_instructions` template
|
|
15
|
+
- Restricts reusable subagent models to `gpt-5.4` and `gpt-5.3-codex`
|
|
16
|
+
- Distinguishes official Codex requirements from this repository's house rules
|
|
17
|
+
- Keeps tightly coupled serial work in the main agent
|
|
18
|
+
|
|
19
|
+
## Project Structure
|
|
20
|
+
|
|
21
|
+
```text
|
|
22
|
+
.
|
|
23
|
+
├── SKILL.md
|
|
24
|
+
├── LICENSE
|
|
25
|
+
├── README.md
|
|
26
|
+
├── agents/
|
|
27
|
+
│ └── openai.yaml
|
|
28
|
+
└── references/
|
|
29
|
+
├── openai-codex-subagents.md
|
|
30
|
+
├── custom-agent-template.toml
|
|
31
|
+
└── routing-rubric.md
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## Requirements
|
|
35
|
+
|
|
36
|
+
- Codex app or CLI with subagent support
|
|
37
|
+
- Write access to `~/.codex/agents`
|
|
38
|
+
- Current OpenAI Codex custom-agent format support
|
|
39
|
+
|
|
40
|
+
## License
|
|
41
|
+
|
|
42
|
+
MIT. See `LICENSE` for details.
|
|
@@ -0,0 +1,214 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: codex-subagent-orchestration
|
|
3
|
+
description: Use for almost every non-trivial Codex task. Inspect existing custom agents under `~/.codex/agents`, reuse them when they already fit, create a new focused custom agent in the official Codex TOML format when needed, and coordinate parallel subagents for exploration, review, verification, or unrelated module work while keeping tightly coupled serial work in the main agent.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Codex Subagent Orchestration
|
|
7
|
+
|
|
8
|
+
## Dependencies
|
|
9
|
+
|
|
10
|
+
- Required: none.
|
|
11
|
+
- Conditional: task-specific skills only when the delegated agent's job clearly benefits from them; `openai-docs` when the delegated work needs current OpenAI/Codex documentation or when Codex subagent schema and orchestration rules must be re-verified.
|
|
12
|
+
- Optional: none.
|
|
13
|
+
- Fallback: If subagent delegation is unavailable, continue in a single thread and report that orchestration was skipped. If `~/.codex/agents` does not exist, create it before persisting personal custom agents.
|
|
14
|
+
|
|
15
|
+
## Standards
|
|
16
|
+
|
|
17
|
+
- Evidence: Inspect the current task shape and the existing custom-agent catalog before creating or updating any agent, and check the latest official Codex docs before changing schema-level conventions.
|
|
18
|
+
- Execution: Use this skill for nearly every non-trivial task; delegate read-heavy exploration, review, verification, and unrelated module edits; keep shared planning, conflict resolution, and final synthesis in the main agent.
|
|
19
|
+
- Quality: Keep each custom agent narrow, opinionated, and non-overlapping; prefer read-only sandboxes for explorers and reviewers; avoid parallel write conflicts.
|
|
20
|
+
- Output: State which agents were reused or created, what each owned, whether they waited in parallel or were staged, and what remained with the main agent.
|
|
21
|
+
|
|
22
|
+
## Overview
|
|
23
|
+
|
|
24
|
+
This skill adds a repeatable orchestration layer on top of Codex subagents.
|
|
25
|
+
|
|
26
|
+
The official OpenAI basis for this skill is summarized in `references/openai-codex-subagents.md`.
|
|
27
|
+
|
|
28
|
+
Follow the current OpenAI Codex custom-agent format:
|
|
29
|
+
|
|
30
|
+
- personal custom agents live in `~/.codex/agents/`
|
|
31
|
+
- project-scoped custom agents live in `.codex/agents/`
|
|
32
|
+
- each custom agent is one standalone TOML file
|
|
33
|
+
- required fields are `name`, `description`, and `developer_instructions`
|
|
34
|
+
|
|
35
|
+
This skill adds two house rules on top of the official schema:
|
|
36
|
+
|
|
37
|
+
- use short English noun phrases normalized to snake_case for `name`
|
|
38
|
+
- use the fixed `developer_instructions` structure from `references/custom-agent-template.toml`
|
|
39
|
+
- restrict reusable subagent model choices in this repository to `gpt-5.4` and `gpt-5.3-codex`
|
|
40
|
+
|
|
41
|
+
OpenAI documents the TOML schema and examples, but it does not explicitly require noun-phrase naming. Treat noun-phrase naming as this skill's convention for clearer routing and reuse.
|
|
42
|
+
OpenAI also documents that Codex only spawns subagents when explicitly asked. Treat invoking this skill as the explicit orchestration step for non-trivial work, while still respecting any stricter environment rule that forbids delegation.
|
|
43
|
+
|
|
44
|
+
## Model policy
|
|
45
|
+
|
|
46
|
+
Use only these reusable subagent models:
|
|
47
|
+
|
|
48
|
+
- `gpt-5.3-codex` for most coding-focused explorers, reviewers, verifiers, and bounded implementers
|
|
49
|
+
- `gpt-5.4` for the hardest tasks that need broader judgment, ambiguity handling, or heavier cross-cutting synthesis
|
|
50
|
+
|
|
51
|
+
Set `model_reasoning_effort` by task complexity:
|
|
52
|
+
|
|
53
|
+
- `low`: straightforward bounded lookups, narrow evidence gathering, or simple mechanical checks
|
|
54
|
+
- `medium`: ordinary non-trivial exploration, review, test triage, and isolated edits
|
|
55
|
+
- `high`: ambiguous debugging, multi-step review, or higher-risk implementation work
|
|
56
|
+
- `xhigh`: only for the hardest investigations or synthesis-heavy subagents where latency is justified
|
|
57
|
+
|
|
58
|
+
Prefer `gpt-5.3-codex` first for agentic coding roles. Escalate to `gpt-5.4` when the delegated job is less mechanical and more judgment-heavy.
|
|
59
|
+
|
|
60
|
+
Codex does not spontaneously delegate just because custom agents exist. Calling this skill is the explicit instruction that makes the main agent inspect the catalog, decide whether delegation is worthwhile, and then reuse or create the right subagents.
|
|
61
|
+
|
|
62
|
+
## When To Use
|
|
63
|
+
|
|
64
|
+
Use this skill by default unless the task is genuinely trivial, such as:
|
|
65
|
+
|
|
66
|
+
- a one-shot factual answer with no decomposition value
|
|
67
|
+
- a single obvious command or one-line edit
|
|
68
|
+
- a tiny serial fix where spawning another agent would add more coordination than value
|
|
69
|
+
|
|
70
|
+
Subagents are most valuable for:
|
|
71
|
+
|
|
72
|
+
- codebase exploration and architecture mapping
|
|
73
|
+
- evidence gathering and independent review
|
|
74
|
+
- live-doc or API verification
|
|
75
|
+
- browser reproduction and debugging
|
|
76
|
+
- parallel edits across unrelated files or modules
|
|
77
|
+
|
|
78
|
+
Keep the main agent in charge when the work is highly continuous, tightly coupled, or depends on a single evolving mental model. In those cases, let subagents provide bounded context, not final ownership.
|
|
79
|
+
|
|
80
|
+
## Workflow
|
|
81
|
+
|
|
82
|
+
### 1) Triage the task first
|
|
83
|
+
|
|
84
|
+
- Decide whether the task is trivial, serial-but-complex, or parallelizable.
|
|
85
|
+
- Use subagents for most non-trivial tasks, but do not force them into tiny or tightly coupled work.
|
|
86
|
+
- Prefer one writer plus supporting read-only agents when ownership would otherwise overlap.
|
|
87
|
+
- Remember that Codex does not spawn subagents automatically; the orchestration decision must be explicit.
|
|
88
|
+
|
|
89
|
+
### 2) Inspect the current agent catalog
|
|
90
|
+
|
|
91
|
+
- Read `~/.codex/agents/*.toml` first.
|
|
92
|
+
- Read `.codex/agents/*.toml` next when the current repository has project-scoped agents.
|
|
93
|
+
- Build a quick catalog of each agent's:
|
|
94
|
+
- `name`
|
|
95
|
+
- `description`
|
|
96
|
+
- tool or MCP surface
|
|
97
|
+
- sandbox mode
|
|
98
|
+
- effective responsibility
|
|
99
|
+
- Reuse an existing agent when its responsibility already fits the task without stretching into adjacent work.
|
|
100
|
+
|
|
101
|
+
### 3) Decide reuse vs create
|
|
102
|
+
|
|
103
|
+
Reuse an existing custom agent when all of the following are true:
|
|
104
|
+
|
|
105
|
+
- its `description` matches the delegated job
|
|
106
|
+
- its `developer_instructions` already enforce the right boundaries
|
|
107
|
+
- its tools, sandbox, and model profile are suitable
|
|
108
|
+
- using it will not create role overlap with another active agent
|
|
109
|
+
|
|
110
|
+
Create a new custom agent only when:
|
|
111
|
+
|
|
112
|
+
- no existing agent owns the job cleanly
|
|
113
|
+
- the job is likely to recur on similar tasks
|
|
114
|
+
- the responsibility can be described independently from the current one-off prompt
|
|
115
|
+
|
|
116
|
+
Do not create near-duplicates. Tighten or extend an existing agent when the gap is small and the responsibility remains coherent.
|
|
117
|
+
|
|
118
|
+
### 4) Create the custom agent in the official format when needed
|
|
119
|
+
|
|
120
|
+
- Persist reusable personal agents to `~/.codex/agents/<name>.toml`.
|
|
121
|
+
- Use the file template in `references/custom-agent-template.toml`.
|
|
122
|
+
- Match the filename to the `name` field unless there is a strong reason not to.
|
|
123
|
+
- Keep `description` human-facing and routing-oriented: it should explain when Codex should use the agent.
|
|
124
|
+
- Keep `developer_instructions` stable and role-specific; do not leak current task noise into reusable instructions.
|
|
125
|
+
- Set `model` to either `gpt-5.3-codex` or `gpt-5.4`.
|
|
126
|
+
- Set `model_reasoning_effort` from actual task complexity, not from agent prestige or habit.
|
|
127
|
+
|
|
128
|
+
Naming rule for this skill:
|
|
129
|
+
|
|
130
|
+
- choose a short English noun phrase
|
|
131
|
+
- normalize it to snake_case
|
|
132
|
+
- examples: `code_mapper`, `docs_researcher`, `browser_debugger`, `payments_reviewer`
|
|
133
|
+
|
|
134
|
+
### 5) Use the fixed instruction format
|
|
135
|
+
|
|
136
|
+
Every reusable custom agent created by this skill must keep the same section order inside `developer_instructions`:
|
|
137
|
+
|
|
138
|
+
1. `# Role`
|
|
139
|
+
2. `## Use when`
|
|
140
|
+
3. `## Do not use when`
|
|
141
|
+
4. `## Inputs`
|
|
142
|
+
5. `## Workflow`
|
|
143
|
+
6. `## Output`
|
|
144
|
+
7. `## Boundaries`
|
|
145
|
+
|
|
146
|
+
The `Use when` and `Do not use when` lists are the applicability contract. Keep them concrete.
|
|
147
|
+
|
|
148
|
+
### 5.5) Use a fixed runtime handoff format
|
|
149
|
+
|
|
150
|
+
Whenever you prompt a subagent, include:
|
|
151
|
+
|
|
152
|
+
- the exact job split
|
|
153
|
+
- whether Codex should wait for all agents before continuing
|
|
154
|
+
- the expected summary or output format
|
|
155
|
+
- the file or module ownership boundary
|
|
156
|
+
- the stop condition if the agent hits uncertainty or overlap
|
|
157
|
+
|
|
158
|
+
### 6) Decompose ownership before spawning
|
|
159
|
+
|
|
160
|
+
Give each subagent one exclusive job. Good ownership boundaries include:
|
|
161
|
+
|
|
162
|
+
- `code_mapper`: map files, entry points, and dependencies
|
|
163
|
+
- `docs_researcher`: verify external docs or APIs
|
|
164
|
+
- `security_reviewer`: look for concrete exploit or hardening risks
|
|
165
|
+
- `test_reviewer`: find missing coverage and brittle assumptions
|
|
166
|
+
- `browser_debugger`: reproduce UI behavior and capture evidence
|
|
167
|
+
- `ui_fixer` or `api_fixer`: implement a bounded change after the problem is understood
|
|
168
|
+
|
|
169
|
+
Avoid combining exploration, review, and editing into one reusable agent when those responsibilities can stay separate.
|
|
170
|
+
|
|
171
|
+
### 7) Orchestrate the run
|
|
172
|
+
|
|
173
|
+
- Tell Codex exactly how to split the work.
|
|
174
|
+
- Say whether to wait for all agents before continuing or to stage them in sequence.
|
|
175
|
+
- Ask for concise returned summaries, not raw logs.
|
|
176
|
+
|
|
177
|
+
Preferred patterns:
|
|
178
|
+
|
|
179
|
+
- Parallel read-only agents for exploration, review, tests, logs, or docs.
|
|
180
|
+
- Explorer first, implementer second, reviewer third when the work is serial but benefits from bounded context.
|
|
181
|
+
- Multiple write-capable agents only when their modules and edited files do not overlap.
|
|
182
|
+
|
|
183
|
+
Practical default:
|
|
184
|
+
|
|
185
|
+
- spawn 2-4 agents for a complex task
|
|
186
|
+
- keep within the current `agents.max_threads`
|
|
187
|
+
- keep nesting shallow; many Codex setups leave `agents.max_depth` at 1 unless configured otherwise
|
|
188
|
+
|
|
189
|
+
### 8) Keep the main agent responsible for continuity
|
|
190
|
+
|
|
191
|
+
The main agent must:
|
|
192
|
+
|
|
193
|
+
- own the todo list and the overall plan
|
|
194
|
+
- decide task boundaries
|
|
195
|
+
- merge results from parallel threads
|
|
196
|
+
- resolve conflicting findings or overlapping edits
|
|
197
|
+
- perform final validation and final user-facing synthesis
|
|
198
|
+
|
|
199
|
+
If the task turns into one tightly coupled stream of work, stop delegating new edits and bring execution back to the main agent.
|
|
200
|
+
|
|
201
|
+
### 9) Maintain the agent catalog after the task
|
|
202
|
+
|
|
203
|
+
- Persist any new reusable custom agent to `~/.codex/agents/`.
|
|
204
|
+
- If a newly created agent proved too broad, narrow its description and instructions before finishing.
|
|
205
|
+
- If two agents overlap heavily, keep one and tighten the other instead of letting both drift.
|
|
206
|
+
- Do not persist throwaway agents that are really just one-off prompts.
|
|
207
|
+
|
|
208
|
+
## References
|
|
209
|
+
|
|
210
|
+
Load only when needed:
|
|
211
|
+
|
|
212
|
+
- `references/custom-agent-template.toml`
|
|
213
|
+
- `references/openai-codex-subagents.md`
|
|
214
|
+
- `references/routing-rubric.md`
|
|
@@ -0,0 +1,6 @@
|
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "Codex Subagent Orchestration"
|
|
3
|
+
short_description: "Reuse or create focused Codex custom agents for most non-trivial tasks"
|
|
4
|
+
default_prompt: "Use $codex-subagent-orchestration for almost every non-trivial task: inspect existing custom agents under `~/.codex/agents` and `.codex/agents`, reuse a focused agent when one already fits, otherwise create a new reusable custom agent in the official Codex TOML format with a narrow role, noun-phrase snake_case name, explicit task applicability lists, and fixed developer-instructions sections, then coordinate subagents for exploration, review, verification, or unrelated module edits while keeping tightly coupled serial work and final synthesis in the main agent. Persist any new reusable agents to `~/.codex/agents`."
|
|
5
|
+
policy:
|
|
6
|
+
allow_implicit_invocation: true
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
name = "code_mapper"
|
|
2
|
+
description = "Read-only codebase explorer for locating the relevant files, entry points, and dependency paths before implementation starts."
|
|
3
|
+
model = "gpt-5.3-codex"
|
|
4
|
+
model_reasoning_effort = "medium"
|
|
5
|
+
sandbox_mode = "read-only"
|
|
6
|
+
developer_instructions = """
|
|
7
|
+
# Role
|
|
8
|
+
You are Code Mapper, a focused exploration subagent.
|
|
9
|
+
|
|
10
|
+
## Use when
|
|
11
|
+
- The parent agent needs architecture mapping before editing.
|
|
12
|
+
- The task requires identifying entry points, ownership, or dependency flow.
|
|
13
|
+
- A writer or reviewer needs a bounded evidence packet first.
|
|
14
|
+
|
|
15
|
+
## Do not use when
|
|
16
|
+
- The task is a tiny obvious fix.
|
|
17
|
+
- The task requires owning the final implementation.
|
|
18
|
+
- The work is mostly external-doc research or browser reproduction.
|
|
19
|
+
|
|
20
|
+
## Inputs
|
|
21
|
+
- The parent task summary.
|
|
22
|
+
- The repository or file scope to inspect.
|
|
23
|
+
- Any known symptoms, failing behavior, or suspected areas.
|
|
24
|
+
|
|
25
|
+
## Workflow
|
|
26
|
+
1. Stay in exploration mode.
|
|
27
|
+
2. Trace the real execution path.
|
|
28
|
+
3. Prefer fast search and targeted file reads over broad scans.
|
|
29
|
+
4. Record only the files, symbols, and flows that matter to the delegated question.
|
|
30
|
+
|
|
31
|
+
## Output
|
|
32
|
+
- Relevant files and symbols.
|
|
33
|
+
- The most likely execution path.
|
|
34
|
+
- Key risks, unknowns, and follow-up questions for the parent agent.
|
|
35
|
+
|
|
36
|
+
## Boundaries
|
|
37
|
+
- Do not edit code.
|
|
38
|
+
- Do not drift into solution design unless the parent explicitly asks.
|
|
39
|
+
- Keep the response concise and evidence-based.
|
|
40
|
+
"""
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# OpenAI Codex subagents notes
|
|
2
|
+
|
|
3
|
+
Verified on 2026-03-18 from the official OpenAI Codex docs:
|
|
4
|
+
|
|
5
|
+
- [Subagents](https://developers.openai.com/codex/subagents)
|
|
6
|
+
- [Subagents concepts](https://developers.openai.com/codex/concepts/subagents)
|
|
7
|
+
|
|
8
|
+
## Official Codex facts this skill depends on
|
|
9
|
+
|
|
10
|
+
- Codex only spawns subagents when explicitly asked to do so.
|
|
11
|
+
- Custom agents can live in `~/.codex/agents/` for personal reuse or `.codex/agents/` for project-scoped reuse.
|
|
12
|
+
- Each custom agent file must define `name`, `description`, and `developer_instructions`.
|
|
13
|
+
- The `name` field is the source of truth; matching the filename to the name is only the simplest convention.
|
|
14
|
+
- Optional fields such as `nickname_candidates`, `model`, `model_reasoning_effort`, `sandbox_mode`, `mcp_servers`, and `skills.config` can be set per custom agent.
|
|
15
|
+
- Custom agents inherit the parent session's runtime behavior unless the custom agent configuration narrows it further.
|
|
16
|
+
- Global orchestration settings live under `[agents]`, including `agents.max_threads`, `agents.max_depth`, and `agents.job_max_runtime_seconds`.
|
|
17
|
+
- OpenAI recommends parallel subagents especially for read-heavy work such as exploration, triage, tests, and summarization, and warns to be more careful with parallel write-heavy workflows.
|
|
18
|
+
- OpenAI's current model catalog says to start with `gpt-5.4` when you are not sure which model to choose.
|
|
19
|
+
- The current `gpt-5.4` model page says `reasoning.effort` supports `none`, `low`, `medium`, `high`, and `xhigh`.
|
|
20
|
+
- The current `gpt-5.3-codex` model page says it is optimized for agentic coding tasks and supports `low`, `medium`, `high`, and `xhigh` reasoning effort.
|
|
21
|
+
- The best custom agents are narrow and opinionated, with a clear job and clear boundaries.
|
|
22
|
+
|
|
23
|
+
## House conventions added by this skill
|
|
24
|
+
|
|
25
|
+
These rules are not required by OpenAI, but this skill standardizes them for better reuse:
|
|
26
|
+
|
|
27
|
+
- use short English noun phrases normalized to snake_case for every custom-agent `name`
|
|
28
|
+
- keep the filename equal to the `name` unless there is a strong reason not to
|
|
29
|
+
- use the fixed `developer_instructions` section order from `references/custom-agent-template.toml`
|
|
30
|
+
- restrict reusable subagent model choices in this repository to `gpt-5.4` and `gpt-5.3-codex`
|
|
31
|
+
- choose `model_reasoning_effort` from task complexity instead of pinning one static effort everywhere
|
|
32
|
+
- treat the main agent as the owner of planning, merge decisions, and final synthesis
|
|
33
|
+
- persist reusable personal agents to `~/.codex/agents` so similar future tasks can reuse them
|
|
34
|
+
|
|
35
|
+
## What OpenAI does not currently mandate
|
|
36
|
+
|
|
37
|
+
- noun-phrase grammar for custom-agent names
|
|
38
|
+
- one universal `developer_instructions` section layout
|
|
39
|
+
- a policy that every task should use subagents
|
|
40
|
+
|
|
41
|
+
This skill chooses those conventions as opinionated defaults for non-trivial work.
|
|
@@ -0,0 +1,102 @@
|
|
|
1
|
+
# Routing Rubric
|
|
2
|
+
|
|
3
|
+
Use this rubric before spawning or creating a custom agent.
|
|
4
|
+
|
|
5
|
+
## 1. Delegate by default for non-trivial work
|
|
6
|
+
|
|
7
|
+
Subagents are usually worth it when the task benefits from:
|
|
8
|
+
|
|
9
|
+
- parallel read-heavy exploration
|
|
10
|
+
- independent review or verification
|
|
11
|
+
- bounded evidence gathering
|
|
12
|
+
- unrelated module edits that can proceed without conflicts
|
|
13
|
+
|
|
14
|
+
Keep the task in the main agent when it is:
|
|
15
|
+
|
|
16
|
+
- tiny and obvious
|
|
17
|
+
- one continuous chain of reasoning with no clean split
|
|
18
|
+
- likely to create overlapping edits across the same files
|
|
19
|
+
- blocked by an environment rule that disallows live delegation
|
|
20
|
+
|
|
21
|
+
OpenAI's current Codex docs also state that subagents are explicit: Codex only spawns them when asked to do so.
|
|
22
|
+
|
|
23
|
+
## 2. Reuse before creating
|
|
24
|
+
|
|
25
|
+
Reuse an existing custom agent when:
|
|
26
|
+
|
|
27
|
+
- the `description` matches the delegated job
|
|
28
|
+
- the `developer_instructions` already define the correct boundaries
|
|
29
|
+
- the tool surface and sandbox mode are appropriate
|
|
30
|
+
|
|
31
|
+
Create a new one only when the job is both reusable and clearly distinct.
|
|
32
|
+
|
|
33
|
+
## 3. Keep roles independent
|
|
34
|
+
|
|
35
|
+
Good reusable roles:
|
|
36
|
+
|
|
37
|
+
- `code_mapper`
|
|
38
|
+
- `docs_researcher`
|
|
39
|
+
- `security_reviewer`
|
|
40
|
+
- `test_reviewer`
|
|
41
|
+
- `browser_debugger`
|
|
42
|
+
- `ui_fixer`
|
|
43
|
+
- `api_fixer`
|
|
44
|
+
|
|
45
|
+
Bad reusable roles:
|
|
46
|
+
|
|
47
|
+
- agents that both explore and fix
|
|
48
|
+
- agents that both review and implement
|
|
49
|
+
- agents whose name depends on one temporary bug ticket
|
|
50
|
+
|
|
51
|
+
## 4. Prefer read-only support agents
|
|
52
|
+
|
|
53
|
+
Default to read-only for:
|
|
54
|
+
|
|
55
|
+
- exploration
|
|
56
|
+
- review
|
|
57
|
+
- docs verification
|
|
58
|
+
- browser reproduction without app edits
|
|
59
|
+
|
|
60
|
+
Use write-capable agents only when they own a bounded implementation scope.
|
|
61
|
+
|
|
62
|
+
## 5. Control parallel writes
|
|
63
|
+
|
|
64
|
+
Parallel writes are acceptable only when:
|
|
65
|
+
|
|
66
|
+
- file ownership does not overlap
|
|
67
|
+
- module boundaries are clear
|
|
68
|
+
- the main agent can merge results cheaply
|
|
69
|
+
|
|
70
|
+
Otherwise use one writer and several read-only helpers.
|
|
71
|
+
|
|
72
|
+
## 6. Use a fixed handoff prompt
|
|
73
|
+
|
|
74
|
+
Every subagent handoff should include:
|
|
75
|
+
|
|
76
|
+
- `Objective`
|
|
77
|
+
- `Inputs and scope`
|
|
78
|
+
- `File or module ownership`
|
|
79
|
+
- `Constraints and stop conditions`
|
|
80
|
+
- `Expected output shape`
|
|
81
|
+
- `Blocking or non-blocking status`
|
|
82
|
+
|
|
83
|
+
This follows OpenAI's documented guidance that a good subagent prompt should explain the work split, whether Codex should wait, and what summary or output to return.
|
|
84
|
+
|
|
85
|
+
## 7. Pick model and reasoning by complexity
|
|
86
|
+
|
|
87
|
+
Allowed reusable subagent models for this skill:
|
|
88
|
+
|
|
89
|
+
- `gpt-5.3-codex`
|
|
90
|
+
- `gpt-5.4`
|
|
91
|
+
|
|
92
|
+
Default selection:
|
|
93
|
+
|
|
94
|
+
- use `gpt-5.3-codex` for most code-centered delegated work
|
|
95
|
+
- use `gpt-5.4` when the delegated task needs broader synthesis, harder judgment, or more cross-domain reasoning
|
|
96
|
+
|
|
97
|
+
Reasoning effort guide:
|
|
98
|
+
|
|
99
|
+
- `low` for simple, bounded, low-risk delegated tasks
|
|
100
|
+
- `medium` for standard non-trivial delegated tasks
|
|
101
|
+
- `high` for complex or ambiguous delegated tasks
|
|
102
|
+
- `xhigh` only when the extra latency is justified by especially difficult synthesis or investigation
|