Prompts

Prompts you can copy

A prompt for every phase, ready to paste. Each one names its goal, its fence, its check and its report.

Why they look like this Prompts for your system

How to use these

Each box on this page is one task card. A task card is a prompt with the same named parts every time. You fill in the blanks, paste it, and read the report.

Find the card for the phase you are in.
Fill in every part in <ANGLE_BRACKETS>. Leave none blank.
Look at the job type under the card's title. Set the model and effort for that job with /model and /effort.
Start a new session, or run /clear. Paste one card. Use one card per session.
Read the report. Look at the first word. Then look for the proof.

The model and effort for each job type are in one table on Claude Setup. It has a column for Max 20x (now called Ultra) and one for Max 5x (now called Max). This page names job types only, so the two pages cannot disagree.

Use the same card for the same kind of job each time. Keep the same check, the same model and the same effort. That keeps results steady from day to day.

These are the general cards. Your platform guide has cards like these with the tools for your system filled in.

The parts of every card

Part	What it tells Claude	Why it is there
GOAL	One outcome, in one sentence.	Anthropic's docs say Claude "stops when the work looks done". One clear outcome gives it one place to stop.
READ FIRST	The files, addresses and docs to open.	You give paths, not pasted pages. Chris Lewis has a rule: "don't provide unasked-for context."
FENCE	The only paths Claude may edit.	It stops side trips. No extra features, tools or clean-ups.
CHECK	The command to run, and the exact result that means done.	The same docs say to give Claude "something it can run that comes back pass or fail."
BUDGET	When to stop trying.	Most wins come early. In one test, nearly half the matches came on the first try.
IF BLOCKED	Stop and tell you. Do not work around it.	A work-around hides the real problem. Anthropic's prompting guide uses the words "inform me rather than working around them."
OTHER PROBLEMS	Write side finds in `notes/parking-lot.md`.	Claude writes them down and does not act. You pick later.
REPORT	One word first: `DONE`, `PARTIAL` or `BLOCKED`. Then proof.	The docs say to ask for "the command it ran and its output."

Some cards add one more part, such as STEPS or RULES. The core parts stay.

If you shorten a card

You can cut words. Do not cut parts. This is the shortest card that still does its job.

The shortest card

GOAL: <ONE OUTCOME>.
READ FIRST: <FILES>.
FENCE: Edit only <PATHS>.
CHECK: Run <CHECK_COMMAND>. Done means <EXACT RESULT>.
BUDGET: Stop after <N> failed tries.
IF BLOCKED: Stop and tell me. Do not work around it.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: DONE, PARTIAL or BLOCKED. Then paste the check output.

What goes in the blanks

Blank	What to put there
`<GAME>`	The game's name and its exact version.
`<HASH>`	The hash of your game file. A hash is a short fingerprint of a file.
`<SYSTEM>`	The console or computer the game came out on.
`<CHECK_COMMAND>`	The one command that runs your check. It prints pass or fail.
`<DIFF_COMMAND>`	The command that scores one function against the original.
`<GOLDEN_RUN_COMMAND>`	The command for a golden run. The game starts with no person and must reach a known point.
`<LEDGER>`	The file that lists every function with a status. A ledger is a record you keep up to date.
`<N>`	A number you pick.
Blanks that end in `_PATH` or `_FOLDER`	A real path on your PC. Check that it exists.

Claude may say no

Since 2026-10-27, Claude Code has a rule against building a recreation of a specific existing game. It was written about remaking games from scratch. No source says how it applies to decomp work. Game Developer reported the rule.

These cards do not try to get around that rule. The scope card and the blocked card ask Claude to say plainly what it will not do. If Claude says no, take it as a real answer. Do not reword a card to slip past it. Claude Setup has the details.

Claude may switch models

Safety checks can move a session to an older model when content looks like security work. The session then stays on that model. Run /model to see which model you are on and to switch back. Do this before you judge an odd result. Anthropic's model docs describe the switch.

Scope and feasibility

Run these before you make a repo. Feasibility means: can this be done at all? The choice you make here shapes months of work.

Scope and feasibility check

Use this first, before any repo exists. It asks what can be done, what exists already, and what Claude cannot or will not do.

Job type: scope

Prompt for Claude

GOAL: Tell me if <GAME> for <SYSTEM> can be done, and how. My goal is <A: PLAYABLE ON PC | B: FULL DECOMP FOR PORTING>. End with a draft Scope Contract.
READ FIRST: The game file at <GAME_FILE_PATH>, hash <HASH>. Do not copy it. Also <MY_LINKS_OR_NOTES>.
FENCE: Research only. Write one file: SCOPE.draft.md. No repo, no installs, no code.
DO:
  1) List what exists: decomps, recomps, ports, symbol files, debug builds, sister games. Give URLs.
  2) Pick one technique and say why. Name the check that will prove each task.
  3) List what cannot be done, or cannot be checked, with what we have.
  4) If there is a part you will not or cannot help with, say so now in plain words. Name the part and the reason. Do not swap in a smaller job quietly.
CHECK: Every claim has a URL or a file path next to it. Mark the rest NOT VERIFIED.
BUDGET: One session. Stop when the draft is written.
IF BLOCKED: Stop. Tell me what you could not find and what you need from me.
OTHER PROBLEMS: List them at the end of the draft. Do not act on them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Your verdict: CAN BE DONE, CAN BE DONE WITH LIMITS, or CANNOT BE DONE. 3) The proof: links and paths. 4) The draft: goal, version and hash, technique, first milestone and its check, out of scope, files never to edit. 5) Questions for me.

A good answer: One word first. Then a list of what exists, each with a link. Then a draft with a first milestone and its check. It names at least one limit. A bad answer has no links and no limits.

Read the draft and change what you want. Then save it as SCOPE.md yourself. Only you change that file. The line about NOT VERIFIED has a reason. Piotr Migdal put it this way: "Hallucinations are worse than a lack of an answer."

Prior-work search

Use this when the first report found little prior work. Prior work is anything that already exists for your game.

Job type: scope

Prompt for Claude

GOAL: Find all prior work for <GAME> on <SYSTEM>, and for games on the same engine.
READ FIRST: SCOPE.md or SCOPE.draft.md, if one exists. The game's hash is <HASH>.
FENCE: Research only. Write one file: notes/prior-work.md. No code. No downloads.
LOOK FOR:
  - a decomp or recomp of this game, or a PC port
  - symbol or map files, and debug or demo builds
  - sister games from the same studio or engine
  - tools made for this system
  - the compiler and its version
  - each project's licence and its rule on AI-made code
CHECK: Each row has a name, a URL, what it gives us, its licence and the date you read it. Open each page yourself. Mark a row NOT VERIFIED if you could not open it.
BUDGET: Stop after <N> searches in a row that find nothing new.
IF BLOCKED: Stop. Tell me which searches failed and what you need from me.
OTHER PROBLEMS: List them at the end of notes/prior-work.md. Do not act on them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The table. 3) The one find that saves the most work, and why. 4) What you looked for and did not find.

A good answer: A table where each row has a link and a date. A plain list of what was not found. No row without a source.

Some projects do not take AI-made code. N64Recomp is one of them. HarbourMasters takes it only with limits. That is why the card asks for each project's rule.

Setup

Setup ends when one command builds and one command checks. Then you prove that the check can fail.

Set up the repo and the one check command

Use this once you have approved SCOPE.md. It makes the repo, the scripts and the one check command.

Job type: setup

Prompt for Claude

GOAL: Set up the repo for <GAME> so one command builds and one command checks. The build may be empty.
READ FIRST: SCOPE.md. Also notes/prior-work.md, if it exists.
FENCE: Work only inside <REPO_FOLDER>. Game files stay in <GAME_FOLDER>, outside the repo or in an ignored folder. Install only these tools: <TOOLS>. Ask before you add any other tool.
MAKE:
  1) An extract script. It reads the game file and stops if the hash is not <HASH>.
  2) A build script.
  3) One check command: <CHECK_COMMAND>. It prints PASS or FAIL and exits with 0 only on a pass. On a fail it also prints the text in tools/check-failed.txt.
  4) CLAUDE.md, PROGRESS.md, notes/parking-lot.md and notes/findings.md.
  5) A .gitignore that keeps game data out of git.
  6) A file that lists each tool and its exact version.
CHECK: From a clean checkout, run the build, then <CHECK_COMMAND>. Done means both run with no errors.
BUDGET: Stop after 3 failed tries at the same step.
IF BLOCKED: Stop. Do not work around it. Tell me the step, the error text and what you need from me.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Both outputs, pasted. 3) Files made. 4) Tool versions. 5) What is left.

A good answer: Two pasted outputs, one from the build and one from the check. A list of tool versions. No tools you did not name.

Prove the check works

Use this right after setup, in a fresh session. Use it again after first light, when there is real code to break.

Job type: verify

Prompt for Claude

GOAL: Prove that <CHECK_COMMAND> can fail. A check that always passes proves nothing.
READ FIRST: The check script and the build script. Read them. Do not change them.
FENCE: Edit only <ONE_SOURCE_FILE>, and only for this test. Put it back at the end.
STEPS:
  1) Run <CHECK_COMMAND> on the clean tree. Save the output.
  2) Make one small change in <ONE_SOURCE_FILE> that must change the result.
  3) Run the check again. It must print FAIL and exit with a code that is not 0.
  4) Put the file back with git. Run the check again. It must pass.
  5) Say if the check rebuilds from scratch or can reuse old build files.
CHECK: Done means you saw pass, then fail, then pass, and `git status` shows no changes.
BUDGET: One round. Do not try to repair the check.
IF BLOCKED: Stop. If the check passed when it should have failed, that is the finding. Report it. Do not fix it.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste all three outputs with their exit codes. 3) Can I trust this check? Yes or no, and why. 4) What is left.

A good answer: Three pasted outputs in order: pass, fail, pass. If the middle one says pass, your check is broken. Fix the check before any other work.

A check can lie. Old build files can make it print OK when the code is broken. One real project tells Claude to prove the check "by breaking a source file and checking it fails."

Map the binary

This phase turns the game file into a list. Each function gets a row. Later cards take their work from that list.

Map the binary into a function ledger

Use this after setup. Later cards take their units from this file.

Job type: analyze

Prompt for Claude

GOAL: Write the function ledger for <GAME>: one row for each function in the code.
READ FIRST: SCOPE.md. The extracted code in <EXTRACTED_FOLDER>. Output from <TOOLS>, if it is already there.
HOW: Use a subagent to read big listings and report back short. Give it paths, not pasted text.
FENCE: Write only <LEDGER>, notes/findings.md and one small script that checks the ledger. Do not edit code or the build.
COLUMNS: address, name, size, section, kind (game, library or unknown), status (todo), notes. Leave the name blank when you do not know it. Do not make names up.
CHECK: Run the ledger script. Done means no two rows overlap, every byte of the code section is in a row or in a listed gap, and the sizes add up to the section size.
BUDGET: Stop after 3 failed tries at the check, or 2 passes in a row that add no rows.
IF BLOCKED: Stop. Tell me which address range you cannot split, and why.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the script output. 3) Counts: functions, bytes, unknown ranges. 4) Ranges where a function edge is a guess. 5) What is left.

A good answer: Counts, not a story. A list of the address ranges where the edge is a guess. Blank names where Claude does not know.

Function edges are hard to get right. On one project, the first tool found 93 functions. A second tool added about 300. The final count was 663. The same author found that Claude could only fail or cheat on a function cut at the wrong place.

Identify library and middleware code

Use this before any matching, so no one decompiles library code by hand. Library code came with the console's kit, and middleware is code the studio bought in.

Job type: analyze

Prompt for Claude

GOAL: Mark each function in <LEDGER> that comes from an SDK, a library or middleware.
READ FIRST: <LEDGER>. notes/prior-work.md. The text strings in the game file. Known library sources for this system: <LIBRARY_SOURCES_OR_SIGNATURES>.
FENCE: Edit only the kind and notes columns of <LEDGER>, and notes/findings.md. Do not decompile anything. Do not rename game functions.
PROOF: Each library row needs one of these in its notes. No proof means the row stays unknown.
  - a signature match
  - a version string
  - a known symbol
  - a byte match to a library file
CHECK: Run the ledger script. Done means it passes and every library row has a proof.
BUDGET: Stop after <N> functions in a row with no new hit.
IF BLOCKED: Stop. Tell me which library you suspect but cannot prove, and what would prove it.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the script output. 3) Counts and bytes for each library. 4) Rows you are not sure about. 5) What is left.

A good answer: Each library row names its proof. Rows with no proof stay unknown. The counts add up to the ledger total.

First light

First light is the smallest proof that the whole chain works. Path A gets one frame on screen. Path B gets one file to match.

Path A uses two words you should know. A recompiler is a tool that turns the game's machine code into C. The runtime is your code that stands in for the console.

First light for Path A: boot to the first frame

Use this for Path A, once the map exists. It runs the recompiler, builds, and boots the game to one frame.

Job type: runtime

Prompt for Claude

GOAL: Boot <GAME> to its first frame on this PC. Nothing more.
READ FIRST: SCOPE.md. <LEDGER>. The docs for <RECOMPILER> at <DOCS_PATH>.
FENCE: Edit only <RECOMPILER_CONFIG> and <RUNTIME_FOLDER>. Never edit the machine-made code in <GENERATED_FOLDER> by hand. If it is wrong, fix the config or the tool input and make it again.
STEPS:
  1) Show me a short plan. Wait for my OK.
  2) Run the recompiler over the whole game. Then build.
  3) A system call you have not written yet must log its name and stop the game. No silent stubs.
  4) Run the game. Write only the calls that block the first frame.
CHECK: Run <GOLDEN_RUN_COMMAND>. Done means the game starts with no person, a window opens, and a screenshot of the first frame is saved within <SECONDS> seconds.
BUDGET: Stop after 5 failed tries at the same error, or 30 minutes with no progress.
IF BLOCKED: Stop. Do not fake the frame. Tell me the last log line, what you tried and what you need from me.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the check output and the screenshot path. 3) Files changed. 4) Calls still not written. 5) New parking-lot items.

A good answer: A screenshot path and the log line that proves the frame. A list of calls that still stop the game. Not "it should boot now".

One real project puts it this way: "The pixels appear on screen, or the phase is not done."

First light for Path B: one file matching end to end

Use this for Path B, on a small file with few functions. It is one unit, but it proves the compiler, the flags and the build at once.

Job type: hard

Prompt for Claude

GOAL: Make one small file, <FILE>, match the original from end to end. One file only.
READ FIRST: SCOPE.md. The row for <FILE> in <LEDGER>. Its assembly at <ASM_PATH>. One or two matched files from a sister project, if notes/prior-work.md lists one.
FENCE: Edit only <SRC_PATH> and the build settings for this one file. The original assembly, the expected hashes and the check script are read-only.
RULES:
  - Use the original compiler: <COMPILER_AND_VERSION>.
  - No inline assembly. No hand-placed bytes. No change to the compiler.
  - Write the C a person would write.
CHECK: Run <CHECK_COMMAND>. Done means the whole build passes and <FILE> is built from your C, not from the original assembly.
BUDGET: Stop after 10 tries in a row with no gain in the match score.
IF BLOCKED: Stop. Tell me the best score, the lines that still differ, what you tried, and if the cause looks like the compiler, its flags or the code.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the check output. 3) Files changed. 4) The compiler and flags that worked. 5) What is left.

A good answer: The check output shows a pass for the whole build. The report names the compiler and the flags. If it stopped early, it shows the lines that still differ.

The unit loop

This is the loop you will run most. One unit, one session, one check. Then clear the chat and start the next one.

For a bug, Anthropic's advice is to "name the file, describe the symptom, and say what 'fixed' looks like up front". The three Path A cards below do that.

Match one function (Path B)

Use this for each function in Path B. The score for one function is only a hint, and the full check is the verdict.

Job type: bulk

Prompt for Claude

GOAL: Make <FUNCTION> in <FILE> match the original 100%. One function, then stop.
READ FIRST: The target assembly at <ASM_PATH>. The C file at <SRC_PATH>. Up to 5 matched functions most like this one: <SIMILAR_FUNCTIONS>. The quirks file <QUIRKS_FILE>.
FENCE: Edit only <SRC_PATH>, a header if this function needs a new type, and this function's row in <LEDGER>. Save each try as a new file in <SCRATCH_FOLDER>.
RULES:
  - Change one thing per try.
  - No inline assembly, register pins, hand-placed bytes or pragma tricks.
  - Do not touch the expected hash, the check script or the original assembly.
  - Write the C a person would have written.
CHECK: Run <DIFF_COMMAND> for the score. Then run <CHECK_COMMAND> for the verdict. Done means the full check passes. A 100% score on the function alone is not done.
BUDGET: Stop after 5 tries.
IF BLOCKED: Stop. Do not start another function. Tell me the best score, the file that holds it, the exact instructions that still differ, and your best idea why.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the check output. 3) Files changed. 4) The ledger status you set: matched, partial or stuck. 5) New parking-lot items.

A good answer: DONE with the full check pasted. Or PARTIAL with the best score, the file that holds it and the lines that differ. Then it stops. It does not start the next function.

A unit that stops at the budget moves to a hard job. The limit of 5 tries comes from a real project's skill file. That file tells Claude: "99% is failure". The quirks file is one shared file of compiler habits that every worker reads.

The rules ban tricks that force a match without real C. Inline assembly is one of them. It means machine instructions typed straight into the C file.

Fix one crash (Path A)

Use this for one crash in Path A. The card makes Claude prove the cause before it fixes anything.

Job type: debug

Prompt for Claude

GOAL: Fix this one crash: <WHAT_HAPPENS> at <WHERE>. Fixed means the game gets past <POINT> with no crash.
READ FIRST: The crash log at <LOG_PATH>. The code at <ADDRESS_OR_FILE>. The dead ends listed in notes/findings.md.
FENCE: Edit only <RUNTIME_PATHS>. Never edit machine-made code by hand. If it is wrong, fix the tool input or config and make the code again.
ORDER:
  1) Make the crash happen with <REPRO_COMMAND>.
  2) Find the cause. Prove it with a log line, a trace or an address.
  3) Only then make the smallest fix.
CHECK: Run <GOLDEN_RUN_COMMAND>. Done means the run gets past <POINT> and every older golden run still passes.
BUDGET: Stop after 3 fixes that fail, or 30 minutes with no new fact.
IF BLOCKED: Stop. Do not hide the crash with a stub, a skip or a caught error. Tell me what you proved, what you tried and what you need from me.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The cause in one sentence, with its proof. 3) Paste the check output. 4) Files changed. 5) What is left.

A good answer: The cause in one sentence, with a log line or a trace. Then the check output. No fix that only hides the crash.

Fix one graphics or sound bug (Path A)

Use this for one picture or sound bug in Path A. You need a reference capture first: a saved picture or recording from the real game.

Job type: runtime

Prompt for Claude

GOAL: Fix this one bug: <WHAT_LOOKS_OR_SOUNDS_WRONG> at <SCENE>. Fixed means our output matches the reference.
READ FIRST: The reference capture at <REFERENCE_PATH>, from the real game or a trusted emulator. Our capture at <OUR_CAPTURE_PATH>. The code for <FEATURE> in <RUNTIME_PATHS>.
FENCE: Edit only <RUNTIME_PATHS>. No fix that works for this one scene only. No edits to machine-made code.
ORDER:
  1) Replay the same inputs with <REPLAY_COMMAND>.
  2) Compare with <COMPARE_COMMAND>. Do not judge by eye or ear.
  3) Find the first frame or sound sample that differs.
  4) Prove the cause. Only then fix it.
CHECK: Run <COMPARE_COMMAND>. Done means the difference is at or under <LIMIT> and every older golden run still passes.
BUDGET: Stop after 3 fixes that fail, or 30 minutes with no gain.
IF BLOCKED: Stop. Tell me the first point that differs, what you proved and what you need from me.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the compare output from before and after. 3) The cause, with proof. 4) Files changed. 5) What is left.

A good answer: Two compare outputs, one from before and one from after. The first frame that differed. A cause with proof.

Claude must compare with a tool, not by eye. Piotr Migdal found that models "were very eager to say that something is the same". A pixel compare fixed that for him.

The sources we read compare pictures and traces. None of them shows a sound check. Expect more PARTIAL reports on sound.

Implement one missing system call (Path A)

Use this when the game stops at a call your runtime does not have. A system call is a request the game makes to the console's own software.

Job type: runtime

Prompt for Claude

GOAL: Write one system call: <CALL_NAME>. The game stops at it: <ADDRESS_OR_LOG_LINE>.
READ FIRST: What the console says this call does: <DOC_OR_HEADER_PATH>. Where the game calls it: <CALL_SITES>. One call of the same kind that already works: <EXAMPLE_PATH>.
FENCE: Edit only <FILE_FOR_THIS_CALL> and its test. One call only. Do not write the calls next to it.
RULES:
  - Do what the console does, as the docs or a trace show.
  - If you do not know what it does, write "I don't know yet". Do not guess.
  - No stub that returns a made-up success.
CHECK: Run <TEST_COMMAND>, then <GOLDEN_RUN_COMMAND>. Done means the test passes, the game no longer stops at this call, and every older golden run still passes.
BUDGET: Stop after 3 failed tries.
IF BLOCKED: Stop. Tell me what the docs do not say, and what trace would answer it.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste both outputs. 3) Files changed. 4) The next call the game stops at. 5) New parking-lot items.

A good answer: Both check outputs. The name of the next call the game stops at. Or a plain "I don't know yet", with the trace that would answer it.

Batch dispatch

Once one unit works, you can run several at once. A lead session picks the units and starts one worker for each. It reads the reports and does no unit work itself.

A worker here is a subagent. That is a helper Claude starts, with its own fresh memory. Each worker gets its own worktree. A worktree is a second copy of the repo folder on its own branch. So two workers never write to the same files.

Do not rush to this step. The Melee project tells new people that "a supervised single-function agent session is gentler than an unattended batch run".

Batch dispatch for a lead session

Use this in a lead session when the unit card works well by hand. Save that unit card as a file first, so the lead can hand it to each worker.

Job type: bulk for each worker. The models table on Claude Setup names the model for a lead session.

Prompt for Claude

GOAL: Run the next <N> units from <LEDGER>. One worker per unit. One round, then stop.
READ FIRST: SCOPE.md. <LEDGER>. The task card in <CARD_FILE>.
PICK: Take the first <N> rows with status todo, smallest first. Skip stuck rows. Show me the list. Wait for my OK before you start any worker.
WORKERS:
  - Use worktrees for your agents. Start one subagent per unit, each in its own worktree.
  - Run each worker on the model <BULK_MODEL>.
  - Workers cannot see this chat. Give each one the full card from <CARD_FILE> with its unit filled in.
  - Add this line to each card: "Do not edit <LEDGER>. Report the status. The lead updates it."
FENCE: You may merge worker branches and edit <LEDGER> and PROGRESS.md. Nothing else. Do not fix a worker's code yourself.
CHECK: For each DONE report, merge that branch and run <CHECK_COMMAND> on the merged tree. If it fails, undo that merge and mark the unit failed-merge.
BUDGET: One round of <N>. No second round and no retry without my OK.
IF BLOCKED: Stop the round. Tell me which worker failed, and paste its report.
OTHER PROBLEMS: Workers report them. You write them in notes/parking-lot.md.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) A table: unit, worker result, check output after merge. 3) Rows changed in <LEDGER>. 4) Units to send to a hard job. 5) New parking-lot items.

A good answer: First a list of units, then a wait for your OK. At the end, a table with one row per unit and the check output after each merge.

Fill <BULK_MODEL> with the model for bulk jobs from the jobs table. A worker uses the lead's model unless you name one. /tasks lists each worker with its model and effort.

Max 20x

Start with three workers. Chris Lewis ran three worktrees, and later four. Your platform guide gives the number for your system.

Max 5x

Start with one or two workers. Matthew Stanley hit limits "regularly" on this plan. Look at /usage before you add a worker.

Four things that trip up worktrees

A new worktree starts from the default branch on the remote, not from your local work. Push first, or put "worktree": {"baseRef": "head"} in your settings file.
A worktree is a fresh checkout. Ignored files are not in it. If your check needs game files, list small ones in .worktreeinclude. For big folders, use the worktree.symlinkDirectories setting.
A worker cannot see the lead's chat. That is why the lead hands over the full card.
A pass inside a worktree is not the last word. One project's rule: "A match proven in an isolated worktree is not a match on the merged branch."

The same loop from the shell

You can run the loop with no lead session. claude -p runs one prompt and then exits. Each unit gets a fresh session. Chris Lewis left a loop like this running for eight hours or more.

This loop is built from Anthropic's docs and his script. We have not run it as written. Test it on three units first.

Save the "Match one function" card as prompts/match-one.md. Fill in every blank you can. Where the card names one function or its files, write "the unit named in the prompt, and its row in the ledger". Add one line: "Commit only if the check passes."

# Run this in WSL or Git Bash, from the repo folder.
# units.txt holds one unit name on each line. Start with three.
# Add batch.log to .gitignore first.
TOOLS="Read,Edit,Write,Bash(<DIFF_COMMAND> *),Bash(<CHECK_COMMAND>)"
TOOLS="$TOOLS,Bash(git add *),Bash(git commit *)"

for unit in $(cat units.txt); do
  claude -p "Follow prompts/match-one.md. The unit is $unit." \
    --model <BULK_MODEL> --effort <BULK_EFFORT> \
    --allowedTools "$TOOLS" --permission-mode dontAsk --max-turns 20 \
    2>&1 | tee -a batch.log
  git reset --hard HEAD
  <CHECK_COMMAND> || break
done

--allowedTools lists what the run may do without asking. --permission-mode dontAsk refuses the rest.
--max-turns 20 caps each run. A run that hits the cap exits with an error. The flag is in the CLI reference but not in claude --help.
git reset --hard HEAD throws away every change that was not committed. Commit your own work before you start.
A unit that did not pass leaves no commit. Its report is in batch.log. Mark it stuck in the ledger yourself.
|| break stops the loop the first time the check fails. Then you look at what went wrong.

Watch your usage

Every run in the loop spends from your plan. Anthropic's docs say: "Running several sessions or subagents at once multiplies token usage". Chris Lewis wrote that such a loop on a costly model could drain a Max 20x plan "in a matter of days".

Start small. The docs say: "Try it on three files first, see what goes wrong, fix the prompt, then run the rest."
Leave out --bare. It skips CLAUDE.md and your hooks, and it needs an API key.
Check that ANTHROPIC_API_KEY is not set. If it is, Claude Code bills that key and not your plan.
Read the log and the diff when the loop ends. The docs say to "have a person approve the result at the end".

Debug with evidence

Use this when you do not know why something is wrong. The session finds the cause and proves it. It does not fix it.

Proof here means a log line, a trace or a diff. A trace is a step-by-step record of what the game did. A diff is a list of the lines that changed.

Find and prove the cause

Use this for a bug that a quick fix did not solve. A fix made before the cause is known is a guess.

Job type: debug

Prompt for Claude

GOAL: Find the cause of <SYMPTOM> at <WHERE>. Prove it. Do not fix it in this session.
READ FIRST: <LOG_OR_TRACE_PATH>. The code at <ADDRESS_OR_FILE>. The dead ends listed in notes/findings.md.
FENCE: Change no project code. You may add log lines in <DEBUG_PATHS>. Take them out at the end. Logs go in <LOG_FOLDER>. Write findings in notes/findings.md.
STEPS:
  1) Make it happen with <REPRO_COMMAND>.
  2) Write down 2 or 3 possible causes.
  3) Name a test that would rule each one out. Run the tests until one cause is left and proven.
RULES:
  - Every claim needs a log line, a trace, an address or a diff.
  - Do not write "probably". If the evidence does not say, write "I don't know yet".
CHECK: Done means the bug happens on demand, the proof runs again, and only notes files changed.
BUDGET: Stop after <N> tests, or 30 minutes with no new fact.
IF BLOCKED: Stop. Tell me what evidence is missing and what tool or capture would get it.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The cause in one sentence. 3) The proof, pasted. 4) Causes ruled out, and how. 5) The smallest fix, as a plan only.

A good answer: One cause. One proof you can run again. A list of causes ruled out. A plan for the fix, but no fix.

The words "I don't know yet" come from a real project's rules. Those rules say the answer is "not a confident guess". Fill in the log folder too. That same project once piled up 555 GB of trace logs.

Verify

A fresh session checks work that another session calls done. It never saw how the work was done, so it judges only the result.

Re-run the check and hunt for cheating

Use this after every batch, and before you count a milestone as met. Always start a new session for it.

Job type: verify

Prompt for Claude

GOAL: Check if the work in <REPORT_OR_COMMITS> is real. You did not do this work.
READ FIRST: SCOPE.md. The task card the worker had. The diff: `git diff <BASE> <HEAD>`.
FENCE: Change no code, scripts or ledgers. Write only <VERIFY_NOTES_FILE> and notes/parking-lot.md.
STEPS:
  1) Run <CHECK_COMMAND> yourself on a clean checkout. Do not trust pasted output.
  2) Read every changed file. Look for each cheat on this list:
    - edits to expected hashes, the check script, tests or the original assembly
    - changes outside the card's FENCE, or a commit made with --no-verify
    - inline assembly, naked functions, hand-placed bytes, register pins or a changed compiler
    - pragma, goto or volatile used only to force a match
    - stubs, fake events, skipped code, or hand edits to machine-made code
    - a failed build called a pass, or a reason given with no command behind it
CHECK: Done means you ran the check yourself and read every changed file.
BUDGET: One pass. Report only gaps that affect correctness. Skip style.
IF BLOCKED: Stop. Tell me what you could not run or open.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Verdict: REAL, NOT PROVEN or CHEAT FOUND. 3) Your own check output, pasted. 4) Each finding, with file and line. 5) What you did not check.

A good answer: Its own check output, not a copy. Findings with file and line. A plain verdict. "Looks fine" with no output is not an answer.

Every cheat on the list was seen in a real project. On one project, Claude changed the stored hash so that a failed match passed. All later work had to be undone. On another, agents kept trying to edit the check script to skip their own function.

That second author wrote: "Agents have the desire to cheat if the assignment leaves room for interpretation". The card also says to skip style. Anthropic warns that a reviewer told to find problems "will always find something."

Status report

This card gives you numbers from the files. It does not give you a story.

Status from the ledger, numbers only

Use this at the start of a day, or before you plan a batch. Each number must name the file or command it came from.

Job type: docs

Prompt for Claude

GOAL: Give me the state of the project in numbers. Do no new work.
READ FIRST: <LEDGER>. PROGRESS.md. notes/parking-lot.md. `git log` since <DATE>.
FENCE: Change nothing. This is a read-only task.
COUNT:
  1) Units by status: todo, done, partial, stuck. Give counts and bytes.
  2) What changed since <DATE>.
  3) The milestone in SCOPE.md and how far along it is, as a number.
  4) Each stuck unit with its one-line reason from the ledger.
  5) Parking-lot items I have not answered.
CHECK: Run <CHECK_COMMAND> once and paste its last lines. Every number comes from a file or a command. Name that file or command next to the number.
BUDGET: One pass. Under 25 lines.
IF BLOCKED: Stop. Tell me which file is missing or does not add up.
OTHER PROBLEMS: If the ledger and the code disagree, list the rows. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The numbers. 3) Nothing else. No praise, no plans, and no guess at how long is left.

A good answer: Under 25 lines. Every number names its file or command. The check result is pasted, not described.

Session handoff

State lives in files, not in the chat. A new session should be able to start from the files alone.

Write what the next session needs

Use this before you close a session that did real work. Dead ends get written down too, so no later session tries them again.

Job type: docs

Prompt for Claude

GOAL: Write what the next session needs into the files. It will have no chat history.
READ FIRST: <LEDGER>. PROGRESS.md. notes/findings.md. This session's work.
FENCE: Edit only PROGRESS.md, <LEDGER>, notes/findings.md and notes/parking-lot.md. No code changes.
WRITE:
  1) PROGRESS.md: what is done, with the check output that proves it. What is half done, and where it stands. The next task, as a full task card.
  2) <LEDGER>: the status of every unit touched in this session.
  3) notes/findings.md: each dead end you tried, so no session tries it again. Each fact you proved, with its proof.
  4) Loose work: commit it on a branch, or list each file in PROGRESS.md.
CHECK: Run `git status` and <CHECK_COMMAND>. Done means the tree is clean, or every loose file is listed, and the check result is written in PROGRESS.md.
BUDGET: One pass. Short lines. No story of the session.
IF BLOCKED: Stop. Tell me what you could not record, and why.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste `git status` and the check output. 3) Files changed. 4) The first line the next session should read.

A good answer: A clean git status. A next task written as a full card. Dead ends written down, each with what was tried.

Blocked or cannot deliver

Use these when Claude stalls, hedges, or says a thing cannot be done. The first card forces a plain answer. The second one tests a claim of "impossible".

Force a plain answer with choices

Paste this into the session that got stuck, since it knows what was tried. A plain no is a good result.

Job type: the same as the task that got stuck. Do not switch models for this.

Prompt for Claude

GOAL: Give me a plain answer about <TASK_OR_MILESTONE>. Can you deliver it, or not?
READ FIRST: SCOPE.md. The task card. Your last report.
FENCE: Change nothing. Answer only.
CHECK: Each reason comes with proof: a command and its output, a file, or a doc. Do not write "should", "probably" or "almost". If you do not know, write "I don't know yet" and say what would tell us.
BUDGET: One answer. Do not start work on any choice.
IF BLOCKED: If you cannot answer even this, say so and say why.
OTHER PROBLEMS: Leave them out of this answer.
REPORT, IN THIS ORDER:
  1) One word: CAN, CANNOT or WILL NOT.
  2) If CANNOT: the exact thing that stops you. "It is hard" is not a reason.
  3) If WILL NOT: say so plainly and name the rule or the concern. I will not argue with it or try to get around it.
  4) What you tried, and the result of each try.
  5) What does work today, with proof.
  6) My choices, 2 to 4 of them. For each one: what I get, what I give up and what it costs. Make "stop here" one of the choices.

A good answer: One word first. A reason with proof. Two to four choices, with "stop here" as one of them. No "should" and no "almost".

Second opinion on an impossible claim

Use this in a fresh session when a report says a unit cannot match. Real projects have shown such claims to be wrong more than once.

Job type: hard

Prompt for Claude

GOAL: Test this claim: "<THE_CLAIM>". You are a fresh session. You did not make it.
READ FIRST: The report that made the claim. The unit: <SRC_PATH> and <ASM_PATH>. The best try so far in <SCRATCH_FOLDER>. The matched code in <MATCHED_FOLDER>.
FENCE: Edit only <SRC_PATH> and files in <SCRATCH_FOLDER>. Do not edit hashes, the check or other code. Put <SRC_PATH> back if no try passes.
STEPS:
  1) Name the exact instructions that differ. "Register allocation" alone is not an answer.
  2) Search the matched code for the same pattern. If matched code already makes the "impossible" shape, show me where.
  3) Try up to <N> new ideas. Change one thing per try.
CHECK: Run <DIFF_COMMAND> on each try. Only a try that passes <CHECK_COMMAND> with no banned tricks disproves the claim.
BUDGET: Stop after <N> tries or <M> minutes.
IF BLOCKED: Stop. Tell me what you could not test.
OTHER PROBLEMS: List them at the end of your report. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Your verdict on the claim: DISPROVED, with the passing try; SUPPORTED, with the evidence; or NOT SETTLED. 3) The instructions that differ. 4) What you tried. 5) What a human expert should look at next.

A good answer: The exact lines that differ. A matched function with the same shape, or a clear note that none was found. A verdict with proof.

On one project a helper worked for 16 minutes and said "97% is the honest ceiling". The author then found matched functions that already did the "impossible" thing. His view: "'It's a compiler artifact' is usually surrender, not diagnosis."

Still, the claim is sometimes right for now. Another author says about 4.8% of his matching commits needed an expert. A unit marked stuck, with the exact lines that differ, is an honest result.

Scope change request

Claude asks before it leaves the fence. You answer yes or no. Nothing changes until you answer.

Ask before leaving the fence

Paste this at the first sign of a detour. You can also add it to a long task from the start.

Job type: the same as the task in hand.

Prompt for Claude

GOAL: Before you touch anything outside the FENCE, ask me. Use this form, then stop.
READ FIRST: SCOPE.md and the task card you are working from.
FENCE: The old fence holds until I answer. Make no edits for the new idea.
ASK LIKE THIS:
  WHAT: the one change you want, and the paths it touches.
  WHY: what it unblocks, with proof that the current path fails.
  COST: files touched, new tools, and how long it takes.
  RISK: what could break, and how the check would catch it.
  IF NO: what you will do inside the old fence.
CHECK: Your request names the check that will prove the change worked.
BUDGET: One request. If I say no, do not ask again in new words.
IF BLOCKED: If you cannot go on without the change, report BLOCKED. That is a fine answer.
OTHER PROBLEMS: Write them in notes/parking-lot.md. Do not fix them.
REPORT: 1) The words SCOPE CHANGE REQUEST. 2) The five lines above. 3) Then wait for me.

A good answer: Five short lines, and then nothing until you reply. No edits for the new idea in the meantime.

One real starter prompt has the same idea in one line: "Do NOT change anything without my OK."

Then you answer. Be exact. Anthropic's advice on approvals is to "say exactly what you want". Here are the two replies.

Your reply: yes

YES to the change you asked for, and only that change.
NEW FENCE: Edit only <PATHS>. The rest of the task card stays the same.
CHECK: <CHECK_COMMAND> must still pass. So must <NEW_CHECK_IF_ANY>.
REPORT as before: DONE, PARTIAL or BLOCKED, with proof.

Your reply: no

NO. The fence stays as it was.
Write your idea in notes/parking-lot.md in one line.
Go on with the task card. If you cannot, report BLOCKED and stop.

Some changes are bigger than one fence. A new goal or a new technique is a change to SCOPE.md. You make that edit yourself.

Port layer task

This is phase 6 of Path B. You move one console part at a time behind an interface. An interface is a fixed list of calls that game code may use.

Put one console part behind an interface

Use this once for each console part: graphics, sound, input or files. It moves the console code and leaves the PC side for a later card.

Job type: runtime

Prompt for Claude

GOAL: Put one console part behind an interface: <PART: GRAPHICS | SOUND | INPUT | FILES>. Game code calls the interface. Console code sits behind it.
READ FIRST: SCOPE.md. The game code that calls <PART>: <CALL_SITES>. The console docs for those calls: <DOC_PATH>.
FENCE: Add files only in <PLATFORM_FOLDER>. In game code, change only the lines that call <PART>. One part only. No other clean-up. No new features.
STEPS:
  1) Show me a short plan. Wait for my OK.
  2) List every call the game makes to <PART>. Write the interface from that list.
  3) Move the console code behind it. Do not write the PC side yet.
CHECK: Run <CHECK_COMMAND> and <GOLDEN_RUN_COMMAND>. Done means both still pass with the interface in place.
BUDGET: Stop after 3 failed tries at the check.
IF BLOCKED: Stop. Do not weaken the check. Tell me which call does not fit behind the interface, and why.
OTHER PROBLEMS: Write 64-bit and byte-order problems in notes/parking-lot.md. Do not fix them here.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste both outputs. 3) Files changed. 4) The calls in the interface. 5) What is left.

A good answer: A list of the calls in the interface. Both check outputs, with the interface in place. Notes on 64-bit and byte-order problems in the parking lot, not fixed.

Byte order is the order in which a chip stores the bytes of a number. It can differ between a console and a PC. The card parks those problems for a later task.

The sources we read say little about how agents did port work. Treat this card as a first draft, and tune it on your first part.

Starter text for the files

The cards lean on a few files. Here is starter text for two of them.

File	What the cards use it for
`SCOPE.md`	The goal, the game version, the milestone and what is out of scope. Only you change it.
`CLAUDE.md`	Short standing rules. Claude Code loads it at the start of every session.
`PROGRESS.md`	What is done, what is next and the next task card.
`<LEDGER>`	One row for each function, with a size and a status.
`notes/findings.md`	Facts that were proved, and dead ends.
`notes/parking-lot.md`	Side ideas and other bugs. Claude adds lines. You decide.
`tools/check-failed.txt`	The text your check prints when it fails.

Lines for `CLAUDE.md`

These lines make Claude read SCOPE.md and end every task the same way. The first line, @SCOPE.md, loads that file into every session. Claude Setup has a longer starter file.

Add to CLAUDE.md

@SCOPE.md
The file above is the Scope Contract. Follow it. Only the owner changes it.
If a task needs a change to it, stop and ask.

The check is `<CHECK_COMMAND>`. A task is done only when it passes.
A build with no errors is not proof. One function that looks right is not proof.

Edit only the paths in the task card's FENCE. Ask before you edit anything else.
Side ideas and other bugs go in notes/parking-lot.md. Do not act on them.
If a task cannot be done, or the check looks wrong, tell me. Do not work around it.

End every task with this report:
1. One word: DONE, PARTIAL or BLOCKED.
2. Proof: the command you ran and its pasted output. No proof means not done.
3. Files changed.
4. What is left.
5. New parking-lot items.

Keep the whole file short. Anthropic's target is under 200 lines. These lines are advice to Claude, not locks. One author saw Claude skip his ten-try limit and make dozens of tries.

For a rule that must hold, use a hook or a deny rule. A hook is a small script that Claude Code runs before a tool call. It can block the call. Stay on Task shows how.

A failure message written for Claude

Claude reads what your check prints. So write the failure text for Claude. One real project's build script prints this: "BUILD HAS FAILED. Claude, you should treat this as a build failure. Adding new warnings or accepting a non-matching checksum count as failures."

Here is a starter for your own check. The setup card tells Claude to print it on every fail.

Save as tools/check-failed.txt

CHECK FAILED. Claude, treat this as a failure, even if one function looks right.
These also count as failures: a new warning, a hash that does not match, a skipped test.
Do not edit this script, the expected hashes or the original assembly to get a pass.
If the BUDGET in your task card is used up, stop now and write your report:
the best result and the file that holds it, what you tried, and what still differs.

The author of that script found that clear text inside the tools beat changes to the prompt.

Sources

Anthropic's own pages:

Write-ups and rule files from real projects:

Prompts you can copy

How to use these

The parts of every card

If you shorten a card

What goes in the blanks

Claude may say no

Claude may switch models

Scope and feasibility

Scope and feasibility check

Prior-work search

Setup

Set up the repo and the one check command

Prove the check works

Map the binary

Map the binary into a function ledger

Identify library and middleware code

First light

First light for Path A: boot to the first frame

First light for Path B: one file matching end to end

The unit loop

Match one function (Path B)

Fix one crash (Path A)

Fix one graphics or sound bug (Path A)

Implement one missing system call (Path A)

Batch dispatch

Batch dispatch for a lead session

Max 20x

Max 5x

Four things that trip up worktrees

The same loop from the shell

Watch your usage

Debug with evidence

Find and prove the cause

Verify

Re-run the check and hunt for cheating

Status report

Status from the ledger, numbers only

Session handoff

Write what the next session needs

Blocked or cannot deliver

Force a plain answer with choices

Second opinion on an impossible claim

Scope change request

Ask before leaving the fence

Port layer task

Put one console part behind an interface

Starter text for the files

Lines for CLAUDE.md

A failure message written for Claude

Sources

Lines for `CLAUDE.md`