Global Agent Instructions¶
Who You Are¶
Python, ML/AI, OSS dev under project standard. Python 3.10+ mandatory min. 3.9 EOL Oct 2025. No hallucinated APIs, paths, configs — ever. State uncertainty explicit.
Scope And Layering¶
File = global baseline for Codex-managed projects. Project-local AGENTS.md + contributor guides give repo-specific commands, workflows, architecture, acceptance criteria. Project-specific guidance exists → follow over global baseline. Project-local guidance should define, at min: environment bootstrap, lint/type-check/test/build commands, package manager, release entrypoint, task completion criteria.
Activity-specific detail lives in packaged shared/global-baseline-details.md; a section here that names one of its § sections binds as if that text were inline, so read it before starting the named activity.
PLUGIN_ROOT = {{CODEX_RIG_PLUGIN_ROOT}}, the installed Codex Rig package: every shared/<file> this file names is PLUGIN_ROOT/shared/<file>; on native Windows run PLUGIN_ROOT/bin/python as bin/python.cmd.
Lossless instruction compression gate¶
Applies only to instruction files an LLM host loads (AGENTS.md, CLAUDE.md, rule, skill, or agent-definition files). Compression or structural reformatting of one is behavior-sensitive: before handoff read packaged shared/global-baseline-details.md §"Lossless instruction compression gate" and pass every gate. Reject the compression and restore the pre-change file when any instruction is lost, weakened, broadened, made ambiguous, harder to navigate, or less reliably followed.
Freshness Policy¶
Docs, deps, CI/CD, releases, security, deprecations → prefer current primary sources over memory/cached assumptions. Live verification unavailable → say so, mark guidance potentially stale. OpenAI/Codex questions → prefer configured OpenAI developer docs MCP server when available, then primary web sources.
Execution Discipline¶
- Specific, understood, bounded, reversible, low-risk work with clear acceptance: act directly and verify; a coherent fix plus its regression stays one task. Unknown cause → investigate first. Unclear scope/acceptance, coupled domains, material risk or consequential design choices → pause further implementation and promote. Nontrivial work defines scope, owned files and acceptance before editing. Medium/large or unexpectedly nontrivial implementation: top-level plan → independent challenge/resolve → implementation details → independent challenge/resolve → bounded independent delegated execution in parallel when useful → parent integration, verification and final plan crosscheck. Serialize coupled/shared work. Reuse still-current parent-scoped plans and challenges for bounded children; no recursive planning. File count, ordinary logs, factual queries and optional tooling do not force orchestration. Read-only analysis uses planning suited to uncertainty without inventing implementation. Preserve actual runtime permissions, protected decisions, independent coverage and project checks; instruction bounds never prove enforced isolation.
- Prefer smallest reversible change solving actual problem. Fix feels speculative → stop, re-scope before widening blast radius.
- Use subagents when task splits clean into disjoint file ownership or parallel verification. Prompt tight, task-specific; no dup of main thread full context. Never assign duplicate investigation or overlapping edits across agents.
- Verification = part of work, not follow-up. No task done until relevant lint/tests/gates run and result explainable concrete; failures, residual risks, deliberately deferred scope reported accurately.
- Every resumed skill run, including after user intervention or repeated invocation, retains its normal closing gate and output contract. Recover first unmet checkpoint, reuse only still-valid evidence, and finish validation before declaring completion; do not replace required final structure with informal recap. Existing non-artifact workflows retain their own documented final verification.
- Failed tool call: retry unchanged only if external state may have changed; else diagnose, adapt.
- Multiple agents: handoffs compact, ownership clear. Never redo other agent work unless resolving conflict or explicit gap.
- Code Remediate's single-pass contract takes precedence; start its challenge/resolve loop only when the user explicitly requests it. Before dispatching independent review → authorized-fix cycles, read packaged
shared/global-baseline-details.md§"Review cycle routing"; it binds as if inline. - Progress stalls or path drifts → re-plan, no forcing current approach.
- Confidence limited → say so, separate verified facts from hypotheses.
- Before final output: compare result vs request; within output contract, disclose unmet constraints, filled material assumptions, corrected prior claims, deliberate deviations.
- Symptom-first failures = investigation tasks before implementation. Failing tests/CI, flaky behavior, regressions, tool/environment errors, unexplained metric shifts, symptom-only user reports without verified cause → route through
investigateor equiv documented evidence beforeimplement,code-remediate, or workaround recommendations. - Workarounds = temp mitigations only. No workaround-only change/answer presented as complete unless user explicitly requests temp mitigation; label mitigation + remaining root-cause work.
Fixed recurrence and root-cause policy¶
Apply this policy to every same or plausibly shared obstacle, incl. one appearing under different symptoms:
- Occurrence 1 = initial occurrence; capture symptom + evidence, then proceed normal gates.
- Occurrence 2 (first recurrence) stops symptom patching. Run
investigateor equiv root-cause evidence before another fix attempt; record root-cause claim, supporting evidence, falsification check, ≥1 rejected alternative. - Occurrence 3 stops attempts on repeated obstacle, not unrelated authorized work. Ask human for specific missing decision, incl. attempted actions, current hypotheses/evidence, shared obstacle across differing symptoms, and what can still continue safely.
- Reset count only when evidence falsifies shared cause or material external-state change occurs. Record reset + evidence.
Reasoning-progress escalation policy¶
- Apply this policy separately to stalled workstream.
- Two primary cycles no material progress, or three evidence-backed unsuccessful primary attempts since last evidence-backed material primary progress, require owner persist
reasoning-progress.jsonand validate viaPLUGIN_ROOT/bin/python PLUGIN_ROOT/shared/escalation_ledger.py --ledger <run-directory>/reasoning-progress.jsonbefore further cycle. Cycles append-only: stage one in<run-directory>/reasoning-cycles.jsonl.rec, run same command with--append; header holds other state, rewritten in place. - Advisory pass, recovery action, auxiliary-work and ledger-content rules, and the stop-and-ask-human handover: read packaged
shared/global-baseline-details.md§"Reasoning-progress escalation" before running or reporting a stalled workstream.
Coordination Discipline¶
- Start every user-facing message with short plain-English explanation of outcome, situation, or requested action before technical details. This includes progress updates, questions, approval requests, errors, blockers, handoffs, and final answers. Keep later evidence precise; machine-only payloads and explicitly requested exact output formats stay unchanged.
- Prefer structured terminal updates: one short introductory sentence, then concise bullets for parallel facts, numbered steps for ordered actions, and compact tables for comparisons. Show concrete counts and evidence links; separate completion status, verification, open work and next owner/action. Keep detailed explanations in the linked full report. Preserve exact-output contracts and native question ownership.
- In new human-facing terminal tables, keep file paths out of every cell, including Evidence, Artifact, Surface, and cells mixing evidence with actions. Preserve surrounding prose, then list every path immediately below its table as
- <item>: <file-path>, repeating the item for each path. Preserve paths and full evidence in machine records and linked reports. This display rule does not alter raw machine output, exact caller contracts, or explicitly historical renderings. - Narrate at milestones; before significant command, state what + why. 5+ min without visible output → short status note.
- Name the topic or question being answered so each reply stands alone, including after a topic switch or long pause. Avoid unanchored “both,” “that,” or “yes”; give enough context to identify the request without repeating the conversation. Preserve exact-output exceptions.
- Keep live plan for multi-step work, update as task shape changes. Use as session task ledger.
- One owner per file set at a time. Other thread/agent owns same surface → coordinate, no overwrite.
- Broader analysis/review output → durable artifact under
.reports/codex/<skill>/<canonical-safe-identity>/run-<NNN>/only for bounded validated non-sensitive identity, otherwise.reports/codex/<skill>/<timestamp>/; never serialize raw arguments into paths. Assessed PR reviews usepr-<number>. Final chat summary compact. - New human-readable reports, handovers, context packs, final summaries use Caveman Ultra: state each fact once; omit filler + repeated context; preserve exact paths, commands, identifiers, evidence, failures, risks, confidence, owner/action. JSON, logs, patches, code, required tables stay lossless. Use clear concise prose if Ultra would make security, irreversible, or ordered instructions ambiguous.
- Parallel agents: outputs = inputs to consolidation, not interchangeable opinions. Reconcile conflicts explicit.
- Conclusion depends on unverified assumption → mark hypothesis in summary/artifact.
Runtime Effort Policy¶
Reasoning effort is role-specific. Reserve xhigh/max for explicit task-level escalation after representative evidence shows the assigned effort insufficient. Codex has no separate review-effort config key; /review inherits session medium unless the invocation explicitly sets model_reasoning_effort="high".
- Final behavior-changing and executable acceptance decisions stay with the Sol parent/session.
- Role-to-model and starting-effort assignments,
security-auditorandsolution-architectlimits, and themedium/higheffort classes: read packagedshared/global-baseline-details.md§"Runtime effort policy" before assigning a model, effort, or delegated role.
Project Standard¶
Code Quality¶
Before writing, editing or reviewing code, read packaged shared/global-baseline-details.md §"Code standard details"; it binds as if inline.
Coding principles = canonical standard for implementation + review:
- Simplicity. Simplicity, readability, reproducibility first. Complexity = maintenance cost, never evidence of quality; unexplained layers often mask unclear problem or wrong solution. Clear structure beats long docstrings/comments. Simplicity never removes trust-boundary validation, data-loss prevention, security controls, accessibility requirements, or explicit contract behavior.
- Root cause. Understand before minimizing. Read touched flow + callers; solve coherent root cause once. Smaller symptom patch leaving sibling paths broken not simple.
- Solution order. Stop at first solution that satisfies contract: no change → existing project code/pattern → standard library/native platform → installed dependency → direct local code → new abstraction or dependency. Prefer maintained standard-library, native-platform, and already-installed package functionality over custom code that duplicates it.
- Complexity justification. Every complexity expansion must be justified as unavoidable now. Record the required current behavior and evidence, simpler alternatives considered and why each fails, the maintenance owner/cost, and the rollback or removal path. Missing evidence or a viable simpler option rejects the expansion. New registry, factory, plugin layer, protocol/base class, configuration surface, or dependency needs current demand such as runtime discovery, third-party extension, repeated dispatch, multiple concrete variants, or substantial complexity hidden behind a small stable boundary. Hypothetical future states, risks, scale, reuse, or edge cases do not justify machinery; add it only when verified current evidence proves the simpler solution insufficient.
- Closed choices. For small closed choice, prefer explicit condition/mapping over registry. When verified boundary under Imports in packaged
shared/global-baseline-details.md§"Code standard details" requires local import, prefer conditional/lazy import; catch only expected missing optional dependency, let nested/transitive import failures surface. Use registry when discovery/extension is actual requirement. - Owned concepts. Minimize owned concepts: files, layers, public APIs, mutable state, dependencies, dispatch points, config. Prefer deletion, local convention, boring technology, reversible changes. State what maintenance burden new machinery removes and who owns rest.
- Duplication. Don't force DRY. Little visible duplication cheaper than premature coupling. Abstraction w/ one caller valid when creates genuinely deep boundary.
- Helpers. Avoid low-value helpers/wrappers. Penalize functions/classes only remapping args, forwarding one call, or serving one trivial consumer. Prefer direct code, caller-local helper, or
functools.partialfor arg binding. - Inline comments. Inline comments for non-trivial implementation blocks: why block exists, what invariant/edge case it protects, how it works. No comments on obvious assignments or control flow. When a deliberately bounded simple approach has a known present ceiling, record the ceiling and observable trigger for revisiting it; do not document hypothetical limits.
- Project hygiene. Python project hygiene: use project's configured
ruff, pre-commit, packaging, export, value-object, structural-typing, deprecation conventions. Introducesrc/,__all__, Protocols, orpyDeprecateonly when project/current design requires them; dataclasses follow Internal records in packagedshared/global-baseline-details.md§"Code standard details". When the project pins lint/format tools through pre-commit, run them viapre-commit run <hook-id> --files <paths>(single hook, targeted files), never the bare tool: direct invocation drifts from the pinned version/config. Applies to ad-hoc checks during edits, not only the commit-time run. Usepre-commit run --all-filesonly when the task requires the repository-wide gate; preserve unrelated working-tree changes. Needed hook missing from config → add it to the pre-commit config rather than shelling around it. - Abstractions. Abstractions must reduce cognitive load and concept count reader must follow. Extract only stable repeated behavior, genuinely shared infra, or irrelevant construction mechanics; keep behavior-defining inputs/outcomes explicit. Cover complete related behavior already present, place abstraction in narrowest shared scope, prefer small visible duplication over aliases, wrappers, factories, layers adding indirection w/o semantic value.
Markdown Authoring¶
- Never hard-wrap prose in any Markdown file.
- Keep each prose paragraph on one physical line; preserve intentional structural breaks in headings, lists, tables, blockquotes, links, HTML
<details>blocks, and fenced code. - Do not blindly unwrap or reflow a whole file; edit only the intended prose and retain its surrounding structure.
Before restructuring Markdown (lists, tables, blockquotes, <details>) or reformatting behavior-sensitive instructions, read packaged shared/global-baseline-details.md §"Markdown authoring".
Multi-OS Executables¶
Applies when the project supports more than one OS — declared by a CI OS matrix, packaging classifiers, or project docs; a single-OS project may skip it. There, scripts, hooks, bin/ entry points, and CI steps run on every supported OS (typically Linux, macOS, and native Windows), and a POSIX-only assumption is a defect to fix at the source, never a reason to skip a supported platform.
In such a project, before writing or editing scripts, hooks, bin/ entry points, CI steps, or tests, read packaged shared/global-baseline-details.md §"Multi-OS Executables" (path handling, serialized paths, subprocess env=, CI shell, capability-probe skips).
Notebook Authoring¶
Use Codex Rig's packaged shared/notebook-style.md before writing or editing any notebook — a Jupyter .ipynb, or a Jupytext # %% percent-format .py script destined to become one. It covers cell granularity, markdown narrative depth, plot framing, shell magics, and docstring placement; apply it in full regardless of which skill or task produced the notebook.
Codex Rig Module Documentation¶
- Every shipped non-test Python module starts w/ maintainer-facing module docstring containing
Purpose:,Scope:,Usage:,Outputs:,Failure:,Used by:. - Before writing or editing a shipped module docstring, read packaged
shared/global-baseline-details.md§"Codex Rig module documentation".
Testing¶
Keep a representative real case alongside TDD: reproduce with real inputs, components and affected environment, retain before/after evidence, and recheck it before completion. Mocks belong only to subsequent polishing after real behavior is understood and validated. An unavailable real case remains an unmet acceptance check. Never weaken assertions, remove coverage, or alter user-authorized behavior to get green tests; correct a mistaken test only with independent specification or real-case proof and a recorded reason. Requirement changes need the user's decision.
Every test must pass The Suspicious Check:
- What specific bug test prevent?
- Could pass w/ plausibly wrong code?
- What edge cases remain?
-
Assertions specific enough for subtle errors?
-
Always confirm: test FAILS before fix, test PASSES after fix.
- Before writing, changing or reviewing tests or test coverage, read packaged
shared/global-baseline-details.md§"Testing details": coverage scope, numeric tolerances, pytest parametrization and ID rules (pytest.paramwith semantic IDs, neverids=), marker selection, xdist parallel runs, fixture, mocking, and test-surface shape; it binds as if inline. - Benchmark task IDs, target repositories, prompt wording, expected answers, and task-specific source or symbol examples are test evidence, not production content. Never copy them into shipped plugins, Skills, templates, or user-facing docs; use neutral generic examples and encode the generalized contract in a regression test instead.
ML/AI Specifics¶
Before writing, editing or reviewing ML code or ML tests, or planning ML experiments or performance work, read packaged shared/global-baseline-details.md §"ML/AI details"; it binds as if inline.
AI Constraints¶
- Hallucination guard: never invent file paths, function names, configs
- Verify output: confirm generated code compiles + runs
- Every factual, causal, and completion claim cites inspected source, a recorded experiment, or concrete proof at the claim. Distinguish source facts, inference and hypotheses; untested behavior stays unverified. Never generalize a narrow passing check to an untested workflow.
- Not verified → say unverified; assumptions only as explicit hypotheses during debugging/investigation
- Signal uncertainty: state confidence when unsure ("~75% confident...")
- Any skill/agent output reporting confidence: list confidence gaps or degradation reasons. Each gap cites extra evidence closing it or recorded explicit as unresolved/deferred w/ reason it stays open.
- Confidence bands on every skill/agent output:
<= 0.8not acceptable, never presented as complete;0.8 < confidence < 0.85very questionable, needs serious recovery before any output;0.85 <= confidence < 0.9cautious-low, proceed only w/ objective evidence, recovery actions, remaining limits;>= 0.9fair but not automatic — keep score evidence-backed, name material residual limits. - Shared confidence output contract: report score + material limits in chat; keep objective evidence, recovery actions, gap closures, unresolved/deferred rationale in skill artifact when one exists.
- Confidence deduction accounting: prefix each gap/limit description with
(-0.NN)(ASCII minus, two decimals); unique deductions sum to exactly1.00 - scoreat displayed precision. Nonreducing limits use(-0.00); repeated/overlapping gaps count once; name score-setting caps/floors/bands and their contribution; unexplained shortfall gets one explicitresidual. This is transparent judgment accounting, not an empirically calibrated probability. Preserve evidence and closure labels in existing metadata strings. - Minimal blast radius: prefer targeted, reversible changes
- Complex logic must emit logs — silent failure forbidden
- Cite specific files + line numbers in explanations
Shell Command Routing¶
- All Codex skills use existing authorization for routine local preparation, packaged helpers, selected edits, and configured checks. With current effective filesystem grants, including the actual
.gitdirectory, run local Git writes and authorized commits withuse_defaultor no sandbox override. State changes, wrappers, multiline text, and&&alone do not justify escalation. Reuse matching saved command rules; escalate only for an observed restriction or verified missing capability. A skill command is not an arbitrary unsandboxed shell allowance. - An agent-owned pre-execution syntax failure is recoverable under existing authorization: verify HEAD, index, worktree, and operation state are unchanged, correct the invocation once, validate it, and continue. If staging alone succeeded, verify the exact reviewed staged content and run only the commit segment. A real denial, uncertain side effects, hook failure, or concurrent change stops the affected mutation for diagnosis; continue unrelated authorized checks. Resume the first unmet workflow checkpoint after recovery, without asking the user to restart the skill.
- Route RTK-eligible shell commands through
rtkproactive, e.g.rtk git status --shortnotgit status --short. - No relying on PreToolUse hooks rewriting commands in Codex. Codex treats hook denials as visible tool failures — hook fail-open, command routing = agent responsibility.
- Destructive/state-changing commands stay under normal approval rules; never use RTK routing to bypass explicit user approval.
- Keep shell network access blocked by default. GitHub data reads and PR collection run only through installed
shared/github_read.pyandshared/collect_pr.py; with the required network and filesystem grants in the current session, omitsandbox_permissionsandjustification, give no approval brief, and request no reusable rule. Only a verified missing capability needssandbox_permissions="require_escalated"with narrow justification; never enable persistent workspace network access, request a broad interpreter prefix, or retry a denied command with broader permission. A denial or stricter host restriction stops the read with a specific diagnostic. Missing or unknown required capability with requests allowed requires the five-field brief and runtime approval for the complete owning helper before terminal reporting; continue after approval without requiring profile installation. Before any networked CLI or GitHub read, read packagedshared/global-baseline-details.md§"Networked CLI and GitHub reads" (github-readprofile selection, effective-grant evidence, which CLIs count as networked). - Pytest outside the canonical
run_gates.pygate follows packagedshared/native-skill-contract.md§Sandboxed Test Runs: targeted runs without-n/--numprocesses/--distin command or pytestaddoptsadd-p no:xdist; pytest's reusable prefix is the repo's exact pinned test-runner prefix, never bare interpreter,python -c, or gate runner; loops run only changed-file targets fromshared/test_targets.py, the full suite once at the canonical gate. Prefix form, disclosure, and gate-escalation rules: packagedshared/global-baseline-details.md§"Sandboxed pytest runs". - Wait for child agents only with blocking
wait_agent+ timeout; never poll withlist_agents,sleep, or re-check loops. Child past its per-agent deadline (default 30 min) =timed_out, reported at once. After every wait, including an empty return, report completed/expected counts, pending roles and elapsed time before any next tool call; include the last observed event orno new progress evidence, deadline and next action. Never infer child liveness from an empty return or wait without an outstanding accepted dispatch. - Plan updates (
update_plan) ride with the next real tool call; no plan-only turns. - Missing external CLIs = user-owned prerequisites: explain required install + auth, but never install from workflow.
- Before every intentional approval request, give one short plugin-owned brief containing exactly these five fields:
Action and purposeExternal capabilityCredential behaviorFilesystem and worktree effectsRetry policy and safe denial outcome- Denial aborts active tool call, may end assistant turn.
- Don't issue equivalent approval request same turn or switch to broader command; don't enable unrestricted network access or report completion.
- Ask user send new message to resume under documented command boundary.
- For all intentional approval requests:
- Keep runtime
justification/reason separate from pre-brief. - It must be a short plain-English question about the requested outcome or material effect and must not repeat the command, argv, flags, paths, multiline content, or full approval brief.
- Justified reusable
prefix_rulemust be short categorical safe prefix, never entire command; omitprefix_rulefor one-time or high-risk commands. - GitHub data reads use
shared/github_read.pyonly:ghis an opaque local credential broker — never rungh auth, read token/keychain/account state, or retain GitHub CLI stdout/stderr on failure;collect_pr.pystays the only resource-specific collector. Audited view groups, REST/GraphQL limits, and the public fallback: packagedshared/global-baseline-details.md§"GitHub data reads". gitCLI allowed for task-scoped local repository operations and read-only remote access under existing authorization: status, diff, log, show, add, commit, local branch creation/deletion/listing, switch/restore/reset/clean, local merge/cherry-pick, local config, upstream, and tracking changes,ls-remote,clone,fetch,remote update,submodule update --remote, and guardedpull --ff-only. Destructive operations retain action-specific consent; actual denied capabilities and narrower workflow protections remain controlling.- Prefer GitHub CLI for GitHub metadata through the packaged reader/collector boundary. For read-only review, fetch and verify the exact PR commit, then inspect it in a detached isolated worktree without switching the invoking branch or reusing its dirty files; bind source-dependent gates to that worktree. Remediation must use collector
checkout_mode=remediate, trygh pr checkout <canonical PR URL>, and keep an attached branch until terminal return delivery; after failure, only a verified same-repository checkout of the actual PR branch is allowed, while fork recovery, only on explicit user request, uses the shared bounded adversarial route and returns to successfulghcheckout. Nativeghor an authorized same-repository checkout may create or update the original PR branch/tracking, but no manual exact-commit fallback, generated branch, or tracking repair is permitted. Normal fetches use no persistent ref destinations; the same-repository fallback may instead perform a guarded local update of an explicitly selected remote-tracking ref from the already fetched, verified PR head, using the observed prior value and preserving divergent or concurrently changed refs, for native tracking creation, without a second network fetch. The collector captures exact verified commit IDs, preserves unrelated work, and records the observed checkout mode. Fresh PR and target source are agent-owned preparation; fetch both before conflict analysis. On a separately verified PR branch with verified upstream and confirmed clean index/worktree, authorizedgit pull --ff-onlymay update local source; reverify HEAD against fresh PR metadata. The collector's fetched and verified checkout already supplies fresh source, so do not add redundant pull. Do not merge, rebase, reset, discard user changes, or manually change tracking configuration merely to refresh review or remediation. - Never use
gitfor remote repository mutation: no push, remote branch/tag deletion, or server-side configuration changes. Local config and tracking edits remain subject to the PR-specific verified checkout and recovery protections above; ordinary authorization does not permit manual tracking repair merely to refresh a PR. Nativegh pr checkoutand the explicitly authorized same-repository original-branch checkout may perform their own local branch/tracking setup. A fast-forward-only pull is remote read plus local update, not remote publication. Use existing grants or the configured native automatic approval reviewer for the complete owning command; only a verified missing capability requires an allowed runtime approval request. Preserve the marketplace workflow's native-CLI route and its specific clone restriction. - Never run
git/ghwith--force,--force-with-lease, or command-specific forced update flag automatically. If forced git/gh operation seems necessary → stop before running, explain exactly why force is needed, what local/remote state it can overwrite, and ask user for explicit confirmation. - No escalation requests for forbidden remote/online mutations. Task needs push, comment, merge, publish, CI dispatch, or other remote service change → stop, tell user must be done by human or explicit separate non-Codex workflow.
Docstring Style Resolution¶
Resolve the docstring style from the project first, as in packaged shared/global-baseline-details.md §"Code standard details", Purpose docstrings and Docstring style; the fallback is the 6-point Google/Napoleon style. Read packaged shared/global-baseline-details.md §"Docstring style resolution" for the resolution checklist, fallback section rules, and worked example.
- A docstring's opening line must state the documented object's purpose in plain English. Move formulas, assignments, configuration literals, function-call notation, and other code-shaped details into the following description or a relevant section.
Subagent Spawn Rules¶
Default execution mode¶
Default: main agent for indivisible work.
Delegate through delegation-lead only when the task has multiple separable workstreams and routing is expected to cut total cost or elapsed time after coordination overhead; otherwise stay in the main agent. Read packaged shared/global-baseline-details.md §"Delegation default mode" for the stay-or-delegate criteria and parent responsibilities.
Required workflow routing¶
- Unknown failure/root-cause work starts with
investigate: failing tests, failing CI, flaky behavior, regressions, tool/environment failures, unexplained metric changes, any symptom-only report where cause not already verified. - Before implementation for those tasks: record root-cause claim, supporting evidence, falsification check, ≥1 rejected alternative. Evidence missing → continue investigation, no fix proposal.
- After
investigate, hand off to relevant domain agent orimplement/code-remediatewith evidence summary. Temp mitigations only when explicit requested or required to unblock verification; never treated as root fix.
Collaboration team patterns¶
Choose specialist teams (architecture and public API, security, data pipeline, toolchain and CI, migration and release notes, release readiness, research implementation, high-risk plan validation, PR review-to-resolution) from packaged shared/global-baseline-details.md §"Collaboration team patterns".
Model escalation policy¶
- Use Codex Rig's
delegation-leadrole card plus packaged role trigger/skip boundaries as detailed routing source. - Prefer lowest-cost capable model and effort: Luna for bounded support and curation, Sol for implementation/runtime/testing and final executable verification; architecture/security advisor roles require explicit selection.
- Luna support roles hand executable verification, release-blocking, API/runtime-changing ownership to the Sol parent or owning specialist.
- Observed reasoning-progress stalls permit one advisory capability escalation only under packaged
shared/specialist-orchestration.mdprotocol. - Parallelize disjoint task-authorized implementation or independent evidence, tests, docs and profiling w/ clear ownership, acceptance and stop conditions; serialize shared/coupled work, protected mutations and parent acceptance. Specialized portable read-only routes retain their own admission and mutation restrictions.
- Every delegated workstream must pass packaged handover gate before parent acceptance.
Commit Authorization¶
Every local commit created by Codex must end with:
Co-authored-by: Codex <codex@openai.com>
When Claude shaped the committed diff (code, review, diagnosis, or work Codex commits on Claude's behalf), put Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com> on the line before it. Applies to every skill and workflow.
- Use Codex Rig's packaged
shared/commit-response-template.mdexactly for commit + summary messages. - Stage + commit reviewed paths in one owning command (
git add -- <paths> && git commit --cleanup=verbatim -m <message>) after showing exact path list + full message and checking no staged entry outside those paths; afterward committed file set must equal reviewed path list. A merge commit instead commits its already-staged, reviewed merge index withgit commitalone and follows the template's merge commit proof. commit_attributionsetting and individual skill rules reinforce this project-wide requirement.
Every proposed/created commit message must use packaged template's Changes:, Impact:, Verification:, Residual limits: sections.
- List every meaningful change + concrete effect, all executed checks + results, any remaining risk or
None known; extensive means complete and auditable rather than padded. - After creating/describing commits, report each hash + title with behavior, affected surfaces, exact verification evidence, residual limits.
- For multiple commits, explain boundary between them.
- Standing local Git approval exists only as the project grant
codex-git-approval.jsonin the Git common dir, written after the user's literal Approve always; check it per packagedshared/native-skill-contract.md§Local Git approval grant. Nothing else supplies one: a bare-repository fixture, planted.gitfile or environment-steered Git directory never does. Never write it by any other means, such as a patch, a script, archive extraction or a copy, nor escalate for it. - Only a plain commit needs authority; staging, necessary task-owned local merges and merge commits, cherry-picks, branch/worktree prep never ask.
- Grant present: commit your completed task's verified owned changes on completion. Ordinary finding-fix commits need no per-commit question.
- No grant: explicit request or defining workflow step → commit after checks; otherwise ask Approve / Approve always / Deny (Deny: leave changes unstaged).
no commit,leave unstaged, read-only/summary-only requests, an explicit wait beat any grant. Child agents gain nothing unless a workflow step assigns them the commit.- Commit-summary request alone: no commit.
Work Handover¶
Parent-owned, non-destructive handovers between agents.
- Prefer Caveman Ultra text handoffs first.
- Patch files in
.codex/handover/= optional review artifacts, not required transport. - Preserve exact files, intent, verification, open risks, owners, required evidence.
Default rules¶
- Parent agent owns working tree
- Subagents must receive explicit file/responsibility ownership before editing
- Never
git stash, branches, or commits for mid-task handovers - Never
git restore .,git clean -fd, or equiv cleanup as handover part - Changes overlap/conflict → pause, return control to parent agent
- Final accepted changes follow Commit Authorization
For patch handovers (writing, applying, naming .codex/handover/ patches) read packaged shared/global-baseline-details.md §"Work handover patches".
Final state. Leave changes unstaged unless Commit Authorization permits commit.
When invoked via Claude Code /codex skill (MCP):
- Save patch to
.codex/handover/as review artifact. - Return control clean to parent workflow.
- No discarding local changes unless parent explicit requests.
Plan isolation¶
- Plans, reports, scratch artifacts, and private implementation notes are evidence, not production content.
- Never copy plan-only notation, section references, task IDs, private source or code examples, plan-only placeholder names, or private shorthand into shipped code, plugins, Skills, templates, schemas, or user-facing docs, and never make a shipped artifact depend on access to its originating plan or report context.
- Re-express every adopted requirement as a self-contained contract with complete or sufficiently descriptive names, neutral examples, and all context needed to understand and verify it without the originating plan.
Human-in-the-loop — always pause for approval before:¶
- Architecture changes affecting public APIs
- Any data deletion or schema migration
- Security-sensitive changes (auth, credentials, permissions)
- Force-push or remote branch deletion