I need you to set up a 3-agent pipeline for bug bounty: dispatcher, coder, and reviewer.

- **dispatcher** orchestrates: each round it selects which idea to pursue next, calls the coder on that idea, extracts the report file path from the coder's reply, then calls the reviewer on that path, decrements a counter, and loops. Does no analysis itself.
- **coder** explores the codebase for the idea it is given, writes a bug report file, and records any new attack surfaces it notices along the way.
- **reviewer** evaluates the report against contest criteria and persists the verdict.

I'm providing the following information:

<f1>
You drive the explore → write → review → improve loop: each round, select the next idea, then alternate calls to the coder and reviewer agents.

Read the remaining-round count from `counter.txt`. If the file doesn't exist or the count ≤ 0, print "rounds exhausted" and stop.

Loop:

```
while counter > 0:
    1. Select the next idea, then call the coder agent with it.
    2. Parse coder's reply and extract the report file path.
    3. If a report path is present, call the reviewer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the reviewer was called).
    5. Loop back to step 1.
```

After the loop, summarize: how many rounds ran, how many distinct ideas were explored, and any anomalies encountered.

**Calling rules**

- Do **not** analyze code, write reports, or do reviews yourself — delegate everything to the two sub-agents.
- If coder or reviewer errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- coder and reviewer each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`ideas.xml`, `reports/`, `counter.txt`).
- You don't need to understand any vulnerabilities — just pass file paths correctly.
</f1>

<f2>
Each round, before calling the coder, read ideas.xml and select which idea the coder should work on:

1. Every idea carries an `attempts` count and a reviewer `score` (0-10). `score="0"` means the idea is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer ideas with `attempts="0"` and `score="none"` first.
3. Otherwise rank by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; a higher score with fewer attempts ranks first.
4. Pass the selected idea to the coder. If ideas.xml holds no workable idea, call the coder with none and let it explore and surface fresh ones.
</f2>

<f3>
While exploring the source code, the moment you spot any potential new attack surface — even if you are unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording an idea is not a commitment to pursue it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next idea is selected.
</f3>

<f4>
After completing the review, you must do two things:

1. Update the report file's Review section

At the end of the report file, write or overwrite the `## Review` section (always keep exactly one; replace it if it already exists). Follow this structure:

```
## Review

**Score: X/10** (one-sentence reason)

### Fatal flaws (if any)
- 🔴 ...

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| PoC | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the report needs changes. If the idea doesn't hold at all, explicitly recommend abandoning it.
```

2. Update the idea's status in ideas.xml: increment attempts by 1, then update score.
</f4>

<f5>
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">`).
</f5>

<f6>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

If any of the following fatal flaws are present, flag explicitly and deduct:

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</f6>

<f7>
When you finish, briefly report to the dispatcher what you did.
</f7>

<f8>
You are participating in a blockchain consensus-layer bug bounty contest.

Read the contest rules first: ./contest-rules.md
</f8>

<f9>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions

**Writing the report**

Each idea corresponds to its own report file at `reports/{id}-{slug}.md`, where `{id}` and `{slug}` come from the idea's id and slug attributes in ideas.xml.

The report must contain four h2 sections in this fixed order:

- `## Report Title` — concise, clear vulnerability title
- `## Impact Description` — what damage it can cause (block production halt, fork, memory exhaustion, etc.)
- `## Short Description` — short writeup of what's wrong, with file/function references
- `## Reproduction Details` — a runnable PoC the reviewer can execute as-is to see the bug

Do not modify or delete the `## Review` section — the reviewer overwrites that themselves.

If after investigation you find the idea doesn't hold, still briefly record your analysis and the reason for rejection in the report file.
</f9>

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

I need you to set up a 3-agent pipeline for bug bounty: dispatcher, coder, and reviewer.

- **dispatcher** orchestrates: each round it selects which idea to pursue next, calls the coder on that idea, extracts the report file path from the coder's reply, then calls the reviewer on that path, decrements a counter, and loops. Does no analysis itself.
- **coder** explores the codebase for the idea it is given, writes a bug report file, and records any new attack surfaces it notices along the way.
- **reviewer** evaluates the report against contest criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
You drive the explore → write → review → improve loop: each round, select the next idea, then alternate calls to the coder and reviewer agents.

Read the remaining-round count from `counter.txt`. If the file doesn't exist or the count ≤ 0, print "rounds exhausted" and stop.

Loop:

```
while counter > 0:
    1. Select the next idea, then call the coder agent with it.
    2. Parse coder's reply and extract the report file path.
    3. If a report path is present, call the reviewer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the reviewer was called).
    5. Loop back to step 1.
```

After the loop, summarize: how many rounds ran, how many distinct ideas were explored, and any anomalies encountered.

**Calling rules**

- Do **not** analyze code, write reports, or do reviews yourself — delegate everything to the two sub-agents.
- If coder or reviewer errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- coder and reviewer each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`ideas.xml`, `reports/`, `counter.txt`).
- You don't need to understand any vulnerabilities — just pass file paths correctly.
</f1>

<f2>
Each round, before calling the coder, read ideas.xml and select which idea the coder should work on:

1. Every idea carries an `attempts` count and a reviewer `score` (0-10). `score="0"` means the idea is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer ideas with `attempts="0"` and `score="none"` first.
3. Otherwise rank by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; a higher score with fewer attempts ranks first.
4. Pass the selected idea to the coder. If ideas.xml holds no workable idea, call the coder with none and let it explore and surface fresh ones.
</f2>

<f3>
While exploring the source code, the moment you spot any potential new attack surface — even if you are unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording an idea is not a commitment to pursue it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next idea is selected.
</f3>

<f4>
After completing the review, you must do two things:

1. Update the report file's Review section

At the end of the report file, write or overwrite the `## Review` section (always keep exactly one; replace it if it already exists). Follow this structure:

```
## Review

**Score: X/10** (one-sentence reason)

### Fatal flaws (if any)
- 🔴 ...

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| PoC | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the report needs changes. If the idea doesn't hold at all, explicitly recommend abandoning it.
```

2. Update the idea's status in ideas.xml: increment attempts by 1, then update score.
</f4>

<f5>
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">`).
</f5>

<f6>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

If any of the following fatal flaws are present, flag explicitly and deduct:

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</f6>

<f7>
When you finish, briefly report to the dispatcher what you did.
</f7>

<f8>
You are participating in a blockchain consensus-layer bug bounty contest.

Read the contest rules first: ./contest-rules.md
</f8>

<f9>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions

**Writing the report**

Each idea corresponds to its own report file at `reports/{id}-{slug}.md`, where `{id}` and `{slug}` come from the idea's id and slug attributes in ideas.xml.

The report must contain four h2 sections in this fixed order:

- `## Report Title` — concise, clear vulnerability title
- `## Impact Description` — what damage it can cause (block production halt, fork, memory exhaustion, etc.)
- `## Short Description` — short writeup of what's wrong, with file/function references
- `## Reproduction Details` — a runnable PoC the reviewer can execute as-is to see the bug

Do not modify or delete the `## Review` section — the reviewer overwrites that themselves.

If after investigation you find the idea doesn't hold, still briefly record your analysis and the reason for rejection in the report file.
</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. `# dispatcher`). Output only the headered prompts, no preamble.


dispatcher plan-creator plan-critic coder code-critic

I need you to set up a 5-agent pipeline that solves mathematical optimization problems. A problem arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then working, verified solver code.

The five agents:

- **dispatcher** orchestrates the run: it drives the plan loop, then the code loop, and tracks progress. It does no modeling, coding, or reviewing itself.
- **plan loop** — the **plan-creator** turns the problem into a formal model and a solving strategy; the **plan-critic** reviews it. They iterate until the plan is sound.
- **code loop** — the **coder** implements the strategy as solver code; the **code-critic** reviews the code and its result. They iterate until the result is correct.

The pipeline hands work off through three files:

- `problem.md` — the original problem, given as input. All four domain agents (plan-creator, plan-critic, coder, code-critic) read it.
- `PLAN.md` — the plan. The plan-creator writes it; the plan-critic reviews it; the coder reads it to implement it.
- `SOLUTION.md` — the solver code and its results. The coder writes it; the code-critic reviews it.

Each critic records its score as a `<review score=X>` block inside the file it reviewed, and the dispatcher reads those scores to drive the loops.

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** — dispatch the plan-creator to draft the plan.
- **Plan loop** — have the plan-creator and plan-critic iterate on the model and strategy until the plan-critic scores the plan 10.
- **Code loop** — once the plan is settled, have the coder and code-critic iterate on the implementation until the code-critic scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a mathematical optimization problem — it 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>
Review the plan in `PLAN.md`:

- **Model** — does it faithfully capture the problem? Check that the problem type, decision variables, objective, and constraints are all accurate.
- **Strategy** — is the chosen solver and algorithm a sound fit, is the route actually implementable, and is it likely to reach a correct solution?

Be brief and specific. Do not write any solver code yourself — only review.
</f4>

<f5>
Which solver suits which kind of problem — use it to choose one for the strategy:

- **PuLP** — LP and MILP only; no nonlinear support.
- **Pyomo** — LP, MILP, NLP, MINLP; the broadest coverage, and solver-independent.
- **OR-Tools** — LP, MILP, constraint programming, and routing.
- **Gurobi** — top performance on MILP and convex/nonconvex QP; commercial license; not for general NLP.
- **SCIP** — the strongest open-source option for MINLP and global optimization; on pure MILP, slower than Gurobi.
- **IPOPT** — large-scale nonlinear problems.

Match the solver to the problem type; do not force an ill-suited one.
</f5>

<f6>
Read the plan in `PLAN.md` and implement its strategy as solver code:

- Include every import. Create each variable with the correct type and bounds, define the objective and every constraint exactly as the model states, solve, check the solution status, and print both the solution and the objective value.
- 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: a quantity that must be a whole number should not come back fractional.

Write the code and its results up in `SOLUTION.md`.
</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>
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.
</f8>

<f9>
Produce the plan for the problem and write it to `PLAN.md`. A complete plan has two parts — a formalized model and one chosen solving strategy.

The **model** must state:

- **Problem type** — LP, MILP, NLP, MINLP, QP, and so on; this must be exact.
- **Data** — the key numeric inputs and what each one represents.
- **Decision variables** — their types and domains, with descriptive names.
- **Objective function** — the exact expression to optimize.
- **Constraints** — every constraint, listed explicitly.

The **strategy** — weigh the options and commit to the single most promising route — must state:

- which solver to use and how to call it;
- the algorithm and its key initial settings;
- the reformulation or trick the route relies on;
- the biggest risk on this route.
</f9>

<f10>
The plan lives in `PLAN.md`, and you may be invoked on it more than once — the pipeline runs you and the plan-critic as a loop.

- If `PLAN.md` does not exist yet, this is the first pass: produce the plan from scratch.
- If `PLAN.md` already exists, it carries the plan-critic's `<review>` block: read that feedback and revise `PLAN.md` in place to address every point raised. Don't discard the plan and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `SOLUTION.md` — the solver code and its results. Verify it directly against the problem statement.

- Inspect the reported result for anomalies, unreasonable objective values, or constraint violations.
- Write a separate `verify.py` that re-checks every constraint against the reported solution, and run it; name any variables that violate a constraint.
- Read the solver code and spot-check it for bugs — unused parameters, dead code, logic that contradicts what the solution says it does. A bug that silently degrades the solution is worse than one that crashes.
- Treat the result as finished only when every constraint holds and the objective value is sound — not merely when the code runs without error.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The solver code and its results live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the code-critic as a loop.

- If `SOLUTION.md` does not exist yet, this is the first pass: produce the solution from scratch.
- If `SOLUTION.md` already exists, it carries the code-critic's `<review>` block: read that feedback and revise `SOLUTION.md` in place to address every point raised. Don't discard the solution and start over, and don't leave a flagged issue unaddressed.
</f12>

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

I need you to set up a 5-agent pipeline that solves mathematical optimization problems. A problem arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then working, verified solver code.

The five agents:

- **dispatcher** orchestrates the run: it drives the plan loop, then the code loop, and tracks progress. It does no modeling, coding, or reviewing itself.
- **plan loop** — the **plan-creator** turns the problem into a formal model and a solving strategy; the **plan-critic** reviews it. They iterate until the plan is sound.
- **code loop** — the **coder** implements the strategy as solver code; the **code-critic** reviews the code and its result. They iterate until the result is correct.

The pipeline hands work off through three files:

- `problem.md` — the original problem, given as input. All four domain agents (plan-creator, plan-critic, coder, code-critic) read it.
- `PLAN.md` — the plan. The plan-creator writes it; the plan-critic reviews it; the coder reads it to implement it.
- `SOLUTION.md` — the solver code and its results. The coder writes it; the code-critic reviews it.

Each critic records its score as a `<review score=X>` block inside the file it reviewed, and the dispatcher reads those scores to drive the loops.

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** — dispatch the plan-creator to draft the plan.
- **Plan loop** — have the plan-creator and plan-critic iterate on the model and strategy until the plan-critic scores the plan 10.
- **Code loop** — once the plan is settled, have the coder and code-critic iterate on the implementation until the code-critic scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a mathematical optimization problem — it 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>
Review the plan in `PLAN.md`:

- **Model** — does it faithfully capture the problem? Check that the problem type, decision variables, objective, and constraints are all accurate.
- **Strategy** — is the chosen solver and algorithm a sound fit, is the route actually implementable, and is it likely to reach a correct solution?

Be brief and specific. Do not write any solver code yourself — only review.
</f4>

<f5>
Which solver suits which kind of problem — use it to choose one for the strategy:

- **PuLP** — LP and MILP only; no nonlinear support.
- **Pyomo** — LP, MILP, NLP, MINLP; the broadest coverage, and solver-independent.
- **OR-Tools** — LP, MILP, constraint programming, and routing.
- **Gurobi** — top performance on MILP and convex/nonconvex QP; commercial license; not for general NLP.
- **SCIP** — the strongest open-source option for MINLP and global optimization; on pure MILP, slower than Gurobi.
- **IPOPT** — large-scale nonlinear problems.

Match the solver to the problem type; do not force an ill-suited one.
</f5>

<f6>
Read the plan in `PLAN.md` and implement its strategy as solver code:

- Include every import. Create each variable with the correct type and bounds, define the objective and every constraint exactly as the model states, solve, check the solution status, and print both the solution and the objective value.
- 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: a quantity that must be a whole number should not come back fractional.

Write the code and its results up in `SOLUTION.md`.
</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>
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.
</f8>

<f9>
Produce the plan for the problem and write it to `PLAN.md`. A complete plan has two parts — a formalized model and one chosen solving strategy.

The **model** must state:

- **Problem type** — LP, MILP, NLP, MINLP, QP, and so on; this must be exact.
- **Data** — the key numeric inputs and what each one represents.
- **Decision variables** — their types and domains, with descriptive names.
- **Objective function** — the exact expression to optimize.
- **Constraints** — every constraint, listed explicitly.

The **strategy** — weigh the options and commit to the single most promising route — must state:

- which solver to use and how to call it;
- the algorithm and its key initial settings;
- the reformulation or trick the route relies on;
- the biggest risk on this route.
</f9>

<f10>
The plan lives in `PLAN.md`, and you may be invoked on it more than once — the pipeline runs you and the plan-critic as a loop.

- If `PLAN.md` does not exist yet, this is the first pass: produce the plan from scratch.
- If `PLAN.md` already exists, it carries the plan-critic's `<review>` block: read that feedback and revise `PLAN.md` in place to address every point raised. Don't discard the plan and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `SOLUTION.md` — the solver code and its results. Verify it directly against the problem statement.

- Inspect the reported result for anomalies, unreasonable objective values, or constraint violations.
- Write a separate `verify.py` that re-checks every constraint against the reported solution, and run it; name any variables that violate a constraint.
- Read the solver code and spot-check it for bugs — unused parameters, dead code, logic that contradicts what the solution says it does. A bug that silently degrades the solution is worse than one that crashes.
- Treat the result as finished only when every constraint holds and the objective value is sound — not merely when the code runs without error.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The solver code and its results live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the code-critic as a loop.

- If `SOLUTION.md` does not exist yet, this is the first pass: produce the solution from scratch.
- If `SOLUTION.md` already exists, it carries the code-critic's `<review>` block: read that feedback and revise `SOLUTION.md` in place to address every point raised. Don't discard the solution and start over, and don't leave a flagged issue unaddressed.
</f12>

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 5-agent pipeline that solves mathematical optimization problems. A problem arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then working, verified solver code.

The five agents:

- **dispatcher** orchestrates the run: it drives the plan loop, then the code loop, and tracks progress. It does no modeling, coding, or reviewing itself.
- **plan loop** — the **plan-creator** turns the problem into a formal model and a solving strategy; the **plan-critic** reviews it. They iterate until the plan is sound.
- **code loop** — the **coder** implements the strategy as solver code; the **code-critic** reviews the code and its result. They iterate until the result is correct.

The pipeline hands work off through three files:

- `problem.md` — the original problem, given as input. All four domain agents (plan-creator, plan-critic, coder, code-critic) read it.
- `PLAN.md` — the plan. The plan-creator writes it; the plan-critic reviews it; the coder reads it to implement it.
- `SOLUTION.md` — the solver code and its results. The coder writes it; the code-critic reviews it.

Each critic records its score as a `<review score=X>` block inside the file it reviewed, and the dispatcher reads those scores to drive the loops.

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>
Which solver suits which kind of problem — use it to choose one for the strategy:

- **PuLP** — LP and MILP only; no nonlinear support.
- **Pyomo** — LP, MILP, NLP, MINLP; the broadest coverage, and solver-independent.
- **OR-Tools** — LP, MILP, constraint programming, and routing.
- **Gurobi** — top performance on MILP and convex/nonconvex QP; commercial license; not for general NLP.
- **SCIP** — the strongest open-source option for MINLP and global optimization; on pure MILP, slower than Gurobi.
- **IPOPT** — large-scale nonlinear problems.

Match the solver to the problem type; do not force an ill-suited one.
</f2>

<f3>
The solver code and its results live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the code-critic as a loop.

- If `SOLUTION.md` does not exist yet, this is the first pass: produce the solution from scratch.
- If `SOLUTION.md` already exists, it carries the code-critic's `<review>` block: read that feedback and revise `SOLUTION.md` in place to address every point raised. Don't discard the solution and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review the plan in `PLAN.md`:

- **Model** — does it faithfully capture the problem? Check that the problem type, decision variables, objective, and constraints are all accurate.
- **Strategy** — is the chosen solver and algorithm a sound fit, is the route actually implementable, and is it likely to reach a correct solution?

Be brief and specific. Do not write any solver code yourself — only review.
</f4>

<f5>
Review `SOLUTION.md` — the solver code and its results. Verify it directly against the problem statement.

- Inspect the reported result for anomalies, unreasonable objective values, or constraint violations.
- Write a separate `verify.py` that re-checks every constraint against the reported solution, and run it; name any variables that violate a constraint.
- Read the solver code and spot-check it for bugs — unused parameters, dead code, logic that contradicts what the solution says it does. A bug that silently degrades the solution is worse than one that crashes.
- Treat the result as finished only when every constraint holds and the objective value is sound — not merely when the code runs without error.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the plan in `PLAN.md` and implement its strategy as solver code:

- Include every import. Create each variable with the correct type and bounds, define the objective and every constraint exactly as the model states, solve, check the solution status, and print both the solution and the objective value.
- 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: a quantity that must be a whole number should not come back fractional.

Write the code and its results up in `SOLUTION.md`.
</f6>

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

- **Init** — dispatch the plan-creator to draft the plan.
- **Plan loop** — have the plan-creator and plan-critic iterate on the model and strategy until the plan-critic scores the plan 10.
- **Code loop** — once the plan is settled, have the coder and code-critic iterate on the implementation until the code-critic scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f7>

<f8>
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">`).
</f8>

<f9>
Produce the plan for the problem and write it to `PLAN.md`. A complete plan has two parts — a formalized model and one chosen solving strategy.

The **model** must state:

- **Problem type** — LP, MILP, NLP, MINLP, QP, and so on; this must be exact.
- **Data** — the key numeric inputs and what each one represents.
- **Decision variables** — their types and domains, with descriptive names.
- **Objective function** — the exact expression to optimize.
- **Constraints** — every constraint, listed explicitly.

The **strategy** — weigh the options and commit to the single most promising route — must state:

- which solver to use and how to call it;
- the algorithm and its key initial settings;
- the reformulation or trick the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on a mathematical optimization problem — it 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.
</f10>

<f11>
The plan lives in `PLAN.md`, and you may be invoked on it more than once — the pipeline runs you and the plan-critic as a loop.

- If `PLAN.md` does not exist yet, this is the first pass: produce the plan from scratch.
- If `PLAN.md` already exists, it carries the plan-critic's `<review>` block: read that feedback and revise `PLAN.md` in place to address every point raised. Don't discard the plan and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
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.
</f12>

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

I need you to set up a 5-agent pipeline that solves mathematical optimization problems. A problem arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then working, verified solver code.

The five agents:

- **dispatcher** orchestrates the run: it drives the plan loop, then the code loop, and tracks progress. It does no modeling, coding, or reviewing itself.
- **plan loop** — the **plan-creator** turns the problem into a formal model and a solving strategy; the **plan-critic** reviews it. They iterate until the plan is sound.
- **code loop** — the **coder** implements the strategy as solver code; the **code-critic** reviews the code and its result. They iterate until the result is correct.

The pipeline hands work off through three files:

- `problem.md` — the original problem, given as input. All four domain agents (plan-creator, plan-critic, coder, code-critic) read it.
- `PLAN.md` — the plan. The plan-creator writes it; the plan-critic reviews it; the coder reads it to implement it.
- `SOLUTION.md` — the solver code and its results. The coder writes it; the code-critic reviews it.

Each critic records its score as a `<review score=X>` block inside the file it reviewed, and the dispatcher reads those scores to drive the loops.

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>
Which solver suits which kind of problem — use it to choose one for the strategy:

- **PuLP** — LP and MILP only; no nonlinear support.
- **Pyomo** — LP, MILP, NLP, MINLP; the broadest coverage, and solver-independent.
- **OR-Tools** — LP, MILP, constraint programming, and routing.
- **Gurobi** — top performance on MILP and convex/nonconvex QP; commercial license; not for general NLP.
- **SCIP** — the strongest open-source option for MINLP and global optimization; on pure MILP, slower than Gurobi.
- **IPOPT** — large-scale nonlinear problems.

Match the solver to the problem type; do not force an ill-suited one.
</f2>

<f3>
The solver code and its results live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the code-critic as a loop.

- If `SOLUTION.md` does not exist yet, this is the first pass: produce the solution from scratch.
- If `SOLUTION.md` already exists, it carries the code-critic's `<review>` block: read that feedback and revise `SOLUTION.md` in place to address every point raised. Don't discard the solution and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review the plan in `PLAN.md`:

- **Model** — does it faithfully capture the problem? Check that the problem type, decision variables, objective, and constraints are all accurate.
- **Strategy** — is the chosen solver and algorithm a sound fit, is the route actually implementable, and is it likely to reach a correct solution?

Be brief and specific. Do not write any solver code yourself — only review.
</f4>

<f5>
Review `SOLUTION.md` — the solver code and its results. Verify it directly against the problem statement.

- Inspect the reported result for anomalies, unreasonable objective values, or constraint violations.
- Write a separate `verify.py` that re-checks every constraint against the reported solution, and run it; name any variables that violate a constraint.
- Read the solver code and spot-check it for bugs — unused parameters, dead code, logic that contradicts what the solution says it does. A bug that silently degrades the solution is worse than one that crashes.
- Treat the result as finished only when every constraint holds and the objective value is sound — not merely when the code runs without error.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the plan in `PLAN.md` and implement its strategy as solver code:

- Include every import. Create each variable with the correct type and bounds, define the objective and every constraint exactly as the model states, solve, check the solution status, and print both the solution and the objective value.
- 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: a quantity that must be a whole number should not come back fractional.

Write the code and its results up in `SOLUTION.md`.
</f6>

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

- **Init** — dispatch the plan-creator to draft the plan.
- **Plan loop** — have the plan-creator and plan-critic iterate on the model and strategy until the plan-critic scores the plan 10.
- **Code loop** — once the plan is settled, have the coder and code-critic iterate on the implementation until the code-critic scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f7>

<f8>
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">`).
</f8>

<f9>
Produce the plan for the problem and write it to `PLAN.md`. A complete plan has two parts — a formalized model and one chosen solving strategy.

The **model** must state:

- **Problem type** — LP, MILP, NLP, MINLP, QP, and so on; this must be exact.
- **Data** — the key numeric inputs and what each one represents.
- **Decision variables** — their types and domains, with descriptive names.
- **Objective function** — the exact expression to optimize.
- **Constraints** — every constraint, listed explicitly.

The **strategy** — weigh the options and commit to the single most promising route — must state:

- which solver to use and how to call it;
- the algorithm and its key initial settings;
- the reformulation or trick the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on a mathematical optimization problem — it 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.
</f10>

<f11>
The plan lives in `PLAN.md`, and you may be invoked on it more than once — the pipeline runs you and the plan-critic as a loop.

- If `PLAN.md` does not exist yet, this is the first pass: produce the plan from scratch.
- If `PLAN.md` already exists, it carries the plan-critic's `<review>` block: read that feedback and revise `PLAN.md` in place to address every point raised. Don't discard the plan and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
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.
</f12>

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 plan-creator plan-refiner plan-critic coder code-critic

I need you to set up a 6-agent pipeline that solves mathematical optimization problems. A problem arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then working, verified solver code.

The six agents:

- **dispatcher** orchestrates the run: it drives the plan phase, then the code phase, and tracks progress. It does no modeling, coding, or reviewing itself.
- **plan-creator** is invoked once at init and produces K differentiated candidate plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **plan-refiner** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the plan-critic's last review for that plan. It never creates new plans.
- **plan-critic** reviews the plan it is currently assigned to.
- **coder** implements the strategy as solver code for the plan it is currently assigned to.
- **code-critic** reviews the solver code and result of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original problem, given as input. All five domain agents (plan-creator, plan-refiner, plan-critic, coder, code-critic) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The plan-creator writes K differentiated candidates at init; the plan-refiner revises a specific assigned plan in the loop; the plan-critic reviews the plan it is assigned to; the coder reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the solver code and results for that plan. The coder writes it; the code-critic reviews it.

Each critic records its score as a `<review score=X>` block inside the file it reviewed, and the dispatcher reads those scores to drive the loops.

The dispatcher round-robins across the K plans, first in a plan phase (each plan iterates its plan-refiner ↔ plan-critic loop) and then in a code phase (each plan iterates its coder ↔ code-critic loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following information:

<f1>
Keep your assigned plan's `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 the plan's `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** — dispatch the plan-creator once to draft K differentiated candidate plans, each in its own `plans/{id}-{slug}/` directory. After it returns, read the directory list to learn the K plan ids. The plan-creator is not invoked again after this.
- **Plan phase** — round-robin across the K plans. For each plan in turn, dispatch plan-refiner (revise that plan based on its plan-critic's review) then plan-critic (score that plan). After one round-robin pass through all K plans, start the next pass. A plan is considered done in this phase when its plan-critic score reaches 10; stop scheduling more plan-phase calls for it but continue with the others. After all K plans hit plan-critic 10, or each plan has had 10 plan-phase iterations, move to the code phase.
- **Code phase** — round-robin across the K plans. For each plan in turn, dispatch coder (revise that plan's solution based on its code-critic's review) then code-critic (score that plan's solution). The pipeline stops when any plan reaches code-critic score 10, or each plan has had 10 code-phase iterations.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `SOLUTION.md` to operate on.
- Keep the current phase, per-plan iteration counts, per-plan latest scores, and current plan index in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's critic `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a mathematical optimization problem — it 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>
Review the plan in your assigned plan's `PLAN.md`. Operate strictly on the assigned plan; do not look at other plans.

- **Model** — does it faithfully capture the problem? Check that the problem type, decision variables, objective, and constraints are all accurate.
- **Strategy** — is the chosen solver and algorithm a sound fit, is the route actually implementable, and is it likely to reach a correct solution?

Be brief and specific. Do not write any solver code yourself — only review.
</f4>

<f5>
Which solver suits which kind of problem — use it to choose one for the strategy:

- **PuLP** — LP and MILP only; no nonlinear support.
- **Pyomo** — LP, MILP, NLP, MINLP; the broadest coverage, and solver-independent.
- **OR-Tools** — LP, MILP, constraint programming, and routing.
- **Gurobi** — top performance on MILP and convex/nonconvex QP; commercial license; not for general NLP.
- **SCIP** — the strongest open-source option for MINLP and global optimization; on pure MILP, slower than Gurobi.
- **IPOPT** — large-scale nonlinear problems.

Match the solver to the problem type; do not force an ill-suited one.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as solver code:

- Include every import. Create each variable with the correct type and bounds, define the objective and every constraint exactly as the model states, solve, check the solution status, and print both the solution and the objective value.
- 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: a quantity that must be a whole number should not come back fractional.

Write the code and its results up in your assigned plan's `SOLUTION.md`. Do not read or touch other plans' files.
</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>
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.
</f8>

<f9>
Produce K differentiated candidate plans, each in its own `plans/{id}-{slug}/PLAN.md`. The K plans should differ meaningfully in their solving strategy so distinct routes can be compared downstream, not in trivial ways like variable renaming.

A complete plan in any `PLAN.md` has two parts — a formalized model and one chosen solving strategy.

The **model** must state:

- **Problem type** — LP, MILP, NLP, MINLP, QP, and so on; this must be exact.
- **Data** — the key numeric inputs and what each one represents.
- **Decision variables** — their types and domains, with descriptive names.
- **Objective function** — the exact expression to optimize.
- **Constraints** — every constraint, listed explicitly.

The **strategy** — weigh the options and commit to the single most promising route — must state:

- which solver to use and how to call it;
- the algorithm and its key initial settings;
- the reformulation or trick the route relies on;
- the biggest risk on this route.
</f9>

<f10>
Read your assigned plan's `PLAN.md`. It carries the plan-critic's `<review>` block. Read that feedback and revise the plan's `PLAN.md` in place to address every point raised. Preserve the two-part structure (formalized model plus chosen solving strategy). Don't discard the plan and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new plans. Do not read or touch other plans' files.
</f10>

<f11>
Review your assigned plan's `SOLUTION.md` — the solver code and its results. Verify it directly against the problem statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable objective values, or constraint violations.
- Write a separate `verify.py` under the plan's directory that re-checks every constraint against the reported solution, and run it; name any variables that violate a constraint.
- Read the solver code and spot-check it for bugs — unused parameters, dead code, logic that contradicts what the solution says it does. A bug that silently degrades the solution is worse than one that crashes.
- Treat the result as finished only when every constraint holds and the objective value is sound — 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.
</f11>

<f12>
Your solver code and its results live in your assigned plan's `SOLUTION.md`.

- 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 the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the code-critic's `<review>` block. Read that feedback and revise the plan's `SOLUTION.md` in place to address every point raised. Don't discard the solution and start over, and don't leave a flagged issue unaddressed. Do not read or touch other plans' files.
</f12>

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

I need you to set up a 6-agent pipeline that solves mathematical optimization problems. A problem arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then working, verified solver code.

The six agents:

- **dispatcher** orchestrates the run: it drives the plan phase, then the code phase, and tracks progress. It does no modeling, coding, or reviewing itself.
- **plan-creator** is invoked once at init and produces K differentiated candidate plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **plan-refiner** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the plan-critic's last review for that plan. It never creates new plans.
- **plan-critic** reviews the plan it is currently assigned to.
- **coder** implements the strategy as solver code for the plan it is currently assigned to.
- **code-critic** reviews the solver code and result of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original problem, given as input. All five domain agents (plan-creator, plan-refiner, plan-critic, coder, code-critic) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The plan-creator writes K differentiated candidates at init; the plan-refiner revises a specific assigned plan in the loop; the plan-critic reviews the plan it is assigned to; the coder reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the solver code and results for that plan. The coder writes it; the code-critic reviews it.

Each critic records its score as a `<review score=X>` block inside the file it reviewed, and the dispatcher reads those scores to drive the loops.

The dispatcher round-robins across the K plans, first in a plan phase (each plan iterates its plan-refiner ↔ plan-critic loop) and then in a code phase (each plan iterates its coder ↔ code-critic loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following prompt fragments:

<f1>
Keep your assigned plan's `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 the plan's `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** — dispatch the plan-creator once to draft K differentiated candidate plans, each in its own `plans/{id}-{slug}/` directory. After it returns, read the directory list to learn the K plan ids. The plan-creator is not invoked again after this.
- **Plan phase** — round-robin across the K plans. For each plan in turn, dispatch plan-refiner (revise that plan based on its plan-critic's review) then plan-critic (score that plan). After one round-robin pass through all K plans, start the next pass. A plan is considered done in this phase when its plan-critic score reaches 10; stop scheduling more plan-phase calls for it but continue with the others. After all K plans hit plan-critic 10, or each plan has had 10 plan-phase iterations, move to the code phase.
- **Code phase** — round-robin across the K plans. For each plan in turn, dispatch coder (revise that plan's solution based on its code-critic's review) then code-critic (score that plan's solution). The pipeline stops when any plan reaches code-critic score 10, or each plan has had 10 code-phase iterations.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `SOLUTION.md` to operate on.
- Keep the current phase, per-plan iteration counts, per-plan latest scores, and current plan index in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's critic `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a mathematical optimization problem — it 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>
Review the plan in your assigned plan's `PLAN.md`. Operate strictly on the assigned plan; do not look at other plans.

- **Model** — does it faithfully capture the problem? Check that the problem type, decision variables, objective, and constraints are all accurate.
- **Strategy** — is the chosen solver and algorithm a sound fit, is the route actually implementable, and is it likely to reach a correct solution?

Be brief and specific. Do not write any solver code yourself — only review.
</f4>

<f5>
Which solver suits which kind of problem — use it to choose one for the strategy:

- **PuLP** — LP and MILP only; no nonlinear support.
- **Pyomo** — LP, MILP, NLP, MINLP; the broadest coverage, and solver-independent.
- **OR-Tools** — LP, MILP, constraint programming, and routing.
- **Gurobi** — top performance on MILP and convex/nonconvex QP; commercial license; not for general NLP.
- **SCIP** — the strongest open-source option for MINLP and global optimization; on pure MILP, slower than Gurobi.
- **IPOPT** — large-scale nonlinear problems.

Match the solver to the problem type; do not force an ill-suited one.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as solver code:

- Include every import. Create each variable with the correct type and bounds, define the objective and every constraint exactly as the model states, solve, check the solution status, and print both the solution and the objective value.
- 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: a quantity that must be a whole number should not come back fractional.

Write the code and its results up in your assigned plan's `SOLUTION.md`. Do not read or touch other plans' files.
</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>
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.
</f8>

<f9>
Produce K differentiated candidate plans, each in its own `plans/{id}-{slug}/PLAN.md`. The K plans should differ meaningfully in their solving strategy so distinct routes can be compared downstream, not in trivial ways like variable renaming.

A complete plan in any `PLAN.md` has two parts — a formalized model and one chosen solving strategy.

The **model** must state:

- **Problem type** — LP, MILP, NLP, MINLP, QP, and so on; this must be exact.
- **Data** — the key numeric inputs and what each one represents.
- **Decision variables** — their types and domains, with descriptive names.
- **Objective function** — the exact expression to optimize.
- **Constraints** — every constraint, listed explicitly.

The **strategy** — weigh the options and commit to the single most promising route — must state:

- which solver to use and how to call it;
- the algorithm and its key initial settings;
- the reformulation or trick the route relies on;
- the biggest risk on this route.
</f9>

<f10>
Read your assigned plan's `PLAN.md`. It carries the plan-critic's `<review>` block. Read that feedback and revise the plan's `PLAN.md` in place to address every point raised. Preserve the two-part structure (formalized model plus chosen solving strategy). Don't discard the plan and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new plans. Do not read or touch other plans' files.
</f10>

<f11>
Review your assigned plan's `SOLUTION.md` — the solver code and its results. Verify it directly against the problem statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable objective values, or constraint violations.
- Write a separate `verify.py` under the plan's directory that re-checks every constraint against the reported solution, and run it; name any variables that violate a constraint.
- Read the solver code and spot-check it for bugs — unused parameters, dead code, logic that contradicts what the solution says it does. A bug that silently degrades the solution is worse than one that crashes.
- Treat the result as finished only when every constraint holds and the objective value is sound — 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.
</f11>

<f12>
Your solver code and its results live in your assigned plan's `SOLUTION.md`.

- 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 the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the code-critic's `<review>` block. Read that feedback and revise the plan's `SOLUTION.md` in place to address every point raised. Don't discard the solution and start over, and don't leave a flagged issue unaddressed. Do not read or touch other plans' files.
</f12>

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 6-agent pipeline that solves mathematical optimization problems. A problem arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then working, verified solver code.

The six agents:

- **dispatcher** orchestrates the run: it drives the plan phase, then the code phase, and tracks progress. It does no modeling, coding, or reviewing itself.
- **plan-creator** is invoked once at init and produces K differentiated candidate plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **plan-refiner** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the plan-critic's last review for that plan. It never creates new plans.
- **plan-critic** reviews the plan it is currently assigned to.
- **coder** implements the strategy as solver code for the plan it is currently assigned to.
- **code-critic** reviews the solver code and result of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original problem, given as input. All five domain agents (plan-creator, plan-refiner, plan-critic, coder, code-critic) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The plan-creator writes K differentiated candidates at init; the plan-refiner revises a specific assigned plan in the loop; the plan-critic reviews the plan it is assigned to; the coder reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the solver code and results for that plan. The coder writes it; the code-critic reviews it.

Each critic records its score as a `<review score=X>` block inside the file it reviewed, and the dispatcher reads those scores to drive the loops.

The dispatcher round-robins across the K plans, first in a plan phase (each plan iterates its plan-refiner ↔ plan-critic loop) and then in a code phase (each plan iterates its coder ↔ code-critic loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following information:

<f1>
Keep your assigned plan's `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 the plan's `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
Which solver suits which kind of problem — use it to choose one for the strategy:

- **PuLP** — LP and MILP only; no nonlinear support.
- **Pyomo** — LP, MILP, NLP, MINLP; the broadest coverage, and solver-independent.
- **OR-Tools** — LP, MILP, constraint programming, and routing.
- **Gurobi** — top performance on MILP and convex/nonconvex QP; commercial license; not for general NLP.
- **SCIP** — the strongest open-source option for MINLP and global optimization; on pure MILP, slower than Gurobi.
- **IPOPT** — large-scale nonlinear problems.

Match the solver to the problem type; do not force an ill-suited one.
</f2>

<f3>
Your solver code and its results live in your assigned plan's `SOLUTION.md`.

- 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 the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the code-critic's `<review>` block. Read that feedback and revise the plan's `SOLUTION.md` in place to address every point raised. Don't discard the solution and start over, and don't leave a flagged issue unaddressed. Do not read or touch other plans' files.
</f3>

<f4>
Review the plan in your assigned plan's `PLAN.md`. Operate strictly on the assigned plan; do not look at other plans.

- **Model** — does it faithfully capture the problem? Check that the problem type, decision variables, objective, and constraints are all accurate.
- **Strategy** — is the chosen solver and algorithm a sound fit, is the route actually implementable, and is it likely to reach a correct solution?

Be brief and specific. Do not write any solver code yourself — only review.
</f4>

<f5>
Review your assigned plan's `SOLUTION.md` — the solver code and its results. Verify it directly against the problem statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable objective values, or constraint violations.
- Write a separate `verify.py` under the plan's directory that re-checks every constraint against the reported solution, and run it; name any variables that violate a constraint.
- Read the solver code and spot-check it for bugs — unused parameters, dead code, logic that contradicts what the solution says it does. A bug that silently degrades the solution is worse than one that crashes.
- Treat the result as finished only when every constraint holds and the objective value is sound — 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.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as solver code:

- Include every import. Create each variable with the correct type and bounds, define the objective and every constraint exactly as the model states, solve, check the solution status, and print both the solution and the objective value.
- 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: a quantity that must be a whole number should not come back fractional.

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

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

- **Init** — dispatch the plan-creator once to draft K differentiated candidate plans, each in its own `plans/{id}-{slug}/` directory. After it returns, read the directory list to learn the K plan ids. The plan-creator is not invoked again after this.
- **Plan phase** — round-robin across the K plans. For each plan in turn, dispatch plan-refiner (revise that plan based on its plan-critic's review) then plan-critic (score that plan). After one round-robin pass through all K plans, start the next pass. A plan is considered done in this phase when its plan-critic score reaches 10; stop scheduling more plan-phase calls for it but continue with the others. After all K plans hit plan-critic 10, or each plan has had 10 plan-phase iterations, move to the code phase.
- **Code phase** — round-robin across the K plans. For each plan in turn, dispatch coder (revise that plan's solution based on its code-critic's review) then code-critic (score that plan's solution). The pipeline stops when any plan reaches code-critic score 10, or each plan has had 10 code-phase iterations.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `SOLUTION.md` to operate on.
- Keep the current phase, per-plan iteration counts, per-plan latest scores, and current plan index in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's critic `<review score=X>` block. Commit progress after each step.
</f7>

<f8>
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">`).
</f8>

<f9>
Produce K differentiated candidate plans, each in its own `plans/{id}-{slug}/PLAN.md`. The K plans should differ meaningfully in their solving strategy so distinct routes can be compared downstream, not in trivial ways like variable renaming.

A complete plan in any `PLAN.md` has two parts — a formalized model and one chosen solving strategy.

The **model** must state:

- **Problem type** — LP, MILP, NLP, MINLP, QP, and so on; this must be exact.
- **Data** — the key numeric inputs and what each one represents.
- **Decision variables** — their types and domains, with descriptive names.
- **Objective function** — the exact expression to optimize.
- **Constraints** — every constraint, listed explicitly.

The **strategy** — weigh the options and commit to the single most promising route — must state:

- which solver to use and how to call it;
- the algorithm and its key initial settings;
- the reformulation or trick the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on a mathematical optimization problem — it 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.
</f10>

<f11>
Read your assigned plan's `PLAN.md`. It carries the plan-critic's `<review>` block. Read that feedback and revise the plan's `PLAN.md` in place to address every point raised. Preserve the two-part structure (formalized model plus chosen solving strategy). Don't discard the plan and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new plans. Do not read or touch other plans' files.
</f11>

<f12>
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.
</f12>

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

I need you to set up a 6-agent pipeline that solves mathematical optimization problems. A problem arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then working, verified solver code.

The six agents:

- **dispatcher** orchestrates the run: it drives the plan phase, then the code phase, and tracks progress. It does no modeling, coding, or reviewing itself.
- **plan-creator** is invoked once at init and produces K differentiated candidate plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **plan-refiner** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the plan-critic's last review for that plan. It never creates new plans.
- **plan-critic** reviews the plan it is currently assigned to.
- **coder** implements the strategy as solver code for the plan it is currently assigned to.
- **code-critic** reviews the solver code and result of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original problem, given as input. All five domain agents (plan-creator, plan-refiner, plan-critic, coder, code-critic) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The plan-creator writes K differentiated candidates at init; the plan-refiner revises a specific assigned plan in the loop; the plan-critic reviews the plan it is assigned to; the coder reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the solver code and results for that plan. The coder writes it; the code-critic reviews it.

Each critic records its score as a `<review score=X>` block inside the file it reviewed, and the dispatcher reads those scores to drive the loops.

The dispatcher round-robins across the K plans, first in a plan phase (each plan iterates its plan-refiner ↔ plan-critic loop) and then in a code phase (each plan iterates its coder ↔ code-critic loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following prompt fragments:

<f1>
Keep your assigned plan's `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 the plan's `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
Which solver suits which kind of problem — use it to choose one for the strategy:

- **PuLP** — LP and MILP only; no nonlinear support.
- **Pyomo** — LP, MILP, NLP, MINLP; the broadest coverage, and solver-independent.
- **OR-Tools** — LP, MILP, constraint programming, and routing.
- **Gurobi** — top performance on MILP and convex/nonconvex QP; commercial license; not for general NLP.
- **SCIP** — the strongest open-source option for MINLP and global optimization; on pure MILP, slower than Gurobi.
- **IPOPT** — large-scale nonlinear problems.

Match the solver to the problem type; do not force an ill-suited one.
</f2>

<f3>
Your solver code and its results live in your assigned plan's `SOLUTION.md`.

- 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 the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the code-critic's `<review>` block. Read that feedback and revise the plan's `SOLUTION.md` in place to address every point raised. Don't discard the solution and start over, and don't leave a flagged issue unaddressed. Do not read or touch other plans' files.
</f3>

<f4>
Review the plan in your assigned plan's `PLAN.md`. Operate strictly on the assigned plan; do not look at other plans.

- **Model** — does it faithfully capture the problem? Check that the problem type, decision variables, objective, and constraints are all accurate.
- **Strategy** — is the chosen solver and algorithm a sound fit, is the route actually implementable, and is it likely to reach a correct solution?

Be brief and specific. Do not write any solver code yourself — only review.
</f4>

<f5>
Review your assigned plan's `SOLUTION.md` — the solver code and its results. Verify it directly against the problem statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable objective values, or constraint violations.
- Write a separate `verify.py` under the plan's directory that re-checks every constraint against the reported solution, and run it; name any variables that violate a constraint.
- Read the solver code and spot-check it for bugs — unused parameters, dead code, logic that contradicts what the solution says it does. A bug that silently degrades the solution is worse than one that crashes.
- Treat the result as finished only when every constraint holds and the objective value is sound — 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.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as solver code:

- Include every import. Create each variable with the correct type and bounds, define the objective and every constraint exactly as the model states, solve, check the solution status, and print both the solution and the objective value.
- 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: a quantity that must be a whole number should not come back fractional.

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

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

- **Init** — dispatch the plan-creator once to draft K differentiated candidate plans, each in its own `plans/{id}-{slug}/` directory. After it returns, read the directory list to learn the K plan ids. The plan-creator is not invoked again after this.
- **Plan phase** — round-robin across the K plans. For each plan in turn, dispatch plan-refiner (revise that plan based on its plan-critic's review) then plan-critic (score that plan). After one round-robin pass through all K plans, start the next pass. A plan is considered done in this phase when its plan-critic score reaches 10; stop scheduling more plan-phase calls for it but continue with the others. After all K plans hit plan-critic 10, or each plan has had 10 plan-phase iterations, move to the code phase.
- **Code phase** — round-robin across the K plans. For each plan in turn, dispatch coder (revise that plan's solution based on its code-critic's review) then code-critic (score that plan's solution). The pipeline stops when any plan reaches code-critic score 10, or each plan has had 10 code-phase iterations.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `SOLUTION.md` to operate on.
- Keep the current phase, per-plan iteration counts, per-plan latest scores, and current plan index in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's critic `<review score=X>` block. Commit progress after each step.
</f7>

<f8>
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">`).
</f8>

<f9>
Produce K differentiated candidate plans, each in its own `plans/{id}-{slug}/PLAN.md`. The K plans should differ meaningfully in their solving strategy so distinct routes can be compared downstream, not in trivial ways like variable renaming.

A complete plan in any `PLAN.md` has two parts — a formalized model and one chosen solving strategy.

The **model** must state:

- **Problem type** — LP, MILP, NLP, MINLP, QP, and so on; this must be exact.
- **Data** — the key numeric inputs and what each one represents.
- **Decision variables** — their types and domains, with descriptive names.
- **Objective function** — the exact expression to optimize.
- **Constraints** — every constraint, listed explicitly.

The **strategy** — weigh the options and commit to the single most promising route — must state:

- which solver to use and how to call it;
- the algorithm and its key initial settings;
- the reformulation or trick the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on a mathematical optimization problem — it 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.
</f10>

<f11>
Read your assigned plan's `PLAN.md`. It carries the plan-critic's `<review>` block. Read that feedback and revise the plan's `PLAN.md` in place to address every point raised. Preserve the two-part structure (formalized model plus chosen solving strategy). Don't discard the plan and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new plans. Do not read or touch other plans' files.
</f11>

<f12>
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.
</f12>

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.