Build a Repeatable ChatGPT Delegation Manual From the Codex Tool Reference

The snapshot documents 232 tool interfaces and 44 complete main skill files. The Codex tool reference preserves exposed descriptions and TypeScript declarations. Use those entries to check whether a tool is exposed. Use the skill files to define repeatable work. Verify output against the criteria you set.

Confirm tools before delegation

The Codex tool reference separates tools from skills. Tools are callable endpoints. Skills are reusable instruction packages. Use a skill to define repeatable work.

Tool availability is not fixed. It can vary by session configuration, permissions, connected apps, and installed plugins. Check session configuration, permissions, connected apps, and installed plugins. If the required tool is missing, stop. Fix the environment or reassign the task. Do not ask the model to simulate it.

The Codex tool reference preserves exposed descriptions and TypeScript declarations. Use them as the visible contract. If a description or declaration is vague, treat the tool as unproven.

For file editing, the apply_patch tool is a freeform file-editing tool. Its patch should not be wrapped in JSON. Verify the patch format before applying it. Check the diff after applying it.

Map every delegated task to a skill

Do not delegate ad hoc. Map the task to an existing skill or draft a SKILL.md. The skill page includes the full current SKILL.md source for each available skill. Use that source as the starting point. It should state the task, required tools, inputs, outputs, constraints, and verification steps.

Use this SKILL.md template: Task: [one-line job]. Required tools: [tool names]. Inputs: [files, data, prompts]. Outputs: [file paths, formats, artifacts]. Constraints: [limits, style, safety rules]. Verification steps: [commands, checks, pass criteria].

If a task has no stable tool, do not encode it as a skill. If the task changes shape every run, do not encode it as a skill. If the result cannot be checked against a clear criterion, do not delegate it yet.

Draft SKILL.md files should be short and operational. Use commands, constraints, and examples.

For repeatable work, include a verification block. List the checks the agent must run before declaring the task complete. For code, include tests. For documents, include required sections. For data, include schema checks or row counts.

Run the Tool-Skill-Verify loop

Use a fixed loop. Confirm tool availability. Map the task to a skill. Define acceptance criteria. Run the agent. Verify output against criteria. Log the failure mode for the next run.

Step one: Repeat the four checks above. If the tool is not exposed, record the gap. Do not let the agent guess.

Step two: load the skill. Use the current SKILL.md source. If the skill is missing, draft one. If the skill is stale, update it before use.

Step three: define acceptance criteria. Criteria should be testable. Write a summary is not a criterion. Produce a 300-word summary with three headings, no citations, and no first-person language is a criterion. Run the build is not a criterion. Exit code 0, no new lint errors, and the target file updated is a criterion.

Step four: run the agent. Give it the skill, the tool list, the inputs, and the criteria. Do not add hidden requirements in the prompt. Put them in the skill.

Step five: verify the output. Check the output against the criteria. If the task produced files, inspect the files. If the task produced code, run the tests. If the task produced a patch, check the diff. If the task produced data, validate the schema.

Step six: log the failure mode. If the run failed, record what broke. Was the tool missing? Was the skill ambiguous? Was the patch malformed? Was the output incomplete? The log is the next run's input.

Build the manual as a living document

The playbook should have three parts. A tool inventory. A skill index. A failure log.

The tool inventory lists each tool, its exposed description, its TypeScript declaration, and any visible constraints. For apply_patch, note that the patch should not be wrapped in JSON. For tools with permissions, note the required access. For tools that depend on connected apps, note the dependency.

The skill index should list each skill, its current SKILL.md source, the tools the operator assigns, and the acceptance criteria the operator sets. If the source lacks required tools or criteria, mark it draft. If a skill has a known failure mode, mark it as monitored.

The failure log records each failed run. It should include the task, the skill used, the tools required, the failure mode, and the fix. Use the log to decide which tasks are safe to delegate.

Delegate only when the tool is exposed, the skill is current, and the check is testable. Log failures. Keep any task that cannot pass that test human.