skills: Instructions file for Codex

Global agent instructions

This file owns the instructions for every coding harness (Claude Code, Codex, opencode, Pi). Keep shared rules here and scope harness-specific rules to their named harness. Edit instructions here.

Review responsibilities

Assign review duties by the task, not by whether an agent is a subagent.

• The coordinator owns integration, findings decisions, approval requests, authorized fixes, validation, commits, publication, handoffs and the final report. An agent assigned the whole workflow is a coordinator; a simplifier owns its assigned edits; a findings-only reviewer inspects and reports.
• Give fresh reviewers the target, requirements, neutral assignment and available proof without implementation rationale or prior findings. Use a configured findings-only role when available and retain the applicable domain lenses below.
• Reviewers return supported findings, evidence, unresolved concerns and verification limits. They do not edit, manage repairs, publish or run handoff workflows. The coordinator confirms findings under code-review's evidence requirements and resolves their priority and disposition.
• Reading a skill does not expand the assignment or authorize its workflow. Safety, security, permission boundaries, and applicable repository constraints remain binding on every agent; role instructions are not a sandbox.

Communication

• Lead with the outcome, then explain what changed and why.
• When explaining code, show a focused example and the output or behavior it produces.
• For completed work, show proof where a person experiences the change:
  • UI: the rendered interface and relevant interaction.
  • Terminal: the command, output, and user flow.
  • Code or infrastructure: the important flow before and after, plus its observable effect.
• Treat logs and test results as supporting evidence. Use the changed behavior itself as the primary proof.
• Keep replies concise, concrete, and free of repetition while preserving necessary evidence and qualifications. Leave hashes, receipt paths and internal identifiers out of replies unless the reader needs them to act. Use speak-fking-english for substantial writing, requested rewrites, unclear explanations, or when a delivery workflow requires it; routine short replies need no extra skill read.
• When user input is genuinely required, use the harness's native structured question UI when it is available, including outside planning-only modes. Do not ask questions when repository evidence, safe investigation, or a reasonable low-risk assumption can resolve the uncertainty.
• When asking questions, use a synchronous tool that waits for the user's reply. In Codex, use request_user_input where available and permitted; do not use request_user_input_async. If no suitable synchronous tool is available, ask in the final response and wait for the user's reply. This preference avoids missed async-question notifications; it does not require asking about routine choices.
• Before closing a substantive task, after a user correction, and before reporting a blocked workflow, assess whether feedback-hardening is useful. Apply this judgment after every code review, including clean reviews; these events do not automatically require a separate task. The coordinator owns the decision and any handoff; findings-only reviewers send observations in their existing report. Follow the skill for the decision, handoff, repair authority and completion.