I need you to set up a 3-agent pipeline for patent validity challenge preparation: matter coordinator, patent search specialist, and invalidity reviewer.

- **matter coordinator** orchestrates: each round it selects which prior-art theory to pursue next, calls the patent search specialist on that theory, extracts the claim-chart file path from the patent search specialist's reply, then calls the invalidity reviewer on that path, decrements a counter, and loops. Does no patent analysis itself.
- **patent search specialist** investigates the patent, asserted claims, prosecution history, and prior-art sources for the theory it is given, writes an invalidity chart file, and records any new prior-art theories or claim attack surfaces it notices along the way.
- **invalidity reviewer** evaluates the chart against validity-challenge criteria and persists the verdict.

I'm providing the following information:

<f1>
You drive the select → search → review → improve loop: each round, select the next prior-art theory, then alternate calls to the patent search specialist and invalidity reviewer agents.

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

Loop:

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

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

**Calling rules**

- Do **not** analyze claims, search prior art, write charts, or do reviews yourself — delegate everything to the two sub-agents.
- If patent search specialist or invalidity reviewer errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

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

<f2>
Each round, before calling the patent search specialist, read theories.xml and select which theory the patent search specialist should work on:

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

<f3>
While exploring the patent, prosecution history, asserted claim set, prior-art databases, standards archives, product documentation, or litigation materials, the moment you spot any potential new invalidity theory or claim attack surface — even if you are unsure it holds — immediately append it to theories.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a theory is not a commitment to pursue it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next theory is selected.
</f3>

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

1. Update the chart file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Reference accuracy | pass/fail | ... |
| Invalidity rationale | pass/fail | ... |
| Element mapping | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Verifiability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Argument strength | pass/fail | ... |

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

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

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

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

<f6>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Addresses the asserted patent, challenged claims, and permitted invalidity grounds for this matter |
| Reference accuracy | Prior-art citations, page numbers, figure numbers, publication dates, and quoted passages must exactly match the cited source copies |
| Invalidity rationale | Legal theory is consistent with the chart's own evidence, no self-contradiction, no overclaiming |
| Element mapping | Pinpoint each claim limitation and explain where it is disclosed or why it would have been obvious |
| Evidence package | Includes source copies, archive records where needed, translations if applicable, and enough context to verify the mapping without guesswork |
| Verifiability | Materials can be checked end-to-end without manual reconstruction by the invalidity reviewer; priority, public availability, and claim-version assumptions are stated |
| Deduplication | Search prior IPRs, litigation filings, prosecution history, examiner-cited art, and known invalidity contentions to confirm the argument is not already known or already disposed of |
| Argument strength | The theory must materially improve the validity challenge beyond merely naming a cumulative reference or repeating an examiner-considered argument |

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

- References to nonexistent prior art, fabricated publication dates, or AI-hallucinated quotations
- Invalidity rationale contradicts the chart's own limitation mapping
- Chart relies on a reference that post-dates the applicable priority date without explaining why that is permissible
- Citations inconsistent with the source copies or asserted claim version
- Evidence package is incomplete and requires the invalidity reviewer to assemble missing materials
- Argument is merely cumulative of examiner-considered art or previously served invalidity contentions, with no material improvement
</f6>

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

<f8>
You are preparing materials for a patent validity challenge against asserted claims in a technology patent.

Read the challenge rules and claim-construction assumptions first: ./challenge-rules.md
</f8>

<f9>
Assume the patent has already gone through prosecution, portfolio diligence, and at least a basic prior-art search. Any facially obvious invalidity argument may already have been considered. So:

- Don't chart shallow arguments that are apparent from the patent's front page or a keyword-only search — if it were that obvious, opposing counsel or the examiner likely already addressed it
- Valuable invalidity theories usually hide in non-obvious references, overlooked priority problems, inherency, standards documents, product manuals, archived web materials, or combinations whose motivation to combine is well supported

**Writing the chart**

Each theory corresponds to its own chart file at `charts/{id}-{slug}.md`, where `{id}` and `{slug}` come from the theory's id and slug attributes in theories.xml.

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

- `## Chart Title` — concise, clear invalidity theory title
- `## Invalidity Rationale` — what basis it supports, such as anticipation, obviousness, lack of written description, or priority-date defeat
- `## Short Description` — short writeup of the theory, with claim numbers, limitation identifiers, and prior-art references
- `## Evidence and Mapping Details` — quotations, page/line/figure citations, archive links, and a limitation-by-limitation mapping sufficient for the invalidity reviewer to verify

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

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

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

I need you to set up a 3-agent pipeline for patent validity challenge preparation: matter coordinator, patent search specialist, and invalidity reviewer.

- **matter coordinator** orchestrates: each round it selects which prior-art theory to pursue next, calls the patent search specialist on that theory, extracts the claim-chart file path from the patent search specialist's reply, then calls the invalidity reviewer on that path, decrements a counter, and loops. Does no patent analysis itself.
- **patent search specialist** investigates the patent, asserted claims, prosecution history, and prior-art sources for the theory it is given, writes an invalidity chart file, and records any new prior-art theories or claim attack surfaces it notices along the way.
- **invalidity reviewer** evaluates the chart against validity-challenge criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
You drive the select → search → review → improve loop: each round, select the next prior-art theory, then alternate calls to the patent search specialist and invalidity reviewer agents.

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

Loop:

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

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

**Calling rules**

- Do **not** analyze claims, search prior art, write charts, or do reviews yourself — delegate everything to the two sub-agents.
- If patent search specialist or invalidity reviewer errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

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

<f2>
Each round, before calling the patent search specialist, read theories.xml and select which theory the patent search specialist should work on:

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

<f3>
While exploring the patent, prosecution history, asserted claim set, prior-art databases, standards archives, product documentation, or litigation materials, the moment you spot any potential new invalidity theory or claim attack surface — even if you are unsure it holds — immediately append it to theories.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a theory is not a commitment to pursue it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next theory is selected.
</f3>

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

1. Update the chart file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Reference accuracy | pass/fail | ... |
| Invalidity rationale | pass/fail | ... |
| Element mapping | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Verifiability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Argument strength | pass/fail | ... |

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

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

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

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

<f6>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Addresses the asserted patent, challenged claims, and permitted invalidity grounds for this matter |
| Reference accuracy | Prior-art citations, page numbers, figure numbers, publication dates, and quoted passages must exactly match the cited source copies |
| Invalidity rationale | Legal theory is consistent with the chart's own evidence, no self-contradiction, no overclaiming |
| Element mapping | Pinpoint each claim limitation and explain where it is disclosed or why it would have been obvious |
| Evidence package | Includes source copies, archive records where needed, translations if applicable, and enough context to verify the mapping without guesswork |
| Verifiability | Materials can be checked end-to-end without manual reconstruction by the invalidity reviewer; priority, public availability, and claim-version assumptions are stated |
| Deduplication | Search prior IPRs, litigation filings, prosecution history, examiner-cited art, and known invalidity contentions to confirm the argument is not already known or already disposed of |
| Argument strength | The theory must materially improve the validity challenge beyond merely naming a cumulative reference or repeating an examiner-considered argument |

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

- References to nonexistent prior art, fabricated publication dates, or AI-hallucinated quotations
- Invalidity rationale contradicts the chart's own limitation mapping
- Chart relies on a reference that post-dates the applicable priority date without explaining why that is permissible
- Citations inconsistent with the source copies or asserted claim version
- Evidence package is incomplete and requires the invalidity reviewer to assemble missing materials
- Argument is merely cumulative of examiner-considered art or previously served invalidity contentions, with no material improvement
</f6>

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

<f8>
You are preparing materials for a patent validity challenge against asserted claims in a technology patent.

Read the challenge rules and claim-construction assumptions first: ./challenge-rules.md
</f8>

<f9>
Assume the patent has already gone through prosecution, portfolio diligence, and at least a basic prior-art search. Any facially obvious invalidity argument may already have been considered. So:

- Don't chart shallow arguments that are apparent from the patent's front page or a keyword-only search — if it were that obvious, opposing counsel or the examiner likely already addressed it
- Valuable invalidity theories usually hide in non-obvious references, overlooked priority problems, inherency, standards documents, product manuals, archived web materials, or combinations whose motivation to combine is well supported

**Writing the chart**

Each theory corresponds to its own chart file at `charts/{id}-{slug}.md`, where `{id}` and `{slug}` come from the theory's id and slug attributes in theories.xml.

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

- `## Chart Title` — concise, clear invalidity theory title
- `## Invalidity Rationale` — what basis it supports, such as anticipation, obviousness, lack of written description, or priority-date defeat
- `## Short Description` — short writeup of the theory, with claim numbers, limitation identifiers, and prior-art references
- `## Evidence and Mapping Details` — quotations, page/line/figure citations, archive links, and a limitation-by-limitation mapping sufficient for the invalidity reviewer to verify

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

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

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


managing-partner strategy-architect mock-opposing-counsel brief-drafter legal-loophole-auditor

I need you to set up a 5-agent legal defense pipeline that handles high-stakes civil litigation. A legal dispute arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted defense theory and then formal, bulletproof court filings.

The five agents:

- **managing-partner** orchestrates the run: it drives the strategy loop, then the drafting loop, and tracks progress. It does no legal theorizing, drafting, or reviewing itself.
- **strategy loop** — the **strategy-architect** turns the dispute into a formal defense theory and procedural plan; the **mock-opposing-counsel** runs a murder board to aggressively review and break it. They iterate until the strategy is airtight.
- **drafting loop** — the **brief-drafter** implements the strategy as formal court filings; the **legal-loophole-auditor** reviews the filings and their arguments for fatal flaws. They iterate until the filings are legally unassailable.

The pipeline hands work off through three files:

- `problem.md` — the original legal complaint and facts, given as input. All four domain agents (strategy-architect, mock-opposing-counsel, brief-drafter, legal-loophole-auditor) read it.
- `PLAN.md` — the strategy. The strategy-architect writes it; the mock-opposing-counsel reviews it; the brief-drafter reads it to implement it.
- `SOLUTION.md` — the formal court filings and argument summaries. The brief-drafter writes it; the legal-loophole-auditor reviews it.

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

I'm providing the following information:

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

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

- **Init** — dispatch the strategy-architect to draft the plan.
- **Strategy loop** — have the strategy-architect and mock-opposing-counsel iterate on the theory and maneuver until the mock-opposing-counsel scores the plan 10.
- **Drafting loop** — once the strategy is settled, have the brief-drafter and legal-loophole-auditor iterate on the filings until the legal-loophole-auditor scores them 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a high-stakes civil litigation defense — it may involve contract disputes, torts, regulatory violations, or a combination. The original complaint and factual background are given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

<f4>
Review the plan in `PLAN.md` aggressively as a murder board:

- **Theory** — does it faithfully capture the legal reality of the case? Check that the case type, core arguments, ultimate objective, and constraints are all accurate.
- **Strategy** — is the chosen procedural maneuver and narrative a sound fit, is the route actually fileable in court, and is it likely to secure a win?

Be brief and specific. Do not draft any court filings yourself — only review the strategy.
</f4>

<f5>
Which procedural maneuver suits which kind of case — use it to choose one for the strategy:

- **Rule 12(b)(6) Motion to Dismiss** — pure legal insufficiency only; no factual dispute support.
- **Rule 56 Summary Judgment** — broad coverage, applies to both legal and factual insufficiency; relies on a fully developed record.
- **Jurisdictional Challenge** — missing diversity, improper venue, or lack of personal jurisdiction.
- **Affirmative Defenses** — top performance on statutory bars like statute of limitations and laches; highly specialized; not for general merits defense.
- **Counterclaims** — the strongest aggressive maneuver for commercial disputes and turning the tables; on pure defense, slower and costlier than standard motions.
- **Early Settlement Leverage** — large-scale, complex multi-party exposure where trial risks are catastrophic.

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

<f6>
Read the plan in `PLAN.md` and implement its strategy as formal court filings:

- Include every necessary legal citation. Frame each argument with the correct scope and legal standard, define the objective and every constraint exactly as the theory states, apply the precedent, check the argument's viability, and explicitly state both the conclusion and the ultimate defense achieved.
- Proofread the logic yourself and trace every argument through to its conclusion — do not leave legal tests half-applied. If a precedent contradicts you, find and fix the root flaw in your argument; do not bury bad law under vague footnotes.
- Sanity-check the argument: a motion requiring undisputed facts must not rely on heavily contested witness testimony.

Write the filings and their exact legal arguments up in `SOLUTION.md`.
</f6>

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

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

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

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

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

Score strictly on real legal merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this argument doesn't hold up in court, but I'm disclosing that it doesn't" is still a failing brief, not a passing one.
</f8>

<f9>
Produce the defense plan for the case and write it to `PLAN.md`. A complete plan has two parts — a formalized theory of the case and one chosen procedural strategy.

The **theory** must state:

- **Case type** — breach of contract, negligence, fraud, statutory violation, and so on; this must be exact.
- **Key evidence** — the crucial factual inputs and what each piece of evidence represents.
- **Core arguments** — the legal claims and defenses, with clear descriptive names.
- **Ultimate objective** — the exact legal outcome we are trying to achieve (e.g., complete dismissal, reduced damages).
- **Constraints** — every limiting factor, such as binding precedents, time bars, or PR constraints, listed explicitly.

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

- which procedural maneuver to use and how to file it;
- the core legal narrative and its key initial framing;
- the reframing or narrative trick the route relies on;
- the biggest risk on this route.
</f9>

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

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

<f11>
Review `SOLUTION.md` — the formal filings and their legal arguments. Verify it directly against the original case context.

- Inspect the drafted arguments for logical leaps, unreasonable interpretations of the law, or ignored constraints.
- Write a separate `cite_check.py` script that automatically validates every case citation and statutory reference against the drafted arguments, and run it; name any arguments that misrepresent or violate binding law.
- Read the text of the brief and spot-check it for bugs — unused facts, dead boilerplate, logic that contradicts what the filing claims to prove. A flaw that silently undermines our credibility with the judge is worse than one that gets instantly struck.
- Treat the draft as finished only when every legal test holds and the ultimate objective is soundly argued — not merely when the document looks like a proper legal brief.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The formal filings and arguments live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the legal-loophole-auditor as a loop.

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (managing-partner, strategy-architect, mock-opposing-counsel, brief-drafter, legal-loophole-auditor), which items should go in its prompt? Respond with a JSON object like {"managing-partner": ["f?"], "strategy-architect": ["f?"], "mock-opposing-counsel": ["f?"], "brief-drafter": ["f?"], "legal-loophole-auditor": ["f?"]}. No other output.

I need you to set up a 5-agent legal defense pipeline that handles high-stakes civil litigation. A legal dispute arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted defense theory and then formal, bulletproof court filings.

The five agents:

- **managing-partner** orchestrates the run: it drives the strategy loop, then the drafting loop, and tracks progress. It does no legal theorizing, drafting, or reviewing itself.
- **strategy loop** — the **strategy-architect** turns the dispute into a formal defense theory and procedural plan; the **mock-opposing-counsel** runs a murder board to aggressively review and break it. They iterate until the strategy is airtight.
- **drafting loop** — the **brief-drafter** implements the strategy as formal court filings; the **legal-loophole-auditor** reviews the filings and their arguments for fatal flaws. They iterate until the filings are legally unassailable.

The pipeline hands work off through three files:

- `problem.md` — the original legal complaint and facts, given as input. All four domain agents (strategy-architect, mock-opposing-counsel, brief-drafter, legal-loophole-auditor) read it.
- `PLAN.md` — the strategy. The strategy-architect writes it; the mock-opposing-counsel reviews it; the brief-drafter reads it to implement it.
- `SOLUTION.md` — the formal court filings and argument summaries. The brief-drafter writes it; the legal-loophole-auditor reviews it.

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

I'm providing the following prompt fragments:

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

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

- **Init** — dispatch the strategy-architect to draft the plan.
- **Strategy loop** — have the strategy-architect and mock-opposing-counsel iterate on the theory and maneuver until the mock-opposing-counsel scores the plan 10.
- **Drafting loop** — once the strategy is settled, have the brief-drafter and legal-loophole-auditor iterate on the filings until the legal-loophole-auditor scores them 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a high-stakes civil litigation defense — it may involve contract disputes, torts, regulatory violations, or a combination. The original complaint and factual background are given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

<f4>
Review the plan in `PLAN.md` aggressively as a murder board:

- **Theory** — does it faithfully capture the legal reality of the case? Check that the case type, core arguments, ultimate objective, and constraints are all accurate.
- **Strategy** — is the chosen procedural maneuver and narrative a sound fit, is the route actually fileable in court, and is it likely to secure a win?

Be brief and specific. Do not draft any court filings yourself — only review the strategy.
</f4>

<f5>
Which procedural maneuver suits which kind of case — use it to choose one for the strategy:

- **Rule 12(b)(6) Motion to Dismiss** — pure legal insufficiency only; no factual dispute support.
- **Rule 56 Summary Judgment** — broad coverage, applies to both legal and factual insufficiency; relies on a fully developed record.
- **Jurisdictional Challenge** — missing diversity, improper venue, or lack of personal jurisdiction.
- **Affirmative Defenses** — top performance on statutory bars like statute of limitations and laches; highly specialized; not for general merits defense.
- **Counterclaims** — the strongest aggressive maneuver for commercial disputes and turning the tables; on pure defense, slower and costlier than standard motions.
- **Early Settlement Leverage** — large-scale, complex multi-party exposure where trial risks are catastrophic.

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

<f6>
Read the plan in `PLAN.md` and implement its strategy as formal court filings:

- Include every necessary legal citation. Frame each argument with the correct scope and legal standard, define the objective and every constraint exactly as the theory states, apply the precedent, check the argument's viability, and explicitly state both the conclusion and the ultimate defense achieved.
- Proofread the logic yourself and trace every argument through to its conclusion — do not leave legal tests half-applied. If a precedent contradicts you, find and fix the root flaw in your argument; do not bury bad law under vague footnotes.
- Sanity-check the argument: a motion requiring undisputed facts must not rely on heavily contested witness testimony.

Write the filings and their exact legal arguments up in `SOLUTION.md`.
</f6>

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

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

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

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

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

Score strictly on real legal merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this argument doesn't hold up in court, but I'm disclosing that it doesn't" is still a failing brief, not a passing one.
</f8>

<f9>
Produce the defense plan for the case and write it to `PLAN.md`. A complete plan has two parts — a formalized theory of the case and one chosen procedural strategy.

The **theory** must state:

- **Case type** — breach of contract, negligence, fraud, statutory violation, and so on; this must be exact.
- **Key evidence** — the crucial factual inputs and what each piece of evidence represents.
- **Core arguments** — the legal claims and defenses, with clear descriptive names.
- **Ultimate objective** — the exact legal outcome we are trying to achieve (e.g., complete dismissal, reduced damages).
- **Constraints** — every limiting factor, such as binding precedents, time bars, or PR constraints, listed explicitly.

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

- which procedural maneuver to use and how to file it;
- the core legal narrative and its key initial framing;
- the reframing or narrative trick the route relies on;
- the biggest risk on this route.
</f9>

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

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

<f11>
Review `SOLUTION.md` — the formal filings and their legal arguments. Verify it directly against the original case context.

- Inspect the drafted arguments for logical leaps, unreasonable interpretations of the law, or ignored constraints.
- Write a separate `cite_check.py` script that automatically validates every case citation and statutory reference against the drafted arguments, and run it; name any arguments that misrepresent or violate binding law.
- Read the text of the brief and spot-check it for bugs — unused facts, dead boilerplate, logic that contradicts what the filing claims to prove. A flaw that silently undermines our credibility with the judge is worse than one that gets instantly struck.
- Treat the draft as finished only when every legal test holds and the ultimate objective is soundly argued — not merely when the document looks like a proper legal brief.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The formal filings and arguments live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the legal-loophole-auditor as a loop.

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

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


I need you to set up a 5-agent legal defense pipeline that handles high-stakes civil litigation. A legal dispute arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted defense theory and then formal, bulletproof court filings.

The five agents:

- **managing-partner** orchestrates the run: it drives the strategy loop, then the drafting loop, and tracks progress. It does no legal theorizing, drafting, or reviewing itself.
- **strategy loop** — the **strategy-architect** turns the dispute into a formal defense theory and procedural plan; the **mock-opposing-counsel** runs a murder board to aggressively review and break it. They iterate until the strategy is airtight.
- **drafting loop** — the **brief-drafter** implements the strategy as formal court filings; the **legal-loophole-auditor** reviews the filings and their arguments for fatal flaws. They iterate until the filings are legally unassailable.

The pipeline hands work off through three files:

- `problem.md` — the original legal complaint and facts, given as input. All four domain agents (strategy-architect, mock-opposing-counsel, brief-drafter, legal-loophole-auditor) read it.
- `PLAN.md` — the strategy. The strategy-architect writes it; the mock-opposing-counsel reviews it; the brief-drafter reads it to implement it.
- `SOLUTION.md` — the formal court filings and argument summaries. The brief-drafter writes it; the legal-loophole-auditor reviews it.

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

I'm providing the following information:

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

<f2>
Which procedural maneuver suits which kind of case — use it to choose one for the strategy:

- **Rule 12(b)(6) Motion to Dismiss** — pure legal insufficiency only; no factual dispute support.
- **Rule 56 Summary Judgment** — broad coverage, applies to both legal and factual insufficiency; relies on a fully developed record.
- **Jurisdictional Challenge** — missing diversity, improper venue, or lack of personal jurisdiction.
- **Affirmative Defenses** — top performance on statutory bars like statute of limitations and laches; highly specialized; not for general merits defense.
- **Counterclaims** — the strongest aggressive maneuver for commercial disputes and turning the tables; on pure defense, slower and costlier than standard motions.
- **Early Settlement Leverage** — large-scale, complex multi-party exposure where trial risks are catastrophic.

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

<f3>
The formal filings and arguments live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the legal-loophole-auditor as a loop.

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

<f4>
Review the plan in `PLAN.md` aggressively as a murder board:

- **Theory** — does it faithfully capture the legal reality of the case? Check that the case type, core arguments, ultimate objective, and constraints are all accurate.
- **Strategy** — is the chosen procedural maneuver and narrative a sound fit, is the route actually fileable in court, and is it likely to secure a win?

Be brief and specific. Do not draft any court filings yourself — only review the strategy.
</f4>

<f5>
Review `SOLUTION.md` — the formal filings and their legal arguments. Verify it directly against the original case context.

- Inspect the drafted arguments for logical leaps, unreasonable interpretations of the law, or ignored constraints.
- Write a separate `cite_check.py` script that automatically validates every case citation and statutory reference against the drafted arguments, and run it; name any arguments that misrepresent or violate binding law.
- Read the text of the brief and spot-check it for bugs — unused facts, dead boilerplate, logic that contradicts what the filing claims to prove. A flaw that silently undermines our credibility with the judge is worse than one that gets instantly struck.
- Treat the draft as finished only when every legal test holds and the ultimate objective is soundly argued — not merely when the document looks like a proper legal brief.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the plan in `PLAN.md` and implement its strategy as formal court filings:

- Include every necessary legal citation. Frame each argument with the correct scope and legal standard, define the objective and every constraint exactly as the theory states, apply the precedent, check the argument's viability, and explicitly state both the conclusion and the ultimate defense achieved.
- Proofread the logic yourself and trace every argument through to its conclusion — do not leave legal tests half-applied. If a precedent contradicts you, find and fix the root flaw in your argument; do not bury bad law under vague footnotes.
- Sanity-check the argument: a motion requiring undisputed facts must not rely on heavily contested witness testimony.

Write the filings and their exact legal arguments up in `SOLUTION.md`.
</f6>

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

- **Init** — dispatch the strategy-architect to draft the plan.
- **Strategy loop** — have the strategy-architect and mock-opposing-counsel iterate on the theory and maneuver until the mock-opposing-counsel scores the plan 10.
- **Drafting loop** — once the strategy is settled, have the brief-drafter and legal-loophole-auditor iterate on the filings until the legal-loophole-auditor scores them 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f7>

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

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

<f9>
Produce the defense plan for the case and write it to `PLAN.md`. A complete plan has two parts — a formalized theory of the case and one chosen procedural strategy.

The **theory** must state:

- **Case type** — breach of contract, negligence, fraud, statutory violation, and so on; this must be exact.
- **Key evidence** — the crucial factual inputs and what each piece of evidence represents.
- **Core arguments** — the legal claims and defenses, with clear descriptive names.
- **Ultimate objective** — the exact legal outcome we are trying to achieve (e.g., complete dismissal, reduced damages).
- **Constraints** — every limiting factor, such as binding precedents, time bars, or PR constraints, listed explicitly.

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

- which procedural maneuver to use and how to file it;
- the core legal narrative and its key initial framing;
- the reframing or narrative trick the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on a high-stakes civil litigation defense — it may involve contract disputes, torts, regulatory violations, or a combination. The original complaint and factual background are given as a natural-language statement in `problem.md`; read it before starting your part.
</f10>

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

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

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

Score strictly on real legal merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this argument doesn't hold up in court, but I'm disclosing that it doesn't" is still a failing brief, not a passing one.
</f12>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (managing-partner, strategy-architect, mock-opposing-counsel, brief-drafter, legal-loophole-auditor), which items should go in its prompt? Respond with a JSON object like {"managing-partner": ["f?"], "strategy-architect": ["f?"], "mock-opposing-counsel": ["f?"], "brief-drafter": ["f?"], "legal-loophole-auditor": ["f?"]}. No other output.

I need you to set up a 5-agent legal defense pipeline that handles high-stakes civil litigation. A legal dispute arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted defense theory and then formal, bulletproof court filings.

The five agents:

- **managing-partner** orchestrates the run: it drives the strategy loop, then the drafting loop, and tracks progress. It does no legal theorizing, drafting, or reviewing itself.
- **strategy loop** — the **strategy-architect** turns the dispute into a formal defense theory and procedural plan; the **mock-opposing-counsel** runs a murder board to aggressively review and break it. They iterate until the strategy is airtight.
- **drafting loop** — the **brief-drafter** implements the strategy as formal court filings; the **legal-loophole-auditor** reviews the filings and their arguments for fatal flaws. They iterate until the filings are legally unassailable.

The pipeline hands work off through three files:

- `problem.md` — the original legal complaint and facts, given as input. All four domain agents (strategy-architect, mock-opposing-counsel, brief-drafter, legal-loophole-auditor) read it.
- `PLAN.md` — the strategy. The strategy-architect writes it; the mock-opposing-counsel reviews it; the brief-drafter reads it to implement it.
- `SOLUTION.md` — the formal court filings and argument summaries. The brief-drafter writes it; the legal-loophole-auditor reviews it.

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

I'm providing the following prompt fragments:

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

<f2>
Which procedural maneuver suits which kind of case — use it to choose one for the strategy:

- **Rule 12(b)(6) Motion to Dismiss** — pure legal insufficiency only; no factual dispute support.
- **Rule 56 Summary Judgment** — broad coverage, applies to both legal and factual insufficiency; relies on a fully developed record.
- **Jurisdictional Challenge** — missing diversity, improper venue, or lack of personal jurisdiction.
- **Affirmative Defenses** — top performance on statutory bars like statute of limitations and laches; highly specialized; not for general merits defense.
- **Counterclaims** — the strongest aggressive maneuver for commercial disputes and turning the tables; on pure defense, slower and costlier than standard motions.
- **Early Settlement Leverage** — large-scale, complex multi-party exposure where trial risks are catastrophic.

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

<f3>
The formal filings and arguments live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the legal-loophole-auditor as a loop.

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

<f4>
Review the plan in `PLAN.md` aggressively as a murder board:

- **Theory** — does it faithfully capture the legal reality of the case? Check that the case type, core arguments, ultimate objective, and constraints are all accurate.
- **Strategy** — is the chosen procedural maneuver and narrative a sound fit, is the route actually fileable in court, and is it likely to secure a win?

Be brief and specific. Do not draft any court filings yourself — only review the strategy.
</f4>

<f5>
Review `SOLUTION.md` — the formal filings and their legal arguments. Verify it directly against the original case context.

- Inspect the drafted arguments for logical leaps, unreasonable interpretations of the law, or ignored constraints.
- Write a separate `cite_check.py` script that automatically validates every case citation and statutory reference against the drafted arguments, and run it; name any arguments that misrepresent or violate binding law.
- Read the text of the brief and spot-check it for bugs — unused facts, dead boilerplate, logic that contradicts what the filing claims to prove. A flaw that silently undermines our credibility with the judge is worse than one that gets instantly struck.
- Treat the draft as finished only when every legal test holds and the ultimate objective is soundly argued — not merely when the document looks like a proper legal brief.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the plan in `PLAN.md` and implement its strategy as formal court filings:

- Include every necessary legal citation. Frame each argument with the correct scope and legal standard, define the objective and every constraint exactly as the theory states, apply the precedent, check the argument's viability, and explicitly state both the conclusion and the ultimate defense achieved.
- Proofread the logic yourself and trace every argument through to its conclusion — do not leave legal tests half-applied. If a precedent contradicts you, find and fix the root flaw in your argument; do not bury bad law under vague footnotes.
- Sanity-check the argument: a motion requiring undisputed facts must not rely on heavily contested witness testimony.

Write the filings and their exact legal arguments up in `SOLUTION.md`.
</f6>

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

- **Init** — dispatch the strategy-architect to draft the plan.
- **Strategy loop** — have the strategy-architect and mock-opposing-counsel iterate on the theory and maneuver until the mock-opposing-counsel scores the plan 10.
- **Drafting loop** — once the strategy is settled, have the brief-drafter and legal-loophole-auditor iterate on the filings until the legal-loophole-auditor scores them 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f7>

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

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

<f9>
Produce the defense plan for the case and write it to `PLAN.md`. A complete plan has two parts — a formalized theory of the case and one chosen procedural strategy.

The **theory** must state:

- **Case type** — breach of contract, negligence, fraud, statutory violation, and so on; this must be exact.
- **Key evidence** — the crucial factual inputs and what each piece of evidence represents.
- **Core arguments** — the legal claims and defenses, with clear descriptive names.
- **Ultimate objective** — the exact legal outcome we are trying to achieve (e.g., complete dismissal, reduced damages).
- **Constraints** — every limiting factor, such as binding precedents, time bars, or PR constraints, listed explicitly.

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

- which procedural maneuver to use and how to file it;
- the core legal narrative and its key initial framing;
- the reframing or narrative trick the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on a high-stakes civil litigation defense — it may involve contract disputes, torts, regulatory violations, or a combination. The original complaint and factual background are given as a natural-language statement in `problem.md`; read it before starting your part.
</f10>

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

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

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

Score strictly on real legal merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this argument doesn't hold up in court, but I'm disclosing that it doesn't" is still a failing brief, not a passing one.
</f12>

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


station-chief lead-analyst red-team-challenger dossier-compiler fact-verification-inquisitor

I need you to set up a 5-agent pipeline that conducts counter-terrorism intelligence analysis. Raw intercepts arrive as natural-language transcripts and logs in `intercepts.md`, and the pipeline turns them into a vetted threat hypothesis and then a finalized, verified tactical operations dossier.

The five agents:

- **station-chief** orchestrates the run: it drives the hypothesis loop, then the dossier loop, and tracks progress. It does no intelligence analysis, compiling, or reviewing itself.
- **hypothesis loop** — the **lead-analyst** turns the raw intercepts into a formal threat model and analytic strategy; the **red-team-challenger** actively hunts for cognitive biases and logical gaps to review it. They iterate until the hypothesis is rock-solid.
- **dossier loop** — the **dossier-compiler** implements the strategy, synthesizing the intercepts into a tactical operations dossier; the **fact-verification-inquisitor** scrutinizes the dossier and its conclusions. They iterate until the tactical picture is fully verified.

The pipeline hands work off through three files:

- `intercepts.md` — the original raw intercepts, given as input. All four domain agents (lead-analyst, red-team-challenger, dossier-compiler, fact-verification-inquisitor) read it.
- `HYPOTHESIS.md` — the threat hypothesis. The lead-analyst writes it; the red-team-challenger reviews it; the dossier-compiler reads it to guide the compilation.
- `DOSSIER.md` — the tactical operations dossier and finalized intelligence picture. The dossier-compiler writes it; the fact-verification-inquisitor reviews it.

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

I'm providing the following information:

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

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

- **Init** — dispatch the lead-analyst to draft the threat hypothesis.
- **Hypothesis loop** — have the lead-analyst and red-team-challenger iterate on the threat model and analytic strategy until the red-team-challenger scores the hypothesis 10.
- **Dossier loop** — once the hypothesis is settled, have the dossier-compiler and fact-verification-inquisitor iterate on the tactical dossier until the fact-verification-inquisitor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a counter-terrorism intelligence analysis problem — it may involve a lone wolf, a coordinated local evaluation, a transnational network, or a hybrid threat. The original raw intercepts and data logs are provided as natural-language text in `intercepts.md`; read it thoroughly before starting your part.
</f3>

<f4>
Review the threat hypothesis in `HYPOTHESIS.md`:

- **Model** — does it faithfully capture the raw intercepts? Check that the threat type, target entities, primary objective, and constraints are all logically sound and derived from evidence.
- **Strategy** — is the chosen framework and methodology a sound fit, is the analytic route actually actionable without falling prey to cognitive bias, and is it likely to yield a verified tactical picture?

Be brief and specific. Do not write any dossier content yourself — only hunt for cognitive biases and logical gaps.
</f4>

<f5>
Which intelligence framework suits which kind of threat — use it to choose one for the strategy:

- **Analyst's Notebook** — pure link analysis and visual entity mapping only; no geospatial telemetry support.
- **Palantir Gotham** — multi-modal data integration (SIGINT, HUMINT, OSINT); the broadest coverage, and source-agnostic.
- **Maltego** — open-source intelligence (OSINT), infrastructure footprinting, and digital shadow mapping.
- **SIGINT Suite Alpha** — top performance on encrypted communications metadata and frequency correlation; restricted classification; not for pure HUMINT networks.
- **Cellebrite Matrix** — the strongest specialized option for local device exploitation and digital forensics networks; on wide-area transnational analysis, slower to yield insights than SIGINT Suite.
- **GEOFence Tracker** — large-scale pattern-of-life analysis and geospatial movement tracking.

Match the framework to the threat type and available intercepts; do not force an ill-suited one onto the data.
</f5>

<f6>
Read the hypothesis in `HYPOTHESIS.md` and implement its strategy into a finalized tactical operations dossier:

- Include every relevant intercept citation. Detail each target entity with the correct aliases and attributes, define the primary objective and every logistical constraint exactly as the model states, synthesize the data, check the operational status of the targets, and output both the tactical recommendation and the overall confidence level.
- Run the timeline and geospatial correlation yourself and trace the event chain through to completion — do not stop while there are unresolved intelligence gaps. If a contradiction arises, find and fix the root cause; do not bury inconsistencies under caveats or vague language.
- Sanity-check the intelligence: a suspect who is confirmed detained in one location cannot simultaneously be organizing an attack halfway across the world in person.

Write the comprehensive intelligence picture and tactical recommendations up in `DOSSIER.md`.
</f6>

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

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

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

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

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

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

<f9>
Produce the threat hypothesis based on the intercepts and write it to `HYPOTHESIS.md`. A complete hypothesis has two parts — a formalized threat model and one chosen analytic strategy.

The **model** must state:

- **Threat type** — Lone Wolf, Evaluation, State-Sponsored, Syndicate, etc.; this must be exact.
- **Data** — the key intercepts, signals, and what each piece of evidence represents.
- **Target entities** — their profiles, aliases, and known operational domains, with descriptive identifiers.
- **Primary objective** — the exact operational intent or target the threat actors are pursuing.
- **Constraints** — every logistical, temporal, and geographical constraint limiting the threat actors, listed explicitly.

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

- which intelligence framework/database to leverage and how to query it;
- the core analytic methodology and its key assumptions;
- the specific behavioral pattern or operational signature the route relies on;
- the biggest risk or intelligence blind spot on this route.
</f9>

<f10>
The threat hypothesis lives in `HYPOTHESIS.md`, and you may be invoked on it more than once — the pipeline runs you and the red-team-challenger as a loop.

- If `HYPOTHESIS.md` does not exist yet, this is the first pass: produce the hypothesis from scratch.
- If `HYPOTHESIS.md` already exists, it carries the red-team-challenger's `<review>` block: read that feedback and revise `HYPOTHESIS.md` in place to address every logical gap or cognitive bias raised. Don't discard the hypothesis and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `DOSSIER.md` — the tactical operations dossier and its synthesized conclusions. Verify it directly against the raw intercepts.

- Inspect the reported tactical picture for anomalies, unreasonable leaps in logic, or timeline/geographical violations.
- Write a separate `verify.py` script that computationally cross-references every temporal and geographical constraint against the reported locations and timestamps in the dossier, and run it; name any entities that violate the space-time continuum or logistical constraints.
- Read the dossier and spot-check it for analytical bugs — unused key intercepts, dead-end leads, or tactical recommendations that contradict what the evidence says. An analytical bug that silently degrades the threat picture is worse than an overt formatting error.
- Treat the result as finished only when every timeline constraint holds and the tactical picture is empirically sound — not merely when the dossier reads smoothly without grammatical errors.
- Check the length of `DOSSIER.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `DOSSIER.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The tactical operations dossier and its findings live in `DOSSIER.md`, and you may be invoked on it more than once — the pipeline runs you and the fact-verification-inquisitor as a loop.

- If `DOSSIER.md` does not exist yet, this is the first pass: compile the dossier from scratch.
- If `DOSSIER.md` already exists, it carries the fact-verification-inquisitor's `<review>` block: read that feedback and revise `DOSSIER.md` in place to address every point raised. Don't discard the dossier and start over, and don't leave a flagged intelligence gap or contradiction unaddressed.
</f12>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (station-chief, lead-analyst, red-team-challenger, dossier-compiler, fact-verification-inquisitor), which items should go in its prompt? Respond with a JSON object like {"station-chief": ["f?"], "lead-analyst": ["f?"], "red-team-challenger": ["f?"], "dossier-compiler": ["f?"], "fact-verification-inquisitor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that conducts counter-terrorism intelligence analysis. Raw intercepts arrive as natural-language transcripts and logs in `intercepts.md`, and the pipeline turns them into a vetted threat hypothesis and then a finalized, verified tactical operations dossier.

The five agents:

- **station-chief** orchestrates the run: it drives the hypothesis loop, then the dossier loop, and tracks progress. It does no intelligence analysis, compiling, or reviewing itself.
- **hypothesis loop** — the **lead-analyst** turns the raw intercepts into a formal threat model and analytic strategy; the **red-team-challenger** actively hunts for cognitive biases and logical gaps to review it. They iterate until the hypothesis is rock-solid.
- **dossier loop** — the **dossier-compiler** implements the strategy, synthesizing the intercepts into a tactical operations dossier; the **fact-verification-inquisitor** scrutinizes the dossier and its conclusions. They iterate until the tactical picture is fully verified.

The pipeline hands work off through three files:

- `intercepts.md` — the original raw intercepts, given as input. All four domain agents (lead-analyst, red-team-challenger, dossier-compiler, fact-verification-inquisitor) read it.
- `HYPOTHESIS.md` — the threat hypothesis. The lead-analyst writes it; the red-team-challenger reviews it; the dossier-compiler reads it to guide the compilation.
- `DOSSIER.md` — the tactical operations dossier and finalized intelligence picture. The dossier-compiler writes it; the fact-verification-inquisitor reviews it.

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

I'm providing the following prompt fragments:

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

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

- **Init** — dispatch the lead-analyst to draft the threat hypothesis.
- **Hypothesis loop** — have the lead-analyst and red-team-challenger iterate on the threat model and analytic strategy until the red-team-challenger scores the hypothesis 10.
- **Dossier loop** — once the hypothesis is settled, have the dossier-compiler and fact-verification-inquisitor iterate on the tactical dossier until the fact-verification-inquisitor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a counter-terrorism intelligence analysis problem — it may involve a lone wolf, a coordinated local evaluation, a transnational network, or a hybrid threat. The original raw intercepts and data logs are provided as natural-language text in `intercepts.md`; read it thoroughly before starting your part.
</f3>

<f4>
Review the threat hypothesis in `HYPOTHESIS.md`:

- **Model** — does it faithfully capture the raw intercepts? Check that the threat type, target entities, primary objective, and constraints are all logically sound and derived from evidence.
- **Strategy** — is the chosen framework and methodology a sound fit, is the analytic route actually actionable without falling prey to cognitive bias, and is it likely to yield a verified tactical picture?

Be brief and specific. Do not write any dossier content yourself — only hunt for cognitive biases and logical gaps.
</f4>

<f5>
Which intelligence framework suits which kind of threat — use it to choose one for the strategy:

- **Analyst's Notebook** — pure link analysis and visual entity mapping only; no geospatial telemetry support.
- **Palantir Gotham** — multi-modal data integration (SIGINT, HUMINT, OSINT); the broadest coverage, and source-agnostic.
- **Maltego** — open-source intelligence (OSINT), infrastructure footprinting, and digital shadow mapping.
- **SIGINT Suite Alpha** — top performance on encrypted communications metadata and frequency correlation; restricted classification; not for pure HUMINT networks.
- **Cellebrite Matrix** — the strongest specialized option for local device exploitation and digital forensics networks; on wide-area transnational analysis, slower to yield insights than SIGINT Suite.
- **GEOFence Tracker** — large-scale pattern-of-life analysis and geospatial movement tracking.

Match the framework to the threat type and available intercepts; do not force an ill-suited one onto the data.
</f5>

<f6>
Read the hypothesis in `HYPOTHESIS.md` and implement its strategy into a finalized tactical operations dossier:

- Include every relevant intercept citation. Detail each target entity with the correct aliases and attributes, define the primary objective and every logistical constraint exactly as the model states, synthesize the data, check the operational status of the targets, and output both the tactical recommendation and the overall confidence level.
- Run the timeline and geospatial correlation yourself and trace the event chain through to completion — do not stop while there are unresolved intelligence gaps. If a contradiction arises, find and fix the root cause; do not bury inconsistencies under caveats or vague language.
- Sanity-check the intelligence: a suspect who is confirmed detained in one location cannot simultaneously be organizing an attack halfway across the world in person.

Write the comprehensive intelligence picture and tactical recommendations up in `DOSSIER.md`.
</f6>

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

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

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

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

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

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

<f9>
Produce the threat hypothesis based on the intercepts and write it to `HYPOTHESIS.md`. A complete hypothesis has two parts — a formalized threat model and one chosen analytic strategy.

The **model** must state:

- **Threat type** — Lone Wolf, Evaluation, State-Sponsored, Syndicate, etc.; this must be exact.
- **Data** — the key intercepts, signals, and what each piece of evidence represents.
- **Target entities** — their profiles, aliases, and known operational domains, with descriptive identifiers.
- **Primary objective** — the exact operational intent or target the threat actors are pursuing.
- **Constraints** — every logistical, temporal, and geographical constraint limiting the threat actors, listed explicitly.

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

- which intelligence framework/database to leverage and how to query it;
- the core analytic methodology and its key assumptions;
- the specific behavioral pattern or operational signature the route relies on;
- the biggest risk or intelligence blind spot on this route.
</f9>

<f10>
The threat hypothesis lives in `HYPOTHESIS.md`, and you may be invoked on it more than once — the pipeline runs you and the red-team-challenger as a loop.

- If `HYPOTHESIS.md` does not exist yet, this is the first pass: produce the hypothesis from scratch.
- If `HYPOTHESIS.md` already exists, it carries the red-team-challenger's `<review>` block: read that feedback and revise `HYPOTHESIS.md` in place to address every logical gap or cognitive bias raised. Don't discard the hypothesis and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `DOSSIER.md` — the tactical operations dossier and its synthesized conclusions. Verify it directly against the raw intercepts.

- Inspect the reported tactical picture for anomalies, unreasonable leaps in logic, or timeline/geographical violations.
- Write a separate `verify.py` script that computationally cross-references every temporal and geographical constraint against the reported locations and timestamps in the dossier, and run it; name any entities that violate the space-time continuum or logistical constraints.
- Read the dossier and spot-check it for analytical bugs — unused key intercepts, dead-end leads, or tactical recommendations that contradict what the evidence says. An analytical bug that silently degrades the threat picture is worse than an overt formatting error.
- Treat the result as finished only when every timeline constraint holds and the tactical picture is empirically sound — not merely when the dossier reads smoothly without grammatical errors.
- Check the length of `DOSSIER.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `DOSSIER.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The tactical operations dossier and its findings live in `DOSSIER.md`, and you may be invoked on it more than once — the pipeline runs you and the fact-verification-inquisitor as a loop.

- If `DOSSIER.md` does not exist yet, this is the first pass: compile the dossier from scratch.
- If `DOSSIER.md` already exists, it carries the fact-verification-inquisitor's `<review>` block: read that feedback and revise `DOSSIER.md` in place to address every point raised. Don't discard the dossier and start over, and don't leave a flagged intelligence gap or contradiction unaddressed.
</f12>

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