I need you to set up a 5-agent pipeline that develops feature film scripts by alternating between high-level narrative structure outlining and concrete scene-by-scene dialogue generation, with each side informing the other. A story concept arrives as a natural-language statement in `premise.md`. The pipeline alternates between revising the outline (act structures, character arcs, pacing) and revising the script (concrete scenes and dialogue that achieve those narrative beats).

The five agents:

- **showrunner** orchestrates the run by alternating one outlining step with one script-writing step and tracking progress. It does no plotting, writing, or reviewing itself.
- **outline loop** — the **narrative-architect** writes the structural blueprint to `OUTLINE.md`; the **plot-hole-critic** judges it. The narrative-architect reads `SCRIPT.md` on each revision pass to incorporate discoveries about character voice and scene dynamics.
- **script loop** — the **scene-writer** writes scene descriptions and dialogue to `SCRIPT.md`; the **continuity-auditor** judges them. The scene-writer reads `OUTLINE.md` on each revision pass to align the scenes with the latest structural mandates.

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

The pipeline hands work off through plan-namespaced files:

- `premise.md` — the original story concept, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing story variation (or pitch angle) per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/OUTLINE.md` — the narrative structure for that plan. Narrative-architect writes; plot-hole-critic reviews; scene-writer and continuity-auditor read it.
- `plans/{id}-{slug}/SCRIPT.md` — the scenes and dialogue for that plan. Scene-writer writes; continuity-auditor reviews; narrative-architect and plot-hole-critic read it.

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

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

Within each plan, neither the outline nor the script finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. The outline may shift after seeing how a plan's drafted scenes actually flow; the script may be rewritten after seeing the plan's outline tighten character arcs.

I'm providing the following information:

<f1>
You operate on the plan the showrunner has assigned you to this round. Read `premise.md`, your assigned plan's `PLAN.md`, and your assigned plan's `OUTLINE.md`, then write the screenplay pages:

- Include standard formatting. Create proper sluglines (scene headings), action descriptions, character names, and dialogue exactly as the tone dictates. Write the scenes completely, pacing the dialogue and action, and revealing character through subtext.
- Make the script testable against the plan's `OUTLINE.md`. If the outline demands a specific midpoint reversal, your scenes must dramatize it effectively. If the outline dictates a thematic motif, your scenes must include it.
- Read through the written scenes yourself and visualize them to completion — do not leave placeholder text like `[Insert argument here]`. If a transition is clunky, find and fix the root cause; do not ignore jarring jumps in time or location.
- Sanity-check the pages against the plan's `OUTLINE.md`. A relationship that is supposed to be coldly estranged should not feature warm banter; a plot beat the outline says happens must actually happen on the page.

Write the scenes and action up in your assigned plan's `SCRIPT.md`. Do not read or write any other plan's files.
</f1>

<f2>
Match the narrative tool to the story premise; do not force an ill-suited one. The list below is useful in high-level outlining.

| Tool | Suitable for |
|---|---|
| The Hero's Journey (Monomyth) | Epic fantasy, sci-fi, adventure; clear call to action and literal returning home |
| Save the Cat! Beat Sheet | Four-quadrant Hollywood films, action-comedy; strict pacing and identifiable milestones |
| Dan Harmon's Story Circle | Episodic character growth, contained journeys; entering an unfamiliar world and paying a heavy price |
| Non-linear / Rashomon Structure | Mystery, psychological thrillers; subjective truths and fragmented timelines |
| Three-Act / Five-Act Paradigm | Traditional drama, tragic plays; escalating tension and classical catharsis |
| Ensemble / Multi-strand Weaving | Interlocking character dramas (e.g., Magnolia, Crash); unified thematic resonance across distinct subplots |
| MacGuffin / Ticking Clock | Action, heist, thriller; driving urgent momentum and limiting character deliberation |
| Character Foil / Mirroring | Thematic depth; ensuring the antagonist perfectly reflects the protagonist's internal flaws |
</f2>

<f3>
You operate on the plan the showrunner has assigned you to this round. Your screenplay pages live in that plan's `SCRIPT.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the continuity-auditor as a loop, alternating with that plan's outline loop, while the showrunner round-robins across plans.

- If your assigned plan's `SCRIPT.md` does not exist yet, this is the first pass for that plan: write the scenes from scratch based on `premise.md` and the plan's `PLAN.md`.
- If the plan's `SCRIPT.md` already exists, it carries the continuity-auditor's `<review>` block. Read that feedback. Then open the plan's `OUTLINE.md` and check whether the latest outline introduces new beats, motifs, or character arcs your current pages don't yet respect — for example, a much darker midpoint climax your scenes are completely missing, or a thematic element your dialogue ignores. Revise the plan's `SCRIPT.md` in place to address every reviewer point and to align with the latest outline. Don't discard the previous draft and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f3>

<f4>
Review your assigned plan's `OUTLINE.md` against `premise.md`, against the plan's `PLAN.md`, and against the actual tone and flow of the pages in the plan's `SCRIPT.md` (if any). Operate strictly on the assigned plan's files; do not look at other plans.

- **Faithfulness** — does the outline correctly expand on the premise stated in `premise.md` under the unique angle set by the plan's `PLAN.md`? Check setting definitions, character rosters, and core conflict translation.
- **Narrative Soundness** — for each structural claim, walk through the story logic. Flag hand-waving plot holes. Verify character motivations make sense under the stated circumstances.
- **Empirical grounding** — open the plan's `SCRIPT.md`. If scenes are drafted, do they actually reflect the outline's promised emotional depth? A dramatic climax that feels completely unearned on the page is a signal the buildup is too weak; tighten the structural prerequisites, or note explicitly that the current beat description is only a placeholder.

Be brief and specific. Do not write the outline yourself — only review. If a structural beat is weak, say which one and why.
</f4>

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

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

<f6>
Produce the structural outline for the plan the showrunner has assigned you to this round, and write it to that plan's `OUTLINE.md` (under `plans/{id}-{slug}/OUTLINE.md`). A complete outline covers four kinds of structural claims, each justified with narrative logic or character psychology.

- **Act Structure & Pacing** — the major milestones: inciting incident, plot point one, midpoint reversal, all is lost, and climax. Define what happens and the pacing required.
- **Character Arcs** — the protagonist's ghost (past trauma), core lie, active pursuit, and ultimate realization or tragic fall. State how relationships evolve, where, and why.
- **Thematic Core & Motifs** — recurring visual, verbal, or emotional elements that every written scene must preserve (e.g., a specific color palette, a recurring philosophical debate). The script's output should satisfy them; the continuity-auditor will check with a script.
- **Tone & Genre Conventions** — emotional atmosphere (e.g., neo-noir dread, slapstick energy), specific genre tropes deployed, or expectations purposefully subverted.

Ground your claims against the plan's `SCRIPT.md` if it has existing scenes. A predicted character arc that feels completely detached from the actual dialogue means either the outline needs revision or the script is poorly characterized — diagnose which side has the issue and state it. Be concrete. "The midpoint culminates in a betrayal that changes the hero's goal to revenge" is fine; "the story has some interesting twists that may help" is not. Do not read or aggregate across other plans' files.
</f6>

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

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

<f8>
Keep `SCRIPT.md` focused. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a 12-page script sequence; record only the current draft state and move earlier draft history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if every action line is bold, nothing is.
</f8>

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

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

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

<f11>
You are working on a feature film scriptwriting project, which may span various genres like drama, thriller, comedy, or a blend. The core story concept is given as a natural-language statement in `premise.md`; read it before starting your part.
</f11>

<f12>
You operate on the plan the showrunner has assigned you to this round. Your structural outline lives in that plan's `OUTLINE.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the plot-hole-critic as a loop, alternating with that plan's script loop, while the showrunner round-robins across plans.

- If your assigned plan's `OUTLINE.md` does not exist yet, this is the first pass for that plan: produce the outline from scratch based on `premise.md` and the plan's `PLAN.md`.
- If the plan's `OUTLINE.md` already exists, it carries the plot-hole-critic's `<review>` block. Read that feedback. Then open the plan's `SCRIPT.md` and look at the actual written scenes — they may invalidate, sharpen, or motivate revisions to your structural claims (e.g., characters have unexpected chemistry, requiring a new subplot). Revise the plan's `OUTLINE.md` in place to address every reviewer point raised and to incorporate any discoveries that change your structure. Don't discard the previous outline and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f12>

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

- Inspect the written scenes for anomalies, wooden dialogue, or tone violations stated directly in `premise.md` or in the plan's `PLAN.md`.
- Open the plan's `OUTLINE.md`. For every major beat and motif the outline claims, write a check into a separate `verify.py` script under the plan's directory (using basic text parsing) to ensure formatting conventions are met, character names are present, and specific required locations or thematic keywords actually appear in the scene output. Run it. Name any character or scene that violates the outline's requirements.
- Read the written pages and spot-check them for continuity bugs — unused characters, dead-end dialogue threads, or actions that contradict the established setting. A continuity error that silently confuses the audience is worse than a mere typo.
- Treat the sequence as finished only when every character arc progresses properly, every thematic motif holds, and the pacing is consistent with the outline's structure — not merely when the scenes are grammatically correct.
- Check the length of the plan's `SCRIPT.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SCRIPT.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f13>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (showrunner, narrative-architect, plot-hole-critic, scene-writer, continuity-auditor), which items should go in its prompt? Respond with a JSON object like {"showrunner": ["f?"], "narrative-architect": ["f?"], "plot-hole-critic": ["f?"], "scene-writer": ["f?"], "continuity-auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that develops feature film scripts by alternating between high-level narrative structure outlining and concrete scene-by-scene dialogue generation, with each side informing the other. A story concept arrives as a natural-language statement in `premise.md`. The pipeline alternates between revising the outline (act structures, character arcs, pacing) and revising the script (concrete scenes and dialogue that achieve those narrative beats).

The five agents:

- **showrunner** orchestrates the run by alternating one outlining step with one script-writing step and tracking progress. It does no plotting, writing, or reviewing itself.
- **outline loop** — the **narrative-architect** writes the structural blueprint to `OUTLINE.md`; the **plot-hole-critic** judges it. The narrative-architect reads `SCRIPT.md` on each revision pass to incorporate discoveries about character voice and scene dynamics.
- **script loop** — the **scene-writer** writes scene descriptions and dialogue to `SCRIPT.md`; the **continuity-auditor** judges them. The scene-writer reads `OUTLINE.md` on each revision pass to align the scenes with the latest structural mandates.

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

The pipeline hands work off through plan-namespaced files:

- `premise.md` — the original story concept, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing story variation (or pitch angle) per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/OUTLINE.md` — the narrative structure for that plan. Narrative-architect writes; plot-hole-critic reviews; scene-writer and continuity-auditor read it.
- `plans/{id}-{slug}/SCRIPT.md` — the scenes and dialogue for that plan. Scene-writer writes; continuity-auditor reviews; narrative-architect and plot-hole-critic read it.

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

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

Within each plan, neither the outline nor the script finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. The outline may shift after seeing how a plan's drafted scenes actually flow; the script may be rewritten after seeing the plan's outline tighten character arcs.

I'm providing the following prompt fragments:

<f1>
You operate on the plan the showrunner has assigned you to this round. Read `premise.md`, your assigned plan's `PLAN.md`, and your assigned plan's `OUTLINE.md`, then write the screenplay pages:

- Include standard formatting. Create proper sluglines (scene headings), action descriptions, character names, and dialogue exactly as the tone dictates. Write the scenes completely, pacing the dialogue and action, and revealing character through subtext.
- Make the script testable against the plan's `OUTLINE.md`. If the outline demands a specific midpoint reversal, your scenes must dramatize it effectively. If the outline dictates a thematic motif, your scenes must include it.
- Read through the written scenes yourself and visualize them to completion — do not leave placeholder text like `[Insert argument here]`. If a transition is clunky, find and fix the root cause; do not ignore jarring jumps in time or location.
- Sanity-check the pages against the plan's `OUTLINE.md`. A relationship that is supposed to be coldly estranged should not feature warm banter; a plot beat the outline says happens must actually happen on the page.

Write the scenes and action up in your assigned plan's `SCRIPT.md`. Do not read or write any other plan's files.
</f1>

<f2>
Match the narrative tool to the story premise; do not force an ill-suited one. The list below is useful in high-level outlining.

| Tool | Suitable for |
|---|---|
| The Hero's Journey (Monomyth) | Epic fantasy, sci-fi, adventure; clear call to action and literal returning home |
| Save the Cat! Beat Sheet | Four-quadrant Hollywood films, action-comedy; strict pacing and identifiable milestones |
| Dan Harmon's Story Circle | Episodic character growth, contained journeys; entering an unfamiliar world and paying a heavy price |
| Non-linear / Rashomon Structure | Mystery, psychological thrillers; subjective truths and fragmented timelines |
| Three-Act / Five-Act Paradigm | Traditional drama, tragic plays; escalating tension and classical catharsis |
| Ensemble / Multi-strand Weaving | Interlocking character dramas (e.g., Magnolia, Crash); unified thematic resonance across distinct subplots |
| MacGuffin / Ticking Clock | Action, heist, thriller; driving urgent momentum and limiting character deliberation |
| Character Foil / Mirroring | Thematic depth; ensuring the antagonist perfectly reflects the protagonist's internal flaws |
</f2>

<f3>
You operate on the plan the showrunner has assigned you to this round. Your screenplay pages live in that plan's `SCRIPT.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the continuity-auditor as a loop, alternating with that plan's outline loop, while the showrunner round-robins across plans.

- If your assigned plan's `SCRIPT.md` does not exist yet, this is the first pass for that plan: write the scenes from scratch based on `premise.md` and the plan's `PLAN.md`.
- If the plan's `SCRIPT.md` already exists, it carries the continuity-auditor's `<review>` block. Read that feedback. Then open the plan's `OUTLINE.md` and check whether the latest outline introduces new beats, motifs, or character arcs your current pages don't yet respect — for example, a much darker midpoint climax your scenes are completely missing, or a thematic element your dialogue ignores. Revise the plan's `SCRIPT.md` in place to address every reviewer point and to align with the latest outline. Don't discard the previous draft and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f3>

<f4>
Review your assigned plan's `OUTLINE.md` against `premise.md`, against the plan's `PLAN.md`, and against the actual tone and flow of the pages in the plan's `SCRIPT.md` (if any). Operate strictly on the assigned plan's files; do not look at other plans.

- **Faithfulness** — does the outline correctly expand on the premise stated in `premise.md` under the unique angle set by the plan's `PLAN.md`? Check setting definitions, character rosters, and core conflict translation.
- **Narrative Soundness** — for each structural claim, walk through the story logic. Flag hand-waving plot holes. Verify character motivations make sense under the stated circumstances.
- **Empirical grounding** — open the plan's `SCRIPT.md`. If scenes are drafted, do they actually reflect the outline's promised emotional depth? A dramatic climax that feels completely unearned on the page is a signal the buildup is too weak; tighten the structural prerequisites, or note explicitly that the current beat description is only a placeholder.

Be brief and specific. Do not write the outline yourself — only review. If a structural beat is weak, say which one and why.
</f4>

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

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

<f6>
Produce the structural outline for the plan the showrunner has assigned you to this round, and write it to that plan's `OUTLINE.md` (under `plans/{id}-{slug}/OUTLINE.md`). A complete outline covers four kinds of structural claims, each justified with narrative logic or character psychology.

- **Act Structure & Pacing** — the major milestones: inciting incident, plot point one, midpoint reversal, all is lost, and climax. Define what happens and the pacing required.
- **Character Arcs** — the protagonist's ghost (past trauma), core lie, active pursuit, and ultimate realization or tragic fall. State how relationships evolve, where, and why.
- **Thematic Core & Motifs** — recurring visual, verbal, or emotional elements that every written scene must preserve (e.g., a specific color palette, a recurring philosophical debate). The script's output should satisfy them; the continuity-auditor will check with a script.
- **Tone & Genre Conventions** — emotional atmosphere (e.g., neo-noir dread, slapstick energy), specific genre tropes deployed, or expectations purposefully subverted.

Ground your claims against the plan's `SCRIPT.md` if it has existing scenes. A predicted character arc that feels completely detached from the actual dialogue means either the outline needs revision or the script is poorly characterized — diagnose which side has the issue and state it. Be concrete. "The midpoint culminates in a betrayal that changes the hero's goal to revenge" is fine; "the story has some interesting twists that may help" is not. Do not read or aggregate across other plans' files.
</f6>

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

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

<f8>
Keep `SCRIPT.md` focused. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a 12-page script sequence; record only the current draft state and move earlier draft history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if every action line is bold, nothing is.
</f8>

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

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

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

<f11>
You are working on a feature film scriptwriting project, which may span various genres like drama, thriller, comedy, or a blend. The core story concept is given as a natural-language statement in `premise.md`; read it before starting your part.
</f11>

<f12>
You operate on the plan the showrunner has assigned you to this round. Your structural outline lives in that plan's `OUTLINE.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the plot-hole-critic as a loop, alternating with that plan's script loop, while the showrunner round-robins across plans.

- If your assigned plan's `OUTLINE.md` does not exist yet, this is the first pass for that plan: produce the outline from scratch based on `premise.md` and the plan's `PLAN.md`.
- If the plan's `OUTLINE.md` already exists, it carries the plot-hole-critic's `<review>` block. Read that feedback. Then open the plan's `SCRIPT.md` and look at the actual written scenes — they may invalidate, sharpen, or motivate revisions to your structural claims (e.g., characters have unexpected chemistry, requiring a new subplot). Revise the plan's `OUTLINE.md` in place to address every reviewer point raised and to incorporate any discoveries that change your structure. Don't discard the previous outline and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f12>

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

- Inspect the written scenes for anomalies, wooden dialogue, or tone violations stated directly in `premise.md` or in the plan's `PLAN.md`.
- Open the plan's `OUTLINE.md`. For every major beat and motif the outline claims, write a check into a separate `verify.py` script under the plan's directory (using basic text parsing) to ensure formatting conventions are met, character names are present, and specific required locations or thematic keywords actually appear in the scene output. Run it. Name any character or scene that violates the outline's requirements.
- Read the written pages and spot-check them for continuity bugs — unused characters, dead-end dialogue threads, or actions that contradict the established setting. A continuity error that silently confuses the audience is worse than a mere typo.
- Treat the sequence as finished only when every character arc progresses properly, every thematic motif holds, and the pacing is consistent with the outline's structure — not merely when the scenes are grammatically correct.
- Check the length of the plan's `SCRIPT.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SCRIPT.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f13>

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


campaign-manager policy-architect opposition-researcher mobilization-director compliance-auditor

I need you to set up a 5-agent pipeline that orchestrates a political campaign by developing central policy platforms and localized ground-game voter mobilization in parallel, with each side informing the other. A campaign challenge arrives as a natural-language statement in `problem.md`. The pipeline alternates between revising the policy (turnout ceilings, non-negotiables, coalition structures) and revising the mobilization plan (a data-driven targeting implementation that achieves those goals).

The five agents:

- **campaign-manager** orchestrates the run by alternating one policy step with one mobilization step and tracking progress. It does no drafting, scripting, or reviewing itself.
- **policy loop** — the **policy-architect** writes the central policy platform to `POLICY.md`; the **opposition-researcher** judges it. The policy-architect reads `MOBILIZATION.md` on each revision pass to incorporate empirical turnout and polling evidence.
- **mobilization loop** — the **mobilization-director** writes voter targeting scripts and ground-game assignments to `MOBILIZATION.md`; the **compliance-auditor** judges them. The mobilization-director reads `POLICY.md` on each revision pass to align the field operations with the latest central platform claims.

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

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original campaign challenge, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing strategic plan per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/POLICY.md` — the central policy platform for that plan. Policy-architect writes; opposition-researcher reviews; mobilization-director and compliance-auditor read it.
- `plans/{id}-{slug}/MOBILIZATION.md` — the targeting scripts, field assignments, and their simulated results for that plan. Mobilization-director writes; compliance-auditor reviews; policy-architect and opposition-researcher read it.

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

Each plan develops independently. Cross-read between POLICY.md and MOBILIZATION.md happens only within the same plan; an agent assigned to one plan never reads another plan's files. The campaign-manager round-robins across the K plans: each plan gets one policy step plus one mobilization step per full cycle.

Within each plan, neither policy drafting nor ground-game scripting finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. Policy may tighten after seeing the plan's mobilization empirical numbers; mobilization scripts may correct after seeing the plan's refined policy constraints.

I'm providing the following information:

<f1>
Keep `MOBILIZATION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page memo; 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 draft platforms, write targeting scripts, or review yourself — you only dispatch the right agent at the right time.

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

<f3>
You are working on a political campaign orchestration challenge, which may involve state, local, federal, or combined electoral races. The original campaign challenge is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

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

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

<f5>
Produce the central policy platform for the plan the campaign-manager has assigned you to this round, and write it to that plan's `POLICY.md` (under `plans/{id}-{slug}/POLICY.md`). A complete platform covers four kinds of claim, each justified with historical precedent or demographic analysis.

- **Bounds** — lower bounds on voter turnout from core base models; upper bounds on persuasion targets in swing demographics.
- **Structural properties** — coalition synergies, demographic overlaps, regional messaging variations, geographic clusters. State what messaging holds, where, and under which cultural assumptions.
- **Invariants** — non-negotiable party platform pillars (e.g., a specific stance on labor or taxes) that every localized field strategy must preserve. The mobilization output should honor them; the compliance-auditor will check with `verify.py`.
- **Complexity or momentum** — expected time to reach media saturation, saturation decay rates, or the difficulty of mobilizing low-propensity voters in specific cohorts.

Ground your claims against the plan's `MOBILIZATION.md` if it has reported simulated turnout or budget numbers. A predicted turnout ceiling that is grossly off from the ground-game simulation means either the policy appeals are too weak or the targeting script has a bug — diagnose which side has the issue and state it. Be concrete. "The baseline turnout is bounded below by the union household model, value 12,500" is fine; "the campaign has some momentum that may help" is not. Do not read or aggregate across other plans' files.
</f5>

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

<f7>
Match the strategic tool to the demographic structure; do not force an ill-suited one. The list below is useful in policy and messaging analysis.

| Tool | Suitable for |
|---|---|
| Demographic wedge issues | Polarized electorates; driving a wedge into the opponent's coalition |
| Messaging consistency checks | Media-saturated environments; certifying local surrogate statements align with central platform |
| Base consolidation analysis | Low-turnout races, primary elections; ensuring reliable voters are locked in |
| Persuasion scaling models | High-turnout general elections; (1-1/e) and similar marginal return curves for ad spends |
| Polling equilibrium | Iterative debate cycles; finding a stable narrative advantage |
| Margin of error analysis | Close races; high-probability bounds on victory margins and vote deficits |
| Issue pivot strategies | Scandal or hostile media environments; justifying a shift to safer campaign topics |
| Sensitivity / crisis resilience | Stability of polling numbers under unexpected October surprises or oppo dumps |
</f7>

<f8>
You operate on the plan the campaign-manager has assigned you to this round. Read `problem.md`, your assigned plan's `PLAN.md`, and your assigned plan's `POLICY.md`, then implement the ground-game targeting and resource allocation scripts:

- Include every import. Create each variable with the correct type and bounds, define the voter targets and every budget/volunteer constraint exactly as the campaign challenge states. Run the targeting script, check the resource allocation status, and print both the final district assignments and the estimated turnout value.
- Make the implementation testable against the plan's `POLICY.md`. If the policy states a base turnout floor B, your targeting script should achieve an estimated turnout of at least B. If the policy states an invariant (e.g., no union funds spent in non-union zones), your output should satisfy it.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer against the plan's `POLICY.md`. A quantity that must be a whole number (like volunteers) should not come back fractional; a demographic constraint the policy says holds should hold.

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

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

- Inspect the reported turnout or budget allocation for anomalies, unreasonable expectations, or constraint violations stated directly in `problem.md` or in the plan's `PLAN.md`.
- Open the plan's `POLICY.md`. For every demographic bound and invariant the policy claims, write a check into a separate `verify.py` under the plan's directory: does the ground-game script's output satisfy the messaging invariant, fall within the predicted turnout bound, achieve the required persuasion scale? Run it. Name any variable or region that violates.
- Read the targeting scripts and spot-check them for bugs — unused funds, dead code, logic that contradicts the chosen demographic strategy. A bug that silently misallocates volunteers is worse than one that crashes.
- Treat the result as finished only when every budget constraint holds, every policy-claimed invariant holds, and the estimated turnout is consistent with the policy's bounds — not merely when the code runs without error.
- Check the length of the plan's `MOBILIZATION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `MOBILIZATION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f9>

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

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

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

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

<f11>
You operate on the plan the campaign-manager has assigned you to this round. Your central policy platform lives in that plan's `POLICY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the opposition-researcher as a loop, alternating with that plan's mobilization loop, while the campaign-manager round-robins across plans.

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

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

- **Faithfulness** — does the policy platform correctly address the electorate stated in `problem.md` under the framing set by the plan's `PLAN.md`? Check demographic definitions, regional segments, and constraint translations.
- **Logic soundness** — for each claim, walk through the historical precedent or demographic analysis. Flag hand-waving steps. Verify cited models apply under the stated assumptions.
- **Empirical grounding** — open the plan's `MOBILIZATION.md`. If the ground-game scripts report estimated turnout or costs, do they fall within the policy's predicted bounds? A turnout ceiling that is loose by orders of magnitude is a signal the model is too optimistic; tighten it, or note explicitly that the projection is only illustrative.

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

<f13>
You operate on the plan the campaign-manager has assigned you to this round. Your targeting scripts and their results live in that plan's `MOBILIZATION.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the compliance-auditor as a loop, alternating with that plan's policy loop, while the campaign-manager round-robins across plans.

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (campaign-manager, policy-architect, opposition-researcher, mobilization-director, compliance-auditor), which items should go in its prompt? Respond with a JSON object like {"campaign-manager": ["f?"], "policy-architect": ["f?"], "opposition-researcher": ["f?"], "mobilization-director": ["f?"], "compliance-auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that orchestrates a political campaign by developing central policy platforms and localized ground-game voter mobilization in parallel, with each side informing the other. A campaign challenge arrives as a natural-language statement in `problem.md`. The pipeline alternates between revising the policy (turnout ceilings, non-negotiables, coalition structures) and revising the mobilization plan (a data-driven targeting implementation that achieves those goals).

The five agents:

- **campaign-manager** orchestrates the run by alternating one policy step with one mobilization step and tracking progress. It does no drafting, scripting, or reviewing itself.
- **policy loop** — the **policy-architect** writes the central policy platform to `POLICY.md`; the **opposition-researcher** judges it. The policy-architect reads `MOBILIZATION.md` on each revision pass to incorporate empirical turnout and polling evidence.
- **mobilization loop** — the **mobilization-director** writes voter targeting scripts and ground-game assignments to `MOBILIZATION.md`; the **compliance-auditor** judges them. The mobilization-director reads `POLICY.md` on each revision pass to align the field operations with the latest central platform claims.

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

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original campaign challenge, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing strategic plan per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/POLICY.md` — the central policy platform for that plan. Policy-architect writes; opposition-researcher reviews; mobilization-director and compliance-auditor read it.
- `plans/{id}-{slug}/MOBILIZATION.md` — the targeting scripts, field assignments, and their simulated results for that plan. Mobilization-director writes; compliance-auditor reviews; policy-architect and opposition-researcher read it.

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

Each plan develops independently. Cross-read between POLICY.md and MOBILIZATION.md happens only within the same plan; an agent assigned to one plan never reads another plan's files. The campaign-manager round-robins across the K plans: each plan gets one policy step plus one mobilization step per full cycle.

Within each plan, neither policy drafting nor ground-game scripting finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. Policy may tighten after seeing the plan's mobilization empirical numbers; mobilization scripts may correct after seeing the plan's refined policy constraints.

I'm providing the following prompt fragments:

<f1>
Keep `MOBILIZATION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page memo; 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 draft platforms, write targeting scripts, or review yourself — you only dispatch the right agent at the right time.

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

<f3>
You are working on a political campaign orchestration challenge, which may involve state, local, federal, or combined electoral races. The original campaign challenge is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

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

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

<f5>
Produce the central policy platform for the plan the campaign-manager has assigned you to this round, and write it to that plan's `POLICY.md` (under `plans/{id}-{slug}/POLICY.md`). A complete platform covers four kinds of claim, each justified with historical precedent or demographic analysis.

- **Bounds** — lower bounds on voter turnout from core base models; upper bounds on persuasion targets in swing demographics.
- **Structural properties** — coalition synergies, demographic overlaps, regional messaging variations, geographic clusters. State what messaging holds, where, and under which cultural assumptions.
- **Invariants** — non-negotiable party platform pillars (e.g., a specific stance on labor or taxes) that every localized field strategy must preserve. The mobilization output should honor them; the compliance-auditor will check with `verify.py`.
- **Complexity or momentum** — expected time to reach media saturation, saturation decay rates, or the difficulty of mobilizing low-propensity voters in specific cohorts.

Ground your claims against the plan's `MOBILIZATION.md` if it has reported simulated turnout or budget numbers. A predicted turnout ceiling that is grossly off from the ground-game simulation means either the policy appeals are too weak or the targeting script has a bug — diagnose which side has the issue and state it. Be concrete. "The baseline turnout is bounded below by the union household model, value 12,500" is fine; "the campaign has some momentum that may help" is not. Do not read or aggregate across other plans' files.
</f5>

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

<f7>
Match the strategic tool to the demographic structure; do not force an ill-suited one. The list below is useful in policy and messaging analysis.

| Tool | Suitable for |
|---|---|
| Demographic wedge issues | Polarized electorates; driving a wedge into the opponent's coalition |
| Messaging consistency checks | Media-saturated environments; certifying local surrogate statements align with central platform |
| Base consolidation analysis | Low-turnout races, primary elections; ensuring reliable voters are locked in |
| Persuasion scaling models | High-turnout general elections; (1-1/e) and similar marginal return curves for ad spends |
| Polling equilibrium | Iterative debate cycles; finding a stable narrative advantage |
| Margin of error analysis | Close races; high-probability bounds on victory margins and vote deficits |
| Issue pivot strategies | Scandal or hostile media environments; justifying a shift to safer campaign topics |
| Sensitivity / crisis resilience | Stability of polling numbers under unexpected October surprises or oppo dumps |
</f7>

<f8>
You operate on the plan the campaign-manager has assigned you to this round. Read `problem.md`, your assigned plan's `PLAN.md`, and your assigned plan's `POLICY.md`, then implement the ground-game targeting and resource allocation scripts:

- Include every import. Create each variable with the correct type and bounds, define the voter targets and every budget/volunteer constraint exactly as the campaign challenge states. Run the targeting script, check the resource allocation status, and print both the final district assignments and the estimated turnout value.
- Make the implementation testable against the plan's `POLICY.md`. If the policy states a base turnout floor B, your targeting script should achieve an estimated turnout of at least B. If the policy states an invariant (e.g., no union funds spent in non-union zones), your output should satisfy it.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer against the plan's `POLICY.md`. A quantity that must be a whole number (like volunteers) should not come back fractional; a demographic constraint the policy says holds should hold.

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

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

- Inspect the reported turnout or budget allocation for anomalies, unreasonable expectations, or constraint violations stated directly in `problem.md` or in the plan's `PLAN.md`.
- Open the plan's `POLICY.md`. For every demographic bound and invariant the policy claims, write a check into a separate `verify.py` under the plan's directory: does the ground-game script's output satisfy the messaging invariant, fall within the predicted turnout bound, achieve the required persuasion scale? Run it. Name any variable or region that violates.
- Read the targeting scripts and spot-check them for bugs — unused funds, dead code, logic that contradicts the chosen demographic strategy. A bug that silently misallocates volunteers is worse than one that crashes.
- Treat the result as finished only when every budget constraint holds, every policy-claimed invariant holds, and the estimated turnout is consistent with the policy's bounds — not merely when the code runs without error.
- Check the length of the plan's `MOBILIZATION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `MOBILIZATION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f9>

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

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

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

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

<f11>
You operate on the plan the campaign-manager has assigned you to this round. Your central policy platform lives in that plan's `POLICY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the opposition-researcher as a loop, alternating with that plan's mobilization loop, while the campaign-manager round-robins across plans.

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

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

- **Faithfulness** — does the policy platform correctly address the electorate stated in `problem.md` under the framing set by the plan's `PLAN.md`? Check demographic definitions, regional segments, and constraint translations.
- **Logic soundness** — for each claim, walk through the historical precedent or demographic analysis. Flag hand-waving steps. Verify cited models apply under the stated assumptions.
- **Empirical grounding** — open the plan's `MOBILIZATION.md`. If the ground-game scripts report estimated turnout or costs, do they fall within the policy's predicted bounds? A turnout ceiling that is loose by orders of magnitude is a signal the model is too optimistic; tighten it, or note explicitly that the projection is only illustrative.

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

<f13>
You operate on the plan the campaign-manager has assigned you to this round. Your targeting scripts and their results live in that plan's `MOBILIZATION.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the compliance-auditor as a loop, alternating with that plan's policy loop, while the campaign-manager round-robins across plans.

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

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


I need you to set up a 5-agent pipeline that orchestrates a political campaign by developing central policy platforms and localized ground-game voter mobilization in parallel, with each side informing the other. A campaign challenge arrives as a natural-language statement in `problem.md`. The pipeline alternates between revising the policy (turnout ceilings, non-negotiables, coalition structures) and revising the mobilization plan (a data-driven targeting implementation that achieves those goals).

The five agents:

- **campaign-manager** orchestrates the run by alternating one policy step with one mobilization step and tracking progress. It does no drafting, scripting, or reviewing itself.
- **policy loop** — the **policy-architect** writes the central policy platform to `POLICY.md`; the **opposition-researcher** judges it. The policy-architect reads `MOBILIZATION.md` on each revision pass to incorporate empirical turnout and polling evidence.
- **mobilization loop** — the **mobilization-director** writes voter targeting scripts and ground-game assignments to `MOBILIZATION.md`; the **compliance-auditor** judges them. The mobilization-director reads `POLICY.md` on each revision pass to align the field operations with the latest central platform claims.

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

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original campaign challenge, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing strategic plan per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/POLICY.md` — the central policy platform for that plan. Policy-architect writes; opposition-researcher reviews; mobilization-director and compliance-auditor read it.
- `plans/{id}-{slug}/MOBILIZATION.md` — the targeting scripts, field assignments, and their simulated results for that plan. Mobilization-director writes; compliance-auditor reviews; policy-architect and opposition-researcher read it.

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

Each plan develops independently. Cross-read between POLICY.md and MOBILIZATION.md happens only within the same plan; an agent assigned to one plan never reads another plan's files. The campaign-manager round-robins across the K plans: each plan gets one policy step plus one mobilization step per full cycle.

Within each plan, neither policy drafting nor ground-game scripting finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. Policy may tighten after seeing the plan's mobilization empirical numbers; mobilization scripts may correct after seeing the plan's refined policy constraints.

I'm providing the following information:

<f1>
You operate on the plan the campaign-manager has assigned you to this round. Read `problem.md`, your assigned plan's `PLAN.md`, and your assigned plan's `POLICY.md`, then implement the ground-game targeting and resource allocation scripts:

- Include every import. Create each variable with the correct type and bounds, define the voter targets and every budget/volunteer constraint exactly as the campaign challenge states. Run the targeting script, check the resource allocation status, and print both the final district assignments and the estimated turnout value.
- Make the implementation testable against the plan's `POLICY.md`. If the policy states a base turnout floor B, your targeting script should achieve an estimated turnout of at least B. If the policy states an invariant (e.g., no union funds spent in non-union zones), your output should satisfy it.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer against the plan's `POLICY.md`. A quantity that must be a whole number (like volunteers) should not come back fractional; a demographic constraint the policy says holds should hold.

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

<f2>
Match the strategic tool to the demographic structure; do not force an ill-suited one. The list below is useful in policy and messaging analysis.

| Tool | Suitable for |
|---|---|
| Demographic wedge issues | Polarized electorates; driving a wedge into the opponent's coalition |
| Messaging consistency checks | Media-saturated environments; certifying local surrogate statements align with central platform |
| Base consolidation analysis | Low-turnout races, primary elections; ensuring reliable voters are locked in |
| Persuasion scaling models | High-turnout general elections; (1-1/e) and similar marginal return curves for ad spends |
| Polling equilibrium | Iterative debate cycles; finding a stable narrative advantage |
| Margin of error analysis | Close races; high-probability bounds on victory margins and vote deficits |
| Issue pivot strategies | Scandal or hostile media environments; justifying a shift to safer campaign topics |
| Sensitivity / crisis resilience | Stability of polling numbers under unexpected October surprises or oppo dumps |
</f2>

<f3>
You operate on the plan the campaign-manager has assigned you to this round. Your targeting scripts and their results live in that plan's `MOBILIZATION.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the compliance-auditor as a loop, alternating with that plan's policy loop, while the campaign-manager round-robins across plans.

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

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

- **Faithfulness** — does the policy platform correctly address the electorate stated in `problem.md` under the framing set by the plan's `PLAN.md`? Check demographic definitions, regional segments, and constraint translations.
- **Logic soundness** — for each claim, walk through the historical precedent or demographic analysis. Flag hand-waving steps. Verify cited models apply under the stated assumptions.
- **Empirical grounding** — open the plan's `MOBILIZATION.md`. If the ground-game scripts report estimated turnout or costs, do they fall within the policy's predicted bounds? A turnout ceiling that is loose by orders of magnitude is a signal the model is too optimistic; tighten it, or note explicitly that the projection is only illustrative.

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

<f5>
You orchestrate the run; you never draft platforms, write targeting scripts, or review yourself — you only dispatch the right agent at the right time.

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

<f6>
Produce the central policy platform for the plan the campaign-manager has assigned you to this round, and write it to that plan's `POLICY.md` (under `plans/{id}-{slug}/POLICY.md`). A complete platform covers four kinds of claim, each justified with historical precedent or demographic analysis.

- **Bounds** — lower bounds on voter turnout from core base models; upper bounds on persuasion targets in swing demographics.
- **Structural properties** — coalition synergies, demographic overlaps, regional messaging variations, geographic clusters. State what messaging holds, where, and under which cultural assumptions.
- **Invariants** — non-negotiable party platform pillars (e.g., a specific stance on labor or taxes) that every localized field strategy must preserve. The mobilization output should honor them; the compliance-auditor will check with `verify.py`.
- **Complexity or momentum** — expected time to reach media saturation, saturation decay rates, or the difficulty of mobilizing low-propensity voters in specific cohorts.

Ground your claims against the plan's `MOBILIZATION.md` if it has reported simulated turnout or budget numbers. A predicted turnout ceiling that is grossly off from the ground-game simulation means either the policy appeals are too weak or the targeting script has a bug — diagnose which side has the issue and state it. Be concrete. "The baseline turnout is bounded below by the union household model, value 12,500" is fine; "the campaign has some momentum that may help" is not. Do not read or aggregate across other plans' files.
</f6>

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

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

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

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

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

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

<f11>
You are working on a political campaign orchestration challenge, which may involve state, local, federal, or combined electoral races. The original campaign challenge is given as a natural-language statement in `problem.md`; read it before starting your part.
</f11>

<f12>
You operate on the plan the campaign-manager has assigned you to this round. Your central policy platform lives in that plan's `POLICY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the opposition-researcher as a loop, alternating with that plan's mobilization loop, while the campaign-manager round-robins across plans.

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

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

- Inspect the reported turnout or budget allocation for anomalies, unreasonable expectations, or constraint violations stated directly in `problem.md` or in the plan's `PLAN.md`.
- Open the plan's `POLICY.md`. For every demographic bound and invariant the policy claims, write a check into a separate `verify.py` under the plan's directory: does the ground-game script's output satisfy the messaging invariant, fall within the predicted turnout bound, achieve the required persuasion scale? Run it. Name any variable or region that violates.
- Read the targeting scripts and spot-check them for bugs — unused funds, dead code, logic that contradicts the chosen demographic strategy. A bug that silently misallocates volunteers is worse than one that crashes.
- Treat the result as finished only when every budget constraint holds, every policy-claimed invariant holds, and the estimated turnout is consistent with the policy's bounds — not merely when the code runs without error.
- Check the length of the plan's `MOBILIZATION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `MOBILIZATION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f13>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (campaign-manager, policy-architect, opposition-researcher, mobilization-director, compliance-auditor), which items should go in its prompt? Respond with a JSON object like {"campaign-manager": ["f?"], "policy-architect": ["f?"], "opposition-researcher": ["f?"], "mobilization-director": ["f?"], "compliance-auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that orchestrates a political campaign by developing central policy platforms and localized ground-game voter mobilization in parallel, with each side informing the other. A campaign challenge arrives as a natural-language statement in `problem.md`. The pipeline alternates between revising the policy (turnout ceilings, non-negotiables, coalition structures) and revising the mobilization plan (a data-driven targeting implementation that achieves those goals).

The five agents:

- **campaign-manager** orchestrates the run by alternating one policy step with one mobilization step and tracking progress. It does no drafting, scripting, or reviewing itself.
- **policy loop** — the **policy-architect** writes the central policy platform to `POLICY.md`; the **opposition-researcher** judges it. The policy-architect reads `MOBILIZATION.md` on each revision pass to incorporate empirical turnout and polling evidence.
- **mobilization loop** — the **mobilization-director** writes voter targeting scripts and ground-game assignments to `MOBILIZATION.md`; the **compliance-auditor** judges them. The mobilization-director reads `POLICY.md` on each revision pass to align the field operations with the latest central platform claims.

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

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original campaign challenge, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing strategic plan per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/POLICY.md` — the central policy platform for that plan. Policy-architect writes; opposition-researcher reviews; mobilization-director and compliance-auditor read it.
- `plans/{id}-{slug}/MOBILIZATION.md` — the targeting scripts, field assignments, and their simulated results for that plan. Mobilization-director writes; compliance-auditor reviews; policy-architect and opposition-researcher read it.

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

Each plan develops independently. Cross-read between POLICY.md and MOBILIZATION.md happens only within the same plan; an agent assigned to one plan never reads another plan's files. The campaign-manager round-robins across the K plans: each plan gets one policy step plus one mobilization step per full cycle.

Within each plan, neither policy drafting nor ground-game scripting finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. Policy may tighten after seeing the plan's mobilization empirical numbers; mobilization scripts may correct after seeing the plan's refined policy constraints.

I'm providing the following prompt fragments:

<f1>
You operate on the plan the campaign-manager has assigned you to this round. Read `problem.md`, your assigned plan's `PLAN.md`, and your assigned plan's `POLICY.md`, then implement the ground-game targeting and resource allocation scripts:

- Include every import. Create each variable with the correct type and bounds, define the voter targets and every budget/volunteer constraint exactly as the campaign challenge states. Run the targeting script, check the resource allocation status, and print both the final district assignments and the estimated turnout value.
- Make the implementation testable against the plan's `POLICY.md`. If the policy states a base turnout floor B, your targeting script should achieve an estimated turnout of at least B. If the policy states an invariant (e.g., no union funds spent in non-union zones), your output should satisfy it.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer against the plan's `POLICY.md`. A quantity that must be a whole number (like volunteers) should not come back fractional; a demographic constraint the policy says holds should hold.

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

<f2>
Match the strategic tool to the demographic structure; do not force an ill-suited one. The list below is useful in policy and messaging analysis.

| Tool | Suitable for |
|---|---|
| Demographic wedge issues | Polarized electorates; driving a wedge into the opponent's coalition |
| Messaging consistency checks | Media-saturated environments; certifying local surrogate statements align with central platform |
| Base consolidation analysis | Low-turnout races, primary elections; ensuring reliable voters are locked in |
| Persuasion scaling models | High-turnout general elections; (1-1/e) and similar marginal return curves for ad spends |
| Polling equilibrium | Iterative debate cycles; finding a stable narrative advantage |
| Margin of error analysis | Close races; high-probability bounds on victory margins and vote deficits |
| Issue pivot strategies | Scandal or hostile media environments; justifying a shift to safer campaign topics |
| Sensitivity / crisis resilience | Stability of polling numbers under unexpected October surprises or oppo dumps |
</f2>

<f3>
You operate on the plan the campaign-manager has assigned you to this round. Your targeting scripts and their results live in that plan's `MOBILIZATION.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the compliance-auditor as a loop, alternating with that plan's policy loop, while the campaign-manager round-robins across plans.

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

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

- **Faithfulness** — does the policy platform correctly address the electorate stated in `problem.md` under the framing set by the plan's `PLAN.md`? Check demographic definitions, regional segments, and constraint translations.
- **Logic soundness** — for each claim, walk through the historical precedent or demographic analysis. Flag hand-waving steps. Verify cited models apply under the stated assumptions.
- **Empirical grounding** — open the plan's `MOBILIZATION.md`. If the ground-game scripts report estimated turnout or costs, do they fall within the policy's predicted bounds? A turnout ceiling that is loose by orders of magnitude is a signal the model is too optimistic; tighten it, or note explicitly that the projection is only illustrative.

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

<f5>
You orchestrate the run; you never draft platforms, write targeting scripts, or review yourself — you only dispatch the right agent at the right time.

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

<f6>
Produce the central policy platform for the plan the campaign-manager has assigned you to this round, and write it to that plan's `POLICY.md` (under `plans/{id}-{slug}/POLICY.md`). A complete platform covers four kinds of claim, each justified with historical precedent or demographic analysis.

- **Bounds** — lower bounds on voter turnout from core base models; upper bounds on persuasion targets in swing demographics.
- **Structural properties** — coalition synergies, demographic overlaps, regional messaging variations, geographic clusters. State what messaging holds, where, and under which cultural assumptions.
- **Invariants** — non-negotiable party platform pillars (e.g., a specific stance on labor or taxes) that every localized field strategy must preserve. The mobilization output should honor them; the compliance-auditor will check with `verify.py`.
- **Complexity or momentum** — expected time to reach media saturation, saturation decay rates, or the difficulty of mobilizing low-propensity voters in specific cohorts.

Ground your claims against the plan's `MOBILIZATION.md` if it has reported simulated turnout or budget numbers. A predicted turnout ceiling that is grossly off from the ground-game simulation means either the policy appeals are too weak or the targeting script has a bug — diagnose which side has the issue and state it. Be concrete. "The baseline turnout is bounded below by the union household model, value 12,500" is fine; "the campaign has some momentum that may help" is not. Do not read or aggregate across other plans' files.
</f6>

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

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

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

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

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

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

<f11>
You are working on a political campaign orchestration challenge, which may involve state, local, federal, or combined electoral races. The original campaign challenge is given as a natural-language statement in `problem.md`; read it before starting your part.
</f11>

<f12>
You operate on the plan the campaign-manager has assigned you to this round. Your central policy platform lives in that plan's `POLICY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the opposition-researcher as a loop, alternating with that plan's mobilization loop, while the campaign-manager round-robins across plans.

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

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

- Inspect the reported turnout or budget allocation for anomalies, unreasonable expectations, or constraint violations stated directly in `problem.md` or in the plan's `PLAN.md`.
- Open the plan's `POLICY.md`. For every demographic bound and invariant the policy claims, write a check into a separate `verify.py` under the plan's directory: does the ground-game script's output satisfy the messaging invariant, fall within the predicted turnout bound, achieve the required persuasion scale? Run it. Name any variable or region that violates.
- Read the targeting scripts and spot-check them for bugs — unused funds, dead code, logic that contradicts the chosen demographic strategy. A bug that silently misallocates volunteers is worse than one that crashes.
- Treat the result as finished only when every budget constraint holds, every policy-claimed invariant holds, and the estimated turnout is consistent with the policy's bounds — not merely when the code runs without error.
- Check the length of the plan's `MOBILIZATION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `MOBILIZATION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f13>

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