I need you to set up a 6-agent pipeline that designs a deep-space probe trajectory and compiles the exact thruster burn sequences, timings, and telemetry expectations for the flight computer. A mission profile arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted trajectory plan and then working, verified burn sequence code.

The six agents:

- **mission-commander** orchestrates the run: it drives the plan phase, then the code phase, and tracks progress. It does no trajectory modeling, coding, or reviewing itself.
- **astrodynamics-architect** is invoked once at init and produces K differentiated candidate trajectory plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **maneuver-adjuster** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the orbital-mechanics-reviewer's last review for that plan. It never creates new plans.
- **orbital-mechanics-reviewer** reviews the trajectory plan it is currently assigned to.
- **burn-sequence-compiler** implements the strategy as burn sequence code for the plan it is currently assigned to.
- **physics-simulator-proxy** reviews the burn sequence code and telemetry result of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original mission profile, given as input. All five domain agents (astrodynamics-architect, maneuver-adjuster, orbital-mechanics-reviewer, burn-sequence-compiler, physics-simulator-proxy) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The astrodynamics-architect writes K differentiated candidates at init; the maneuver-adjuster revises a specific assigned plan in the loop; the orbital-mechanics-reviewer reviews the plan it is assigned to; the burn-sequence-compiler reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the burn sequence code and telemetry results for that plan. The burn-sequence-compiler writes it; the physics-simulator-proxy reviews it.

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

The mission-commander round-robins across the K plans, first in a plan phase (each plan iterates its maneuver-adjuster ↔ orbital-mechanics-reviewer loop) and then in a code phase (each plan iterates its burn-sequence-compiler ↔ physics-simulator-proxy loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following information:

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

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

- **GMAT (General Mission Analysis Tool)** — excellent for high-fidelity multi-regime trajectory optimization; standard for NASA missions.
- **Copernicus** — N-body trajectory design and optimization; best for complex gravity assists.
- **FreeFlyer** — strong commercial tool for operational flight dynamics and maneuver planning.
- **SPICE** — essential for observation geometry and ephemeris lookups; not a trajectory optimizer itself but often paired.
- **Poliastro** — pure Python orbital mechanics; great for preliminary interplanetary transfers, but lacks high-fidelity perturbations.
- **Tudat** — strong open-source option for numerical propagation and estimation; very customizable.

Match the engine to the mission phase type; do not force an ill-suited one.
</f2>

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

- If your assigned plan's `SOLUTION.md` does not exist yet, this is the first pass for that plan: produce the solution from scratch based on the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the physics-simulator-proxy's `<review>` block. Read that feedback and revise the plan's `SOLUTION.md` in place to address every point raised. Don't discard the solution and start over, and don't leave a flagged issue unaddressed. Do not read or touch other plans' files.
</f3>

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

- **Trajectory model** — does it faithfully capture the mission profile? Check that the mission phase type, state variables, objective, and constraints are all accurate.
- **Flight strategy** — is the chosen astrodynamics engine and integrator a sound fit, is the route actually flyable, and is it likely to reach a correct orbit?

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

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

- Inspect the reported telemetry for anomalies, unreasonable delta-V values, or constraint violations (e.g., impacting a planetary body).
- Write a separate `verify.py` under the plan's directory that re-checks every constraint against the reported ephemeris, and run it; name any state variables that violate a constraint.
- Read the burn sequence code and spot-check it for bugs — unused thruster configurations, dead code, logic that contradicts what the sequence says it does. A bug that silently degrades the trajectory is worse than one that crashes.
- Treat the result as finished only when every constraint holds and the objective value is sound — not merely when the code runs without error.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

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

- Include every import. Create each state vector with the correct epochs and bounds, define the objective and every constraint exactly as the trajectory model states, propagate the orbit, check the final state, and print both the telemetry and the objective value.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer: a delta-V that exceeds the spacecraft's total fuel capacity should not be reported as a success.

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

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

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

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

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

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

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

The **trajectory model** must state:

- **Mission phase type** — Heliocentric transfer, multi-body gravity assist, low-thrust spiral, aerocapture, and so on; this must be exact.
- **Spacecraft data** — the key numeric inputs like dry mass, fuel capacity, specific impulse (Isp), and what each represents.
- **State variables** — position, velocity, and mass types and bounds, with descriptive names.
- **Objective function** — the exact metric to optimize (e.g., minimize delta-V, maximize payload mass, minimize time-of-flight).
- **Constraints** — every constraint, such as thermal limits, maximum dynamic pressure, or communication line-of-sight, listed explicitly.

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

- which astrodynamics engine to use and how to call it;
- the numerical integrator and its key initial settings (e.g., Runge-Kutta tolerances);
- the maneuver timing or trick the route relies on (e.g., Oberth effect usage);
- the biggest risk on this route.
</f9>

<f10>
You are working on designing a deep-space probe trajectory — it may involve planetary flybys, deep space maneuvers, orbital insertions, or a combination. The original mission profile is given as a natural-language statement in `problem.md`; read it before starting your part.
</f10>

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

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

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (mission-commander, astrodynamics-architect, maneuver-adjuster, orbital-mechanics-reviewer, burn-sequence-compiler, physics-simulator-proxy), which items should go in its prompt? Respond with a JSON object like {"mission-commander": ["f?"], "astrodynamics-architect": ["f?"], "maneuver-adjuster": ["f?"], "orbital-mechanics-reviewer": ["f?"], "burn-sequence-compiler": ["f?"], "physics-simulator-proxy": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline that designs a deep-space probe trajectory and compiles the exact thruster burn sequences, timings, and telemetry expectations for the flight computer. A mission profile arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted trajectory plan and then working, verified burn sequence code.

The six agents:

- **mission-commander** orchestrates the run: it drives the plan phase, then the code phase, and tracks progress. It does no trajectory modeling, coding, or reviewing itself.
- **astrodynamics-architect** is invoked once at init and produces K differentiated candidate trajectory plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **maneuver-adjuster** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the orbital-mechanics-reviewer's last review for that plan. It never creates new plans.
- **orbital-mechanics-reviewer** reviews the trajectory plan it is currently assigned to.
- **burn-sequence-compiler** implements the strategy as burn sequence code for the plan it is currently assigned to.
- **physics-simulator-proxy** reviews the burn sequence code and telemetry result of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original mission profile, given as input. All five domain agents (astrodynamics-architect, maneuver-adjuster, orbital-mechanics-reviewer, burn-sequence-compiler, physics-simulator-proxy) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The astrodynamics-architect writes K differentiated candidates at init; the maneuver-adjuster revises a specific assigned plan in the loop; the orbital-mechanics-reviewer reviews the plan it is assigned to; the burn-sequence-compiler reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the burn sequence code and telemetry results for that plan. The burn-sequence-compiler writes it; the physics-simulator-proxy reviews it.

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

The mission-commander round-robins across the K plans, first in a plan phase (each plan iterates its maneuver-adjuster ↔ orbital-mechanics-reviewer loop) and then in a code phase (each plan iterates its burn-sequence-compiler ↔ physics-simulator-proxy loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following prompt fragments:

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

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

- **GMAT (General Mission Analysis Tool)** — excellent for high-fidelity multi-regime trajectory optimization; standard for NASA missions.
- **Copernicus** — N-body trajectory design and optimization; best for complex gravity assists.
- **FreeFlyer** — strong commercial tool for operational flight dynamics and maneuver planning.
- **SPICE** — essential for observation geometry and ephemeris lookups; not a trajectory optimizer itself but often paired.
- **Poliastro** — pure Python orbital mechanics; great for preliminary interplanetary transfers, but lacks high-fidelity perturbations.
- **Tudat** — strong open-source option for numerical propagation and estimation; very customizable.

Match the engine to the mission phase type; do not force an ill-suited one.
</f2>

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

- If your assigned plan's `SOLUTION.md` does not exist yet, this is the first pass for that plan: produce the solution from scratch based on the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the physics-simulator-proxy's `<review>` block. Read that feedback and revise the plan's `SOLUTION.md` in place to address every point raised. Don't discard the solution and start over, and don't leave a flagged issue unaddressed. Do not read or touch other plans' files.
</f3>

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

- **Trajectory model** — does it faithfully capture the mission profile? Check that the mission phase type, state variables, objective, and constraints are all accurate.
- **Flight strategy** — is the chosen astrodynamics engine and integrator a sound fit, is the route actually flyable, and is it likely to reach a correct orbit?

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

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

- Inspect the reported telemetry for anomalies, unreasonable delta-V values, or constraint violations (e.g., impacting a planetary body).
- Write a separate `verify.py` under the plan's directory that re-checks every constraint against the reported ephemeris, and run it; name any state variables that violate a constraint.
- Read the burn sequence code and spot-check it for bugs — unused thruster configurations, dead code, logic that contradicts what the sequence says it does. A bug that silently degrades the trajectory is worse than one that crashes.
- Treat the result as finished only when every constraint holds and the objective value is sound — not merely when the code runs without error.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

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

- Include every import. Create each state vector with the correct epochs and bounds, define the objective and every constraint exactly as the trajectory model states, propagate the orbit, check the final state, and print both the telemetry and the objective value.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer: a delta-V that exceeds the spacecraft's total fuel capacity should not be reported as a success.

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

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

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

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

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

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

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

The **trajectory model** must state:

- **Mission phase type** — Heliocentric transfer, multi-body gravity assist, low-thrust spiral, aerocapture, and so on; this must be exact.
- **Spacecraft data** — the key numeric inputs like dry mass, fuel capacity, specific impulse (Isp), and what each represents.
- **State variables** — position, velocity, and mass types and bounds, with descriptive names.
- **Objective function** — the exact metric to optimize (e.g., minimize delta-V, maximize payload mass, minimize time-of-flight).
- **Constraints** — every constraint, such as thermal limits, maximum dynamic pressure, or communication line-of-sight, listed explicitly.

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

- which astrodynamics engine to use and how to call it;
- the numerical integrator and its key initial settings (e.g., Runge-Kutta tolerances);
- the maneuver timing or trick the route relies on (e.g., Oberth effect usage);
- the biggest risk on this route.
</f9>

<f10>
You are working on designing a deep-space probe trajectory — it may involve planetary flybys, deep space maneuvers, orbital insertions, or a combination. The original mission profile is given as a natural-language statement in `problem.md`; read it before starting your part.
</f10>

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

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

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

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


case coordinator
litigation strategist
theory reviser
opposing-counsel analyst
brief drafter
brief challenge reviewer

I need you to set up a 6-agent pipeline for civil litigation preparation. A case arrives as a factual and procedural summary in `casefile.md`, and the pipeline turns it into vetted legal theories and then a working motion or brief that has been adversarially reviewed for weaknesses.

The six agents:

- **case coordinator** orchestrates the run: it drives the theory phase, then the drafting phase, and tracks progress. It does no legal analysis, drafting, or reviewing itself.
- **litigation strategist** is invoked once at init and produces K differentiated candidate legal theories, one per `theories/{id}-{slug}/THEORY.md`. It never enters the per-theory revision loop.
- **theory reviser** is invoked once per theory-refinement step in the loop. It revises a single assigned theory's `THEORY.md` based on the opposing-counsel analyst's last review for that theory. It never creates new theories.
- **opposing-counsel analyst** reviews the theory it is currently assigned to.
- **brief drafter** drafts the motion or brief for the theory it is currently assigned to.
- **brief challenge reviewer** adversarially reviews the drafted motion or brief for the theory it is currently assigned to.

The pipeline hands work off through theory-namespaced files:

- `casefile.md` — the original case summary, given as input. All five domain agents (litigation strategist, theory reviser, opposing-counsel analyst, brief drafter, brief challenge reviewer) read it.
- `theories/{id}-{slug}/THEORY.md` — one theory per directory, K theories total. The litigation strategist writes K differentiated candidates at init; the theory reviser revises a specific assigned theory in the loop; the opposing-counsel analyst reviews the theory it is assigned to; the brief drafter reads the theory it is assigned to.
- `theories/{id}-{slug}/BRIEF.md` — the motion or brief draft and supporting analysis for that theory. The brief drafter writes it; the brief challenge reviewer reviews it.

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

The case coordinator round-robins across the K theories, first in a theory phase (each theory iterates its theory reviser ↔ opposing-counsel analyst loop) and then in a drafting phase (each theory iterates its brief drafter ↔ brief challenge reviewer loop). Cross-theory reading does not happen: an agent assigned to one theory never reads another theory's files.

I'm providing the following information:

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

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

- **Init** — dispatch the litigation strategist once to draft K differentiated candidate theories, each in its own `theories/{id}-{slug}/` directory. After it returns, read the directory list to learn the K theory ids. The litigation strategist is not invoked again after this.
- **Theory phase** — round-robin across the K theories. For each theory in turn, dispatch theory reviser (revise that theory based on its opposing-counsel analyst's review) then opposing-counsel analyst (score that theory). After one round-robin pass through all K theories, start the next pass. A theory is considered done in this phase when its opposing-counsel analyst score reaches 10; stop scheduling more theory-phase calls for it but continue with the others. After all K theories hit opposing-counsel analyst 10, or each theory has had 10 theory-phase iterations, move to the drafting phase.
- **Drafting phase** — round-robin across the K theories. For each theory in turn, dispatch brief drafter (revise that theory's brief based on its brief challenge reviewer's review) then brief challenge reviewer (score that theory's brief). The pipeline stops when any theory reaches brief challenge reviewer score 10, or each theory has had 10 drafting-phase iterations.
- When dispatching, always pass the theory's directory path so the dispatched agent knows which `THEORY.md` / `BRIEF.md` to operate on.
- Keep the current phase, per-theory iteration counts, per-theory latest scores, and current theory index in `STATE.md`, accurate after each dispatch. Read each score from the relevant theory's reviewer `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a civil litigation matter — it may involve contract claims, tort claims, statutory causes of action, equitable relief, procedural motions, or a combination. The original case summary is given in `casefile.md`; read it before starting your part.
</f3>

<f4>
Review the theory in your assigned theory's `THEORY.md`. Operate strictly on the assigned theory; do not look at other theories.

- **Case theory** — does it faithfully capture the case? Check that the procedural posture, requested relief, claims or defenses, legal standard, and element-by-element factual application are all accurate.
- **Strategy** — is the chosen procedural vehicle and argument route a sound fit, is the route actually draftable from the available facts and law, and is it likely to survive adversarial opposition?

Be brief and specific. Do not draft any motion or brief yourself — only review.
</f4>

<f5>
Which litigation route suits which kind of civil matter — use it to choose one for the strategy:

- **Rule 12 motion practice** — best for legal insufficiency on the pleadings, jurisdictional defects, limitations apparent on the face of the complaint, or failure to plead required elements; not suited to fact-heavy merits disputes.
- **Summary judgment** — best when discovery has created a record showing no genuine dispute of material fact; requires admissible evidence and careful citation to the record.
- **Preliminary injunction** — best for urgent equitable relief where irreparable harm, likelihood of success, balance of equities, and public interest can be shown; weak if damages would be adequate.
- **Contract theory** — best where a valid agreement, breach, causation, and damages can be proved through documents, performance history, and communications.
- **Tort theory** — best where duty, breach, causation, and damages can be tied to concrete conduct; often vulnerable on duty, foreseeability, privilege, or economic-loss limitations.
- **Statutory claim or defense** — best when the statute supplies clear elements, remedies, fee shifting, limitations periods, or administrative prerequisites; check exhaustion, notice, standing, and preemption.
- **Equitable theory** — best where legal remedies are inadequate and facts support fairness-based relief such as estoppel, unjust enrichment, constructive trust, or specific performance; highly fact-sensitive.
- **Discovery or evidentiary motion** — best when the immediate objective is compelling production, excluding unreliable evidence, protecting privileged material, or shaping the record before merits briefing.

Match the procedural vehicle and legal theory to the case posture and available facts; do not force an ill-suited route.
</f5>

<f6>
Read the theory in your assigned theory's `THEORY.md` and implement its strategy as a motion or brief:

- Include the caption placeholder, requested relief, introduction, factual background, legal standard, argument sections, and conclusion. State the governing rule accurately, apply every required element or factor, and cite the facts and authorities the theory depends on.
- Draft the argument through to completion — do not leave placeholders such as “add citation,” “insert facts,” or “research later.” If a weakness appears, address it directly rather than hiding it.
- Sanity-check the filing: the requested relief should match the procedural posture, factual assertions should be supported by the casefile or identified exhibits, and the argument should not rely on elements the record cannot support.

Write the draft and its supporting notes up in your assigned theory's `BRIEF.md`. Do not read or touch other theories' files.
</f6>

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

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

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

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

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

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

<f9>
Produce K differentiated candidate legal theories, each in its own `theories/{id}-{slug}/THEORY.md`. The K theories should differ meaningfully in their legal route so distinct approaches can be compared downstream, not in trivial ways like changing headings or rephrasing the same argument.

A complete theory in any `THEORY.md` has two parts — a formalized case theory and one chosen litigation strategy.

The **case theory** must state:

- **Procedural posture and requested relief** — for example, complaint, motion to dismiss opposition, summary judgment motion, preliminary injunction, sanctions motion, or discovery motion; this must be exact.
- **Key facts** — the facts that matter legally, including dates, parties, communications, documents, injuries, damages, and procedural deadlines where relevant.
- **Claims, defenses, or issues presented** — each cause of action, affirmative defense, procedural issue, or remedy being advanced.
- **Legal standard** — the governing rule, elements, burden of proof, and any controlling or persuasive authority needed to frame the argument.
- **Element-by-element application** — every required element or factor, listed explicitly with the facts that support it and any known weaknesses.

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

- which procedural vehicle or filing to use and how to frame it;
- the argument sequence and the key evidence or authority to lead with;
- the doctrinal hook, burden-shifting rule, presumption, waiver point, or procedural leverage the route relies on;
- the biggest litigation risk on this route.
</f9>

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

<f11>
Review your assigned theory's `BRIEF.md` — the motion or brief draft and its supporting analysis. Verify it directly against the casefile. Operate strictly on the assigned theory; do not look at other theories.

- Inspect the requested relief and argument for anomalies, overclaims, unsupported factual assertions, missing elements, or concessions an opponent could exploit.
- Write a separate `authority_check.md` under the theory's directory that re-checks every required element, factual assertion, record citation, and legal authority against the reported draft; name any facts, elements, or citations that do not hold up.
- Read the brief and spot-check it for drafting defects — unused facts, dead arguments, misstated standards, contradictory positions, missing burdens, or logic that contradicts what the draft says it proves. A defect that silently weakens the filing is worse than one that is obvious.
- Treat the draft as finished only when every required element or factor is addressed, the requested relief is procedurally available, and the argument is legally sound — not merely when the prose reads smoothly.
- Check the length of the theory's `BRIEF.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the theory's `BRIEF.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your motion or brief and its supporting analysis live in your assigned theory's `BRIEF.md`.

- If your assigned theory's `BRIEF.md` does not exist yet, this is the first pass for that theory: produce the draft from scratch based on the theory's `THEORY.md`.
- If the theory's `BRIEF.md` already exists, it carries the brief challenge reviewer's `<review>` block. Read that feedback and revise the theory's `BRIEF.md` in place to address every point raised. Don't discard the brief and start over, and don't leave a flagged issue unaddressed. Do not read or touch other theories' files.
</f12>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (case coordinator, litigation strategist, theory reviser, opposing-counsel analyst, brief drafter, brief challenge reviewer), which items should go in its prompt? Respond with a JSON object like {"case coordinator": ["f?"], "litigation strategist": ["f?"], "theory reviser": ["f?"], "opposing-counsel analyst": ["f?"], "brief drafter": ["f?"], "brief challenge reviewer": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline for civil litigation preparation. A case arrives as a factual and procedural summary in `casefile.md`, and the pipeline turns it into vetted legal theories and then a working motion or brief that has been adversarially reviewed for weaknesses.

The six agents:

- **case coordinator** orchestrates the run: it drives the theory phase, then the drafting phase, and tracks progress. It does no legal analysis, drafting, or reviewing itself.
- **litigation strategist** is invoked once at init and produces K differentiated candidate legal theories, one per `theories/{id}-{slug}/THEORY.md`. It never enters the per-theory revision loop.
- **theory reviser** is invoked once per theory-refinement step in the loop. It revises a single assigned theory's `THEORY.md` based on the opposing-counsel analyst's last review for that theory. It never creates new theories.
- **opposing-counsel analyst** reviews the theory it is currently assigned to.
- **brief drafter** drafts the motion or brief for the theory it is currently assigned to.
- **brief challenge reviewer** adversarially reviews the drafted motion or brief for the theory it is currently assigned to.

The pipeline hands work off through theory-namespaced files:

- `casefile.md` — the original case summary, given as input. All five domain agents (litigation strategist, theory reviser, opposing-counsel analyst, brief drafter, brief challenge reviewer) read it.
- `theories/{id}-{slug}/THEORY.md` — one theory per directory, K theories total. The litigation strategist writes K differentiated candidates at init; the theory reviser revises a specific assigned theory in the loop; the opposing-counsel analyst reviews the theory it is assigned to; the brief drafter reads the theory it is assigned to.
- `theories/{id}-{slug}/BRIEF.md` — the motion or brief draft and supporting analysis for that theory. The brief drafter writes it; the brief challenge reviewer reviews it.

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

The case coordinator round-robins across the K theories, first in a theory phase (each theory iterates its theory reviser ↔ opposing-counsel analyst loop) and then in a drafting phase (each theory iterates its brief drafter ↔ brief challenge reviewer loop). Cross-theory reading does not happen: an agent assigned to one theory never reads another theory's files.

I'm providing the following prompt fragments:

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

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

- **Init** — dispatch the litigation strategist once to draft K differentiated candidate theories, each in its own `theories/{id}-{slug}/` directory. After it returns, read the directory list to learn the K theory ids. The litigation strategist is not invoked again after this.
- **Theory phase** — round-robin across the K theories. For each theory in turn, dispatch theory reviser (revise that theory based on its opposing-counsel analyst's review) then opposing-counsel analyst (score that theory). After one round-robin pass through all K theories, start the next pass. A theory is considered done in this phase when its opposing-counsel analyst score reaches 10; stop scheduling more theory-phase calls for it but continue with the others. After all K theories hit opposing-counsel analyst 10, or each theory has had 10 theory-phase iterations, move to the drafting phase.
- **Drafting phase** — round-robin across the K theories. For each theory in turn, dispatch brief drafter (revise that theory's brief based on its brief challenge reviewer's review) then brief challenge reviewer (score that theory's brief). The pipeline stops when any theory reaches brief challenge reviewer score 10, or each theory has had 10 drafting-phase iterations.
- When dispatching, always pass the theory's directory path so the dispatched agent knows which `THEORY.md` / `BRIEF.md` to operate on.
- Keep the current phase, per-theory iteration counts, per-theory latest scores, and current theory index in `STATE.md`, accurate after each dispatch. Read each score from the relevant theory's reviewer `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a civil litigation matter — it may involve contract claims, tort claims, statutory causes of action, equitable relief, procedural motions, or a combination. The original case summary is given in `casefile.md`; read it before starting your part.
</f3>

<f4>
Review the theory in your assigned theory's `THEORY.md`. Operate strictly on the assigned theory; do not look at other theories.

- **Case theory** — does it faithfully capture the case? Check that the procedural posture, requested relief, claims or defenses, legal standard, and element-by-element factual application are all accurate.
- **Strategy** — is the chosen procedural vehicle and argument route a sound fit, is the route actually draftable from the available facts and law, and is it likely to survive adversarial opposition?

Be brief and specific. Do not draft any motion or brief yourself — only review.
</f4>

<f5>
Which litigation route suits which kind of civil matter — use it to choose one for the strategy:

- **Rule 12 motion practice** — best for legal insufficiency on the pleadings, jurisdictional defects, limitations apparent on the face of the complaint, or failure to plead required elements; not suited to fact-heavy merits disputes.
- **Summary judgment** — best when discovery has created a record showing no genuine dispute of material fact; requires admissible evidence and careful citation to the record.
- **Preliminary injunction** — best for urgent equitable relief where irreparable harm, likelihood of success, balance of equities, and public interest can be shown; weak if damages would be adequate.
- **Contract theory** — best where a valid agreement, breach, causation, and damages can be proved through documents, performance history, and communications.
- **Tort theory** — best where duty, breach, causation, and damages can be tied to concrete conduct; often vulnerable on duty, foreseeability, privilege, or economic-loss limitations.
- **Statutory claim or defense** — best when the statute supplies clear elements, remedies, fee shifting, limitations periods, or administrative prerequisites; check exhaustion, notice, standing, and preemption.
- **Equitable theory** — best where legal remedies are inadequate and facts support fairness-based relief such as estoppel, unjust enrichment, constructive trust, or specific performance; highly fact-sensitive.
- **Discovery or evidentiary motion** — best when the immediate objective is compelling production, excluding unreliable evidence, protecting privileged material, or shaping the record before merits briefing.

Match the procedural vehicle and legal theory to the case posture and available facts; do not force an ill-suited route.
</f5>

<f6>
Read the theory in your assigned theory's `THEORY.md` and implement its strategy as a motion or brief:

- Include the caption placeholder, requested relief, introduction, factual background, legal standard, argument sections, and conclusion. State the governing rule accurately, apply every required element or factor, and cite the facts and authorities the theory depends on.
- Draft the argument through to completion — do not leave placeholders such as “add citation,” “insert facts,” or “research later.” If a weakness appears, address it directly rather than hiding it.
- Sanity-check the filing: the requested relief should match the procedural posture, factual assertions should be supported by the casefile or identified exhibits, and the argument should not rely on elements the record cannot support.

Write the draft and its supporting notes up in your assigned theory's `BRIEF.md`. Do not read or touch other theories' files.
</f6>

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

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

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

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

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

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

<f9>
Produce K differentiated candidate legal theories, each in its own `theories/{id}-{slug}/THEORY.md`. The K theories should differ meaningfully in their legal route so distinct approaches can be compared downstream, not in trivial ways like changing headings or rephrasing the same argument.

A complete theory in any `THEORY.md` has two parts — a formalized case theory and one chosen litigation strategy.

The **case theory** must state:

- **Procedural posture and requested relief** — for example, complaint, motion to dismiss opposition, summary judgment motion, preliminary injunction, sanctions motion, or discovery motion; this must be exact.
- **Key facts** — the facts that matter legally, including dates, parties, communications, documents, injuries, damages, and procedural deadlines where relevant.
- **Claims, defenses, or issues presented** — each cause of action, affirmative defense, procedural issue, or remedy being advanced.
- **Legal standard** — the governing rule, elements, burden of proof, and any controlling or persuasive authority needed to frame the argument.
- **Element-by-element application** — every required element or factor, listed explicitly with the facts that support it and any known weaknesses.

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

- which procedural vehicle or filing to use and how to frame it;
- the argument sequence and the key evidence or authority to lead with;
- the doctrinal hook, burden-shifting rule, presumption, waiver point, or procedural leverage the route relies on;
- the biggest litigation risk on this route.
</f9>

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

<f11>
Review your assigned theory's `BRIEF.md` — the motion or brief draft and its supporting analysis. Verify it directly against the casefile. Operate strictly on the assigned theory; do not look at other theories.

- Inspect the requested relief and argument for anomalies, overclaims, unsupported factual assertions, missing elements, or concessions an opponent could exploit.
- Write a separate `authority_check.md` under the theory's directory that re-checks every required element, factual assertion, record citation, and legal authority against the reported draft; name any facts, elements, or citations that do not hold up.
- Read the brief and spot-check it for drafting defects — unused facts, dead arguments, misstated standards, contradictory positions, missing burdens, or logic that contradicts what the draft says it proves. A defect that silently weakens the filing is worse than one that is obvious.
- Treat the draft as finished only when every required element or factor is addressed, the requested relief is procedurally available, and the argument is legally sound — not merely when the prose reads smoothly.
- Check the length of the theory's `BRIEF.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the theory's `BRIEF.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your motion or brief and its supporting analysis live in your assigned theory's `BRIEF.md`.

- If your assigned theory's `BRIEF.md` does not exist yet, this is the first pass for that theory: produce the draft from scratch based on the theory's `THEORY.md`.
- If the theory's `BRIEF.md` already exists, it carries the brief challenge reviewer's `<review>` block. Read that feedback and revise the theory's `BRIEF.md` in place to address every point raised. Don't discard the brief and start over, and don't leave a flagged issue unaddressed. Do not read or touch other theories' files.
</f12>

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


I need you to set up a 6-agent pipeline for civil litigation preparation. A case arrives as a factual and procedural summary in `casefile.md`, and the pipeline turns it into vetted legal theories and then a working motion or brief that has been adversarially reviewed for weaknesses.

The six agents:

- **case coordinator** orchestrates the run: it drives the theory phase, then the drafting phase, and tracks progress. It does no legal analysis, drafting, or reviewing itself.
- **litigation strategist** is invoked once at init and produces K differentiated candidate legal theories, one per `theories/{id}-{slug}/THEORY.md`. It never enters the per-theory revision loop.
- **theory reviser** is invoked once per theory-refinement step in the loop. It revises a single assigned theory's `THEORY.md` based on the opposing-counsel analyst's last review for that theory. It never creates new theories.
- **opposing-counsel analyst** reviews the theory it is currently assigned to.
- **brief drafter** drafts the motion or brief for the theory it is currently assigned to.
- **brief challenge reviewer** adversarially reviews the drafted motion or brief for the theory it is currently assigned to.

The pipeline hands work off through theory-namespaced files:

- `casefile.md` — the original case summary, given as input. All five domain agents (litigation strategist, theory reviser, opposing-counsel analyst, brief drafter, brief challenge reviewer) read it.
- `theories/{id}-{slug}/THEORY.md` — one theory per directory, K theories total. The litigation strategist writes K differentiated candidates at init; the theory reviser revises a specific assigned theory in the loop; the opposing-counsel analyst reviews the theory it is assigned to; the brief drafter reads the theory it is assigned to.
- `theories/{id}-{slug}/BRIEF.md` — the motion or brief draft and supporting analysis for that theory. The brief drafter writes it; the brief challenge reviewer reviews it.

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

The case coordinator round-robins across the K theories, first in a theory phase (each theory iterates its theory reviser ↔ opposing-counsel analyst loop) and then in a drafting phase (each theory iterates its brief drafter ↔ brief challenge reviewer loop). Cross-theory reading does not happen: an agent assigned to one theory never reads another theory's files.

I'm providing the following information:

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

<f2>
Which litigation route suits which kind of civil matter — use it to choose one for the strategy:

- **Rule 12 motion practice** — best for legal insufficiency on the pleadings, jurisdictional defects, limitations apparent on the face of the complaint, or failure to plead required elements; not suited to fact-heavy merits disputes.
- **Summary judgment** — best when discovery has created a record showing no genuine dispute of material fact; requires admissible evidence and careful citation to the record.
- **Preliminary injunction** — best for urgent equitable relief where irreparable harm, likelihood of success, balance of equities, and public interest can be shown; weak if damages would be adequate.
- **Contract theory** — best where a valid agreement, breach, causation, and damages can be proved through documents, performance history, and communications.
- **Tort theory** — best where duty, breach, causation, and damages can be tied to concrete conduct; often vulnerable on duty, foreseeability, privilege, or economic-loss limitations.
- **Statutory claim or defense** — best when the statute supplies clear elements, remedies, fee shifting, limitations periods, or administrative prerequisites; check exhaustion, notice, standing, and preemption.
- **Equitable theory** — best where legal remedies are inadequate and facts support fairness-based relief such as estoppel, unjust enrichment, constructive trust, or specific performance; highly fact-sensitive.
- **Discovery or evidentiary motion** — best when the immediate objective is compelling production, excluding unreliable evidence, protecting privileged material, or shaping the record before merits briefing.

Match the procedural vehicle and legal theory to the case posture and available facts; do not force an ill-suited route.
</f2>

<f3>
Your motion or brief and its supporting analysis live in your assigned theory's `BRIEF.md`.

- If your assigned theory's `BRIEF.md` does not exist yet, this is the first pass for that theory: produce the draft from scratch based on the theory's `THEORY.md`.
- If the theory's `BRIEF.md` already exists, it carries the brief challenge reviewer's `<review>` block. Read that feedback and revise the theory's `BRIEF.md` in place to address every point raised. Don't discard the brief and start over, and don't leave a flagged issue unaddressed. Do not read or touch other theories' files.
</f3>

<f4>
Review the theory in your assigned theory's `THEORY.md`. Operate strictly on the assigned theory; do not look at other theories.

- **Case theory** — does it faithfully capture the case? Check that the procedural posture, requested relief, claims or defenses, legal standard, and element-by-element factual application are all accurate.
- **Strategy** — is the chosen procedural vehicle and argument route a sound fit, is the route actually draftable from the available facts and law, and is it likely to survive adversarial opposition?

Be brief and specific. Do not draft any motion or brief yourself — only review.
</f4>

<f5>
Review your assigned theory's `BRIEF.md` — the motion or brief draft and its supporting analysis. Verify it directly against the casefile. Operate strictly on the assigned theory; do not look at other theories.

- Inspect the requested relief and argument for anomalies, overclaims, unsupported factual assertions, missing elements, or concessions an opponent could exploit.
- Write a separate `authority_check.md` under the theory's directory that re-checks every required element, factual assertion, record citation, and legal authority against the reported draft; name any facts, elements, or citations that do not hold up.
- Read the brief and spot-check it for drafting defects — unused facts, dead arguments, misstated standards, contradictory positions, missing burdens, or logic that contradicts what the draft says it proves. A defect that silently weakens the filing is worse than one that is obvious.
- Treat the draft as finished only when every required element or factor is addressed, the requested relief is procedurally available, and the argument is legally sound — not merely when the prose reads smoothly.
- Check the length of the theory's `BRIEF.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the theory's `BRIEF.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the theory in your assigned theory's `THEORY.md` and implement its strategy as a motion or brief:

- Include the caption placeholder, requested relief, introduction, factual background, legal standard, argument sections, and conclusion. State the governing rule accurately, apply every required element or factor, and cite the facts and authorities the theory depends on.
- Draft the argument through to completion — do not leave placeholders such as “add citation,” “insert facts,” or “research later.” If a weakness appears, address it directly rather than hiding it.
- Sanity-check the filing: the requested relief should match the procedural posture, factual assertions should be supported by the casefile or identified exhibits, and the argument should not rely on elements the record cannot support.

Write the draft and its supporting notes up in your assigned theory's `BRIEF.md`. Do not read or touch other theories' files.
</f6>

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

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

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

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

<f9>
Produce K differentiated candidate legal theories, each in its own `theories/{id}-{slug}/THEORY.md`. The K theories should differ meaningfully in their legal route so distinct approaches can be compared downstream, not in trivial ways like changing headings or rephrasing the same argument.

A complete theory in any `THEORY.md` has two parts — a formalized case theory and one chosen litigation strategy.

The **case theory** must state:

- **Procedural posture and requested relief** — for example, complaint, motion to dismiss opposition, summary judgment motion, preliminary injunction, sanctions motion, or discovery motion; this must be exact.
- **Key facts** — the facts that matter legally, including dates, parties, communications, documents, injuries, damages, and procedural deadlines where relevant.
- **Claims, defenses, or issues presented** — each cause of action, affirmative defense, procedural issue, or remedy being advanced.
- **Legal standard** — the governing rule, elements, burden of proof, and any controlling or persuasive authority needed to frame the argument.
- **Element-by-element application** — every required element or factor, listed explicitly with the facts that support it and any known weaknesses.

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

- which procedural vehicle or filing to use and how to frame it;
- the argument sequence and the key evidence or authority to lead with;
- the doctrinal hook, burden-shifting rule, presumption, waiver point, or procedural leverage the route relies on;
- the biggest litigation risk on this route.
</f9>

<f10>
You are working on a civil litigation matter — it may involve contract claims, tort claims, statutory causes of action, equitable relief, procedural motions, or a combination. The original case summary is given in `casefile.md`; read it before starting your part.
</f10>

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

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

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (case coordinator, litigation strategist, theory reviser, opposing-counsel analyst, brief drafter, brief challenge reviewer), which items should go in its prompt? Respond with a JSON object like {"case coordinator": ["f?"], "litigation strategist": ["f?"], "theory reviser": ["f?"], "opposing-counsel analyst": ["f?"], "brief drafter": ["f?"], "brief challenge reviewer": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline for civil litigation preparation. A case arrives as a factual and procedural summary in `casefile.md`, and the pipeline turns it into vetted legal theories and then a working motion or brief that has been adversarially reviewed for weaknesses.

The six agents:

- **case coordinator** orchestrates the run: it drives the theory phase, then the drafting phase, and tracks progress. It does no legal analysis, drafting, or reviewing itself.
- **litigation strategist** is invoked once at init and produces K differentiated candidate legal theories, one per `theories/{id}-{slug}/THEORY.md`. It never enters the per-theory revision loop.
- **theory reviser** is invoked once per theory-refinement step in the loop. It revises a single assigned theory's `THEORY.md` based on the opposing-counsel analyst's last review for that theory. It never creates new theories.
- **opposing-counsel analyst** reviews the theory it is currently assigned to.
- **brief drafter** drafts the motion or brief for the theory it is currently assigned to.
- **brief challenge reviewer** adversarially reviews the drafted motion or brief for the theory it is currently assigned to.

The pipeline hands work off through theory-namespaced files:

- `casefile.md` — the original case summary, given as input. All five domain agents (litigation strategist, theory reviser, opposing-counsel analyst, brief drafter, brief challenge reviewer) read it.
- `theories/{id}-{slug}/THEORY.md` — one theory per directory, K theories total. The litigation strategist writes K differentiated candidates at init; the theory reviser revises a specific assigned theory in the loop; the opposing-counsel analyst reviews the theory it is assigned to; the brief drafter reads the theory it is assigned to.
- `theories/{id}-{slug}/BRIEF.md` — the motion or brief draft and supporting analysis for that theory. The brief drafter writes it; the brief challenge reviewer reviews it.

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

The case coordinator round-robins across the K theories, first in a theory phase (each theory iterates its theory reviser ↔ opposing-counsel analyst loop) and then in a drafting phase (each theory iterates its brief drafter ↔ brief challenge reviewer loop). Cross-theory reading does not happen: an agent assigned to one theory never reads another theory's files.

I'm providing the following prompt fragments:

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

<f2>
Which litigation route suits which kind of civil matter — use it to choose one for the strategy:

- **Rule 12 motion practice** — best for legal insufficiency on the pleadings, jurisdictional defects, limitations apparent on the face of the complaint, or failure to plead required elements; not suited to fact-heavy merits disputes.
- **Summary judgment** — best when discovery has created a record showing no genuine dispute of material fact; requires admissible evidence and careful citation to the record.
- **Preliminary injunction** — best for urgent equitable relief where irreparable harm, likelihood of success, balance of equities, and public interest can be shown; weak if damages would be adequate.
- **Contract theory** — best where a valid agreement, breach, causation, and damages can be proved through documents, performance history, and communications.
- **Tort theory** — best where duty, breach, causation, and damages can be tied to concrete conduct; often vulnerable on duty, foreseeability, privilege, or economic-loss limitations.
- **Statutory claim or defense** — best when the statute supplies clear elements, remedies, fee shifting, limitations periods, or administrative prerequisites; check exhaustion, notice, standing, and preemption.
- **Equitable theory** — best where legal remedies are inadequate and facts support fairness-based relief such as estoppel, unjust enrichment, constructive trust, or specific performance; highly fact-sensitive.
- **Discovery or evidentiary motion** — best when the immediate objective is compelling production, excluding unreliable evidence, protecting privileged material, or shaping the record before merits briefing.

Match the procedural vehicle and legal theory to the case posture and available facts; do not force an ill-suited route.
</f2>

<f3>
Your motion or brief and its supporting analysis live in your assigned theory's `BRIEF.md`.

- If your assigned theory's `BRIEF.md` does not exist yet, this is the first pass for that theory: produce the draft from scratch based on the theory's `THEORY.md`.
- If the theory's `BRIEF.md` already exists, it carries the brief challenge reviewer's `<review>` block. Read that feedback and revise the theory's `BRIEF.md` in place to address every point raised. Don't discard the brief and start over, and don't leave a flagged issue unaddressed. Do not read or touch other theories' files.
</f3>

<f4>
Review the theory in your assigned theory's `THEORY.md`. Operate strictly on the assigned theory; do not look at other theories.

- **Case theory** — does it faithfully capture the case? Check that the procedural posture, requested relief, claims or defenses, legal standard, and element-by-element factual application are all accurate.
- **Strategy** — is the chosen procedural vehicle and argument route a sound fit, is the route actually draftable from the available facts and law, and is it likely to survive adversarial opposition?

Be brief and specific. Do not draft any motion or brief yourself — only review.
</f4>

<f5>
Review your assigned theory's `BRIEF.md` — the motion or brief draft and its supporting analysis. Verify it directly against the casefile. Operate strictly on the assigned theory; do not look at other theories.

- Inspect the requested relief and argument for anomalies, overclaims, unsupported factual assertions, missing elements, or concessions an opponent could exploit.
- Write a separate `authority_check.md` under the theory's directory that re-checks every required element, factual assertion, record citation, and legal authority against the reported draft; name any facts, elements, or citations that do not hold up.
- Read the brief and spot-check it for drafting defects — unused facts, dead arguments, misstated standards, contradictory positions, missing burdens, or logic that contradicts what the draft says it proves. A defect that silently weakens the filing is worse than one that is obvious.
- Treat the draft as finished only when every required element or factor is addressed, the requested relief is procedurally available, and the argument is legally sound — not merely when the prose reads smoothly.
- Check the length of the theory's `BRIEF.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the theory's `BRIEF.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the theory in your assigned theory's `THEORY.md` and implement its strategy as a motion or brief:

- Include the caption placeholder, requested relief, introduction, factual background, legal standard, argument sections, and conclusion. State the governing rule accurately, apply every required element or factor, and cite the facts and authorities the theory depends on.
- Draft the argument through to completion — do not leave placeholders such as “add citation,” “insert facts,” or “research later.” If a weakness appears, address it directly rather than hiding it.
- Sanity-check the filing: the requested relief should match the procedural posture, factual assertions should be supported by the casefile or identified exhibits, and the argument should not rely on elements the record cannot support.

Write the draft and its supporting notes up in your assigned theory's `BRIEF.md`. Do not read or touch other theories' files.
</f6>

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

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

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

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

<f9>
Produce K differentiated candidate legal theories, each in its own `theories/{id}-{slug}/THEORY.md`. The K theories should differ meaningfully in their legal route so distinct approaches can be compared downstream, not in trivial ways like changing headings or rephrasing the same argument.

A complete theory in any `THEORY.md` has two parts — a formalized case theory and one chosen litigation strategy.

The **case theory** must state:

- **Procedural posture and requested relief** — for example, complaint, motion to dismiss opposition, summary judgment motion, preliminary injunction, sanctions motion, or discovery motion; this must be exact.
- **Key facts** — the facts that matter legally, including dates, parties, communications, documents, injuries, damages, and procedural deadlines where relevant.
- **Claims, defenses, or issues presented** — each cause of action, affirmative defense, procedural issue, or remedy being advanced.
- **Legal standard** — the governing rule, elements, burden of proof, and any controlling or persuasive authority needed to frame the argument.
- **Element-by-element application** — every required element or factor, listed explicitly with the facts that support it and any known weaknesses.

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

- which procedural vehicle or filing to use and how to frame it;
- the argument sequence and the key evidence or authority to lead with;
- the doctrinal hook, burden-shifting rule, presumption, waiver point, or procedural leverage the route relies on;
- the biggest litigation risk on this route.
</f9>

<f10>
You are working on a civil litigation matter — it may involve contract claims, tort claims, statutory causes of action, equitable relief, procedural motions, or a combination. The original case summary is given in `casefile.md`; read it before starting your part.
</f10>

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

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

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

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