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