Codex and consult runbook | Proxi GUIDE Manual

Status: Operating guide, v0.1
Last updated: 2026-07-11

Recommended project type#

Use a local project in the ChatGPT desktop app. A local project gives Work and Codex direct access to the files in this folder and lets each new task share the same source-of-truth files without sharing an ever-growing transcript.

A web-only ChatGPT project can hold uploaded copies, but it does not directly edit the folder on the computer. Use that only when browser/mobile access is more important than maintaining one local source of truth.

Windows setup#

Download and extract the complete ProxI_GUIDE_SOP folder to a stable location, for example:

C:\Users\<you>\Documents\ProxI_GUIDE_SOP
Open the ChatGPT desktop app and sign in.
Choose Add new project or press Ctrl+O.
Select the extracted ProxI_GUIDE_SOP folder itself, not its parent folder and not an individual Markdown file.
Start a task inside that local project and select Work for document production or Codex for file-centric editing and review. Both can use the local project files.
Beneath the composer, choose GPT-5.6 Sol. Use Medium or High for ordinary drafting; choose Ultra for a major review that can be split among specialist subagents.

The root AGENTS.md is automatically loaded by Codex-compatible tasks. It contains the project’s non-negotiable authority boundary, source hierarchy, context packet, and multi-agent rules.

Optional but strongly recommended version control#

Install Git if it is not already available. From the project folder, create the baseline:

git init
git add .
git commit -m "Initial ProxI GUIDE SOP baseline v0.1"

Git gives the app a clean diff, change history, and a safe way to compare agent edits. It also enables isolated worktrees when separate tasks truly need independent file changes.

First task: verify the project contract#

Use Medium or High rather than Ultra:

Read AGENTS.md and README.md. Then read the project charter, architecture principles, roles and escalation document, and decision log. Do not edit anything. Return: (1) the non-negotiable authority boundary, (2) the source-of-truth hierarchy, (3) settled versus open decisions, (4) which files you would load for a medication-management review, and (5) any contradiction you see in the governing documents.

Do not begin substantive drafting until this verification is correct.

Recommended task structure#

Create a separate task for each distinct outcome. Suggested task names:

Medication SOP — adversarial review
Care Coordination — edge cases and closure
Care Plan — state machine and consent
CMS GUIDE — source verification
Interoperability — eRx and medication data gaps
Staffing model — exception minutes and cost
Integrated SOP v0.2 — controlled merge

The tasks share the folder, but each retains its own transcript. Durable decisions belong in the files, especially 08_Decision_Log.md, rather than only in a task conversation.

Ultra prompt for a pillar review#

Replace the bracketed target:

Review [target SOP filename] as a controlled multi-agent workflow. First read AGENTS.md, README.md, 01_Architecture_and_Control_Principles.md, 02_Roles_and_Escalation.md, the target SOP, 06_Edge_Case_Register.md, 08_Decision_Log.md, 09_Source_Register.md, and 10_Agent_Review_Protocol.md.

Delegate independent read-only reviews to specialist subagents for: (1) CMS/GUIDE compliance and audit evidence, (2) clinical safety, (3) workflow/state-machine and deterministic-rule integrity, (4) privacy/interoperability/data provenance, and (5) operations, staffing, and adversarial edge cases. Add a pharmacy reviewer for medication management.

Require every finding to identify the affected section or rule ID, severity, missing edge case, unsafe automation or unnecessary human work, supporting primary source where applicable, proposed discrete edit, and test case. Wait for all reviews, reconcile disagreements, and distinguish requirements from design recommendations.

Do not edit source-of-truth files during the review. Write the consolidated findings to reviews/[target]-review-v0.1.md. Stop for my approval before integrating changes.

This prompt intentionally makes the first Ultra pass read-only. After approval, use a separate integration task so one main agent controls edits.

Integration prompt#

Use High or Max; Ultra is usually unnecessary because integration should be serialized:

Read the approved review report and the governing project documents. Propose an integration plan listing every source file to change, rule IDs affected, decision-log entries required, and tests to add. Identify any finding that conflicts with a SETTLED decision or lacks sufficient evidence. Do not edit until I approve the plan.

After approval:

Implement only the approved integration plan. Preserve stable IDs. Update the target SOP, edge-case register, rule catalog, decision log, and project index wherever applicable. Run a cross-file contradiction check and return a concise change report with unresolved blockers and required human sign-offs.

When to use each intelligence level#

Setting	Use in this project	Review
Medium	Focused drafting, formatting, extraction, and routine file updates
High / Extra High	One difficult SOP section, rule design, source reconciliation, or controlled integration
Max	Deep single-agent reasoning where parallel review would add little
Ultra	Broad pillar red-team, multi-source research, or independent specialist reviews that can run in parallel

Ultra is not a substitute for project structure. Its agents still need bounded roles, explicit source packets, a required output schema, and a single integrator.