OpenAI Codex tutorial for reliable repository work

Act as a work-surface selector. Do not change anything.

Task: [one real task]
Source of truth: [repo / files / connected knowledge / web]
Finished artifact: [diff / report / decision / other]
Permission boundary: [read-only / draft only / approved write]

Return exactly:
1. Recommended surface: Chat, ChatGPT Work or Codex
2. Why this source and artifact require it
3. First safe action
4. Files, tools or sources to inspect
5. Proof that would let a reviewer accept the result
6. One assumption that could change the recommendation

Turn this messy request into a task contract. Do not edit files.

Raw request: [paste notes]
Source of truth: [files, issue, docs or URL]
What must not change: [non-goals]
Human who accepts the result: [name or role]

Return a one-screen contract with:
- outcome and user-facing effect
- in-scope and out-of-scope files or systems
- required evidence
- approval points
- smallest reversible first move
- assumptions that need confirmation
- a stop condition

Run a read-only repository reconnaissance for [task]. Do not edit, install, send, deploy or use an alternate tool to bypass a missing permission.

Inspect: repository instructions, git status, relevant route or module, existing tests and the nearest source of truth.

Return:
- current behavior, with file paths
- the narrowest safe change
- exact files that would change
- checks that prove behavior, not just compilation
- risks, missing evidence and explicit approval points
- one recommended next command
Stop after the plan.

Build a context map for [task]. Do not edit files.

Return a four-row authority table:
1. required rule or fact
2. authoritative source and exact location
3. owner
4. freshness trigger or conflict-resolution rule

Then identify:
- one rule that must be checked in
- one decision that needs a reviewed record
- one optional memory that must not become authority
- one large-output risk and how to bound it

Optional local memories: recall only; compare them with the checked-in rule and reviewed decision record before relying on them.

Finish with the smallest repair, if any.

Plan issue [number] without editing files.

Outcome: [one sentence]
Baseline: [current behavior or URL]
Non-goals: [what must remain untouched]

Create a dependency-ordered plan. For each step give:
- exact files
- observable behavior change
- deterministic or browser proof
- rollback path
- approval needed before the step

End with a one-line diff budget and the first step that is safe to execute.

Design a reusable skill only if this workflow has succeeded manually at least once.

Workflow: [repeated job]
Trigger phrases: [what users actually ask]
Inputs: [sources and constraints]
Output: [observable artifact]
Authority boundary: [what it may prepare versus what needs approval]

First find an existing owner. If none fits, draft a compact SKILL.md with: purpose, trigger, inputs, ordered steps, verification, failure behavior and stop condition. Include one realistic regression case. Do not create a duplicate or a skill for generic advice.

Create an MCP preflight for [goal]. Do not call tools yet.

For every proposed tool, return a row with:
- data it can read
- state it can change
- minimum permission needed
- evidence it returns
- failure behavior
- whether a human must approve immediately before use

Choose the smallest read-only tool set first. Name the exact action that must remain blocked.

Delegate a read-only verification slice.

Role: [researcher / verifier]
Question: [one answerable question]
Scope: [exact files, URLs or sources]
Must not do: [edits, sends, deployments, external writes]
Return format: finding, evidence, exact location, confidence and unresolved gap.

Stop when evidence is incomplete. Do not make product decisions or inspect outside the stated scope.

Design a durable monitor for [goal]. Default to read-only monitoring. Do not send messages, merge, publish or change external state unless the exact approval is present.

Source of truth: [issue, PR, dashboard or URL]
Verifier: [test, status field or human review]
Cadence: [frequency]
Material change: [specific condition]

Return a monitor contract with: what to check, current baseline, proof of progress, update rule, stop condition, owner, escalation path and the exact approval needed for a proposed fix.

Act as a release verifier for [change]. Do not modify files.

Acceptance criteria: [paste]
Expected rendered marker: [heading, control or metadata]
Relevant checks: [commands]

Return a release receipt:
- source diff reviewed
- each command and result
- rendered behavior evidence
- asset or API substance checks where relevant
- failed or unavailable proof
- release recommendation: accept, revise or hold
Never treat HTTP 200 alone as proof.

Pilot goal: [goal]
Approved users/groups: [groups]
Approved repositories: [repos]
Allowed apps and MCP tools: [tools]
Read/write boundary: [boundary]
The agent must never: [prohibited actions]
Human approval points: [points]
Who accepts a source-of-record, production or external state change: [role]
Exception and fallback: [route]
Access expiry or revocation: [rule]
Audit evidence: [evidence]
Data and secret handling: [policy]
Rollback/exit criteria: [criteria]
Owner: [owner]

I am the accountable non-developer for [outcome]. Start with a plain-language plan and do not edit until I approve.

Explain:
1. what changes for the user
2. the smallest files or systems involved
3. what could go wrong
4. the evidence I will see before accepting it
5. the one decision only I need to make now

After implementation, return a before-and-after summary, changed files, proof, remaining uncertainty and the safe rollback.

Build a first-run context pack. Do not take action yet.

Role: [founder / consultant / chief of staff]
Recurring workflow: [one repeated job]
Approved sources: [specific systems and files]
Agent may do: [read, organize, draft]
Human must approve: [commitments, external messages, assignments]

Return:
- a one-page context pack
- source authority and owner for each field
- an explicit non-goal
- the first safe run
- the proof required before the human accepts the result
- a review date for stale context

Prepare a handoff that a new operator can continue without this chat.

Use this exact structure:
- state changed or confirmed
- source-of-record links
- validation performed and result
- unresolved question or constraint
- owner and next action
- review date or trigger
- changed files and visible behavior
- rollback or correction route
- durable instruction to update, if the same failure could recur

If any field is unknown, write UNKNOWN and name the evidence needed.