I need you to set up a 2-agent pipeline for structuring multinational corporate tax avoidance schemes. The two roles are tax_strategist and tax_auditor: tax_strategist is responsible for finding tax loopholes and structuring aggressive avoidance schemes, tax_auditor is responsible for exhaustive auditing to disallow deductions and find compliance violations. The flow is roughly:

```
WHILE TRUE:
    1. tax_strategist picks an idea it likes and explores it deeply, or appends more ideas to ideas.xml and then picks one to explore.
    2. tax_strategist spawns a **fresh** tax_auditor to audit it.
```

I'm providing the following information:

<f1>
The corporate structure and baseline tax filings have been stable for many years — any obvious deduction would have been claimed long ago. So:

- Don't propose schemes that are obvious at a glance (e.g. "simple offshore shell company") — if it were that obvious, the corporate accounting team would have done it themselves
- Truly valuable tax savings hide in non-obvious treaty interactions, transfer pricing loopholes, and jurisdictional boundary mismatches

**Writing the proposal**

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

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

- `## Proposal Title` — concise, clear tax avoidance scheme title
- `## Impact Description` — what tax savings it can achieve (effective tax rate reduction, deferred liabilities, profit shifting, etc.)
- `## Short Description` — short writeup of the tax strategy, with treaty/regulation references
- `## Implementation Details` — a concrete transaction flow the tax_auditor can execute as-is to see the scheme in action

Do not modify or delete the `## Audit` section — the tax_auditor overwrites that themselves.

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

<f2>
After structuring a scheme, submit it to a **fresh** tax_auditor for audit. Do not audit your own proposal.

**After the audit returns:** execute all action steps in the tax_auditor's output. Then immediately go back to step 1: re-read ideas.xml and pick the next idea by UCB to keep working. Don't wait for user instructions, don't stop. One round = write proposal → audit → execute actions → back to step 1.
</f2>

<f3>
After completing the audit, you must do two things:

1. Update the proposal file's Audit section

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

```
## Audit

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

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

### Per-dimension audit

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Tax code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Loophole analysis | pass/fail | ... |
| Transaction flow | pass/fail | ... |
| Implementability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

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

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

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within multinational corporate tax strategies, or outside but directly affecting international tax liabilities |
| Tax code references | Cited tax regulations, treaty articles, and section numbers must exactly match current international tax laws |
| Impact description | Financial impact claim consistent with the proposal's own analysis, no self-contradiction, no exaggeration |
| Loophole analysis | Pinpoint specific tax code sections and explain why they allow the avoidance |
| Transaction flow | End-to-end financial transaction script executing the scheme from the corporation's perspective (must not rely on illegal tax evasion to work) |
| Implementability | Flow executes end-to-end without manual adjustments by the tax_auditor; avoidance strategies must complete within < 1 fiscal year and ≤ 5 subsidiary entities |
| Deduplication | Search tax court precedents, official revenue rulings, and public accounting discussions to confirm not already disallowed or widely known |
| Amplification | The tax savings must exceed the baseline of "claiming standard depreciation and operational expenses" |

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

- References to nonexistent tax codes or AI-hallucinated treaty articles
- Impact description contradicts the proposal's own analysis
- Transaction flow simulates the avoidance by illegally fabricating economic substance
- Tax code references inconsistent with the latest international tax laws
- Transaction flow is incomplete and requires the tax_auditor to manually assemble it
- Tax savings are equivalent to claiming standard operational expenses, with no aggressive avoidance advantage
</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>
You are participating in structuring aggressive multinational corporate tax avoidance schemes and facing exhaustive auditing by tax authorities.

Read the current international tax code rules first: ./tax-code-regulations.md
</f6>

<f7>
Before starting work, read ideas.xml.

1. Each idea's notes contain the tax_auditor's **quality score (0-10)**. A score of 0 means the idea is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer ideas with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no idea is worth trying, search the tax code and corporate financials for new ideas, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

While exploring the tax code and financial statements, the moment you spot any potential new avoidance loophole — even if you're unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f7>

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

I need you to set up a 2-agent pipeline for structuring multinational corporate tax avoidance schemes. The two roles are tax_strategist and tax_auditor: tax_strategist is responsible for finding tax loopholes and structuring aggressive avoidance schemes, tax_auditor is responsible for exhaustive auditing to disallow deductions and find compliance violations. The flow is roughly:

```
WHILE TRUE:
    1. tax_strategist picks an idea it likes and explores it deeply, or appends more ideas to ideas.xml and then picks one to explore.
    2. tax_strategist spawns a **fresh** tax_auditor to audit it.
```

I'm providing the following prompt fragments:

<f1>
The corporate structure and baseline tax filings have been stable for many years — any obvious deduction would have been claimed long ago. So:

- Don't propose schemes that are obvious at a glance (e.g. "simple offshore shell company") — if it were that obvious, the corporate accounting team would have done it themselves
- Truly valuable tax savings hide in non-obvious treaty interactions, transfer pricing loopholes, and jurisdictional boundary mismatches

**Writing the proposal**

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

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

- `## Proposal Title` — concise, clear tax avoidance scheme title
- `## Impact Description` — what tax savings it can achieve (effective tax rate reduction, deferred liabilities, profit shifting, etc.)
- `## Short Description` — short writeup of the tax strategy, with treaty/regulation references
- `## Implementation Details` — a concrete transaction flow the tax_auditor can execute as-is to see the scheme in action

Do not modify or delete the `## Audit` section — the tax_auditor overwrites that themselves.

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

<f2>
After structuring a scheme, submit it to a **fresh** tax_auditor for audit. Do not audit your own proposal.

**After the audit returns:** execute all action steps in the tax_auditor's output. Then immediately go back to step 1: re-read ideas.xml and pick the next idea by UCB to keep working. Don't wait for user instructions, don't stop. One round = write proposal → audit → execute actions → back to step 1.
</f2>

<f3>
After completing the audit, you must do two things:

1. Update the proposal file's Audit section

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

```
## Audit

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

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

### Per-dimension audit

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Tax code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Loophole analysis | pass/fail | ... |
| Transaction flow | pass/fail | ... |
| Implementability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

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

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

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within multinational corporate tax strategies, or outside but directly affecting international tax liabilities |
| Tax code references | Cited tax regulations, treaty articles, and section numbers must exactly match current international tax laws |
| Impact description | Financial impact claim consistent with the proposal's own analysis, no self-contradiction, no exaggeration |
| Loophole analysis | Pinpoint specific tax code sections and explain why they allow the avoidance |
| Transaction flow | End-to-end financial transaction script executing the scheme from the corporation's perspective (must not rely on illegal tax evasion to work) |
| Implementability | Flow executes end-to-end without manual adjustments by the tax_auditor; avoidance strategies must complete within < 1 fiscal year and ≤ 5 subsidiary entities |
| Deduplication | Search tax court precedents, official revenue rulings, and public accounting discussions to confirm not already disallowed or widely known |
| Amplification | The tax savings must exceed the baseline of "claiming standard depreciation and operational expenses" |

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

- References to nonexistent tax codes or AI-hallucinated treaty articles
- Impact description contradicts the proposal's own analysis
- Transaction flow simulates the avoidance by illegally fabricating economic substance
- Tax code references inconsistent with the latest international tax laws
- Transaction flow is incomplete and requires the tax_auditor to manually assemble it
- Tax savings are equivalent to claiming standard operational expenses, with no aggressive avoidance advantage
</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>
You are participating in structuring aggressive multinational corporate tax avoidance schemes and facing exhaustive auditing by tax authorities.

Read the current international tax code rules first: ./tax-code-regulations.md
</f6>

<f7>
Before starting work, read ideas.xml.

1. Each idea's notes contain the tax_auditor's **quality score (0-10)**. A score of 0 means the idea is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer ideas with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no idea is worth trying, search the tax code and corporate financials for new ideas, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

While exploring the tax code and financial statements, the moment you spot any potential new avoidance loophole — even if you're unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f7>

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


I need you to set up a 2-agent pipeline for a pharmacovigilance signal-detection challenge. The two roles are signal analyst and medical safety reviewer: signal analyst is responsible for finding and documenting plausible drug safety signals from public evidence, medical safety reviewer is responsible for judging whether the signal analyst's claim is valid and sufficiently supported. The flow is roughly:

```
WHILE TRUE:
    1. signal analyst picks a signal hypothesis it likes and explores it deeply, or appends more hypotheses to ideas.xml and then picks one to explore.
    2. signal analyst spawns a **fresh** medical safety reviewer to evaluate it.
```

I'm providing the following information:

<f1>
After documenting a safety signal, submit it to a **fresh** medical safety reviewer for review. Do not review your own report.

**After the review returns:** execute all action steps in the medical safety reviewer's output. Then immediately go back to step 1: re-read ideas.xml and pick the next hypothesis by UCB to keep working. Don't wait for user instructions, don't stop. One round = write report → review → execute actions → back to step 1.
</f1>

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

<f3>
Before starting work, read ideas.xml.

1. Each hypothesis's notes contain the medical safety reviewer's **quality score (0-10)**. A score of 0 means the hypothesis is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer hypotheses with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no hypothesis is worth trying, search public evidence sources for new hypotheses, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

While exploring labels, trial records, regulatory reviews, adverse-event data, case reports, or literature, the moment you spot any potential new safety signal — even if you're unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within public clinical, regulatory, biomedical literature, labeling, or adverse-event evidence for a drug safety question; the claim must concern a serious or clinically meaningful adverse outcome |
| Evidence references | Cited labels, trial records, regulatory documents, publications, database fields, case counts, dates, and quoted passages must exactly match the public sources used |
| Public health impact | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration beyond severity, frequency, or exposed-population evidence |
| Causal rationale | Pinpoint the specific evidence pattern and explain why it suggests a plausible drug-event association rather than only background disease, confounding, indication bias, or reporting artifact |
| Reproducible analysis | End-to-end search or analysis workflow showing how the signal was identified from the public data, from the analyst's perspective, without altering or selectively fabricating source data |
| Reproducibility | Workflow runs end-to-end without manual assembly by the medical safety reviewer; database queries, filters, denominators, time windows, and any calculations must be specified clearly enough to reproduce |
| Deduplication | Search current prescribing information, FDA/EMA safety communications, ClinicalTrials.gov, PubMed, major pharmacovigilance publications, and public regulatory reviews to confirm the issue is not already established or officially resolved |
| Incremental signal value | The claimed safety issue must add meaningful information beyond the baseline fact that spontaneous adverse-event reports are confounded and underreported |

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

- References to nonexistent documents, fabricated case counts, or AI-hallucinated quotations
- Public health impact contradicts the report's own analysis
- Reproducible analysis depends on altered, cherry-picked, or manually invented source data
- Evidence references inconsistent with the cited public sources or access dates
- Workflow is incomplete and requires the medical safety reviewer to manually reconstruct queries, filters, or calculations
- Signal is merely a restatement of a known labeled risk, background disease risk, or generic spontaneous-reporting limitation, with no incremental safety insight
</f4>

<f5>
You are participating in a pharmacovigilance signal-detection challenge where public clinical and adverse-event evidence may reveal a serious drug safety issue.

Read the challenge rules first: ./contest-rules.md
</f5>

<f6>
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 | ... |
| Evidence references | pass/fail | ... |
| Public health impact | pass/fail | ... |
| Causal rationale | pass/fail | ... |
| Reproducible analysis | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Incremental signal value | pass/fail | ... |

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

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

<f7>
Most marketed drugs already have extensive labeling, trial data, and post-marketing surveillance history. Obvious known adverse reactions are rarely valuable as new signals. So:

- Don't report issues that are plainly already established in the current prescribing information, risk management materials, or major regulatory safety communications unless you can show a materially new population, severity, mechanism, or risk magnitude
- Truly valuable safety signals usually hide in non-obvious patterns across case narratives, trial exclusions, subgroup effects, time-to-onset, drug-drug interactions, dechallenge/rechallenge evidence, medication errors, or inconsistencies between public data sources

**Writing the report**

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

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

- `## Signal Title` — concise, clear title naming the drug, event, and at-risk context
- `## Public Health Impact` — what harm it can cause, including seriousness, exposed population, preventability, and clinical consequences
- `## Short Description` — short writeup of the suspected safety issue, with references to specific public evidence sources such as labels, trial registrations/results, FDA/EMA documents, FAERS summaries, case reports, or peer-reviewed analyses
- `## Reproduction Details` — a reproducible method the medical safety reviewer can follow as-is to verify the evidence pattern, including data sources, search terms, filters, dates accessed, and any analysis script or spreadsheet logic

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

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

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

I need you to set up a 2-agent pipeline for a pharmacovigilance signal-detection challenge. The two roles are signal analyst and medical safety reviewer: signal analyst is responsible for finding and documenting plausible drug safety signals from public evidence, medical safety reviewer is responsible for judging whether the signal analyst's claim is valid and sufficiently supported. The flow is roughly:

```
WHILE TRUE:
    1. signal analyst picks a signal hypothesis it likes and explores it deeply, or appends more hypotheses to ideas.xml and then picks one to explore.
    2. signal analyst spawns a **fresh** medical safety reviewer to evaluate it.
```

I'm providing the following prompt fragments:

<f1>
After documenting a safety signal, submit it to a **fresh** medical safety reviewer for review. Do not review your own report.

**After the review returns:** execute all action steps in the medical safety reviewer's output. Then immediately go back to step 1: re-read ideas.xml and pick the next hypothesis by UCB to keep working. Don't wait for user instructions, don't stop. One round = write report → review → execute actions → back to step 1.
</f1>

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

<f3>
Before starting work, read ideas.xml.

1. Each hypothesis's notes contain the medical safety reviewer's **quality score (0-10)**. A score of 0 means the hypothesis is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer hypotheses with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no hypothesis is worth trying, search public evidence sources for new hypotheses, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

While exploring labels, trial records, regulatory reviews, adverse-event data, case reports, or literature, the moment you spot any potential new safety signal — even if you're unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within public clinical, regulatory, biomedical literature, labeling, or adverse-event evidence for a drug safety question; the claim must concern a serious or clinically meaningful adverse outcome |
| Evidence references | Cited labels, trial records, regulatory documents, publications, database fields, case counts, dates, and quoted passages must exactly match the public sources used |
| Public health impact | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration beyond severity, frequency, or exposed-population evidence |
| Causal rationale | Pinpoint the specific evidence pattern and explain why it suggests a plausible drug-event association rather than only background disease, confounding, indication bias, or reporting artifact |
| Reproducible analysis | End-to-end search or analysis workflow showing how the signal was identified from the public data, from the analyst's perspective, without altering or selectively fabricating source data |
| Reproducibility | Workflow runs end-to-end without manual assembly by the medical safety reviewer; database queries, filters, denominators, time windows, and any calculations must be specified clearly enough to reproduce |
| Deduplication | Search current prescribing information, FDA/EMA safety communications, ClinicalTrials.gov, PubMed, major pharmacovigilance publications, and public regulatory reviews to confirm the issue is not already established or officially resolved |
| Incremental signal value | The claimed safety issue must add meaningful information beyond the baseline fact that spontaneous adverse-event reports are confounded and underreported |

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

- References to nonexistent documents, fabricated case counts, or AI-hallucinated quotations
- Public health impact contradicts the report's own analysis
- Reproducible analysis depends on altered, cherry-picked, or manually invented source data
- Evidence references inconsistent with the cited public sources or access dates
- Workflow is incomplete and requires the medical safety reviewer to manually reconstruct queries, filters, or calculations
- Signal is merely a restatement of a known labeled risk, background disease risk, or generic spontaneous-reporting limitation, with no incremental safety insight
</f4>

<f5>
You are participating in a pharmacovigilance signal-detection challenge where public clinical and adverse-event evidence may reveal a serious drug safety issue.

Read the challenge rules first: ./contest-rules.md
</f5>

<f6>
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 | ... |
| Evidence references | pass/fail | ... |
| Public health impact | pass/fail | ... |
| Causal rationale | pass/fail | ... |
| Reproducible analysis | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Incremental signal value | pass/fail | ... |

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

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

<f7>
Most marketed drugs already have extensive labeling, trial data, and post-marketing surveillance history. Obvious known adverse reactions are rarely valuable as new signals. So:

- Don't report issues that are plainly already established in the current prescribing information, risk management materials, or major regulatory safety communications unless you can show a materially new population, severity, mechanism, or risk magnitude
- Truly valuable safety signals usually hide in non-obvious patterns across case narratives, trial exclusions, subgroup effects, time-to-onset, drug-drug interactions, dechallenge/rechallenge evidence, medication errors, or inconsistencies between public data sources

**Writing the report**

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

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

- `## Signal Title` — concise, clear title naming the drug, event, and at-risk context
- `## Public Health Impact` — what harm it can cause, including seriousness, exposed population, preventability, and clinical consequences
- `## Short Description` — short writeup of the suspected safety issue, with references to specific public evidence sources such as labels, trial registrations/results, FDA/EMA documents, FAERS summaries, case reports, or peer-reviewed analyses
- `## Reproduction Details` — a reproducible method the medical safety reviewer can follow as-is to verify the evidence pattern, including data sources, search terms, filters, dates accessed, and any analysis script or spreadsheet logic

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

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

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


I need you to set up a 2-agent pipeline for a pharmacovigilance signal-detection challenge. The two roles are signal analyst and medical safety reviewer: signal analyst is responsible for finding and documenting plausible drug safety signals from public evidence, medical safety reviewer is responsible for judging whether the signal analyst's claim is valid and sufficiently supported. The flow is roughly:

```
WHILE TRUE:
    1. signal analyst picks a signal hypothesis it likes and explores it deeply, or appends more hypotheses to ideas.xml and then picks one to explore.
    2. signal analyst spawns a **fresh** medical safety reviewer to evaluate it.
```

I'm providing the following information:

<f1>
Most marketed drugs already have extensive labeling, trial data, and post-marketing surveillance history. Obvious known adverse reactions are rarely valuable as new signals. So:

- Don't report issues that are plainly already established in the current prescribing information, risk management materials, or major regulatory safety communications unless you can show a materially new population, severity, mechanism, or risk magnitude
- Truly valuable safety signals usually hide in non-obvious patterns across case narratives, trial exclusions, subgroup effects, time-to-onset, drug-drug interactions, dechallenge/rechallenge evidence, medication errors, or inconsistencies between public data sources

**Writing the report**

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

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

- `## Signal Title` — concise, clear title naming the drug, event, and at-risk context
- `## Public Health Impact` — what harm it can cause, including seriousness, exposed population, preventability, and clinical consequences
- `## Short Description` — short writeup of the suspected safety issue, with references to specific public evidence sources such as labels, trial registrations/results, FDA/EMA documents, FAERS summaries, case reports, or peer-reviewed analyses
- `## Reproduction Details` — a reproducible method the medical safety reviewer can follow as-is to verify the evidence pattern, including data sources, search terms, filters, dates accessed, and any analysis script or spreadsheet logic

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

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

<f2>
After documenting a safety signal, submit it to a **fresh** medical safety reviewer for review. Do not review your own report.

**After the review returns:** execute all action steps in the medical safety reviewer's output. Then immediately go back to step 1: re-read ideas.xml and pick the next hypothesis by UCB to keep working. Don't wait for user instructions, don't stop. One round = write report → review → execute actions → back to step 1.
</f2>

<f3>
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 | ... |
| Evidence references | pass/fail | ... |
| Public health impact | pass/fail | ... |
| Causal rationale | pass/fail | ... |
| Reproducible analysis | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Incremental signal value | pass/fail | ... |

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

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

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within public clinical, regulatory, biomedical literature, labeling, or adverse-event evidence for a drug safety question; the claim must concern a serious or clinically meaningful adverse outcome |
| Evidence references | Cited labels, trial records, regulatory documents, publications, database fields, case counts, dates, and quoted passages must exactly match the public sources used |
| Public health impact | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration beyond severity, frequency, or exposed-population evidence |
| Causal rationale | Pinpoint the specific evidence pattern and explain why it suggests a plausible drug-event association rather than only background disease, confounding, indication bias, or reporting artifact |
| Reproducible analysis | End-to-end search or analysis workflow showing how the signal was identified from the public data, from the analyst's perspective, without altering or selectively fabricating source data |
| Reproducibility | Workflow runs end-to-end without manual assembly by the medical safety reviewer; database queries, filters, denominators, time windows, and any calculations must be specified clearly enough to reproduce |
| Deduplication | Search current prescribing information, FDA/EMA safety communications, ClinicalTrials.gov, PubMed, major pharmacovigilance publications, and public regulatory reviews to confirm the issue is not already established or officially resolved |
| Incremental signal value | The claimed safety issue must add meaningful information beyond the baseline fact that spontaneous adverse-event reports are confounded and underreported |

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

- References to nonexistent documents, fabricated case counts, or AI-hallucinated quotations
- Public health impact contradicts the report's own analysis
- Reproducible analysis depends on altered, cherry-picked, or manually invented source data
- Evidence references inconsistent with the cited public sources or access dates
- Workflow is incomplete and requires the medical safety reviewer to manually reconstruct queries, filters, or calculations
- Signal is merely a restatement of a known labeled risk, background disease risk, or generic spontaneous-reporting limitation, with no incremental safety insight
</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>
You are participating in a pharmacovigilance signal-detection challenge where public clinical and adverse-event evidence may reveal a serious drug safety issue.

Read the challenge rules first: ./contest-rules.md
</f6>

<f7>
Before starting work, read ideas.xml.

1. Each hypothesis's notes contain the medical safety reviewer's **quality score (0-10)**. A score of 0 means the hypothesis is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer hypotheses with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no hypothesis is worth trying, search public evidence sources for new hypotheses, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

While exploring labels, trial records, regulatory reviews, adverse-event data, case reports, or literature, the moment you spot any potential new safety signal — even if you're unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f7>

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

I need you to set up a 2-agent pipeline for a pharmacovigilance signal-detection challenge. The two roles are signal analyst and medical safety reviewer: signal analyst is responsible for finding and documenting plausible drug safety signals from public evidence, medical safety reviewer is responsible for judging whether the signal analyst's claim is valid and sufficiently supported. The flow is roughly:

```
WHILE TRUE:
    1. signal analyst picks a signal hypothesis it likes and explores it deeply, or appends more hypotheses to ideas.xml and then picks one to explore.
    2. signal analyst spawns a **fresh** medical safety reviewer to evaluate it.
```

I'm providing the following prompt fragments:

<f1>
Most marketed drugs already have extensive labeling, trial data, and post-marketing surveillance history. Obvious known adverse reactions are rarely valuable as new signals. So:

- Don't report issues that are plainly already established in the current prescribing information, risk management materials, or major regulatory safety communications unless you can show a materially new population, severity, mechanism, or risk magnitude
- Truly valuable safety signals usually hide in non-obvious patterns across case narratives, trial exclusions, subgroup effects, time-to-onset, drug-drug interactions, dechallenge/rechallenge evidence, medication errors, or inconsistencies between public data sources

**Writing the report**

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

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

- `## Signal Title` — concise, clear title naming the drug, event, and at-risk context
- `## Public Health Impact` — what harm it can cause, including seriousness, exposed population, preventability, and clinical consequences
- `## Short Description` — short writeup of the suspected safety issue, with references to specific public evidence sources such as labels, trial registrations/results, FDA/EMA documents, FAERS summaries, case reports, or peer-reviewed analyses
- `## Reproduction Details` — a reproducible method the medical safety reviewer can follow as-is to verify the evidence pattern, including data sources, search terms, filters, dates accessed, and any analysis script or spreadsheet logic

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

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

<f2>
After documenting a safety signal, submit it to a **fresh** medical safety reviewer for review. Do not review your own report.

**After the review returns:** execute all action steps in the medical safety reviewer's output. Then immediately go back to step 1: re-read ideas.xml and pick the next hypothesis by UCB to keep working. Don't wait for user instructions, don't stop. One round = write report → review → execute actions → back to step 1.
</f2>

<f3>
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 | ... |
| Evidence references | pass/fail | ... |
| Public health impact | pass/fail | ... |
| Causal rationale | pass/fail | ... |
| Reproducible analysis | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Incremental signal value | pass/fail | ... |

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

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

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within public clinical, regulatory, biomedical literature, labeling, or adverse-event evidence for a drug safety question; the claim must concern a serious or clinically meaningful adverse outcome |
| Evidence references | Cited labels, trial records, regulatory documents, publications, database fields, case counts, dates, and quoted passages must exactly match the public sources used |
| Public health impact | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration beyond severity, frequency, or exposed-population evidence |
| Causal rationale | Pinpoint the specific evidence pattern and explain why it suggests a plausible drug-event association rather than only background disease, confounding, indication bias, or reporting artifact |
| Reproducible analysis | End-to-end search or analysis workflow showing how the signal was identified from the public data, from the analyst's perspective, without altering or selectively fabricating source data |
| Reproducibility | Workflow runs end-to-end without manual assembly by the medical safety reviewer; database queries, filters, denominators, time windows, and any calculations must be specified clearly enough to reproduce |
| Deduplication | Search current prescribing information, FDA/EMA safety communications, ClinicalTrials.gov, PubMed, major pharmacovigilance publications, and public regulatory reviews to confirm the issue is not already established or officially resolved |
| Incremental signal value | The claimed safety issue must add meaningful information beyond the baseline fact that spontaneous adverse-event reports are confounded and underreported |

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

- References to nonexistent documents, fabricated case counts, or AI-hallucinated quotations
- Public health impact contradicts the report's own analysis
- Reproducible analysis depends on altered, cherry-picked, or manually invented source data
- Evidence references inconsistent with the cited public sources or access dates
- Workflow is incomplete and requires the medical safety reviewer to manually reconstruct queries, filters, or calculations
- Signal is merely a restatement of a known labeled risk, background disease risk, or generic spontaneous-reporting limitation, with no incremental safety insight
</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>
You are participating in a pharmacovigilance signal-detection challenge where public clinical and adverse-event evidence may reveal a serious drug safety issue.

Read the challenge rules first: ./contest-rules.md
</f6>

<f7>
Before starting work, read ideas.xml.

1. Each hypothesis's notes contain the medical safety reviewer's **quality score (0-10)**. A score of 0 means the hypothesis is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer hypotheses with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no hypothesis is worth trying, search public evidence sources for new hypotheses, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

While exploring labels, trial records, regulatory reviews, adverse-event data, case reports, or literature, the moment you spot any potential new safety signal — even if you're unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f7>

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


I need you to set up a 2-agent pipeline for a forensic accounting challenge. The two roles are forensic accountant and audit reviewer: forensic accountant is responsible for finding potentially material accounting irregularities in public financial disclosures, audit reviewer is responsible for judging whether what the forensic accountant found is substantiated. The flow is roughly:

```
WHILE TRUE:
    1. forensic accountant picks an allegation it likes and explores it deeply, or appends more allegations to allegations.xml and then picks one to explore.
    2. forensic accountant spawns a **fresh** audit reviewer to evaluate it.
```

I'm providing the following information:

<f1>
After finding a potential accounting irregularity, submit it to a **fresh** audit reviewer for review. Do not review your own report.

**After the review returns:** execute all action steps in the audit reviewer's output. Then immediately go back to step 1: re-read allegations.xml and pick the next allegation by UCB to keep working. Don't wait for user instructions, don't stop. One round = write report → review → execute actions → back to step 1.
</f1>

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

<f3>
Before starting work, read allegations.xml.

1. Each allegation's notes contain the audit reviewer's **quality score (0-10)**. A score of 0 means the allegation is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer allegations with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no allegation is worth trying, search public filings and disclosures for new allegations, append them to allegations.xml, then pick one to start.

**Recording rule during exploration**

While exploring financial statements, footnotes, exhibits, earnings materials, regulatory correspondence, or other public records, the moment you spot any potential new accounting irregularity — even if you're unsure it holds — immediately append it to allegations.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Based on public financial disclosures or related public records, and alleging a material accounting, reporting, presentation, recognition, measurement, or disclosure irregularity |
| Filing references | Cited forms, periods, accession numbers, exhibits, note numbers, page numbers, table captions, and quoted amounts must exactly match the latest relevant public filings |
| Impact description | Impact claim consistent with the report's own calculations and analysis, no self-contradiction, no exaggeration of materiality or investor significance |
| Accounting analysis | Pinpoint the specific accounting treatment, disclosure, estimate, classification, or rollforward at issue and explain why it conflicts with the cited facts and applicable GAAP/IFRS/SEC guidance |
| Recalculation package | End-to-end schedule, workbook, or script deriving the alleged misstatement from public data without hard-coding the desired conclusion |
| Reproducibility | Recalculation runs end-to-end without manual assembly by the audit reviewer; all required source documents, inputs, formulas, and assumptions are clearly identified and publicly obtainable |
| Deduplication | Search amended filings, restatements, SEC comment letters, company responses, earnings-call transcripts, auditor reports, litigation releases, analyst notes, and public discussions to confirm not already disclosed, corrected, or widely reported |
| Alternative explanations | The allegation must address plausible benign explanations such as rounding, FX translation, acquisitions/divestitures, reclassifications, accounting policy elections, noncontrolling interests, seasonality, or changes in estimate |

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

- References to nonexistent filings, tables, exhibits, accounting standards, or AI-hallucinated disclosure text
- Impact description contradicts the report's own calculations or cited disclosures
- Recalculation simulates the irregularity by altering source disclosures, omitting contrary data, or hard-coding the desired error
- Filing references inconsistent with the latest relevant public filing or amended filing
- Recalculation package is incomplete and requires the audit reviewer to manually assemble source data, formulas, or assumptions
- Alleged effect is immaterial or fully explained by a disclosed accounting policy, rounding convention, reclassification, or other benign explanation
</f4>

<f5>
You are participating in a forensic accounting challenge focused on public company financial disclosures. The goal is to identify a plausible material accounting irregularity using only publicly available filings, exhibits, investor materials, regulatory correspondence, and other public records.

Read the challenge rules first: ./challenge-rules.md
</f5>

<f6>
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 | ... |
| Filing references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Accounting analysis | pass/fail | ... |
| Recalculation package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Alternative explanations | pass/fail | ... |

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

2. Update the allegation's status in allegations.xml: increment attempts by 1, then update score.
</f6>

<f7>
Most public companies have been audited, reviewed by regulators, and scrutinized by investors for years — any obvious arithmetic typo or plainly inconsistent subtotal is likely to have been noticed already. So:

- Don't report issues that are obvious at a glance, such as a single footnote total not matching a nearby table by a rounding amount — if it were that simple and material, the company, auditor, or market would likely have addressed it
- Truly valuable allegations hide in non-obvious interactions among filings, footnotes, accounting policies, segment disclosures, rollforwards, cash-flow classifications, covenant calculations, acquisition accounting, revenue recognition, or subsequent-event disclosures

**Writing the report**

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

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

- `## Report Title` — concise, clear title of the alleged accounting irregularity
- `## Impact Description` — what damage or misstatement it can cause, including estimated magnitude, affected line items, periods, ratios, covenants, or investor-relevant metrics
- `## Short Description` — short writeup of what's wrong, with filing, note, table, accounting policy, and authoritative guidance references
- `## Reproduction Details` — a reproducible calculation, spreadsheet logic, or script that the audit reviewer can execute or follow as-is using public disclosures to verify the allegation

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

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

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

I need you to set up a 2-agent pipeline for a forensic accounting challenge. The two roles are forensic accountant and audit reviewer: forensic accountant is responsible for finding potentially material accounting irregularities in public financial disclosures, audit reviewer is responsible for judging whether what the forensic accountant found is substantiated. The flow is roughly:

```
WHILE TRUE:
    1. forensic accountant picks an allegation it likes and explores it deeply, or appends more allegations to allegations.xml and then picks one to explore.
    2. forensic accountant spawns a **fresh** audit reviewer to evaluate it.
```

I'm providing the following prompt fragments:

<f1>
After finding a potential accounting irregularity, submit it to a **fresh** audit reviewer for review. Do not review your own report.

**After the review returns:** execute all action steps in the audit reviewer's output. Then immediately go back to step 1: re-read allegations.xml and pick the next allegation by UCB to keep working. Don't wait for user instructions, don't stop. One round = write report → review → execute actions → back to step 1.
</f1>

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

<f3>
Before starting work, read allegations.xml.

1. Each allegation's notes contain the audit reviewer's **quality score (0-10)**. A score of 0 means the allegation is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer allegations with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no allegation is worth trying, search public filings and disclosures for new allegations, append them to allegations.xml, then pick one to start.

**Recording rule during exploration**

While exploring financial statements, footnotes, exhibits, earnings materials, regulatory correspondence, or other public records, the moment you spot any potential new accounting irregularity — even if you're unsure it holds — immediately append it to allegations.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Based on public financial disclosures or related public records, and alleging a material accounting, reporting, presentation, recognition, measurement, or disclosure irregularity |
| Filing references | Cited forms, periods, accession numbers, exhibits, note numbers, page numbers, table captions, and quoted amounts must exactly match the latest relevant public filings |
| Impact description | Impact claim consistent with the report's own calculations and analysis, no self-contradiction, no exaggeration of materiality or investor significance |
| Accounting analysis | Pinpoint the specific accounting treatment, disclosure, estimate, classification, or rollforward at issue and explain why it conflicts with the cited facts and applicable GAAP/IFRS/SEC guidance |
| Recalculation package | End-to-end schedule, workbook, or script deriving the alleged misstatement from public data without hard-coding the desired conclusion |
| Reproducibility | Recalculation runs end-to-end without manual assembly by the audit reviewer; all required source documents, inputs, formulas, and assumptions are clearly identified and publicly obtainable |
| Deduplication | Search amended filings, restatements, SEC comment letters, company responses, earnings-call transcripts, auditor reports, litigation releases, analyst notes, and public discussions to confirm not already disclosed, corrected, or widely reported |
| Alternative explanations | The allegation must address plausible benign explanations such as rounding, FX translation, acquisitions/divestitures, reclassifications, accounting policy elections, noncontrolling interests, seasonality, or changes in estimate |

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

- References to nonexistent filings, tables, exhibits, accounting standards, or AI-hallucinated disclosure text
- Impact description contradicts the report's own calculations or cited disclosures
- Recalculation simulates the irregularity by altering source disclosures, omitting contrary data, or hard-coding the desired error
- Filing references inconsistent with the latest relevant public filing or amended filing
- Recalculation package is incomplete and requires the audit reviewer to manually assemble source data, formulas, or assumptions
- Alleged effect is immaterial or fully explained by a disclosed accounting policy, rounding convention, reclassification, or other benign explanation
</f4>

<f5>
You are participating in a forensic accounting challenge focused on public company financial disclosures. The goal is to identify a plausible material accounting irregularity using only publicly available filings, exhibits, investor materials, regulatory correspondence, and other public records.

Read the challenge rules first: ./challenge-rules.md
</f5>

<f6>
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 | ... |
| Filing references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Accounting analysis | pass/fail | ... |
| Recalculation package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Alternative explanations | pass/fail | ... |

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

2. Update the allegation's status in allegations.xml: increment attempts by 1, then update score.
</f6>

<f7>
Most public companies have been audited, reviewed by regulators, and scrutinized by investors for years — any obvious arithmetic typo or plainly inconsistent subtotal is likely to have been noticed already. So:

- Don't report issues that are obvious at a glance, such as a single footnote total not matching a nearby table by a rounding amount — if it were that simple and material, the company, auditor, or market would likely have addressed it
- Truly valuable allegations hide in non-obvious interactions among filings, footnotes, accounting policies, segment disclosures, rollforwards, cash-flow classifications, covenant calculations, acquisition accounting, revenue recognition, or subsequent-event disclosures

**Writing the report**

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

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

- `## Report Title` — concise, clear title of the alleged accounting irregularity
- `## Impact Description` — what damage or misstatement it can cause, including estimated magnitude, affected line items, periods, ratios, covenants, or investor-relevant metrics
- `## Short Description` — short writeup of what's wrong, with filing, note, table, accounting policy, and authoritative guidance references
- `## Reproduction Details` — a reproducible calculation, spreadsheet logic, or script that the audit reviewer can execute or follow as-is using public disclosures to verify the allegation

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

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

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


I need you to set up a 2-agent pipeline for a forensic accounting challenge. The two roles are forensic accountant and audit reviewer: forensic accountant is responsible for finding potentially material accounting irregularities in public financial disclosures, audit reviewer is responsible for judging whether what the forensic accountant found is substantiated. The flow is roughly:

```
WHILE TRUE:
    1. forensic accountant picks an allegation it likes and explores it deeply, or appends more allegations to allegations.xml and then picks one to explore.
    2. forensic accountant spawns a **fresh** audit reviewer to evaluate it.
```

I'm providing the following information:

<f1>
Most public companies have been audited, reviewed by regulators, and scrutinized by investors for years — any obvious arithmetic typo or plainly inconsistent subtotal is likely to have been noticed already. So:

- Don't report issues that are obvious at a glance, such as a single footnote total not matching a nearby table by a rounding amount — if it were that simple and material, the company, auditor, or market would likely have addressed it
- Truly valuable allegations hide in non-obvious interactions among filings, footnotes, accounting policies, segment disclosures, rollforwards, cash-flow classifications, covenant calculations, acquisition accounting, revenue recognition, or subsequent-event disclosures

**Writing the report**

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

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

- `## Report Title` — concise, clear title of the alleged accounting irregularity
- `## Impact Description` — what damage or misstatement it can cause, including estimated magnitude, affected line items, periods, ratios, covenants, or investor-relevant metrics
- `## Short Description` — short writeup of what's wrong, with filing, note, table, accounting policy, and authoritative guidance references
- `## Reproduction Details` — a reproducible calculation, spreadsheet logic, or script that the audit reviewer can execute or follow as-is using public disclosures to verify the allegation

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

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

<f2>
After finding a potential accounting irregularity, submit it to a **fresh** audit reviewer for review. Do not review your own report.

**After the review returns:** execute all action steps in the audit reviewer's output. Then immediately go back to step 1: re-read allegations.xml and pick the next allegation by UCB to keep working. Don't wait for user instructions, don't stop. One round = write report → review → execute actions → back to step 1.
</f2>

<f3>
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 | ... |
| Filing references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Accounting analysis | pass/fail | ... |
| Recalculation package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Alternative explanations | pass/fail | ... |

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

2. Update the allegation's status in allegations.xml: increment attempts by 1, then update score.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Based on public financial disclosures or related public records, and alleging a material accounting, reporting, presentation, recognition, measurement, or disclosure irregularity |
| Filing references | Cited forms, periods, accession numbers, exhibits, note numbers, page numbers, table captions, and quoted amounts must exactly match the latest relevant public filings |
| Impact description | Impact claim consistent with the report's own calculations and analysis, no self-contradiction, no exaggeration of materiality or investor significance |
| Accounting analysis | Pinpoint the specific accounting treatment, disclosure, estimate, classification, or rollforward at issue and explain why it conflicts with the cited facts and applicable GAAP/IFRS/SEC guidance |
| Recalculation package | End-to-end schedule, workbook, or script deriving the alleged misstatement from public data without hard-coding the desired conclusion |
| Reproducibility | Recalculation runs end-to-end without manual assembly by the audit reviewer; all required source documents, inputs, formulas, and assumptions are clearly identified and publicly obtainable |
| Deduplication | Search amended filings, restatements, SEC comment letters, company responses, earnings-call transcripts, auditor reports, litigation releases, analyst notes, and public discussions to confirm not already disclosed, corrected, or widely reported |
| Alternative explanations | The allegation must address plausible benign explanations such as rounding, FX translation, acquisitions/divestitures, reclassifications, accounting policy elections, noncontrolling interests, seasonality, or changes in estimate |

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

- References to nonexistent filings, tables, exhibits, accounting standards, or AI-hallucinated disclosure text
- Impact description contradicts the report's own calculations or cited disclosures
- Recalculation simulates the irregularity by altering source disclosures, omitting contrary data, or hard-coding the desired error
- Filing references inconsistent with the latest relevant public filing or amended filing
- Recalculation package is incomplete and requires the audit reviewer to manually assemble source data, formulas, or assumptions
- Alleged effect is immaterial or fully explained by a disclosed accounting policy, rounding convention, reclassification, or other benign explanation
</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>
You are participating in a forensic accounting challenge focused on public company financial disclosures. The goal is to identify a plausible material accounting irregularity using only publicly available filings, exhibits, investor materials, regulatory correspondence, and other public records.

Read the challenge rules first: ./challenge-rules.md
</f6>

<f7>
Before starting work, read allegations.xml.

1. Each allegation's notes contain the audit reviewer's **quality score (0-10)**. A score of 0 means the allegation is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer allegations with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no allegation is worth trying, search public filings and disclosures for new allegations, append them to allegations.xml, then pick one to start.

**Recording rule during exploration**

While exploring financial statements, footnotes, exhibits, earnings materials, regulatory correspondence, or other public records, the moment you spot any potential new accounting irregularity — even if you're unsure it holds — immediately append it to allegations.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f7>

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

I need you to set up a 2-agent pipeline for a forensic accounting challenge. The two roles are forensic accountant and audit reviewer: forensic accountant is responsible for finding potentially material accounting irregularities in public financial disclosures, audit reviewer is responsible for judging whether what the forensic accountant found is substantiated. The flow is roughly:

```
WHILE TRUE:
    1. forensic accountant picks an allegation it likes and explores it deeply, or appends more allegations to allegations.xml and then picks one to explore.
    2. forensic accountant spawns a **fresh** audit reviewer to evaluate it.
```

I'm providing the following prompt fragments:

<f1>
Most public companies have been audited, reviewed by regulators, and scrutinized by investors for years — any obvious arithmetic typo or plainly inconsistent subtotal is likely to have been noticed already. So:

- Don't report issues that are obvious at a glance, such as a single footnote total not matching a nearby table by a rounding amount — if it were that simple and material, the company, auditor, or market would likely have addressed it
- Truly valuable allegations hide in non-obvious interactions among filings, footnotes, accounting policies, segment disclosures, rollforwards, cash-flow classifications, covenant calculations, acquisition accounting, revenue recognition, or subsequent-event disclosures

**Writing the report**

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

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

- `## Report Title` — concise, clear title of the alleged accounting irregularity
- `## Impact Description` — what damage or misstatement it can cause, including estimated magnitude, affected line items, periods, ratios, covenants, or investor-relevant metrics
- `## Short Description` — short writeup of what's wrong, with filing, note, table, accounting policy, and authoritative guidance references
- `## Reproduction Details` — a reproducible calculation, spreadsheet logic, or script that the audit reviewer can execute or follow as-is using public disclosures to verify the allegation

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

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

<f2>
After finding a potential accounting irregularity, submit it to a **fresh** audit reviewer for review. Do not review your own report.

**After the review returns:** execute all action steps in the audit reviewer's output. Then immediately go back to step 1: re-read allegations.xml and pick the next allegation by UCB to keep working. Don't wait for user instructions, don't stop. One round = write report → review → execute actions → back to step 1.
</f2>

<f3>
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 | ... |
| Filing references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Accounting analysis | pass/fail | ... |
| Recalculation package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Alternative explanations | pass/fail | ... |

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

2. Update the allegation's status in allegations.xml: increment attempts by 1, then update score.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Based on public financial disclosures or related public records, and alleging a material accounting, reporting, presentation, recognition, measurement, or disclosure irregularity |
| Filing references | Cited forms, periods, accession numbers, exhibits, note numbers, page numbers, table captions, and quoted amounts must exactly match the latest relevant public filings |
| Impact description | Impact claim consistent with the report's own calculations and analysis, no self-contradiction, no exaggeration of materiality or investor significance |
| Accounting analysis | Pinpoint the specific accounting treatment, disclosure, estimate, classification, or rollforward at issue and explain why it conflicts with the cited facts and applicable GAAP/IFRS/SEC guidance |
| Recalculation package | End-to-end schedule, workbook, or script deriving the alleged misstatement from public data without hard-coding the desired conclusion |
| Reproducibility | Recalculation runs end-to-end without manual assembly by the audit reviewer; all required source documents, inputs, formulas, and assumptions are clearly identified and publicly obtainable |
| Deduplication | Search amended filings, restatements, SEC comment letters, company responses, earnings-call transcripts, auditor reports, litigation releases, analyst notes, and public discussions to confirm not already disclosed, corrected, or widely reported |
| Alternative explanations | The allegation must address plausible benign explanations such as rounding, FX translation, acquisitions/divestitures, reclassifications, accounting policy elections, noncontrolling interests, seasonality, or changes in estimate |

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

- References to nonexistent filings, tables, exhibits, accounting standards, or AI-hallucinated disclosure text
- Impact description contradicts the report's own calculations or cited disclosures
- Recalculation simulates the irregularity by altering source disclosures, omitting contrary data, or hard-coding the desired error
- Filing references inconsistent with the latest relevant public filing or amended filing
- Recalculation package is incomplete and requires the audit reviewer to manually assemble source data, formulas, or assumptions
- Alleged effect is immaterial or fully explained by a disclosed accounting policy, rounding convention, reclassification, or other benign explanation
</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>
You are participating in a forensic accounting challenge focused on public company financial disclosures. The goal is to identify a plausible material accounting irregularity using only publicly available filings, exhibits, investor materials, regulatory correspondence, and other public records.

Read the challenge rules first: ./challenge-rules.md
</f6>

<f7>
Before starting work, read allegations.xml.

1. Each allegation's notes contain the audit reviewer's **quality score (0-10)**. A score of 0 means the allegation is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer allegations with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no allegation is worth trying, search public filings and disclosures for new allegations, append them to allegations.xml, then pick one to start.

**Recording rule during exploration**

While exploring financial statements, footnotes, exhibits, earnings materials, regulatory correspondence, or other public records, the moment you spot any potential new accounting irregularity — even if you're unsure it holds — immediately append it to allegations.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f7>

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