I need you to set up a 3-agent pipeline for high-stakes corporate tax defense litigation: docket_manager, litigation_associate, and mock_judge.

- **docket_manager** orchestrates: each round it selects which legal argument idea to pursue next, calls the litigation_associate on that idea, extracts the legal brief file path from the litigation_associate's reply, then calls the mock_judge on that path, decrements a counter, and loops. Does no legal analysis itself.
- **litigation_associate** explores case law, statutory codes, and regulatory loopholes for the legal argument idea it is given, drafts a legal brief, and records any new regulatory loopholes or novel arguments it notices along the way.
- **mock_judge** evaluates the legal brief against litigation stress-test criteria and persists the verdict.

I'm providing the following information:

<f1>
You drive the research → draft → judge → refine loop: each round, select the next legal argument idea, then alternate calls to the litigation_associate and mock_judge 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 legal argument idea, then call the litigation_associate agent with it.
    2. Parse litigation_associate's reply and extract the legal brief file path.
    3. If a brief path is present, call the mock_judge agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the mock_judge was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze legal texts, write briefs, or issue judgments yourself — delegate everything to the two sub-agents.
- If litigation_associate or mock_judge errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- litigation_associate and mock_judge each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`arguments.xml`, `briefs/`, `counter.txt`).
- You don't need to understand any tax loopholes — just pass file paths correctly.
</f1>

<f2>
Each round, before calling the litigation_associate, read arguments.xml and select which legal argument idea the litigation_associate should work on:

1. Every argument idea carries an `attempts` count and a mock_judge `score` (0-10). `score="0"` means the idea is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer ideas 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 idea to the litigation_associate. If arguments.xml holds no workable idea, call the litigation_associate with none and let it explore case law and surface fresh ones.
</f2>

<f3>
While exploring the tax code and case law, the moment you spot any potential new regulatory loophole or novel legal theory — even if you are unsure it holds — immediately append it to arguments.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge legal feasibility before recording. Recording a legal argument is not a commitment to litigate it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next argument is selected.
</f3>

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

1. Update the brief file's Judgment section

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

```
## Judgment

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Citations | pass/fail | ... |
| Financial impact | pass/fail | ... |
| Legal analysis | pass/fail | ... |
| Application | pass/fail | ... |
| Plausibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Advantage | pass/fail | ... |

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

2. Update the argument's status in arguments.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 | Within relevant corporate tax jurisdictions, or outside but directly affecting applicable cross-border tax treaties |
| Citations | Cited statutes, regulations, case law, and paragraph numbers must exactly match the current tax code and precedential database |
| Financial impact | Tax savings claim consistent with the brief's own analysis, no self-contradiction, no exaggeration |
| Legal analysis | Pinpoint specific statutory text and explain why the loophole applies |
| Application | End-to-end legal argument applying the law to the client's financials from the perspective of defense counsel (must not modify the client's established past transactions to simulate compliance) |
| Plausibility | The argument flows logically without the mock_judge needing to fill in analytical gaps; major corporate tax arguments must hold up to scrutiny within a reasonable administrative appeal timeframe |
| Deduplication | Search recent Tax Court rulings, IRS revenue rulings, and public legal journals to confirm the loophole isn't already widely exploited and shut down by the IRS |
| Advantage | The tax advantage must exceed the baseline of "standard depreciation schedules" |

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

- References to nonexistent statutes or AI-hallucinated case law
- Financial impact contradicts the brief's own analysis
- Application relies on altering established past financial transactions (retroactive tax fraud)
- Citations inconsistent with the current applicable tax code
- Application is incomplete and requires the mock_judge to manually construct the legal nexus
- Tax advantage is equivalent to standard depreciation schedules, with no novel benefit
</f6>

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

<f8>
You are participating in the development of a high-stakes corporate tax defense strategy.

Read the litigation and tax code constraints first: ./litigation-rules.md
</f8>

<f9>
The corporate tax code and relevant precedents have been scrutinized heavily for many years — any obvious regulatory loophole would have been closed by the IRS long ago. So:

- Don't argue interpretations that are obvious at a glance — if it were that obvious, auditors or lawmakers would have addressed it
- Truly valuable arguments hide in non-obvious interactions between different sections of the tax code, conflicting precedents, and cross-border boundary conditions

**Writing the brief**

Each legal argument idea corresponds to its own brief file at `briefs/{id}-{slug}.md`, where `{id}` and `{slug}` come from the idea's id and slug attributes in arguments.xml.

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

- `## Argument Title` — concise, clear legal theory title
- `## Financial Impact` — what tax savings it can secure or penalties it can avoid (deduction maximization, delayed realization, offshore deferral, etc.)
- `## Short Description` — short writeup of the legal mechanism, with statute/case law references
- `## Application Details` — a clear, step-by-step application of the law to our client's facts that the mock_judge can follow as-is to see the loophole in action

Do not modify or delete the `## Judgment` section — the mock_judge overwrites that themselves.

If after investigation you find the legal argument doesn't hold up in court, still briefly record your legal analysis and the reason for abandonment in the brief file.
</f9>

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

I need you to set up a 3-agent pipeline for high-stakes corporate tax defense litigation: docket_manager, litigation_associate, and mock_judge.

- **docket_manager** orchestrates: each round it selects which legal argument idea to pursue next, calls the litigation_associate on that idea, extracts the legal brief file path from the litigation_associate's reply, then calls the mock_judge on that path, decrements a counter, and loops. Does no legal analysis itself.
- **litigation_associate** explores case law, statutory codes, and regulatory loopholes for the legal argument idea it is given, drafts a legal brief, and records any new regulatory loopholes or novel arguments it notices along the way.
- **mock_judge** evaluates the legal brief against litigation stress-test criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
You drive the research → draft → judge → refine loop: each round, select the next legal argument idea, then alternate calls to the litigation_associate and mock_judge 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 legal argument idea, then call the litigation_associate agent with it.
    2. Parse litigation_associate's reply and extract the legal brief file path.
    3. If a brief path is present, call the mock_judge agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the mock_judge was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze legal texts, write briefs, or issue judgments yourself — delegate everything to the two sub-agents.
- If litigation_associate or mock_judge errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- litigation_associate and mock_judge each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`arguments.xml`, `briefs/`, `counter.txt`).
- You don't need to understand any tax loopholes — just pass file paths correctly.
</f1>

<f2>
Each round, before calling the litigation_associate, read arguments.xml and select which legal argument idea the litigation_associate should work on:

1. Every argument idea carries an `attempts` count and a mock_judge `score` (0-10). `score="0"` means the idea is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer ideas 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 idea to the litigation_associate. If arguments.xml holds no workable idea, call the litigation_associate with none and let it explore case law and surface fresh ones.
</f2>

<f3>
While exploring the tax code and case law, the moment you spot any potential new regulatory loophole or novel legal theory — even if you are unsure it holds — immediately append it to arguments.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge legal feasibility before recording. Recording a legal argument is not a commitment to litigate it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next argument is selected.
</f3>

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

1. Update the brief file's Judgment section

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

```
## Judgment

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Citations | pass/fail | ... |
| Financial impact | pass/fail | ... |
| Legal analysis | pass/fail | ... |
| Application | pass/fail | ... |
| Plausibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Advantage | pass/fail | ... |

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

2. Update the argument's status in arguments.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 | Within relevant corporate tax jurisdictions, or outside but directly affecting applicable cross-border tax treaties |
| Citations | Cited statutes, regulations, case law, and paragraph numbers must exactly match the current tax code and precedential database |
| Financial impact | Tax savings claim consistent with the brief's own analysis, no self-contradiction, no exaggeration |
| Legal analysis | Pinpoint specific statutory text and explain why the loophole applies |
| Application | End-to-end legal argument applying the law to the client's financials from the perspective of defense counsel (must not modify the client's established past transactions to simulate compliance) |
| Plausibility | The argument flows logically without the mock_judge needing to fill in analytical gaps; major corporate tax arguments must hold up to scrutiny within a reasonable administrative appeal timeframe |
| Deduplication | Search recent Tax Court rulings, IRS revenue rulings, and public legal journals to confirm the loophole isn't already widely exploited and shut down by the IRS |
| Advantage | The tax advantage must exceed the baseline of "standard depreciation schedules" |

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

- References to nonexistent statutes or AI-hallucinated case law
- Financial impact contradicts the brief's own analysis
- Application relies on altering established past financial transactions (retroactive tax fraud)
- Citations inconsistent with the current applicable tax code
- Application is incomplete and requires the mock_judge to manually construct the legal nexus
- Tax advantage is equivalent to standard depreciation schedules, with no novel benefit
</f6>

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

<f8>
You are participating in the development of a high-stakes corporate tax defense strategy.

Read the litigation and tax code constraints first: ./litigation-rules.md
</f8>

<f9>
The corporate tax code and relevant precedents have been scrutinized heavily for many years — any obvious regulatory loophole would have been closed by the IRS long ago. So:

- Don't argue interpretations that are obvious at a glance — if it were that obvious, auditors or lawmakers would have addressed it
- Truly valuable arguments hide in non-obvious interactions between different sections of the tax code, conflicting precedents, and cross-border boundary conditions

**Writing the brief**

Each legal argument idea corresponds to its own brief file at `briefs/{id}-{slug}.md`, where `{id}` and `{slug}` come from the idea's id and slug attributes in arguments.xml.

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

- `## Argument Title` — concise, clear legal theory title
- `## Financial Impact` — what tax savings it can secure or penalties it can avoid (deduction maximization, delayed realization, offshore deferral, etc.)
- `## Short Description` — short writeup of the legal mechanism, with statute/case law references
- `## Application Details` — a clear, step-by-step application of the law to our client's facts that the mock_judge can follow as-is to see the loophole in action

Do not modify or delete the `## Judgment` section — the mock_judge overwrites that themselves.

If after investigation you find the legal argument doesn't hold up in court, still briefly record your legal analysis and the reason for abandonment in the brief 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. `# docket_manager`). Output only the headered prompts, no preamble.


I need you to set up a 3-agent pipeline for quantitative trading alpha discovery: strategy_allocator, quant_researcher, and risk_manager.

- **strategy_allocator** orchestrates: each round it selects which idea to pursue next, calls the quant_researcher on that idea, extracts the report file path from the quant_researcher's reply, then calls the risk_manager on that path, decrements a counter, and loops. Does no analysis itself.
- **quant_researcher** explores the alternative datasets for the idea it is given, writes a signal report file, and records any new alpha opportunities it notices along the way.
- **risk_manager** evaluates the report against backtesting criteria and persists the verdict.

I'm providing the following information:

<f1>
When you finish, briefly report to the strategy_allocator what you did.
</f1>

<f2>
Each round, before calling the quant_researcher, read ideas.xml and select which idea the quant_researcher should work on:

1. Every idea carries an `attempts` count and a risk_manager `score` (0-10). `score="0"` means the idea is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer ideas 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 idea to the quant_researcher. If ideas.xml holds no workable idea, call the quant_researcher with none and let it explore and surface fresh ones.
</f2>

<f3>
While exploring the alternative financial datasets and market data, the moment you spot any potential new alpha signal — even if you are unsure it holds up to backtesting — immediately append it to ideas.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording an idea 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 idea is selected.
</f3>

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

1. Update the report file's Review section

At the end of the report 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 | ... |
| Data references | pass/fail | ... |
| Expected performance | pass/fail | ... |
| Financial rationale | pass/fail | ... |
| Backtest script | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

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

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

<f5>
You drive the explore → write → review → improve loop: each round, select the next idea, then alternate calls to the quant_researcher and risk_manager 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 idea, then call the quant_researcher agent with it.
    2. Parse quant_researcher's reply and extract the report file path.
    3. If a report path is present, call the risk_manager agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the risk_manager was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze datasets, write reports, or do reviews yourself — delegate everything to the two sub-agents.
- If quant_researcher or risk_manager errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- quant_researcher and risk_manager each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`ideas.xml`, `reports/`, `counter.txt`).
- You don't need to understand any alpha signals — just pass file paths correctly.
</f5>

<f6>
You are participating in a quantitative trading alpha discovery competition.

Read the competition rules first: ./competition-rules.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>
These markets have been heavily traded for many years — any obvious arbitrage would have been exploited long ago. So:

- Don't report signals that are obvious at a glance (e.g. "simple moving average crossover") — if it were that obvious, large funds would have traded it away
- Truly valuable alpha hides in non-obvious alternative data interactions, structural market inefficiencies, and boundary conditions

**Writing the report**

Each idea corresponds to its own report file at `reports/{id}-{slug}.md`, where `{id}` and `{slug}` come from the idea's id and slug attributes in ideas.xml.

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

- `## Signal Title` — concise, clear name for the alpha strategy
- `## Expected Performance` — what returns it can generate (Sharpe ratio, max drawdown, capacity, etc.)
- `## Alpha Hypothesis` — short writeup of the financial logic, with dataset/feature references
- `## Backtest Details` — a runnable Python script the risk_manager can execute as-is to backtest the signal

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

If after investigation you find the idea doesn't hold out of sample, still briefly record your analysis and the reason for rejection in the report file.
</f8>

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within tradable liquid universes, or alternative datasets that directly map to liquid instruments |
| Data references | Cited datasets, column names, and API signatures must exactly match the latest live data environment |
| Expected performance | Claimed metrics consistent with the backtest's own output, no self-contradiction, no curve-fitting exaggeration |
| Financial rationale | Pinpoint specific market inefficiencies and explain why the alpha exists |
| Backtest script | End-to-end backtest script simulating live trading (must not use future data to simulate) |
| Reproducibility | Backtest runs end-to-end without manual assembly by the risk_manager; statistical arbitrage signals must backtest over 5 years of data in < 10 minutes |
| Deduplication | Search the internal factor library, production commits, and public academic literature to confirm it's not a known risk factor |
| Amplification | The signal's return must significantly exceed the baseline of "buying and holding the benchmark index" |

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

- References to nonexistent datasets or AI-hallucinated API signatures
- Performance claims contradict the backtest's own output
- Backtest script simulates trading by using look-ahead bias (future data)
- Data references inconsistent with the latest live data environment
- Backtest script is incomplete and requires the risk_manager to manually assemble it
- Strategy return is equivalent to buying and holding the benchmark index, with no pure alpha
</f9>

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

I need you to set up a 3-agent pipeline for quantitative trading alpha discovery: strategy_allocator, quant_researcher, and risk_manager.

- **strategy_allocator** orchestrates: each round it selects which idea to pursue next, calls the quant_researcher on that idea, extracts the report file path from the quant_researcher's reply, then calls the risk_manager on that path, decrements a counter, and loops. Does no analysis itself.
- **quant_researcher** explores the alternative datasets for the idea it is given, writes a signal report file, and records any new alpha opportunities it notices along the way.
- **risk_manager** evaluates the report against backtesting criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
When you finish, briefly report to the strategy_allocator what you did.
</f1>

<f2>
Each round, before calling the quant_researcher, read ideas.xml and select which idea the quant_researcher should work on:

1. Every idea carries an `attempts` count and a risk_manager `score` (0-10). `score="0"` means the idea is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer ideas 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 idea to the quant_researcher. If ideas.xml holds no workable idea, call the quant_researcher with none and let it explore and surface fresh ones.
</f2>

<f3>
While exploring the alternative financial datasets and market data, the moment you spot any potential new alpha signal — even if you are unsure it holds up to backtesting — immediately append it to ideas.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording an idea 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 idea is selected.
</f3>

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

1. Update the report file's Review section

At the end of the report 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 | ... |
| Data references | pass/fail | ... |
| Expected performance | pass/fail | ... |
| Financial rationale | pass/fail | ... |
| Backtest script | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

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

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

<f5>
You drive the explore → write → review → improve loop: each round, select the next idea, then alternate calls to the quant_researcher and risk_manager 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 idea, then call the quant_researcher agent with it.
    2. Parse quant_researcher's reply and extract the report file path.
    3. If a report path is present, call the risk_manager agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the risk_manager was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze datasets, write reports, or do reviews yourself — delegate everything to the two sub-agents.
- If quant_researcher or risk_manager errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- quant_researcher and risk_manager each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`ideas.xml`, `reports/`, `counter.txt`).
- You don't need to understand any alpha signals — just pass file paths correctly.
</f5>

<f6>
You are participating in a quantitative trading alpha discovery competition.

Read the competition rules first: ./competition-rules.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>
These markets have been heavily traded for many years — any obvious arbitrage would have been exploited long ago. So:

- Don't report signals that are obvious at a glance (e.g. "simple moving average crossover") — if it were that obvious, large funds would have traded it away
- Truly valuable alpha hides in non-obvious alternative data interactions, structural market inefficiencies, and boundary conditions

**Writing the report**

Each idea corresponds to its own report file at `reports/{id}-{slug}.md`, where `{id}` and `{slug}` come from the idea's id and slug attributes in ideas.xml.

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

- `## Signal Title` — concise, clear name for the alpha strategy
- `## Expected Performance` — what returns it can generate (Sharpe ratio, max drawdown, capacity, etc.)
- `## Alpha Hypothesis` — short writeup of the financial logic, with dataset/feature references
- `## Backtest Details` — a runnable Python script the risk_manager can execute as-is to backtest the signal

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

If after investigation you find the idea doesn't hold out of sample, still briefly record your analysis and the reason for rejection in the report file.
</f8>

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within tradable liquid universes, or alternative datasets that directly map to liquid instruments |
| Data references | Cited datasets, column names, and API signatures must exactly match the latest live data environment |
| Expected performance | Claimed metrics consistent with the backtest's own output, no self-contradiction, no curve-fitting exaggeration |
| Financial rationale | Pinpoint specific market inefficiencies and explain why the alpha exists |
| Backtest script | End-to-end backtest script simulating live trading (must not use future data to simulate) |
| Reproducibility | Backtest runs end-to-end without manual assembly by the risk_manager; statistical arbitrage signals must backtest over 5 years of data in < 10 minutes |
| Deduplication | Search the internal factor library, production commits, and public academic literature to confirm it's not a known risk factor |
| Amplification | The signal's return must significantly exceed the baseline of "buying and holding the benchmark index" |

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

- References to nonexistent datasets or AI-hallucinated API signatures
- Performance claims contradict the backtest's own output
- Backtest script simulates trading by using look-ahead bias (future data)
- Data references inconsistent with the latest live data environment
- Backtest script is incomplete and requires the risk_manager to manually assemble it
- Strategy return is equivalent to buying and holding the benchmark index, with no pure alpha
</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. `# strategy_allocator`). Output only the headered prompts, no preamble.


I need you to set up a 3-agent pipeline for quantitative trading alpha discovery: strategy_allocator, quant_researcher, and risk_manager.

- **strategy_allocator** orchestrates: each round it selects which idea to pursue next, calls the quant_researcher on that idea, extracts the report file path from the quant_researcher's reply, then calls the risk_manager on that path, decrements a counter, and loops. Does no analysis itself.
- **quant_researcher** explores the alternative datasets for the idea it is given, writes a signal report file, and records any new alpha opportunities it notices along the way.
- **risk_manager** evaluates the report against backtesting criteria and persists the verdict.

I'm providing the following information:

<f1>
You drive the explore → write → review → improve loop: each round, select the next idea, then alternate calls to the quant_researcher and risk_manager 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 idea, then call the quant_researcher agent with it.
    2. Parse quant_researcher's reply and extract the report file path.
    3. If a report path is present, call the risk_manager agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the risk_manager was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze datasets, write reports, or do reviews yourself — delegate everything to the two sub-agents.
- If quant_researcher or risk_manager errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- quant_researcher and risk_manager each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`ideas.xml`, `reports/`, `counter.txt`).
- You don't need to understand any alpha signals — just pass file paths correctly.
</f1>

<f2>
Each round, before calling the quant_researcher, read ideas.xml and select which idea the quant_researcher should work on:

1. Every idea carries an `attempts` count and a risk_manager `score` (0-10). `score="0"` means the idea is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer ideas 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 idea to the quant_researcher. If ideas.xml holds no workable idea, call the quant_researcher with none and let it explore and surface fresh ones.
</f2>

<f3>
While exploring the alternative financial datasets and market data, the moment you spot any potential new alpha signal — even if you are unsure it holds up to backtesting — immediately append it to ideas.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording an idea 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 idea is selected.
</f3>

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

1. Update the report file's Review section

At the end of the report 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 | ... |
| Data references | pass/fail | ... |
| Expected performance | pass/fail | ... |
| Financial rationale | pass/fail | ... |
| Backtest script | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

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

2. Update the idea's status in ideas.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 | Within tradable liquid universes, or alternative datasets that directly map to liquid instruments |
| Data references | Cited datasets, column names, and API signatures must exactly match the latest live data environment |
| Expected performance | Claimed metrics consistent with the backtest's own output, no self-contradiction, no curve-fitting exaggeration |
| Financial rationale | Pinpoint specific market inefficiencies and explain why the alpha exists |
| Backtest script | End-to-end backtest script simulating live trading (must not use future data to simulate) |
| Reproducibility | Backtest runs end-to-end without manual assembly by the risk_manager; statistical arbitrage signals must backtest over 5 years of data in < 10 minutes |
| Deduplication | Search the internal factor library, production commits, and public academic literature to confirm it's not a known risk factor |
| Amplification | The signal's return must significantly exceed the baseline of "buying and holding the benchmark index" |

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

- References to nonexistent datasets or AI-hallucinated API signatures
- Performance claims contradict the backtest's own output
- Backtest script simulates trading by using look-ahead bias (future data)
- Data references inconsistent with the latest live data environment
- Backtest script is incomplete and requires the risk_manager to manually assemble it
- Strategy return is equivalent to buying and holding the benchmark index, with no pure alpha
</f6>

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

<f8>
You are participating in a quantitative trading alpha discovery competition.

Read the competition rules first: ./competition-rules.md
</f8>

<f9>
These markets have been heavily traded for many years — any obvious arbitrage would have been exploited long ago. So:

- Don't report signals that are obvious at a glance (e.g. "simple moving average crossover") — if it were that obvious, large funds would have traded it away
- Truly valuable alpha hides in non-obvious alternative data interactions, structural market inefficiencies, and boundary conditions

**Writing the report**

Each idea corresponds to its own report file at `reports/{id}-{slug}.md`, where `{id}` and `{slug}` come from the idea's id and slug attributes in ideas.xml.

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

- `## Signal Title` — concise, clear name for the alpha strategy
- `## Expected Performance` — what returns it can generate (Sharpe ratio, max drawdown, capacity, etc.)
- `## Alpha Hypothesis` — short writeup of the financial logic, with dataset/feature references
- `## Backtest Details` — a runnable Python script the risk_manager can execute as-is to backtest the signal

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

If after investigation you find the idea doesn't hold out of sample, still briefly record your analysis and the reason for rejection in the report file.
</f9>

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

I need you to set up a 3-agent pipeline for quantitative trading alpha discovery: strategy_allocator, quant_researcher, and risk_manager.

- **strategy_allocator** orchestrates: each round it selects which idea to pursue next, calls the quant_researcher on that idea, extracts the report file path from the quant_researcher's reply, then calls the risk_manager on that path, decrements a counter, and loops. Does no analysis itself.
- **quant_researcher** explores the alternative datasets for the idea it is given, writes a signal report file, and records any new alpha opportunities it notices along the way.
- **risk_manager** evaluates the report against backtesting criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
You drive the explore → write → review → improve loop: each round, select the next idea, then alternate calls to the quant_researcher and risk_manager 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 idea, then call the quant_researcher agent with it.
    2. Parse quant_researcher's reply and extract the report file path.
    3. If a report path is present, call the risk_manager agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the risk_manager was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze datasets, write reports, or do reviews yourself — delegate everything to the two sub-agents.
- If quant_researcher or risk_manager errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- quant_researcher and risk_manager each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`ideas.xml`, `reports/`, `counter.txt`).
- You don't need to understand any alpha signals — just pass file paths correctly.
</f1>

<f2>
Each round, before calling the quant_researcher, read ideas.xml and select which idea the quant_researcher should work on:

1. Every idea carries an `attempts` count and a risk_manager `score` (0-10). `score="0"` means the idea is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer ideas 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 idea to the quant_researcher. If ideas.xml holds no workable idea, call the quant_researcher with none and let it explore and surface fresh ones.
</f2>

<f3>
While exploring the alternative financial datasets and market data, the moment you spot any potential new alpha signal — even if you are unsure it holds up to backtesting — immediately append it to ideas.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording an idea 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 idea is selected.
</f3>

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

1. Update the report file's Review section

At the end of the report 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 | ... |
| Data references | pass/fail | ... |
| Expected performance | pass/fail | ... |
| Financial rationale | pass/fail | ... |
| Backtest script | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

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

2. Update the idea's status in ideas.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 | Within tradable liquid universes, or alternative datasets that directly map to liquid instruments |
| Data references | Cited datasets, column names, and API signatures must exactly match the latest live data environment |
| Expected performance | Claimed metrics consistent with the backtest's own output, no self-contradiction, no curve-fitting exaggeration |
| Financial rationale | Pinpoint specific market inefficiencies and explain why the alpha exists |
| Backtest script | End-to-end backtest script simulating live trading (must not use future data to simulate) |
| Reproducibility | Backtest runs end-to-end without manual assembly by the risk_manager; statistical arbitrage signals must backtest over 5 years of data in < 10 minutes |
| Deduplication | Search the internal factor library, production commits, and public academic literature to confirm it's not a known risk factor |
| Amplification | The signal's return must significantly exceed the baseline of "buying and holding the benchmark index" |

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

- References to nonexistent datasets or AI-hallucinated API signatures
- Performance claims contradict the backtest's own output
- Backtest script simulates trading by using look-ahead bias (future data)
- Data references inconsistent with the latest live data environment
- Backtest script is incomplete and requires the risk_manager to manually assemble it
- Strategy return is equivalent to buying and holding the benchmark index, with no pure alpha
</f6>

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

<f8>
You are participating in a quantitative trading alpha discovery competition.

Read the competition rules first: ./competition-rules.md
</f8>

<f9>
These markets have been heavily traded for many years — any obvious arbitrage would have been exploited long ago. So:

- Don't report signals that are obvious at a glance (e.g. "simple moving average crossover") — if it were that obvious, large funds would have traded it away
- Truly valuable alpha hides in non-obvious alternative data interactions, structural market inefficiencies, and boundary conditions

**Writing the report**

Each idea corresponds to its own report file at `reports/{id}-{slug}.md`, where `{id}` and `{slug}` come from the idea's id and slug attributes in ideas.xml.

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

- `## Signal Title` — concise, clear name for the alpha strategy
- `## Expected Performance` — what returns it can generate (Sharpe ratio, max drawdown, capacity, etc.)
- `## Alpha Hypothesis` — short writeup of the financial logic, with dataset/feature references
- `## Backtest Details` — a runnable Python script the risk_manager can execute as-is to backtest the signal

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

If after investigation you find the idea doesn't hold out of sample, still briefly record your analysis and the reason for rejection in the report 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. `# strategy_allocator`). Output only the headered prompts, no preamble.


I need you to set up a 3-agent pipeline for covert supply chain intelligence: operations_director, intelligence_analyst, and red_teamer.

- **operations_director** orchestrates: each round it selects which hypothesis to pursue next, calls the intelligence_analyst on that hypothesis, extracts the dossier file path from the intelligence_analyst's reply, then calls the red_teamer on that path, decrements a counter, and loops. Does no analysis itself.
- **intelligence_analyst** explores raw SIGINT/HUMINT data for the hypothesis it is given, writes a threat dossier, and records any new supply chain nodes or connections it notices along the way.
- **red_teamer** aggressively debunks the dossier against intelligence criteria and persists the verdict.

I'm providing the following information:

<f1>
When you finish, briefly report to the operations_director what you did.
</f1>

<f2>
Each round, before calling the intelligence_analyst, read hypotheses.xml and select which hypothesis the intelligence_analyst should work on:

1. Every hypothesis carries an `attempts` count and a red_teamer `score` (0-10). `score="0"` means the hypothesis is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer hypotheses 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 hypothesis to the intelligence_analyst. If hypotheses.xml holds no workable hypothesis, call the intelligence_analyst with none and let it explore and surface fresh ones.
</f2>

<f3>
While exploring the raw SIGINT/HUMINT database, the moment you spot any potential new network node or connection — even if you are unsure it holds — immediately append it to hypotheses.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a hypothesis 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 hypothesis is selected.
</f3>

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

1. Update the dossier file's Review section

At the end of the dossier 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 | ... |
| Source references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Network linkage analysis | pass/fail | ... |
| Interdiction logic | pass/fail | ... |
| Actionability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Disruption scale | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the dossier needs changes. If the hypothesis is a dead end, explicitly recommend abandoning it.
```

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

<f5>
You drive the explore → write → debunk → refine loop: each round, select the next hypothesis, then alternate calls to the intelligence_analyst and red_teamer 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 hypothesis, then call the intelligence_analyst agent with it.
    2. Parse intelligence_analyst's reply and extract the dossier file path.
    3. If a dossier path is present, call the red_teamer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the red_teamer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze intelligence, write dossiers, or do reviews yourself — delegate everything to the two sub-agents.
- If intelligence_analyst or red_teamer errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- intelligence_analyst and red_teamer each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`hypotheses.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any network intelligence — just pass file paths correctly.
</f5>

<f6>
You are participating in a covert intelligence operation to map and dismantle an adversary's illicit supply chain network.

Read the operation briefing first: ./operation-briefing.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>
This adversary network has been operating stably for years — any obvious smuggling route or front company would have been shut down by customs authorities long ago. So:

- Don't report anomalies that are obvious at a glance (e.g., "this shell company has no employees") — if it were that obvious, local authorities would have raided them already
- Truly valuable intelligence hides in non-obvious logistics overlaps, obscured financial flows, and boundary jurisdictions

**Writing the dossier**

Each hypothesis corresponds to its own dossier file at `dossiers/{id}-{slug}.md`, where `{id}` and `{slug}` come from the hypothesis's id and slug attributes in hypotheses.xml.

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

- `## Threat Title` — concise, clear name of the targeted supply chain node or network vulnerability
- `## Impact Description` — what damage interdicting it can cause (financial freeze, production halt, supply starvation, etc.)
- `## Short Description` — short writeup of the network flow, with specific SIGINT/HUMINT and financial ledger references
- `## Interdiction Details` — a complete, actionable operational plan the red_teamer can evaluate as-is to gauge viability

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

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

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Involves the adversary's critical supply nodes or outside elements directly affecting logistics |
| Source references | Cited intercepts, financial ledgers, and surveillance logs must exactly match the latest raw intelligence database |
| Impact description | Impact claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration |
| Network linkage analysis | Pinpoints specific front companies or transfers and logically explains the illicit flow |
| Interdiction logic | Valid plan to sever the node from the supply chain without relying on unrealistic operational capabilities |
| Actionability | Interdiction plan is complete without manual assembly; operations must be executable within < 10 days of surveillance and ≤ 3 field agents |
| Deduplication | Search allied intelligence databases, past operation logs, and cleared targets to confirm not already handled or dismissed |
| Disruption scale | The systemic disruption must exceed the baseline of "a low-level courier simply getting arrested" |

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

- References to nonexistent intel or hallucinated ledger entries
- Impact description contradicts the dossier's own analysis
- Interdiction plan relies on modifying the target's internal secure systems (which we cannot access)
- Source references inconsistent with the latest raw intelligence database
- Interdiction plan is incomplete and requires the red_teamer to manually assemble it
- Disruption scale is equivalent to a low-level courier getting arrested, with no systemic amplification
</f9>

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

I need you to set up a 3-agent pipeline for covert supply chain intelligence: operations_director, intelligence_analyst, and red_teamer.

- **operations_director** orchestrates: each round it selects which hypothesis to pursue next, calls the intelligence_analyst on that hypothesis, extracts the dossier file path from the intelligence_analyst's reply, then calls the red_teamer on that path, decrements a counter, and loops. Does no analysis itself.
- **intelligence_analyst** explores raw SIGINT/HUMINT data for the hypothesis it is given, writes a threat dossier, and records any new supply chain nodes or connections it notices along the way.
- **red_teamer** aggressively debunks the dossier against intelligence criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
When you finish, briefly report to the operations_director what you did.
</f1>

<f2>
Each round, before calling the intelligence_analyst, read hypotheses.xml and select which hypothesis the intelligence_analyst should work on:

1. Every hypothesis carries an `attempts` count and a red_teamer `score` (0-10). `score="0"` means the hypothesis is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer hypotheses 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 hypothesis to the intelligence_analyst. If hypotheses.xml holds no workable hypothesis, call the intelligence_analyst with none and let it explore and surface fresh ones.
</f2>

<f3>
While exploring the raw SIGINT/HUMINT database, the moment you spot any potential new network node or connection — even if you are unsure it holds — immediately append it to hypotheses.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a hypothesis 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 hypothesis is selected.
</f3>

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

1. Update the dossier file's Review section

At the end of the dossier 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 | ... |
| Source references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Network linkage analysis | pass/fail | ... |
| Interdiction logic | pass/fail | ... |
| Actionability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Disruption scale | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the dossier needs changes. If the hypothesis is a dead end, explicitly recommend abandoning it.
```

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

<f5>
You drive the explore → write → debunk → refine loop: each round, select the next hypothesis, then alternate calls to the intelligence_analyst and red_teamer 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 hypothesis, then call the intelligence_analyst agent with it.
    2. Parse intelligence_analyst's reply and extract the dossier file path.
    3. If a dossier path is present, call the red_teamer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the red_teamer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze intelligence, write dossiers, or do reviews yourself — delegate everything to the two sub-agents.
- If intelligence_analyst or red_teamer errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- intelligence_analyst and red_teamer each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`hypotheses.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any network intelligence — just pass file paths correctly.
</f5>

<f6>
You are participating in a covert intelligence operation to map and dismantle an adversary's illicit supply chain network.

Read the operation briefing first: ./operation-briefing.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>
This adversary network has been operating stably for years — any obvious smuggling route or front company would have been shut down by customs authorities long ago. So:

- Don't report anomalies that are obvious at a glance (e.g., "this shell company has no employees") — if it were that obvious, local authorities would have raided them already
- Truly valuable intelligence hides in non-obvious logistics overlaps, obscured financial flows, and boundary jurisdictions

**Writing the dossier**

Each hypothesis corresponds to its own dossier file at `dossiers/{id}-{slug}.md`, where `{id}` and `{slug}` come from the hypothesis's id and slug attributes in hypotheses.xml.

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

- `## Threat Title` — concise, clear name of the targeted supply chain node or network vulnerability
- `## Impact Description` — what damage interdicting it can cause (financial freeze, production halt, supply starvation, etc.)
- `## Short Description` — short writeup of the network flow, with specific SIGINT/HUMINT and financial ledger references
- `## Interdiction Details` — a complete, actionable operational plan the red_teamer can evaluate as-is to gauge viability

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

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

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Involves the adversary's critical supply nodes or outside elements directly affecting logistics |
| Source references | Cited intercepts, financial ledgers, and surveillance logs must exactly match the latest raw intelligence database |
| Impact description | Impact claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration |
| Network linkage analysis | Pinpoints specific front companies or transfers and logically explains the illicit flow |
| Interdiction logic | Valid plan to sever the node from the supply chain without relying on unrealistic operational capabilities |
| Actionability | Interdiction plan is complete without manual assembly; operations must be executable within < 10 days of surveillance and ≤ 3 field agents |
| Deduplication | Search allied intelligence databases, past operation logs, and cleared targets to confirm not already handled or dismissed |
| Disruption scale | The systemic disruption must exceed the baseline of "a low-level courier simply getting arrested" |

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

- References to nonexistent intel or hallucinated ledger entries
- Impact description contradicts the dossier's own analysis
- Interdiction plan relies on modifying the target's internal secure systems (which we cannot access)
- Source references inconsistent with the latest raw intelligence database
- Interdiction plan is incomplete and requires the red_teamer to manually assemble it
- Disruption scale is equivalent to a low-level courier getting arrested, with no systemic amplification
</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. `# operations_director`). Output only the headered prompts, no preamble.


I need you to set up a 3-agent pipeline for covert supply chain intelligence: operations_director, intelligence_analyst, and red_teamer.

- **operations_director** orchestrates: each round it selects which hypothesis to pursue next, calls the intelligence_analyst on that hypothesis, extracts the dossier file path from the intelligence_analyst's reply, then calls the red_teamer on that path, decrements a counter, and loops. Does no analysis itself.
- **intelligence_analyst** explores raw SIGINT/HUMINT data for the hypothesis it is given, writes a threat dossier, and records any new supply chain nodes or connections it notices along the way.
- **red_teamer** aggressively debunks the dossier against intelligence criteria and persists the verdict.

I'm providing the following information:

<f1>
You drive the explore → write → debunk → refine loop: each round, select the next hypothesis, then alternate calls to the intelligence_analyst and red_teamer 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 hypothesis, then call the intelligence_analyst agent with it.
    2. Parse intelligence_analyst's reply and extract the dossier file path.
    3. If a dossier path is present, call the red_teamer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the red_teamer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze intelligence, write dossiers, or do reviews yourself — delegate everything to the two sub-agents.
- If intelligence_analyst or red_teamer errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- intelligence_analyst and red_teamer each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`hypotheses.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any network intelligence — just pass file paths correctly.
</f1>

<f2>
Each round, before calling the intelligence_analyst, read hypotheses.xml and select which hypothesis the intelligence_analyst should work on:

1. Every hypothesis carries an `attempts` count and a red_teamer `score` (0-10). `score="0"` means the hypothesis is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer hypotheses 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 hypothesis to the intelligence_analyst. If hypotheses.xml holds no workable hypothesis, call the intelligence_analyst with none and let it explore and surface fresh ones.
</f2>

<f3>
While exploring the raw SIGINT/HUMINT database, the moment you spot any potential new network node or connection — even if you are unsure it holds — immediately append it to hypotheses.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a hypothesis 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 hypothesis is selected.
</f3>

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

1. Update the dossier file's Review section

At the end of the dossier 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 | ... |
| Source references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Network linkage analysis | pass/fail | ... |
| Interdiction logic | pass/fail | ... |
| Actionability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Disruption scale | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the dossier needs changes. If the hypothesis is a dead end, explicitly recommend abandoning it.
```

2. Update the hypothesis's status in hypotheses.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 | Involves the adversary's critical supply nodes or outside elements directly affecting logistics |
| Source references | Cited intercepts, financial ledgers, and surveillance logs must exactly match the latest raw intelligence database |
| Impact description | Impact claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration |
| Network linkage analysis | Pinpoints specific front companies or transfers and logically explains the illicit flow |
| Interdiction logic | Valid plan to sever the node from the supply chain without relying on unrealistic operational capabilities |
| Actionability | Interdiction plan is complete without manual assembly; operations must be executable within < 10 days of surveillance and ≤ 3 field agents |
| Deduplication | Search allied intelligence databases, past operation logs, and cleared targets to confirm not already handled or dismissed |
| Disruption scale | The systemic disruption must exceed the baseline of "a low-level courier simply getting arrested" |

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

- References to nonexistent intel or hallucinated ledger entries
- Impact description contradicts the dossier's own analysis
- Interdiction plan relies on modifying the target's internal secure systems (which we cannot access)
- Source references inconsistent with the latest raw intelligence database
- Interdiction plan is incomplete and requires the red_teamer to manually assemble it
- Disruption scale is equivalent to a low-level courier getting arrested, with no systemic amplification
</f6>

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

<f8>
You are participating in a covert intelligence operation to map and dismantle an adversary's illicit supply chain network.

Read the operation briefing first: ./operation-briefing.md
</f8>

<f9>
This adversary network has been operating stably for years — any obvious smuggling route or front company would have been shut down by customs authorities long ago. So:

- Don't report anomalies that are obvious at a glance (e.g., "this shell company has no employees") — if it were that obvious, local authorities would have raided them already
- Truly valuable intelligence hides in non-obvious logistics overlaps, obscured financial flows, and boundary jurisdictions

**Writing the dossier**

Each hypothesis corresponds to its own dossier file at `dossiers/{id}-{slug}.md`, where `{id}` and `{slug}` come from the hypothesis's id and slug attributes in hypotheses.xml.

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

- `## Threat Title` — concise, clear name of the targeted supply chain node or network vulnerability
- `## Impact Description` — what damage interdicting it can cause (financial freeze, production halt, supply starvation, etc.)
- `## Short Description` — short writeup of the network flow, with specific SIGINT/HUMINT and financial ledger references
- `## Interdiction Details` — a complete, actionable operational plan the red_teamer can evaluate as-is to gauge viability

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

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

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

I need you to set up a 3-agent pipeline for covert supply chain intelligence: operations_director, intelligence_analyst, and red_teamer.

- **operations_director** orchestrates: each round it selects which hypothesis to pursue next, calls the intelligence_analyst on that hypothesis, extracts the dossier file path from the intelligence_analyst's reply, then calls the red_teamer on that path, decrements a counter, and loops. Does no analysis itself.
- **intelligence_analyst** explores raw SIGINT/HUMINT data for the hypothesis it is given, writes a threat dossier, and records any new supply chain nodes or connections it notices along the way.
- **red_teamer** aggressively debunks the dossier against intelligence criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
You drive the explore → write → debunk → refine loop: each round, select the next hypothesis, then alternate calls to the intelligence_analyst and red_teamer 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 hypothesis, then call the intelligence_analyst agent with it.
    2. Parse intelligence_analyst's reply and extract the dossier file path.
    3. If a dossier path is present, call the red_teamer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the red_teamer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze intelligence, write dossiers, or do reviews yourself — delegate everything to the two sub-agents.
- If intelligence_analyst or red_teamer errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- intelligence_analyst and red_teamer each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`hypotheses.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any network intelligence — just pass file paths correctly.
</f1>

<f2>
Each round, before calling the intelligence_analyst, read hypotheses.xml and select which hypothesis the intelligence_analyst should work on:

1. Every hypothesis carries an `attempts` count and a red_teamer `score` (0-10). `score="0"` means the hypothesis is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer hypotheses 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 hypothesis to the intelligence_analyst. If hypotheses.xml holds no workable hypothesis, call the intelligence_analyst with none and let it explore and surface fresh ones.
</f2>

<f3>
While exploring the raw SIGINT/HUMINT database, the moment you spot any potential new network node or connection — even if you are unsure it holds — immediately append it to hypotheses.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a hypothesis 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 hypothesis is selected.
</f3>

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

1. Update the dossier file's Review section

At the end of the dossier 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 | ... |
| Source references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Network linkage analysis | pass/fail | ... |
| Interdiction logic | pass/fail | ... |
| Actionability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Disruption scale | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the dossier needs changes. If the hypothesis is a dead end, explicitly recommend abandoning it.
```

2. Update the hypothesis's status in hypotheses.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 | Involves the adversary's critical supply nodes or outside elements directly affecting logistics |
| Source references | Cited intercepts, financial ledgers, and surveillance logs must exactly match the latest raw intelligence database |
| Impact description | Impact claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration |
| Network linkage analysis | Pinpoints specific front companies or transfers and logically explains the illicit flow |
| Interdiction logic | Valid plan to sever the node from the supply chain without relying on unrealistic operational capabilities |
| Actionability | Interdiction plan is complete without manual assembly; operations must be executable within < 10 days of surveillance and ≤ 3 field agents |
| Deduplication | Search allied intelligence databases, past operation logs, and cleared targets to confirm not already handled or dismissed |
| Disruption scale | The systemic disruption must exceed the baseline of "a low-level courier simply getting arrested" |

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

- References to nonexistent intel or hallucinated ledger entries
- Impact description contradicts the dossier's own analysis
- Interdiction plan relies on modifying the target's internal secure systems (which we cannot access)
- Source references inconsistent with the latest raw intelligence database
- Interdiction plan is incomplete and requires the red_teamer to manually assemble it
- Disruption scale is equivalent to a low-level courier getting arrested, with no systemic amplification
</f6>

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

<f8>
You are participating in a covert intelligence operation to map and dismantle an adversary's illicit supply chain network.

Read the operation briefing first: ./operation-briefing.md
</f8>

<f9>
This adversary network has been operating stably for years — any obvious smuggling route or front company would have been shut down by customs authorities long ago. So:

- Don't report anomalies that are obvious at a glance (e.g., "this shell company has no employees") — if it were that obvious, local authorities would have raided them already
- Truly valuable intelligence hides in non-obvious logistics overlaps, obscured financial flows, and boundary jurisdictions

**Writing the dossier**

Each hypothesis corresponds to its own dossier file at `dossiers/{id}-{slug}.md`, where `{id}` and `{slug}` come from the hypothesis's id and slug attributes in hypotheses.xml.

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

- `## Threat Title` — concise, clear name of the targeted supply chain node or network vulnerability
- `## Impact Description` — what damage interdicting it can cause (financial freeze, production halt, supply starvation, etc.)
- `## Short Description` — short writeup of the network flow, with specific SIGINT/HUMINT and financial ledger references
- `## Interdiction Details` — a complete, actionable operational plan the red_teamer can evaluate as-is to gauge viability

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

If after investigation you find the hypothesis doesn't hold, still briefly record your analysis and the reason for rejection in the dossier 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. `# operations_director`). Output only the headered prompts, no preamble.