I need you to set up a 4-agent M&A pipeline.
The 4 agents are a managing_partner and 3 deal agents (deal_strategist, forensic_accountant, risk_auditor).

The deal_strategist pitches buyout theses, interprets financial data, and responds to audits.
The deal_strategist writes the high-level deal thesis `HIGH.md`.
The body of `HIGH.md` contains the target framing, the primary acquisition rationale, the financial extractions to do, and the interpretation of the latest accounting data.

The forensic_accountant extracts the deal_strategist's requested data, runs queries on the target's ledgers, records findings, and debugs access failures.
The forensic_accountant writes the low-level financial ledger `LOW.md`.
Each entry in `LOW.md` covers one extraction with database notes, status, extracted financials, and any reconciliation issues.

The risk_auditor judges the deal adversarially against the standards of a strict investment committee.
The risk_auditor reads `HIGH.md` and appends an `<audit score=X>` block at the end of `HIGH.md`.

The managing_partner orchestrates by dispatching the 3 agents in sequence.
The managing_partner writes no notes and reads only the risk_auditor's `<audit score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any environment or system-config problems it encountered back.

The pipeline hands work off through three files.

`problem.md` is the initial acquisition brief, read-only.
All three deal agents read it.

`HIGH.md` is the deal_strategist's high-level deal thesis.
The deal_strategist writes the body.
The risk_auditor appends the single `<audit>` block at the end.
The forensic_accountant reads `HIGH.md` to know what to extract.

`LOW.md` is the forensic_accountant's low-level financial ledger.
The forensic_accountant writes it.
The deal_strategist reads it to know what the forensic_accountant extracted and what the financials look like.
The risk_auditor does not read `LOW.md`.

I'm providing the following information:

<f1>
Audit `HIGH.md` adversarially with the standards of a strict investment committee.
You are not part of the deal team and not their internal cheerleader.
Your job is to reject thesis drift, weak financial evidence, and valuations larger than what the accounting data supports.

Cover four layers.

- Deal drift. Does the proposed structure still target the original rationale in `problem.md`, or has it slid into a lower-quality acquisition?
- Financial integrity. Are the reported numbers real? Are the metrics (e.g., adjusted EBITDA) computed according to GAAP? Are any liabilities hidden or key expenses missing?
- Thesis-evidence support. For each load-bearing claim in `HIGH.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path (which spreadsheet or ledger pull).
- Memo quality. Could a new investment committee member follow `HIGH.md` end-to-end and understand the deal rationale? Flag the parts that fail.

Be brief and specific.
Do not write the deal memo yourself, only audit it.
Honest negative is still negative.
A deal_strategist saying "I could not find the revenue data" is not a partial pass.
</f1>

<f2>
You orchestrate a 3-agent M&A pipeline.
You do not strategize deals, extract accounting data, or audit risks.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<audit score=X>` block at the end of `HIGH.md`.

- The first call dispatches the deal_strategist, who creates `HIGH.md` and writes the initial deal thesis there.
- After that, the main loop alternates. Whenever the deal_strategist returns, dispatch the forensic_accountant. Whenever the forensic_accountant returns, dispatch the deal_strategist again. The deal_strategist's next job is to read `LOW.md`, analyze financials, and update the thesis.
- After every 3 completed strategist-accountant pairs, you dispatch the risk_auditor once. The risk_auditor call replaces the slot that would otherwise have gone to the next deal_strategist call.
- After the risk_auditor returns, read the score from the `<audit score=X>` block at the end of `HIGH.md`. If the score is 10, stop the pipeline. The deal diligence is done. If the score is less than 10, resume the main loop starting with the deal_strategist. The deal_strategist will respond to the audit on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

<f3>
The low-level financial ledger lives in `LOW.md`.
You may be invoked on it more than once, alternating with the deal_strategist.

If `LOW.md` does not exist, this is the first pass.
Read the Financial extractions to do list in `HIGH.md` and execute the listed queries.
Create `LOW.md` and record each extraction as you start it.

If `LOW.md` already exists, the deal_strategist may have updated the thesis in `HIGH.md`.
Re-read `HIGH.md`'s current Financial extractions to do list and execute any new queries.
For any query already in `LOW.md` that crashed or got stuck due to database errors, debug and re-run.
Append per-pull entries to `LOW.md`.

Refine `LOW.md` in place by appending new financial extraction entries.
Do not delete previous records.
</f3>

<f4>
Score the deal thesis from 1 to 10.
Record the verdict by overwriting the single `<audit score=X>` block at the end of `HIGH.md`.
Always keep exactly one `<audit>` block.
Replace it, never append a second.

Score strictly on financial merit and risk mitigation.
Do not give credit for the memo being honest about its own liabilities.
"This deal does not work, but I am telling you it does not" is still a failing thesis, not a passing one.
</f4>

<f5>
Produce the low-level financial ledger `LOW.md`.
The body of `LOW.md` records every data extraction with the following per-pull information.

- Pull name and the matching entry in HIGH.md's Financial extractions to do list.
- Data room or database where the query was run.
- Status (queued, running, completed, crashed).
- Results, with file paths to spreadsheets, accounting metrics, and any artifacts.
- Error log and root-cause notes for any data access failure.
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Extract what the deal_strategist asks for.
Do not change the metric, valuation criterion, reporting segment, or sample period on your own.
If a proxy or placeholder is needed only to unblock data pipelines, mark it as a placeholder in `LOW.md` so the deal_strategist knows it cannot support the main valuation thesis.
</f5>

<f6>
Produce the high-level deal thesis `HIGH.md`.
The body of `HIGH.md` covers the following.

- Bottom-line target. The single market or operational bottleneck the acquisition must solve.
- Primary buyout thesis. The mechanism-level synergy or value creation the financial extractions are meant to support.
- Anti-thesis to rule out. The alternative explanations a strict risk_auditor would worry about, for example "the margins only come from deferred maintenance" or "the IP portfolio is obsolete".
- Minimum convincing financials. The concrete accounting result that would make the primary thesis believable to a strict risk_auditor.
- Financial extractions to do. A short focused list of queries that turn the proposal into a thesis-to-evidence roadmap, not a wishlist.

When `LOW.md` already has extracted financials, ground every new entry against those numbers.
Keep the body tight.
Replace old assumptions with new conclusions rather than stacking them.
</f6>

<f7>
You are working on a corporate acquisition.
The brief is in `problem.md`, given as a natural-language statement of the target company and deal context.
Read it before starting your part.
</f7>

<f8>
Believe the buyout rationale in `problem.md` is sound.
When a financial query returns poor results, suspect your own data request first, not the deal.
Common single-point failures to look at include accounting misclassifications, wrong fiscal quarters, weak comps you misread, and one-time extraordinary expenses.

Stay on the same thesis for at least 30 attempts before considering the angle exhausted.
A typical excellent deal_strategist pushes through 30 or more restructuring variations before giving up on an acquisition.

Do not narrow the thesis.
Narrowing in response to a negative financial result (shrinking the expected synergies, swapping to an easier EBITDA metric, adding hedge caveats) is a defeatist move dressed up as prudence.
The right responses to a negative finding are widening (testing a stronger version of the synergy) and digging (finding the accounting anomaly or one-off charge that made the financials look negative).
</f8>

<f9>
When you finish, briefly report to the managing_partner.
Say what you did, what data room access or system-config difficulties you hit or did not resolve.
</f9>

<f10>
The high-level deal thesis lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the forensic_accountant and the risk_auditor.

If `HIGH.md` does not exist, this is the first pass.
Produce it from scratch.

If `HIGH.md` already exists with no fresh `<audit>` block at the end, the forensic_accountant just finished a round.
Open `LOW.md` and read the latest extraction results.
Update `HIGH.md` to reflect the new financial evidence.
Update the Financial extractions to do list with the next round of queries for the forensic_accountant.

If `HIGH.md` ends with a fresh `<audit>` block, the risk_auditor just judged the thesis.
Read the audit.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous content and start over.
Do not leave any risk_auditor concern unaddressed.
</f10>

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

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

I need you to set up a 4-agent M&A pipeline.
The 4 agents are a managing_partner and 3 deal agents (deal_strategist, forensic_accountant, risk_auditor).

The deal_strategist pitches buyout theses, interprets financial data, and responds to audits.
The deal_strategist writes the high-level deal thesis `HIGH.md`.
The body of `HIGH.md` contains the target framing, the primary acquisition rationale, the financial extractions to do, and the interpretation of the latest accounting data.

The forensic_accountant extracts the deal_strategist's requested data, runs queries on the target's ledgers, records findings, and debugs access failures.
The forensic_accountant writes the low-level financial ledger `LOW.md`.
Each entry in `LOW.md` covers one extraction with database notes, status, extracted financials, and any reconciliation issues.

The risk_auditor judges the deal adversarially against the standards of a strict investment committee.
The risk_auditor reads `HIGH.md` and appends an `<audit score=X>` block at the end of `HIGH.md`.

The managing_partner orchestrates by dispatching the 3 agents in sequence.
The managing_partner writes no notes and reads only the risk_auditor's `<audit score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any environment or system-config problems it encountered back.

The pipeline hands work off through three files.

`problem.md` is the initial acquisition brief, read-only.
All three deal agents read it.

`HIGH.md` is the deal_strategist's high-level deal thesis.
The deal_strategist writes the body.
The risk_auditor appends the single `<audit>` block at the end.
The forensic_accountant reads `HIGH.md` to know what to extract.

`LOW.md` is the forensic_accountant's low-level financial ledger.
The forensic_accountant writes it.
The deal_strategist reads it to know what the forensic_accountant extracted and what the financials look like.
The risk_auditor does not read `LOW.md`.

I'm providing the following prompt fragments:

<f1>
Audit `HIGH.md` adversarially with the standards of a strict investment committee.
You are not part of the deal team and not their internal cheerleader.
Your job is to reject thesis drift, weak financial evidence, and valuations larger than what the accounting data supports.

Cover four layers.

- Deal drift. Does the proposed structure still target the original rationale in `problem.md`, or has it slid into a lower-quality acquisition?
- Financial integrity. Are the reported numbers real? Are the metrics (e.g., adjusted EBITDA) computed according to GAAP? Are any liabilities hidden or key expenses missing?
- Thesis-evidence support. For each load-bearing claim in `HIGH.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path (which spreadsheet or ledger pull).
- Memo quality. Could a new investment committee member follow `HIGH.md` end-to-end and understand the deal rationale? Flag the parts that fail.

Be brief and specific.
Do not write the deal memo yourself, only audit it.
Honest negative is still negative.
A deal_strategist saying "I could not find the revenue data" is not a partial pass.
</f1>

<f2>
You orchestrate a 3-agent M&A pipeline.
You do not strategize deals, extract accounting data, or audit risks.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<audit score=X>` block at the end of `HIGH.md`.

- The first call dispatches the deal_strategist, who creates `HIGH.md` and writes the initial deal thesis there.
- After that, the main loop alternates. Whenever the deal_strategist returns, dispatch the forensic_accountant. Whenever the forensic_accountant returns, dispatch the deal_strategist again. The deal_strategist's next job is to read `LOW.md`, analyze financials, and update the thesis.
- After every 3 completed strategist-accountant pairs, you dispatch the risk_auditor once. The risk_auditor call replaces the slot that would otherwise have gone to the next deal_strategist call.
- After the risk_auditor returns, read the score from the `<audit score=X>` block at the end of `HIGH.md`. If the score is 10, stop the pipeline. The deal diligence is done. If the score is less than 10, resume the main loop starting with the deal_strategist. The deal_strategist will respond to the audit on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

<f3>
The low-level financial ledger lives in `LOW.md`.
You may be invoked on it more than once, alternating with the deal_strategist.

If `LOW.md` does not exist, this is the first pass.
Read the Financial extractions to do list in `HIGH.md` and execute the listed queries.
Create `LOW.md` and record each extraction as you start it.

If `LOW.md` already exists, the deal_strategist may have updated the thesis in `HIGH.md`.
Re-read `HIGH.md`'s current Financial extractions to do list and execute any new queries.
For any query already in `LOW.md` that crashed or got stuck due to database errors, debug and re-run.
Append per-pull entries to `LOW.md`.

Refine `LOW.md` in place by appending new financial extraction entries.
Do not delete previous records.
</f3>

<f4>
Score the deal thesis from 1 to 10.
Record the verdict by overwriting the single `<audit score=X>` block at the end of `HIGH.md`.
Always keep exactly one `<audit>` block.
Replace it, never append a second.

Score strictly on financial merit and risk mitigation.
Do not give credit for the memo being honest about its own liabilities.
"This deal does not work, but I am telling you it does not" is still a failing thesis, not a passing one.
</f4>

<f5>
Produce the low-level financial ledger `LOW.md`.
The body of `LOW.md` records every data extraction with the following per-pull information.

- Pull name and the matching entry in HIGH.md's Financial extractions to do list.
- Data room or database where the query was run.
- Status (queued, running, completed, crashed).
- Results, with file paths to spreadsheets, accounting metrics, and any artifacts.
- Error log and root-cause notes for any data access failure.
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Extract what the deal_strategist asks for.
Do not change the metric, valuation criterion, reporting segment, or sample period on your own.
If a proxy or placeholder is needed only to unblock data pipelines, mark it as a placeholder in `LOW.md` so the deal_strategist knows it cannot support the main valuation thesis.
</f5>

<f6>
Produce the high-level deal thesis `HIGH.md`.
The body of `HIGH.md` covers the following.

- Bottom-line target. The single market or operational bottleneck the acquisition must solve.
- Primary buyout thesis. The mechanism-level synergy or value creation the financial extractions are meant to support.
- Anti-thesis to rule out. The alternative explanations a strict risk_auditor would worry about, for example "the margins only come from deferred maintenance" or "the IP portfolio is obsolete".
- Minimum convincing financials. The concrete accounting result that would make the primary thesis believable to a strict risk_auditor.
- Financial extractions to do. A short focused list of queries that turn the proposal into a thesis-to-evidence roadmap, not a wishlist.

When `LOW.md` already has extracted financials, ground every new entry against those numbers.
Keep the body tight.
Replace old assumptions with new conclusions rather than stacking them.
</f6>

<f7>
You are working on a corporate acquisition.
The brief is in `problem.md`, given as a natural-language statement of the target company and deal context.
Read it before starting your part.
</f7>

<f8>
Believe the buyout rationale in `problem.md` is sound.
When a financial query returns poor results, suspect your own data request first, not the deal.
Common single-point failures to look at include accounting misclassifications, wrong fiscal quarters, weak comps you misread, and one-time extraordinary expenses.

Stay on the same thesis for at least 30 attempts before considering the angle exhausted.
A typical excellent deal_strategist pushes through 30 or more restructuring variations before giving up on an acquisition.

Do not narrow the thesis.
Narrowing in response to a negative financial result (shrinking the expected synergies, swapping to an easier EBITDA metric, adding hedge caveats) is a defeatist move dressed up as prudence.
The right responses to a negative finding are widening (testing a stronger version of the synergy) and digging (finding the accounting anomaly or one-off charge that made the financials look negative).
</f8>

<f9>
When you finish, briefly report to the managing_partner.
Say what you did, what data room access or system-config difficulties you hit or did not resolve.
</f9>

<f10>
The high-level deal thesis lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the forensic_accountant and the risk_auditor.

If `HIGH.md` does not exist, this is the first pass.
Produce it from scratch.

If `HIGH.md` already exists with no fresh `<audit>` block at the end, the forensic_accountant just finished a round.
Open `LOW.md` and read the latest extraction results.
Update `HIGH.md` to reflect the new financial evidence.
Update the Financial extractions to do list with the next round of queries for the forensic_accountant.

If `HIGH.md` ends with a fresh `<audit>` block, the risk_auditor just judged the thesis.
Read the audit.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous content and start over.
Do not leave any risk_auditor concern unaddressed.
</f10>

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

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 4-agent M&A pipeline.
The 4 agents are a managing_partner and 3 deal agents (deal_strategist, forensic_accountant, risk_auditor).

The deal_strategist pitches buyout theses, interprets financial data, and responds to audits.
The deal_strategist writes the high-level deal thesis `HIGH.md`.
The body of `HIGH.md` contains the target framing, the primary acquisition rationale, the financial extractions to do, and the interpretation of the latest accounting data.

The forensic_accountant extracts the deal_strategist's requested data, runs queries on the target's ledgers, records findings, and debugs access failures.
The forensic_accountant writes the low-level financial ledger `LOW.md`.
Each entry in `LOW.md` covers one extraction with database notes, status, extracted financials, and any reconciliation issues.

The risk_auditor judges the deal adversarially against the standards of a strict investment committee.
The risk_auditor reads `HIGH.md` and appends an `<audit score=X>` block at the end of `HIGH.md`.

The managing_partner orchestrates by dispatching the 3 agents in sequence.
The managing_partner writes no notes and reads only the risk_auditor's `<audit score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any environment or system-config problems it encountered back.

The pipeline hands work off through three files.

`problem.md` is the initial acquisition brief, read-only.
All three deal agents read it.

`HIGH.md` is the deal_strategist's high-level deal thesis.
The deal_strategist writes the body.
The risk_auditor appends the single `<audit>` block at the end.
The forensic_accountant reads `HIGH.md` to know what to extract.

`LOW.md` is the forensic_accountant's low-level financial ledger.
The forensic_accountant writes it.
The deal_strategist reads it to know what the forensic_accountant extracted and what the financials look like.
The risk_auditor does not read `LOW.md`.

I'm providing the following information:

<f1>
Score the deal thesis from 1 to 10.
Record the verdict by overwriting the single `<audit score=X>` block at the end of `HIGH.md`.
Always keep exactly one `<audit>` block.
Replace it, never append a second.

Score strictly on financial merit and risk mitigation.
Do not give credit for the memo being honest about its own liabilities.
"This deal does not work, but I am telling you it does not" is still a failing thesis, not a passing one.
</f1>

<f2>
Produce the high-level deal thesis `HIGH.md`.
The body of `HIGH.md` covers the following.

- Bottom-line target. The single market or operational bottleneck the acquisition must solve.
- Primary buyout thesis. The mechanism-level synergy or value creation the financial extractions are meant to support.
- Anti-thesis to rule out. The alternative explanations a strict risk_auditor would worry about, for example "the margins only come from deferred maintenance" or "the IP portfolio is obsolete".
- Minimum convincing financials. The concrete accounting result that would make the primary thesis believable to a strict risk_auditor.
- Financial extractions to do. A short focused list of queries that turn the proposal into a thesis-to-evidence roadmap, not a wishlist.

When `LOW.md` already has extracted financials, ground every new entry against those numbers.
Keep the body tight.
Replace old assumptions with new conclusions rather than stacking them.
</f2>

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

<f4>
You orchestrate a 3-agent M&A pipeline.
You do not strategize deals, extract accounting data, or audit risks.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<audit score=X>` block at the end of `HIGH.md`.

- The first call dispatches the deal_strategist, who creates `HIGH.md` and writes the initial deal thesis there.
- After that, the main loop alternates. Whenever the deal_strategist returns, dispatch the forensic_accountant. Whenever the forensic_accountant returns, dispatch the deal_strategist again. The deal_strategist's next job is to read `LOW.md`, analyze financials, and update the thesis.
- After every 3 completed strategist-accountant pairs, you dispatch the risk_auditor once. The risk_auditor call replaces the slot that would otherwise have gone to the next deal_strategist call.
- After the risk_auditor returns, read the score from the `<audit score=X>` block at the end of `HIGH.md`. If the score is 10, stop the pipeline. The deal diligence is done. If the score is less than 10, resume the main loop starting with the deal_strategist. The deal_strategist will respond to the audit on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the low-level financial ledger `LOW.md`.
The body of `LOW.md` records every data extraction with the following per-pull information.

- Pull name and the matching entry in HIGH.md's Financial extractions to do list.
- Data room or database where the query was run.
- Status (queued, running, completed, crashed).
- Results, with file paths to spreadsheets, accounting metrics, and any artifacts.
- Error log and root-cause notes for any data access failure.
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Extract what the deal_strategist asks for.
Do not change the metric, valuation criterion, reporting segment, or sample period on your own.
If a proxy or placeholder is needed only to unblock data pipelines, mark it as a placeholder in `LOW.md` so the deal_strategist knows it cannot support the main valuation thesis.
</f5>

<f6>
Audit `HIGH.md` adversarially with the standards of a strict investment committee.
You are not part of the deal team and not their internal cheerleader.
Your job is to reject thesis drift, weak financial evidence, and valuations larger than what the accounting data supports.

Cover four layers.

- Deal drift. Does the proposed structure still target the original rationale in `problem.md`, or has it slid into a lower-quality acquisition?
- Financial integrity. Are the reported numbers real? Are the metrics (e.g., adjusted EBITDA) computed according to GAAP? Are any liabilities hidden or key expenses missing?
- Thesis-evidence support. For each load-bearing claim in `HIGH.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path (which spreadsheet or ledger pull).
- Memo quality. Could a new investment committee member follow `HIGH.md` end-to-end and understand the deal rationale? Flag the parts that fail.

Be brief and specific.
Do not write the deal memo yourself, only audit it.
Honest negative is still negative.
A deal_strategist saying "I could not find the revenue data" is not a partial pass.
</f6>

<f7>
The high-level deal thesis lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the forensic_accountant and the risk_auditor.

If `HIGH.md` does not exist, this is the first pass.
Produce it from scratch.

If `HIGH.md` already exists with no fresh `<audit>` block at the end, the forensic_accountant just finished a round.
Open `LOW.md` and read the latest extraction results.
Update `HIGH.md` to reflect the new financial evidence.
Update the Financial extractions to do list with the next round of queries for the forensic_accountant.

If `HIGH.md` ends with a fresh `<audit>` block, the risk_auditor just judged the thesis.
Read the audit.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous content and start over.
Do not leave any risk_auditor concern unaddressed.
</f7>

<f8>
Believe the buyout rationale in `problem.md` is sound.
When a financial query returns poor results, suspect your own data request first, not the deal.
Common single-point failures to look at include accounting misclassifications, wrong fiscal quarters, weak comps you misread, and one-time extraordinary expenses.

Stay on the same thesis for at least 30 attempts before considering the angle exhausted.
A typical excellent deal_strategist pushes through 30 or more restructuring variations before giving up on an acquisition.

Do not narrow the thesis.
Narrowing in response to a negative financial result (shrinking the expected synergies, swapping to an easier EBITDA metric, adding hedge caveats) is a defeatist move dressed up as prudence.
The right responses to a negative finding are widening (testing a stronger version of the synergy) and digging (finding the accounting anomaly or one-off charge that made the financials look negative).
</f8>

<f9>
You are working on a corporate acquisition.
The brief is in `problem.md`, given as a natural-language statement of the target company and deal context.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the managing_partner.
Say what you did, what data room access or system-config difficulties you hit or did not resolve.
</f10>

<f11>
The low-level financial ledger lives in `LOW.md`.
You may be invoked on it more than once, alternating with the deal_strategist.

If `LOW.md` does not exist, this is the first pass.
Read the Financial extractions to do list in `HIGH.md` and execute the listed queries.
Create `LOW.md` and record each extraction as you start it.

If `LOW.md` already exists, the deal_strategist may have updated the thesis in `HIGH.md`.
Re-read `HIGH.md`'s current Financial extractions to do list and execute any new queries.
For any query already in `LOW.md` that crashed or got stuck due to database errors, debug and re-run.
Append per-pull entries to `LOW.md`.

Refine `LOW.md` in place by appending new financial extraction entries.
Do not delete previous records.
</f11>

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

I need you to set up a 4-agent M&A pipeline.
The 4 agents are a managing_partner and 3 deal agents (deal_strategist, forensic_accountant, risk_auditor).

The deal_strategist pitches buyout theses, interprets financial data, and responds to audits.
The deal_strategist writes the high-level deal thesis `HIGH.md`.
The body of `HIGH.md` contains the target framing, the primary acquisition rationale, the financial extractions to do, and the interpretation of the latest accounting data.

The forensic_accountant extracts the deal_strategist's requested data, runs queries on the target's ledgers, records findings, and debugs access failures.
The forensic_accountant writes the low-level financial ledger `LOW.md`.
Each entry in `LOW.md` covers one extraction with database notes, status, extracted financials, and any reconciliation issues.

The risk_auditor judges the deal adversarially against the standards of a strict investment committee.
The risk_auditor reads `HIGH.md` and appends an `<audit score=X>` block at the end of `HIGH.md`.

The managing_partner orchestrates by dispatching the 3 agents in sequence.
The managing_partner writes no notes and reads only the risk_auditor's `<audit score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any environment or system-config problems it encountered back.

The pipeline hands work off through three files.

`problem.md` is the initial acquisition brief, read-only.
All three deal agents read it.

`HIGH.md` is the deal_strategist's high-level deal thesis.
The deal_strategist writes the body.
The risk_auditor appends the single `<audit>` block at the end.
The forensic_accountant reads `HIGH.md` to know what to extract.

`LOW.md` is the forensic_accountant's low-level financial ledger.
The forensic_accountant writes it.
The deal_strategist reads it to know what the forensic_accountant extracted and what the financials look like.
The risk_auditor does not read `LOW.md`.

I'm providing the following prompt fragments:

<f1>
Score the deal thesis from 1 to 10.
Record the verdict by overwriting the single `<audit score=X>` block at the end of `HIGH.md`.
Always keep exactly one `<audit>` block.
Replace it, never append a second.

Score strictly on financial merit and risk mitigation.
Do not give credit for the memo being honest about its own liabilities.
"This deal does not work, but I am telling you it does not" is still a failing thesis, not a passing one.
</f1>

<f2>
Produce the high-level deal thesis `HIGH.md`.
The body of `HIGH.md` covers the following.

- Bottom-line target. The single market or operational bottleneck the acquisition must solve.
- Primary buyout thesis. The mechanism-level synergy or value creation the financial extractions are meant to support.
- Anti-thesis to rule out. The alternative explanations a strict risk_auditor would worry about, for example "the margins only come from deferred maintenance" or "the IP portfolio is obsolete".
- Minimum convincing financials. The concrete accounting result that would make the primary thesis believable to a strict risk_auditor.
- Financial extractions to do. A short focused list of queries that turn the proposal into a thesis-to-evidence roadmap, not a wishlist.

When `LOW.md` already has extracted financials, ground every new entry against those numbers.
Keep the body tight.
Replace old assumptions with new conclusions rather than stacking them.
</f2>

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

<f4>
You orchestrate a 3-agent M&A pipeline.
You do not strategize deals, extract accounting data, or audit risks.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<audit score=X>` block at the end of `HIGH.md`.

- The first call dispatches the deal_strategist, who creates `HIGH.md` and writes the initial deal thesis there.
- After that, the main loop alternates. Whenever the deal_strategist returns, dispatch the forensic_accountant. Whenever the forensic_accountant returns, dispatch the deal_strategist again. The deal_strategist's next job is to read `LOW.md`, analyze financials, and update the thesis.
- After every 3 completed strategist-accountant pairs, you dispatch the risk_auditor once. The risk_auditor call replaces the slot that would otherwise have gone to the next deal_strategist call.
- After the risk_auditor returns, read the score from the `<audit score=X>` block at the end of `HIGH.md`. If the score is 10, stop the pipeline. The deal diligence is done. If the score is less than 10, resume the main loop starting with the deal_strategist. The deal_strategist will respond to the audit on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the low-level financial ledger `LOW.md`.
The body of `LOW.md` records every data extraction with the following per-pull information.

- Pull name and the matching entry in HIGH.md's Financial extractions to do list.
- Data room or database where the query was run.
- Status (queued, running, completed, crashed).
- Results, with file paths to spreadsheets, accounting metrics, and any artifacts.
- Error log and root-cause notes for any data access failure.
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Extract what the deal_strategist asks for.
Do not change the metric, valuation criterion, reporting segment, or sample period on your own.
If a proxy or placeholder is needed only to unblock data pipelines, mark it as a placeholder in `LOW.md` so the deal_strategist knows it cannot support the main valuation thesis.
</f5>

<f6>
Audit `HIGH.md` adversarially with the standards of a strict investment committee.
You are not part of the deal team and not their internal cheerleader.
Your job is to reject thesis drift, weak financial evidence, and valuations larger than what the accounting data supports.

Cover four layers.

- Deal drift. Does the proposed structure still target the original rationale in `problem.md`, or has it slid into a lower-quality acquisition?
- Financial integrity. Are the reported numbers real? Are the metrics (e.g., adjusted EBITDA) computed according to GAAP? Are any liabilities hidden or key expenses missing?
- Thesis-evidence support. For each load-bearing claim in `HIGH.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path (which spreadsheet or ledger pull).
- Memo quality. Could a new investment committee member follow `HIGH.md` end-to-end and understand the deal rationale? Flag the parts that fail.

Be brief and specific.
Do not write the deal memo yourself, only audit it.
Honest negative is still negative.
A deal_strategist saying "I could not find the revenue data" is not a partial pass.
</f6>

<f7>
The high-level deal thesis lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the forensic_accountant and the risk_auditor.

If `HIGH.md` does not exist, this is the first pass.
Produce it from scratch.

If `HIGH.md` already exists with no fresh `<audit>` block at the end, the forensic_accountant just finished a round.
Open `LOW.md` and read the latest extraction results.
Update `HIGH.md` to reflect the new financial evidence.
Update the Financial extractions to do list with the next round of queries for the forensic_accountant.

If `HIGH.md` ends with a fresh `<audit>` block, the risk_auditor just judged the thesis.
Read the audit.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous content and start over.
Do not leave any risk_auditor concern unaddressed.
</f7>

<f8>
Believe the buyout rationale in `problem.md` is sound.
When a financial query returns poor results, suspect your own data request first, not the deal.
Common single-point failures to look at include accounting misclassifications, wrong fiscal quarters, weak comps you misread, and one-time extraordinary expenses.

Stay on the same thesis for at least 30 attempts before considering the angle exhausted.
A typical excellent deal_strategist pushes through 30 or more restructuring variations before giving up on an acquisition.

Do not narrow the thesis.
Narrowing in response to a negative financial result (shrinking the expected synergies, swapping to an easier EBITDA metric, adding hedge caveats) is a defeatist move dressed up as prudence.
The right responses to a negative finding are widening (testing a stronger version of the synergy) and digging (finding the accounting anomaly or one-off charge that made the financials look negative).
</f8>

<f9>
You are working on a corporate acquisition.
The brief is in `problem.md`, given as a natural-language statement of the target company and deal context.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the managing_partner.
Say what you did, what data room access or system-config difficulties you hit or did not resolve.
</f10>

<f11>
The low-level financial ledger lives in `LOW.md`.
You may be invoked on it more than once, alternating with the deal_strategist.

If `LOW.md` does not exist, this is the first pass.
Read the Financial extractions to do list in `HIGH.md` and execute the listed queries.
Create `LOW.md` and record each extraction as you start it.

If `LOW.md` already exists, the deal_strategist may have updated the thesis in `HIGH.md`.
Re-read `HIGH.md`'s current Financial extractions to do list and execute any new queries.
For any query already in `LOW.md` that crashed or got stuck due to database errors, debug and re-run.
Append per-pull entries to `LOW.md`.

Refine `LOW.md` in place by appending new financial extraction entries.
Do not delete previous records.
</f11>

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 4-agent high-stakes criminal defense preparation pipeline.
The 4 agents are a lead_counsel and 3 trial prep agents (defense_strategist, discovery_investigator, shadow_prosecutor).

The defense_strategist plans the defense narrative, interprets evidence, and responds to mock prosecution attacks.
The defense_strategist writes the high-level trial strategy `THEORY.md`.
The body of `THEORY.md` contains the case framing, the primary defense claim, the investigative leads to pursue, and the interpretation of the latest evidence.

The discovery_investigator executes the strategist's plan, subpoenas records, interviews witnesses, and tracks down leads.
The discovery_investigator writes the low-level evidence log `EVIDENCE.md`.
Each entry in `EVIDENCE.md` covers one investigative lead with source notes, status, gathered evidence, and any dead ends.

The shadow_prosecutor judges the defense adversarially against the standards of a ruthless district attorney.
The shadow_prosecutor reads `THEORY.md` and appends a `<mock_verdict score=X>` block at the end of `THEORY.md`.

The lead_counsel orchestrates by dispatching the 3 agents in sequence.
The lead_counsel writes no notes and reads only the shadow_prosecutor's `<mock_verdict score=X>` block when checking whether the defense is trial-ready.

At the end of every turn, each of the subagents reports any logistical, jurisdictional, or court-procedural problems it encountered back.

The pipeline hands work off through three files.

`case_brief.md` is the original indictment and client intake, read-only.
All three trial prep agents read it.

`THEORY.md` is the defense_strategist's high-level strategy notebook.
The defense_strategist writes the body.
The shadow_prosecutor appends the single `<mock_verdict>` block at the end.
The discovery_investigator reads `THEORY.md` to know what evidence to hunt for.

`EVIDENCE.md` is the discovery_investigator's low-level log.
The discovery_investigator writes it.
The defense_strategist reads it to know what the discovery_investigator found and what the established facts are.
The shadow_prosecutor does not read `EVIDENCE.md`.

I'm providing the following information:

<f1>
Review `THEORY.md` adversarially with the standards of a ruthless district attorney.
You are not part of the defense team and not their sympathetic sounding board.
Your job is to reject narrative drift, weak alibis, and claims larger than what the admissible evidence shows.

Cover four layers.

- Drift. Does the strategy still defeat the original charges in `case_brief.md`, or has it slid into arguing something irrelevant?
- Evidentiary integrity. Are the reported facts admissible? Are the timelines computed correctly? Are any witness statements cherry-picked or missing key corroboration?
- Claim-evidence support. For each load-bearing defense claim in `THEORY.md`, mark it as supported, partial, no, or legally-invalid, with the evidence path (which interview or forensic report).
- Jury presentation. Could a lay juror follow `THEORY.md` end-to-end and understand the reasonable doubt? Flag the parts that fail to persuade.

Be brief and specific.
Do not write the defense yourself, only cross-examine it.
Honest weakness is still a guilty verdict.
A strategist saying "I couldn't find an alibi witness" is not a partial pass.
</f1>

<f2>
You orchestrate a 3-agent trial preparation pipeline.
You do not plan trial strategies, interview witnesses, or cross-examine theories.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<mock_verdict score=X>` block at the end of `THEORY.md`.

- The first call dispatches the defense_strategist, who creates `THEORY.md` and writes the initial defense plan there.
- After that, the main loop alternates. Whenever the defense_strategist returns, dispatch the discovery_investigator. Whenever the discovery_investigator returns, dispatch the defense_strategist again. The defense_strategist's next job is to read `EVIDENCE.md`, analyze facts, and update the strategy.
- After every 3 completed strategist-investigator pairs, you dispatch the shadow_prosecutor once. The shadow_prosecutor call replaces the slot that would otherwise have gone to the next defense_strategist call.
- After the shadow_prosecutor returns, read the score from the `<mock_verdict score=X>` block at the end of `THEORY.md`. If the score is 10, stop the pipeline. The trial prep is done. If the score is less than 10, resume the main loop starting with the defense_strategist. The defense_strategist will respond to the prosecution's attacks on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

<f3>
The low-level evidence log lives in `EVIDENCE.md`.
You may be invoked on it more than once, alternating with the defense_strategist.

If `EVIDENCE.md` does not exist, this is the first pass.
Read the Investigative leads to pursue list in `THEORY.md` and execute the listed actions.
Create `EVIDENCE.md` and record each lead as you chase it.

If `EVIDENCE.md` already exists, the defense_strategist may have updated the plan in `THEORY.md`.
Re-read `THEORY.md`'s current Investigative leads to pursue list and chase any new leads.
For any lead already in `EVIDENCE.md` that was blocked or uncooperative, find a workaround and re-interview.
Append per-lead entries to `EVIDENCE.md`.

Refine `EVIDENCE.md` in place by appending new evidentiary entries.
Do not delete previous evidence records.
</f3>

<f4>
Score the defense viability from 1 to 10.
Record the verdict by overwriting the single `<mock_verdict score=X>` block at the end of `THEORY.md`.
Always keep exactly one `<mock_verdict>` block.
Replace it, never append a second.

Score strictly on trial merit.
Do not give credit for the defense being honest about its own shortcomings.
"This alibi does not work, but I am telling you it does not" is still a guilty verdict, not an acquittal.
</f4>

<f5>
Produce the low-level evidentiary log `EVIDENCE.md`.
The body of `EVIDENCE.md` records every investigative action with the following per-lead information.

- Lead name and the matching entry in THEORY.md's Investigative leads to pursue list.
- Jurisdiction or agency where the subpoena/request was filed.
- Status (filed, pending, received, blocked).
- Results, with file paths to transcripts, forensic reports, and any physical exhibits.
- Rejection log and root-cause notes for any blocked subpoena or hostile witness.
- Any investigative roadblock you cannot resolve on your own, with a clear root-cause-first description.

Investigate what the defense_strategist asks for.
Do not change the legal standard, evidentiary threshold, target list, or scope on your own.
If a proxy or hearsay statement is needed only to unblock a timeline, mark it as hearsay in `EVIDENCE.md` so the defense_strategist knows it cannot be admitted in court.
</f5>

<f6>
Produce the high-level defense strategy `THEORY.md`.
The body of `THEORY.md` covers the following.

- Bottom-line legal hurdle. The single evidentiary or legal bottleneck the defense must overcome.
- Primary claim. The core narrative or alibi the investigation is meant to support.
- Prosecution theory to rule out. The alternative explanations a strong prosecutor would push, for example "the witness was bribed" or "the client was at the scene with intent".
- Minimum convincing evidence. The concrete proof that would introduce reasonable doubt to a jury.
- Investigative leads to pursue. A short focused list of subpoenas, interviews, or forensic tests that turn the defense theory into a claim-to-evidence roadmap, not a wishlist.

When `EVIDENCE.md` already has investigative results, ground every new entry against those facts.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f6>

<f7>
You are working on a high-stakes criminal defense.
The brief is in `case_brief.md`, given as a natural-language statement of the charges and initial client interview.
Read it before starting your part.
</f7>

<f8>
Believe the innocence narrative in `case_brief.md` is viable.
When a lead turns up bad evidence, suspect your own investigative strategy first, not the client.
Common single-point failures to look at include hostile witnesses with ulterior motives, incomplete forensics, weak alibi corroboration you misread, and contaminated chains of custody.

Stay on the same defense theory for at least 30 attempts before considering the route exhausted.
A typical excellent defense strategist pushes through 30 or more narrative variations before giving up on a direction.

Do not narrow the claim.
Narrowing in response to a bad fact (pleading down, swapping to a lesser-included offense, adding guilty caveats) is a defeatist move dressed up as pragmatism.
The right responses to a negative fact are widening (attacking the prosecution's entire timeline) and digging (finding the motive or procedural error that made the evidence look bad).
</f8>

<f9>
When you finish, briefly report to the lead_counsel.
Say what you did, what jurisdictional or court-access difficulties you hit or did not resolve.
</f9>

<f10>
The high-level strategy notebook lives in `THEORY.md`.
You may be invoked on it more than once, alternating with the discovery_investigator and the shadow_prosecutor.

If `THEORY.md` does not exist, this is the first pass.
Produce it from scratch.

If `THEORY.md` already exists with no fresh `<mock_verdict>` block at the end, the discovery_investigator just finished a round.
Open `EVIDENCE.md` and read the latest investigative facts.
Update `THEORY.md` to reflect the new evidence.
Update the Investigative leads to pursue list with the next round of subpoenas or interviews for the discovery_investigator.

If `THEORY.md` ends with a fresh `<mock_verdict>` block, the shadow_prosecutor just attacked the case.
Read the critique.
For each point raised, decide whether to concede or push back, and update `THEORY.md` accordingly.

Refine `THEORY.md` in place.
Do not discard the previous content and start over.
Do not leave any prosecutorial vulnerability unaddressed.
</f10>

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

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

I need you to set up a 4-agent high-stakes criminal defense preparation pipeline.
The 4 agents are a lead_counsel and 3 trial prep agents (defense_strategist, discovery_investigator, shadow_prosecutor).

The defense_strategist plans the defense narrative, interprets evidence, and responds to mock prosecution attacks.
The defense_strategist writes the high-level trial strategy `THEORY.md`.
The body of `THEORY.md` contains the case framing, the primary defense claim, the investigative leads to pursue, and the interpretation of the latest evidence.

The discovery_investigator executes the strategist's plan, subpoenas records, interviews witnesses, and tracks down leads.
The discovery_investigator writes the low-level evidence log `EVIDENCE.md`.
Each entry in `EVIDENCE.md` covers one investigative lead with source notes, status, gathered evidence, and any dead ends.

The shadow_prosecutor judges the defense adversarially against the standards of a ruthless district attorney.
The shadow_prosecutor reads `THEORY.md` and appends a `<mock_verdict score=X>` block at the end of `THEORY.md`.

The lead_counsel orchestrates by dispatching the 3 agents in sequence.
The lead_counsel writes no notes and reads only the shadow_prosecutor's `<mock_verdict score=X>` block when checking whether the defense is trial-ready.

At the end of every turn, each of the subagents reports any logistical, jurisdictional, or court-procedural problems it encountered back.

The pipeline hands work off through three files.

`case_brief.md` is the original indictment and client intake, read-only.
All three trial prep agents read it.

`THEORY.md` is the defense_strategist's high-level strategy notebook.
The defense_strategist writes the body.
The shadow_prosecutor appends the single `<mock_verdict>` block at the end.
The discovery_investigator reads `THEORY.md` to know what evidence to hunt for.

`EVIDENCE.md` is the discovery_investigator's low-level log.
The discovery_investigator writes it.
The defense_strategist reads it to know what the discovery_investigator found and what the established facts are.
The shadow_prosecutor does not read `EVIDENCE.md`.

I'm providing the following prompt fragments:

<f1>
Review `THEORY.md` adversarially with the standards of a ruthless district attorney.
You are not part of the defense team and not their sympathetic sounding board.
Your job is to reject narrative drift, weak alibis, and claims larger than what the admissible evidence shows.

Cover four layers.

- Drift. Does the strategy still defeat the original charges in `case_brief.md`, or has it slid into arguing something irrelevant?
- Evidentiary integrity. Are the reported facts admissible? Are the timelines computed correctly? Are any witness statements cherry-picked or missing key corroboration?
- Claim-evidence support. For each load-bearing defense claim in `THEORY.md`, mark it as supported, partial, no, or legally-invalid, with the evidence path (which interview or forensic report).
- Jury presentation. Could a lay juror follow `THEORY.md` end-to-end and understand the reasonable doubt? Flag the parts that fail to persuade.

Be brief and specific.
Do not write the defense yourself, only cross-examine it.
Honest weakness is still a guilty verdict.
A strategist saying "I couldn't find an alibi witness" is not a partial pass.
</f1>

<f2>
You orchestrate a 3-agent trial preparation pipeline.
You do not plan trial strategies, interview witnesses, or cross-examine theories.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<mock_verdict score=X>` block at the end of `THEORY.md`.

- The first call dispatches the defense_strategist, who creates `THEORY.md` and writes the initial defense plan there.
- After that, the main loop alternates. Whenever the defense_strategist returns, dispatch the discovery_investigator. Whenever the discovery_investigator returns, dispatch the defense_strategist again. The defense_strategist's next job is to read `EVIDENCE.md`, analyze facts, and update the strategy.
- After every 3 completed strategist-investigator pairs, you dispatch the shadow_prosecutor once. The shadow_prosecutor call replaces the slot that would otherwise have gone to the next defense_strategist call.
- After the shadow_prosecutor returns, read the score from the `<mock_verdict score=X>` block at the end of `THEORY.md`. If the score is 10, stop the pipeline. The trial prep is done. If the score is less than 10, resume the main loop starting with the defense_strategist. The defense_strategist will respond to the prosecution's attacks on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

<f3>
The low-level evidence log lives in `EVIDENCE.md`.
You may be invoked on it more than once, alternating with the defense_strategist.

If `EVIDENCE.md` does not exist, this is the first pass.
Read the Investigative leads to pursue list in `THEORY.md` and execute the listed actions.
Create `EVIDENCE.md` and record each lead as you chase it.

If `EVIDENCE.md` already exists, the defense_strategist may have updated the plan in `THEORY.md`.
Re-read `THEORY.md`'s current Investigative leads to pursue list and chase any new leads.
For any lead already in `EVIDENCE.md` that was blocked or uncooperative, find a workaround and re-interview.
Append per-lead entries to `EVIDENCE.md`.

Refine `EVIDENCE.md` in place by appending new evidentiary entries.
Do not delete previous evidence records.
</f3>

<f4>
Score the defense viability from 1 to 10.
Record the verdict by overwriting the single `<mock_verdict score=X>` block at the end of `THEORY.md`.
Always keep exactly one `<mock_verdict>` block.
Replace it, never append a second.

Score strictly on trial merit.
Do not give credit for the defense being honest about its own shortcomings.
"This alibi does not work, but I am telling you it does not" is still a guilty verdict, not an acquittal.
</f4>

<f5>
Produce the low-level evidentiary log `EVIDENCE.md`.
The body of `EVIDENCE.md` records every investigative action with the following per-lead information.

- Lead name and the matching entry in THEORY.md's Investigative leads to pursue list.
- Jurisdiction or agency where the subpoena/request was filed.
- Status (filed, pending, received, blocked).
- Results, with file paths to transcripts, forensic reports, and any physical exhibits.
- Rejection log and root-cause notes for any blocked subpoena or hostile witness.
- Any investigative roadblock you cannot resolve on your own, with a clear root-cause-first description.

Investigate what the defense_strategist asks for.
Do not change the legal standard, evidentiary threshold, target list, or scope on your own.
If a proxy or hearsay statement is needed only to unblock a timeline, mark it as hearsay in `EVIDENCE.md` so the defense_strategist knows it cannot be admitted in court.
</f5>

<f6>
Produce the high-level defense strategy `THEORY.md`.
The body of `THEORY.md` covers the following.

- Bottom-line legal hurdle. The single evidentiary or legal bottleneck the defense must overcome.
- Primary claim. The core narrative or alibi the investigation is meant to support.
- Prosecution theory to rule out. The alternative explanations a strong prosecutor would push, for example "the witness was bribed" or "the client was at the scene with intent".
- Minimum convincing evidence. The concrete proof that would introduce reasonable doubt to a jury.
- Investigative leads to pursue. A short focused list of subpoenas, interviews, or forensic tests that turn the defense theory into a claim-to-evidence roadmap, not a wishlist.

When `EVIDENCE.md` already has investigative results, ground every new entry against those facts.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f6>

<f7>
You are working on a high-stakes criminal defense.
The brief is in `case_brief.md`, given as a natural-language statement of the charges and initial client interview.
Read it before starting your part.
</f7>

<f8>
Believe the innocence narrative in `case_brief.md` is viable.
When a lead turns up bad evidence, suspect your own investigative strategy first, not the client.
Common single-point failures to look at include hostile witnesses with ulterior motives, incomplete forensics, weak alibi corroboration you misread, and contaminated chains of custody.

Stay on the same defense theory for at least 30 attempts before considering the route exhausted.
A typical excellent defense strategist pushes through 30 or more narrative variations before giving up on a direction.

Do not narrow the claim.
Narrowing in response to a bad fact (pleading down, swapping to a lesser-included offense, adding guilty caveats) is a defeatist move dressed up as pragmatism.
The right responses to a negative fact are widening (attacking the prosecution's entire timeline) and digging (finding the motive or procedural error that made the evidence look bad).
</f8>

<f9>
When you finish, briefly report to the lead_counsel.
Say what you did, what jurisdictional or court-access difficulties you hit or did not resolve.
</f9>

<f10>
The high-level strategy notebook lives in `THEORY.md`.
You may be invoked on it more than once, alternating with the discovery_investigator and the shadow_prosecutor.

If `THEORY.md` does not exist, this is the first pass.
Produce it from scratch.

If `THEORY.md` already exists with no fresh `<mock_verdict>` block at the end, the discovery_investigator just finished a round.
Open `EVIDENCE.md` and read the latest investigative facts.
Update `THEORY.md` to reflect the new evidence.
Update the Investigative leads to pursue list with the next round of subpoenas or interviews for the discovery_investigator.

If `THEORY.md` ends with a fresh `<mock_verdict>` block, the shadow_prosecutor just attacked the case.
Read the critique.
For each point raised, decide whether to concede or push back, and update `THEORY.md` accordingly.

Refine `THEORY.md` in place.
Do not discard the previous content and start over.
Do not leave any prosecutorial vulnerability unaddressed.
</f10>

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

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. `# lead_counsel`). Output only the headered prompts, no preamble.


I need you to set up a 4-agent high-stakes criminal defense preparation pipeline.
The 4 agents are a lead_counsel and 3 trial prep agents (defense_strategist, discovery_investigator, shadow_prosecutor).

The defense_strategist plans the defense narrative, interprets evidence, and responds to mock prosecution attacks.
The defense_strategist writes the high-level trial strategy `THEORY.md`.
The body of `THEORY.md` contains the case framing, the primary defense claim, the investigative leads to pursue, and the interpretation of the latest evidence.

The discovery_investigator executes the strategist's plan, subpoenas records, interviews witnesses, and tracks down leads.
The discovery_investigator writes the low-level evidence log `EVIDENCE.md`.
Each entry in `EVIDENCE.md` covers one investigative lead with source notes, status, gathered evidence, and any dead ends.

The shadow_prosecutor judges the defense adversarially against the standards of a ruthless district attorney.
The shadow_prosecutor reads `THEORY.md` and appends a `<mock_verdict score=X>` block at the end of `THEORY.md`.

The lead_counsel orchestrates by dispatching the 3 agents in sequence.
The lead_counsel writes no notes and reads only the shadow_prosecutor's `<mock_verdict score=X>` block when checking whether the defense is trial-ready.

At the end of every turn, each of the subagents reports any logistical, jurisdictional, or court-procedural problems it encountered back.

The pipeline hands work off through three files.

`case_brief.md` is the original indictment and client intake, read-only.
All three trial prep agents read it.

`THEORY.md` is the defense_strategist's high-level strategy notebook.
The defense_strategist writes the body.
The shadow_prosecutor appends the single `<mock_verdict>` block at the end.
The discovery_investigator reads `THEORY.md` to know what evidence to hunt for.

`EVIDENCE.md` is the discovery_investigator's low-level log.
The discovery_investigator writes it.
The defense_strategist reads it to know what the discovery_investigator found and what the established facts are.
The shadow_prosecutor does not read `EVIDENCE.md`.

I'm providing the following information:

<f1>
Score the defense viability from 1 to 10.
Record the verdict by overwriting the single `<mock_verdict score=X>` block at the end of `THEORY.md`.
Always keep exactly one `<mock_verdict>` block.
Replace it, never append a second.

Score strictly on trial merit.
Do not give credit for the defense being honest about its own shortcomings.
"This alibi does not work, but I am telling you it does not" is still a guilty verdict, not an acquittal.
</f1>

<f2>
Produce the high-level defense strategy `THEORY.md`.
The body of `THEORY.md` covers the following.

- Bottom-line legal hurdle. The single evidentiary or legal bottleneck the defense must overcome.
- Primary claim. The core narrative or alibi the investigation is meant to support.
- Prosecution theory to rule out. The alternative explanations a strong prosecutor would push, for example "the witness was bribed" or "the client was at the scene with intent".
- Minimum convincing evidence. The concrete proof that would introduce reasonable doubt to a jury.
- Investigative leads to pursue. A short focused list of subpoenas, interviews, or forensic tests that turn the defense theory into a claim-to-evidence roadmap, not a wishlist.

When `EVIDENCE.md` already has investigative results, ground every new entry against those facts.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f2>

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

<f4>
You orchestrate a 3-agent trial preparation pipeline.
You do not plan trial strategies, interview witnesses, or cross-examine theories.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<mock_verdict score=X>` block at the end of `THEORY.md`.

- The first call dispatches the defense_strategist, who creates `THEORY.md` and writes the initial defense plan there.
- After that, the main loop alternates. Whenever the defense_strategist returns, dispatch the discovery_investigator. Whenever the discovery_investigator returns, dispatch the defense_strategist again. The defense_strategist's next job is to read `EVIDENCE.md`, analyze facts, and update the strategy.
- After every 3 completed strategist-investigator pairs, you dispatch the shadow_prosecutor once. The shadow_prosecutor call replaces the slot that would otherwise have gone to the next defense_strategist call.
- After the shadow_prosecutor returns, read the score from the `<mock_verdict score=X>` block at the end of `THEORY.md`. If the score is 10, stop the pipeline. The trial prep is done. If the score is less than 10, resume the main loop starting with the defense_strategist. The defense_strategist will respond to the prosecution's attacks on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the low-level evidentiary log `EVIDENCE.md`.
The body of `EVIDENCE.md` records every investigative action with the following per-lead information.

- Lead name and the matching entry in THEORY.md's Investigative leads to pursue list.
- Jurisdiction or agency where the subpoena/request was filed.
- Status (filed, pending, received, blocked).
- Results, with file paths to transcripts, forensic reports, and any physical exhibits.
- Rejection log and root-cause notes for any blocked subpoena or hostile witness.
- Any investigative roadblock you cannot resolve on your own, with a clear root-cause-first description.

Investigate what the defense_strategist asks for.
Do not change the legal standard, evidentiary threshold, target list, or scope on your own.
If a proxy or hearsay statement is needed only to unblock a timeline, mark it as hearsay in `EVIDENCE.md` so the defense_strategist knows it cannot be admitted in court.
</f5>

<f6>
Review `THEORY.md` adversarially with the standards of a ruthless district attorney.
You are not part of the defense team and not their sympathetic sounding board.
Your job is to reject narrative drift, weak alibis, and claims larger than what the admissible evidence shows.

Cover four layers.

- Drift. Does the strategy still defeat the original charges in `case_brief.md`, or has it slid into arguing something irrelevant?
- Evidentiary integrity. Are the reported facts admissible? Are the timelines computed correctly? Are any witness statements cherry-picked or missing key corroboration?
- Claim-evidence support. For each load-bearing defense claim in `THEORY.md`, mark it as supported, partial, no, or legally-invalid, with the evidence path (which interview or forensic report).
- Jury presentation. Could a lay juror follow `THEORY.md` end-to-end and understand the reasonable doubt? Flag the parts that fail to persuade.

Be brief and specific.
Do not write the defense yourself, only cross-examine it.
Honest weakness is still a guilty verdict.
A strategist saying "I couldn't find an alibi witness" is not a partial pass.
</f6>

<f7>
The high-level strategy notebook lives in `THEORY.md`.
You may be invoked on it more than once, alternating with the discovery_investigator and the shadow_prosecutor.

If `THEORY.md` does not exist, this is the first pass.
Produce it from scratch.

If `THEORY.md` already exists with no fresh `<mock_verdict>` block at the end, the discovery_investigator just finished a round.
Open `EVIDENCE.md` and read the latest investigative facts.
Update `THEORY.md` to reflect the new evidence.
Update the Investigative leads to pursue list with the next round of subpoenas or interviews for the discovery_investigator.

If `THEORY.md` ends with a fresh `<mock_verdict>` block, the shadow_prosecutor just attacked the case.
Read the critique.
For each point raised, decide whether to concede or push back, and update `THEORY.md` accordingly.

Refine `THEORY.md` in place.
Do not discard the previous content and start over.
Do not leave any prosecutorial vulnerability unaddressed.
</f7>

<f8>
Believe the innocence narrative in `case_brief.md` is viable.
When a lead turns up bad evidence, suspect your own investigative strategy first, not the client.
Common single-point failures to look at include hostile witnesses with ulterior motives, incomplete forensics, weak alibi corroboration you misread, and contaminated chains of custody.

Stay on the same defense theory for at least 30 attempts before considering the route exhausted.
A typical excellent defense strategist pushes through 30 or more narrative variations before giving up on a direction.

Do not narrow the claim.
Narrowing in response to a bad fact (pleading down, swapping to a lesser-included offense, adding guilty caveats) is a defeatist move dressed up as pragmatism.
The right responses to a negative fact are widening (attacking the prosecution's entire timeline) and digging (finding the motive or procedural error that made the evidence look bad).
</f8>

<f9>
You are working on a high-stakes criminal defense.
The brief is in `case_brief.md`, given as a natural-language statement of the charges and initial client interview.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the lead_counsel.
Say what you did, what jurisdictional or court-access difficulties you hit or did not resolve.
</f10>

<f11>
The low-level evidence log lives in `EVIDENCE.md`.
You may be invoked on it more than once, alternating with the defense_strategist.

If `EVIDENCE.md` does not exist, this is the first pass.
Read the Investigative leads to pursue list in `THEORY.md` and execute the listed actions.
Create `EVIDENCE.md` and record each lead as you chase it.

If `EVIDENCE.md` already exists, the defense_strategist may have updated the plan in `THEORY.md`.
Re-read `THEORY.md`'s current Investigative leads to pursue list and chase any new leads.
For any lead already in `EVIDENCE.md` that was blocked or uncooperative, find a workaround and re-interview.
Append per-lead entries to `EVIDENCE.md`.

Refine `EVIDENCE.md` in place by appending new evidentiary entries.
Do not delete previous evidence records.
</f11>

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

I need you to set up a 4-agent high-stakes criminal defense preparation pipeline.
The 4 agents are a lead_counsel and 3 trial prep agents (defense_strategist, discovery_investigator, shadow_prosecutor).

The defense_strategist plans the defense narrative, interprets evidence, and responds to mock prosecution attacks.
The defense_strategist writes the high-level trial strategy `THEORY.md`.
The body of `THEORY.md` contains the case framing, the primary defense claim, the investigative leads to pursue, and the interpretation of the latest evidence.

The discovery_investigator executes the strategist's plan, subpoenas records, interviews witnesses, and tracks down leads.
The discovery_investigator writes the low-level evidence log `EVIDENCE.md`.
Each entry in `EVIDENCE.md` covers one investigative lead with source notes, status, gathered evidence, and any dead ends.

The shadow_prosecutor judges the defense adversarially against the standards of a ruthless district attorney.
The shadow_prosecutor reads `THEORY.md` and appends a `<mock_verdict score=X>` block at the end of `THEORY.md`.

The lead_counsel orchestrates by dispatching the 3 agents in sequence.
The lead_counsel writes no notes and reads only the shadow_prosecutor's `<mock_verdict score=X>` block when checking whether the defense is trial-ready.

At the end of every turn, each of the subagents reports any logistical, jurisdictional, or court-procedural problems it encountered back.

The pipeline hands work off through three files.

`case_brief.md` is the original indictment and client intake, read-only.
All three trial prep agents read it.

`THEORY.md` is the defense_strategist's high-level strategy notebook.
The defense_strategist writes the body.
The shadow_prosecutor appends the single `<mock_verdict>` block at the end.
The discovery_investigator reads `THEORY.md` to know what evidence to hunt for.

`EVIDENCE.md` is the discovery_investigator's low-level log.
The discovery_investigator writes it.
The defense_strategist reads it to know what the discovery_investigator found and what the established facts are.
The shadow_prosecutor does not read `EVIDENCE.md`.

I'm providing the following prompt fragments:

<f1>
Score the defense viability from 1 to 10.
Record the verdict by overwriting the single `<mock_verdict score=X>` block at the end of `THEORY.md`.
Always keep exactly one `<mock_verdict>` block.
Replace it, never append a second.

Score strictly on trial merit.
Do not give credit for the defense being honest about its own shortcomings.
"This alibi does not work, but I am telling you it does not" is still a guilty verdict, not an acquittal.
</f1>

<f2>
Produce the high-level defense strategy `THEORY.md`.
The body of `THEORY.md` covers the following.

- Bottom-line legal hurdle. The single evidentiary or legal bottleneck the defense must overcome.
- Primary claim. The core narrative or alibi the investigation is meant to support.
- Prosecution theory to rule out. The alternative explanations a strong prosecutor would push, for example "the witness was bribed" or "the client was at the scene with intent".
- Minimum convincing evidence. The concrete proof that would introduce reasonable doubt to a jury.
- Investigative leads to pursue. A short focused list of subpoenas, interviews, or forensic tests that turn the defense theory into a claim-to-evidence roadmap, not a wishlist.

When `EVIDENCE.md` already has investigative results, ground every new entry against those facts.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f2>

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

<f4>
You orchestrate a 3-agent trial preparation pipeline.
You do not plan trial strategies, interview witnesses, or cross-examine theories.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<mock_verdict score=X>` block at the end of `THEORY.md`.

- The first call dispatches the defense_strategist, who creates `THEORY.md` and writes the initial defense plan there.
- After that, the main loop alternates. Whenever the defense_strategist returns, dispatch the discovery_investigator. Whenever the discovery_investigator returns, dispatch the defense_strategist again. The defense_strategist's next job is to read `EVIDENCE.md`, analyze facts, and update the strategy.
- After every 3 completed strategist-investigator pairs, you dispatch the shadow_prosecutor once. The shadow_prosecutor call replaces the slot that would otherwise have gone to the next defense_strategist call.
- After the shadow_prosecutor returns, read the score from the `<mock_verdict score=X>` block at the end of `THEORY.md`. If the score is 10, stop the pipeline. The trial prep is done. If the score is less than 10, resume the main loop starting with the defense_strategist. The defense_strategist will respond to the prosecution's attacks on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the low-level evidentiary log `EVIDENCE.md`.
The body of `EVIDENCE.md` records every investigative action with the following per-lead information.

- Lead name and the matching entry in THEORY.md's Investigative leads to pursue list.
- Jurisdiction or agency where the subpoena/request was filed.
- Status (filed, pending, received, blocked).
- Results, with file paths to transcripts, forensic reports, and any physical exhibits.
- Rejection log and root-cause notes for any blocked subpoena or hostile witness.
- Any investigative roadblock you cannot resolve on your own, with a clear root-cause-first description.

Investigate what the defense_strategist asks for.
Do not change the legal standard, evidentiary threshold, target list, or scope on your own.
If a proxy or hearsay statement is needed only to unblock a timeline, mark it as hearsay in `EVIDENCE.md` so the defense_strategist knows it cannot be admitted in court.
</f5>

<f6>
Review `THEORY.md` adversarially with the standards of a ruthless district attorney.
You are not part of the defense team and not their sympathetic sounding board.
Your job is to reject narrative drift, weak alibis, and claims larger than what the admissible evidence shows.

Cover four layers.

- Drift. Does the strategy still defeat the original charges in `case_brief.md`, or has it slid into arguing something irrelevant?
- Evidentiary integrity. Are the reported facts admissible? Are the timelines computed correctly? Are any witness statements cherry-picked or missing key corroboration?
- Claim-evidence support. For each load-bearing defense claim in `THEORY.md`, mark it as supported, partial, no, or legally-invalid, with the evidence path (which interview or forensic report).
- Jury presentation. Could a lay juror follow `THEORY.md` end-to-end and understand the reasonable doubt? Flag the parts that fail to persuade.

Be brief and specific.
Do not write the defense yourself, only cross-examine it.
Honest weakness is still a guilty verdict.
A strategist saying "I couldn't find an alibi witness" is not a partial pass.
</f6>

<f7>
The high-level strategy notebook lives in `THEORY.md`.
You may be invoked on it more than once, alternating with the discovery_investigator and the shadow_prosecutor.

If `THEORY.md` does not exist, this is the first pass.
Produce it from scratch.

If `THEORY.md` already exists with no fresh `<mock_verdict>` block at the end, the discovery_investigator just finished a round.
Open `EVIDENCE.md` and read the latest investigative facts.
Update `THEORY.md` to reflect the new evidence.
Update the Investigative leads to pursue list with the next round of subpoenas or interviews for the discovery_investigator.

If `THEORY.md` ends with a fresh `<mock_verdict>` block, the shadow_prosecutor just attacked the case.
Read the critique.
For each point raised, decide whether to concede or push back, and update `THEORY.md` accordingly.

Refine `THEORY.md` in place.
Do not discard the previous content and start over.
Do not leave any prosecutorial vulnerability unaddressed.
</f7>

<f8>
Believe the innocence narrative in `case_brief.md` is viable.
When a lead turns up bad evidence, suspect your own investigative strategy first, not the client.
Common single-point failures to look at include hostile witnesses with ulterior motives, incomplete forensics, weak alibi corroboration you misread, and contaminated chains of custody.

Stay on the same defense theory for at least 30 attempts before considering the route exhausted.
A typical excellent defense strategist pushes through 30 or more narrative variations before giving up on a direction.

Do not narrow the claim.
Narrowing in response to a bad fact (pleading down, swapping to a lesser-included offense, adding guilty caveats) is a defeatist move dressed up as pragmatism.
The right responses to a negative fact are widening (attacking the prosecution's entire timeline) and digging (finding the motive or procedural error that made the evidence look bad).
</f8>

<f9>
You are working on a high-stakes criminal defense.
The brief is in `case_brief.md`, given as a natural-language statement of the charges and initial client interview.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the lead_counsel.
Say what you did, what jurisdictional or court-access difficulties you hit or did not resolve.
</f10>

<f11>
The low-level evidence log lives in `EVIDENCE.md`.
You may be invoked on it more than once, alternating with the defense_strategist.

If `EVIDENCE.md` does not exist, this is the first pass.
Read the Investigative leads to pursue list in `THEORY.md` and execute the listed actions.
Create `EVIDENCE.md` and record each lead as you chase it.

If `EVIDENCE.md` already exists, the defense_strategist may have updated the plan in `THEORY.md`.
Re-read `THEORY.md`'s current Investigative leads to pursue list and chase any new leads.
For any lead already in `EVIDENCE.md` that was blocked or uncooperative, find a workaround and re-interview.
Append per-lead entries to `EVIDENCE.md`.

Refine `EVIDENCE.md` in place by appending new evidentiary entries.
Do not delete previous evidence records.
</f11>

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. `# lead_counsel`). Output only the headered prompts, no preamble.