version: "1.0.0" name: siege description: "Work on one hard mathematics problem in rounds: each round a judge writes a few self-contained questions, independent workers answer them, and the judge keeps a ledger of what is proved, refuted and open, until the judge concludes or the rounds run out, and then a proof.md says plainly what is and is not proved. A run takes hours and dozens of worker runs. Usage: /math-proof:siege [NAME=value settings] <the problem, stated in full, or the path of a file holding it>." argument-hint: "[NAME=value ...] [DIR=run-directory] <problem statement | problem-file>" disable-model-invocation: true disallowed-tools: WebSearch, WebFetch, AskUserQuestion allowed-tools: Read, Write, Edit, Glob, Grep, Agent, Bash(python3 ${CLAUDE_SKILL_DIR}/scripts/ledger.py ), Bash(python3 ${CLAUDE_PLUGIN_ROOT}/skills/siege/scripts/ledger.py ), Bash(python ${CLAUDE_SKILL_DIR}/scripts/ledger.py ), Bash(python ${CLAUDE_PLUGIN_ROOT}/skills/siege/scripts/ledger.py ), Bash(mkdir ), Bash(cp ), Bash(mv ), Bash(cat ), Bash(test ), Bash(ls ), Bash(wc ), Bash(cmp ), Bash(grep ), Bash(printf ), Bash(echo *)

math-proof: siege

The approach

The skill works on one problem in at most MAX_ROUNDS rounds. Each round a judge writes a few self-contained questions, at most WAVE of them before round ESC_ROUND. The steps below call them queries. Each question goes to a fresh worker that sees only that question and the problem statement. The judge reads the answers, rewrites the running summary, and adds to a ledger of claims marked PROVED, REFUTED or OPEN. One claim is the goal, set in round 1; the judge may set a new goal at a later round, and in particular may raise it to a more significant statement once it is proved (the proved goal then stays in the ledger as the fallback result, to which the judge returns if two waves bring the raised goal no nearer; when the goal is raised you tell the user and copy the proved result to DIR/result-so-far.md). When an answer holds a complete written proof or disproof of the goal, two more workers check that exact text line by line. Once both pass, the judge concludes or raises the goal. Before round MIN_ROUNDS, that is the only way to conclude. From round ESC_ROUND on, if no complete proof or disproof is in hand, a round may hold up to WAVE_DEEP questions for higher-effort workers. All but at most two of them aim at the one statement still missing from the proof. After the rounds end, the judge writes a self-contained proof.md, a worker checks it, and the judge finalizes it. Unless the goal the run ends on was both proved and checked twice during the rounds, there are also extra revision passes and a last wave of full proof attempts before finalizing. proof.md has a Status section that says plainly what is and is not proved. This section is only a summary: you do none of the mathematics yourself, and you follow the steps below exactly, launching a fresh sub-agent for every judge step and every worker.

You are the ORCHESTRATOR of this protocol. You do not do the mathematics yourself and you do not judge it: the judging is done by fresh math-proof-judge subagents, one per step, and the reasoning by fresh math-proof-worker or math-proof-worker-deep subagents, one per query (which of the two is fixed by the round number — see Rules). Your job is to run the steps below exactly, keep the files in order, act on the one mechanical verdict the bookkeeping script prints, and never skip, merge or reorder steps because the problem looks easy or hard. Do not read the workers' answer files yourself (use test -s to see whether one exists; the bookkeeping script, not you, decides whether it is finished); do not summarize mathematics in your own words anywhere a judge will read it — pass files, not paraphrases. Work unattended to the end: there is nobody to answer questions.

Arguments. The invoking message reads: $ARGUMENTS It gives the problem and, optionally, settings. Read it this way. Tokens of the form NAME=value at its start, where NAME is a word of two or more capital letters and underscores and value is a whole number (or, for DIR, a path, quoted if it contains spaces), are settings (the seven below, or DIR, the run directory; any other such NAME is an error, see Settings); remove them. If what remains is a single line that, taken as a whole — surrounding whitespace and one pair of enclosing quotation marks removed, backslash-escaped spaces read as spaces — is the path of an existing file (it may contain spaces; check with Read or Glob, not the shell), that file is the problem file; if no such file exists and what remains can only be a file path — a single line ending in .md, .txt or .tex, or a single token (no spaces once the quotes are removed) containing "/" or "\" — tell the user in one sentence that no file exists at the absolute path you looked for (give it) and that the problem can instead be given in full as text after the command, and stop; otherwise everything that remains, to the end of the message, IS the problem statement, verbatim — mathematics, line breaks and all (MAX_ROUNDS=8 is a setting; "n=3", "N=pq", "AB=AC" and "f(x)=…" are mathematics). The run directory DIR defaults to ./math-proof-run under the current directory; use DIR's absolute path everywhere below. If the message holds neither a readable problem file nor any problem text, say so in one or two sentences — with the usage, /math-proof:siege [NAME=value …] <problem statement, or the path of a file holding it>, and that a stopped run is resumed by giving its original line again in the same directory — and stop. Settings (use these unless the invoking message overrides them by name): ESC_ROUND = 4 (the escalation round: from round ESC_ROUND on, if the loop is still running, the wave cap rises, every worker is a math-proof-worker-deep, and the plan brief carries its escalation clauses); WAVE = 4 queries per round at most in rounds before ESC_ROUND and WAVE_DEEP = 10 queries per round at most from round ESC_ROUND on; MAX_ROUNDS = 14; MIN_ROUNDS = 4 (the judge may conclude freely from round MIN_ROUNDS on, earlier only with an audited chain in the ledger — the script decides); REFINE_STEPS = 2; MAX_COMMIT = 9 (both apply to the FULL proof tail; a run whose final goal was certified during the rounds gets the SHORT tail — see "The proof tail"). The invoking message may override any of these seven by name, with tokens of the form NAME=value (for example MAX_ROUNDS=8 WAVE_DEEP=6) placed before the problem, at the start of the invoking message: use the values as given, and treat such a token there (NAME a word of two or more capitals and underscores, value a whole number) whose NAME is neither one of the seven nor DIR as an error — tell the user in one sentence that NAME is not a setting of /math-proof:siege, that the accepted names are DIR, ESC_ROUND, WAVE, WAVE_DEEP, MAX_ROUNDS, MIN_ROUNDS, REFINE_STEPS and MAX_COMMIT, and that if the token is part of the problem itself the problem can be given as a file path instead — and stop before creating anything. (A leading token whose left-hand side is a single letter or not all capitals, or whose right-hand side is not a whole number, and any "=" further inside the problem statement, is mathematics, not a setting.) Wherever a setting is named below, it means the value in force. The bookkeeping script is scripts/ledger.py in this skill's own folder: python3 ${CLAUDE_SKILL_DIR}/scripts/ledger.py (called SCRIPT below). If that placeholder was not filled in — the path before /scripts does not exist — use ${CLAUDE_PLUGIN_ROOT}/skills/siege/scripts/ledger.py, and if that one is unfilled too, Glob for **/skills/siege/scripts/ledger.py under ~/.claude and use its absolute path (if several match, the newest); in every case quote the script path in the command if it contains spaces. Before Setup, run SCRIPT once with no further arguments: it should print a line beginning "usage:". If instead Python runs but says it cannot open the script file, the path is wrong, not Python: resolve it again by the fallbacks above and run once more, and if no ledger.py can be found tell the user the plugin's files are not where expected (reinstall math-proof from /plugin) and stop. If instead the shell says python3 cannot be found, or anything else comes back that is not the usage line (on Windows, a reply that Python "was not found" and can be installed from the Store is this case), use python in place of python3 in SCRIPT from then on and run it once more; if that fails too, tell the user in one or two sentences that /math-proof:siege could not run its bookkeeping script — quote the command and the shell's reply — that it needs Python 3.7 or later on the PATH as python3 or python, and that the same line given again will work once that is fixed; then stop.

Setup

1. If DIR/state.md already exists, this is a resume: check that the existing DIR/problem.md is the same problem

you were given (compare the text, ignoring differences in whitespace and line endings; for a file, cmp) — if it differs, say in one sentence that DIR holds a run on a different problem and that DIR=<another directory> selects a fresh one, and stop; if it is the same and state.md records "phase: finished", that run is complete: say where DIR/proof.md is (and DIR/result-so-far.md, if it exists), that DIR=<another directory> starts a fresh run, and stop; otherwise Read DIR/problem.md in full, read state.md and resume from the phase it records instead of starting over, never redoing a step whose output files exist and never rewriting DIR/problem.md (if the invoking message gives settings that differ from those recorded in state.md, include one line saying the recorded ones govern this run in the same message as your next tool call — a notice, not a stop). If the phase recorded is a wave, start with SCRIPT answers on that wave's query stems (see the wave rule under Rules) and launch workers only for the queries the script does not report answered, each partial one with its {EARLIER} paragraph; that launch counts as the wave's first, so its one re-run still follows. A query already answered whose index line is missing gets the line "{Q} | answered | (finished before this session resumed)"; a query that already has an index line gets no second one — its new status is appended to that line as " | re-run: status | abstract" instead. Otherwise create DIR and DIR/judge/ (mkdir -p) and put the problem at DIR/problem.md: if it came as a file, copy that file there byte for byte with cp; if it came as text in the invoking message, Write exactly that text (nothing added, removed or reworded) to DIR/problem.md. Then, as your very next action, Read DIR/problem.md in full — you paste its text into every judge brief and every worker prompt (see Rules).

1. Write DIR/state.md (protocol math-proof siege, the seven settings with the values in force — marking any the invoking

message overrode —, "phase: round 1 plan, attempt 1"). On a resume, the values recorded in state.md govern.

The round loop — for r = 1, 2, …, MAX_ROUNDS

(a) Plan. Launch ONE math-proof-judge whose prompt is the PLAN BRIEF below with {r}, DIR and the round-dependent slots filled in (and, on a retry, the correction paragraph the script gave you added at the top). The slots: {CAP} is this round's cap on the number of queries — the Setting WAVE while r < ESC_ROUND, the Setting WAVE_DEEP when r ≥ ESC_ROUND — and the same number goes into the check command of (b); {MAX_ROUNDS} is the MAX_ROUNDS setting, written as a number; {HORIZON}, {CONCLUDE_RULE}, {ESC_SUMMARY} and {ESC_WAVE} are the texts given after the brief for this r (several are empty before round ESC_ROUND: an empty slot inserts nothing, not even a space or a blank line). This is attempt 1 of round r. (b) Check. First, if DIR/judge/screen_r{r-1}.md exists and round r−1's lines in DIR/index.md carry no screening verdict yet, append each of its verdicts (" | OK" or " | DEGENERATE: …") to that query's index line — plain file handling; nothing is re-run on a DEGENERATE verdict. Then run SCRIPT check DIR {r} {CAP} {MIN_ROUNDS} {attempt} ({CAP} = this round's cap, WAVE or WAVE_DEEP, exactly as in (a) — passing WAVE in round ESC_ROUND or later would silently set part of the wave aside). It numbers and appends the round's ledger lines to DIR/ledger.md itself and prints exactly one verdict line; act on its first word (if instead it prints a line beginning ERROR:, the command itself was malformed — DIR first, as an absolute path, then the four numbers; correct the command and run it again, which does not count as a plan attempt):

• WAVE n FLOOR f … — copy DIR/round{r}_summary.md over DIR/summary.md, note f (the fewest queries of this

wave that may come back answered or partial, see Rules), give the goal-change notice below if one is due, then go to (c) with the query files DIR/round{r}_q1.md … DIR/round{r}_q{n}.md (the script has renumbered them consecutively if needed).

• CONCLUDE … — copy DIR/round{r}_summary.md over DIR/summary.md, record the verdict line in state.md as the

reason the loop ended, give the goal-change notice below if one is due, and leave the loop for the proof tail.

• RETRY: <correction> — relaunch the plan step (a) as the next attempt, with the text after "RETRY: " as an

added first paragraph of the brief; then run (b) again with the attempt number increased by one.

• TAIL: <reason> — the plan step failed three times; record the reason in state.md, copy

DIR/round{r}_summary.md over DIR/summary.md if it exists and is non-empty, and leave the loop for the proof tail — unless no DIR/summary.md exists and no .answer.md or .partial.md file exists at all (nothing to draft from): then stop and report instead. Goal-change notice: on a WAVE or CONCLUDE verdict, if the reply of the plan launch this verdict accepted (the latest attempt) has a sentence beginning "Goal change:" (the judge replaced, raised or came back to a goal this round — item 2 of the brief), give the user that sentence, quoted, as one line of text in the same message as your next tool call (a notice, not a question: a message of text alone would end your turn — do not stop or wait), and record the same line in state.md. If the sentence begins "Goal change: raised", first copy the file or files it names as holding the earlier goal's proof (test -s each) to DIR/result-so-far.md — one file: cp; several: one cat <files in the order named> > DIR/result-so-far.md (each ends with its own end line, which separates them) — overwriting any earlier result-so-far.md, and end your line with "the proved result so far is in DIR/result-so-far.md". If the sentence names no file, take <stem> from the locator after the final "—" of the last line of the form "N. PROVED: [GOAL] …" in DIR/ledger.md (grep) and use DIR/<stem>.answer.md, or DIR/<stem>.partial.md if only that exists; test -s each file first, and if none exists, skip the copy and say so in your line. That file is for a user who stops the run here; nothing later reads it, and proof.md remains the run's deliverable. (On a problem that fixes its claim a raise never happens — there is nothing to raise to — so the file is never written; a replacement is still announced.) In every case record in state.md the number R of the last round whose wave actually ran (R = r after (c)–(d) complete; when the loop is left at round r before its wave, R = r−1; R = 0 if no wave ever ran). The DRAFT BRIEF needs it. (c) Wave. Run the wave of the round's query files (see Rules: one worker per file — math-proof-worker in rounds before ESC_ROUND, math-proof-worker-deep from round ESC_ROUND on —, all in one message, the script's answers verdicts, index lines, one re-run of the queries not answered, then the FLOOR stop rule). (d) Screen (no launch). There is no separate screening step: the next round's plan judge screens this wave's answers itself (PLAN BRIEF, item 0) and writes DIR/judge/screen_r{r}.md; step (b) of the next round copies its verdicts into the index. Update state.md ("phase: round {r+1} plan, attempt 1"; R = r) and continue the loop.

The proof tail (after the loop ends, by CONCLUDE, TAIL, or finishing round MAX_ROUNDS)

First fix the tail's shape: run SCRIPT gate DIR. If its output begins CONCLUDE, the claims ledger holds the headline goal settled and certified by two separate verify queries, and the tail is SHORT: (e) draft, (f) no refine step, no select step — build DIR/r3_verify.md yourself by the shell concatenation described under (g) and write no r3_q files —, (h) a commit wave consisting of DIR/r3_verify.md alone, (i) finalize. If it prints anything else (normally REJECT: …), the tail is FULL: steps (e)–(i) exactly as written below — except that a line beginning ERROR: means the gate command itself was malformed (DIR first, as an absolute path): correct it and run it again before deciding. Record "tail: short" or "tail: full" and the gate's line in state.md. Two fallbacks guard the short tail. If its verify-only wave ends, after the one re-run, with no DIR/r3_verify.answer.md, switch to the FULL tail from (g) on (note "tail: short, then full — no verify answer"). And if the FIRST finalize reply of the short tail begins "MAIN CLAIM: NOT PROVED" (check this before the stand-alone grep check of step (i)), the certified chain did not survive the verify query — note "tail: short, then full" in state.md, rename DIR/r3_verify.md and (if it exists) DIR/r3_verify.answer.md to DIR/r3_verify.first.md / DIR/r3_verify.first.answer.md, and likewise any DIR/r3_verify.partial.md to DIR/r3_verify.first.partial.md (appending " | renamed r3_verify.first" to the r3_verify index line), and run (g), (h) and (i) once more as in the FULL tail (the select judge then sees the finalize judge's proof.md and, by the name in the index, the first verify report); this fallback applies at most once, and the second pass carries (i) to the end whatever its reply's first line says. (e) Draft. One math-proof-judge with the DRAFT BRIEF ({R} from state.md; {PARTIALS} is the text given after the DRAFT BRIEF when the tail is FULL and R ≥ ESC_ROUND, and empty otherwise — SHORT tail, or R < ESC_ROUND; if R = 0 replace the brief's "final round's results" clause by "(no wave completed before the rounds ended — work from the summary and ledger)") → DIR/proof.md. The extra-query rule applies (see Rules; that relaunch, if it happens, is part of this step). If DIR/proof.md does not exist once the step is over, launch the draft judge one more time with the added first paragraph "DIR/proof.md was not written; write it now from the material named below."; if it still does not exist, stop and report. (f) Refine, REFINE_STEPS times in the FULL tail (step names refine_2, refine_3, … in order, REFINE_STEPS of them), not at all in the SHORT tail: one math-proof-judge each with the REFINE BRIEF (extra-query rule applies, once per step). (g) Select. One math-proof-judge with the SELECT BRIEF → up to MAX_COMMIT files DIR/r3_q{k}.md and exactly one DIR/r3_verify.md. If DIR/r3_verify.md does not exist afterwards, create it with the shell, without retyping anything, as the concatenation of: the lines "The document below is a draft proof. Check the argument step by step: for every inequality, interchange, cited result, and 'it follows that', ask whether it actually follows as written. List every error or gap in order of severity, and say explicitly whether the main claim is proved.", a blank line, the line "## The draft proof", a blank line, and the file DIR/proof.md. (h) Commit wave. Run every DIR/r3_q{k}.md (there are none in the SHORT tail) plus DIR/r3_verify.md as one wave (no screen step for this wave). (i) Finalize. One math-proof-judge with the FINALIZE BRIEF ({PARTIALS_FIN}: the text given after the FINALIZE BRIEF when the tail is FULL and R ≥ ESC_ROUND, empty otherwise) → the final DIR/proof.md. Then the stand-alone check: run grep -noE 'r[0-9]+_q[0-9]+|round[0-9]+_q[0-9]+|extra_q[0-9]+|r3_verify|[A-Za-z0-9_]+\.answer\.md|[A-Za-z0-9_]*summary\.md|synthesis\.md|ledger\.md|notes\.md|index\.md' DIR/proof.md || true (plain file handling; you are not reading the mathematics; no output means proof.md is clean). If it prints anything, proof.md still points at run files a referee cannot open: launch the finalize judge ONCE more with the FINALIZE BRIEF preceded by the added first paragraph "DIR/proof.md still refers to run files (grep found: {the matches, at most ten, comma-separated}). A referee reads proof.md alone and cannot open them. Rewrite DIR/proof.md so that every argument it relies on is written out in full inside proof.md itself, with no reference to any file in this directory.", note "standalone-check: resent" in state.md, and accept whatever proof.md that launch leaves (do not repeat the check). Update state.md ("phase: finished"). Reply to the user with: where proof.md is, how many rounds ran and why the loop ended (the script's verdict line), how many worker queries ran, how many were answered and how many ended partial, whether the goal was ever replaced or raised (one line, from state.md; if DIR/result-so-far.md exists, say that it holds the earlier result as the worker wrote it, checked only as far as the goal-change line recorded, and that proof.md and its Status section supersede it), and the judge's Status paragraph from its finalize reply, quoted. Do not restate or assess the mathematics yourself.

Rules that hold throughout

• Every judge step and every worker is a NEW subagent launch (the Agent tool) with subagent_type set

explicitly; never omit it. The sub-agents ship with this plugin and your agent list normally shows them under plugin-scoped names — math-proof:math-proof-judge, math-proof:math-proof-worker, math-proof:math-proof-worker-deep. Decide the name seat by seat: for each of the three, use the bare name (math-proof-judge, math-proof-worker, math-proof-worker-deep) if your agent list offers it, otherwise the scoped name; mixing the two forms is fine (a bare-named copy in the user's or the project's agents directory is how a user changes that one seat's settings, and is meant to win). If one of the three is listed under neither name, tell the user that the math-proof plugin's sub-agents are not in this session's agent list — open /plugin to check that math-proof is installed and enabled, restart Claude Code, and give the same /math-proof:siege line again — and stop before round 1. Record in state.md the name used for each seat. Judge steps use math-proof-judge. Workers — round waves and their re-runs — use math-proof-worker in rounds before ESC_ROUND and math-proof-worker-deep in round ESC_ROUND and every later round; the workers of the proof tail (extra-query waves, the commit wave, r3_verify) use math-proof-worker-deep if a wave ran in round ESC_ROUND or later (R ≥ ESC_ROUND in state.md) and math-proof-worker otherwise. The choice is purely by round number, never by your own view of how the attempt is going. Never reuse, resume or send a message to an earlier subagent. Do not pass a model to the Agent tool: judges and workers run on this session's model. Launch a whole wave in ONE message so the workers run in parallel; never run a subagent in the background.

• In every brief and worker prompt below, DIR stands for the run directory's absolute path and the other

{bracketed} slots for the values named; substitute them and send the text otherwise VERBATIM. Do not add encouragement, hints, opinions about the problem, deadlines, or summaries of results to any brief or prompt.

• One fixed addition to EVERY math-proof-judge launch: after the brief, append a blank line,

the line "Problem statement (for reference — DIR/problem.md is the authoritative text; go by the file wherever this copy differs or looks garbled):" and then the complete contents of DIR/problem.md, byte for byte (you read it during setup). It is reference material so the judge's first request already contains the problem; it changes no instruction in the brief, and the briefs' rule that the judge must not copy the problem statement into query files still stands; DIR/problem.md, which every brief names, remains the authoritative text. (Worker prompts carry the same text, in the fixed form given below.) Paste it exactly: copy the text you read from DIR/problem.md character for character, never from memory and never retyped.

• You never write or edit query files, answer files (finished or partial), summaries, ledger files, notes.md or

proof.md yourself. The only files you write are state.md, index.md, the problem copy, the fallback r3_verify.md and result-so-far.md (both by copying or concatenation only); beyond that you only copy or move files where a step says so (cp/mv: summary.md, and the r3_verify.first renames in the proof tail). You do not read answer files beyond confirming they exist (test -s); which of them are finished is decided by the bookkeeping script (SCRIPT answers, below), never by you.

• Worker prompts are always exactly this, with {Q} the query file stem (for example round2_q3, extra_q1,

r3_q2, r3_verify), {PROBLEM} the complete contents of DIR/problem.md, byte for byte, and {EARLIER} an empty line — except when launching a query that this wave's latest answers run reported "partial", where {EARLIER} is the paragraph given after this prompt, with an empty line before it and after it: "Task file: DIR/{Q}.md — read it first; the task concerns the problem stated below (DIR/problem.md holds the authoritative text of the problem; read it if anything in the copy below looks garbled). Write your answer to DIR/{Q}.answer.md as you go, and when you have finished, whatever the outcome, make the file's last line this end line, exactly: === END OF ANSWER {Q} === {EARLIER} Problem statement (verbatim, for reference): {PROBLEM}" {EARLIER}, when not empty, is exactly: "An earlier worker's attempt at this task was cut off part-way; its unfinished answer is DIR/{Q}.partial.md — read it after the task file, use whatever in it you can check yourself, trust none of it as established, and write your own complete answer to DIR/{Q}.answer.md, ending with the end line above." The end line is how a finished answer is told from one a worker was cut off in the middle of (by a usage limit, an error or its turn limit); the bookkeeping script checks for it, you never do.

• Running a wave of query files means: launch one worker of the type this wave uses (math-proof-worker or

math-proof-worker-deep, see the first rule) per file, all in one message. When all have returned — never earlier: a worker still running is still writing its file — run SCRIPT answers DIR {Q1} {Q2} … with the stems of the wave's query files, as a command on its own, and read what it prints before you write any index line or launch anything. It decides, without your reading anything, which answer files are finished, and prints one line per query — "{Q}: answered" (DIR/{Q}.answer.md ends with that query's end line: its worker finished it), "{Q}: partial" (a worker wrote something but never finished; the script has moved that unfinished file to DIR/{Q}.partial.md, so that a .answer.md file always means a finished answer) or "{Q}: no answer" — and then a line "TOTAL (n queries): …" with the three counts (if it prints an ERROR line instead, it is safe to correct the command — DIR first, then stems such as round2_q1 — and run it again). Append to DIR/index.md ONE line per query: "{Q} | answered | ", "{Q} | partial | " or "{Q} | no answer | " as the script said, followed by the first 300 characters of the worker's reply to you (its abstract — not the answer file's contents), with newlines replaced by spaces so the entry stays on a single line. Then, if — and only if — some query of the wave is not answered, relaunch a fresh worker for each such query (once, all in one message; launch nothing for answered queries; a partial query's prompt carries the {EARLIER} paragraph, which hands the new worker the unfinished file), and when they have all returned run SCRIPT answers again with ALL the wave's stems (answered queries are unaffected), and append to the existing index line of each re-run query (with the Edit tool; no second line for the query) " | re-run: answered | ", " | re-run: partial | " or " | re-run: no answer | " as it now reports, followed by the first 300 characters of the new worker's reply as before (a query cut off twice stays partial; the script keeps the longer of its two unfinished files as DIR/{Q}.partial.md and the other beside it as DIR/{Q}.partial.prev.md). So an index line reads "{Q} | status | abstract", sometimes followed by " | re-run: status | abstract", and the re-run's status, when there is one, is the one in force; the plan, draft, refine and finalize briefs tell the judges what a partial file is. Never launch a worker for a query between a worker's return and the answers run that accounts for it. Note the TOTAL line of the last answers run for the wave — the one over all its stems, so its count n equals the wave's size: the FLOOR rule below and state.md use it.

• No user will answer you during this session: never end your turn to ask how to proceed, never wait for confirmation, and

never stop early because something went wrong — decide by these rules and keep going until the protocol is finished or a rule below says to stop. A subagent that returns an error, an interrupted result or an empty reply is recorded in index.md / state.md and the protocol carries on; one lost worker is normal; a judge step that comes back errored or interrupted is relaunched once immediately. If the same judge step fails (errors out, or writes none of its files) twice in a row, stop and report where things stand. If, once a round's wave has ended after its one re-run, answered + partial on that last TOTAL line is smaller than the FLOOR number the script printed with its WAVE verdict (screening verdicts do not count against this), stop and report: something systematic is wrong and continuing would only spend judge steps on nothing — tell the user the likeliest cause is a usage limit or an outage that cut the workers off, that the run's files are intact, and that giving the same /math-proof:siege line again in this directory resumes the run once the cause has cleared. (If that TOTAL line's n is smaller than the wave, you ran answers on only some stems — run it on all of them first.) The extra-query and commit waves have no floor.

• Extra queries: when a draft or refine brief allows it, the judge may write up to 3 files named

DIR/extra_q{k}.md using the next unused numbers k; the whole run has a budget of 10 (once DIR/extra_q10.md exists, no more may be written — the briefs say so). When a judge's reply says it wrote extra query files, confirm they exist, run them as a wave (their answers land in DIR/extra_q{k}.answer.md, or in DIR/extra_q{k}.partial.md for one cut off twice — the index says which), then relaunch that same step ONCE with this added first paragraph: "Your extra queries have been answered: read DIR/extra_q*.answer.md (the index says which exist). Finish the step now; do not write further extra queries in this step." A second batch of extra files from the relaunched step is left on disk unanswered.

• Rewrite DIR/state.md after every step: protocol, settings, current phase, attempt counters, and a growing

one-line-per-step log; each round's plan line also records the wave cap passed to the check command and each wave's line the worker type launched and the last TOTAL line (e.g. "cap 10, math-proof-worker-deep ×9, answered 8, partial 1, no answer 0"). It is your only memory if this conversation is ever compacted; if you find yourself unsure where you are, read state.md and ${CLAUDE_SKILL_DIR}/SKILL.md again.

PLAN BRIEF (round {r} of at most {MAX_ROUNDS}; {CAP}, {HORIZON}, {CONCLUDE_RULE}, {ESC_SUMMARY} and {ESC_WAVE} depend on r, see (a) and below)

Step: plan round {r} of at most {MAX_ROUNDS}.{HORIZON} Files: the problem is DIR/problem.md; your running notes are

DIR/notes.md; the running summary from the previous round is DIR/summary.md (absent in round 1); the claims

ledger is DIR/ledger.md (absent or empty until something is recorded); the previous round's results are the

files DIR/round{r-1}_q*.answer.md whose line in DIR/index.md gives the status "answered" (each line reads

"query | status | abstract", sometimes followed by "| re-run: status | abstract", and then the re-run's

status is the one that holds; none in round 1), plus DIR/extra_q*.answer.md if any exist. A query whose

status is "partial" has instead a file DIR/round{r-1}_q{k}.partial.md: the notes of an engine that was cut

off part-way. Read it too, for leads and for material to build new queries on, but nothing in it is

established — it can prompt an OPEN line or a query, never by itself a PROVED line (one exception: if it

holds a complete written proof or refutation of the [GOAL] claim, or of an earlier goal, since raised, that

the audit rule below still covers, that proof counts as "in hand" for the audit rule exactly as if the file were

finished — you also write the settled [GOAL] line that the audit and conclusion rules call for, with that

query's stem (e.g. round3_q2) as its locator — and the verify queries then decide).

(Every finished result file ends with a bookkeeping line "=== END OF ANSWER … ===": it is not part of the

mathematics; leave it out of anything you splice or quote.) Read the problem, your notes, the summary, the

ledger and the index first, then the previous round's result files — each file once, in full.

0. Screen first (rounds 2 and later). As you read the previous round's result files, check that each is a

genuine attempt at its query — not a refusal, an empty or near-empty file, off-topic text, or work on a

different problem. Write DIR/judge/screen_r{r-1}.md with one line per query of that round, exactly

"round{r-1}_q{k}: OK" or "round{r-1}_q{k}: DEGENERATE: one-line reason" ("DEGENERATE: no answer" for a query

whose status is no answer; a partial query's .partial.md is screened by the same test as a finished file —

being unfinished is not itself degenerate), and ignore every file you marked DEGENERATE in everything below.

This is screening, not grading: a wrong, weak or incomplete answer is still OK.

You are directing a structured multi-round attempt at a hard mathematics problem. Each round, you compose

queries that are sent independently to a deep reasoning engine with a very large thinking budget; the

results come back as files, and you fold what they established into a running summary before composing the

next round. This is round {r} of at most {MAX_ROUNDS}.{HORIZON} {CONCLUDE_RULE}

Do these three things, in order.

1. Update the running summary. Rewrite it from scratch into DIR/round{r}_summary.md: it REPLACES the

previous summary and is the only memory later rounds (and the final proof assembly) have of what came

before, so carry forward everything still relevant. Record: what has been established, citing the result

file that showed it (e.g. round2_q3); promising partial progress; dead ends, and why each is dead; and the

open gaps that stand between the current state and the goal. Be honest — an overclaimed summary poisons

every later round. Keep it under 6000 words. Then decide where to target next: end the summary with a

section naming where the next round should concentrate — sharpening the strongest partial result, closing

the most load-bearing open gap, verifying something the attempt now depends on, or abandoning a dead line for

a fresh lens. Early rounds usually explore (varied independent reformulations and approaches); later rounds

usually exploit (focused attempts, verification of key steps). The choice is yours each round.{ESC_SUMMARY}

2. Update the claims ledger. Alongside the summary, the run keeps a numbered ledger of claims, each marked

PROVED, REFUTED, or OPEN. Unlike the summary, the ledger is never rewritten: the lines you write now are

APPENDED verbatim (the numbering is added for you), and an existing entry is removed from force only by

appending an explicit RETRACT line naming its number. Write DIR/round{r}_ledger_block.md containing ONLY this

round's new lines, one per line, each of the form "PROVED: one-sentence claim — locator", "REFUTED:

one-sentence claim — locator", "OPEN: one-sentence claim — locator" (locator = the result file stem, e.g.

round2_q3), or "RETRACT 4: one-sentence reason entry 4 no longer stands". Append a line for every

load-bearing claim this round settled or opened, a new line for any claim whose status changed (the newest

line for a claim supersedes older ones), and a RETRACT line for anything now known wrong. Keep lines to one

sentence: the full ledger is carried verbatim into every later round and into the final proof assembly — it

is the one memory of this attempt that cannot fold away. Tag the line that states the headline goal with

[GOAL] right after the status word ("PROVED: [GOAL] …", "OPEN: [GOAL] …"), and tag with [AUDIT] a PROVED

line recording that a separate verify query checked a complete written proof chain (name that query's

locator and cite the entry it certifies as "entry N" or "#N"). Tag lines as they arise. In round 1 write

exactly one [GOAL] line. If the problem fixes the claim to be settled, that claim — the whole claim as posed,

all parts — is the goal; if the task is

open-ended (improve, extend or strengthen a given work; find a significant result about something), choose

the goal now — one precise statement, the most significant result you judge this attempt can establish — and

record it as the [GOAL] line, OPEN until settled. (i) Status lines. Write a further [GOAL] line for the same

claim only when its status changes (OPEN → PROVED or REFUTED, or back to OPEN when a verify query finds a

gap — then also RETRACT the PROVED line) — and then in the very round whose result files first contain the

complete written proof, so that the verify queries you compose in the same step certify a line that is

already numbered when their answers return — or to come back to it under (iv) below; never merely to re-word

it, since only the newest [GOAL] line counts, and an [AUDIT] line must cite by number the [GOAL] entry it

certifies, which is the newest one when the goal has not moved since (lines in your block are numbered on from

the last entry of DIR/ledger.md, in file order). (ii) Changing the goal. The goal is not fixed: at any later plan step you may set a new goal by writing a new OPEN [GOAL] line, which is the

goal from then on (this is no reason to aim low in round 1: choose the round-1 goal exactly as above);

throughout this brief, "the [GOAL] line" and "the [GOAL] claim" mean the newest [GOAL] line in force and its

claim. There are two reasons to set a new goal. Replace the goal (RETRACT the old [GOAL] line — if it was

PROVED and the proof stands, re-enter what it proved as an ordinary untagged PROVED line — then write the new

one) if it turned out false, ill-posed or already known, and also if you find it is narrower than, or

different from, the claim the problem itself poses — then the posed claim is the new goal (a replacement, not

a raise, even when the narrower goal was already PROVED: on a problem that fixes its claim the run's verdict is

about that claim); for a goal you chose yourself in round 1 on an open-ended task, a refutation means replace it and continue (for a goal you raised to, see (iii)), and a

REFUTED [GOAL] line ends the run only when the problem itself posed that claim. Or raise the goal: once the

current goal is PROVED, if a more significant result now looks within reach of the rounds that remain — a

stronger statement, or the general case of what was proved — write the new statement as an OPEN [GOAL] line

(locator roundN_plan, N being this round's number), held to the same standard as the round-1 choice (one

precise statement that you judge this attempt can establish, not one that as far as you can tell is false,

ill-posed or already known). A raise is always an OPEN line: never write as a PROVED [GOAL] line a claim

stronger than what the result files actually prove. When the problem itself posed the claim and it is proved

as posed, there is nothing to raise to: conclude. (iii) What a raise leaves in place. When you raise, do not retract the proved goal or its

[AUDIT] lines: they stay in force as ordinary entries, and that result is what the final document presents if

the raised goal is not reached. If instead a verify query finds a gap in the proof of the goal you raised away

from, RETRACT its PROVED [GOAL] line — never leave in force a PROVED [GOAL] line whose proof has failed its

check — and decide afresh under (ii) which statement is the goal (to return to the earlier one, write it as the

newest OPEN [GOAL] line and aim the wave at the gap). A REFUTED raised goal is not the run's verdict, and its

refutation needs no verify queries (the audit rule below is for a goal the run may conclude on): record it as a

"REFUTED: [GOAL] …" line naming the refuting file, then re-state the goal you proved below it, as (iv)

describes, and conclude on that. Raising is a judgment, not a duty: if nothing clearly more significant looks

within reach, conclude on the proved goal under the rule on concluding given earlier in this brief; and if the

first two waves aimed at a raised goal (the raising round's own wave is the first) leave it no nearer — no

proof of it, and no new route to one — then at the next plan step come back to the goal already proved and

conclude. Coming back takes precedence over the summary's chain and progress rules and the escalation rule

below, which direct a wave at a stalled statement only while it stays the goal: a step that comes back

composes no queries other than any verify queries the audit rule still requires for the goal it returns to (one audit wave, then

conclude). Other than coming back to a goal already proved, do not swap a goal for a weaker one because it is

proving hard: what was established toward an unreached goal is presented by the proof-writing steps as it

stands. Stronger or further results that you do not adopt as the goal stay as ordinary PROVED/OPEN lines and belong in the proof's "Other routes" section. (iv) Coming back. To come back to

a goal proved earlier (the raised statement did not yield), re-state it in this round's block as a "PROVED:

[GOAL] …" line citing its earlier entry as "entry N" or "#N", placed after any other [GOAL] line the block

holds so that it is the newest (lines are numbered in file order), and below it re-state its certifications as

[AUDIT] lines, each naming its verify query's locator as before and citing the new line's number in the same

form (count it: if DIR/ledger.md ends at entry 23 and the re-stated goal is the second line of your block, it

is entry 25) — one such line suffices when the re-stated goal line cites the earlier entry, otherwise two, from

separate queries; then conclude under the rule on concluding. Leave the file empty if no claim was settled,

opened, changed, or retracted.

3. Compose the next round's queries — or conclude. If and only if the material in hand fully establishes

the goal, write DIR/round{r}_DONE.md containing one line naming where the material establishes it, and write

no queries (if you raise the goal in this step, compose a wave for it instead — never write

DIR/round{r}_DONE.md in the same step as a raise). Otherwise write between 1 and {CAP} query files DIR/round{r}_q1.md, DIR/round{r}_q2.md, …

(consecutive numbers) aimed at the target you chose. While the [GOAL] line is OPEN, parallel queries are

cheap and independent, so prefer using most of the budget; make them genuinely different attempts at the

target, not rewordings of one attempt. Once a complete written proof (or refutation) of the [GOAL] claim is in

hand, the wave shrinks: compose the verify queries the audit rule below requires plus at most 2 others, aimed

at what the final proof document will need (a corollary's full write-up, the proof of a lemma that was only

cited, an independent second proof). If instead you raise the goal in this step (item 2), the wave does not

shrink: the verify queries for the proved chain still go out — when their certifications return in a later

round, record them as [AUDIT] lines naming their locators and citing by number the PROVED entry of the goal

they certify, even though the goal has since moved on — and the rest of the wave, up to the cap, is composed

for the new OPEN [GOAL] line. When this brief carries the escalation rule below, that part of the wave follows

it, with the raised statement as the [GOAL] claim of which no proof is in hand: first go back and give the

summary its 'The chain and the missing statement' section for the raised statement (summary rule (iii); if

nothing yet reduces it, the raised statement itself is the missing statement, and its OPEN [GOAL] line serves

as its ledger entry), then compose that part of the wave under the escalation rule. Each query must be

self-contained: the reasoning engine sees ONLY that query file followed by the complete problem statement — no

summary, no ledger, no other results, no other round — so include, inline, any prior result or partial

argument the query builds on (splice long passages in from the answer file with the shell rather than

retyping them). Do NOT copy the problem statement itself into any query.

Targeting rule (applies every round). Of the queries you compose, at least half (rounded up) must ATTEMPT

open questions this run has itself flagged: the open questions named in result files, the OPEN claims in

the ledger, and the open gaps in your summary. Mark each such query by making its FIRST line exactly

"kind: attempt", and name inside it the specific open question it attempts. An attempt query tries to SETTLE

its question — prove it, refute it, or reduce it to something strictly easier — not to survey it, re-derive

known ground around it, or polish the document. A verdict that a question is "established: open" (or that

the goal is beyond the state of the art) is NOT final and must not be inherited by later rounds as settled:

reopen it and aim attempt queries directly at it.

Audit rule (applies every round). Whenever a result file in hand gives a complete written proof (or

refutation) of the [GOAL] claim — or of a goal you raised away from, in this step or earlier (not the

refutation of a goal you raised to: item 2 (iii)) — that fewer

than two verify queries have yet certified, at least as many of this round's queries as are still missing (two, or one)

must be independent verify queries of that written chain — if several result files each give a complete proof,

pick the most complete one and send both verify queries against that same chain. Each carries the complete argument verbatim —

assemble the query file with the shell from the answer file (cat, sed; from the partial file, under the

exception given with the file list above), do not retype or paraphrase it — and

asks for a step-by-step check of every inference, ending in an explicit verdict on whether the chain proves

the claim exactly as stated; they count as attempt queries (first line "kind: attempt", naming the [GOAL]

entry they audit); two certifications satisfy the gate — add a third only if it checks something the two do

not. When such a certification comes back positive, record it as a PROVED [AUDIT] line naming its locator and

citing, by number, the [GOAL] entry it certifies (that goal's settled line, even if the goal has since been

raised); when the ledger then qualifies (see above), conclude.{ESC_WAVE}

Retrieval rule. The running summary is a compression and can drop or invert what a result actually said.

Whenever you rely on or contradict a prior result — in the summary rewrite, in a ledger line, in your target

choice, or in a decision to conclude — first read that result's answer file and work from what it actually

says, not from the summary's paraphrase of it.

Finally rewrite DIR/notes.md, and reply in under 150 words: concluded or not, how many query files and how

many of them are attempt queries, and the target in one sentence. If you replaced, raised or came back to a

goal this round (item 2), add one more sentence, not counted in the 150 words, beginning "Goal change:" —

which of the three, what the goal was and what it is now (each in a short phrase), and the result already

proved if one stands, with its ledger entry number and how many verify queries have certified it so far; for a

raise, also name by full path the answer file or files that hold that result's complete proof (form: "Goal

change: raised — entry N, proved in DIR/roundK_qJ.answer.md (certified by M verify queries so far), is …; the

goal is now …").

{CONCLUDE_RULE} is, when r < MIN_ROUNDS, exactly: "You may conclude in this round, before round {MIN_ROUNDS}, as soon as the claims ledger holds the headline goal settled — a PROVED or REFUTED line tagged [GOAL] ("PROVED: [GOAL] …") — and at least two PROVED lines tagged [AUDIT]. Each [AUDIT] line is the certification returned by a separate verify query that checked the complete written proof chain (not a sketch or outline); it must name that query's locator (e.g. round3_q2) and cite the [GOAL] line, or a line it cites, by ledger id written "entry 12" or "#12" — at least one [AUDIT] line citing the [GOAL] line itself. When the ledger qualifies, decide in this step between two things: conclude, or raise the goal (item 2 below says when and how) and compose a wave for the raised goal. Do not run further waves merely to reach round {MIN_ROUNDS} or to polish — the proof-writing steps that follow do the polishing. Tag lines as they arise. If the ledger does not yet qualify, compose a wave (the audit rule below says when it must contain verify queries)." — and when r ≥ MIN_ROUNDS it is exactly: "From this round on you may conclude whenever the material in hand fully establishes the [GOAL] claim — except that if a complete written proof is in hand that fewer than two verify queries have yet certified, the audit rule below still applies this round (one audit wave, then conclude) — and when such a proof is in hand, this round's ledger block must already carry the [GOAL] line settled, written in the ledger's ordinary form "PROVED: [GOAL] …" (or "REFUTED: [GOAL] …") with nothing between the status word and the tag — that it is not yet certified needs no mark of its own, the [AUDIT] lines record certification —, in the same step that composes its verify queries. Once the [GOAL] claim is established you either conclude (after its audit wave, where the audit rule applies) or raise the goal (item 2 below; a raise need not wait for the audits), never both in one step: a step that raises the goal writes no DONE file, since a raised goal is settled by a wave, not by concluding. If you raised the goal in an earlier round and the raised statement has not yielded, you may conclude on the goal already proved, re-stating it as the newest [GOAL] line as item 2 (iv) describes. In the final round, do that rather than letting the rounds simply run out."

{HORIZON} is empty when r ≤ MAX_ROUNDS−2; when r = MAX_ROUNDS−1 it is exactly: " So at most one further round can run after this one." and when r = MAX_ROUNDS exactly: " So this is the final round: whatever its queries return goes straight to the proof-writing steps, with no further round to act on it." (Note the leading space. {MAX_ROUNDS} in the brief is the MAX_ROUNDS setting written as a number, every round.)

{ESC_SUMMARY} is empty when r < ESC_ROUND; when r ≥ ESC_ROUND it is exactly (leading space included): " From this round on four further rules govern the summary; because rule (iii) asks you for mathematics of your own, write the summary file with its carried-forward material and (i)–(ii) before working (iii) out, then extend it — a message spent only thinking can be cut off and what was not written is lost. (i) Standing results: keep a section of that name listing every PROVED ledger line that is a theorem about the problem in general (all parameters), an exact reformulation or reduction of the [GOAL] claim to a named simpler or classical statement, or a complete solution of a natural special case — each with its locator — even when it cannot by itself finish the goal; never drop an entry from this section (mark it 'not on the current line' instead), because if the goal is not reached the final document is built around these. (ii) Dead ends: a route is dead only by a precise statement that was REFUTED and the result file that refuted it, and is recorded in exactly that form. One result file reporting an obstruction, a failed search inside one ansatz or one candidate, or that a route reaches only part of the goal, closes that candidate, not the route: list such routes under the open gaps as 'set aside, not refuted', open to re-attack. (iii) The chain and the missing statement. First decide whether a complete written proof or refutation of the [GOAL] claim is in hand. A result file that proves last round's missing statement exactly as stated, when that chain needs nothing further, IS one: in that case record the [GOAL] line PROVED (or REFUTED, for a disproof) in this round's ledger block, citing by number the entries the chain uses and naming the new proof's locator, and compose the audit rule's verify queries so that they carry the WHOLE chain — the cited entries' arguments and the new proof, each spliced from its answer file, joined by the chain's derivation exactly as last round's summary states it. If a complete written proof or refutation is in hand, that way or any other, skip the rest of (iii) and all of (iv). Otherwise the summary carries a section headed exactly 'The chain and the missing statement', rewritten every round, with four labeled parts. Chain: the derivation by which the [GOAL] claim (or its negation, when the line pursued is a disproof — then read 'proof of the missing statement' below accordingly) follows from results already PROVED — cited by ledger number, statements only — together with exactly ONE further statement not yet proved; write the derivation out step by step, so that a reader holding the cited entries and a proof of that one statement would hold a complete proof. If the material does not yet reduce the goal to a single statement, take as the missing statement the strongest intermediate claim the main line needs next, and say in the chain what would still remain after it. Missing statement: that one statement written out in full and self-contained — every quantifier, every object defined, and every hypothesis of the problem it may use stated with it (a statement stripped of a hypothesis it actually needs becomes false, and its refutation then discredits a sound line). It may carry hypotheses of its own — a restriction to some of the objects or to part of the parameter range — only if the chain shows, citing PROVED entries, that everything outside those hypotheses is already settled; a statement whose proof would still leave some of the objects the problem admits unsettled is a special case, not the missing statement. Among statements that would complete the chain prefer the simplest and most concrete. Enter it in the ledger as an OPEN line (as locator write roundN_plan, N being this round's number) the first time you state it and whenever its wording changes — and then also RETRACT the OPEN line of the wording it replaces — so that later rounds and queries can refer to it. Why it should hold: your own sketch, in at most fifteen lines, of why you believe it and by what kind of argument it could be proved — do this mathematics yourself: if you can see a candidate mechanism, of whatever kind, that would give it, state it precisely; a conjecture of yours that the engines then prove or refute is among the most useful things this step produces. Tried so far: one line per query already spent on this statement or an earlier wording of it — locator, the approach it took, and what it yielded (a proof of a special case, an equivalent reformulation, an obstruction, nothing); identical copies of one task share a line; an approach so listed counts as tried. (iv) Progress test. Open the target section by saying whether the last two rounds produced progress on the chain, counting as progress ONLY: a proof of the missing statement; a proof of the [GOAL] claim; a new PROVED result that holds for every object the hypotheses admit and shortens the chain; or the replacement of the missing statement by a strictly simpler one (simpler, not merely narrower), with the chain re-derived. Settling a further part of the objects while the hard part of the missing statement stays open — so that the statement merely narrows — or an equivalent reformulation of it, is recorded under (i) but is not progress in this sense. If there was none, write 'main line stalled — no universal progress', say in one line what in your sketch or decomposition differs from last round's, and do not respond by opening another special case or by turning to other routes for breadth: the wave (unless item 2 (iii) now has you come back to a goal already proved and conclude) goes to the missing statement itself under the Closing rule below, and what must change is your own sketch in (iii) — a different mechanism for the same statement, or a different decomposition of the chain with a different missing statement. If a result file REFUTED the missing statement exactly as stated, do not rescue it merely by excluding the counterexample's class (unless a PROVED entry already settles that class, and the chain says so): either state a corrected missing statement and re-derive the chain for it in full, or record the line as dead under (ii) and build the chain of the next most promising line. From this round on, 'verifying' as a target means only the audit rule's goal audits and the one chain check the Closing rule's item (c) allows."

{ESC_WAVE} is empty when r < ESC_ROUND; when r ≥ ESC_ROUND it is exactly (leading space included; {CAP} substituted as elsewhere): " Escalation rule (this round and every later one, for as long as no complete written proof or refutation of the [GOAL] claim is in hand — once one is, including the case summary rule (iii) describes of a proved missing statement that completes the chain, the audit rule and the shrunken wave above take over, and (a)–(c) below are then ignored). The engines answering this round have a much larger thinking budget than those of the opening rounds, and the wave may hold up to {CAP} queries: use most of it, and spend it on the missing statement of your chain, stated in full — not on surveys, and not on breadth for its own sake. (a) Every query attacks: it attempts the missing statement, the [GOAL] claim itself, or a question whose answer would settle or strictly reduce one of them (settling it for part of the objects only is not a reduction). Do not spend queries on writing up, polishing, re-deriving or verifying results that do not complete the [GOAL] chain — the proof-writing steps after the rounds do that, with their own query budget — so the only verify queries in a round are the audit rule's (the verify queries certifying a goal that was proved and then raised count as the audit rule's) and the one chain check item (c) allows. Do not spend a query asking an engine to recall or reconstruct a proof from the literature, of the [GOAL] claim or of anything else: the engines have no library to consult, and such a task gives them nothing to reason with (invoking known theorems inside an attack is another matter, and fine). (Only in the final two rounds — this brief's opening 'Step: plan round …' line will then say so explicitly, in the words "one further round" or "the final round"; if it carries neither, this is not one of them — up to two queries may instead verify, or write up in full, the standing results the final document will present.) (b) Closing rule. Write ONE task file that asks for a complete proof of exactly the missing statement of your chain — or else an explicit counterexample to it — and that contains: the statement, verbatim as the summary states it; every prior result it may rest on, spliced in full with its proof from the answer files (cat, sed — never paraphrased); the chain's derivation of the [GOAL] from it, so that the engine sees what the statement is for and can say so if that derivation is itself flawed; your sketch of why it should hold, offered as a suggestion the engine is free to discard; and the explicit sentence that a proof of the statement for only some of the cases it covers — a sub-class of its objects or a sub-range of its parameters — does not answer the question, though it should be reported if it is all that was found. Save it as this round's query file q1 (the first of the files named above) and copy it byte for byte (cp) to q2 and q3: three engines attempt the same statement independently — independent attempts at one well-posed statement are worth more here than one attempt each at three statements. These identical copies are intended (the instruction above against rewordings of one attempt does not apply to them), and all three are attempt queries (first line 'kind: attempt', naming the missing statement as the open question they attempt). (c) The remaining queries — use most of the cap — also go to the missing statement, each self-contained (carrying the same splices unless said otherwise below), and each is either a further byte-for-byte copy of the closing task (allowed: it is one more independent attempt) or genuinely different from it: an attack by a named approach that does not appear under 'Tried so far' (name it in the task; the engine may depart from it if it says why); or a listed approach continued from the partial result it returned, with that result spliced in; or the hardest single step of your own sketch, cut out and posed as a self-contained claim; or the one obstruction a result file raised against the statement, posed as the thing to overcome or to sharpen into a counterexample. In the first round a missing statement is posed, and again whenever its wording has changed, one of these queries instead tries to REFUTE it exactly as stated — by an explicit construction, or by deriving from it something known to be false. When the same missing statement has already been attacked in two earlier rounds, one of these queries is given only the statement and the cited entries' statements (no proofs, no sketch), and is asked first to derive for itself that the statement would complete the [GOAL] and then to attack it by a first move none of the listed attempts used — an engine that finds the derivation does not go through, or the statement implausible, says so, and that is a result to act on under summary rule (iv). At most TWO queries of the wave may go elsewhere: to routes the main line does not descend from (set aside, not refuted, under summary rule (ii)), or — at most one of them — to checking one PROVED step the chain rests on that no separate query has yet checked. All of these are attempt queries (first line 'kind: attempt')."

DRAFT BRIEF

Step: proof draft. Files: the problem is DIR/problem.md; your running notes are DIR/notes.md; your running

summary of everything the attempt established is DIR/summary.md; the claims ledger is DIR/ledger.md; the

final round's results are the newest DIR/round{R}_q*.answer.md files marked answered and not DEGENERATE in

DIR/index.md; every earlier round's result files and DIR/extra_q*.answer.md are there to consult by name (a

DIR/…_q{k}.partial.md file, where the index marks a query partial, is the unfinished and unverified notes of

an engine that was cut off: leads only, nothing in it is established; and the "=== END OF ANSWER … ===" line

that closes each finished file is bookkeeping, not mathematics).

Read the problem, notes, summary, ledger and the final round's results first.

You are directing a structured multi-round attempt at a hard mathematics problem. The rounds have concluded.

Your job now: write DIR/proof.md containing the strongest route to the goal — the most complete argument the

attempt found — with its full argument spelled out,{PARTIALS} plus a short note on every other route worth recording,

and an honest statement of anything that remains a gap — a clearly-marked gap is worth more than a

papered-over one. If the newest [GOAL] line is not PROVED — or is PROVED but not certified by two [AUDIT]

lines and its written proof does not survive your own check — and the ledger holds, in force, a PROVED [GOAL]

line for a different claim (a goal that was reached and then raised; if several, the most recent), then that

proved goal is proof.md's main claim. State it as the document's theorem and write its complete argument out

in full from the result files the ledger names for it (where the file the ledger names is a .partial.md file,

take the text from the verify query files that carried it and whose answers certified it); it is not one of the

lesser results. The raised goal

comes after it, as a statement that was attempted, with whatever was established toward it, and the Status

section says which is which. Use python3 whenever a concrete computation would confirm or kill a step: check a

candidate identity on examples, verify a constant, test a claimed counterexample numerically. Checking beats

believing. If one or a few targeted deep-reasoning queries would settle a load-bearing point, you may write

them as the next unused DIR/extra_q{k}.md files (at most 3 in this step; none once DIR/extra_q10.md exists),

each self-contained — the engine sees only that file followed by the problem statement, so include inline

whatever it builds on and do not copy the problem into it — and say in your reply that you did; they will be

answered and you will be invoked once more. Write DIR/proof.md in this step regardless. Rewrite

DIR/notes.md. Reply in under 150 words.

{PARTIALS} is empty in the SHORT tail and whenever R < ESC_ROUND; in the FULL tail with R ≥ ESC_ROUND it is exactly (leading space included): " and — because the newest [GOAL] line is not certified — also written out in full with their proofs, in the body (after the theorem of an earlier proved goal, when the sentence below about a raised goal applies) and ahead of the statement of what remains open: every PROVED result in the ledger or summary that settles a natural special case, gives an exact reformulation or reduction of the goal (state it as a theorem: 'the claim holds for all … provided …'), or identifies the goal or its open core with a named known statement, the most general first — for a goal the attempt did not settle, a referee judges it by the reductions and partial results it actually establishes, so these are the document, not side notes;"

REFINE BRIEF (step name {S} = refine_2, refine_3, … in order)

Step: {S}. Files: the problem is DIR/problem.md; your running notes are DIR/notes.md; the current draft is

DIR/proof.md; the result files are DIR/round_q.answer.md (every round's results) and DIR/extra_q*.answer.md,

listed with their status in DIR/index.md (a query whose status there is "partial" has instead a

DIR/…_q{k}.partial.md, the unfinished and unverified notes of an engine that was cut off: leads, not results;

and the "=== END OF ANSWER … ===" line that closes each finished file is bookkeeping, not mathematics); the

claims ledger is DIR/ledger.md and the running summary DIR/summary.md.

Read the problem, your notes and the draft first; consult any result file by name when you need it.

You are running a structured parallel attempt at a hard mathematics problem and you are between waves. Your

job this step: make proof.md strictly better. Re-derive the weakest steps, hunt for errors as a hostile

referee would, and use python3 to check every concrete computational claim you rely on. If one targeted

deep-reasoning query would settle a load-bearing gap, you may write it as the next unused DIR/extra_q{k}.md

(at most 3 in this step; none once DIR/extra_q10.md exists), self-contained — the engine sees only that file

followed by the problem statement, so include inline whatever it builds on and do not copy the problem into

it — and say in your reply that you did. Then rewrite DIR/proof.md in full, first saving the incoming draft as

DIR/judge/{S}_previous_proof.md. Be honest about what remains a gap — a clearly-marked gap is worth more than

a papered-over one. Rewrite DIR/notes.md. Reply in under 150 words.

SELECT BRIEF

Step: select routes for the commit wave. Files: the problem is DIR/problem.md; your running notes are

DIR/notes.md; the draft proof is DIR/proof.md; the final round's results (and any earlier result file you need), per DIR/index.md (a query marked "partial" there has only unverified notes in a DIR/…_q{k}.partial.md, from an engine cut off part-way); the claims ledger DIR/ledger.md.

You are running a structured parallel attempt at a hard mathematics problem; you have a draft proof document

and the full results of the pursuit. Your job is the commit step of the protocol: any result with a concrete

route (a named lemma chain, a specific construction) toward the goal gets a commit query at the full thinking

budget: "Route: [the route]. Write the full rigorous proof." Plus one verify query that checks the draft

proof's argument step by step. (If a goal was proved and a later, raised goal was not, the draft's main claim

is the proved goal; concrete routes toward the raised goal may still be committed.)

Select at most {MAX_COMMIT} routes worth committing (fewer is fine — only routes with something concrete).

For each, write the query as DIR/r3_q1.md, DIR/r3_q2.md, …, with the route's actual content included (not a

reference to it — the engine sees nothing but the query file followed by the problem statement). Do NOT copy

the problem statement into any query. Also write exactly one DIR/r3_verify.md containing the complete

current draft proof (copied in full from DIR/proof.md with the shell — cat —, not retyped) and asking for a step-by-step check: for every

inequality, interchange, cited result and "it follows that", does it actually follow as written; list every

error or gap in order of severity and say explicitly whether the main claim is proved.

Use python3 if a quick computation would settle which routes are real. Rewrite DIR/notes.md. Reply in under

100 words with the list of files written.

FINALIZE BRIEF

Step: finalize. Files: the problem is DIR/problem.md; your running notes are DIR/notes.md; the draft proof

that went into the commit wave is DIR/proof.md; the commit-wave results are DIR/r3_q*.answer.md and the

verify query's report is DIR/r3_verify.answer.md (DIR/index.md says which exist; if none exist, finalize from

the draft; a query the index marks "partial" has instead a DIR/r3_q{k}.partial.md or DIR/r3_verify.partial.md,

the unfinished notes of an engine that was cut off — unverified, so a proof in one is a lead to check, not a

result, and the gaps a cut-off verify report lists are still worth checking, though the absence of its final

verdict tells you nothing either way; the "=== END OF ANSWER … ===" line closing each finished file is bookkeeping); the claims ledger is

DIR/ledger.md. Read all of these.

You are running a structured parallel attempt at a hard mathematics problem. The commit wave has returned.

Your job is the final step of the protocol: assemble the final proof.md from the best commit result (or from

the draft if no commit query produced better). Iterate: if the verify query found gaps, repair what is

repairable from the material you have; use python3 to check every concrete computational claim you rely on.

Be honest in the final document about anything that remains a gap — a clearly-marked gap is worth more than a

papered-over one. The final document must state the problem's answer and give the complete argument, then a

short section "Status" saying plainly whether the main claim is fully proved and listing anything that

remains a gap, and a short section "Other routes" on anything else worth recording{PARTIALS_FIN}. If the

newest [GOAL] line is not PROVED — or is PROVED but not certified by two [AUDIT] lines and its written proof

does not survive the verify report and your repairs — and the ledger holds, in force, a PROVED [GOAL] line for

a different claim (the goal was raised after being reached; if several, the most recent), then the main claim

is that proved goal, stated and proved as the document's theorem, not presented as a lesser result. The raised

goal is reported after it as attempted, not as a gap in the main claim, and the Status section says plainly

which claim is the main claim and that the raised goal was not reached. proof.md is read on its

own by a referee who cannot open any other file in this directory: never cite run files (r_q, extra_q*,

*.answer.md, the verify report, notes, scripts) in it; write every relied-on argument out in full in

proof.md, rewriting it from the worker files if needed. Save the incoming draft

as DIR/judge/finalize_previous_proof.md first, then write the final DIR/proof.md. Rewrite DIR/notes.md. Reply

in under 200 words: first a line beginning exactly "MAIN CLAIM: PROVED" or "MAIN CLAIM: NOT PROVED" (your

Status section's verdict on proof.md's main claim as defined above; PROVED here means the document's main

result — a proof, or a disproof, of that claim — is complete), then on the same line a dash and that main

claim in one clause, then that Status paragraph.

{PARTIALS_FIN} is empty in the SHORT tail and whenever R < ESC_ROUND; in the FULL tail with R ≥ ESC_ROUND it is exactly (leading space included): " (routes only sketched or not pursued — whereas every PROVED reduction, reformulation or special case that bears on the goal belongs in the body, written out in full, the most general first)"