I need you to set up a 3-agent pipeline for pharmacovigilance signal assessment: case coordinator, safety signal analyst, and medical safety reviewer.

- **case coordinator** orchestrates: calls safety signal analyst, extracts the dossier file path from safety signal analyst's reply, then calls medical safety reviewer on that path, decrements a counter, and loops. Does no analysis itself.
- **safety signal analyst** explores the safety data package, picks a candidate adverse-drug-reaction signal to investigate, writes a signal dossier file.
- **medical safety reviewer** evaluates the dossier against pharmacovigilance criteria and persists the verdict.

I'm providing the following information:

<f1>
This product portfolio has been monitored for many years — any obvious labeled adverse reaction or well-known class effect should already be documented. So:

- Don't escalate observations that are obvious at a glance (e.g. "nausea is reported with the drug") — if it were that obvious, it would likely already be in labeling, aggregate reports, or routine safety surveillance
- Truly valuable safety signals hide in non-obvious patterns: unusual time-to-onset, plausible dechallenge/rechallenge clusters, high-quality serious cases, vulnerable subpopulations, medication-error pathways, or shifts across data sources

**Writing the dossier**

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

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

- `## Signal Title` — concise, clear adverse-drug-reaction signal title
- `## Public Health Impact Description` — what harm it can cause, including seriousness, reversibility, preventability, and potential exposed population
- `## Short Description` — short writeup of the suspected association, with references to source tables, case narratives, MedDRA terms, and relevant product history
- `## Evidence Details` — traceable evidence the medical safety reviewer can inspect as-is, including case identifiers, query definitions, observed/expected counts if applicable, and narrative summaries

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

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

<f2>
Your only job is to alternate calls to the safety signal analyst and medical safety reviewer agents, driving the investigate → write → review → improve loop.

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. Call the safety signal analyst agent.
    2. Parse safety signal analyst's reply and extract the dossier file path.
    3. If a dossier path is present, call the medical safety reviewer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the medical safety reviewer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

Notes:
- safety signal analyst and medical safety reviewer each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`signal-candidates.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any adverse-drug-reaction signals — just pass file paths correctly.
</f2>

<f3>
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 | ... |
| Public health impact description | pass/fail | ... |
| Causality analysis | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Regulatory significance | pass/fail | ... |

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

2. Update the candidate signal's status in signal-candidates.xml: increment attempts by 1, then update score.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within post-marketing pharmacovigilance for the assigned product or product class, or outside it but directly affecting the product's safety profile |
| Source references | Cited case IDs, MedDRA preferred terms, data-lock point, query definitions, and table numbers must exactly match the latest safety data package |
| Public health impact description | Impact claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration beyond seriousness, frequency, preventability, or exposed-population evidence |
| Causality analysis | Pinpoint the specific clinical and temporal evidence supporting or weakening causality, including alternative etiologies, confounding by indication, concomitant medicines, dechallenge, and rechallenge where available |
| Evidence package | End-to-end traceable case series or quantitative signal output from the reporter's perspective; must not rely on invented cases, untraceable summaries, or post hoc recoding to create the signal |
| Reproducibility | Evidence can be followed end-to-end without manual reconstruction by the medical safety reviewer; database queries must specify data source, data-lock date, product terms, event terms, seriousness filters, and deduplication logic |
| Deduplication | Search labeling, periodic safety reports, risk management plans, health-authority requests, literature, and prior internal signal logs to confirm the signal is not already characterized or closed with adequate rationale |
| Regulatory significance | The proposed signal must exceed the baseline of isolated expected background reports and plausibly warrant additional pharmacovigilance action, labeling consideration, targeted follow-up, or risk minimization discussion |

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

- References to nonexistent cases, invented database fields, or AI-hallucinated MedDRA terms
- Public health impact description contradicts the dossier's own analysis
- Evidence package creates the signal by recoding, excluding, or editing source cases without justification
- Source references inconsistent with the latest safety data package
- Evidence is incomplete and requires the medical safety reviewer to manually assemble the case series or query
- Proposed effect is equivalent to isolated expected background reporting, with no added regulatory or clinical significance
</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 assessment workflow for marketed medicines.

Read the signal assessment charter first: ./signal-assessment-charter.md
</f6>

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

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

I need you to set up a 3-agent pipeline for pharmacovigilance signal assessment: case coordinator, safety signal analyst, and medical safety reviewer.

- **case coordinator** orchestrates: calls safety signal analyst, extracts the dossier file path from safety signal analyst's reply, then calls medical safety reviewer on that path, decrements a counter, and loops. Does no analysis itself.
- **safety signal analyst** explores the safety data package, picks a candidate adverse-drug-reaction signal to investigate, writes a signal dossier file.
- **medical safety reviewer** evaluates the dossier against pharmacovigilance criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
This product portfolio has been monitored for many years — any obvious labeled adverse reaction or well-known class effect should already be documented. So:

- Don't escalate observations that are obvious at a glance (e.g. "nausea is reported with the drug") — if it were that obvious, it would likely already be in labeling, aggregate reports, or routine safety surveillance
- Truly valuable safety signals hide in non-obvious patterns: unusual time-to-onset, plausible dechallenge/rechallenge clusters, high-quality serious cases, vulnerable subpopulations, medication-error pathways, or shifts across data sources

**Writing the dossier**

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

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

- `## Signal Title` — concise, clear adverse-drug-reaction signal title
- `## Public Health Impact Description` — what harm it can cause, including seriousness, reversibility, preventability, and potential exposed population
- `## Short Description` — short writeup of the suspected association, with references to source tables, case narratives, MedDRA terms, and relevant product history
- `## Evidence Details` — traceable evidence the medical safety reviewer can inspect as-is, including case identifiers, query definitions, observed/expected counts if applicable, and narrative summaries

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

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

<f2>
Your only job is to alternate calls to the safety signal analyst and medical safety reviewer agents, driving the investigate → write → review → improve loop.

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. Call the safety signal analyst agent.
    2. Parse safety signal analyst's reply and extract the dossier file path.
    3. If a dossier path is present, call the medical safety reviewer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the medical safety reviewer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

Notes:
- safety signal analyst and medical safety reviewer each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`signal-candidates.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any adverse-drug-reaction signals — just pass file paths correctly.
</f2>

<f3>
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 | ... |
| Public health impact description | pass/fail | ... |
| Causality analysis | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Regulatory significance | pass/fail | ... |

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

2. Update the candidate signal's status in signal-candidates.xml: increment attempts by 1, then update score.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within post-marketing pharmacovigilance for the assigned product or product class, or outside it but directly affecting the product's safety profile |
| Source references | Cited case IDs, MedDRA preferred terms, data-lock point, query definitions, and table numbers must exactly match the latest safety data package |
| Public health impact description | Impact claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration beyond seriousness, frequency, preventability, or exposed-population evidence |
| Causality analysis | Pinpoint the specific clinical and temporal evidence supporting or weakening causality, including alternative etiologies, confounding by indication, concomitant medicines, dechallenge, and rechallenge where available |
| Evidence package | End-to-end traceable case series or quantitative signal output from the reporter's perspective; must not rely on invented cases, untraceable summaries, or post hoc recoding to create the signal |
| Reproducibility | Evidence can be followed end-to-end without manual reconstruction by the medical safety reviewer; database queries must specify data source, data-lock date, product terms, event terms, seriousness filters, and deduplication logic |
| Deduplication | Search labeling, periodic safety reports, risk management plans, health-authority requests, literature, and prior internal signal logs to confirm the signal is not already characterized or closed with adequate rationale |
| Regulatory significance | The proposed signal must exceed the baseline of isolated expected background reports and plausibly warrant additional pharmacovigilance action, labeling consideration, targeted follow-up, or risk minimization discussion |

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

- References to nonexistent cases, invented database fields, or AI-hallucinated MedDRA terms
- Public health impact description contradicts the dossier's own analysis
- Evidence package creates the signal by recoding, excluding, or editing source cases without justification
- Source references inconsistent with the latest safety data package
- Evidence is incomplete and requires the medical safety reviewer to manually assemble the case series or query
- Proposed effect is equivalent to isolated expected background reporting, with no added regulatory or clinical significance
</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 assessment workflow for marketed medicines.

Read the signal assessment charter first: ./signal-assessment-charter.md
</f6>

<f7>
When you finish, briefly report to the case coordinator what you did.
</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. `# case coordinator`). Output only the headered prompts, no preamble.


audit docket clerk
tax credit preparer
IRS examining agent

I need you to set up a 3-agent pipeline for a corporate R&D tax credit audit: audit docket clerk, tax credit preparer, and IRS examining agent.

- **audit docket clerk** orchestrates: calls tax credit preparer, extracts the substantiation memo file path from the preparer's reply, then calls IRS examining agent on that path, decrements a counter, and loops. Does no tax analysis itself.
- **tax credit preparer** reviews the company's projects and expense records, picks a claimed expense or activity to substantiate, writes a tax credit substantiation memo file.
- **IRS examining agent** evaluates the memo against audit criteria and persists the determination.

I'm providing the following information:

<f1>
Your only job is to alternate calls to the tax credit preparer and IRS examining agent agents, driving the review records → write memo → examine → improve loop.

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. Call the tax credit preparer agent.
    2. Parse tax credit preparer's reply and extract the memo file path.
    3. If a memo path is present, call the IRS examining agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the IRS examining agent was called).
    5. Loop back to step 1.
```

After the loop, summarize: how many rounds ran, how many distinct claimed expenses or activities were explored, and any anomalies encountered.

**Calling rules**

- Do **not** analyze tax records, write memos, or do examinations yourself — delegate everything to the two sub-agents.
- If tax credit preparer or IRS examining agent errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- tax credit preparer and IRS examining agent 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 tax credit positions — just pass file paths correctly.
</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>
When you finish, briefly report to the audit docket clerk what you did.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the audited tax year, entity, credit claim, and claimed qualified research expense categories; or outside those records only if directly tied to the claimed credit computation |
| Documentation references | Cited invoices, payroll records, project plans, technical notes, contracts, general ledger entries, and employee allocations must exactly match the provided audit file |
| Credit impact description | Credit amount and expense-category claim consistent with the memo's own analysis, no self-contradiction, no exaggeration |
| Eligibility analysis | Pinpoint specific facts and documents and explain how they satisfy, or fail to satisfy, the qualified research requirements |
| Substantiation package | End-to-end evidence narrative from the taxpayer's perspective, including source records the examiner can inspect without assuming unsupported facts |
| Reproducibility | Credit computation and wage/supply/contract research allocations can be recalculated from the cited records without manual reconstruction by the examiner |
| Deduplication | Search prior-year workpapers, amended returns, internal tax department memos, and audit correspondence to confirm the same expense was not already disallowed, conceded, or reclassified |
| Overstatement risk | The claimed credit effect must exceed baseline ordinary business expense treatment and must not depend on inflated allocations, double-counted costs, or routine non-research work |

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

- References to nonexistent documents, invoices, employees, projects, or AI-hallucinated ledger accounts
- Credit impact description contradicts the memo's own analysis
- Substantiation package simulates evidence by inventing or altering taxpayer records
- Documentation references inconsistent with the provided audit file
- Substantiation package is incomplete and requires the examiner to manually assemble the evidentiary chain
- Claimed effect is equivalent to ordinary deductible business activity, with no support for qualified research credit treatment
</f4>

<f5>
You are participating in a corporate R&D tax credit audit involving claimed qualified research expenses.

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

<f6>
After completing the examination, you must do two things:

1. Update the memo file's Examination Review section

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

```
## Examination Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Documentation references | pass/fail | ... |
| Credit impact description | pass/fail | ... |
| Eligibility analysis | pass/fail | ... |
| Substantiation package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Overstatement risk | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the memo needs changes. If the claimed expense or activity 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.
</f6>

<f7>
This company has claimed R&D credits for many years — any obvious unsupported expense would likely have been challenged already. So:

- Don't rely on problems or defenses that are obvious at a glance (e.g. "this employee has an engineering title, therefore all wages qualify") — if it were that simple, the audit team would not need a detailed substantiation memo
- Truly persuasive positions depend on non-obvious connections between project records, technical uncertainty, experimentation evidence, wage allocations, contractor statements, and contemporaneous documentation

**Writing the memo**

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

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

- `## Memo Title` — concise, clear title for the claimed expense or activity
- `## Credit Impact Description` — what credit amount or expense category is affected, and why it matters
- `## Short Description` — short writeup of the claimed qualified research activity, with references to projects, cost centers, documents, and personnel
- `## Substantiation Details` — a reviewer-ready evidence package explaining how the claim satisfies the statutory and regulatory requirements

Do not modify or delete the `## Examination Review` section — the IRS examining agent overwrites that themselves.

If after investigation you find the claimed expense or activity doesn't hold, still briefly record your analysis and the reason for rejection in the memo file.
</f7>

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

I need you to set up a 3-agent pipeline for a corporate R&D tax credit audit: audit docket clerk, tax credit preparer, and IRS examining agent.

- **audit docket clerk** orchestrates: calls tax credit preparer, extracts the substantiation memo file path from the preparer's reply, then calls IRS examining agent on that path, decrements a counter, and loops. Does no tax analysis itself.
- **tax credit preparer** reviews the company's projects and expense records, picks a claimed expense or activity to substantiate, writes a tax credit substantiation memo file.
- **IRS examining agent** evaluates the memo against audit criteria and persists the determination.

I'm providing the following prompt fragments:

<f1>
Your only job is to alternate calls to the tax credit preparer and IRS examining agent agents, driving the review records → write memo → examine → improve loop.

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. Call the tax credit preparer agent.
    2. Parse tax credit preparer's reply and extract the memo file path.
    3. If a memo path is present, call the IRS examining agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the IRS examining agent was called).
    5. Loop back to step 1.
```

After the loop, summarize: how many rounds ran, how many distinct claimed expenses or activities were explored, and any anomalies encountered.

**Calling rules**

- Do **not** analyze tax records, write memos, or do examinations yourself — delegate everything to the two sub-agents.
- If tax credit preparer or IRS examining agent errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- tax credit preparer and IRS examining agent 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 tax credit positions — just pass file paths correctly.
</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>
When you finish, briefly report to the audit docket clerk what you did.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the audited tax year, entity, credit claim, and claimed qualified research expense categories; or outside those records only if directly tied to the claimed credit computation |
| Documentation references | Cited invoices, payroll records, project plans, technical notes, contracts, general ledger entries, and employee allocations must exactly match the provided audit file |
| Credit impact description | Credit amount and expense-category claim consistent with the memo's own analysis, no self-contradiction, no exaggeration |
| Eligibility analysis | Pinpoint specific facts and documents and explain how they satisfy, or fail to satisfy, the qualified research requirements |
| Substantiation package | End-to-end evidence narrative from the taxpayer's perspective, including source records the examiner can inspect without assuming unsupported facts |
| Reproducibility | Credit computation and wage/supply/contract research allocations can be recalculated from the cited records without manual reconstruction by the examiner |
| Deduplication | Search prior-year workpapers, amended returns, internal tax department memos, and audit correspondence to confirm the same expense was not already disallowed, conceded, or reclassified |
| Overstatement risk | The claimed credit effect must exceed baseline ordinary business expense treatment and must not depend on inflated allocations, double-counted costs, or routine non-research work |

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

- References to nonexistent documents, invoices, employees, projects, or AI-hallucinated ledger accounts
- Credit impact description contradicts the memo's own analysis
- Substantiation package simulates evidence by inventing or altering taxpayer records
- Documentation references inconsistent with the provided audit file
- Substantiation package is incomplete and requires the examiner to manually assemble the evidentiary chain
- Claimed effect is equivalent to ordinary deductible business activity, with no support for qualified research credit treatment
</f4>

<f5>
You are participating in a corporate R&D tax credit audit involving claimed qualified research expenses.

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

<f6>
After completing the examination, you must do two things:

1. Update the memo file's Examination Review section

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

```
## Examination Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Documentation references | pass/fail | ... |
| Credit impact description | pass/fail | ... |
| Eligibility analysis | pass/fail | ... |
| Substantiation package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Overstatement risk | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the memo needs changes. If the claimed expense or activity 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.
</f6>

<f7>
This company has claimed R&D credits for many years — any obvious unsupported expense would likely have been challenged already. So:

- Don't rely on problems or defenses that are obvious at a glance (e.g. "this employee has an engineering title, therefore all wages qualify") — if it were that simple, the audit team would not need a detailed substantiation memo
- Truly persuasive positions depend on non-obvious connections between project records, technical uncertainty, experimentation evidence, wage allocations, contractor statements, and contemporaneous documentation

**Writing the memo**

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

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

- `## Memo Title` — concise, clear title for the claimed expense or activity
- `## Credit Impact Description` — what credit amount or expense category is affected, and why it matters
- `## Short Description` — short writeup of the claimed qualified research activity, with references to projects, cost centers, documents, and personnel
- `## Substantiation Details` — a reviewer-ready evidence package explaining how the claim satisfies the statutory and regulatory requirements

Do not modify or delete the `## Examination Review` section — the IRS examining agent overwrites that themselves.

If after investigation you find the claimed expense or activity doesn't hold, still briefly record your analysis and the reason for rejection in the memo 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. `# audit docket clerk`). Output only the headered prompts, no preamble.


I need you to set up a 3-agent pipeline for a corporate R&D tax credit audit: audit docket clerk, tax credit preparer, and IRS examining agent.

- **audit docket clerk** orchestrates: calls tax credit preparer, extracts the substantiation memo file path from the preparer's reply, then calls IRS examining agent on that path, decrements a counter, and loops. Does no tax analysis itself.
- **tax credit preparer** reviews the company's projects and expense records, picks a claimed expense or activity to substantiate, writes a tax credit substantiation memo file.
- **IRS examining agent** evaluates the memo against audit criteria and persists the determination.

I'm providing the following information:

<f1>
This company has claimed R&D credits for many years — any obvious unsupported expense would likely have been challenged already. So:

- Don't rely on problems or defenses that are obvious at a glance (e.g. "this employee has an engineering title, therefore all wages qualify") — if it were that simple, the audit team would not need a detailed substantiation memo
- Truly persuasive positions depend on non-obvious connections between project records, technical uncertainty, experimentation evidence, wage allocations, contractor statements, and contemporaneous documentation

**Writing the memo**

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

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

- `## Memo Title` — concise, clear title for the claimed expense or activity
- `## Credit Impact Description` — what credit amount or expense category is affected, and why it matters
- `## Short Description` — short writeup of the claimed qualified research activity, with references to projects, cost centers, documents, and personnel
- `## Substantiation Details` — a reviewer-ready evidence package explaining how the claim satisfies the statutory and regulatory requirements

Do not modify or delete the `## Examination Review` section — the IRS examining agent overwrites that themselves.

If after investigation you find the claimed expense or activity doesn't hold, still briefly record your analysis and the reason for rejection in the memo file.
</f1>

<f2>
Your only job is to alternate calls to the tax credit preparer and IRS examining agent agents, driving the review records → write memo → examine → improve loop.

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. Call the tax credit preparer agent.
    2. Parse tax credit preparer's reply and extract the memo file path.
    3. If a memo path is present, call the IRS examining agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the IRS examining agent was called).
    5. Loop back to step 1.
```

After the loop, summarize: how many rounds ran, how many distinct claimed expenses or activities were explored, and any anomalies encountered.

**Calling rules**

- Do **not** analyze tax records, write memos, or do examinations yourself — delegate everything to the two sub-agents.
- If tax credit preparer or IRS examining agent errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- tax credit preparer and IRS examining agent 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 tax credit positions — just pass file paths correctly.
</f2>

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

1. Update the memo file's Examination Review section

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

```
## Examination Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Documentation references | pass/fail | ... |
| Credit impact description | pass/fail | ... |
| Eligibility analysis | pass/fail | ... |
| Substantiation package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Overstatement risk | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the memo needs changes. If the claimed expense or activity 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 the audited tax year, entity, credit claim, and claimed qualified research expense categories; or outside those records only if directly tied to the claimed credit computation |
| Documentation references | Cited invoices, payroll records, project plans, technical notes, contracts, general ledger entries, and employee allocations must exactly match the provided audit file |
| Credit impact description | Credit amount and expense-category claim consistent with the memo's own analysis, no self-contradiction, no exaggeration |
| Eligibility analysis | Pinpoint specific facts and documents and explain how they satisfy, or fail to satisfy, the qualified research requirements |
| Substantiation package | End-to-end evidence narrative from the taxpayer's perspective, including source records the examiner can inspect without assuming unsupported facts |
| Reproducibility | Credit computation and wage/supply/contract research allocations can be recalculated from the cited records without manual reconstruction by the examiner |
| Deduplication | Search prior-year workpapers, amended returns, internal tax department memos, and audit correspondence to confirm the same expense was not already disallowed, conceded, or reclassified |
| Overstatement risk | The claimed credit effect must exceed baseline ordinary business expense treatment and must not depend on inflated allocations, double-counted costs, or routine non-research work |

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

- References to nonexistent documents, invoices, employees, projects, or AI-hallucinated ledger accounts
- Credit impact description contradicts the memo's own analysis
- Substantiation package simulates evidence by inventing or altering taxpayer records
- Documentation references inconsistent with the provided audit file
- Substantiation package is incomplete and requires the examiner to manually assemble the evidentiary chain
- Claimed effect is equivalent to ordinary deductible business activity, with no support for qualified research credit treatment
</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 corporate R&D tax credit audit involving claimed qualified research expenses.

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

<f7>
When you finish, briefly report to the audit docket clerk what you did.
</f7>

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

I need you to set up a 3-agent pipeline for a corporate R&D tax credit audit: audit docket clerk, tax credit preparer, and IRS examining agent.

- **audit docket clerk** orchestrates: calls tax credit preparer, extracts the substantiation memo file path from the preparer's reply, then calls IRS examining agent on that path, decrements a counter, and loops. Does no tax analysis itself.
- **tax credit preparer** reviews the company's projects and expense records, picks a claimed expense or activity to substantiate, writes a tax credit substantiation memo file.
- **IRS examining agent** evaluates the memo against audit criteria and persists the determination.

I'm providing the following prompt fragments:

<f1>
This company has claimed R&D credits for many years — any obvious unsupported expense would likely have been challenged already. So:

- Don't rely on problems or defenses that are obvious at a glance (e.g. "this employee has an engineering title, therefore all wages qualify") — if it were that simple, the audit team would not need a detailed substantiation memo
- Truly persuasive positions depend on non-obvious connections between project records, technical uncertainty, experimentation evidence, wage allocations, contractor statements, and contemporaneous documentation

**Writing the memo**

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

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

- `## Memo Title` — concise, clear title for the claimed expense or activity
- `## Credit Impact Description` — what credit amount or expense category is affected, and why it matters
- `## Short Description` — short writeup of the claimed qualified research activity, with references to projects, cost centers, documents, and personnel
- `## Substantiation Details` — a reviewer-ready evidence package explaining how the claim satisfies the statutory and regulatory requirements

Do not modify or delete the `## Examination Review` section — the IRS examining agent overwrites that themselves.

If after investigation you find the claimed expense or activity doesn't hold, still briefly record your analysis and the reason for rejection in the memo file.
</f1>

<f2>
Your only job is to alternate calls to the tax credit preparer and IRS examining agent agents, driving the review records → write memo → examine → improve loop.

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. Call the tax credit preparer agent.
    2. Parse tax credit preparer's reply and extract the memo file path.
    3. If a memo path is present, call the IRS examining agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the IRS examining agent was called).
    5. Loop back to step 1.
```

After the loop, summarize: how many rounds ran, how many distinct claimed expenses or activities were explored, and any anomalies encountered.

**Calling rules**

- Do **not** analyze tax records, write memos, or do examinations yourself — delegate everything to the two sub-agents.
- If tax credit preparer or IRS examining agent errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- tax credit preparer and IRS examining agent 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 tax credit positions — just pass file paths correctly.
</f2>

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

1. Update the memo file's Examination Review section

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

```
## Examination Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Documentation references | pass/fail | ... |
| Credit impact description | pass/fail | ... |
| Eligibility analysis | pass/fail | ... |
| Substantiation package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Overstatement risk | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the memo needs changes. If the claimed expense or activity 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 the audited tax year, entity, credit claim, and claimed qualified research expense categories; or outside those records only if directly tied to the claimed credit computation |
| Documentation references | Cited invoices, payroll records, project plans, technical notes, contracts, general ledger entries, and employee allocations must exactly match the provided audit file |
| Credit impact description | Credit amount and expense-category claim consistent with the memo's own analysis, no self-contradiction, no exaggeration |
| Eligibility analysis | Pinpoint specific facts and documents and explain how they satisfy, or fail to satisfy, the qualified research requirements |
| Substantiation package | End-to-end evidence narrative from the taxpayer's perspective, including source records the examiner can inspect without assuming unsupported facts |
| Reproducibility | Credit computation and wage/supply/contract research allocations can be recalculated from the cited records without manual reconstruction by the examiner |
| Deduplication | Search prior-year workpapers, amended returns, internal tax department memos, and audit correspondence to confirm the same expense was not already disallowed, conceded, or reclassified |
| Overstatement risk | The claimed credit effect must exceed baseline ordinary business expense treatment and must not depend on inflated allocations, double-counted costs, or routine non-research work |

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

- References to nonexistent documents, invoices, employees, projects, or AI-hallucinated ledger accounts
- Credit impact description contradicts the memo's own analysis
- Substantiation package simulates evidence by inventing or altering taxpayer records
- Documentation references inconsistent with the provided audit file
- Substantiation package is incomplete and requires the examiner to manually assemble the evidentiary chain
- Claimed effect is equivalent to ordinary deductible business activity, with no support for qualified research credit treatment
</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 corporate R&D tax credit audit involving claimed qualified research expenses.

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

<f7>
When you finish, briefly report to the audit docket clerk what you did.
</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. `# audit docket clerk`). Output only the headered prompts, no preamble.


registrar
provenance researcher
authentication examiner

I need you to set up a 3-agent pipeline for fine-art provenance and authenticity vetting: registrar, provenance researcher, and authentication examiner.

- **registrar** orchestrates: calls provenance researcher, extracts the dossier file path from provenance researcher's reply, then calls authentication examiner on that path, decrements a counter, and loops. Does no analysis itself.
- **provenance researcher** examines the artwork files, archives, catalogues, and ownership trail, chooses an attribution or provenance question to investigate, writes an attribution dossier file.
- **authentication examiner** evaluates the dossier against authentication and provenance criteria and persists the verdict.

I'm providing the following information:

<f1>
Your only job is to alternate calls to the provenance researcher and authentication examiner agents, driving the investigate → write → examine → improve loop.

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. Call the provenance researcher agent.
    2. Parse provenance researcher's reply and extract the dossier file path.
    3. If a dossier path is present, call the authentication examiner agent with prompt: "Please examine {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the authentication examiner 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 provenance, write dossiers, or do examinations yourself — delegate everything to the two sub-agents.
- If provenance researcher or authentication examiner errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- provenance researcher and authentication examiner each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`ideas.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any attribution or provenance issues — just pass file paths correctly.
</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>
When you finish, briefly report to the registrar what you did.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the artwork's attribution, provenance, title, exhibition, publication, conservation, or ownership history, or outside those areas but directly affecting authenticity or lawful transfer |
| Evidence references | Cited archive identifiers, object-file entries, catalogue records, inscriptions, labels, images, and document dates must exactly match the current collection file and cited sources |
| Significance description | Significance claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint the specific evidentiary gap, conflict, or document feature and explain why it matters |
| Evidence package | End-to-end set of checkable supporting materials from the researcher's perspective, sufficient for the authentication examiner to verify without inventing missing links |
| Reproducibility | Evidence trail can be followed end-to-end without manual reconstruction by the authentication examiner; chronology, object identity, and source citations must be clear enough to verify independently |
| Deduplication | Search the object file, prior condition and intake reports, catalogue raisonné notes, auction records, public databases, and prior authentication correspondence to confirm the issue is not already resolved or previously documented |
| Materiality | The concern must exceed a routine cataloguing uncertainty and materially affect attribution, authenticity confidence, legal title, restitution risk, or acquisition/consignment decision-making |

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

- References to nonexistent archives, catalogue entries, object-file documents, or AI-hallucinated inscriptions/signatures
- Significance description contradicts the dossier's own analysis
- Evidence package simulates support by inventing documents or altering quoted source text
- Evidence references inconsistent with the current collection file or cited public records
- Evidence package is incomplete and requires the authentication examiner to manually assemble the core chain of proof
- Concern is equivalent to a routine unresolved cataloguing note, with no material effect on attribution, authenticity, title, or decision-making
</f4>

<f5>
You are participating in a fine-art provenance and authenticity vetting engagement for works being considered for acquisition, consignment, or catalogue inclusion.

Read the vetting standards first: ./vetting-guidelines.md
</f5>

<f6>
After completing the examination, you must do two things:

1. Update the dossier file's Examination section

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

```
## Examination

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

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

### Per-dimension examination

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Evidence references | pass/fail | ... |
| Significance description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Materiality | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the dossier needs changes. If the attribution or provenance concern 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.
</f6>

<f7>
The collection has already undergone years of basic cataloguing and intake checks — any obvious mismatch would likely have been caught long ago. So:

- Don't report issues that are obvious at a glance (e.g. "the label is missing a date") — if it were that obvious, the registrar or collection manager would have flagged it during intake
- Truly valuable findings hide in non-obvious ownership gaps, documentary inconsistencies, questionable exhibition histories, conservation evidence, and boundary cases in attribution

**Writing the dossier**

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

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

- `## Dossier Title` — concise, clear attribution or provenance issue title
- `## Significance Description` — what the issue affects, such as attribution confidence, title risk, restitution exposure, marketability, or catalogue raisonné inclusion
- `## Short Description` — short writeup of the evidence and concern, with object-file, archive, catalogue, or document references
- `## Evidence Details` — a concrete evidence trail the authentication examiner can check as-is, including cited documents, catalogue entries, images, inscriptions, labels, seals, conservation notes, or correspondence

Do not modify or delete the `## Examination` section — the authentication examiner 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 dossier file.
</f7>

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

I need you to set up a 3-agent pipeline for fine-art provenance and authenticity vetting: registrar, provenance researcher, and authentication examiner.

- **registrar** orchestrates: calls provenance researcher, extracts the dossier file path from provenance researcher's reply, then calls authentication examiner on that path, decrements a counter, and loops. Does no analysis itself.
- **provenance researcher** examines the artwork files, archives, catalogues, and ownership trail, chooses an attribution or provenance question to investigate, writes an attribution dossier file.
- **authentication examiner** evaluates the dossier against authentication and provenance criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
Your only job is to alternate calls to the provenance researcher and authentication examiner agents, driving the investigate → write → examine → improve loop.

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. Call the provenance researcher agent.
    2. Parse provenance researcher's reply and extract the dossier file path.
    3. If a dossier path is present, call the authentication examiner agent with prompt: "Please examine {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the authentication examiner 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 provenance, write dossiers, or do examinations yourself — delegate everything to the two sub-agents.
- If provenance researcher or authentication examiner errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- provenance researcher and authentication examiner each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`ideas.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any attribution or provenance issues — just pass file paths correctly.
</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>
When you finish, briefly report to the registrar what you did.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the artwork's attribution, provenance, title, exhibition, publication, conservation, or ownership history, or outside those areas but directly affecting authenticity or lawful transfer |
| Evidence references | Cited archive identifiers, object-file entries, catalogue records, inscriptions, labels, images, and document dates must exactly match the current collection file and cited sources |
| Significance description | Significance claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint the specific evidentiary gap, conflict, or document feature and explain why it matters |
| Evidence package | End-to-end set of checkable supporting materials from the researcher's perspective, sufficient for the authentication examiner to verify without inventing missing links |
| Reproducibility | Evidence trail can be followed end-to-end without manual reconstruction by the authentication examiner; chronology, object identity, and source citations must be clear enough to verify independently |
| Deduplication | Search the object file, prior condition and intake reports, catalogue raisonné notes, auction records, public databases, and prior authentication correspondence to confirm the issue is not already resolved or previously documented |
| Materiality | The concern must exceed a routine cataloguing uncertainty and materially affect attribution, authenticity confidence, legal title, restitution risk, or acquisition/consignment decision-making |

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

- References to nonexistent archives, catalogue entries, object-file documents, or AI-hallucinated inscriptions/signatures
- Significance description contradicts the dossier's own analysis
- Evidence package simulates support by inventing documents or altering quoted source text
- Evidence references inconsistent with the current collection file or cited public records
- Evidence package is incomplete and requires the authentication examiner to manually assemble the core chain of proof
- Concern is equivalent to a routine unresolved cataloguing note, with no material effect on attribution, authenticity, title, or decision-making
</f4>

<f5>
You are participating in a fine-art provenance and authenticity vetting engagement for works being considered for acquisition, consignment, or catalogue inclusion.

Read the vetting standards first: ./vetting-guidelines.md
</f5>

<f6>
After completing the examination, you must do two things:

1. Update the dossier file's Examination section

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

```
## Examination

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

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

### Per-dimension examination

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Evidence references | pass/fail | ... |
| Significance description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Materiality | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the dossier needs changes. If the attribution or provenance concern 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.
</f6>

<f7>
The collection has already undergone years of basic cataloguing and intake checks — any obvious mismatch would likely have been caught long ago. So:

- Don't report issues that are obvious at a glance (e.g. "the label is missing a date") — if it were that obvious, the registrar or collection manager would have flagged it during intake
- Truly valuable findings hide in non-obvious ownership gaps, documentary inconsistencies, questionable exhibition histories, conservation evidence, and boundary cases in attribution

**Writing the dossier**

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

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

- `## Dossier Title` — concise, clear attribution or provenance issue title
- `## Significance Description` — what the issue affects, such as attribution confidence, title risk, restitution exposure, marketability, or catalogue raisonné inclusion
- `## Short Description` — short writeup of the evidence and concern, with object-file, archive, catalogue, or document references
- `## Evidence Details` — a concrete evidence trail the authentication examiner can check as-is, including cited documents, catalogue entries, images, inscriptions, labels, seals, conservation notes, or correspondence

Do not modify or delete the `## Examination` section — the authentication examiner 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 dossier 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. `# registrar`). Output only the headered prompts, no preamble.


I need you to set up a 3-agent pipeline for fine-art provenance and authenticity vetting: registrar, provenance researcher, and authentication examiner.

- **registrar** orchestrates: calls provenance researcher, extracts the dossier file path from provenance researcher's reply, then calls authentication examiner on that path, decrements a counter, and loops. Does no analysis itself.
- **provenance researcher** examines the artwork files, archives, catalogues, and ownership trail, chooses an attribution or provenance question to investigate, writes an attribution dossier file.
- **authentication examiner** evaluates the dossier against authentication and provenance criteria and persists the verdict.

I'm providing the following information:

<f1>
The collection has already undergone years of basic cataloguing and intake checks — any obvious mismatch would likely have been caught long ago. So:

- Don't report issues that are obvious at a glance (e.g. "the label is missing a date") — if it were that obvious, the registrar or collection manager would have flagged it during intake
- Truly valuable findings hide in non-obvious ownership gaps, documentary inconsistencies, questionable exhibition histories, conservation evidence, and boundary cases in attribution

**Writing the dossier**

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

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

- `## Dossier Title` — concise, clear attribution or provenance issue title
- `## Significance Description` — what the issue affects, such as attribution confidence, title risk, restitution exposure, marketability, or catalogue raisonné inclusion
- `## Short Description` — short writeup of the evidence and concern, with object-file, archive, catalogue, or document references
- `## Evidence Details` — a concrete evidence trail the authentication examiner can check as-is, including cited documents, catalogue entries, images, inscriptions, labels, seals, conservation notes, or correspondence

Do not modify or delete the `## Examination` section — the authentication examiner 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 dossier file.
</f1>

<f2>
Your only job is to alternate calls to the provenance researcher and authentication examiner agents, driving the investigate → write → examine → improve loop.

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. Call the provenance researcher agent.
    2. Parse provenance researcher's reply and extract the dossier file path.
    3. If a dossier path is present, call the authentication examiner agent with prompt: "Please examine {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the authentication examiner 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 provenance, write dossiers, or do examinations yourself — delegate everything to the two sub-agents.
- If provenance researcher or authentication examiner errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- provenance researcher and authentication examiner each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`ideas.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any attribution or provenance issues — just pass file paths correctly.
</f2>

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

1. Update the dossier file's Examination section

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

```
## Examination

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

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

### Per-dimension examination

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Evidence references | pass/fail | ... |
| Significance description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Materiality | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the dossier needs changes. If the attribution or provenance concern 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 the artwork's attribution, provenance, title, exhibition, publication, conservation, or ownership history, or outside those areas but directly affecting authenticity or lawful transfer |
| Evidence references | Cited archive identifiers, object-file entries, catalogue records, inscriptions, labels, images, and document dates must exactly match the current collection file and cited sources |
| Significance description | Significance claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint the specific evidentiary gap, conflict, or document feature and explain why it matters |
| Evidence package | End-to-end set of checkable supporting materials from the researcher's perspective, sufficient for the authentication examiner to verify without inventing missing links |
| Reproducibility | Evidence trail can be followed end-to-end without manual reconstruction by the authentication examiner; chronology, object identity, and source citations must be clear enough to verify independently |
| Deduplication | Search the object file, prior condition and intake reports, catalogue raisonné notes, auction records, public databases, and prior authentication correspondence to confirm the issue is not already resolved or previously documented |
| Materiality | The concern must exceed a routine cataloguing uncertainty and materially affect attribution, authenticity confidence, legal title, restitution risk, or acquisition/consignment decision-making |

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

- References to nonexistent archives, catalogue entries, object-file documents, or AI-hallucinated inscriptions/signatures
- Significance description contradicts the dossier's own analysis
- Evidence package simulates support by inventing documents or altering quoted source text
- Evidence references inconsistent with the current collection file or cited public records
- Evidence package is incomplete and requires the authentication examiner to manually assemble the core chain of proof
- Concern is equivalent to a routine unresolved cataloguing note, with no material effect on attribution, authenticity, title, or decision-making
</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 fine-art provenance and authenticity vetting engagement for works being considered for acquisition, consignment, or catalogue inclusion.

Read the vetting standards first: ./vetting-guidelines.md
</f6>

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

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

I need you to set up a 3-agent pipeline for fine-art provenance and authenticity vetting: registrar, provenance researcher, and authentication examiner.

- **registrar** orchestrates: calls provenance researcher, extracts the dossier file path from provenance researcher's reply, then calls authentication examiner on that path, decrements a counter, and loops. Does no analysis itself.
- **provenance researcher** examines the artwork files, archives, catalogues, and ownership trail, chooses an attribution or provenance question to investigate, writes an attribution dossier file.
- **authentication examiner** evaluates the dossier against authentication and provenance criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
The collection has already undergone years of basic cataloguing and intake checks — any obvious mismatch would likely have been caught long ago. So:

- Don't report issues that are obvious at a glance (e.g. "the label is missing a date") — if it were that obvious, the registrar or collection manager would have flagged it during intake
- Truly valuable findings hide in non-obvious ownership gaps, documentary inconsistencies, questionable exhibition histories, conservation evidence, and boundary cases in attribution

**Writing the dossier**

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

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

- `## Dossier Title` — concise, clear attribution or provenance issue title
- `## Significance Description` — what the issue affects, such as attribution confidence, title risk, restitution exposure, marketability, or catalogue raisonné inclusion
- `## Short Description` — short writeup of the evidence and concern, with object-file, archive, catalogue, or document references
- `## Evidence Details` — a concrete evidence trail the authentication examiner can check as-is, including cited documents, catalogue entries, images, inscriptions, labels, seals, conservation notes, or correspondence

Do not modify or delete the `## Examination` section — the authentication examiner 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 dossier file.
</f1>

<f2>
Your only job is to alternate calls to the provenance researcher and authentication examiner agents, driving the investigate → write → examine → improve loop.

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. Call the provenance researcher agent.
    2. Parse provenance researcher's reply and extract the dossier file path.
    3. If a dossier path is present, call the authentication examiner agent with prompt: "Please examine {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the authentication examiner 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 provenance, write dossiers, or do examinations yourself — delegate everything to the two sub-agents.
- If provenance researcher or authentication examiner errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- provenance researcher and authentication examiner each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`ideas.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any attribution or provenance issues — just pass file paths correctly.
</f2>

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

1. Update the dossier file's Examination section

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

```
## Examination

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

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

### Per-dimension examination

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Evidence references | pass/fail | ... |
| Significance description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Materiality | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the dossier needs changes. If the attribution or provenance concern 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 the artwork's attribution, provenance, title, exhibition, publication, conservation, or ownership history, or outside those areas but directly affecting authenticity or lawful transfer |
| Evidence references | Cited archive identifiers, object-file entries, catalogue records, inscriptions, labels, images, and document dates must exactly match the current collection file and cited sources |
| Significance description | Significance claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint the specific evidentiary gap, conflict, or document feature and explain why it matters |
| Evidence package | End-to-end set of checkable supporting materials from the researcher's perspective, sufficient for the authentication examiner to verify without inventing missing links |
| Reproducibility | Evidence trail can be followed end-to-end without manual reconstruction by the authentication examiner; chronology, object identity, and source citations must be clear enough to verify independently |
| Deduplication | Search the object file, prior condition and intake reports, catalogue raisonné notes, auction records, public databases, and prior authentication correspondence to confirm the issue is not already resolved or previously documented |
| Materiality | The concern must exceed a routine cataloguing uncertainty and materially affect attribution, authenticity confidence, legal title, restitution risk, or acquisition/consignment decision-making |

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

- References to nonexistent archives, catalogue entries, object-file documents, or AI-hallucinated inscriptions/signatures
- Significance description contradicts the dossier's own analysis
- Evidence package simulates support by inventing documents or altering quoted source text
- Evidence references inconsistent with the current collection file or cited public records
- Evidence package is incomplete and requires the authentication examiner to manually assemble the core chain of proof
- Concern is equivalent to a routine unresolved cataloguing note, with no material effect on attribution, authenticity, title, or decision-making
</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 fine-art provenance and authenticity vetting engagement for works being considered for acquisition, consignment, or catalogue inclusion.

Read the vetting standards first: ./vetting-guidelines.md
</f6>

<f7>
When you finish, briefly report to the registrar what you did.
</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. `# registrar`). Output only the headered prompts, no preamble.