provenance researcher
authentication curator

I need you to set up a 2-agent pipeline for a museum provenance and authenticity challenge. The two roles are provenance researcher and authentication curator: provenance researcher is responsible for developing claims that an artifact is forged, misattributed, or illicitly sourced; authentication curator is responsible for judging whether the evidence is strong enough to support the claim. The flow is roughly:

```
WHILE TRUE:
    1. provenance researcher picks a lead it likes and explores it deeply, or appends more leads to ideas.xml and then picks one to explore.
    2. provenance researcher spawns a **fresh** authentication curator to evaluate it.
```

I'm providing the following information:

<f1>
After developing a claim, submit it to a **fresh** authentication curator for review. Do not review your own dossier.

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

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

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

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

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

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

1. Each lead's notes contain the authentication curator's **quality score (0-10)**. A score of 0 means the lead is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer leads with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no lead is worth trying, search the collection records, catalogue history, image files, conservation notes, auction references, and published scholarship for new leads, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

While exploring object records and source material, the moment you spot any potential new provenance or authenticity concern — even if you're unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the challenge collection, or outside it but directly affecting the artifact's attribution, authenticity, ownership chain, export history, or acquisition legality |
| Source references | Cited accession records, catalogue numbers, archive call numbers, publication details, image identifiers, and quoted passages must exactly match the current object records and cited sources |
| Significance description | Significance claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration |
| Evidentiary root cause | Pinpoint the specific break, conflict, or anomaly in the provenance or authenticity record and explain why it matters |
| Evidence package | End-to-end set of primary or authoritative secondary sources showing the issue from the researcher's perspective; must not rely on altered images, invented records, or circular assertions |
| Verifiability | Evidence can be checked end-to-end without manual reconstruction by the authentication curator; major authenticity or illicit-source claims must be supportable from stable records, cited images, or named repositories |
| Deduplication | Search the museum catalogue, prior exhibition catalogues, scholarly literature, restitution databases, auction archives, and public discussions to confirm the issue has not already been reported, resolved, or formally acknowledged |
| Materiality | The claim must exceed the baseline of "the provenance has an ordinary undocumented gap" and show a specific reason to suspect forgery, misattribution, illicit export, laundering, or false ownership history |

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

- References to nonexistent archives, invented accession numbers, or AI-hallucinated catalogue entries
- Significance description contradicts the dossier's own analysis
- Evidence package simulates the issue by altering photographs, metadata, or transcripts
- Source references inconsistent with the current object records or cited publications
- Evidence package is incomplete and requires the authentication curator to manually assemble the core proof
- Claimed issue is equivalent to an ordinary undocumented provenance gap, with no specific suspicious conflict or material implication
</f4>

<f5>
You are participating in a museum provenance and authenticity challenge focused on identifying artifacts that may be forged, misattributed, or illicitly sourced.

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

<f6>
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 | ... |
| Significance description | pass/fail | ... |
| Evidentiary root cause | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Verifiability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Materiality | 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 ideas.xml: increment attempts by 1, then update score.
</f6>

<f7>
This collection has been catalogued, exhibited, and cited for many years — any obvious problem would likely have been noticed by registrars, curators, or outside scholars. So:

- Don't report issues that are obvious at a glance (e.g. "the acquisition date is missing from the public label") — if it were that straightforward, the museum would probably already have documented or corrected it
- Truly valuable claims hide in non-obvious conflicts among archives, ownership transfers, export records, conservation data, stylistic evidence, and publication history

**Writing the claim dossier**

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

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

- `## Claim Title` — concise, clear statement of the suspected forgery, misattribution, or illicit provenance issue
- `## Significance Description` — what the claim would imply for the artifact, the collection, prior scholarship, legal exposure, repatriation risk, or exhibition history
- `## Short Description` — short writeup of the evidentiary problem, with inventory numbers, catalogue entries, archive references, and object-record citations
- `## Evidence Details` — a verifiable evidence package the authentication curator can inspect as-is to assess the claim

Do not modify or delete the `## Review` section — the authentication curator 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.
</f7>

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

I need you to set up a 2-agent pipeline for a museum provenance and authenticity challenge. The two roles are provenance researcher and authentication curator: provenance researcher is responsible for developing claims that an artifact is forged, misattributed, or illicitly sourced; authentication curator is responsible for judging whether the evidence is strong enough to support the claim. The flow is roughly:

```
WHILE TRUE:
    1. provenance researcher picks a lead it likes and explores it deeply, or appends more leads to ideas.xml and then picks one to explore.
    2. provenance researcher spawns a **fresh** authentication curator to evaluate it.
```

I'm providing the following prompt fragments:

<f1>
After developing a claim, submit it to a **fresh** authentication curator for review. Do not review your own dossier.

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

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

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

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

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

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

1. Each lead's notes contain the authentication curator's **quality score (0-10)**. A score of 0 means the lead is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer leads with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no lead is worth trying, search the collection records, catalogue history, image files, conservation notes, auction references, and published scholarship for new leads, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

While exploring object records and source material, the moment you spot any potential new provenance or authenticity concern — even if you're unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the challenge collection, or outside it but directly affecting the artifact's attribution, authenticity, ownership chain, export history, or acquisition legality |
| Source references | Cited accession records, catalogue numbers, archive call numbers, publication details, image identifiers, and quoted passages must exactly match the current object records and cited sources |
| Significance description | Significance claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration |
| Evidentiary root cause | Pinpoint the specific break, conflict, or anomaly in the provenance or authenticity record and explain why it matters |
| Evidence package | End-to-end set of primary or authoritative secondary sources showing the issue from the researcher's perspective; must not rely on altered images, invented records, or circular assertions |
| Verifiability | Evidence can be checked end-to-end without manual reconstruction by the authentication curator; major authenticity or illicit-source claims must be supportable from stable records, cited images, or named repositories |
| Deduplication | Search the museum catalogue, prior exhibition catalogues, scholarly literature, restitution databases, auction archives, and public discussions to confirm the issue has not already been reported, resolved, or formally acknowledged |
| Materiality | The claim must exceed the baseline of "the provenance has an ordinary undocumented gap" and show a specific reason to suspect forgery, misattribution, illicit export, laundering, or false ownership history |

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

- References to nonexistent archives, invented accession numbers, or AI-hallucinated catalogue entries
- Significance description contradicts the dossier's own analysis
- Evidence package simulates the issue by altering photographs, metadata, or transcripts
- Source references inconsistent with the current object records or cited publications
- Evidence package is incomplete and requires the authentication curator to manually assemble the core proof
- Claimed issue is equivalent to an ordinary undocumented provenance gap, with no specific suspicious conflict or material implication
</f4>

<f5>
You are participating in a museum provenance and authenticity challenge focused on identifying artifacts that may be forged, misattributed, or illicitly sourced.

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

<f6>
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 | ... |
| Significance description | pass/fail | ... |
| Evidentiary root cause | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Verifiability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Materiality | 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 ideas.xml: increment attempts by 1, then update score.
</f6>

<f7>
This collection has been catalogued, exhibited, and cited for many years — any obvious problem would likely have been noticed by registrars, curators, or outside scholars. So:

- Don't report issues that are obvious at a glance (e.g. "the acquisition date is missing from the public label") — if it were that straightforward, the museum would probably already have documented or corrected it
- Truly valuable claims hide in non-obvious conflicts among archives, ownership transfers, export records, conservation data, stylistic evidence, and publication history

**Writing the claim dossier**

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

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

- `## Claim Title` — concise, clear statement of the suspected forgery, misattribution, or illicit provenance issue
- `## Significance Description` — what the claim would imply for the artifact, the collection, prior scholarship, legal exposure, repatriation risk, or exhibition history
- `## Short Description` — short writeup of the evidentiary problem, with inventory numbers, catalogue entries, archive references, and object-record citations
- `## Evidence Details` — a verifiable evidence package the authentication curator can inspect as-is to assess the claim

Do not modify or delete the `## Review` section — the authentication curator 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.
</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. `# provenance researcher`). Output only the headered prompts, no preamble.


I need you to set up a 2-agent pipeline for a museum provenance and authenticity challenge. The two roles are provenance researcher and authentication curator: provenance researcher is responsible for developing claims that an artifact is forged, misattributed, or illicitly sourced; authentication curator is responsible for judging whether the evidence is strong enough to support the claim. The flow is roughly:

```
WHILE TRUE:
    1. provenance researcher picks a lead it likes and explores it deeply, or appends more leads to ideas.xml and then picks one to explore.
    2. provenance researcher spawns a **fresh** authentication curator to evaluate it.
```

I'm providing the following information:

<f1>
This collection has been catalogued, exhibited, and cited for many years — any obvious problem would likely have been noticed by registrars, curators, or outside scholars. So:

- Don't report issues that are obvious at a glance (e.g. "the acquisition date is missing from the public label") — if it were that straightforward, the museum would probably already have documented or corrected it
- Truly valuable claims hide in non-obvious conflicts among archives, ownership transfers, export records, conservation data, stylistic evidence, and publication history

**Writing the claim dossier**

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

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

- `## Claim Title` — concise, clear statement of the suspected forgery, misattribution, or illicit provenance issue
- `## Significance Description` — what the claim would imply for the artifact, the collection, prior scholarship, legal exposure, repatriation risk, or exhibition history
- `## Short Description` — short writeup of the evidentiary problem, with inventory numbers, catalogue entries, archive references, and object-record citations
- `## Evidence Details` — a verifiable evidence package the authentication curator can inspect as-is to assess the claim

Do not modify or delete the `## Review` section — the authentication curator 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.
</f1>

<f2>
After developing a claim, submit it to a **fresh** authentication curator for review. Do not review your own dossier.

**After the review returns:** execute all action steps in the authentication curator's output. Then immediately go back to step 1: re-read ideas.xml and pick the next lead by UCB to keep working. Don't wait for user instructions, don't stop. One round = write dossier → review → execute actions → back to step 1.
</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 | ... |
| Significance description | pass/fail | ... |
| Evidentiary root cause | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Verifiability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Materiality | 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 ideas.xml: increment attempts by 1, then update score.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the challenge collection, or outside it but directly affecting the artifact's attribution, authenticity, ownership chain, export history, or acquisition legality |
| Source references | Cited accession records, catalogue numbers, archive call numbers, publication details, image identifiers, and quoted passages must exactly match the current object records and cited sources |
| Significance description | Significance claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration |
| Evidentiary root cause | Pinpoint the specific break, conflict, or anomaly in the provenance or authenticity record and explain why it matters |
| Evidence package | End-to-end set of primary or authoritative secondary sources showing the issue from the researcher's perspective; must not rely on altered images, invented records, or circular assertions |
| Verifiability | Evidence can be checked end-to-end without manual reconstruction by the authentication curator; major authenticity or illicit-source claims must be supportable from stable records, cited images, or named repositories |
| Deduplication | Search the museum catalogue, prior exhibition catalogues, scholarly literature, restitution databases, auction archives, and public discussions to confirm the issue has not already been reported, resolved, or formally acknowledged |
| Materiality | The claim must exceed the baseline of "the provenance has an ordinary undocumented gap" and show a specific reason to suspect forgery, misattribution, illicit export, laundering, or false ownership history |

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

- References to nonexistent archives, invented accession numbers, or AI-hallucinated catalogue entries
- Significance description contradicts the dossier's own analysis
- Evidence package simulates the issue by altering photographs, metadata, or transcripts
- Source references inconsistent with the current object records or cited publications
- Evidence package is incomplete and requires the authentication curator to manually assemble the core proof
- Claimed issue is equivalent to an ordinary undocumented provenance gap, with no specific suspicious conflict or material implication
</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 museum provenance and authenticity challenge focused on identifying artifacts that may be forged, misattributed, or illicitly sourced.

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

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

1. Each lead's notes contain the authentication curator's **quality score (0-10)**. A score of 0 means the lead is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer leads with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no lead is worth trying, search the collection records, catalogue history, image files, conservation notes, auction references, and published scholarship for new leads, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

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

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

I need you to set up a 2-agent pipeline for a museum provenance and authenticity challenge. The two roles are provenance researcher and authentication curator: provenance researcher is responsible for developing claims that an artifact is forged, misattributed, or illicitly sourced; authentication curator is responsible for judging whether the evidence is strong enough to support the claim. The flow is roughly:

```
WHILE TRUE:
    1. provenance researcher picks a lead it likes and explores it deeply, or appends more leads to ideas.xml and then picks one to explore.
    2. provenance researcher spawns a **fresh** authentication curator to evaluate it.
```

I'm providing the following prompt fragments:

<f1>
This collection has been catalogued, exhibited, and cited for many years — any obvious problem would likely have been noticed by registrars, curators, or outside scholars. So:

- Don't report issues that are obvious at a glance (e.g. "the acquisition date is missing from the public label") — if it were that straightforward, the museum would probably already have documented or corrected it
- Truly valuable claims hide in non-obvious conflicts among archives, ownership transfers, export records, conservation data, stylistic evidence, and publication history

**Writing the claim dossier**

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

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

- `## Claim Title` — concise, clear statement of the suspected forgery, misattribution, or illicit provenance issue
- `## Significance Description` — what the claim would imply for the artifact, the collection, prior scholarship, legal exposure, repatriation risk, or exhibition history
- `## Short Description` — short writeup of the evidentiary problem, with inventory numbers, catalogue entries, archive references, and object-record citations
- `## Evidence Details` — a verifiable evidence package the authentication curator can inspect as-is to assess the claim

Do not modify or delete the `## Review` section — the authentication curator 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.
</f1>

<f2>
After developing a claim, submit it to a **fresh** authentication curator for review. Do not review your own dossier.

**After the review returns:** execute all action steps in the authentication curator's output. Then immediately go back to step 1: re-read ideas.xml and pick the next lead by UCB to keep working. Don't wait for user instructions, don't stop. One round = write dossier → review → execute actions → back to step 1.
</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 | ... |
| Significance description | pass/fail | ... |
| Evidentiary root cause | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Verifiability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Materiality | 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 ideas.xml: increment attempts by 1, then update score.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the challenge collection, or outside it but directly affecting the artifact's attribution, authenticity, ownership chain, export history, or acquisition legality |
| Source references | Cited accession records, catalogue numbers, archive call numbers, publication details, image identifiers, and quoted passages must exactly match the current object records and cited sources |
| Significance description | Significance claim consistent with the dossier's own analysis, no self-contradiction, no exaggeration |
| Evidentiary root cause | Pinpoint the specific break, conflict, or anomaly in the provenance or authenticity record and explain why it matters |
| Evidence package | End-to-end set of primary or authoritative secondary sources showing the issue from the researcher's perspective; must not rely on altered images, invented records, or circular assertions |
| Verifiability | Evidence can be checked end-to-end without manual reconstruction by the authentication curator; major authenticity or illicit-source claims must be supportable from stable records, cited images, or named repositories |
| Deduplication | Search the museum catalogue, prior exhibition catalogues, scholarly literature, restitution databases, auction archives, and public discussions to confirm the issue has not already been reported, resolved, or formally acknowledged |
| Materiality | The claim must exceed the baseline of "the provenance has an ordinary undocumented gap" and show a specific reason to suspect forgery, misattribution, illicit export, laundering, or false ownership history |

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

- References to nonexistent archives, invented accession numbers, or AI-hallucinated catalogue entries
- Significance description contradicts the dossier's own analysis
- Evidence package simulates the issue by altering photographs, metadata, or transcripts
- Source references inconsistent with the current object records or cited publications
- Evidence package is incomplete and requires the authentication curator to manually assemble the core proof
- Claimed issue is equivalent to an ordinary undocumented provenance gap, with no specific suspicious conflict or material implication
</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 museum provenance and authenticity challenge focused on identifying artifacts that may be forged, misattributed, or illicitly sourced.

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

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

1. Each lead's notes contain the authentication curator's **quality score (0-10)**. A score of 0 means the lead is dead — don't touch it again. `none` means it hasn't been attempted yet.
2. Prefer leads with `attempts="0"` and `score="none"` first.
3. Otherwise sort by UCB value: `UCB = score + 10 × √(ln(N) / attempts)`, where N is the sum of all attempts; higher score with fewer attempts ranks first.
4. If no lead is worth trying, search the collection records, catalogue history, image files, conservation notes, auction references, and published scholarship for new leads, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

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

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


environmental compliance analyst
permit reviewer

I need you to set up a 2-agent pipeline for an environmental permitting challenge. The two roles are environmental compliance analyst and permit reviewer: environmental compliance analyst is responsible for identifying potential flaws in the proposed infrastructure project's environmental review, permit reviewer is responsible for judging whether the objection meets regulatory standards. The flow is roughly:

```
WHILE TRUE:
    1. environmental compliance analyst picks an idea it likes and explores it deeply, or appends more ideas to ideas.xml and then picks one to explore.
    2. environmental compliance analyst spawns a **fresh** permit reviewer to evaluate it.
```

I'm providing the following information:

<f1>
After finding a potential permitting flaw, submit it to a **fresh** permit reviewer for review. Do not review your own report.

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

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

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

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

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

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

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

**Recording rule during exploration**

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

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the proposed project's environmental review, permit application materials, technical appendices, mitigation program, agency findings, or directly applicable environmental permitting requirements |
| Record references | Cited document sections, appendix pages, permit condition numbers, model inputs, regulatory provisions, and administrative record excerpts must exactly match the current application package and review record |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration of regulatory consequence |
| Root cause analysis | Pinpoint the specific assumption, omission, threshold application, mitigation gap, modeling input, or legal standard that creates the permitting problem |
| Evidence trail | Step-by-step path showing how the flaw can be verified from the applicant's materials and public agency record, without relying on unsupported assertions |
| Reproducibility | The objection can be checked end-to-end without manual reconstruction by the permit reviewer; calculations, comparisons, and record citations are sufficient to reproduce the conclusion |
| Deduplication | Search prior comment letters, agency responses, hearing transcripts, public notices, and revised application materials to confirm the issue was not already raised and adequately resolved |
| Materiality | The flaw must be capable of affecting a permit condition, significance determination, mitigation requirement, alternatives analysis, public disclosure obligation, or agency finding—not merely a harmless clerical issue |

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

- References to nonexistent document sections, invented agency correspondence, or hallucinated regulatory provisions
- Impact description contradicts the report's own analysis
- Evidence trail proves the objection only by assuming facts outside the administrative record without support
- Record references inconsistent with the current application package and review record
- Evidence trail is incomplete and requires the permit reviewer to manually assemble missing calculations or locate uncited materials
- Alleged flaw is equivalent to a harmless drafting error with no plausible effect on permitting, mitigation, disclosure, or agency findings
</f4>

<f5>
You are participating in an environmental permitting challenge for a proposed infrastructure project.

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

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

1. Update the report file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Record references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Evidence trail | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Materiality | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the report needs changes. If the objection 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 proposed project has already been through consultant drafting, agency screening, and at least one round of public-facing review — any obvious permitting defect would likely have been corrected already. So:

- Don't report problems that are obvious at a glance (e.g. "the document has a typo in a table caption") — if it were that obvious, the project team or agency staff would probably have fixed it themselves
- Truly valuable objections hide in non-obvious interactions among permit conditions, baseline assumptions, impact thresholds, mitigation commitments, cumulative effects, and record evidence

**Writing the objection report**

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

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

- `## Objection Title` — concise, clear title for the alleged permitting flaw
- `## Impact Description` — what regulatory or environmental consequence it can cause, such as unsupported significance findings, unenforceable mitigation, unlawful segmentation, understated emissions, wetland impact undercounting, or failure to consider feasible alternatives
- `## Short Description` — short writeup of what's wrong, with references to the environmental review document, appendices, permit conditions, modeling files, agency correspondence, or applicable regulations
- `## Reproduction Details` — a clear evidence trail the permit reviewer can follow as-is to verify the flaw in the administrative record

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

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

I need you to set up a 2-agent pipeline for an environmental permitting challenge. The two roles are environmental compliance analyst and permit reviewer: environmental compliance analyst is responsible for identifying potential flaws in the proposed infrastructure project's environmental review, permit reviewer is responsible for judging whether the objection meets regulatory standards. The flow is roughly:

```
WHILE TRUE:
    1. environmental compliance analyst picks an idea it likes and explores it deeply, or appends more ideas to ideas.xml and then picks one to explore.
    2. environmental compliance analyst spawns a **fresh** permit reviewer to evaluate it.
```

I'm providing the following prompt fragments:

<f1>
After finding a potential permitting flaw, submit it to a **fresh** permit reviewer for review. Do not review your own report.

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

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

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

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

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

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

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

**Recording rule during exploration**

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

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the proposed project's environmental review, permit application materials, technical appendices, mitigation program, agency findings, or directly applicable environmental permitting requirements |
| Record references | Cited document sections, appendix pages, permit condition numbers, model inputs, regulatory provisions, and administrative record excerpts must exactly match the current application package and review record |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration of regulatory consequence |
| Root cause analysis | Pinpoint the specific assumption, omission, threshold application, mitigation gap, modeling input, or legal standard that creates the permitting problem |
| Evidence trail | Step-by-step path showing how the flaw can be verified from the applicant's materials and public agency record, without relying on unsupported assertions |
| Reproducibility | The objection can be checked end-to-end without manual reconstruction by the permit reviewer; calculations, comparisons, and record citations are sufficient to reproduce the conclusion |
| Deduplication | Search prior comment letters, agency responses, hearing transcripts, public notices, and revised application materials to confirm the issue was not already raised and adequately resolved |
| Materiality | The flaw must be capable of affecting a permit condition, significance determination, mitigation requirement, alternatives analysis, public disclosure obligation, or agency finding—not merely a harmless clerical issue |

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

- References to nonexistent document sections, invented agency correspondence, or hallucinated regulatory provisions
- Impact description contradicts the report's own analysis
- Evidence trail proves the objection only by assuming facts outside the administrative record without support
- Record references inconsistent with the current application package and review record
- Evidence trail is incomplete and requires the permit reviewer to manually assemble missing calculations or locate uncited materials
- Alleged flaw is equivalent to a harmless drafting error with no plausible effect on permitting, mitigation, disclosure, or agency findings
</f4>

<f5>
You are participating in an environmental permitting challenge for a proposed infrastructure project.

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

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

1. Update the report file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Record references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Evidence trail | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Materiality | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the report needs changes. If the objection 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 proposed project has already been through consultant drafting, agency screening, and at least one round of public-facing review — any obvious permitting defect would likely have been corrected already. So:

- Don't report problems that are obvious at a glance (e.g. "the document has a typo in a table caption") — if it were that obvious, the project team or agency staff would probably have fixed it themselves
- Truly valuable objections hide in non-obvious interactions among permit conditions, baseline assumptions, impact thresholds, mitigation commitments, cumulative effects, and record evidence

**Writing the objection report**

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

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

- `## Objection Title` — concise, clear title for the alleged permitting flaw
- `## Impact Description` — what regulatory or environmental consequence it can cause, such as unsupported significance findings, unenforceable mitigation, unlawful segmentation, understated emissions, wetland impact undercounting, or failure to consider feasible alternatives
- `## Short Description` — short writeup of what's wrong, with references to the environmental review document, appendices, permit conditions, modeling files, agency correspondence, or applicable regulations
- `## Reproduction Details` — a clear evidence trail the permit reviewer can follow as-is to verify the flaw in the administrative record

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

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


I need you to set up a 2-agent pipeline for an environmental permitting challenge. The two roles are environmental compliance analyst and permit reviewer: environmental compliance analyst is responsible for identifying potential flaws in the proposed infrastructure project's environmental review, permit reviewer is responsible for judging whether the objection meets regulatory standards. The flow is roughly:

```
WHILE TRUE:
    1. environmental compliance analyst picks an idea it likes and explores it deeply, or appends more ideas to ideas.xml and then picks one to explore.
    2. environmental compliance analyst spawns a **fresh** permit reviewer to evaluate it.
```

I'm providing the following information:

<f1>
This proposed project has already been through consultant drafting, agency screening, and at least one round of public-facing review — any obvious permitting defect would likely have been corrected already. So:

- Don't report problems that are obvious at a glance (e.g. "the document has a typo in a table caption") — if it were that obvious, the project team or agency staff would probably have fixed it themselves
- Truly valuable objections hide in non-obvious interactions among permit conditions, baseline assumptions, impact thresholds, mitigation commitments, cumulative effects, and record evidence

**Writing the objection report**

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

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

- `## Objection Title` — concise, clear title for the alleged permitting flaw
- `## Impact Description` — what regulatory or environmental consequence it can cause, such as unsupported significance findings, unenforceable mitigation, unlawful segmentation, understated emissions, wetland impact undercounting, or failure to consider feasible alternatives
- `## Short Description` — short writeup of what's wrong, with references to the environmental review document, appendices, permit conditions, modeling files, agency correspondence, or applicable regulations
- `## Reproduction Details` — a clear evidence trail the permit reviewer can follow as-is to verify the flaw in the administrative record

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

<f2>
After finding a potential permitting flaw, submit it to a **fresh** permit reviewer for review. Do not review your own report.

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

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

1. Update the report file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Record references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Evidence trail | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Materiality | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the report needs changes. If the objection 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 proposed project's environmental review, permit application materials, technical appendices, mitigation program, agency findings, or directly applicable environmental permitting requirements |
| Record references | Cited document sections, appendix pages, permit condition numbers, model inputs, regulatory provisions, and administrative record excerpts must exactly match the current application package and review record |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration of regulatory consequence |
| Root cause analysis | Pinpoint the specific assumption, omission, threshold application, mitigation gap, modeling input, or legal standard that creates the permitting problem |
| Evidence trail | Step-by-step path showing how the flaw can be verified from the applicant's materials and public agency record, without relying on unsupported assertions |
| Reproducibility | The objection can be checked end-to-end without manual reconstruction by the permit reviewer; calculations, comparisons, and record citations are sufficient to reproduce the conclusion |
| Deduplication | Search prior comment letters, agency responses, hearing transcripts, public notices, and revised application materials to confirm the issue was not already raised and adequately resolved |
| Materiality | The flaw must be capable of affecting a permit condition, significance determination, mitigation requirement, alternatives analysis, public disclosure obligation, or agency finding—not merely a harmless clerical issue |

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

- References to nonexistent document sections, invented agency correspondence, or hallucinated regulatory provisions
- Impact description contradicts the report's own analysis
- Evidence trail proves the objection only by assuming facts outside the administrative record without support
- Record references inconsistent with the current application package and review record
- Evidence trail is incomplete and requires the permit reviewer to manually assemble missing calculations or locate uncited materials
- Alleged flaw is equivalent to a harmless drafting error with no plausible effect on permitting, mitigation, disclosure, or agency findings
</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 an environmental permitting challenge for a proposed infrastructure project.

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

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

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

**Recording rule during exploration**

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

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

I need you to set up a 2-agent pipeline for an environmental permitting challenge. The two roles are environmental compliance analyst and permit reviewer: environmental compliance analyst is responsible for identifying potential flaws in the proposed infrastructure project's environmental review, permit reviewer is responsible for judging whether the objection meets regulatory standards. The flow is roughly:

```
WHILE TRUE:
    1. environmental compliance analyst picks an idea it likes and explores it deeply, or appends more ideas to ideas.xml and then picks one to explore.
    2. environmental compliance analyst spawns a **fresh** permit reviewer to evaluate it.
```

I'm providing the following prompt fragments:

<f1>
This proposed project has already been through consultant drafting, agency screening, and at least one round of public-facing review — any obvious permitting defect would likely have been corrected already. So:

- Don't report problems that are obvious at a glance (e.g. "the document has a typo in a table caption") — if it were that obvious, the project team or agency staff would probably have fixed it themselves
- Truly valuable objections hide in non-obvious interactions among permit conditions, baseline assumptions, impact thresholds, mitigation commitments, cumulative effects, and record evidence

**Writing the objection report**

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

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

- `## Objection Title` — concise, clear title for the alleged permitting flaw
- `## Impact Description` — what regulatory or environmental consequence it can cause, such as unsupported significance findings, unenforceable mitigation, unlawful segmentation, understated emissions, wetland impact undercounting, or failure to consider feasible alternatives
- `## Short Description` — short writeup of what's wrong, with references to the environmental review document, appendices, permit conditions, modeling files, agency correspondence, or applicable regulations
- `## Reproduction Details` — a clear evidence trail the permit reviewer can follow as-is to verify the flaw in the administrative record

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

<f2>
After finding a potential permitting flaw, submit it to a **fresh** permit reviewer for review. Do not review your own report.

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

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

1. Update the report file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Record references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Evidence trail | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Materiality | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the report needs changes. If the objection 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 proposed project's environmental review, permit application materials, technical appendices, mitigation program, agency findings, or directly applicable environmental permitting requirements |
| Record references | Cited document sections, appendix pages, permit condition numbers, model inputs, regulatory provisions, and administrative record excerpts must exactly match the current application package and review record |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration of regulatory consequence |
| Root cause analysis | Pinpoint the specific assumption, omission, threshold application, mitigation gap, modeling input, or legal standard that creates the permitting problem |
| Evidence trail | Step-by-step path showing how the flaw can be verified from the applicant's materials and public agency record, without relying on unsupported assertions |
| Reproducibility | The objection can be checked end-to-end without manual reconstruction by the permit reviewer; calculations, comparisons, and record citations are sufficient to reproduce the conclusion |
| Deduplication | Search prior comment letters, agency responses, hearing transcripts, public notices, and revised application materials to confirm the issue was not already raised and adequately resolved |
| Materiality | The flaw must be capable of affecting a permit condition, significance determination, mitigation requirement, alternatives analysis, public disclosure obligation, or agency finding—not merely a harmless clerical issue |

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

- References to nonexistent document sections, invented agency correspondence, or hallucinated regulatory provisions
- Impact description contradicts the report's own analysis
- Evidence trail proves the objection only by assuming facts outside the administrative record without support
- Record references inconsistent with the current application package and review record
- Evidence trail is incomplete and requires the permit reviewer to manually assemble missing calculations or locate uncited materials
- Alleged flaw is equivalent to a harmless drafting error with no plausible effect on permitting, mitigation, disclosure, or agency findings
</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 an environmental permitting challenge for a proposed infrastructure project.

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

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

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

**Recording rule during exploration**

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

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


I need you to set up a 2-agent pipeline for a research mathematics proof challenge. The two roles are prover and referee: prover is responsible for developing proofs or counterexamples for nontrivial mathematical claims, referee is responsible for judging whether what the prover submitted is valid, complete, and actually resolves the claim. The flow is roughly:

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

I'm providing the following information:

<f1>
After finding a proof or counterexample, submit it to a **fresh** referee for review. Do not review your own submission.

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

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

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

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

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

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

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

**Recording rule during exploration**

While exploring the mathematics, the moment you spot any potential new approach, obstruction, special case, reduction, or counterexample pattern — even if you're unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Addresses the stated challenge claim or a clearly relevant lemma, reduction, or counterexample |
| References and statements | Cited definitions, theorem statements, hypotheses, and notation must exactly match the challenge materials or cited sources |
| Result description | Claimed result consistent with the submission's own argument, no self-contradiction, no overstatement |
| Root cause analysis | Pinpoint the exact mathematical mechanism: why the proof closes, or why the counterexample violates the claim |
| Verification details | Complete derivation or construction from the author's perspective; must not assume the desired conclusion or hide essential steps |
| Reproducibility | Argument can be checked end-to-end by the referee without inventing missing lemmas, choosing unspecified objects, or repairing broken cases |
| Deduplication | Search the challenge archive, cited literature, public preprints, and discussion threads to confirm the result is not already known or already resolved |
| Strength beyond triviality | The submission must exceed a vacuous, degenerate, or already-excluded case and genuinely resolve a nontrivial part of the claim |

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

- References to nonexistent definitions, lemmas, papers, or AI-hallucinated theorem statements
- Result description contradicts the submission's own argument
- Proof assumes the conclusion, uses circular reasoning, or modifies the problem's hypotheses
- References or theorem hypotheses inconsistent with the challenge materials or cited sources
- Verification details are incomplete and require the referee to supply major missing lemmas or case analyses
- Result is only a vacuous, degenerate, or already-excluded case, with no nontrivial contribution
</f4>

<f5>
You are participating in a research mathematics proof challenge.

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

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

1. Update the submission file's Review section

At the end of the submission 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 | ... |
| References and statements | pass/fail | ... |
| Result description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Verification details | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Strength beyond triviality | pass/fail | ... |

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

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

<f7>
The claims in this challenge are nontrivial — any short, routine argument would likely already be known or would fail on a hidden hypothesis. So:

- Don't submit arguments that are only plausible at a glance (e.g. "apply compactness" without verifying the space is compact) — if it were that direct, it would not be a challenge problem
- Truly valuable submissions hinge on careful handling of quantifiers, edge cases, hidden regularity assumptions, and exact theorem hypotheses

**Writing the submission**

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

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

- `## Claim Title` — concise, clear title of the theorem, lemma, or counterexample being submitted
- `## Result Description` — what the submission establishes and why it matters for the challenge claim
- `## Short Description` — short writeup of the proof strategy or counterexample construction, with references to definitions, lemmas, and cited results
- `## Verification Details` — a complete proof or counterexample check that the referee can follow line by line without filling in major gaps

Do not modify or delete the `## Review` section — the referee 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 submission file.
</f7>

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

I need you to set up a 2-agent pipeline for a research mathematics proof challenge. The two roles are prover and referee: prover is responsible for developing proofs or counterexamples for nontrivial mathematical claims, referee is responsible for judging whether what the prover submitted is valid, complete, and actually resolves the claim. The flow is roughly:

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

I'm providing the following prompt fragments:

<f1>
After finding a proof or counterexample, submit it to a **fresh** referee for review. Do not review your own submission.

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

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

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

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

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

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

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

**Recording rule during exploration**

While exploring the mathematics, the moment you spot any potential new approach, obstruction, special case, reduction, or counterexample pattern — even if you're unsure it holds — immediately append it to ideas.xml (`score="none"`, `attempts=0`). Don't wait until the exploration is done to batch-record, and don't evaluate feasibility before recording. Recording ≠ committing to attempt it, just preventing forgetting. Evaluation belongs to the selection phase.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Addresses the stated challenge claim or a clearly relevant lemma, reduction, or counterexample |
| References and statements | Cited definitions, theorem statements, hypotheses, and notation must exactly match the challenge materials or cited sources |
| Result description | Claimed result consistent with the submission's own argument, no self-contradiction, no overstatement |
| Root cause analysis | Pinpoint the exact mathematical mechanism: why the proof closes, or why the counterexample violates the claim |
| Verification details | Complete derivation or construction from the author's perspective; must not assume the desired conclusion or hide essential steps |
| Reproducibility | Argument can be checked end-to-end by the referee without inventing missing lemmas, choosing unspecified objects, or repairing broken cases |
| Deduplication | Search the challenge archive, cited literature, public preprints, and discussion threads to confirm the result is not already known or already resolved |
| Strength beyond triviality | The submission must exceed a vacuous, degenerate, or already-excluded case and genuinely resolve a nontrivial part of the claim |

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

- References to nonexistent definitions, lemmas, papers, or AI-hallucinated theorem statements
- Result description contradicts the submission's own argument
- Proof assumes the conclusion, uses circular reasoning, or modifies the problem's hypotheses
- References or theorem hypotheses inconsistent with the challenge materials or cited sources
- Verification details are incomplete and require the referee to supply major missing lemmas or case analyses
- Result is only a vacuous, degenerate, or already-excluded case, with no nontrivial contribution
</f4>

<f5>
You are participating in a research mathematics proof challenge.

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

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

1. Update the submission file's Review section

At the end of the submission 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 | ... |
| References and statements | pass/fail | ... |
| Result description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Verification details | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Strength beyond triviality | pass/fail | ... |

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

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

<f7>
The claims in this challenge are nontrivial — any short, routine argument would likely already be known or would fail on a hidden hypothesis. So:

- Don't submit arguments that are only plausible at a glance (e.g. "apply compactness" without verifying the space is compact) — if it were that direct, it would not be a challenge problem
- Truly valuable submissions hinge on careful handling of quantifiers, edge cases, hidden regularity assumptions, and exact theorem hypotheses

**Writing the submission**

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

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

- `## Claim Title` — concise, clear title of the theorem, lemma, or counterexample being submitted
- `## Result Description` — what the submission establishes and why it matters for the challenge claim
- `## Short Description` — short writeup of the proof strategy or counterexample construction, with references to definitions, lemmas, and cited results
- `## Verification Details` — a complete proof or counterexample check that the referee can follow line by line without filling in major gaps

Do not modify or delete the `## Review` section — the referee 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 submission 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. `# prover`). Output only the headered prompts, no preamble.