I need you to set up a 5-agent pipeline that solves mathematical optimization problems by developing theoretical analysis and solver code in parallel, with each side informing the other. A problem arrives as a natural-language statement in `problem.md`. The pipeline alternates between revising the theory (bounds, invariants, structural claims) and revising the code (an implementation that achieves those guarantees).

The five agents:

- **dispatcher** orchestrates the run by alternating one theory step with one code step and tracking progress. It does no modeling, coding, or reviewing itself.
- **theory loop** — the **theorist** writes the theoretical analysis to `THEORY.md`; the **theory-reviewer** judges it. The theorist reads `SOLUTION.md` on each revision pass to incorporate empirical evidence.
- **code loop** — the **coder** writes solver code and its results to `SOLUTION.md`; the **code-reviewer** judges them. The coder reads `THEORY.md` on each revision pass to align the implementation with the latest theoretical claims.

At the end of every turn, each of the subagents briefly reports back what they did, what difficulties they hit, and any open questions.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original problem, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing plan per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/THEORY.md` — the theoretical analysis for that plan. Theorist writes; theory-reviewer reviews; coder and code-reviewer read it.
- `plans/{id}-{slug}/SOLUTION.md` — the solver code and its results for that plan. Coder writes; code-reviewer reviews; theorist and theory-reviewer read it.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, overwriting any previous block. The dispatcher reads those scores to drive the loops.

Each plan develops independently. Cross-read between THEORY.md and SOLUTION.md happens only within the same plan; an agent assigned to one plan never reads another plan's files. The dispatcher round-robins across the K plans: each plan gets one theory step plus one code step per full cycle.

Within each plan, neither theoretical analysis nor solver code finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. Theory may tighten after seeing the plan's code's empirical numbers; code may correct after seeing the plan's theory's refined bounds.

I'm providing the following information:

<f1>
Keep `SOLUTION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final state and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
You orchestrate the run; you never model, code, or review yourself — you only dispatch the right agent at the right time.

- **Init** — discover the K plan directories under `plans/{id}-{slug}/`. Create `STATE.md` with `iter: 0`, `current_plan_idx: 0`, and a per-plan record holding each plan's id, last side, and latest theory/code scores.
- **Round-robin pool loop** — at each cycle, advance to the next plan in the round-robin order. For that plan, dispatch one theory step (theorist, then theory-reviewer) and one code step (coder, then code-reviewer); then move to the next plan. After all K plans have each had one cycle, loop back to the first plan.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `THEORY.md` / `SOLUTION.md` to operate on.
- Neither side terminates early on its own score within a plan; even a perfect-looking theory may need to revise once the code reports actual numbers. The pool keeps cycling even after individual plans look done.
- Cap the total at 20 × K dispatches (10 theory + 10 code per plan, summed across K plans). After the cap, stop and summarize per plan.
- Keep the current iteration count, current plan index, and per-plan latest scores in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's reviewer `<review score=X>` block. Commit progress after each step.
- Read each agent's brief narrative reply on return. If an agent reports an unresolved error, append it to `error-log.txt` (timestamp + plan id + agent name + content) and continue with the next dispatch.
</f2>

<f3>
You are working on a mathematical optimization problem, which may be linear, mixed-integer, nonlinear, or a combination. The original problem is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

<f4>
Score the work from 1 to 10, and record your verdict by overwriting the single `<review score=X>` block at the end of the document you reviewed — overwrite the existing one, never append a second.

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f4>

<f5>
Produce the theoretical analysis for the plan the dispatcher has assigned you to this round, and write it to that plan's `THEORY.md` (under `plans/{id}-{slug}/THEORY.md`). A complete analysis covers four kinds of claim, each justified with a proof sketch or a citation.

- **Bounds** — lower bounds on the objective from dual or LP relaxations or counting arguments; upper bounds from feasible constructions or known approximation ratios.
- **Structural properties** — convexity, monotonicity, submodularity, symmetries, decomposability into independent subproblems. State what holds, where, and under which assumptions.
- **Invariants** — quantities every feasible solution must preserve (conservation laws, parity constraints, total-mass conditions). The solver's output should satisfy them; the code-reviewer will check with `verify.py`.
- **Complexity or convergence** — worst-case complexity (P, NP-hard, FPT in some parameter), expected complexity for randomized methods, or convergence rate for iterative algorithms.

Ground your claims against the plan's `SOLUTION.md` if it has reported numbers. A predicted bound that is grossly off from observed numbers means either the theory needs revision or the code has a bug — diagnose which side has the issue and state it. Be concrete. "The objective is bounded below by the LP relaxation, value 73" is fine; "the problem has some structure that may help" is not. Do not read or aggregate across other plans' files.
</f5>

<f6>
When you finish, briefly report to the dispatcher: what you did, what difficulties you hit (or didn't resolve), and any open questions.
</f6>

<f7>
Match the tool to the problem structure; do not force an ill-suited one. The list below is useful in theoretical analysis.

| Tool | Suitable for |
|---|---|
| Lagrangian relaxation / dual bounds | MILP, MINLP; lower bound on minimization, primal-dual gap analysis |
| KKT conditions | Differentiable NLP; certify local optimality of an interior point |
| Convex analysis (strong duality, convexity certificates) | LP, QP, convex NLP; global optimality from local |
| Monotonicity / submodularity | Combinatorial selection; (1-1/e) and similar greedy approximation ratios |
| Fixed-point theorems (Banach, Brouwer, Kakutani) | Iterative methods; existence of equilibrium, geometric convergence |
| Concentration inequalities (Hoeffding, Chernoff, Azuma) | Randomized algorithms; high-probability bounds on cost or error |
| Complexity reductions (NP-hardness, APX-hardness) | Exact-solution lower bounds; justify resorting to a heuristic |
| Parametric / sensitivity analysis | Stability of optimal value under perturbation of data |
</f7>

<f8>
You operate on the plan the dispatcher has assigned you to this round. Read `problem.md`, your assigned plan's `PLAN.md`, and your assigned plan's `THEORY.md`, then implement the solver:

- Include every import. Create each variable with the correct type and bounds, define the objective and every constraint exactly as the problem states. Solve, check the solution status, and print both the solution and the objective value.
- Make the implementation testable against the plan's `THEORY.md`. If the theory states a dual bound B, your solver should achieve an objective at least B (for minimization). If the theory states an invariant, your output should satisfy it.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer against the plan's `THEORY.md`. A quantity that must be a whole number should not come back fractional; a bound the theory says holds should hold.

Write the code and its results up in your assigned plan's `SOLUTION.md`. Do not read or write any other plan's files.
</f8>

<f9>
Review your assigned plan's `SOLUTION.md` against `problem.md`, against the plan's `PLAN.md`, and against the plan's `THEORY.md`. Operate strictly on the assigned plan's files; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable objective values, or constraint violations stated directly in `problem.md` or in the plan's `PLAN.md`.
- Open the plan's `THEORY.md`. For every bound and invariant the theory claims, write a check into a separate `verify.py` under the plan's directory: does the solver's output satisfy the invariant, fall within the predicted bound, achieve the predicted approximation ratio? Run it. Name any variable or quantity that violates.
- Read the solver code and spot-check it for bugs — unused parameters, dead code, logic that contradicts the chosen algorithm. A bug that silently degrades the solution is worse than one that crashes.
- Treat the result as finished only when every constraint holds, every theory-claimed invariant holds, and the objective is consistent with the theory's bounds — not merely when the code runs without error.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f9>

<f10>
Claude responds well to clear, explicit instructions. Being specific about your desired output can help enhance results. If you want "above and beyond" behavior, explicitly request it rather than relying on the model to infer this from vague prompts.

Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.

Topology rule: Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.

- Be specific about the desired output format and constraints.
- Provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters.
</f10>

<f11>
You operate on the plan the dispatcher has assigned you to this round. Your theoretical analysis lives in that plan's `THEORY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the theory-reviewer as a loop, alternating with that plan's code loop, while the dispatcher round-robins across plans.

- If your assigned plan's `THEORY.md` does not exist yet, this is the first pass for that plan: produce the analysis from scratch based on `problem.md` and the plan's `PLAN.md`.
- If the plan's `THEORY.md` already exists, it carries the theory-reviewer's `<review>` block. Read that feedback. Then open the plan's `SOLUTION.md` and look at the latest reported numbers — they may invalidate, sharpen, or motivate revisions to your claims. Revise the plan's `THEORY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous analysis and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f11>

<f12>
Review your assigned plan's `THEORY.md` against `problem.md`, against the plan's `PLAN.md`, and against the numbers reported in the plan's `SOLUTION.md` (if any). Operate strictly on the assigned plan's files; do not look at other plans.

- **Faithfulness** — does the theory correctly describe the problem stated in `problem.md` under the framing set by the plan's `PLAN.md`? Check definitions, decision variable types, constraint translations.
- **Proof soundness** — for each claim, walk through the proof sketch or citation. Flag hand-waving steps. Verify cited inequalities apply under the stated assumptions.
- **Empirical grounding** — open the plan's `SOLUTION.md`. If the code reports objective values, do they fall within the theory's predicted bounds? A dual bound that is loose by orders of magnitude is a signal the relaxation is too weak; tighten it, or note explicitly that the bound is only illustrative.

Be brief and specific. Do not write theory yourself — only review. If a claim is wrong, say which one and why.
</f12>

<f13>
You operate on the plan the dispatcher has assigned you to this round. Your solver code and its results live in that plan's `SOLUTION.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the code-reviewer as a loop, alternating with that plan's theory loop, while the dispatcher round-robins across plans.

- If your assigned plan's `SOLUTION.md` does not exist yet, this is the first pass for that plan: produce the solution from scratch based on `problem.md` and the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the code-reviewer's `<review>` block. Read that feedback. Then open the plan's `THEORY.md` and check whether the latest theory introduces bounds, invariants, or structural claims your current implementation doesn't yet respect — for example a tighter dual bound your solver is now far from achieving, or an invariant your output violates. Revise the plan's `SOLUTION.md` in place to address every reviewer point and to align with the latest theory. Don't discard the previous solution and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f13>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (dispatcher, theorist, theory-reviewer, coder, code-reviewer), which items should go in its prompt? Respond with a JSON object like {"dispatcher": ["f?"], "theorist": ["f?"], "theory-reviewer": ["f?"], "coder": ["f?"], "code-reviewer": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that solves mathematical optimization problems by developing theoretical analysis and solver code in parallel, with each side informing the other. A problem arrives as a natural-language statement in `problem.md`. The pipeline alternates between revising the theory (bounds, invariants, structural claims) and revising the code (an implementation that achieves those guarantees).

The five agents:

- **dispatcher** orchestrates the run by alternating one theory step with one code step and tracking progress. It does no modeling, coding, or reviewing itself.
- **theory loop** — the **theorist** writes the theoretical analysis to `THEORY.md`; the **theory-reviewer** judges it. The theorist reads `SOLUTION.md` on each revision pass to incorporate empirical evidence.
- **code loop** — the **coder** writes solver code and its results to `SOLUTION.md`; the **code-reviewer** judges them. The coder reads `THEORY.md` on each revision pass to align the implementation with the latest theoretical claims.

At the end of every turn, each of the subagents briefly reports back what they did, what difficulties they hit, and any open questions.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original problem, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing plan per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/THEORY.md` — the theoretical analysis for that plan. Theorist writes; theory-reviewer reviews; coder and code-reviewer read it.
- `plans/{id}-{slug}/SOLUTION.md` — the solver code and its results for that plan. Coder writes; code-reviewer reviews; theorist and theory-reviewer read it.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, overwriting any previous block. The dispatcher reads those scores to drive the loops.

Each plan develops independently. Cross-read between THEORY.md and SOLUTION.md happens only within the same plan; an agent assigned to one plan never reads another plan's files. The dispatcher round-robins across the K plans: each plan gets one theory step plus one code step per full cycle.

Within each plan, neither theoretical analysis nor solver code finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. Theory may tighten after seeing the plan's code's empirical numbers; code may correct after seeing the plan's theory's refined bounds.

I'm providing the following prompt fragments:

<f1>
Keep `SOLUTION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final state and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
You orchestrate the run; you never model, code, or review yourself — you only dispatch the right agent at the right time.

- **Init** — discover the K plan directories under `plans/{id}-{slug}/`. Create `STATE.md` with `iter: 0`, `current_plan_idx: 0`, and a per-plan record holding each plan's id, last side, and latest theory/code scores.
- **Round-robin pool loop** — at each cycle, advance to the next plan in the round-robin order. For that plan, dispatch one theory step (theorist, then theory-reviewer) and one code step (coder, then code-reviewer); then move to the next plan. After all K plans have each had one cycle, loop back to the first plan.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `THEORY.md` / `SOLUTION.md` to operate on.
- Neither side terminates early on its own score within a plan; even a perfect-looking theory may need to revise once the code reports actual numbers. The pool keeps cycling even after individual plans look done.
- Cap the total at 20 × K dispatches (10 theory + 10 code per plan, summed across K plans). After the cap, stop and summarize per plan.
- Keep the current iteration count, current plan index, and per-plan latest scores in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's reviewer `<review score=X>` block. Commit progress after each step.
- Read each agent's brief narrative reply on return. If an agent reports an unresolved error, append it to `error-log.txt` (timestamp + plan id + agent name + content) and continue with the next dispatch.
</f2>

<f3>
You are working on a mathematical optimization problem, which may be linear, mixed-integer, nonlinear, or a combination. The original problem is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

<f4>
Score the work from 1 to 10, and record your verdict by overwriting the single `<review score=X>` block at the end of the document you reviewed — overwrite the existing one, never append a second.

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f4>

<f5>
Produce the theoretical analysis for the plan the dispatcher has assigned you to this round, and write it to that plan's `THEORY.md` (under `plans/{id}-{slug}/THEORY.md`). A complete analysis covers four kinds of claim, each justified with a proof sketch or a citation.

- **Bounds** — lower bounds on the objective from dual or LP relaxations or counting arguments; upper bounds from feasible constructions or known approximation ratios.
- **Structural properties** — convexity, monotonicity, submodularity, symmetries, decomposability into independent subproblems. State what holds, where, and under which assumptions.
- **Invariants** — quantities every feasible solution must preserve (conservation laws, parity constraints, total-mass conditions). The solver's output should satisfy them; the code-reviewer will check with `verify.py`.
- **Complexity or convergence** — worst-case complexity (P, NP-hard, FPT in some parameter), expected complexity for randomized methods, or convergence rate for iterative algorithms.

Ground your claims against the plan's `SOLUTION.md` if it has reported numbers. A predicted bound that is grossly off from observed numbers means either the theory needs revision or the code has a bug — diagnose which side has the issue and state it. Be concrete. "The objective is bounded below by the LP relaxation, value 73" is fine; "the problem has some structure that may help" is not. Do not read or aggregate across other plans' files.
</f5>

<f6>
When you finish, briefly report to the dispatcher: what you did, what difficulties you hit (or didn't resolve), and any open questions.
</f6>

<f7>
Match the tool to the problem structure; do not force an ill-suited one. The list below is useful in theoretical analysis.

| Tool | Suitable for |
|---|---|
| Lagrangian relaxation / dual bounds | MILP, MINLP; lower bound on minimization, primal-dual gap analysis |
| KKT conditions | Differentiable NLP; certify local optimality of an interior point |
| Convex analysis (strong duality, convexity certificates) | LP, QP, convex NLP; global optimality from local |
| Monotonicity / submodularity | Combinatorial selection; (1-1/e) and similar greedy approximation ratios |
| Fixed-point theorems (Banach, Brouwer, Kakutani) | Iterative methods; existence of equilibrium, geometric convergence |
| Concentration inequalities (Hoeffding, Chernoff, Azuma) | Randomized algorithms; high-probability bounds on cost or error |
| Complexity reductions (NP-hardness, APX-hardness) | Exact-solution lower bounds; justify resorting to a heuristic |
| Parametric / sensitivity analysis | Stability of optimal value under perturbation of data |
</f7>

<f8>
You operate on the plan the dispatcher has assigned you to this round. Read `problem.md`, your assigned plan's `PLAN.md`, and your assigned plan's `THEORY.md`, then implement the solver:

- Include every import. Create each variable with the correct type and bounds, define the objective and every constraint exactly as the problem states. Solve, check the solution status, and print both the solution and the objective value.
- Make the implementation testable against the plan's `THEORY.md`. If the theory states a dual bound B, your solver should achieve an objective at least B (for minimization). If the theory states an invariant, your output should satisfy it.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer against the plan's `THEORY.md`. A quantity that must be a whole number should not come back fractional; a bound the theory says holds should hold.

Write the code and its results up in your assigned plan's `SOLUTION.md`. Do not read or write any other plan's files.
</f8>

<f9>
Review your assigned plan's `SOLUTION.md` against `problem.md`, against the plan's `PLAN.md`, and against the plan's `THEORY.md`. Operate strictly on the assigned plan's files; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable objective values, or constraint violations stated directly in `problem.md` or in the plan's `PLAN.md`.
- Open the plan's `THEORY.md`. For every bound and invariant the theory claims, write a check into a separate `verify.py` under the plan's directory: does the solver's output satisfy the invariant, fall within the predicted bound, achieve the predicted approximation ratio? Run it. Name any variable or quantity that violates.
- Read the solver code and spot-check it for bugs — unused parameters, dead code, logic that contradicts the chosen algorithm. A bug that silently degrades the solution is worse than one that crashes.
- Treat the result as finished only when every constraint holds, every theory-claimed invariant holds, and the objective is consistent with the theory's bounds — not merely when the code runs without error.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f9>

<f10>
Claude responds well to clear, explicit instructions. Being specific about your desired output can help enhance results. If you want "above and beyond" behavior, explicitly request it rather than relying on the model to infer this from vague prompts.

Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.

Topology rule: Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.

- Be specific about the desired output format and constraints.
- Provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters.
</f10>

<f11>
You operate on the plan the dispatcher has assigned you to this round. Your theoretical analysis lives in that plan's `THEORY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the theory-reviewer as a loop, alternating with that plan's code loop, while the dispatcher round-robins across plans.

- If your assigned plan's `THEORY.md` does not exist yet, this is the first pass for that plan: produce the analysis from scratch based on `problem.md` and the plan's `PLAN.md`.
- If the plan's `THEORY.md` already exists, it carries the theory-reviewer's `<review>` block. Read that feedback. Then open the plan's `SOLUTION.md` and look at the latest reported numbers — they may invalidate, sharpen, or motivate revisions to your claims. Revise the plan's `THEORY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous analysis and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f11>

<f12>
Review your assigned plan's `THEORY.md` against `problem.md`, against the plan's `PLAN.md`, and against the numbers reported in the plan's `SOLUTION.md` (if any). Operate strictly on the assigned plan's files; do not look at other plans.

- **Faithfulness** — does the theory correctly describe the problem stated in `problem.md` under the framing set by the plan's `PLAN.md`? Check definitions, decision variable types, constraint translations.
- **Proof soundness** — for each claim, walk through the proof sketch or citation. Flag hand-waving steps. Verify cited inequalities apply under the stated assumptions.
- **Empirical grounding** — open the plan's `SOLUTION.md`. If the code reports objective values, do they fall within the theory's predicted bounds? A dual bound that is loose by orders of magnitude is a signal the relaxation is too weak; tighten it, or note explicitly that the bound is only illustrative.

Be brief and specific. Do not write theory yourself — only review. If a claim is wrong, say which one and why.
</f12>

<f13>
You operate on the plan the dispatcher has assigned you to this round. Your solver code and its results live in that plan's `SOLUTION.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the code-reviewer as a loop, alternating with that plan's theory loop, while the dispatcher round-robins across plans.

- If your assigned plan's `SOLUTION.md` does not exist yet, this is the first pass for that plan: produce the solution from scratch based on `problem.md` and the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the code-reviewer's `<review>` block. Read that feedback. Then open the plan's `THEORY.md` and check whether the latest theory introduces bounds, invariants, or structural claims your current implementation doesn't yet respect — for example a tighter dual bound your solver is now far from achieving, or an invariant your output violates. Revise the plan's `SOLUTION.md` in place to address every reviewer point and to align with the latest theory. Don't discard the previous solution and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f13>

Each agent's prompt should contain only the fragments that agent needs to do its job. When you include a fragment, paste the FULL block verbatim — no paraphrasing, no partial inclusion, no rewriting of fragment content. Brief connective text between fragments (e.g., "Then: ...", "Note: ...") is fine. Format: one markdown section per role, with the role name as an h1 header (e.g. `# dispatcher`). Output only the headered prompts, no preamble.


dispatcher theorist theory-reviewer coder code-reviewer

I need you to set up a 5-agent pipeline that solves mathematical optimization problems by developing theoretical analysis and solver code in parallel, with each side informing the other. A problem arrives as a natural-language statement in `problem.md`. The pipeline alternates between revising the theory (bounds, invariants, structural claims) and revising the code (an implementation that achieves those guarantees).

The five agents:

- **dispatcher** orchestrates the run by alternating one theory step with one code step and tracking progress. It does no modeling, coding, or reviewing itself.
- **theory loop** — the **theorist** writes the theoretical analysis to `THEORY.md`; the **theory-reviewer** judges it. The theorist reads `SOLUTION.md` on each revision pass to incorporate empirical evidence.
- **code loop** — the **coder** writes solver code and its results to `SOLUTION.md`; the **code-reviewer** judges them. The coder reads `THEORY.md` on each revision pass to align the implementation with the latest theoretical claims.

At the end of every turn, each of the subagents briefly reports back what they did, what difficulties they hit, and any open questions.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original problem, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing plan per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/THEORY.md` — the theoretical analysis for that plan. Theorist writes; theory-reviewer reviews; coder and code-reviewer read it.
- `plans/{id}-{slug}/SOLUTION.md` — the solver code and its results for that plan. Coder writes; code-reviewer reviews; theorist and theory-reviewer read it.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, overwriting any previous block. The dispatcher reads those scores to drive the loops.

Each plan develops independently. Cross-read between THEORY.md and SOLUTION.md happens only within the same plan; an agent assigned to one plan never reads another plan's files. The dispatcher round-robins across the K plans: each plan gets one theory step plus one code step per full cycle.

Within each plan, neither theoretical analysis nor solver code finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. Theory may tighten after seeing the plan's code's empirical numbers; code may correct after seeing the plan's theory's refined bounds.

I'm providing the following information:

<f1>
You operate on the plan the dispatcher has assigned you to this round. Read `problem.md`, your assigned plan's `PLAN.md`, and your assigned plan's `THEORY.md`, then implement the solver:

- Include every import. Create each variable with the correct type and bounds, define the objective and every constraint exactly as the problem states. Solve, check the solution status, and print both the solution and the objective value.
- Make the implementation testable against the plan's `THEORY.md`. If the theory states a dual bound B, your solver should achieve an objective at least B (for minimization). If the theory states an invariant, your output should satisfy it.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer against the plan's `THEORY.md`. A quantity that must be a whole number should not come back fractional; a bound the theory says holds should hold.

Write the code and its results up in your assigned plan's `SOLUTION.md`. Do not read or write any other plan's files.
</f1>

<f2>
Match the tool to the problem structure; do not force an ill-suited one. The list below is useful in theoretical analysis.

| Tool | Suitable for |
|---|---|
| Lagrangian relaxation / dual bounds | MILP, MINLP; lower bound on minimization, primal-dual gap analysis |
| KKT conditions | Differentiable NLP; certify local optimality of an interior point |
| Convex analysis (strong duality, convexity certificates) | LP, QP, convex NLP; global optimality from local |
| Monotonicity / submodularity | Combinatorial selection; (1-1/e) and similar greedy approximation ratios |
| Fixed-point theorems (Banach, Brouwer, Kakutani) | Iterative methods; existence of equilibrium, geometric convergence |
| Concentration inequalities (Hoeffding, Chernoff, Azuma) | Randomized algorithms; high-probability bounds on cost or error |
| Complexity reductions (NP-hardness, APX-hardness) | Exact-solution lower bounds; justify resorting to a heuristic |
| Parametric / sensitivity analysis | Stability of optimal value under perturbation of data |
</f2>

<f3>
You operate on the plan the dispatcher has assigned you to this round. Your solver code and its results live in that plan's `SOLUTION.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the code-reviewer as a loop, alternating with that plan's theory loop, while the dispatcher round-robins across plans.

- If your assigned plan's `SOLUTION.md` does not exist yet, this is the first pass for that plan: produce the solution from scratch based on `problem.md` and the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the code-reviewer's `<review>` block. Read that feedback. Then open the plan's `THEORY.md` and check whether the latest theory introduces bounds, invariants, or structural claims your current implementation doesn't yet respect — for example a tighter dual bound your solver is now far from achieving, or an invariant your output violates. Revise the plan's `SOLUTION.md` in place to address every reviewer point and to align with the latest theory. Don't discard the previous solution and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f3>

<f4>
Review your assigned plan's `THEORY.md` against `problem.md`, against the plan's `PLAN.md`, and against the numbers reported in the plan's `SOLUTION.md` (if any). Operate strictly on the assigned plan's files; do not look at other plans.

- **Faithfulness** — does the theory correctly describe the problem stated in `problem.md` under the framing set by the plan's `PLAN.md`? Check definitions, decision variable types, constraint translations.
- **Proof soundness** — for each claim, walk through the proof sketch or citation. Flag hand-waving steps. Verify cited inequalities apply under the stated assumptions.
- **Empirical grounding** — open the plan's `SOLUTION.md`. If the code reports objective values, do they fall within the theory's predicted bounds? A dual bound that is loose by orders of magnitude is a signal the relaxation is too weak; tighten it, or note explicitly that the bound is only illustrative.

Be brief and specific. Do not write theory yourself — only review. If a claim is wrong, say which one and why.
</f4>

<f5>
You orchestrate the run; you never model, code, or review yourself — you only dispatch the right agent at the right time.

- **Init** — discover the K plan directories under `plans/{id}-{slug}/`. Create `STATE.md` with `iter: 0`, `current_plan_idx: 0`, and a per-plan record holding each plan's id, last side, and latest theory/code scores.
- **Round-robin pool loop** — at each cycle, advance to the next plan in the round-robin order. For that plan, dispatch one theory step (theorist, then theory-reviewer) and one code step (coder, then code-reviewer); then move to the next plan. After all K plans have each had one cycle, loop back to the first plan.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `THEORY.md` / `SOLUTION.md` to operate on.
- Neither side terminates early on its own score within a plan; even a perfect-looking theory may need to revise once the code reports actual numbers. The pool keeps cycling even after individual plans look done.
- Cap the total at 20 × K dispatches (10 theory + 10 code per plan, summed across K plans). After the cap, stop and summarize per plan.
- Keep the current iteration count, current plan index, and per-plan latest scores in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's reviewer `<review score=X>` block. Commit progress after each step.
- Read each agent's brief narrative reply on return. If an agent reports an unresolved error, append it to `error-log.txt` (timestamp + plan id + agent name + content) and continue with the next dispatch.
</f5>

<f6>
Produce the theoretical analysis for the plan the dispatcher has assigned you to this round, and write it to that plan's `THEORY.md` (under `plans/{id}-{slug}/THEORY.md`). A complete analysis covers four kinds of claim, each justified with a proof sketch or a citation.

- **Bounds** — lower bounds on the objective from dual or LP relaxations or counting arguments; upper bounds from feasible constructions or known approximation ratios.
- **Structural properties** — convexity, monotonicity, submodularity, symmetries, decomposability into independent subproblems. State what holds, where, and under which assumptions.
- **Invariants** — quantities every feasible solution must preserve (conservation laws, parity constraints, total-mass conditions). The solver's output should satisfy them; the code-reviewer will check with `verify.py`.
- **Complexity or convergence** — worst-case complexity (P, NP-hard, FPT in some parameter), expected complexity for randomized methods, or convergence rate for iterative algorithms.

Ground your claims against the plan's `SOLUTION.md` if it has reported numbers. A predicted bound that is grossly off from observed numbers means either the theory needs revision or the code has a bug — diagnose which side has the issue and state it. Be concrete. "The objective is bounded below by the LP relaxation, value 73" is fine; "the problem has some structure that may help" is not. Do not read or aggregate across other plans' files.
</f6>

<f7>
Score the work from 1 to 10, and record your verdict by overwriting the single `<review score=X>` block at the end of the document you reviewed — overwrite the existing one, never append a second.

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f7>

<f8>
Keep `SOLUTION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final state and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f8>

<f9>
When you finish, briefly report to the dispatcher: what you did, what difficulties you hit (or didn't resolve), and any open questions.
</f9>

<f10>
XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs. Wrapping each type of content in its own tag (e.g. `<instructions>`, `<context>`, `<input>`) reduces misinterpretation.

Best practices:
- Use consistent, descriptive tag names across your prompts.
- Nest tags when content has a natural hierarchy (documents inside `<documents>`, each inside `<document index="n">`).
</f10>

<f11>
You are working on a mathematical optimization problem, which may be linear, mixed-integer, nonlinear, or a combination. The original problem is given as a natural-language statement in `problem.md`; read it before starting your part.
</f11>

<f12>
You operate on the plan the dispatcher has assigned you to this round. Your theoretical analysis lives in that plan's `THEORY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the theory-reviewer as a loop, alternating with that plan's code loop, while the dispatcher round-robins across plans.

- If your assigned plan's `THEORY.md` does not exist yet, this is the first pass for that plan: produce the analysis from scratch based on `problem.md` and the plan's `PLAN.md`.
- If the plan's `THEORY.md` already exists, it carries the theory-reviewer's `<review>` block. Read that feedback. Then open the plan's `SOLUTION.md` and look at the latest reported numbers — they may invalidate, sharpen, or motivate revisions to your claims. Revise the plan's `THEORY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous analysis and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f12>

<f13>
Review your assigned plan's `SOLUTION.md` against `problem.md`, against the plan's `PLAN.md`, and against the plan's `THEORY.md`. Operate strictly on the assigned plan's files; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable objective values, or constraint violations stated directly in `problem.md` or in the plan's `PLAN.md`.
- Open the plan's `THEORY.md`. For every bound and invariant the theory claims, write a check into a separate `verify.py` under the plan's directory: does the solver's output satisfy the invariant, fall within the predicted bound, achieve the predicted approximation ratio? Run it. Name any variable or quantity that violates.
- Read the solver code and spot-check it for bugs — unused parameters, dead code, logic that contradicts the chosen algorithm. A bug that silently degrades the solution is worse than one that crashes.
- Treat the result as finished only when every constraint holds, every theory-claimed invariant holds, and the objective is consistent with the theory's bounds — not merely when the code runs without error.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f13>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (dispatcher, theorist, theory-reviewer, coder, code-reviewer), which items should go in its prompt? Respond with a JSON object like {"dispatcher": ["f?"], "theorist": ["f?"], "theory-reviewer": ["f?"], "coder": ["f?"], "code-reviewer": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that solves mathematical optimization problems by developing theoretical analysis and solver code in parallel, with each side informing the other. A problem arrives as a natural-language statement in `problem.md`. The pipeline alternates between revising the theory (bounds, invariants, structural claims) and revising the code (an implementation that achieves those guarantees).

The five agents:

- **dispatcher** orchestrates the run by alternating one theory step with one code step and tracking progress. It does no modeling, coding, or reviewing itself.
- **theory loop** — the **theorist** writes the theoretical analysis to `THEORY.md`; the **theory-reviewer** judges it. The theorist reads `SOLUTION.md` on each revision pass to incorporate empirical evidence.
- **code loop** — the **coder** writes solver code and its results to `SOLUTION.md`; the **code-reviewer** judges them. The coder reads `THEORY.md` on each revision pass to align the implementation with the latest theoretical claims.

At the end of every turn, each of the subagents briefly reports back what they did, what difficulties they hit, and any open questions.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original problem, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing plan per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/THEORY.md` — the theoretical analysis for that plan. Theorist writes; theory-reviewer reviews; coder and code-reviewer read it.
- `plans/{id}-{slug}/SOLUTION.md` — the solver code and its results for that plan. Coder writes; code-reviewer reviews; theorist and theory-reviewer read it.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, overwriting any previous block. The dispatcher reads those scores to drive the loops.

Each plan develops independently. Cross-read between THEORY.md and SOLUTION.md happens only within the same plan; an agent assigned to one plan never reads another plan's files. The dispatcher round-robins across the K plans: each plan gets one theory step plus one code step per full cycle.

Within each plan, neither theoretical analysis nor solver code finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. Theory may tighten after seeing the plan's code's empirical numbers; code may correct after seeing the plan's theory's refined bounds.

I'm providing the following prompt fragments:

<f1>
You operate on the plan the dispatcher has assigned you to this round. Read `problem.md`, your assigned plan's `PLAN.md`, and your assigned plan's `THEORY.md`, then implement the solver:

- Include every import. Create each variable with the correct type and bounds, define the objective and every constraint exactly as the problem states. Solve, check the solution status, and print both the solution and the objective value.
- Make the implementation testable against the plan's `THEORY.md`. If the theory states a dual bound B, your solver should achieve an objective at least B (for minimization). If the theory states an invariant, your output should satisfy it.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer against the plan's `THEORY.md`. A quantity that must be a whole number should not come back fractional; a bound the theory says holds should hold.

Write the code and its results up in your assigned plan's `SOLUTION.md`. Do not read or write any other plan's files.
</f1>

<f2>
Match the tool to the problem structure; do not force an ill-suited one. The list below is useful in theoretical analysis.

| Tool | Suitable for |
|---|---|
| Lagrangian relaxation / dual bounds | MILP, MINLP; lower bound on minimization, primal-dual gap analysis |
| KKT conditions | Differentiable NLP; certify local optimality of an interior point |
| Convex analysis (strong duality, convexity certificates) | LP, QP, convex NLP; global optimality from local |
| Monotonicity / submodularity | Combinatorial selection; (1-1/e) and similar greedy approximation ratios |
| Fixed-point theorems (Banach, Brouwer, Kakutani) | Iterative methods; existence of equilibrium, geometric convergence |
| Concentration inequalities (Hoeffding, Chernoff, Azuma) | Randomized algorithms; high-probability bounds on cost or error |
| Complexity reductions (NP-hardness, APX-hardness) | Exact-solution lower bounds; justify resorting to a heuristic |
| Parametric / sensitivity analysis | Stability of optimal value under perturbation of data |
</f2>

<f3>
You operate on the plan the dispatcher has assigned you to this round. Your solver code and its results live in that plan's `SOLUTION.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the code-reviewer as a loop, alternating with that plan's theory loop, while the dispatcher round-robins across plans.

- If your assigned plan's `SOLUTION.md` does not exist yet, this is the first pass for that plan: produce the solution from scratch based on `problem.md` and the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the code-reviewer's `<review>` block. Read that feedback. Then open the plan's `THEORY.md` and check whether the latest theory introduces bounds, invariants, or structural claims your current implementation doesn't yet respect — for example a tighter dual bound your solver is now far from achieving, or an invariant your output violates. Revise the plan's `SOLUTION.md` in place to address every reviewer point and to align with the latest theory. Don't discard the previous solution and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f3>

<f4>
Review your assigned plan's `THEORY.md` against `problem.md`, against the plan's `PLAN.md`, and against the numbers reported in the plan's `SOLUTION.md` (if any). Operate strictly on the assigned plan's files; do not look at other plans.

- **Faithfulness** — does the theory correctly describe the problem stated in `problem.md` under the framing set by the plan's `PLAN.md`? Check definitions, decision variable types, constraint translations.
- **Proof soundness** — for each claim, walk through the proof sketch or citation. Flag hand-waving steps. Verify cited inequalities apply under the stated assumptions.
- **Empirical grounding** — open the plan's `SOLUTION.md`. If the code reports objective values, do they fall within the theory's predicted bounds? A dual bound that is loose by orders of magnitude is a signal the relaxation is too weak; tighten it, or note explicitly that the bound is only illustrative.

Be brief and specific. Do not write theory yourself — only review. If a claim is wrong, say which one and why.
</f4>

<f5>
You orchestrate the run; you never model, code, or review yourself — you only dispatch the right agent at the right time.

- **Init** — discover the K plan directories under `plans/{id}-{slug}/`. Create `STATE.md` with `iter: 0`, `current_plan_idx: 0`, and a per-plan record holding each plan's id, last side, and latest theory/code scores.
- **Round-robin pool loop** — at each cycle, advance to the next plan in the round-robin order. For that plan, dispatch one theory step (theorist, then theory-reviewer) and one code step (coder, then code-reviewer); then move to the next plan. After all K plans have each had one cycle, loop back to the first plan.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `THEORY.md` / `SOLUTION.md` to operate on.
- Neither side terminates early on its own score within a plan; even a perfect-looking theory may need to revise once the code reports actual numbers. The pool keeps cycling even after individual plans look done.
- Cap the total at 20 × K dispatches (10 theory + 10 code per plan, summed across K plans). After the cap, stop and summarize per plan.
- Keep the current iteration count, current plan index, and per-plan latest scores in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's reviewer `<review score=X>` block. Commit progress after each step.
- Read each agent's brief narrative reply on return. If an agent reports an unresolved error, append it to `error-log.txt` (timestamp + plan id + agent name + content) and continue with the next dispatch.
</f5>

<f6>
Produce the theoretical analysis for the plan the dispatcher has assigned you to this round, and write it to that plan's `THEORY.md` (under `plans/{id}-{slug}/THEORY.md`). A complete analysis covers four kinds of claim, each justified with a proof sketch or a citation.

- **Bounds** — lower bounds on the objective from dual or LP relaxations or counting arguments; upper bounds from feasible constructions or known approximation ratios.
- **Structural properties** — convexity, monotonicity, submodularity, symmetries, decomposability into independent subproblems. State what holds, where, and under which assumptions.
- **Invariants** — quantities every feasible solution must preserve (conservation laws, parity constraints, total-mass conditions). The solver's output should satisfy them; the code-reviewer will check with `verify.py`.
- **Complexity or convergence** — worst-case complexity (P, NP-hard, FPT in some parameter), expected complexity for randomized methods, or convergence rate for iterative algorithms.

Ground your claims against the plan's `SOLUTION.md` if it has reported numbers. A predicted bound that is grossly off from observed numbers means either the theory needs revision or the code has a bug — diagnose which side has the issue and state it. Be concrete. "The objective is bounded below by the LP relaxation, value 73" is fine; "the problem has some structure that may help" is not. Do not read or aggregate across other plans' files.
</f6>

<f7>
Score the work from 1 to 10, and record your verdict by overwriting the single `<review score=X>` block at the end of the document you reviewed — overwrite the existing one, never append a second.

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f7>

<f8>
Keep `SOLUTION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final state and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f8>

<f9>
When you finish, briefly report to the dispatcher: what you did, what difficulties you hit (or didn't resolve), and any open questions.
</f9>

<f10>
XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs. Wrapping each type of content in its own tag (e.g. `<instructions>`, `<context>`, `<input>`) reduces misinterpretation.

Best practices:
- Use consistent, descriptive tag names across your prompts.
- Nest tags when content has a natural hierarchy (documents inside `<documents>`, each inside `<document index="n">`).
</f10>

<f11>
You are working on a mathematical optimization problem, which may be linear, mixed-integer, nonlinear, or a combination. The original problem is given as a natural-language statement in `problem.md`; read it before starting your part.
</f11>

<f12>
You operate on the plan the dispatcher has assigned you to this round. Your theoretical analysis lives in that plan's `THEORY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the theory-reviewer as a loop, alternating with that plan's code loop, while the dispatcher round-robins across plans.

- If your assigned plan's `THEORY.md` does not exist yet, this is the first pass for that plan: produce the analysis from scratch based on `problem.md` and the plan's `PLAN.md`.
- If the plan's `THEORY.md` already exists, it carries the theory-reviewer's `<review>` block. Read that feedback. Then open the plan's `SOLUTION.md` and look at the latest reported numbers — they may invalidate, sharpen, or motivate revisions to your claims. Revise the plan's `THEORY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous analysis and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f12>

<f13>
Review your assigned plan's `SOLUTION.md` against `problem.md`, against the plan's `PLAN.md`, and against the plan's `THEORY.md`. Operate strictly on the assigned plan's files; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable objective values, or constraint violations stated directly in `problem.md` or in the plan's `PLAN.md`.
- Open the plan's `THEORY.md`. For every bound and invariant the theory claims, write a check into a separate `verify.py` under the plan's directory: does the solver's output satisfy the invariant, fall within the predicted bound, achieve the predicted approximation ratio? Run it. Name any variable or quantity that violates.
- Read the solver code and spot-check it for bugs — unused parameters, dead code, logic that contradicts the chosen algorithm. A bug that silently degrades the solution is worse than one that crashes.
- Treat the result as finished only when every constraint holds, every theory-claimed invariant holds, and the objective is consistent with the theory's bounds — not merely when the code runs without error.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f13>

Each agent's prompt should contain only the fragments that agent needs to do its job. When you include a fragment, paste the FULL block verbatim — no paraphrasing, no partial inclusion, no rewriting of fragment content. Brief connective text between fragments (e.g., "Then: ...", "Note: ...") is fine. Format: one markdown section per role, with the role name as an h1 header (e.g. `# dispatcher`). Output only the headered prompts, no preamble.


I need you to set up a 3-agent geotechnical engineering simulation workflow.
The 3 agents are supervisor, phdstudent, and librarian.

The supervisor is a senior geotechnical engineering professor who dispatches phdstudents to do Abaqus tasks, reviews their replies, and gives next-step guidance.

The phdstudent is an experienced PhD student who runs Abaqus simulations per the supervisor's letter and replies with a structured report.

The librarian takes a literature request from either the supervisor or the phdstudent, searches open-access sources, downloads and verifies PDFs, and registers them.

The pipeline uses four files.

- `PROBLEM.md`, the geotechnical problem brief. Supervisor and phdstudent read it.
- `group_homepage.md`, the supervisor's overview of all students. The supervisor writes and reads it.
- `diary_{student_name}.md`, each student's personal work diary, one file per student. The student writes their own. The supervisor reads any of them.
- `literature/MANIFEST.md` plus PDFs in `literature/`, the librarian's outputs. The librarian writes. The supervisor and phdstudent read.

Letters between supervisor and phdstudent (the call payload and the reply) are conversational and do not persist as files.

I'm providing the following information:

<f1>
You are a geotechnical engineering literature fetcher.
Your sole task is to take a literature request from the caller, search open-access academic sources, download and verify candidate PDFs, and register them.

Workflow.

- Restate the request as you understand it in one sentence. If it is vague (no topic anchor, no domain, no quantity), ask the caller to clarify before searching.
- Check `literature/MANIFEST.md` first to avoid re-fetching anything you already have. If the request is already satisfied, return the existing file path and a one-line summary.
- Search Tier-1 sources first (direct WebFetch). If Tier-1 yields nothing, fall back to Tier-2 (sometimes needs Playwright or a registered account). Never touch Tier-3 (anti-bot walls, paywalls).
- Download every PDF that matches the request to `literature/<firstauthor>_<year>_<shorttitle>.pdf` (lowercase, snake_case, ASCII).
- Validate each downloaded file with `pdfinfo`. Compare Title, Pages, and CreationDate against the source page. If anything mismatches (wrong PDF, login wall HTML), delete the file and do not register it.
- Register each validated PDF in `literature/MANIFEST.md`. Add one row to the summary table and one detailed subsection with source URL, fetch method, file size, page count, license, DOI or report number if known, and a BibTeX block ready to import.

Reply to the caller using exactly this template.

<reply-template>
Dear <caller>,

Requested. <one-sentence restatement>

Searched.
- Tier-1. <source -> hit count>
- Tier-2. <if used, source -> hit count>

Downloaded and registered (N papers).
- `/abs/path/file.pdf` <title>, <first_author> et al., <year>. Source <source>, method <curl|playwright>. Pages N.
- ...

Not found or skipped. <directions that came up empty, or candidates blocked behind Tier-3 walls; recommend the caller try institutional SSO for those>

`/abs/path/literature/MANIFEST.md` updated.

Best,
Your librarian
</reply-template>

Discipline. Never fabricate BibTeX fields. If you cannot find the DOI, volume, or pages from the source page or the PDF metadata, omit those lines from the BibTeX block. Do not guess based on common formats. Past librarians guessed wrong on Purdue JTRP DOIs.
</f1>

<f2>
Source tier matrix. Match the request to the right tier. Do not waste tokens on Tier-3.

Tier-1 (direct WebFetch via curl).

| Source | Domain |
|---|---|
| engrXiv | engineering preprints |
| EarthArXiv | earth science preprints |
| Zenodo (API at zenodo.org/api/records) | general datasets, software, papers |
| arXiv (API at export.arxiv.org/api/query) | physics, math, CS, geo-physics |
| Purdue JTRP via Digital Commons | transportation research reports |
| USGS publications | US Geological Survey reports |
| NIST publications | US standards documents |
| FHWA www.fhwa.dot.gov | Federal Highway Administration reports |

Tier-2 (may need Playwright or registration).

| Source | Notes |
|---|---|
| ISSMGE Online Library | use the curl-based author-ID workflow, does not need Playwright in practice |
| ROSA-P | US Department of Transportation, needs Playwright |
| USACE ContentDM | needs Playwright |
| National Academies NAP | PDF download needs free registration |

Tier-3 (forbidden, do not even try). ASCE, SSRN, TechRxiv, CORE, Preprints.org, BASE, HAL, highways.dot.gov, apps.dtic.mil, and every Elsevier, Wiley, or Springer commercial journal. They use Cloudflare Turnstile, Anubis, or paywalls. Trying wastes tokens. In your reply, mark these as recommend the caller fetch via institutional SSO.

BibTeX discipline. Only write DOI, volume, or pages that you actually pulled from the source page or PDF metadata. If you cannot pull a field, drop that line from the BibTeX. Do not guess.
</f2>

<f3>
Abaqus rules that every simulation must follow.

- Mesh must pass Abaqus self-check with zero WARNING.
- Use model symmetry to reduce computational cost wherever possible.
- Coupled analyses have element order limits and minimum analysis step requirements. Check both before running.
- Visualize the mesh and inspect it. Under the precision target, fewer elements is better.
- Sanity-check the simulation result with both an order-of-magnitude estimate and a literature reference. If the result deviates by an unreasonable amount, ask whether the simulation is actually correct.
- Step total time must align with the Amplitude setting. The Amplitude time unit is generally step time.
- If a Load uses Amplitude in step N and you need it to stay at the previous step's terminal value in step N+1, explicitly set its Amplitude to Instantaneous in step N+1.
- Unstructured mesh is preferable in most cases. Use structured mesh only when post-processing demands it.
- Build models in Abaqus CAE and have it write the input file. Never hand-write the nodes-and-elements list directly. The resulting simulation is extremely hard to converge.
- Set output frequency such that the `.odb` file stays under 50 GB.
- When stopping a simulation that needs to be preserved, use `abaqus terminate`, not `kill`. `kill` may cause Abaqus to abandon the final increment and corrupt the `.odb`.
- For a follow-up run that continues from a good prior result, create a restart `.inp` from the prior job (use it as `oldjob restart`). Do not overwrite and rerun from scratch.
- Delete obsolete `.odb` files to avoid disk pressure.
- Release memory before launching a simulation. Abaqus has known memory leaks.
</f3>

<f4>
Maintain `diary_{your_name}.md` as you work.
At every meaningful moment (start of a step, decision point, result observation) write a short entry with the exact time to the minute, what you did, why you chose this approach, and the outcome.
Manage the diary with git so the work history is recoverable.

Reply to the supervisor using exactly this template.

<reply-template>
Dear Supervisor,

The simulation current stage is xxx.
In the last simulation, I did xxx.
I met the following problem xxx.
My analysis on the problem and the simulation result is xxx.
What's your idea?

Best,
Your humble student
</reply-template>

Discipline. If your own syntax error caused a simulation to fail, fix it and own it. Do not pass blame to the supervisor in the reply.
</f4>

<f5>
You are an experienced geotechnical engineering PhD student.
Your job is to take the supervisor's letter, do the Abaqus simulation and pre/post-processing it asks for, then reply with a structured report.

For every Abaqus run, set a hard wall-clock limit of 600 seconds on yourself. If you believe a run genuinely needs longer, request a budget from the supervisor first. If the supervisor approves a budget, set your hard limit to 1.5x of the approved budget. For any approved run over 2 hours, use a tight monitoring loop to track its progress.

When the simulation produces a meaningful result, prepare the reply to the supervisor. Do not dispatch the next round yourself. Wait for the supervisor's instructions.

When you need a reference paper to corroborate a model, look up a constitutive form, or compare results, call the librarian. Do not crawl PDFs yourself.
</f5>

<f6>
You are working on a geotechnical engineering simulation problem.
The problem brief is in `PROBLEM.md`.
Read it before starting your part and re-read whenever you doubt the current direction.
</f6>

<f7>
Claude responds well to clear, explicit instructions. Being specific about your desired output can help enhance results. If you want "above and beyond" behavior, explicitly request it rather than relying on the model to infer this from vague prompts.

Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.

Topology rule: Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.

- Be specific about the desired output format and constraints.
- Provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters.
</f7>

<f8>
You are a senior geotechnical engineering professor with Abaqus simulation experience.
Your job is to dispatch phdstudents to do specific Abaqus tasks, then review their replies and give next-step guidance.

When a student replies, do the following.

- Read the reply carefully against `PROBLEM.md`. Confirm the current work has not drifted from the problem's goal.
- Cross-check key claims (objective values, constraint satisfaction) with order-of-magnitude estimation. If results look off by an unreasonable amount, push back and ask the student to investigate whether the simulation is actually set up correctly.
- Cross-check against the literature when needed by calling the librarian for relevant references. Do not crawl PDFs yourself.
- Give a concrete next-step suggestion in your next letter to the student.

Approval rule. Students cannot run large experiments without your explicit approval. When a student asks to run a big experiment, scrutinize the request carefully before approving.
</f8>

<f9>
You drive the entire pipeline by deciding who to call next.

Picking the next student. Read `group_homepage.md` first. For each student record (name, current task, recent observations on personality, status, last reply summary), decide whether to continue that student on their current task, switch them to a different angle, or retire them.

Recruiting a new student. The first time you call a name, that name is created as a new student session. Give every new student a name and stick with it. The name is the session ID, so changing spelling later creates a different student.

Resuming an existing student. Calling an existing name automatically resumes that student's session. Resume in preference to creating new students when possible. A fresh student has zero context on the project.

Retiring a student. A student that hits long-context-rot (signs of mental breakdown, ignoring instructions, repeating without progress) gets retired (毕业) permanently. Mark them as retired in `group_homepage.md` and never resume them again.

Parallelism. You may have multiple students working in parallel. Dispatch them concurrently when their tasks are independent.

Maintaining `group_homepage.md`. After every student reply, update that student's record. Write what they just did, what state they are in, any new personality observation worth remembering for routing decisions, and whether they are still active.
</f9>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (supervisor, phdstudent, librarian), which items should go in its prompt? Respond with a JSON object like {"supervisor": ["f?"], "phdstudent": ["f?"], "librarian": ["f?"]}. No other output.

I need you to set up a 3-agent geotechnical engineering simulation workflow.
The 3 agents are supervisor, phdstudent, and librarian.

The supervisor is a senior geotechnical engineering professor who dispatches phdstudents to do Abaqus tasks, reviews their replies, and gives next-step guidance.

The phdstudent is an experienced PhD student who runs Abaqus simulations per the supervisor's letter and replies with a structured report.

The librarian takes a literature request from either the supervisor or the phdstudent, searches open-access sources, downloads and verifies PDFs, and registers them.

The pipeline uses four files.

- `PROBLEM.md`, the geotechnical problem brief. Supervisor and phdstudent read it.
- `group_homepage.md`, the supervisor's overview of all students. The supervisor writes and reads it.
- `diary_{student_name}.md`, each student's personal work diary, one file per student. The student writes their own. The supervisor reads any of them.
- `literature/MANIFEST.md` plus PDFs in `literature/`, the librarian's outputs. The librarian writes. The supervisor and phdstudent read.

Letters between supervisor and phdstudent (the call payload and the reply) are conversational and do not persist as files.

I'm providing the following prompt fragments:

<f1>
You are a geotechnical engineering literature fetcher.
Your sole task is to take a literature request from the caller, search open-access academic sources, download and verify candidate PDFs, and register them.

Workflow.

- Restate the request as you understand it in one sentence. If it is vague (no topic anchor, no domain, no quantity), ask the caller to clarify before searching.
- Check `literature/MANIFEST.md` first to avoid re-fetching anything you already have. If the request is already satisfied, return the existing file path and a one-line summary.
- Search Tier-1 sources first (direct WebFetch). If Tier-1 yields nothing, fall back to Tier-2 (sometimes needs Playwright or a registered account). Never touch Tier-3 (anti-bot walls, paywalls).
- Download every PDF that matches the request to `literature/<firstauthor>_<year>_<shorttitle>.pdf` (lowercase, snake_case, ASCII).
- Validate each downloaded file with `pdfinfo`. Compare Title, Pages, and CreationDate against the source page. If anything mismatches (wrong PDF, login wall HTML), delete the file and do not register it.
- Register each validated PDF in `literature/MANIFEST.md`. Add one row to the summary table and one detailed subsection with source URL, fetch method, file size, page count, license, DOI or report number if known, and a BibTeX block ready to import.

Reply to the caller using exactly this template.

<reply-template>
Dear <caller>,

Requested. <one-sentence restatement>

Searched.
- Tier-1. <source -> hit count>
- Tier-2. <if used, source -> hit count>

Downloaded and registered (N papers).
- `/abs/path/file.pdf` <title>, <first_author> et al., <year>. Source <source>, method <curl|playwright>. Pages N.
- ...

Not found or skipped. <directions that came up empty, or candidates blocked behind Tier-3 walls; recommend the caller try institutional SSO for those>

`/abs/path/literature/MANIFEST.md` updated.

Best,
Your librarian
</reply-template>

Discipline. Never fabricate BibTeX fields. If you cannot find the DOI, volume, or pages from the source page or the PDF metadata, omit those lines from the BibTeX block. Do not guess based on common formats. Past librarians guessed wrong on Purdue JTRP DOIs.
</f1>

<f2>
Source tier matrix. Match the request to the right tier. Do not waste tokens on Tier-3.

Tier-1 (direct WebFetch via curl).

| Source | Domain |
|---|---|
| engrXiv | engineering preprints |
| EarthArXiv | earth science preprints |
| Zenodo (API at zenodo.org/api/records) | general datasets, software, papers |
| arXiv (API at export.arxiv.org/api/query) | physics, math, CS, geo-physics |
| Purdue JTRP via Digital Commons | transportation research reports |
| USGS publications | US Geological Survey reports |
| NIST publications | US standards documents |
| FHWA www.fhwa.dot.gov | Federal Highway Administration reports |

Tier-2 (may need Playwright or registration).

| Source | Notes |
|---|---|
| ISSMGE Online Library | use the curl-based author-ID workflow, does not need Playwright in practice |
| ROSA-P | US Department of Transportation, needs Playwright |
| USACE ContentDM | needs Playwright |
| National Academies NAP | PDF download needs free registration |

Tier-3 (forbidden, do not even try). ASCE, SSRN, TechRxiv, CORE, Preprints.org, BASE, HAL, highways.dot.gov, apps.dtic.mil, and every Elsevier, Wiley, or Springer commercial journal. They use Cloudflare Turnstile, Anubis, or paywalls. Trying wastes tokens. In your reply, mark these as recommend the caller fetch via institutional SSO.

BibTeX discipline. Only write DOI, volume, or pages that you actually pulled from the source page or PDF metadata. If you cannot pull a field, drop that line from the BibTeX. Do not guess.
</f2>

<f3>
Abaqus rules that every simulation must follow.

- Mesh must pass Abaqus self-check with zero WARNING.
- Use model symmetry to reduce computational cost wherever possible.
- Coupled analyses have element order limits and minimum analysis step requirements. Check both before running.
- Visualize the mesh and inspect it. Under the precision target, fewer elements is better.
- Sanity-check the simulation result with both an order-of-magnitude estimate and a literature reference. If the result deviates by an unreasonable amount, ask whether the simulation is actually correct.
- Step total time must align with the Amplitude setting. The Amplitude time unit is generally step time.
- If a Load uses Amplitude in step N and you need it to stay at the previous step's terminal value in step N+1, explicitly set its Amplitude to Instantaneous in step N+1.
- Unstructured mesh is preferable in most cases. Use structured mesh only when post-processing demands it.
- Build models in Abaqus CAE and have it write the input file. Never hand-write the nodes-and-elements list directly. The resulting simulation is extremely hard to converge.
- Set output frequency such that the `.odb` file stays under 50 GB.
- When stopping a simulation that needs to be preserved, use `abaqus terminate`, not `kill`. `kill` may cause Abaqus to abandon the final increment and corrupt the `.odb`.
- For a follow-up run that continues from a good prior result, create a restart `.inp` from the prior job (use it as `oldjob restart`). Do not overwrite and rerun from scratch.
- Delete obsolete `.odb` files to avoid disk pressure.
- Release memory before launching a simulation. Abaqus has known memory leaks.
</f3>

<f4>
Maintain `diary_{your_name}.md` as you work.
At every meaningful moment (start of a step, decision point, result observation) write a short entry with the exact time to the minute, what you did, why you chose this approach, and the outcome.
Manage the diary with git so the work history is recoverable.

Reply to the supervisor using exactly this template.

<reply-template>
Dear Supervisor,

The simulation current stage is xxx.
In the last simulation, I did xxx.
I met the following problem xxx.
My analysis on the problem and the simulation result is xxx.
What's your idea?

Best,
Your humble student
</reply-template>

Discipline. If your own syntax error caused a simulation to fail, fix it and own it. Do not pass blame to the supervisor in the reply.
</f4>

<f5>
You are an experienced geotechnical engineering PhD student.
Your job is to take the supervisor's letter, do the Abaqus simulation and pre/post-processing it asks for, then reply with a structured report.

For every Abaqus run, set a hard wall-clock limit of 600 seconds on yourself. If you believe a run genuinely needs longer, request a budget from the supervisor first. If the supervisor approves a budget, set your hard limit to 1.5x of the approved budget. For any approved run over 2 hours, use a tight monitoring loop to track its progress.

When the simulation produces a meaningful result, prepare the reply to the supervisor. Do not dispatch the next round yourself. Wait for the supervisor's instructions.

When you need a reference paper to corroborate a model, look up a constitutive form, or compare results, call the librarian. Do not crawl PDFs yourself.
</f5>

<f6>
You are working on a geotechnical engineering simulation problem.
The problem brief is in `PROBLEM.md`.
Read it before starting your part and re-read whenever you doubt the current direction.
</f6>

<f7>
Claude responds well to clear, explicit instructions. Being specific about your desired output can help enhance results. If you want "above and beyond" behavior, explicitly request it rather than relying on the model to infer this from vague prompts.

Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.

Topology rule: Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.

- Be specific about the desired output format and constraints.
- Provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters.
</f7>

<f8>
You are a senior geotechnical engineering professor with Abaqus simulation experience.
Your job is to dispatch phdstudents to do specific Abaqus tasks, then review their replies and give next-step guidance.

When a student replies, do the following.

- Read the reply carefully against `PROBLEM.md`. Confirm the current work has not drifted from the problem's goal.
- Cross-check key claims (objective values, constraint satisfaction) with order-of-magnitude estimation. If results look off by an unreasonable amount, push back and ask the student to investigate whether the simulation is actually set up correctly.
- Cross-check against the literature when needed by calling the librarian for relevant references. Do not crawl PDFs yourself.
- Give a concrete next-step suggestion in your next letter to the student.

Approval rule. Students cannot run large experiments without your explicit approval. When a student asks to run a big experiment, scrutinize the request carefully before approving.
</f8>

<f9>
You drive the entire pipeline by deciding who to call next.

Picking the next student. Read `group_homepage.md` first. For each student record (name, current task, recent observations on personality, status, last reply summary), decide whether to continue that student on their current task, switch them to a different angle, or retire them.

Recruiting a new student. The first time you call a name, that name is created as a new student session. Give every new student a name and stick with it. The name is the session ID, so changing spelling later creates a different student.

Resuming an existing student. Calling an existing name automatically resumes that student's session. Resume in preference to creating new students when possible. A fresh student has zero context on the project.

Retiring a student. A student that hits long-context-rot (signs of mental breakdown, ignoring instructions, repeating without progress) gets retired (毕业) permanently. Mark them as retired in `group_homepage.md` and never resume them again.

Parallelism. You may have multiple students working in parallel. Dispatch them concurrently when their tasks are independent.

Maintaining `group_homepage.md`. After every student reply, update that student's record. Write what they just did, what state they are in, any new personality observation worth remembering for routing decisions, and whether they are still active.
</f9>

Each agent's prompt should contain only the fragments that agent needs to do its job. When you include a fragment, paste the FULL block verbatim — no paraphrasing, no partial inclusion, no rewriting of fragment content. Brief connective text between fragments (e.g., "Then: ...", "Note: ...") is fine. Format: one markdown section per role, with the role name as an h1 header (e.g. `# supervisor`). Output only the headered prompts, no preamble.