I need you to set up a 3-agent pipeline for pharmaceutical clinical-trial safety signal assessment: signal coordinator, pharmacovigilance analyst, and regulatory safety reviewer.

- **signal coordinator** orchestrates: each round it selects which candidate adverse-event signal to assess next, calls the pharmacovigilance analyst on that signal, extracts the assessment report file path from the pharmacovigilance analyst's reply, then calls the regulatory safety reviewer on that path, decrements a counter, and loops. Does no medical or statistical analysis itself.
- **pharmacovigilance analyst** examines the clinical-trial safety materials for the signal it is given, writes an assessment report file, and records any new potential adverse-event signals it notices along the way.
- **regulatory safety reviewer** evaluates the assessment report against FDA-style safety-review criteria and persists the verdict.

I'm providing the following information:

<f1>
You drive the select → assess → review → improve loop: each round, select the next candidate signal, then alternate calls to the pharmacovigilance analyst and regulatory safety reviewer agents.

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

Loop:

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

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

**Calling rules**

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

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

<f2>
Each round, before calling the pharmacovigilance analyst, read signals.xml and select which candidate signal the pharmacovigilance analyst should work on:

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

<f3>
While exploring the clinical-trial safety materials, the moment you spot any potential new adverse-event signal — even if you are unsure it holds — immediately append it to signals.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a signal is not a commitment to pursue it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next candidate signal is selected.
</f3>

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

1. Update the assessment report file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Data references | pass/fail | ... |
| Safety impact description | pass/fail | ... |
| Causality analysis | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Prior knowledge and duplication | pass/fail | ... |
| Clinical amplification | pass/fail | ... |

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

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

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

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

<f6>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within clinical-trial safety data for the investigational product, or outside core safety tables but directly affecting safety interpretation |
| Data references | Cited datasets, tables, listings, variable names, subject IDs, visit windows, and derivations must exactly match the current locked safety-review package |
| Safety impact description | Safety concern consistent with the report's own evidence, no self-contradiction, no exaggeration beyond observed clinical significance |
| Causality analysis | Pinpoint specific evidence supporting or weakening causality: temporality, dechallenge/rechallenge, biological plausibility, dose relationship, alternative etiologies, and concomitant medications |
| Evidence package | End-to-end analysis from the safety reviewer’s perspective, using available clinical datasets or listings without altering source data to manufacture an effect |
| Reproducibility | Analysis runs or can be independently verified without manual reconstruction by the regulatory safety reviewer; denominators, exposure windows, seriousness criteria, and MedDRA coding levels must be explicit |
| Prior knowledge and duplication | Search the investigator brochure, protocol safety sections, DSUR/IB updates, prior safety review memos, medical-monitor notes, and public labeling/literature to confirm whether the signal is already known, already adjudicated, or already mitigated |
| Clinical amplification | The observed pattern must exceed the baseline of nonspecific background adverse events expected in this population and study design |

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

- References to nonexistent datasets, tables, variables, subject IDs, or AI-hallucinated clinical terms
- Safety impact description contradicts the report's own evidence
- Analysis simulates the signal by modifying source data or changing derivations without justification
- Data references inconsistent with the current locked safety-review package
- Evidence package is incomplete and requires the regulatory safety reviewer to manually assemble denominators, exposure windows, or subject narratives
- Observed effect is equivalent to nonspecific background noise, with no clinical or statistical amplification
</f6>

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

<f8>
You are participating in a blinded-but-operational pharmaceutical clinical-trial safety signal assessment exercise for an investigational therapy.

Read the assessment charter first: ./safety-assessment-charter.md
</f8>

<f9>
This development program has already been monitored through routine clinical safety review for multiple study milestones — any obvious imbalance or trivial coding error would likely have been noticed already. So:

- Don't escalate observations that are obvious at a glance without clinical relevance (e.g. "one mild headache appears in the active arm") — if it were that simple, the study team would already have handled it through routine safety surveillance
- Truly valuable safety signals hide in non-obvious patterns: timing after exposure, dose relationship, seriousness gradients, recurrence on rechallenge, related lab/vital-sign shifts, subgroup concentration, or confounding that has not been adequately ruled out

**Writing the assessment report**

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

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

- `## Signal Title` — concise, clear adverse-event signal title
- `## Potential Safety Impact` — what risk it may imply for participants, labeling, monitoring, dose modification, enrollment, or trial continuation
- `## Short Assessment` — short writeup of the evidence, with dataset/table/listing references and relevant subject-level details
- `## Evidence Details` — reproducible analysis steps, queries, tables, or code snippets the regulatory safety reviewer can run or inspect as-is to evaluate the signal

Do not modify or delete the `## Review` section — the regulatory 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 report file.
</f9>

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

I need you to set up a 3-agent pipeline for pharmaceutical clinical-trial safety signal assessment: signal coordinator, pharmacovigilance analyst, and regulatory safety reviewer.

- **signal coordinator** orchestrates: each round it selects which candidate adverse-event signal to assess next, calls the pharmacovigilance analyst on that signal, extracts the assessment report file path from the pharmacovigilance analyst's reply, then calls the regulatory safety reviewer on that path, decrements a counter, and loops. Does no medical or statistical analysis itself.
- **pharmacovigilance analyst** examines the clinical-trial safety materials for the signal it is given, writes an assessment report file, and records any new potential adverse-event signals it notices along the way.
- **regulatory safety reviewer** evaluates the assessment report against FDA-style safety-review criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
You drive the select → assess → review → improve loop: each round, select the next candidate signal, then alternate calls to the pharmacovigilance analyst and regulatory safety reviewer agents.

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

Loop:

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

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

**Calling rules**

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

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

<f2>
Each round, before calling the pharmacovigilance analyst, read signals.xml and select which candidate signal the pharmacovigilance analyst should work on:

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

<f3>
While exploring the clinical-trial safety materials, the moment you spot any potential new adverse-event signal — even if you are unsure it holds — immediately append it to signals.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a signal is not a commitment to pursue it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next candidate signal is selected.
</f3>

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

1. Update the assessment report file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Data references | pass/fail | ... |
| Safety impact description | pass/fail | ... |
| Causality analysis | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Prior knowledge and duplication | pass/fail | ... |
| Clinical amplification | pass/fail | ... |

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

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

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

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

<f6>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within clinical-trial safety data for the investigational product, or outside core safety tables but directly affecting safety interpretation |
| Data references | Cited datasets, tables, listings, variable names, subject IDs, visit windows, and derivations must exactly match the current locked safety-review package |
| Safety impact description | Safety concern consistent with the report's own evidence, no self-contradiction, no exaggeration beyond observed clinical significance |
| Causality analysis | Pinpoint specific evidence supporting or weakening causality: temporality, dechallenge/rechallenge, biological plausibility, dose relationship, alternative etiologies, and concomitant medications |
| Evidence package | End-to-end analysis from the safety reviewer’s perspective, using available clinical datasets or listings without altering source data to manufacture an effect |
| Reproducibility | Analysis runs or can be independently verified without manual reconstruction by the regulatory safety reviewer; denominators, exposure windows, seriousness criteria, and MedDRA coding levels must be explicit |
| Prior knowledge and duplication | Search the investigator brochure, protocol safety sections, DSUR/IB updates, prior safety review memos, medical-monitor notes, and public labeling/literature to confirm whether the signal is already known, already adjudicated, or already mitigated |
| Clinical amplification | The observed pattern must exceed the baseline of nonspecific background adverse events expected in this population and study design |

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

- References to nonexistent datasets, tables, variables, subject IDs, or AI-hallucinated clinical terms
- Safety impact description contradicts the report's own evidence
- Analysis simulates the signal by modifying source data or changing derivations without justification
- Data references inconsistent with the current locked safety-review package
- Evidence package is incomplete and requires the regulatory safety reviewer to manually assemble denominators, exposure windows, or subject narratives
- Observed effect is equivalent to nonspecific background noise, with no clinical or statistical amplification
</f6>

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

<f8>
You are participating in a blinded-but-operational pharmaceutical clinical-trial safety signal assessment exercise for an investigational therapy.

Read the assessment charter first: ./safety-assessment-charter.md
</f8>

<f9>
This development program has already been monitored through routine clinical safety review for multiple study milestones — any obvious imbalance or trivial coding error would likely have been noticed already. So:

- Don't escalate observations that are obvious at a glance without clinical relevance (e.g. "one mild headache appears in the active arm") — if it were that simple, the study team would already have handled it through routine safety surveillance
- Truly valuable safety signals hide in non-obvious patterns: timing after exposure, dose relationship, seriousness gradients, recurrence on rechallenge, related lab/vital-sign shifts, subgroup concentration, or confounding that has not been adequately ruled out

**Writing the assessment report**

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

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

- `## Signal Title` — concise, clear adverse-event signal title
- `## Potential Safety Impact` — what risk it may imply for participants, labeling, monitoring, dose modification, enrollment, or trial continuation
- `## Short Assessment` — short writeup of the evidence, with dataset/table/listing references and relevant subject-level details
- `## Evidence Details` — reproducible analysis steps, queries, tables, or code snippets the regulatory safety reviewer can run or inspect as-is to evaluate the signal

Do not modify or delete the `## Review` section — the regulatory 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 report file.
</f9>

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


case manager
provenance researcher
restitution examiner

I need you to set up a 3-agent pipeline for museum antiquities provenance investigation: case manager, provenance researcher, and restitution examiner.

- **case manager** orchestrates: each round it selects which contested artifact or lead to pursue next, calls the provenance researcher on that item, extracts the dossier file path from the provenance researcher's reply, then calls the restitution examiner on that path, decrements a counter, and loops. Does no substantive investigation itself.
- **provenance researcher** investigates the assigned artifact, writes a provenance dossier file, and records any new ownership gaps, suspicious documents, dealers, collectors, or source-country leads noticed along the way.
- **restitution examiner** evaluates the dossier against repatriation and documentation standards and persists the verdict.

I'm providing the following information:

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

<f2>
Each round, before calling the provenance researcher, read leads.xml and select which lead the provenance researcher should work on:

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

<f3>
While exploring provenance records, the moment you spot any potential new issue — even if you are unsure it holds — immediately append it to leads.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a lead is not a commitment to pursue it; it just keeps the concern from being forgotten. Whether it ever gets worked on is decided later, when the next lead is selected.
</f3>

<f4>
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 | ... |
| Source references | pass/fail | ... |
| Significance description | pass/fail | ... |
| Provenance gap analysis | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Repatriation relevance | pass/fail | ... |

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

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

<f5>
You drive the investigate → document → examine → improve loop: each round, select the next lead, then alternate calls to the provenance researcher and restitution examiner agents.

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

Loop:

```
while counter > 0:
    1. Select the next lead, then call the provenance researcher agent with it.
    2. Parse provenance researcher's reply and extract the dossier file path.
    3. If a dossier path is present, call the restitution examiner agent with prompt: "Please examine {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the restitution examiner was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** investigate provenance, write dossiers, or perform restitution examinations yourself — delegate everything to the two sub-agents.
- If provenance researcher or restitution 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 restitution examiner each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`leads.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any provenance issues — just pass file paths correctly.
</f5>

<f6>
You are participating in a museum antiquities provenance review focused on contested objects with possible illicit excavation, wartime displacement, forged export paperwork, or unresolved source-country claims.

Read the investigation protocol first: ./investigation-protocol.md
</f6>

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

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

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

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

<f8>
This collection has been cataloged and exhibited for many years — any obvious missing accession detail would likely have been noticed already. So:

- Don't overstate issues that are obvious at a glance (e.g. "the accession record lacks a photograph") — if it were that simple, the museum registrar or curatorial staff would probably already have addressed it
- Truly significant provenance problems hide in non-obvious ownership gaps, document inconsistencies, suspicious dealer networks, export-law timing, and mismatches between object type, findspot claims, and market history

**Writing the dossier**

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

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

- `## Dossier Title` — concise, clear title naming the artifact and provenance concern
- `## Significance Description` — what is at stake, such as possible illicit removal, Nazi-era forced sale, violation of source-country patrimony law, forged export license, or likely repatriation claim
- `## Short Description` — short writeup of the provenance problem, with references to accession records, correspondence, catalog entries, dealer invoices, archival sources, or legal dates
- `## Evidence Details` — concrete evidence the restitution examiner can verify as-is, including citations, document names, archive call numbers, database entries, or side-by-side inconsistencies

Do not modify or delete the `## Examination` section — the restitution examiner overwrites that themselves.

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

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Concerns antiquities or cultural objects in the museum collection, or external records directly affecting title, lawful export, ownership history, or repatriation risk |
| Source references | Cited accession files, archival documents, catalog entries, legal instruments, collection database fields, and dates must exactly match the current institutional records or cited public sources |
| Significance description | Significance claim consistent with the dossier's own evidence, no self-contradiction, no exaggeration |
| Provenance gap analysis | Pinpoint specific ownership intervals, transaction documents, export events, or custody transfers and explain why they create a problem |
| Evidence package | Verifiable evidence trail from the claimant/source-country or prior-owner perspective; must not rely on altered museum records or invented documents |
| Reproducibility | Examiner can verify the evidence end-to-end without manual reconstruction; document citations, URLs, archive call numbers, and database identifiers are complete |
| Deduplication | Search prior museum reviews, collection committee minutes, public claims databases, exhibition catalog updates, and known restitution settlements to confirm the issue is not already resolved or officially addressed |
| Repatriation relevance | The concern must exceed a minor cataloging imperfection and plausibly affect lawful title, ethical retention, claimant notification, or return negotiations |

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

- References to nonexistent records or AI-hallucinated archival call numbers
- Significance description contradicts the dossier's own evidence
- Evidence package depends on modifying or fabricating museum records
- Source references inconsistent with the current institutional files or cited public sources
- Evidence is incomplete and requires the restitution examiner to manually assemble the case
- Concern is equivalent to a minor cataloging cleanup, with no plausible ownership, legal, ethical, or repatriation consequence
</f9>

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

I need you to set up a 3-agent pipeline for museum antiquities provenance investigation: case manager, provenance researcher, and restitution examiner.

- **case manager** orchestrates: each round it selects which contested artifact or lead to pursue next, calls the provenance researcher on that item, extracts the dossier file path from the provenance researcher's reply, then calls the restitution examiner on that path, decrements a counter, and loops. Does no substantive investigation itself.
- **provenance researcher** investigates the assigned artifact, writes a provenance dossier file, and records any new ownership gaps, suspicious documents, dealers, collectors, or source-country leads noticed along the way.
- **restitution examiner** evaluates the dossier against repatriation and documentation standards and persists the verdict.

I'm providing the following prompt fragments:

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

<f2>
Each round, before calling the provenance researcher, read leads.xml and select which lead the provenance researcher should work on:

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

<f3>
While exploring provenance records, the moment you spot any potential new issue — even if you are unsure it holds — immediately append it to leads.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a lead is not a commitment to pursue it; it just keeps the concern from being forgotten. Whether it ever gets worked on is decided later, when the next lead is selected.
</f3>

<f4>
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 | ... |
| Source references | pass/fail | ... |
| Significance description | pass/fail | ... |
| Provenance gap analysis | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Repatriation relevance | pass/fail | ... |

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

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

<f5>
You drive the investigate → document → examine → improve loop: each round, select the next lead, then alternate calls to the provenance researcher and restitution examiner agents.

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

Loop:

```
while counter > 0:
    1. Select the next lead, then call the provenance researcher agent with it.
    2. Parse provenance researcher's reply and extract the dossier file path.
    3. If a dossier path is present, call the restitution examiner agent with prompt: "Please examine {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the restitution examiner was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** investigate provenance, write dossiers, or perform restitution examinations yourself — delegate everything to the two sub-agents.
- If provenance researcher or restitution 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 restitution examiner each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`leads.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any provenance issues — just pass file paths correctly.
</f5>

<f6>
You are participating in a museum antiquities provenance review focused on contested objects with possible illicit excavation, wartime displacement, forged export paperwork, or unresolved source-country claims.

Read the investigation protocol first: ./investigation-protocol.md
</f6>

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

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

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

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

<f8>
This collection has been cataloged and exhibited for many years — any obvious missing accession detail would likely have been noticed already. So:

- Don't overstate issues that are obvious at a glance (e.g. "the accession record lacks a photograph") — if it were that simple, the museum registrar or curatorial staff would probably already have addressed it
- Truly significant provenance problems hide in non-obvious ownership gaps, document inconsistencies, suspicious dealer networks, export-law timing, and mismatches between object type, findspot claims, and market history

**Writing the dossier**

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

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

- `## Dossier Title` — concise, clear title naming the artifact and provenance concern
- `## Significance Description` — what is at stake, such as possible illicit removal, Nazi-era forced sale, violation of source-country patrimony law, forged export license, or likely repatriation claim
- `## Short Description` — short writeup of the provenance problem, with references to accession records, correspondence, catalog entries, dealer invoices, archival sources, or legal dates
- `## Evidence Details` — concrete evidence the restitution examiner can verify as-is, including citations, document names, archive call numbers, database entries, or side-by-side inconsistencies

Do not modify or delete the `## Examination` section — the restitution examiner overwrites that themselves.

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

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Concerns antiquities or cultural objects in the museum collection, or external records directly affecting title, lawful export, ownership history, or repatriation risk |
| Source references | Cited accession files, archival documents, catalog entries, legal instruments, collection database fields, and dates must exactly match the current institutional records or cited public sources |
| Significance description | Significance claim consistent with the dossier's own evidence, no self-contradiction, no exaggeration |
| Provenance gap analysis | Pinpoint specific ownership intervals, transaction documents, export events, or custody transfers and explain why they create a problem |
| Evidence package | Verifiable evidence trail from the claimant/source-country or prior-owner perspective; must not rely on altered museum records or invented documents |
| Reproducibility | Examiner can verify the evidence end-to-end without manual reconstruction; document citations, URLs, archive call numbers, and database identifiers are complete |
| Deduplication | Search prior museum reviews, collection committee minutes, public claims databases, exhibition catalog updates, and known restitution settlements to confirm the issue is not already resolved or officially addressed |
| Repatriation relevance | The concern must exceed a minor cataloging imperfection and plausibly affect lawful title, ethical retention, claimant notification, or return negotiations |

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

- References to nonexistent records or AI-hallucinated archival call numbers
- Significance description contradicts the dossier's own evidence
- Evidence package depends on modifying or fabricating museum records
- Source references inconsistent with the current institutional files or cited public sources
- Evidence is incomplete and requires the restitution examiner to manually assemble the case
- Concern is equivalent to a minor cataloging cleanup, with no plausible ownership, legal, ethical, or repatriation consequence
</f9>

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


I need you to set up a 3-agent pipeline for museum antiquities provenance investigation: case manager, provenance researcher, and restitution examiner.

- **case manager** orchestrates: each round it selects which contested artifact or lead to pursue next, calls the provenance researcher on that item, extracts the dossier file path from the provenance researcher's reply, then calls the restitution examiner on that path, decrements a counter, and loops. Does no substantive investigation itself.
- **provenance researcher** investigates the assigned artifact, writes a provenance dossier file, and records any new ownership gaps, suspicious documents, dealers, collectors, or source-country leads noticed along the way.
- **restitution examiner** evaluates the dossier against repatriation and documentation standards and persists the verdict.

I'm providing the following information:

<f1>
You drive the investigate → document → examine → improve loop: each round, select the next lead, then alternate calls to the provenance researcher and restitution examiner agents.

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

Loop:

```
while counter > 0:
    1. Select the next lead, then call the provenance researcher agent with it.
    2. Parse provenance researcher's reply and extract the dossier file path.
    3. If a dossier path is present, call the restitution examiner agent with prompt: "Please examine {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the restitution examiner was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** investigate provenance, write dossiers, or perform restitution examinations yourself — delegate everything to the two sub-agents.
- If provenance researcher or restitution 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 restitution examiner each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`leads.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any provenance issues — just pass file paths correctly.
</f1>

<f2>
Each round, before calling the provenance researcher, read leads.xml and select which lead the provenance researcher should work on:

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

<f3>
While exploring provenance records, the moment you spot any potential new issue — even if you are unsure it holds — immediately append it to leads.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a lead is not a commitment to pursue it; it just keeps the concern from being forgotten. Whether it ever gets worked on is decided later, when the next lead is selected.
</f3>

<f4>
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 | ... |
| Source references | pass/fail | ... |
| Significance description | pass/fail | ... |
| Provenance gap analysis | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Repatriation relevance | pass/fail | ... |

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

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

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

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

<f6>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Concerns antiquities or cultural objects in the museum collection, or external records directly affecting title, lawful export, ownership history, or repatriation risk |
| Source references | Cited accession files, archival documents, catalog entries, legal instruments, collection database fields, and dates must exactly match the current institutional records or cited public sources |
| Significance description | Significance claim consistent with the dossier's own evidence, no self-contradiction, no exaggeration |
| Provenance gap analysis | Pinpoint specific ownership intervals, transaction documents, export events, or custody transfers and explain why they create a problem |
| Evidence package | Verifiable evidence trail from the claimant/source-country or prior-owner perspective; must not rely on altered museum records or invented documents |
| Reproducibility | Examiner can verify the evidence end-to-end without manual reconstruction; document citations, URLs, archive call numbers, and database identifiers are complete |
| Deduplication | Search prior museum reviews, collection committee minutes, public claims databases, exhibition catalog updates, and known restitution settlements to confirm the issue is not already resolved or officially addressed |
| Repatriation relevance | The concern must exceed a minor cataloging imperfection and plausibly affect lawful title, ethical retention, claimant notification, or return negotiations |

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

- References to nonexistent records or AI-hallucinated archival call numbers
- Significance description contradicts the dossier's own evidence
- Evidence package depends on modifying or fabricating museum records
- Source references inconsistent with the current institutional files or cited public sources
- Evidence is incomplete and requires the restitution examiner to manually assemble the case
- Concern is equivalent to a minor cataloging cleanup, with no plausible ownership, legal, ethical, or repatriation consequence
</f6>

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

<f8>
You are participating in a museum antiquities provenance review focused on contested objects with possible illicit excavation, wartime displacement, forged export paperwork, or unresolved source-country claims.

Read the investigation protocol first: ./investigation-protocol.md
</f8>

<f9>
This collection has been cataloged and exhibited for many years — any obvious missing accession detail would likely have been noticed already. So:

- Don't overstate issues that are obvious at a glance (e.g. "the accession record lacks a photograph") — if it were that simple, the museum registrar or curatorial staff would probably already have addressed it
- Truly significant provenance problems hide in non-obvious ownership gaps, document inconsistencies, suspicious dealer networks, export-law timing, and mismatches between object type, findspot claims, and market history

**Writing the dossier**

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

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

- `## Dossier Title` — concise, clear title naming the artifact and provenance concern
- `## Significance Description` — what is at stake, such as possible illicit removal, Nazi-era forced sale, violation of source-country patrimony law, forged export license, or likely repatriation claim
- `## Short Description` — short writeup of the provenance problem, with references to accession records, correspondence, catalog entries, dealer invoices, archival sources, or legal dates
- `## Evidence Details` — concrete evidence the restitution examiner can verify as-is, including citations, document names, archive call numbers, database entries, or side-by-side inconsistencies

Do not modify or delete the `## Examination` section — the restitution examiner overwrites that themselves.

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

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

I need you to set up a 3-agent pipeline for museum antiquities provenance investigation: case manager, provenance researcher, and restitution examiner.

- **case manager** orchestrates: each round it selects which contested artifact or lead to pursue next, calls the provenance researcher on that item, extracts the dossier file path from the provenance researcher's reply, then calls the restitution examiner on that path, decrements a counter, and loops. Does no substantive investigation itself.
- **provenance researcher** investigates the assigned artifact, writes a provenance dossier file, and records any new ownership gaps, suspicious documents, dealers, collectors, or source-country leads noticed along the way.
- **restitution examiner** evaluates the dossier against repatriation and documentation standards and persists the verdict.

I'm providing the following prompt fragments:

<f1>
You drive the investigate → document → examine → improve loop: each round, select the next lead, then alternate calls to the provenance researcher and restitution examiner agents.

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

Loop:

```
while counter > 0:
    1. Select the next lead, then call the provenance researcher agent with it.
    2. Parse provenance researcher's reply and extract the dossier file path.
    3. If a dossier path is present, call the restitution examiner agent with prompt: "Please examine {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the restitution examiner was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** investigate provenance, write dossiers, or perform restitution examinations yourself — delegate everything to the two sub-agents.
- If provenance researcher or restitution 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 restitution examiner each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`leads.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any provenance issues — just pass file paths correctly.
</f1>

<f2>
Each round, before calling the provenance researcher, read leads.xml and select which lead the provenance researcher should work on:

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

<f3>
While exploring provenance records, the moment you spot any potential new issue — even if you are unsure it holds — immediately append it to leads.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a lead is not a commitment to pursue it; it just keeps the concern from being forgotten. Whether it ever gets worked on is decided later, when the next lead is selected.
</f3>

<f4>
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 | ... |
| Source references | pass/fail | ... |
| Significance description | pass/fail | ... |
| Provenance gap analysis | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Repatriation relevance | pass/fail | ... |

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

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

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

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

<f6>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Concerns antiquities or cultural objects in the museum collection, or external records directly affecting title, lawful export, ownership history, or repatriation risk |
| Source references | Cited accession files, archival documents, catalog entries, legal instruments, collection database fields, and dates must exactly match the current institutional records or cited public sources |
| Significance description | Significance claim consistent with the dossier's own evidence, no self-contradiction, no exaggeration |
| Provenance gap analysis | Pinpoint specific ownership intervals, transaction documents, export events, or custody transfers and explain why they create a problem |
| Evidence package | Verifiable evidence trail from the claimant/source-country or prior-owner perspective; must not rely on altered museum records or invented documents |
| Reproducibility | Examiner can verify the evidence end-to-end without manual reconstruction; document citations, URLs, archive call numbers, and database identifiers are complete |
| Deduplication | Search prior museum reviews, collection committee minutes, public claims databases, exhibition catalog updates, and known restitution settlements to confirm the issue is not already resolved or officially addressed |
| Repatriation relevance | The concern must exceed a minor cataloging imperfection and plausibly affect lawful title, ethical retention, claimant notification, or return negotiations |

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

- References to nonexistent records or AI-hallucinated archival call numbers
- Significance description contradicts the dossier's own evidence
- Evidence package depends on modifying or fabricating museum records
- Source references inconsistent with the current institutional files or cited public sources
- Evidence is incomplete and requires the restitution examiner to manually assemble the case
- Concern is equivalent to a minor cataloging cleanup, with no plausible ownership, legal, ethical, or repatriation consequence
</f6>

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

<f8>
You are participating in a museum antiquities provenance review focused on contested objects with possible illicit excavation, wartime displacement, forged export paperwork, or unresolved source-country claims.

Read the investigation protocol first: ./investigation-protocol.md
</f8>

<f9>
This collection has been cataloged and exhibited for many years — any obvious missing accession detail would likely have been noticed already. So:

- Don't overstate issues that are obvious at a glance (e.g. "the accession record lacks a photograph") — if it were that simple, the museum registrar or curatorial staff would probably already have addressed it
- Truly significant provenance problems hide in non-obvious ownership gaps, document inconsistencies, suspicious dealer networks, export-law timing, and mismatches between object type, findspot claims, and market history

**Writing the dossier**

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

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

- `## Dossier Title` — concise, clear title naming the artifact and provenance concern
- `## Significance Description` — what is at stake, such as possible illicit removal, Nazi-era forced sale, violation of source-country patrimony law, forged export license, or likely repatriation claim
- `## Short Description` — short writeup of the provenance problem, with references to accession records, correspondence, catalog entries, dealer invoices, archival sources, or legal dates
- `## Evidence Details` — concrete evidence the restitution examiner can verify as-is, including citations, document names, archive call numbers, database entries, or side-by-side inconsistencies

Do not modify or delete the `## Examination` section — the restitution examiner overwrites that themselves.

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

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


permitting coordinator
impact modeler
environmental auditor

I need you to set up a 3-agent pipeline for environmental impact permitting on a major infrastructure project: permitting coordinator, impact modeler, and environmental auditor.

- **permitting coordinator** orchestrates: each round it selects which risk hypothesis to pursue next, calls the impact modeler on that hypothesis, extracts the assessment file path from the impact modeler's reply, then calls the environmental auditor on that path, decrements a counter, and loops. Does no technical analysis itself.
- **impact modeler** examines the permit application, baseline studies, design drawings, monitoring data, and regulatory context for the hypothesis it is given, writes an impact assessment file, and records any new risk hypotheses it notices along the way.
- **environmental auditor** evaluates the assessment against permitting criteria and persists the audit verdict.

I'm providing the following information:

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

<f2>
Each round, before calling the impact modeler, read ideas.xml and select which risk hypothesis the impact modeler should work on:

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

<f3>
While exploring the permit application, technical appendices, design drawings, baseline studies, agency correspondence, or environmental datasets, the moment you spot any potential new risk hypothesis — even if you are unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a hypothesis is not a commitment to pursue it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next hypothesis is selected.
</f3>

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

1. Update the assessment file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Source references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Verification package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Significance beyond baseline | pass/fail | ... |

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

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

<f5>
You drive the explore → write → audit → improve loop: each round, select the next risk hypothesis, then alternate calls to the impact modeler and environmental auditor agents.

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

Loop:

```
while counter > 0:
    1. Select the next risk hypothesis, then call the impact modeler agent with it.
    2. Parse impact modeler's reply and extract the assessment file path.
    3. If an assessment path is present, call the environmental auditor agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the environmental auditor was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze permit materials, write assessments, or do audits yourself — delegate everything to the two sub-agents.
- If impact modeler or environmental auditor errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- impact modeler and environmental auditor 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 environmental impacts — just pass file paths correctly.
</f5>

<f6>
You are supporting environmental impact permitting for a major infrastructure project with potentially significant effects on wetlands, waterways, habitat, air quality, noise, traffic, environmental justice communities, and cumulative regional impacts.

Read the permitting instructions first: ./permit-review-rules.md
</f6>

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

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

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

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

<f8>
This project has already gone through years of planning, public scoping, and consultant review — any obvious permitting issue would likely already be addressed in the application materials. So:

- Don't focus on impacts that are obvious at a glance, such as "construction creates dust" or "the alignment crosses a mapped wetland" — if it were that straightforward, the applicant's environmental team would have included a standard mitigation measure
- Truly important permitting risks often hide in non-obvious interactions, seasonal assumptions, model boundary choices, cumulative stressors, monitoring gaps, and mismatches between design drawings and environmental baselines

**Writing the assessment**

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

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

- `## Assessment Title` — concise, clear title for the potential permitting issue
- `## Impact Description` — what harm it could cause, such as wetland loss, habitat fragmentation, exceedance of air or noise thresholds, water-quality degradation, floodplain effects, or disproportionate community burden
- `## Short Description` — short writeup of what appears wrong, with references to specific application documents, drawings, tables, appendices, model inputs, or regulatory requirements
- `## Reproduction Details` — the calculations, GIS steps, model rerun instructions, or document cross-checks the environmental auditor can perform as-is to verify the issue

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

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

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the project’s permitting footprint, affected resource areas, construction methods, mitigation commitments, or cumulative impact setting |
| Source references | Cited permit application sections, drawing numbers, model files, monitoring datasets, appendix tables, and regulatory provisions must exactly match the latest submitted permit package |
| Impact description | Impact claim consistent with the assessment's own analysis, no self-contradiction, no exaggeration beyond what the data support |
| Root cause analysis | Pinpoint specific assumptions, inputs, omissions, spatial boundaries, time windows, or mitigation gaps and explain why they create a permitting risk |
| Verification package | End-to-end calculation, GIS overlay, model rerun, or document comparison demonstrating the issue from the regulator’s perspective without altering applicant materials to manufacture the result |
| Reproducibility | Verification steps run end-to-end without manual assembly by the environmental auditor; major-impact claims must be reproducible using the cited permit package, public datasets, and stated assumptions |
| Deduplication | Search the permit docket, agency comment letters, prior deficiency notices, public hearing materials, and applicant responses to confirm the issue was not already raised and resolved |
| Significance beyond baseline | The alleged effect must exceed ordinary construction disturbance or already-disclosed baseline impacts, and must show a material permitting or mitigation consequence |

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

- References to nonexistent application materials, fabricated datasets, or AI-hallucinated permit sections
- Impact description contradicts the assessment's own analysis
- Verification simulates the harm by changing applicant assumptions or design files without justification
- Source references inconsistent with the latest submitted permit package
- Verification package is incomplete and requires the environmental auditor to manually assemble missing inputs
- Claimed effect is equivalent to ordinary disclosed construction disturbance, with no material increase in environmental harm or permitting significance
</f9>

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

I need you to set up a 3-agent pipeline for environmental impact permitting on a major infrastructure project: permitting coordinator, impact modeler, and environmental auditor.

- **permitting coordinator** orchestrates: each round it selects which risk hypothesis to pursue next, calls the impact modeler on that hypothesis, extracts the assessment file path from the impact modeler's reply, then calls the environmental auditor on that path, decrements a counter, and loops. Does no technical analysis itself.
- **impact modeler** examines the permit application, baseline studies, design drawings, monitoring data, and regulatory context for the hypothesis it is given, writes an impact assessment file, and records any new risk hypotheses it notices along the way.
- **environmental auditor** evaluates the assessment against permitting criteria and persists the audit verdict.

I'm providing the following prompt fragments:

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

<f2>
Each round, before calling the impact modeler, read ideas.xml and select which risk hypothesis the impact modeler should work on:

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

<f3>
While exploring the permit application, technical appendices, design drawings, baseline studies, agency correspondence, or environmental datasets, the moment you spot any potential new risk hypothesis — even if you are unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a hypothesis is not a commitment to pursue it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next hypothesis is selected.
</f3>

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

1. Update the assessment file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Source references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Verification package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Significance beyond baseline | pass/fail | ... |

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

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

<f5>
You drive the explore → write → audit → improve loop: each round, select the next risk hypothesis, then alternate calls to the impact modeler and environmental auditor agents.

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

Loop:

```
while counter > 0:
    1. Select the next risk hypothesis, then call the impact modeler agent with it.
    2. Parse impact modeler's reply and extract the assessment file path.
    3. If an assessment path is present, call the environmental auditor agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the environmental auditor was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze permit materials, write assessments, or do audits yourself — delegate everything to the two sub-agents.
- If impact modeler or environmental auditor errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- impact modeler and environmental auditor 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 environmental impacts — just pass file paths correctly.
</f5>

<f6>
You are supporting environmental impact permitting for a major infrastructure project with potentially significant effects on wetlands, waterways, habitat, air quality, noise, traffic, environmental justice communities, and cumulative regional impacts.

Read the permitting instructions first: ./permit-review-rules.md
</f6>

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

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

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

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

<f8>
This project has already gone through years of planning, public scoping, and consultant review — any obvious permitting issue would likely already be addressed in the application materials. So:

- Don't focus on impacts that are obvious at a glance, such as "construction creates dust" or "the alignment crosses a mapped wetland" — if it were that straightforward, the applicant's environmental team would have included a standard mitigation measure
- Truly important permitting risks often hide in non-obvious interactions, seasonal assumptions, model boundary choices, cumulative stressors, monitoring gaps, and mismatches between design drawings and environmental baselines

**Writing the assessment**

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

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

- `## Assessment Title` — concise, clear title for the potential permitting issue
- `## Impact Description` — what harm it could cause, such as wetland loss, habitat fragmentation, exceedance of air or noise thresholds, water-quality degradation, floodplain effects, or disproportionate community burden
- `## Short Description` — short writeup of what appears wrong, with references to specific application documents, drawings, tables, appendices, model inputs, or regulatory requirements
- `## Reproduction Details` — the calculations, GIS steps, model rerun instructions, or document cross-checks the environmental auditor can perform as-is to verify the issue

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

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

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the project’s permitting footprint, affected resource areas, construction methods, mitigation commitments, or cumulative impact setting |
| Source references | Cited permit application sections, drawing numbers, model files, monitoring datasets, appendix tables, and regulatory provisions must exactly match the latest submitted permit package |
| Impact description | Impact claim consistent with the assessment's own analysis, no self-contradiction, no exaggeration beyond what the data support |
| Root cause analysis | Pinpoint specific assumptions, inputs, omissions, spatial boundaries, time windows, or mitigation gaps and explain why they create a permitting risk |
| Verification package | End-to-end calculation, GIS overlay, model rerun, or document comparison demonstrating the issue from the regulator’s perspective without altering applicant materials to manufacture the result |
| Reproducibility | Verification steps run end-to-end without manual assembly by the environmental auditor; major-impact claims must be reproducible using the cited permit package, public datasets, and stated assumptions |
| Deduplication | Search the permit docket, agency comment letters, prior deficiency notices, public hearing materials, and applicant responses to confirm the issue was not already raised and resolved |
| Significance beyond baseline | The alleged effect must exceed ordinary construction disturbance or already-disclosed baseline impacts, and must show a material permitting or mitigation consequence |

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

- References to nonexistent application materials, fabricated datasets, or AI-hallucinated permit sections
- Impact description contradicts the assessment's own analysis
- Verification simulates the harm by changing applicant assumptions or design files without justification
- Source references inconsistent with the latest submitted permit package
- Verification package is incomplete and requires the environmental auditor to manually assemble missing inputs
- Claimed effect is equivalent to ordinary disclosed construction disturbance, with no material increase in environmental harm or permitting significance
</f9>

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