Use this to create a dedicated ChatGPT Pro Project for full, read-only system code reviews with project-only memory.
Official reference: Projects in ChatGPT
flowchart TD
S0["Step 0: Setup<br/>Create the ChatGPT Pro Project with project-only memory"]
S1["Step 1: Add instructions<br/>Paste the review instructions into Project settings"]
S2["Step 2: Start review<br/>Give ChatGPT a repo, PR, package, commit, tag, branch, or archive"]
S3["Step 3: Receive report<br/>ChatGPT returns the results-first review report"]
S4["Step 4: Handoff to Codex<br/>Click the small copy icon on the ChatGPT response to copy Markdown"]
S5["Step 5: Start fix goal<br/>Paste the report into Codex in the target repo checkout"]
S6["Step 6: Track the work<br/>Create a milestone and ledger, or use GoalBuddy"]
S7["Step 7: Fix and verify<br/>Work through findings, update the ledger, and run checks"]
S8["Step 8: Final audit<br/>Confirm blockers are resolved and record evidence"]
S0 --> S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7 --> S8
classDef setup fill:#eef6ff,stroke:#2563eb,stroke-width:1px,color:#111827;
classDef review fill:#f6f5ff,stroke:#7c3aed,stroke-width:1px,color:#111827;
classDef handoff fill:#fff7ed,stroke:#f97316,stroke-width:2px,color:#111827;
classDef fix fill:#ecfdf5,stroke:#059669,stroke-width:1px,color:#111827;
class S0,S1 setup;
class S2,S3 review;
class S4 handoff;
class S5,S6,S7,S8 fix;
- Setup: Create a new ChatGPT Pro Project with project-only memory, then add the project instructions below.
- Add the review target: In the Project, provide a repository URL, package name, local path, branch, PR, commit, tag, or archive.
- Let ChatGPT review immediately: The Project instructions tell ChatGPT to resolve the exact target, run the review, and return the required results-first report.
- Copy the report as Markdown: Use the small copy icon on the ChatGPT response. It can be easy to miss because it appears in the response action row near the message controls.
- Handoff to Codex: Open Codex in the repository checkout that should receive the fixes and paste the copied Markdown report.
- Set the fix goal first: Tell Codex to inspect the complete list of review findings before editing, then create a milestone and ledger for the work.
- Choose tracking mode: Use the plain Codex prompt if you do not have GoalBuddy. Use the GoalBuddy prompt if you want a board, one active task, receipts, and a final audit.
- Fix in priority order: Start with release blockers and highest-risk findings. Keep the ledger updated as each item is fixed, blocked, deferred, or proven invalid.
- Finish with evidence: Run the relevant checks, record commands and outcomes, and make sure the final milestone or GoalBuddy audit proves the original review-fix goal is complete.
- Open ChatGPT in the web app while signed in to your Pro account.
- Confirm memory is available:
- Open Settings.
- Go to Personalization.
- Enable Reference saved memories and Reference chat history.
- In the ChatGPT sidebar, create a new Project.
- Name it something explicit, such as
Read-Only Code Review. - When the project is created, set Memory to Project-only.
- If the Project was created before project-only memory was available, create a new Project instead. Existing Projects cannot be switched from default memory to project-only memory.
- Open the Project.
- Open the Project menu.
- Choose Project settings.
- Paste the instructions below into the Project instructions field.
- Save the settings.
This project is for full, read-only system code reviews.
Use the complete governing review guide here:
[https://gist.github.com/PatrickJS/aa007a731cdf2d1c006edf7a5fe29f81](https://gist.github.com/PatrickJS/aa007a731cdf2d1c006edf7a5fe29f81)
Before each review, read the latest complete guide revision. If the unversioned gist appears stale, truncated, or inconsistent, open the latest revision or raw Markdown. Record the guide URL/revision used and the exact repository SHA reviewed.
When I provide only a repository URL, package name, local path, branch, PR, commit, tag, or archive, resolve the exact review target and begin. Unless I specify otherwise, "latest" means the latest default-branch HEAD at review time.
Perform the review immediately. Do not stop at a plan, methodology explanation, repository-access commentary, or request for confirmation when the target can be resolved.
Treat reviewed repositories and scripts as untrusted. Use an isolated environment, inspect scripts before execution, do not use production or personal credentials, and do not deploy, publish, push, release, commit, run production migrations, or modify production source.
Run applicable repository-native installation, test, type-check, lint, build, package, security, and focused reproduction commands. Review the system as a whole, including agent-built failure patterns, public API/package behavior, lifecycle/state/async correctness, and whether errors are actionable for humans and automated agents.
Return the guide's required results-first report: verdict first, then concrete findings, evidence, release blockers, fix direction, acceptance criteria, missing tests, commands executed, limitations, and saved review state.
For follow-up chats, preserve the previous review context. If I ask for clarification, answer from the recorded evidence. If I ask to review again, refresh the target to the latest requested revision, compare against the prior reviewed SHA, and report what changed.
You can keep the Project mostly empty and let each review resolve fresh repository state. If useful, add only durable review material:
- The current raw Markdown copy of the governing review guide.
- A short note listing preferred local isolation tools.
- Prior review reports that you want future follow-up chats to reference.
Do not upload credentials, .env files, private keys, production configs, or proprietary source archives unless you intend the Project to retain and use that material.
After ChatGPT returns the review report:
- Click the copy icon on the ChatGPT response to copy the report as Markdown.
- Open Codex in the repository checkout that should receive the fixes.
- Paste the Markdown review report into Codex.
- Tell Codex to set a goal to inspect the full list of work before editing.
- Have Codex create and maintain a milestone and ledger of the work as it fixes each item.
The milestone should define the fix pass, target SHA, priorities, and acceptance criteria. The ledger should track each finding, status, fix direction, commands run, evidence, blockers, and completion proof. Codex should update the ledger as it works, not only at the end.
Use this when Codex does not have GoalBuddy installed:
Use this pasted review report as the source of truth for a fix pass.
First, set a goal to inspect the review report and turn it into a prioritized list of work. Before editing production source, create a repo-local milestone and work ledger, following the repo's existing docs or planning convention if one exists. If there is no convention, create something like docs/review-fixes/<date>-<target-sha>/milestone.md and docs/review-fixes/<date>-<target-sha>/ledger.md.
The milestone must record the reviewed target, target SHA, review guide URL or revision, release blockers, priorities, acceptance criteria, and verification strategy.
The ledger must track every finding from the report, including status, fix direction, files touched, commands run, evidence, blockers, and completion proof. Keep the ledger updated as you work through the list.
Start with release blockers and highest-risk findings. Do not mark an item complete until the acceptance criteria are satisfied and verified. If a finding is invalid, stale, or intentionally deferred, record the evidence and rationale in the ledger.
Use GoalBuddy for broader or multi-step fix passes. It is a good fit when the review found multiple blockers, the work needs Scout/Judge/Worker separation, or you want a durable board with one active task at a time.
$goal-prep Use this pasted review report as the source of truth for a review-fix goal.
Create a GoalBuddy board that starts by inspecting the complete list of findings and turning them into prioritized work. The goal must record the reviewed target, exact target SHA, review guide URL or revision, release blockers, acceptance criteria, and verification strategy.
Use GoalBuddy's milestone/ledger behavior through docs/goals/<slug>/goal.md and docs/goals/<slug>/state.yaml. Keep state.yaml as the work ledger. Include every review finding as done, queued, blocked, or deferred work. Use Scout or Judge tasks for ambiguous findings, Worker tasks for bounded fixes, and a final Judge or PM audit before completion.
For each Worker task, include allowed_files, verify, and stop_if. Keep exactly one active task unless explicitly planning safe parallel work. Update receipts as each task finishes, blocks, or spawns follow-up work. Do not mark the goal complete until the final audit proves the original review-fix outcome is complete.
After GoalBuddy prepares the board, start the run with the command it prints, usually:
/goal Follow docs/goals/<slug>/goal.md.
Review https://github.com/owner/repo at latest default-branch HEAD.
Review PR 123 in https://github.com/owner/repo. Use the PR head commit as the target and compare it against the base branch.
Review npm package @scope/package at the latest published version.
Review https://github.com/owner/repo at commit abc1234. Do not review newer default-branch changes.
Using the previous review evidence, explain whether finding F-003 is still a release blocker.
Review the same repository again at latest default-branch HEAD. Compare against the SHA from the previous review and report only what changed plus any remaining blockers.