I need you to set up a 5-agent pipeline that develops a wildfire incident response plan by refining fire-behavior forecasts and tactical operations planning in parallel, with each side informing the other. An incident package arrives as a natural-language briefing in `incident.md`. The pipeline alternates between revising the forecast assumptions (spread potential, trigger points, weather sensitivities, exposure concerns) and revising the operations plan (divisions, resources, tactics, contingencies, and safety controls).

The five agents:

- **incident coordination officer** orchestrates the run by alternating one fire-behavior step with one operations step and tracking progress. It does no forecasting, tactical planning, or reviewing itself.
- **fire-behavior loop** — the **fire behavior analyst** writes the forecast and fire-behavior rationale to `FORECAST.md`; the **red-team fire model reviewer** challenges it. The fire behavior analyst reads `IAP.md` on each revision pass to incorporate operational observations, resource constraints, and field-reported conditions.
- **operations loop** — the **operations plan chief** writes the tactical incident action plan to `IAP.md`; the **incident safety officer** judges it. The operations plan chief reads `FORECAST.md` on each revision pass to align tactics with the latest fire-behavior 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 three files:

- `incident.md` — the original incident briefing, read-only. All four domain agents read it.
- `FORECAST.md` — the fire-behavior forecast and rationale. Fire behavior analyst writes; red-team fire model reviewer reviews; operations plan chief and incident safety officer read it to know which spread scenarios, trigger points, and exposure risks the plan must respect.
- `IAP.md` — the tactical operations plan and operational results. Operations plan chief writes; incident safety officer reviews; fire behavior analyst and red-team fire model reviewer read it to ground the forecast in actual assignments, access limits, and field constraints.

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

Unlike a forecast-then-plan pipeline where modeling must settle before tactics start, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. Forecast assumptions may tighten after seeing operational reports and feasible resource deployments; the operations plan may change after seeing a revised wind scenario, spotting-probability assessment, or evacuation trigger.

I'm providing the following information:

<f1>
Read `incident.md` and `FORECAST.md`, then produce the tactical operations plan:

- Include the incident objectives, operational period, division or group assignments, available resources, communications assumptions, medical plan references, evacuation coordination needs, contingency branches, and clear tactical tasks. Assign resources with realistic capability limits and travel/access constraints.
- Make the plan testable against `FORECAST.md`. If the forecast states a trigger point, your plan should specify the action tied to that trigger. If the forecast states an invariant such as required egress, safety zones, or no direct attack above a flame-length threshold, your plan should preserve it.
- Walk the plan through to completion for the operational period — do not stop at broad strategy. If a tactic depends on an unavailable crew type, closed road, grounded aircraft, or unrealistic production rate, find and fix the root cause; do not hide the gap in vague language.
- Sanity-check the plan against `FORECAST.md`. A hand crew should not be assigned direct attack in flame lengths the forecast says are unsafe; an evacuation trigger should not occur after the modeled arrival time at the community; a division should not rely on an egress route threatened by the same run it is assigned to hold.

Write the plan and its operational rationale up in `IAP.md`.
</f1>

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

| Tool | Suitable for |
|---|---|
| Rothermel surface fire-spread estimates | Grass, brush, timber litter; rate-of-spread and flame-length estimates under specified fuel, slope, and wind |
| Campbell Prediction System alignment analysis | Identifying where wind, slope, and aspect combine to create high-risk runs |
| Haines Index and plume-dominated assessment | Evaluating vertical instability, plume growth, spotting potential, and erratic fire behavior |
| Spotting-distance and ember-cast analysis | Wind-driven spotting across roads, drainages, rivers, or control lines |
| Fuel-moisture and Energy Release Component trends | Burn-period severity, ignition probability, resistance to control, and overnight recovery |
| WFDSS / FSPro-style scenario reasoning | Probabilistic spread pathways, values-at-risk exposure, and strategic risk comparison |
| Trigger-point and time-distance analysis | Evacuation timing, point-protection deadlines, and tactical withdrawal thresholds |
| After-action analogue comparison | Incidents in similar fuel, weather, and terrain where observed behavior constrains plausible forecasts |
</f2>

<f3>
The tactical operations plan lives in `IAP.md`, and you may be invoked on it more than once — the pipeline runs you and the incident safety officer as a loop, alternating with the fire-behavior loop.

- If `IAP.md` does not exist yet, this is the first pass: produce the plan from scratch based on `incident.md`.
- If `IAP.md` already exists, it carries the incident safety officer’s `<review>` block. Read that feedback. Then open `FORECAST.md` and check whether the latest forecast introduces trigger points, safety invariants, spread scenarios, or structural fire-behavior claims your current plan does not yet respect — for example a tighter evacuation deadline, a new spotting concern across the primary line, or an egress route forecast to be compromised. Revise `IAP.md` in place to address every reviewer point and to align with the latest forecast. Don’t discard the previous plan and start over, and don’t leave a flagged issue unaddressed.
</f3>

<f4>
Review `FORECAST.md` against `incident.md` and against the tactical assignments reported in `IAP.md` (if any).

- **Faithfulness** — does the forecast correctly describe the incident stated in `incident.md`? Check fuels, topography, wind direction, access constraints, values at risk, resource availability, and time references.
- **Reasoning soundness** — for each claim, walk through the calculation, model assumption, analogy, or cited fire-behavior principle. Flag hand-waving steps. Verify that spread estimates, spotting assumptions, and trigger times apply under the stated fuel, slope, wind, and moisture conditions.
- **Operational grounding** — open `IAP.md`. If the plan reports division placements, control lines, evacuation timing, or resource limits, do they fit within the forecast's predicted spread windows and hazard areas? A forecast that ignores a division working below an unstable slope or assumes aviation support that the plan says is unavailable is not operationally grounded.

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

<f5>
You orchestrate the run; you never forecast, plan tactics, or review yourself — you only assign the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Assign the fire behavior analyst for the first forecast step (fire behavior analyst, then red-team fire model reviewer), then the operations plan chief for the first operations step (operations plan chief, then incident safety officer).
- **Alternation loop** — alternate one fire-behavior step with one operations step. Neither side terminates early on its own score; even a strong-looking forecast may need revision once the operations plan exposes resource constraints or field observations.
- Cap the total at 20 iterations (10 fire-behavior steps + 10 operations steps). After the cap, stop and summarize.
- Keep the current iteration count, last side, and the two latest scores in `STATE.md`, accurate after each assignment. Read each score from the reviewer’s `<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 + agent name + content) and continue with the next step.
</f5>

<f6>
Produce the fire-behavior forecast for the incident and write it to `FORECAST.md`. A complete forecast covers four kinds of claim, each justified with a calculation, fire-behavior principle, local observation, or cited model assumption.

- **Spread and intensity bounds** — expected and worst-plausible rates of spread, flame-length ranges, spotting distances, arrival-time windows at key values at risk, and the conditions under which those ranges change.
- **Structural properties** — wind alignment, slope effects, fuel continuity, barriers, diurnal recovery, plume-dominated potential, channeling in drainages, or opportunities created by recent burns, roads, rivers, or fuel transitions. State what holds, where, and under which assumptions.
- **Operational invariants** — facts every safe tactical plan must preserve, such as keeping crews out of chimneys during wind shifts, maintaining egress and safety zones, honoring evacuation trigger points, preserving lookout-communication-escape-safety coverage, and avoiding direct attack where flame lengths exceed safe handline thresholds.
- **Uncertainty and update behavior** — confidence in weather inputs, sensitivity to wind speed and direction, expected change at burn-period transitions, likelihood of spotting or crown-fire transition, and what field observations would invalidate the current forecast.

Ground your claims against `IAP.md` if it has reported assignments, resource limits, or field observations. A predicted fire spread that is grossly inconsistent with observed perimeter movement or planned division placement means either the forecast needs revision or the operations plan is unsafe or infeasible — diagnose which side has the issue and state it. Be concrete. “With 15 mph southwest winds, the eastern flank can reach Ridge Road in 3–5 hours unless held at the dozer line” is useful; “the fire may move quickly” is not.
</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 is unsafe, but I am telling you it is unsafe” is still a failing result, not a passing one.
</f7>

<f8>
Keep `IAP.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page operational note; record iteration-by-iteration history in 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 incident coordination officer: what you did, what difficulties you hit or could not 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 wildfire incident response planning problem. The original incident is given as a natural-language briefing in `incident.md`; read it before starting your part. It may describe fuels, topography, forecast weather, communities at risk, roads and access points, available crews and equipment, aviation limits, evacuation concerns, and command objectives.
</f11>

<f12>
The fire-behavior forecast lives in `FORECAST.md`, and you may be invoked on it more than once — the pipeline runs you and the red-team fire model reviewer as a loop, alternating with the operations loop.

- If `FORECAST.md` does not exist yet, this is the first pass: produce the forecast from scratch based on `incident.md`.
- If `FORECAST.md` already exists, it carries the red-team fire model reviewer’s `<review>` block. Read that feedback. Then open `IAP.md` and look at the latest operational assignments, constraints, and reported field observations — they may invalidate, sharpen, or motivate revisions to your claims. Revise `FORECAST.md` in place to address every reviewer point raised and to incorporate any operational evidence that changes your forecast. Don’t discard the previous forecast and start over, and don’t leave a flagged issue unaddressed.
</f12>

<f13>
Review `IAP.md` against `incident.md` and against `FORECAST.md`.

- Inspect the reported tactics for anomalies, unsafe assignments, unrealistic production expectations, missing resources, or contradictions with hazards stated directly in `incident.md`.
- Open `FORECAST.md`. For every trigger point, spread estimate, safety invariant, and high-risk scenario the forecast claims, write a check into a separate `SAFETY_CHECK.md`: does the operations plan preserve egress, keep resources out of predicted entrapment zones, initiate evacuations before forecast arrival times, and match tactics to expected flame length and spotting risk? Mark each check PASS, FAIL, or NEEDS INFORMATION. Name any division, resource, route, or value at risk that violates the forecast.
- Read the operations plan and spot-check it for dangerous assumptions — unused resources that were counted on elsewhere, dead-end egress routes, tactics that contradict the stated strategy, aviation missions planned in smoke or wind conditions that would likely ground aircraft, or night operations without adequate lookouts and communications. A plan that silently exposes crews to an avoidable hazard is worse than one that openly says a task cannot be done.
- Treat the plan as acceptable only when every incident constraint holds, every forecast-claimed safety invariant holds, and the tactics are consistent with the forecast's spread windows and hazard areas — not merely when the plan sounds complete.
- Check the length of `IAP.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `IAP.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 (incident coordination officer, fire behavior analyst, red-team fire model reviewer, operations plan chief, incident safety officer), which items should go in its prompt? Respond with a JSON object like {"incident coordination officer": ["f?"], "fire behavior analyst": ["f?"], "red-team fire model reviewer": ["f?"], "operations plan chief": ["f?"], "incident safety officer": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that develops a wildfire incident response plan by refining fire-behavior forecasts and tactical operations planning in parallel, with each side informing the other. An incident package arrives as a natural-language briefing in `incident.md`. The pipeline alternates between revising the forecast assumptions (spread potential, trigger points, weather sensitivities, exposure concerns) and revising the operations plan (divisions, resources, tactics, contingencies, and safety controls).

The five agents:

- **incident coordination officer** orchestrates the run by alternating one fire-behavior step with one operations step and tracking progress. It does no forecasting, tactical planning, or reviewing itself.
- **fire-behavior loop** — the **fire behavior analyst** writes the forecast and fire-behavior rationale to `FORECAST.md`; the **red-team fire model reviewer** challenges it. The fire behavior analyst reads `IAP.md` on each revision pass to incorporate operational observations, resource constraints, and field-reported conditions.
- **operations loop** — the **operations plan chief** writes the tactical incident action plan to `IAP.md`; the **incident safety officer** judges it. The operations plan chief reads `FORECAST.md` on each revision pass to align tactics with the latest fire-behavior 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 three files:

- `incident.md` — the original incident briefing, read-only. All four domain agents read it.
- `FORECAST.md` — the fire-behavior forecast and rationale. Fire behavior analyst writes; red-team fire model reviewer reviews; operations plan chief and incident safety officer read it to know which spread scenarios, trigger points, and exposure risks the plan must respect.
- `IAP.md` — the tactical operations plan and operational results. Operations plan chief writes; incident safety officer reviews; fire behavior analyst and red-team fire model reviewer read it to ground the forecast in actual assignments, access limits, and field constraints.

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

Unlike a forecast-then-plan pipeline where modeling must settle before tactics start, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. Forecast assumptions may tighten after seeing operational reports and feasible resource deployments; the operations plan may change after seeing a revised wind scenario, spotting-probability assessment, or evacuation trigger.

I'm providing the following prompt fragments:

<f1>
Read `incident.md` and `FORECAST.md`, then produce the tactical operations plan:

- Include the incident objectives, operational period, division or group assignments, available resources, communications assumptions, medical plan references, evacuation coordination needs, contingency branches, and clear tactical tasks. Assign resources with realistic capability limits and travel/access constraints.
- Make the plan testable against `FORECAST.md`. If the forecast states a trigger point, your plan should specify the action tied to that trigger. If the forecast states an invariant such as required egress, safety zones, or no direct attack above a flame-length threshold, your plan should preserve it.
- Walk the plan through to completion for the operational period — do not stop at broad strategy. If a tactic depends on an unavailable crew type, closed road, grounded aircraft, or unrealistic production rate, find and fix the root cause; do not hide the gap in vague language.
- Sanity-check the plan against `FORECAST.md`. A hand crew should not be assigned direct attack in flame lengths the forecast says are unsafe; an evacuation trigger should not occur after the modeled arrival time at the community; a division should not rely on an egress route threatened by the same run it is assigned to hold.

Write the plan and its operational rationale up in `IAP.md`.
</f1>

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

| Tool | Suitable for |
|---|---|
| Rothermel surface fire-spread estimates | Grass, brush, timber litter; rate-of-spread and flame-length estimates under specified fuel, slope, and wind |
| Campbell Prediction System alignment analysis | Identifying where wind, slope, and aspect combine to create high-risk runs |
| Haines Index and plume-dominated assessment | Evaluating vertical instability, plume growth, spotting potential, and erratic fire behavior |
| Spotting-distance and ember-cast analysis | Wind-driven spotting across roads, drainages, rivers, or control lines |
| Fuel-moisture and Energy Release Component trends | Burn-period severity, ignition probability, resistance to control, and overnight recovery |
| WFDSS / FSPro-style scenario reasoning | Probabilistic spread pathways, values-at-risk exposure, and strategic risk comparison |
| Trigger-point and time-distance analysis | Evacuation timing, point-protection deadlines, and tactical withdrawal thresholds |
| After-action analogue comparison | Incidents in similar fuel, weather, and terrain where observed behavior constrains plausible forecasts |
</f2>

<f3>
The tactical operations plan lives in `IAP.md`, and you may be invoked on it more than once — the pipeline runs you and the incident safety officer as a loop, alternating with the fire-behavior loop.

- If `IAP.md` does not exist yet, this is the first pass: produce the plan from scratch based on `incident.md`.
- If `IAP.md` already exists, it carries the incident safety officer’s `<review>` block. Read that feedback. Then open `FORECAST.md` and check whether the latest forecast introduces trigger points, safety invariants, spread scenarios, or structural fire-behavior claims your current plan does not yet respect — for example a tighter evacuation deadline, a new spotting concern across the primary line, or an egress route forecast to be compromised. Revise `IAP.md` in place to address every reviewer point and to align with the latest forecast. Don’t discard the previous plan and start over, and don’t leave a flagged issue unaddressed.
</f3>

<f4>
Review `FORECAST.md` against `incident.md` and against the tactical assignments reported in `IAP.md` (if any).

- **Faithfulness** — does the forecast correctly describe the incident stated in `incident.md`? Check fuels, topography, wind direction, access constraints, values at risk, resource availability, and time references.
- **Reasoning soundness** — for each claim, walk through the calculation, model assumption, analogy, or cited fire-behavior principle. Flag hand-waving steps. Verify that spread estimates, spotting assumptions, and trigger times apply under the stated fuel, slope, wind, and moisture conditions.
- **Operational grounding** — open `IAP.md`. If the plan reports division placements, control lines, evacuation timing, or resource limits, do they fit within the forecast's predicted spread windows and hazard areas? A forecast that ignores a division working below an unstable slope or assumes aviation support that the plan says is unavailable is not operationally grounded.

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

<f5>
You orchestrate the run; you never forecast, plan tactics, or review yourself — you only assign the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Assign the fire behavior analyst for the first forecast step (fire behavior analyst, then red-team fire model reviewer), then the operations plan chief for the first operations step (operations plan chief, then incident safety officer).
- **Alternation loop** — alternate one fire-behavior step with one operations step. Neither side terminates early on its own score; even a strong-looking forecast may need revision once the operations plan exposes resource constraints or field observations.
- Cap the total at 20 iterations (10 fire-behavior steps + 10 operations steps). After the cap, stop and summarize.
- Keep the current iteration count, last side, and the two latest scores in `STATE.md`, accurate after each assignment. Read each score from the reviewer’s `<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 + agent name + content) and continue with the next step.
</f5>

<f6>
Produce the fire-behavior forecast for the incident and write it to `FORECAST.md`. A complete forecast covers four kinds of claim, each justified with a calculation, fire-behavior principle, local observation, or cited model assumption.

- **Spread and intensity bounds** — expected and worst-plausible rates of spread, flame-length ranges, spotting distances, arrival-time windows at key values at risk, and the conditions under which those ranges change.
- **Structural properties** — wind alignment, slope effects, fuel continuity, barriers, diurnal recovery, plume-dominated potential, channeling in drainages, or opportunities created by recent burns, roads, rivers, or fuel transitions. State what holds, where, and under which assumptions.
- **Operational invariants** — facts every safe tactical plan must preserve, such as keeping crews out of chimneys during wind shifts, maintaining egress and safety zones, honoring evacuation trigger points, preserving lookout-communication-escape-safety coverage, and avoiding direct attack where flame lengths exceed safe handline thresholds.
- **Uncertainty and update behavior** — confidence in weather inputs, sensitivity to wind speed and direction, expected change at burn-period transitions, likelihood of spotting or crown-fire transition, and what field observations would invalidate the current forecast.

Ground your claims against `IAP.md` if it has reported assignments, resource limits, or field observations. A predicted fire spread that is grossly inconsistent with observed perimeter movement or planned division placement means either the forecast needs revision or the operations plan is unsafe or infeasible — diagnose which side has the issue and state it. Be concrete. “With 15 mph southwest winds, the eastern flank can reach Ridge Road in 3–5 hours unless held at the dozer line” is useful; “the fire may move quickly” is not.
</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 is unsafe, but I am telling you it is unsafe” is still a failing result, not a passing one.
</f7>

<f8>
Keep `IAP.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page operational note; record iteration-by-iteration history in 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 incident coordination officer: what you did, what difficulties you hit or could not 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 wildfire incident response planning problem. The original incident is given as a natural-language briefing in `incident.md`; read it before starting your part. It may describe fuels, topography, forecast weather, communities at risk, roads and access points, available crews and equipment, aviation limits, evacuation concerns, and command objectives.
</f11>

<f12>
The fire-behavior forecast lives in `FORECAST.md`, and you may be invoked on it more than once — the pipeline runs you and the red-team fire model reviewer as a loop, alternating with the operations loop.

- If `FORECAST.md` does not exist yet, this is the first pass: produce the forecast from scratch based on `incident.md`.
- If `FORECAST.md` already exists, it carries the red-team fire model reviewer’s `<review>` block. Read that feedback. Then open `IAP.md` and look at the latest operational assignments, constraints, and reported field observations — they may invalidate, sharpen, or motivate revisions to your claims. Revise `FORECAST.md` in place to address every reviewer point raised and to incorporate any operational evidence that changes your forecast. Don’t discard the previous forecast and start over, and don’t leave a flagged issue unaddressed.
</f12>

<f13>
Review `IAP.md` against `incident.md` and against `FORECAST.md`.

- Inspect the reported tactics for anomalies, unsafe assignments, unrealistic production expectations, missing resources, or contradictions with hazards stated directly in `incident.md`.
- Open `FORECAST.md`. For every trigger point, spread estimate, safety invariant, and high-risk scenario the forecast claims, write a check into a separate `SAFETY_CHECK.md`: does the operations plan preserve egress, keep resources out of predicted entrapment zones, initiate evacuations before forecast arrival times, and match tactics to expected flame length and spotting risk? Mark each check PASS, FAIL, or NEEDS INFORMATION. Name any division, resource, route, or value at risk that violates the forecast.
- Read the operations plan and spot-check it for dangerous assumptions — unused resources that were counted on elsewhere, dead-end egress routes, tactics that contradict the stated strategy, aviation missions planned in smoke or wind conditions that would likely ground aircraft, or night operations without adequate lookouts and communications. A plan that silently exposes crews to an avoidable hazard is worse than one that openly says a task cannot be done.
- Treat the plan as acceptable only when every incident constraint holds, every forecast-claimed safety invariant holds, and the tactics are consistent with the forecast's spread windows and hazard areas — not merely when the plan sounds complete.
- Check the length of `IAP.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `IAP.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. `# incident coordination officer`). Output only the headered prompts, no preamble.


litigation-manager legal-strategist shadow-counsel discovery-specialist evidentiary-auditor

I need you to set up a 5-agent pipeline that manages corporate litigation defense by developing abstract legal argumentation strategy and concrete evidentiary discovery in parallel, with each side informing the other. A lawsuit arrives as a natural-language statement in `lawsuit.md`. The pipeline alternates between revising the legal strategy (liability bounds, procedural defenses, required elements) and revising the discovery (document review and witness preparation that support those arguments).

The five agents:

- **litigation-manager** orchestrates the run by alternating one legal strategy step with one discovery step and tracking progress. It does no legal analysis, document review, or auditing itself.
- **strategy loop** — the **legal-strategist** writes the abstract legal argumentation strategy to `THEORY.md`; the **shadow-counsel** judges it. The legal-strategist reads `DISCOVERY.md` on each revision pass to incorporate empirical evidentiary findings.
- **discovery loop** — the **discovery-specialist** conducts evidentiary document review and witness prep, documenting results in `DISCOVERY.md`; the **evidentiary-auditor** judges them. The discovery-specialist reads `THEORY.md` on each revision pass to align the evidentiary focus with the latest legal 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:

- `lawsuit.md` — the original lawsuit complaint, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing defense plan per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/THEORY.md` — the legal strategy analysis for that plan. legal-strategist writes; shadow-counsel reviews; discovery-specialist and evidentiary-auditor read it.
- `plans/{id}-{slug}/DISCOVERY.md` — the evidentiary discovery findings and witness outlines for that plan. discovery-specialist writes; evidentiary-auditor reviews; legal-strategist and shadow-counsel read it.

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

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

Within each plan, neither legal strategy nor discovery finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. Legal theory may pivot after seeing the plan's discovery's actual document yields; discovery focus may shift after seeing the plan's legal theory's refined defense elements.

I'm providing the following information:

<f1>
Keep `DISCOVERY.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page memo; record only the current synthesized evidentiary record and move iteration-by-iteration search 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 strategy, review documents, or audit 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 strategy/discovery scores.
- **Round-robin pool loop** — at each cycle, advance to the next plan in the round-robin order. For that plan, dispatch one legal strategy step (legal-strategist, then shadow-counsel) and one discovery step (discovery-specialist, then evidentiary-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` / `THEORY.md` / `DISCOVERY.md` to operate on.
- Neither side terminates early on its own score within a plan; even a perfect-looking legal strategy may need to revise once the discovery process unearths actual documents. The pool keeps cycling even after individual plans look trial-ready.
- Cap the total at 20 × K dispatches (10 strategy + 10 discovery 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 corporate litigation defense, which may involve breach of contract, securities fraud, intellectual property infringement, or a combination. The original claims are given as a natural-language statement in `lawsuit.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 legal argumentation strategy for the plan the litigation-manager has assigned you to this round, and write it to that plan's `THEORY.md` (under `plans/{id}-{slug}/THEORY.md`). A complete legal strategy covers four kinds of claims, each justified with case law citations or statutory analysis.

- **Liability Bounds** — lower and upper bounds on financial exposure, derived from statutory damages caps, mitigation arguments, or insurance coverage limits.
- **Procedural and Structural Defenses** — jurisdictional challenges, statutes of limitations, class action typicality/commonality, or safe harbor provisions. State what defenses apply, where, and under which legal assumptions.
- **Required Elements (Invariants)** — evidentiary requirements the plaintiff must prove (e.g., scienter, proximate cause, strict liability triggers) and defenses we must establish. The discovery's findings should address them; the evidentiary-auditor will verify using e-discovery scripts.
- **Procedural Complexity and Timeline** — likelihood of early dismissal (e.g., summary judgment vs. protracted jury trial), administrative bottlenecks, or settlement viability timelines.

Ground your arguments against the plan's `DISCOVERY.md` if it has reported evidentiary findings. A legal defense claiming "no prior knowledge" that is grossly contradicted by smoking-gun emails in discovery means either the legal theory needs a pivot or the discovery context is misunderstood — diagnose which side has the issue and state it. Be concrete. "Damages are capped at $5M under the relevant statute" is fine; "the case has some procedural elements that may help" is not. Do not read or aggregate across other plans' files.
</f5>

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

<f7>
Match the legal tool to the case structure; do not force an ill-suited one. The list below is useful in corporate litigation strategy.

| Tool | Suitable for |
|---|---|
| Motion to Dismiss (Rule 12(b)(6)) | Facial insufficiency of the complaint; eliminating claims before discovery begins |
| Summary Judgment (Rule 56) | Cases with undisputed material facts; securing early victory based on a clear evidentiary record |
| Piercing the Corporate Veil Analysis | Defending parent companies from subsidiary liabilities; demonstrating corporate separateness |
| Class Certification Defenses | Defeating class actions; attacking Rule 23 typicality, commonality, or adequacy |
| Settlement Leverage Analysis | Iterative negotiations; evaluating settlement viability and optimal timing |
| Statistical Sampling / Privilege Logs | Massive e-discovery loads; defensible review methodologies and protecting work product |
| Evidentiary Exclusions (Daubert / Hearsay) | Witness prep and trial evidence; blocking adverse testimony or documents from being admitted |
| Witness Credibility Vulnerabilities | Witness preparation; assessing vulnerability under cross-examination |
</f7>

<f8>
You operate on the plan the litigation-manager has assigned you to this round. Read `lawsuit.md`, your assigned plan's `PLAN.md`, and your assigned plan's `THEORY.md`, then execute the evidentiary discovery:

- Include every relevant custodian. Create specific search strings and custodian lists, define the document review filters exactly as the legal issues require. Execute the search, check the production status, and summarize both the documentary evidence and the witness prep outlines.
- Make the evidentiary yield testable against the plan's `THEORY.md`. If the legal theory relies on an exposure bound of B, your discovery should substantiate damages mitigation to at most B. If the theory relies on a required legal element (e.g., lack of intent), your documents and witness statements must support it.
- Run the e-discovery queries yourself and review the outputs thoroughly — do not stop while documents are still unreviewed. If a search errors or returns overly broad garbage, find and fix the root cause; do not bury missing data under generic disclaimers.
- Sanity-check the evidence against the plan's `THEORY.md`. A timeline that must be strictly before a certain date should not contain contradictory post-dated emails; a factual claim the theory says holds should hold in the evidence.

Write the evidentiary findings and witness prep outlines up in your assigned plan's `DISCOVERY.md`. Do not read or write any other plan's files.
</f8>

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

- Inspect the reported evidentiary yield for anomalies, devastating admissions ("smoking guns"), or timeline violations stated directly in `lawsuit.md` or in the plan's `PLAN.md`.
- Open the plan's `THEORY.md`. For every factual requirement and liability bound the theory claims, write an e-discovery check into a separate `verify.py` script under the plan's directory: does the document yield support the defense, stay within the damages bound, and avoid triggering adverse inferences? Run it. Name any custodian or document that violates the theory.
- Read the discovery methodology and spot-check it for flaws — omitted key custodians, dead-end search terms, review protocols that contradict the chosen legal defense. A flawed search protocol that silently omits crucial documents is worse than one that crashes the e-discovery platform.
- Treat the discovery phase as finished only when every legal element is supported, every theory-claimed factual invariant holds, and the damages profile is consistent with the theory's bounds — not merely when the search queries run without syntax errors.
- Check the length of the plan's `DISCOVERY.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `DISCOVERY.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 litigation-manager has assigned you to this round. Your legal argumentation strategy lives in that plan's `THEORY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the shadow-counsel as a loop, alternating with that plan's discovery loop, while the litigation-manager round-robins across plans.

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

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

- **Faithfulness** — does the strategy correctly address the claims stated in `lawsuit.md` under the framing set by the plan's `PLAN.md`? Check statutory definitions, liability scopes, and procedural posture.
- **Argument soundness** — for each defense, walk through the case law citation or legal logic. Flag hand-waving legal conclusions. Verify cited precedents apply under the stated facts.
- **Empirical grounding** — open the plan's `DISCOVERY.md`. If the discovery reports actual witness statements or documents, do they fall within the theory's factual assumptions? A jurisdictional defense that is clearly defeated by the subsidiary's physical emails is a signal the argument is too weak; pivot the strategy, or note explicitly that the defense is only preserved for appeal.

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

<f13>
You operate on the plan the litigation-manager has assigned you to this round. Your evidentiary discovery findings and witness prep live in that plan's `DISCOVERY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the evidentiary-auditor as a loop, alternating with that plan's strategy loop, while the litigation-manager round-robins across plans.

- If your assigned plan's `DISCOVERY.md` does not exist yet, this is the first pass for that plan: conduct the discovery from scratch based on `lawsuit.md` and the plan's `PLAN.md`.
- If the plan's `DISCOVERY.md` already exists, it carries the evidentiary-auditor's `<review>` block. Read that feedback. Then open the plan's `THEORY.md` and check whether the latest legal strategy introduces procedural defenses, required factual elements, or exposure bounds your current document review doesn't yet address — for example, a tighter damages bound your evidence is far from substantiating, or a required legal element your witnesses contradict. Revise the plan's `DISCOVERY.md` in place to address every reviewer point and to align with the latest legal strategy. Don't discard the previous findings 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 (litigation-manager, legal-strategist, shadow-counsel, discovery-specialist, evidentiary-auditor), which items should go in its prompt? Respond with a JSON object like {"litigation-manager": ["f?"], "legal-strategist": ["f?"], "shadow-counsel": ["f?"], "discovery-specialist": ["f?"], "evidentiary-auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that manages corporate litigation defense by developing abstract legal argumentation strategy and concrete evidentiary discovery in parallel, with each side informing the other. A lawsuit arrives as a natural-language statement in `lawsuit.md`. The pipeline alternates between revising the legal strategy (liability bounds, procedural defenses, required elements) and revising the discovery (document review and witness preparation that support those arguments).

The five agents:

- **litigation-manager** orchestrates the run by alternating one legal strategy step with one discovery step and tracking progress. It does no legal analysis, document review, or auditing itself.
- **strategy loop** — the **legal-strategist** writes the abstract legal argumentation strategy to `THEORY.md`; the **shadow-counsel** judges it. The legal-strategist reads `DISCOVERY.md` on each revision pass to incorporate empirical evidentiary findings.
- **discovery loop** — the **discovery-specialist** conducts evidentiary document review and witness prep, documenting results in `DISCOVERY.md`; the **evidentiary-auditor** judges them. The discovery-specialist reads `THEORY.md` on each revision pass to align the evidentiary focus with the latest legal 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:

- `lawsuit.md` — the original lawsuit complaint, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing defense plan per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/THEORY.md` — the legal strategy analysis for that plan. legal-strategist writes; shadow-counsel reviews; discovery-specialist and evidentiary-auditor read it.
- `plans/{id}-{slug}/DISCOVERY.md` — the evidentiary discovery findings and witness outlines for that plan. discovery-specialist writes; evidentiary-auditor reviews; legal-strategist and shadow-counsel read it.

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

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

Within each plan, neither legal strategy nor discovery finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. Legal theory may pivot after seeing the plan's discovery's actual document yields; discovery focus may shift after seeing the plan's legal theory's refined defense elements.

I'm providing the following prompt fragments:

<f1>
Keep `DISCOVERY.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page memo; record only the current synthesized evidentiary record and move iteration-by-iteration search 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 strategy, review documents, or audit 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 strategy/discovery scores.
- **Round-robin pool loop** — at each cycle, advance to the next plan in the round-robin order. For that plan, dispatch one legal strategy step (legal-strategist, then shadow-counsel) and one discovery step (discovery-specialist, then evidentiary-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` / `THEORY.md` / `DISCOVERY.md` to operate on.
- Neither side terminates early on its own score within a plan; even a perfect-looking legal strategy may need to revise once the discovery process unearths actual documents. The pool keeps cycling even after individual plans look trial-ready.
- Cap the total at 20 × K dispatches (10 strategy + 10 discovery 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 corporate litigation defense, which may involve breach of contract, securities fraud, intellectual property infringement, or a combination. The original claims are given as a natural-language statement in `lawsuit.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 legal argumentation strategy for the plan the litigation-manager has assigned you to this round, and write it to that plan's `THEORY.md` (under `plans/{id}-{slug}/THEORY.md`). A complete legal strategy covers four kinds of claims, each justified with case law citations or statutory analysis.

- **Liability Bounds** — lower and upper bounds on financial exposure, derived from statutory damages caps, mitigation arguments, or insurance coverage limits.
- **Procedural and Structural Defenses** — jurisdictional challenges, statutes of limitations, class action typicality/commonality, or safe harbor provisions. State what defenses apply, where, and under which legal assumptions.
- **Required Elements (Invariants)** — evidentiary requirements the plaintiff must prove (e.g., scienter, proximate cause, strict liability triggers) and defenses we must establish. The discovery's findings should address them; the evidentiary-auditor will verify using e-discovery scripts.
- **Procedural Complexity and Timeline** — likelihood of early dismissal (e.g., summary judgment vs. protracted jury trial), administrative bottlenecks, or settlement viability timelines.

Ground your arguments against the plan's `DISCOVERY.md` if it has reported evidentiary findings. A legal defense claiming "no prior knowledge" that is grossly contradicted by smoking-gun emails in discovery means either the legal theory needs a pivot or the discovery context is misunderstood — diagnose which side has the issue and state it. Be concrete. "Damages are capped at $5M under the relevant statute" is fine; "the case has some procedural elements that may help" is not. Do not read or aggregate across other plans' files.
</f5>

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

<f7>
Match the legal tool to the case structure; do not force an ill-suited one. The list below is useful in corporate litigation strategy.

| Tool | Suitable for |
|---|---|
| Motion to Dismiss (Rule 12(b)(6)) | Facial insufficiency of the complaint; eliminating claims before discovery begins |
| Summary Judgment (Rule 56) | Cases with undisputed material facts; securing early victory based on a clear evidentiary record |
| Piercing the Corporate Veil Analysis | Defending parent companies from subsidiary liabilities; demonstrating corporate separateness |
| Class Certification Defenses | Defeating class actions; attacking Rule 23 typicality, commonality, or adequacy |
| Settlement Leverage Analysis | Iterative negotiations; evaluating settlement viability and optimal timing |
| Statistical Sampling / Privilege Logs | Massive e-discovery loads; defensible review methodologies and protecting work product |
| Evidentiary Exclusions (Daubert / Hearsay) | Witness prep and trial evidence; blocking adverse testimony or documents from being admitted |
| Witness Credibility Vulnerabilities | Witness preparation; assessing vulnerability under cross-examination |
</f7>

<f8>
You operate on the plan the litigation-manager has assigned you to this round. Read `lawsuit.md`, your assigned plan's `PLAN.md`, and your assigned plan's `THEORY.md`, then execute the evidentiary discovery:

- Include every relevant custodian. Create specific search strings and custodian lists, define the document review filters exactly as the legal issues require. Execute the search, check the production status, and summarize both the documentary evidence and the witness prep outlines.
- Make the evidentiary yield testable against the plan's `THEORY.md`. If the legal theory relies on an exposure bound of B, your discovery should substantiate damages mitigation to at most B. If the theory relies on a required legal element (e.g., lack of intent), your documents and witness statements must support it.
- Run the e-discovery queries yourself and review the outputs thoroughly — do not stop while documents are still unreviewed. If a search errors or returns overly broad garbage, find and fix the root cause; do not bury missing data under generic disclaimers.
- Sanity-check the evidence against the plan's `THEORY.md`. A timeline that must be strictly before a certain date should not contain contradictory post-dated emails; a factual claim the theory says holds should hold in the evidence.

Write the evidentiary findings and witness prep outlines up in your assigned plan's `DISCOVERY.md`. Do not read or write any other plan's files.
</f8>

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

- Inspect the reported evidentiary yield for anomalies, devastating admissions ("smoking guns"), or timeline violations stated directly in `lawsuit.md` or in the plan's `PLAN.md`.
- Open the plan's `THEORY.md`. For every factual requirement and liability bound the theory claims, write an e-discovery check into a separate `verify.py` script under the plan's directory: does the document yield support the defense, stay within the damages bound, and avoid triggering adverse inferences? Run it. Name any custodian or document that violates the theory.
- Read the discovery methodology and spot-check it for flaws — omitted key custodians, dead-end search terms, review protocols that contradict the chosen legal defense. A flawed search protocol that silently omits crucial documents is worse than one that crashes the e-discovery platform.
- Treat the discovery phase as finished only when every legal element is supported, every theory-claimed factual invariant holds, and the damages profile is consistent with the theory's bounds — not merely when the search queries run without syntax errors.
- Check the length of the plan's `DISCOVERY.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `DISCOVERY.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 litigation-manager has assigned you to this round. Your legal argumentation strategy lives in that plan's `THEORY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the shadow-counsel as a loop, alternating with that plan's discovery loop, while the litigation-manager round-robins across plans.

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

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

- **Faithfulness** — does the strategy correctly address the claims stated in `lawsuit.md` under the framing set by the plan's `PLAN.md`? Check statutory definitions, liability scopes, and procedural posture.
- **Argument soundness** — for each defense, walk through the case law citation or legal logic. Flag hand-waving legal conclusions. Verify cited precedents apply under the stated facts.
- **Empirical grounding** — open the plan's `DISCOVERY.md`. If the discovery reports actual witness statements or documents, do they fall within the theory's factual assumptions? A jurisdictional defense that is clearly defeated by the subsidiary's physical emails is a signal the argument is too weak; pivot the strategy, or note explicitly that the defense is only preserved for appeal.

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

<f13>
You operate on the plan the litigation-manager has assigned you to this round. Your evidentiary discovery findings and witness prep live in that plan's `DISCOVERY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the evidentiary-auditor as a loop, alternating with that plan's strategy loop, while the litigation-manager round-robins across plans.

- If your assigned plan's `DISCOVERY.md` does not exist yet, this is the first pass for that plan: conduct the discovery from scratch based on `lawsuit.md` and the plan's `PLAN.md`.
- If the plan's `DISCOVERY.md` already exists, it carries the evidentiary-auditor's `<review>` block. Read that feedback. Then open the plan's `THEORY.md` and check whether the latest legal strategy introduces procedural defenses, required factual elements, or exposure bounds your current document review doesn't yet address — for example, a tighter damages bound your evidence is far from substantiating, or a required legal element your witnesses contradict. Revise the plan's `DISCOVERY.md` in place to address every reviewer point and to align with the latest legal strategy. Don't discard the previous findings 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. `# litigation-manager`). Output only the headered prompts, no preamble.


I need you to set up a 5-agent pipeline that manages corporate litigation defense by developing abstract legal argumentation strategy and concrete evidentiary discovery in parallel, with each side informing the other. A lawsuit arrives as a natural-language statement in `lawsuit.md`. The pipeline alternates between revising the legal strategy (liability bounds, procedural defenses, required elements) and revising the discovery (document review and witness preparation that support those arguments).

The five agents:

- **litigation-manager** orchestrates the run by alternating one legal strategy step with one discovery step and tracking progress. It does no legal analysis, document review, or auditing itself.
- **strategy loop** — the **legal-strategist** writes the abstract legal argumentation strategy to `THEORY.md`; the **shadow-counsel** judges it. The legal-strategist reads `DISCOVERY.md` on each revision pass to incorporate empirical evidentiary findings.
- **discovery loop** — the **discovery-specialist** conducts evidentiary document review and witness prep, documenting results in `DISCOVERY.md`; the **evidentiary-auditor** judges them. The discovery-specialist reads `THEORY.md` on each revision pass to align the evidentiary focus with the latest legal 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:

- `lawsuit.md` — the original lawsuit complaint, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing defense plan per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/THEORY.md` — the legal strategy analysis for that plan. legal-strategist writes; shadow-counsel reviews; discovery-specialist and evidentiary-auditor read it.
- `plans/{id}-{slug}/DISCOVERY.md` — the evidentiary discovery findings and witness outlines for that plan. discovery-specialist writes; evidentiary-auditor reviews; legal-strategist and shadow-counsel read it.

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

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

Within each plan, neither legal strategy nor discovery finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. Legal theory may pivot after seeing the plan's discovery's actual document yields; discovery focus may shift after seeing the plan's legal theory's refined defense elements.

I'm providing the following information:

<f1>
You operate on the plan the litigation-manager has assigned you to this round. Read `lawsuit.md`, your assigned plan's `PLAN.md`, and your assigned plan's `THEORY.md`, then execute the evidentiary discovery:

- Include every relevant custodian. Create specific search strings and custodian lists, define the document review filters exactly as the legal issues require. Execute the search, check the production status, and summarize both the documentary evidence and the witness prep outlines.
- Make the evidentiary yield testable against the plan's `THEORY.md`. If the legal theory relies on an exposure bound of B, your discovery should substantiate damages mitigation to at most B. If the theory relies on a required legal element (e.g., lack of intent), your documents and witness statements must support it.
- Run the e-discovery queries yourself and review the outputs thoroughly — do not stop while documents are still unreviewed. If a search errors or returns overly broad garbage, find and fix the root cause; do not bury missing data under generic disclaimers.
- Sanity-check the evidence against the plan's `THEORY.md`. A timeline that must be strictly before a certain date should not contain contradictory post-dated emails; a factual claim the theory says holds should hold in the evidence.

Write the evidentiary findings and witness prep outlines up in your assigned plan's `DISCOVERY.md`. Do not read or write any other plan's files.
</f1>

<f2>
Match the legal tool to the case structure; do not force an ill-suited one. The list below is useful in corporate litigation strategy.

| Tool | Suitable for |
|---|---|
| Motion to Dismiss (Rule 12(b)(6)) | Facial insufficiency of the complaint; eliminating claims before discovery begins |
| Summary Judgment (Rule 56) | Cases with undisputed material facts; securing early victory based on a clear evidentiary record |
| Piercing the Corporate Veil Analysis | Defending parent companies from subsidiary liabilities; demonstrating corporate separateness |
| Class Certification Defenses | Defeating class actions; attacking Rule 23 typicality, commonality, or adequacy |
| Settlement Leverage Analysis | Iterative negotiations; evaluating settlement viability and optimal timing |
| Statistical Sampling / Privilege Logs | Massive e-discovery loads; defensible review methodologies and protecting work product |
| Evidentiary Exclusions (Daubert / Hearsay) | Witness prep and trial evidence; blocking adverse testimony or documents from being admitted |
| Witness Credibility Vulnerabilities | Witness preparation; assessing vulnerability under cross-examination |
</f2>

<f3>
You operate on the plan the litigation-manager has assigned you to this round. Your evidentiary discovery findings and witness prep live in that plan's `DISCOVERY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the evidentiary-auditor as a loop, alternating with that plan's strategy loop, while the litigation-manager round-robins across plans.

- If your assigned plan's `DISCOVERY.md` does not exist yet, this is the first pass for that plan: conduct the discovery from scratch based on `lawsuit.md` and the plan's `PLAN.md`.
- If the plan's `DISCOVERY.md` already exists, it carries the evidentiary-auditor's `<review>` block. Read that feedback. Then open the plan's `THEORY.md` and check whether the latest legal strategy introduces procedural defenses, required factual elements, or exposure bounds your current document review doesn't yet address — for example, a tighter damages bound your evidence is far from substantiating, or a required legal element your witnesses contradict. Revise the plan's `DISCOVERY.md` in place to address every reviewer point and to align with the latest legal strategy. Don't discard the previous findings and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f3>

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

- **Faithfulness** — does the strategy correctly address the claims stated in `lawsuit.md` under the framing set by the plan's `PLAN.md`? Check statutory definitions, liability scopes, and procedural posture.
- **Argument soundness** — for each defense, walk through the case law citation or legal logic. Flag hand-waving legal conclusions. Verify cited precedents apply under the stated facts.
- **Empirical grounding** — open the plan's `DISCOVERY.md`. If the discovery reports actual witness statements or documents, do they fall within the theory's factual assumptions? A jurisdictional defense that is clearly defeated by the subsidiary's physical emails is a signal the argument is too weak; pivot the strategy, or note explicitly that the defense is only preserved for appeal.

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

<f5>
You orchestrate the run; you never draft strategy, review documents, or audit 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 strategy/discovery scores.
- **Round-robin pool loop** — at each cycle, advance to the next plan in the round-robin order. For that plan, dispatch one legal strategy step (legal-strategist, then shadow-counsel) and one discovery step (discovery-specialist, then evidentiary-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` / `THEORY.md` / `DISCOVERY.md` to operate on.
- Neither side terminates early on its own score within a plan; even a perfect-looking legal strategy may need to revise once the discovery process unearths actual documents. The pool keeps cycling even after individual plans look trial-ready.
- Cap the total at 20 × K dispatches (10 strategy + 10 discovery 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 legal argumentation strategy for the plan the litigation-manager has assigned you to this round, and write it to that plan's `THEORY.md` (under `plans/{id}-{slug}/THEORY.md`). A complete legal strategy covers four kinds of claims, each justified with case law citations or statutory analysis.

- **Liability Bounds** — lower and upper bounds on financial exposure, derived from statutory damages caps, mitigation arguments, or insurance coverage limits.
- **Procedural and Structural Defenses** — jurisdictional challenges, statutes of limitations, class action typicality/commonality, or safe harbor provisions. State what defenses apply, where, and under which legal assumptions.
- **Required Elements (Invariants)** — evidentiary requirements the plaintiff must prove (e.g., scienter, proximate cause, strict liability triggers) and defenses we must establish. The discovery's findings should address them; the evidentiary-auditor will verify using e-discovery scripts.
- **Procedural Complexity and Timeline** — likelihood of early dismissal (e.g., summary judgment vs. protracted jury trial), administrative bottlenecks, or settlement viability timelines.

Ground your arguments against the plan's `DISCOVERY.md` if it has reported evidentiary findings. A legal defense claiming "no prior knowledge" that is grossly contradicted by smoking-gun emails in discovery means either the legal theory needs a pivot or the discovery context is misunderstood — diagnose which side has the issue and state it. Be concrete. "Damages are capped at $5M under the relevant statute" is fine; "the case has some procedural elements 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 `DISCOVERY.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page memo; record only the current synthesized evidentiary record and move iteration-by-iteration search 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 litigation-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 corporate litigation defense, which may involve breach of contract, securities fraud, intellectual property infringement, or a combination. The original claims are given as a natural-language statement in `lawsuit.md`; read it before starting your part.
</f11>

<f12>
You operate on the plan the litigation-manager has assigned you to this round. Your legal argumentation strategy lives in that plan's `THEORY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the shadow-counsel as a loop, alternating with that plan's discovery loop, while the litigation-manager round-robins across plans.

- If your assigned plan's `THEORY.md` does not exist yet, this is the first pass for that plan: produce the legal strategy from scratch based on `lawsuit.md` and the plan's `PLAN.md`.
- If the plan's `THEORY.md` already exists, it carries the shadow-counsel's `<review>` block. Read that feedback. Then open the plan's `DISCOVERY.md` and look at the latest reported evidentiary facts — they may invalidate, sharpen, or motivate revisions to your legal claims. Revise the plan's `THEORY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your strategy. Don't discard the previous strategy 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 `DISCOVERY.md` against `lawsuit.md`, against the plan's `PLAN.md`, and against the plan's `THEORY.md`. Operate strictly on the assigned plan's files; do not look at other plans.

- Inspect the reported evidentiary yield for anomalies, devastating admissions ("smoking guns"), or timeline violations stated directly in `lawsuit.md` or in the plan's `PLAN.md`.
- Open the plan's `THEORY.md`. For every factual requirement and liability bound the theory claims, write an e-discovery check into a separate `verify.py` script under the plan's directory: does the document yield support the defense, stay within the damages bound, and avoid triggering adverse inferences? Run it. Name any custodian or document that violates the theory.
- Read the discovery methodology and spot-check it for flaws — omitted key custodians, dead-end search terms, review protocols that contradict the chosen legal defense. A flawed search protocol that silently omits crucial documents is worse than one that crashes the e-discovery platform.
- Treat the discovery phase as finished only when every legal element is supported, every theory-claimed factual invariant holds, and the damages profile is consistent with the theory's bounds — not merely when the search queries run without syntax errors.
- Check the length of the plan's `DISCOVERY.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `DISCOVERY.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 (litigation-manager, legal-strategist, shadow-counsel, discovery-specialist, evidentiary-auditor), which items should go in its prompt? Respond with a JSON object like {"litigation-manager": ["f?"], "legal-strategist": ["f?"], "shadow-counsel": ["f?"], "discovery-specialist": ["f?"], "evidentiary-auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that manages corporate litigation defense by developing abstract legal argumentation strategy and concrete evidentiary discovery in parallel, with each side informing the other. A lawsuit arrives as a natural-language statement in `lawsuit.md`. The pipeline alternates between revising the legal strategy (liability bounds, procedural defenses, required elements) and revising the discovery (document review and witness preparation that support those arguments).

The five agents:

- **litigation-manager** orchestrates the run by alternating one legal strategy step with one discovery step and tracking progress. It does no legal analysis, document review, or auditing itself.
- **strategy loop** — the **legal-strategist** writes the abstract legal argumentation strategy to `THEORY.md`; the **shadow-counsel** judges it. The legal-strategist reads `DISCOVERY.md` on each revision pass to incorporate empirical evidentiary findings.
- **discovery loop** — the **discovery-specialist** conducts evidentiary document review and witness prep, documenting results in `DISCOVERY.md`; the **evidentiary-auditor** judges them. The discovery-specialist reads `THEORY.md` on each revision pass to align the evidentiary focus with the latest legal 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:

- `lawsuit.md` — the original lawsuit complaint, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing defense plan per directory, K plans total, given as input (read-only). All four domain agents read the PLAN.md of the plan they are currently assigned to.
- `plans/{id}-{slug}/THEORY.md` — the legal strategy analysis for that plan. legal-strategist writes; shadow-counsel reviews; discovery-specialist and evidentiary-auditor read it.
- `plans/{id}-{slug}/DISCOVERY.md` — the evidentiary discovery findings and witness outlines for that plan. discovery-specialist writes; evidentiary-auditor reviews; legal-strategist and shadow-counsel read it.

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

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

Within each plan, neither legal strategy nor discovery finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. Legal theory may pivot after seeing the plan's discovery's actual document yields; discovery focus may shift after seeing the plan's legal theory's refined defense elements.

I'm providing the following prompt fragments:

<f1>
You operate on the plan the litigation-manager has assigned you to this round. Read `lawsuit.md`, your assigned plan's `PLAN.md`, and your assigned plan's `THEORY.md`, then execute the evidentiary discovery:

- Include every relevant custodian. Create specific search strings and custodian lists, define the document review filters exactly as the legal issues require. Execute the search, check the production status, and summarize both the documentary evidence and the witness prep outlines.
- Make the evidentiary yield testable against the plan's `THEORY.md`. If the legal theory relies on an exposure bound of B, your discovery should substantiate damages mitigation to at most B. If the theory relies on a required legal element (e.g., lack of intent), your documents and witness statements must support it.
- Run the e-discovery queries yourself and review the outputs thoroughly — do not stop while documents are still unreviewed. If a search errors or returns overly broad garbage, find and fix the root cause; do not bury missing data under generic disclaimers.
- Sanity-check the evidence against the plan's `THEORY.md`. A timeline that must be strictly before a certain date should not contain contradictory post-dated emails; a factual claim the theory says holds should hold in the evidence.

Write the evidentiary findings and witness prep outlines up in your assigned plan's `DISCOVERY.md`. Do not read or write any other plan's files.
</f1>

<f2>
Match the legal tool to the case structure; do not force an ill-suited one. The list below is useful in corporate litigation strategy.

| Tool | Suitable for |
|---|---|
| Motion to Dismiss (Rule 12(b)(6)) | Facial insufficiency of the complaint; eliminating claims before discovery begins |
| Summary Judgment (Rule 56) | Cases with undisputed material facts; securing early victory based on a clear evidentiary record |
| Piercing the Corporate Veil Analysis | Defending parent companies from subsidiary liabilities; demonstrating corporate separateness |
| Class Certification Defenses | Defeating class actions; attacking Rule 23 typicality, commonality, or adequacy |
| Settlement Leverage Analysis | Iterative negotiations; evaluating settlement viability and optimal timing |
| Statistical Sampling / Privilege Logs | Massive e-discovery loads; defensible review methodologies and protecting work product |
| Evidentiary Exclusions (Daubert / Hearsay) | Witness prep and trial evidence; blocking adverse testimony or documents from being admitted |
| Witness Credibility Vulnerabilities | Witness preparation; assessing vulnerability under cross-examination |
</f2>

<f3>
You operate on the plan the litigation-manager has assigned you to this round. Your evidentiary discovery findings and witness prep live in that plan's `DISCOVERY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the evidentiary-auditor as a loop, alternating with that plan's strategy loop, while the litigation-manager round-robins across plans.

- If your assigned plan's `DISCOVERY.md` does not exist yet, this is the first pass for that plan: conduct the discovery from scratch based on `lawsuit.md` and the plan's `PLAN.md`.
- If the plan's `DISCOVERY.md` already exists, it carries the evidentiary-auditor's `<review>` block. Read that feedback. Then open the plan's `THEORY.md` and check whether the latest legal strategy introduces procedural defenses, required factual elements, or exposure bounds your current document review doesn't yet address — for example, a tighter damages bound your evidence is far from substantiating, or a required legal element your witnesses contradict. Revise the plan's `DISCOVERY.md` in place to address every reviewer point and to align with the latest legal strategy. Don't discard the previous findings and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f3>

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

- **Faithfulness** — does the strategy correctly address the claims stated in `lawsuit.md` under the framing set by the plan's `PLAN.md`? Check statutory definitions, liability scopes, and procedural posture.
- **Argument soundness** — for each defense, walk through the case law citation or legal logic. Flag hand-waving legal conclusions. Verify cited precedents apply under the stated facts.
- **Empirical grounding** — open the plan's `DISCOVERY.md`. If the discovery reports actual witness statements or documents, do they fall within the theory's factual assumptions? A jurisdictional defense that is clearly defeated by the subsidiary's physical emails is a signal the argument is too weak; pivot the strategy, or note explicitly that the defense is only preserved for appeal.

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

<f5>
You orchestrate the run; you never draft strategy, review documents, or audit 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 strategy/discovery scores.
- **Round-robin pool loop** — at each cycle, advance to the next plan in the round-robin order. For that plan, dispatch one legal strategy step (legal-strategist, then shadow-counsel) and one discovery step (discovery-specialist, then evidentiary-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` / `THEORY.md` / `DISCOVERY.md` to operate on.
- Neither side terminates early on its own score within a plan; even a perfect-looking legal strategy may need to revise once the discovery process unearths actual documents. The pool keeps cycling even after individual plans look trial-ready.
- Cap the total at 20 × K dispatches (10 strategy + 10 discovery 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 legal argumentation strategy for the plan the litigation-manager has assigned you to this round, and write it to that plan's `THEORY.md` (under `plans/{id}-{slug}/THEORY.md`). A complete legal strategy covers four kinds of claims, each justified with case law citations or statutory analysis.

- **Liability Bounds** — lower and upper bounds on financial exposure, derived from statutory damages caps, mitigation arguments, or insurance coverage limits.
- **Procedural and Structural Defenses** — jurisdictional challenges, statutes of limitations, class action typicality/commonality, or safe harbor provisions. State what defenses apply, where, and under which legal assumptions.
- **Required Elements (Invariants)** — evidentiary requirements the plaintiff must prove (e.g., scienter, proximate cause, strict liability triggers) and defenses we must establish. The discovery's findings should address them; the evidentiary-auditor will verify using e-discovery scripts.
- **Procedural Complexity and Timeline** — likelihood of early dismissal (e.g., summary judgment vs. protracted jury trial), administrative bottlenecks, or settlement viability timelines.

Ground your arguments against the plan's `DISCOVERY.md` if it has reported evidentiary findings. A legal defense claiming "no prior knowledge" that is grossly contradicted by smoking-gun emails in discovery means either the legal theory needs a pivot or the discovery context is misunderstood — diagnose which side has the issue and state it. Be concrete. "Damages are capped at $5M under the relevant statute" is fine; "the case has some procedural elements 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 `DISCOVERY.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page memo; record only the current synthesized evidentiary record and move iteration-by-iteration search 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 litigation-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 corporate litigation defense, which may involve breach of contract, securities fraud, intellectual property infringement, or a combination. The original claims are given as a natural-language statement in `lawsuit.md`; read it before starting your part.
</f11>

<f12>
You operate on the plan the litigation-manager has assigned you to this round. Your legal argumentation strategy lives in that plan's `THEORY.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the shadow-counsel as a loop, alternating with that plan's discovery loop, while the litigation-manager round-robins across plans.

- If your assigned plan's `THEORY.md` does not exist yet, this is the first pass for that plan: produce the legal strategy from scratch based on `lawsuit.md` and the plan's `PLAN.md`.
- If the plan's `THEORY.md` already exists, it carries the shadow-counsel's `<review>` block. Read that feedback. Then open the plan's `DISCOVERY.md` and look at the latest reported evidentiary facts — they may invalidate, sharpen, or motivate revisions to your legal claims. Revise the plan's `THEORY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your strategy. Don't discard the previous strategy 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 `DISCOVERY.md` against `lawsuit.md`, against the plan's `PLAN.md`, and against the plan's `THEORY.md`. Operate strictly on the assigned plan's files; do not look at other plans.

- Inspect the reported evidentiary yield for anomalies, devastating admissions ("smoking guns"), or timeline violations stated directly in `lawsuit.md` or in the plan's `PLAN.md`.
- Open the plan's `THEORY.md`. For every factual requirement and liability bound the theory claims, write an e-discovery check into a separate `verify.py` script under the plan's directory: does the document yield support the defense, stay within the damages bound, and avoid triggering adverse inferences? Run it. Name any custodian or document that violates the theory.
- Read the discovery methodology and spot-check it for flaws — omitted key custodians, dead-end search terms, review protocols that contradict the chosen legal defense. A flawed search protocol that silently omits crucial documents is worse than one that crashes the e-discovery platform.
- Treat the discovery phase as finished only when every legal element is supported, every theory-claimed factual invariant holds, and the damages profile is consistent with the theory's bounds — not merely when the search queries run without syntax errors.
- Check the length of the plan's `DISCOVERY.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `DISCOVERY.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. `# litigation-manager`). Output only the headered prompts, no preamble.