siege — скилл для Claude Code: что делает и как установить

---
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).
2. 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...