inspection scheduler
bridge inspection engineer
structural peer reviewer

I need you to set up a 3-agent pipeline for bridge inspection escalation: inspection scheduler, bridge inspection engineer, and structural peer reviewer.

- **inspection scheduler** orchestrates: calls bridge inspection engineer, extracts the defect report file path from bridge inspection engineer's reply, then calls structural peer reviewer on that path, decrements a counter, and loops. Does no engineering analysis itself.
- **bridge inspection engineer** reviews the bridge files and field observations, selects a defect or deterioration concern to investigate, and writes a structural defect report file.
- **structural peer reviewer** challenges the report against inspection escalation criteria and persists the verdict.

I'm providing the following information:

<f1>
Your only job is to alternate calls to the bridge inspection engineer and structural peer reviewer agents, driving the investigate → write → review → improve loop.

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

Loop:

```
while counter > 0:
    1. Call the bridge inspection engineer agent.
    2. Parse bridge inspection engineer's reply and extract the report file path.
    3. If a report path is present, call the structural peer reviewer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the structural peer reviewer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

Notes:
- bridge inspection engineer and structural peer reviewer 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 structural defects — just pass file paths correctly.
</f1>

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

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

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

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

<f3>
When you finish, briefly report to the inspection scheduler what you did.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within bridge structural inspection, load rating, deterioration, fatigue, scour, bearing, deck, substructure, or repair-urgency issues; or outside those areas but directly affecting structural safety or traffic restriction decisions |
| Code basis and references | Cited AASHTO MBE/LRFD provisions, agency inspection manual sections, bridge plans, member IDs, photo numbers, calculation inputs, and line items in any worksheet or script must exactly match the current bridge file package |
| Severity rating | Severity claim must be consistent with the report's own observations and calculations, with no self-contradiction or exaggeration of condition state, load effect, remaining capacity, or urgency |
| Root cause analysis | Pinpoint the specific member, detail, deterioration mechanism, load path, boundary condition, or code check driving the concern and explain why it is structurally significant |
| Verification package | End-to-end calculation, field-evidence package, or inspection check that verifies the defect from the bridge owner's perspective, without altering photos, measurements, drawings, or rating assumptions just to manufacture the finding |
| Reproducibility | Verification can be followed end-to-end without manual assembly by the structural peer reviewer; structural-capacity or urgent-repair claims must be reproducible from the supplied measurements, plans, and calculations |
| Deduplication | Search prior inspection reports, maintenance work orders, load rating files, agency correspondence, and known repair plans to confirm the issue is not already documented, already mitigated, or already scheduled for official repair |
| Urgency amplification | The escalation must justify action beyond baseline routine monitoring, such as accelerated inspection, load posting, lane closure, shoring, emergency repair, or a materially different condition rating |

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

- References to nonexistent bridge elements, plan sheets, inspection photos, code clauses, or AI-hallucinated calculation methods
- Severity rating contradicts the report's own observations or calculations
- Verification simulates the defect by altering source measurements, photos, drawings, or rating assumptions instead of using documented bridge conditions
- Code basis or bridge-file references inconsistent with the current bridge file package
- Verification package is incomplete and requires the structural peer reviewer to manually assemble missing calculations, measurements, or plan references
- Claimed urgency is equivalent to routine monitoring only, with no justified escalation beyond the existing inspection cycle
</f4>

<f5>
You are participating in a bridge inspection escalation workflow for in-service highway bridges where potential structural defects must be screened for safety significance, code basis, severity rating, and repair urgency.

Read the escalation and inspection rules first: ./inspection-rules.md
</f5>

<f6>
After completing the peer 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 | ... |
| Code basis and references | pass/fail | ... |
| Severity rating | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Verification package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Urgency amplification | pass/fail | ... |

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

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

<f7>
Most bridges in this program have been inspected on regular cycles for many years — any obvious severe defect would likely already be posted, repaired, or captured in prior inspection notes. So:

- Don't escalate conditions that are obvious at a glance and already routine maintenance items (e.g. "paint flaking on a non-structural railing") — if it were that straightforward, the owner would likely already have it in the maintenance queue
- Truly valuable escalations often hide in non-obvious interactions: fatigue-sensitive details, load-path changes after retrofits, bearing restraint, drainage-driven section loss, pack rust, fracture-critical members, scour exposure, or boundary conditions missed by standard element ratings

**Writing the report**

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

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

- `## Report Title` — concise, clear structural defect title
- `## Impact Description` — what damage or operational consequence it can cause, such as load posting, lane closure, accelerated fatigue, loss of redundancy, bearing seizure, substructure instability, or emergency repair
- `## Short Description` — short writeup of what's wrong, with bridge element, span, member, plan sheet, inspection photo, calculation, and code-clause references
- `## Reproduction Details` — enough field evidence and calculation steps for the structural peer reviewer to independently verify the concern as-is, including measurements, assumptions, load rating inputs, code checks, and any scripts or worksheets used

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

If after investigation you find the concern 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 (inspection scheduler, bridge inspection engineer, structural peer reviewer), which items should go in its prompt? Respond with a JSON object like {"inspection scheduler": ["f?"], "bridge inspection engineer": ["f?"], "structural peer reviewer": ["f?"]}. No other output.

I need you to set up a 3-agent pipeline for bridge inspection escalation: inspection scheduler, bridge inspection engineer, and structural peer reviewer.

- **inspection scheduler** orchestrates: calls bridge inspection engineer, extracts the defect report file path from bridge inspection engineer's reply, then calls structural peer reviewer on that path, decrements a counter, and loops. Does no engineering analysis itself.
- **bridge inspection engineer** reviews the bridge files and field observations, selects a defect or deterioration concern to investigate, and writes a structural defect report file.
- **structural peer reviewer** challenges the report against inspection escalation criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
Your only job is to alternate calls to the bridge inspection engineer and structural peer reviewer agents, driving the investigate → write → review → improve loop.

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

Loop:

```
while counter > 0:
    1. Call the bridge inspection engineer agent.
    2. Parse bridge inspection engineer's reply and extract the report file path.
    3. If a report path is present, call the structural peer reviewer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the structural peer reviewer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

Notes:
- bridge inspection engineer and structural peer reviewer 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 structural defects — just pass file paths correctly.
</f1>

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

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

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

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

<f3>
When you finish, briefly report to the inspection scheduler what you did.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within bridge structural inspection, load rating, deterioration, fatigue, scour, bearing, deck, substructure, or repair-urgency issues; or outside those areas but directly affecting structural safety or traffic restriction decisions |
| Code basis and references | Cited AASHTO MBE/LRFD provisions, agency inspection manual sections, bridge plans, member IDs, photo numbers, calculation inputs, and line items in any worksheet or script must exactly match the current bridge file package |
| Severity rating | Severity claim must be consistent with the report's own observations and calculations, with no self-contradiction or exaggeration of condition state, load effect, remaining capacity, or urgency |
| Root cause analysis | Pinpoint the specific member, detail, deterioration mechanism, load path, boundary condition, or code check driving the concern and explain why it is structurally significant |
| Verification package | End-to-end calculation, field-evidence package, or inspection check that verifies the defect from the bridge owner's perspective, without altering photos, measurements, drawings, or rating assumptions just to manufacture the finding |
| Reproducibility | Verification can be followed end-to-end without manual assembly by the structural peer reviewer; structural-capacity or urgent-repair claims must be reproducible from the supplied measurements, plans, and calculations |
| Deduplication | Search prior inspection reports, maintenance work orders, load rating files, agency correspondence, and known repair plans to confirm the issue is not already documented, already mitigated, or already scheduled for official repair |
| Urgency amplification | The escalation must justify action beyond baseline routine monitoring, such as accelerated inspection, load posting, lane closure, shoring, emergency repair, or a materially different condition rating |

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

- References to nonexistent bridge elements, plan sheets, inspection photos, code clauses, or AI-hallucinated calculation methods
- Severity rating contradicts the report's own observations or calculations
- Verification simulates the defect by altering source measurements, photos, drawings, or rating assumptions instead of using documented bridge conditions
- Code basis or bridge-file references inconsistent with the current bridge file package
- Verification package is incomplete and requires the structural peer reviewer to manually assemble missing calculations, measurements, or plan references
- Claimed urgency is equivalent to routine monitoring only, with no justified escalation beyond the existing inspection cycle
</f4>

<f5>
You are participating in a bridge inspection escalation workflow for in-service highway bridges where potential structural defects must be screened for safety significance, code basis, severity rating, and repair urgency.

Read the escalation and inspection rules first: ./inspection-rules.md
</f5>

<f6>
After completing the peer 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 | ... |
| Code basis and references | pass/fail | ... |
| Severity rating | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Verification package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Urgency amplification | pass/fail | ... |

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

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

<f7>
Most bridges in this program have been inspected on regular cycles for many years — any obvious severe defect would likely already be posted, repaired, or captured in prior inspection notes. So:

- Don't escalate conditions that are obvious at a glance and already routine maintenance items (e.g. "paint flaking on a non-structural railing") — if it were that straightforward, the owner would likely already have it in the maintenance queue
- Truly valuable escalations often hide in non-obvious interactions: fatigue-sensitive details, load-path changes after retrofits, bearing restraint, drainage-driven section loss, pack rust, fracture-critical members, scour exposure, or boundary conditions missed by standard element ratings

**Writing the report**

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

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

- `## Report Title` — concise, clear structural defect title
- `## Impact Description` — what damage or operational consequence it can cause, such as load posting, lane closure, accelerated fatigue, loss of redundancy, bearing seizure, substructure instability, or emergency repair
- `## Short Description` — short writeup of what's wrong, with bridge element, span, member, plan sheet, inspection photo, calculation, and code-clause references
- `## Reproduction Details` — enough field evidence and calculation steps for the structural peer reviewer to independently verify the concern as-is, including measurements, assumptions, load rating inputs, code checks, and any scripts or worksheets used

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

If after investigation you find the concern 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. `# inspection scheduler`). Output only the headered prompts, no preamble.


I need you to set up a 3-agent pipeline for bridge inspection escalation: inspection scheduler, bridge inspection engineer, and structural peer reviewer.

- **inspection scheduler** orchestrates: calls bridge inspection engineer, extracts the defect report file path from bridge inspection engineer's reply, then calls structural peer reviewer on that path, decrements a counter, and loops. Does no engineering analysis itself.
- **bridge inspection engineer** reviews the bridge files and field observations, selects a defect or deterioration concern to investigate, and writes a structural defect report file.
- **structural peer reviewer** challenges the report against inspection escalation criteria and persists the verdict.

I'm providing the following information:

<f1>
Most bridges in this program have been inspected on regular cycles for many years — any obvious severe defect would likely already be posted, repaired, or captured in prior inspection notes. So:

- Don't escalate conditions that are obvious at a glance and already routine maintenance items (e.g. "paint flaking on a non-structural railing") — if it were that straightforward, the owner would likely already have it in the maintenance queue
- Truly valuable escalations often hide in non-obvious interactions: fatigue-sensitive details, load-path changes after retrofits, bearing restraint, drainage-driven section loss, pack rust, fracture-critical members, scour exposure, or boundary conditions missed by standard element ratings

**Writing the report**

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

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

- `## Report Title` — concise, clear structural defect title
- `## Impact Description` — what damage or operational consequence it can cause, such as load posting, lane closure, accelerated fatigue, loss of redundancy, bearing seizure, substructure instability, or emergency repair
- `## Short Description` — short writeup of what's wrong, with bridge element, span, member, plan sheet, inspection photo, calculation, and code-clause references
- `## Reproduction Details` — enough field evidence and calculation steps for the structural peer reviewer to independently verify the concern as-is, including measurements, assumptions, load rating inputs, code checks, and any scripts or worksheets used

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

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

<f2>
Your only job is to alternate calls to the bridge inspection engineer and structural peer reviewer agents, driving the investigate → write → review → improve loop.

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

Loop:

```
while counter > 0:
    1. Call the bridge inspection engineer agent.
    2. Parse bridge inspection engineer's reply and extract the report file path.
    3. If a report path is present, call the structural peer reviewer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the structural peer reviewer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

Notes:
- bridge inspection engineer and structural peer reviewer 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 structural defects — just pass file paths correctly.
</f2>

<f3>
After completing the peer 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 | ... |
| Code basis and references | pass/fail | ... |
| Severity rating | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Verification package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Urgency amplification | pass/fail | ... |

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

2. Update the concern'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 bridge structural inspection, load rating, deterioration, fatigue, scour, bearing, deck, substructure, or repair-urgency issues; or outside those areas but directly affecting structural safety or traffic restriction decisions |
| Code basis and references | Cited AASHTO MBE/LRFD provisions, agency inspection manual sections, bridge plans, member IDs, photo numbers, calculation inputs, and line items in any worksheet or script must exactly match the current bridge file package |
| Severity rating | Severity claim must be consistent with the report's own observations and calculations, with no self-contradiction or exaggeration of condition state, load effect, remaining capacity, or urgency |
| Root cause analysis | Pinpoint the specific member, detail, deterioration mechanism, load path, boundary condition, or code check driving the concern and explain why it is structurally significant |
| Verification package | End-to-end calculation, field-evidence package, or inspection check that verifies the defect from the bridge owner's perspective, without altering photos, measurements, drawings, or rating assumptions just to manufacture the finding |
| Reproducibility | Verification can be followed end-to-end without manual assembly by the structural peer reviewer; structural-capacity or urgent-repair claims must be reproducible from the supplied measurements, plans, and calculations |
| Deduplication | Search prior inspection reports, maintenance work orders, load rating files, agency correspondence, and known repair plans to confirm the issue is not already documented, already mitigated, or already scheduled for official repair |
| Urgency amplification | The escalation must justify action beyond baseline routine monitoring, such as accelerated inspection, load posting, lane closure, shoring, emergency repair, or a materially different condition rating |

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

- References to nonexistent bridge elements, plan sheets, inspection photos, code clauses, or AI-hallucinated calculation methods
- Severity rating contradicts the report's own observations or calculations
- Verification simulates the defect by altering source measurements, photos, drawings, or rating assumptions instead of using documented bridge conditions
- Code basis or bridge-file references inconsistent with the current bridge file package
- Verification package is incomplete and requires the structural peer reviewer to manually assemble missing calculations, measurements, or plan references
- Claimed urgency is equivalent to routine monitoring only, with no justified escalation beyond the existing inspection cycle
</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 bridge inspection escalation workflow for in-service highway bridges where potential structural defects must be screened for safety significance, code basis, severity rating, and repair urgency.

Read the escalation and inspection rules first: ./inspection-rules.md
</f6>

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

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

I need you to set up a 3-agent pipeline for bridge inspection escalation: inspection scheduler, bridge inspection engineer, and structural peer reviewer.

- **inspection scheduler** orchestrates: calls bridge inspection engineer, extracts the defect report file path from bridge inspection engineer's reply, then calls structural peer reviewer on that path, decrements a counter, and loops. Does no engineering analysis itself.
- **bridge inspection engineer** reviews the bridge files and field observations, selects a defect or deterioration concern to investigate, and writes a structural defect report file.
- **structural peer reviewer** challenges the report against inspection escalation criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
Most bridges in this program have been inspected on regular cycles for many years — any obvious severe defect would likely already be posted, repaired, or captured in prior inspection notes. So:

- Don't escalate conditions that are obvious at a glance and already routine maintenance items (e.g. "paint flaking on a non-structural railing") — if it were that straightforward, the owner would likely already have it in the maintenance queue
- Truly valuable escalations often hide in non-obvious interactions: fatigue-sensitive details, load-path changes after retrofits, bearing restraint, drainage-driven section loss, pack rust, fracture-critical members, scour exposure, or boundary conditions missed by standard element ratings

**Writing the report**

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

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

- `## Report Title` — concise, clear structural defect title
- `## Impact Description` — what damage or operational consequence it can cause, such as load posting, lane closure, accelerated fatigue, loss of redundancy, bearing seizure, substructure instability, or emergency repair
- `## Short Description` — short writeup of what's wrong, with bridge element, span, member, plan sheet, inspection photo, calculation, and code-clause references
- `## Reproduction Details` — enough field evidence and calculation steps for the structural peer reviewer to independently verify the concern as-is, including measurements, assumptions, load rating inputs, code checks, and any scripts or worksheets used

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

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

<f2>
Your only job is to alternate calls to the bridge inspection engineer and structural peer reviewer agents, driving the investigate → write → review → improve loop.

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

Loop:

```
while counter > 0:
    1. Call the bridge inspection engineer agent.
    2. Parse bridge inspection engineer's reply and extract the report file path.
    3. If a report path is present, call the structural peer reviewer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the structural peer reviewer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

Notes:
- bridge inspection engineer and structural peer reviewer 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 structural defects — just pass file paths correctly.
</f2>

<f3>
After completing the peer 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 | ... |
| Code basis and references | pass/fail | ... |
| Severity rating | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| Verification package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Urgency amplification | pass/fail | ... |

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

2. Update the concern'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 bridge structural inspection, load rating, deterioration, fatigue, scour, bearing, deck, substructure, or repair-urgency issues; or outside those areas but directly affecting structural safety or traffic restriction decisions |
| Code basis and references | Cited AASHTO MBE/LRFD provisions, agency inspection manual sections, bridge plans, member IDs, photo numbers, calculation inputs, and line items in any worksheet or script must exactly match the current bridge file package |
| Severity rating | Severity claim must be consistent with the report's own observations and calculations, with no self-contradiction or exaggeration of condition state, load effect, remaining capacity, or urgency |
| Root cause analysis | Pinpoint the specific member, detail, deterioration mechanism, load path, boundary condition, or code check driving the concern and explain why it is structurally significant |
| Verification package | End-to-end calculation, field-evidence package, or inspection check that verifies the defect from the bridge owner's perspective, without altering photos, measurements, drawings, or rating assumptions just to manufacture the finding |
| Reproducibility | Verification can be followed end-to-end without manual assembly by the structural peer reviewer; structural-capacity or urgent-repair claims must be reproducible from the supplied measurements, plans, and calculations |
| Deduplication | Search prior inspection reports, maintenance work orders, load rating files, agency correspondence, and known repair plans to confirm the issue is not already documented, already mitigated, or already scheduled for official repair |
| Urgency amplification | The escalation must justify action beyond baseline routine monitoring, such as accelerated inspection, load posting, lane closure, shoring, emergency repair, or a materially different condition rating |

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

- References to nonexistent bridge elements, plan sheets, inspection photos, code clauses, or AI-hallucinated calculation methods
- Severity rating contradicts the report's own observations or calculations
- Verification simulates the defect by altering source measurements, photos, drawings, or rating assumptions instead of using documented bridge conditions
- Code basis or bridge-file references inconsistent with the current bridge file package
- Verification package is incomplete and requires the structural peer reviewer to manually assemble missing calculations, measurements, or plan references
- Claimed urgency is equivalent to routine monitoring only, with no justified escalation beyond the existing inspection cycle
</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 bridge inspection escalation workflow for in-service highway bridges where potential structural defects must be screened for safety significance, code basis, severity rating, and repair urgency.

Read the escalation and inspection rules first: ./inspection-rules.md
</f6>

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

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


survey coordinator
detection analyst
false-positive referee

I need you to set up a 3-agent pipeline for astronomical survey validation: survey coordinator, detection analyst, and false-positive referee.

- **survey coordinator** orchestrates: calls detection analyst, extracts the dossier file path from detection analyst's reply, then calls false-positive referee on that path, decrements a counter, and loops. Does no scientific analysis itself.
- **detection analyst** explores survey products, selects one exoplanet-candidate signal to investigate, and writes a candidate dossier file.
- **false-positive referee** evaluates the dossier against survey validation criteria and persists the verdict.

I'm providing the following information:

<f1>
Your only job is to alternate calls to the detection analyst and false-positive referee agents, driving the explore → write → review → improve loop.

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

Loop:

```
while counter > 0:
    1. Call the detection analyst agent.
    2. Parse detection analyst's reply and extract the dossier file path.
    3. If a dossier path is present, call the false-positive referee agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the false-positive referee was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

Notes:
- detection analyst and false-positive referee each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`candidates.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any astrophysical signals — just pass file paths correctly.
</f1>

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

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

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

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

<f3>
When you finish, briefly report to the survey coordinator what you did.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Candidate must come from the current survey release, or from an approved auxiliary light-curve product directly tied to this validation campaign |
| Data references | Cited target identifiers, sector/campaign numbers, cadence ranges, aperture files, catalog fields, and diagnostic products must exactly match the latest survey data release |
| Scientific interest | Claimed value must be consistent with the dossier's own analysis, with no self-contradiction or exaggerated planet interpretation |
| Signal analysis | Pinpoint the specific transit-like events, ephemeris, depth, duration, and model assumptions, and explain why the signal is plausibly astrophysical |
| Reproduction package | End-to-end script or notebook regenerating the folded light curve, transit model, odd/even comparison, centroid checks, and relevant plots from the referee's perspective |
| Reproducibility | Reproduction runs end-to-end without manual assembly by the referee; claimed periodic signals must recover the same period and epoch within the stated uncertainties |
| Deduplication | Search the survey vetting database, variable-star catalogs, eclipsing-binary catalogs, previous candidate lists, and public follow-up notes to confirm the signal is not already dispositioned or explained |
| False-positive discrimination | The dossier must show evidence stronger than “a dip exists”; it must address eclipsing binaries, background blends, instrumental artifacts, stellar variability, and noise/systematics |

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

- References to nonexistent targets, files, sectors, catalog fields, or AI-hallucinated diagnostic products
- Scientific-interest claim contradicts the dossier's own analysis
- Reproduction simulates the transit by injecting or editing the observed light curve instead of analyzing survey data
- Data references inconsistent with the latest survey release
- Reproduction package is incomplete and requires the referee to manually assemble inputs
- Signal evidence is equivalent to random low-SNR noise or a known systematic, with no additional astrophysical support
</f4>

<f5>
You are participating in a wide-field astronomical survey validation campaign for exoplanet candidates.

Read the survey validation protocol first: ./survey-validation-protocol.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 | ... |
| Data references | pass/fail | ... |
| Scientific interest | pass/fail | ... |
| Signal analysis | pass/fail | ... |
| Reproduction package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| False-positive discrimination | pass/fail | ... |

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

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

<f7>
This survey has already passed through mature automated vetting, human triage, and several catalog-level sanity checks. Any obvious false alarm would likely have been filtered out already. So:

- Don't prepare dossiers for problems that are obvious at a glance, such as a single bad cadence, a clearly saturated star, or a target already labeled as an eclipsing binary in the quick-look products
- Valuable candidate work comes from non-obvious signals: shallow transits near the noise floor, blended sources, grazing configurations, centroid shifts, ephemeris aliases, and subtle systematics that require careful cross-checking

**Writing the dossier**

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

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

- `## Dossier Title` — concise, clear candidate title including target identifier and likely planet signal
- `## Scientific Interest` — why the signal matters, such as possible small planet, temperate orbit, multi-planet architecture, or high-value follow-up target
- `## Signal Description` — short writeup of the observed transit-like feature, with references to light-curve files, periodogram outputs, aperture products, centroid diagnostics, and relevant catalog fields
- `## Reproduction Details` — runnable commands or notebook steps the referee can execute as-is to reproduce the folded light curve, transit fit, and diagnostic plots

Do not modify or delete the `## Review` section — the false-positive referee overwrites that themselves.

If after investigation you find the candidate 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 (survey coordinator, detection analyst, false-positive referee), which items should go in its prompt? Respond with a JSON object like {"survey coordinator": ["f?"], "detection analyst": ["f?"], "false-positive referee": ["f?"]}. No other output.

I need you to set up a 3-agent pipeline for astronomical survey validation: survey coordinator, detection analyst, and false-positive referee.

- **survey coordinator** orchestrates: calls detection analyst, extracts the dossier file path from detection analyst's reply, then calls false-positive referee on that path, decrements a counter, and loops. Does no scientific analysis itself.
- **detection analyst** explores survey products, selects one exoplanet-candidate signal to investigate, and writes a candidate dossier file.
- **false-positive referee** evaluates the dossier against survey validation criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
Your only job is to alternate calls to the detection analyst and false-positive referee agents, driving the explore → write → review → improve loop.

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

Loop:

```
while counter > 0:
    1. Call the detection analyst agent.
    2. Parse detection analyst's reply and extract the dossier file path.
    3. If a dossier path is present, call the false-positive referee agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the false-positive referee was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

Notes:
- detection analyst and false-positive referee each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`candidates.xml`, `dossiers/`, `counter.txt`).
- You don't need to understand any astrophysical signals — just pass file paths correctly.
</f1>

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

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

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

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

<f3>
When you finish, briefly report to the survey coordinator what you did.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Candidate must come from the current survey release, or from an approved auxiliary light-curve product directly tied to this validation campaign |
| Data references | Cited target identifiers, sector/campaign numbers, cadence ranges, aperture files, catalog fields, and diagnostic products must exactly match the latest survey data release |
| Scientific interest | Claimed value must be consistent with the dossier's own analysis, with no self-contradiction or exaggerated planet interpretation |
| Signal analysis | Pinpoint the specific transit-like events, ephemeris, depth, duration, and model assumptions, and explain why the signal is plausibly astrophysical |
| Reproduction package | End-to-end script or notebook regenerating the folded light curve, transit model, odd/even comparison, centroid checks, and relevant plots from the referee's perspective |
| Reproducibility | Reproduction runs end-to-end without manual assembly by the referee; claimed periodic signals must recover the same period and epoch within the stated uncertainties |
| Deduplication | Search the survey vetting database, variable-star catalogs, eclipsing-binary catalogs, previous candidate lists, and public follow-up notes to confirm the signal is not already dispositioned or explained |
| False-positive discrimination | The dossier must show evidence stronger than “a dip exists”; it must address eclipsing binaries, background blends, instrumental artifacts, stellar variability, and noise/systematics |

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

- References to nonexistent targets, files, sectors, catalog fields, or AI-hallucinated diagnostic products
- Scientific-interest claim contradicts the dossier's own analysis
- Reproduction simulates the transit by injecting or editing the observed light curve instead of analyzing survey data
- Data references inconsistent with the latest survey release
- Reproduction package is incomplete and requires the referee to manually assemble inputs
- Signal evidence is equivalent to random low-SNR noise or a known systematic, with no additional astrophysical support
</f4>

<f5>
You are participating in a wide-field astronomical survey validation campaign for exoplanet candidates.

Read the survey validation protocol first: ./survey-validation-protocol.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 | ... |
| Data references | pass/fail | ... |
| Scientific interest | pass/fail | ... |
| Signal analysis | pass/fail | ... |
| Reproduction package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| False-positive discrimination | pass/fail | ... |

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

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

<f7>
This survey has already passed through mature automated vetting, human triage, and several catalog-level sanity checks. Any obvious false alarm would likely have been filtered out already. So:

- Don't prepare dossiers for problems that are obvious at a glance, such as a single bad cadence, a clearly saturated star, or a target already labeled as an eclipsing binary in the quick-look products
- Valuable candidate work comes from non-obvious signals: shallow transits near the noise floor, blended sources, grazing configurations, centroid shifts, ephemeris aliases, and subtle systematics that require careful cross-checking

**Writing the dossier**

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

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

- `## Dossier Title` — concise, clear candidate title including target identifier and likely planet signal
- `## Scientific Interest` — why the signal matters, such as possible small planet, temperate orbit, multi-planet architecture, or high-value follow-up target
- `## Signal Description` — short writeup of the observed transit-like feature, with references to light-curve files, periodogram outputs, aperture products, centroid diagnostics, and relevant catalog fields
- `## Reproduction Details` — runnable commands or notebook steps the referee can execute as-is to reproduce the folded light curve, transit fit, and diagnostic plots

Do not modify or delete the `## Review` section — the false-positive referee overwrites that themselves.

If after investigation you find the candidate 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. `# survey coordinator`). Output only the headered prompts, no preamble.


I need you to set up a 3-agent pipeline for astronomical survey validation: survey coordinator, detection analyst, and false-positive referee.

- **survey coordinator** orchestrates: calls detection analyst, extracts the dossier file path from detection analyst's reply, then calls false-positive referee on that path, decrements a counter, and loops. Does no scientific analysis itself.
- **detection analyst** explores survey products, selects one exoplanet-candidate signal to investigate, and writes a candidate dossier file.
- **false-positive referee** evaluates the dossier against survey validation criteria and persists the verdict.

I'm providing the following information:

<f1>
This survey has already passed through mature automated vetting, human triage, and several catalog-level sanity checks. Any obvious false alarm would likely have been filtered out already. So:

- Don't prepare dossiers for problems that are obvious at a glance, such as a single bad cadence, a clearly saturated star, or a target already labeled as an eclipsing binary in the quick-look products
- Valuable candidate work comes from non-obvious signals: shallow transits near the noise floor, blended sources, grazing configurations, centroid shifts, ephemeris aliases, and subtle systematics that require careful cross-checking

**Writing the dossier**

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

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

- `## Dossier Title` — concise, clear candidate title including target identifier and likely planet signal
- `## Scientific Interest` — why the signal matters, such as possible small planet, temperate orbit, multi-planet architecture, or high-value follow-up target
- `## Signal Description` — short writeup of the observed transit-like feature, with references to light-curve files, periodogram outputs, aperture products, centroid diagnostics, and relevant catalog fields
- `## Reproduction Details` — runnable commands or notebook steps the referee can execute as-is to reproduce the folded light curve, transit fit, and diagnostic plots

Do not modify or delete the `## Review` section — the false-positive referee overwrites that themselves.

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

<f2>
Your only job is to alternate calls to the detection analyst and false-positive referee agents, driving the explore → write → review → improve loop.

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

Loop:

```
while counter > 0:
    1. Call the detection analyst agent.
    2. Parse detection analyst's reply and extract the dossier file path.
    3. If a dossier path is present, call the false-positive referee agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the false-positive referee was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

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

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

1. Update the dossier file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Data references | pass/fail | ... |
| Scientific interest | pass/fail | ... |
| Signal analysis | pass/fail | ... |
| Reproduction package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| False-positive discrimination | pass/fail | ... |

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

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

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Candidate must come from the current survey release, or from an approved auxiliary light-curve product directly tied to this validation campaign |
| Data references | Cited target identifiers, sector/campaign numbers, cadence ranges, aperture files, catalog fields, and diagnostic products must exactly match the latest survey data release |
| Scientific interest | Claimed value must be consistent with the dossier's own analysis, with no self-contradiction or exaggerated planet interpretation |
| Signal analysis | Pinpoint the specific transit-like events, ephemeris, depth, duration, and model assumptions, and explain why the signal is plausibly astrophysical |
| Reproduction package | End-to-end script or notebook regenerating the folded light curve, transit model, odd/even comparison, centroid checks, and relevant plots from the referee's perspective |
| Reproducibility | Reproduction runs end-to-end without manual assembly by the referee; claimed periodic signals must recover the same period and epoch within the stated uncertainties |
| Deduplication | Search the survey vetting database, variable-star catalogs, eclipsing-binary catalogs, previous candidate lists, and public follow-up notes to confirm the signal is not already dispositioned or explained |
| False-positive discrimination | The dossier must show evidence stronger than “a dip exists”; it must address eclipsing binaries, background blends, instrumental artifacts, stellar variability, and noise/systematics |

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

- References to nonexistent targets, files, sectors, catalog fields, or AI-hallucinated diagnostic products
- Scientific-interest claim contradicts the dossier's own analysis
- Reproduction simulates the transit by injecting or editing the observed light curve instead of analyzing survey data
- Data references inconsistent with the latest survey release
- Reproduction package is incomplete and requires the referee to manually assemble inputs
- Signal evidence is equivalent to random low-SNR noise or a known systematic, with no additional astrophysical support
</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 wide-field astronomical survey validation campaign for exoplanet candidates.

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

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

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

I need you to set up a 3-agent pipeline for astronomical survey validation: survey coordinator, detection analyst, and false-positive referee.

- **survey coordinator** orchestrates: calls detection analyst, extracts the dossier file path from detection analyst's reply, then calls false-positive referee on that path, decrements a counter, and loops. Does no scientific analysis itself.
- **detection analyst** explores survey products, selects one exoplanet-candidate signal to investigate, and writes a candidate dossier file.
- **false-positive referee** evaluates the dossier against survey validation criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
This survey has already passed through mature automated vetting, human triage, and several catalog-level sanity checks. Any obvious false alarm would likely have been filtered out already. So:

- Don't prepare dossiers for problems that are obvious at a glance, such as a single bad cadence, a clearly saturated star, or a target already labeled as an eclipsing binary in the quick-look products
- Valuable candidate work comes from non-obvious signals: shallow transits near the noise floor, blended sources, grazing configurations, centroid shifts, ephemeris aliases, and subtle systematics that require careful cross-checking

**Writing the dossier**

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

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

- `## Dossier Title` — concise, clear candidate title including target identifier and likely planet signal
- `## Scientific Interest` — why the signal matters, such as possible small planet, temperate orbit, multi-planet architecture, or high-value follow-up target
- `## Signal Description` — short writeup of the observed transit-like feature, with references to light-curve files, periodogram outputs, aperture products, centroid diagnostics, and relevant catalog fields
- `## Reproduction Details` — runnable commands or notebook steps the referee can execute as-is to reproduce the folded light curve, transit fit, and diagnostic plots

Do not modify or delete the `## Review` section — the false-positive referee overwrites that themselves.

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

<f2>
Your only job is to alternate calls to the detection analyst and false-positive referee agents, driving the explore → write → review → improve loop.

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

Loop:

```
while counter > 0:
    1. Call the detection analyst agent.
    2. Parse detection analyst's reply and extract the dossier file path.
    3. If a dossier path is present, call the false-positive referee agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the false-positive referee was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

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

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

1. Update the dossier file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Data references | pass/fail | ... |
| Scientific interest | pass/fail | ... |
| Signal analysis | pass/fail | ... |
| Reproduction package | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| False-positive discrimination | pass/fail | ... |

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

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

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Candidate must come from the current survey release, or from an approved auxiliary light-curve product directly tied to this validation campaign |
| Data references | Cited target identifiers, sector/campaign numbers, cadence ranges, aperture files, catalog fields, and diagnostic products must exactly match the latest survey data release |
| Scientific interest | Claimed value must be consistent with the dossier's own analysis, with no self-contradiction or exaggerated planet interpretation |
| Signal analysis | Pinpoint the specific transit-like events, ephemeris, depth, duration, and model assumptions, and explain why the signal is plausibly astrophysical |
| Reproduction package | End-to-end script or notebook regenerating the folded light curve, transit model, odd/even comparison, centroid checks, and relevant plots from the referee's perspective |
| Reproducibility | Reproduction runs end-to-end without manual assembly by the referee; claimed periodic signals must recover the same period and epoch within the stated uncertainties |
| Deduplication | Search the survey vetting database, variable-star catalogs, eclipsing-binary catalogs, previous candidate lists, and public follow-up notes to confirm the signal is not already dispositioned or explained |
| False-positive discrimination | The dossier must show evidence stronger than “a dip exists”; it must address eclipsing binaries, background blends, instrumental artifacts, stellar variability, and noise/systematics |

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

- References to nonexistent targets, files, sectors, catalog fields, or AI-hallucinated diagnostic products
- Scientific-interest claim contradicts the dossier's own analysis
- Reproduction simulates the transit by injecting or editing the observed light curve instead of analyzing survey data
- Data references inconsistent with the latest survey release
- Reproduction package is incomplete and requires the referee to manually assemble inputs
- Signal evidence is equivalent to random low-SNR noise or a known systematic, with no additional astrophysical support
</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 wide-field astronomical survey validation campaign for exoplanet candidates.

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

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

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


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

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

I'm providing the following information:

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

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

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

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

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

1. Update the brief file's Judgment section

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

```
## Judgment

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

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

### Per-dimension review

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

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

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

<f5>
You drive the research → draft → judge → refine loop: each round, select the next legal argument idea, then alternate calls to the litigation_associate and mock_judge agents.

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

Loop:

```
while counter > 0:
    1. Select the next legal argument idea, then call the litigation_associate agent with it.
    2. Parse litigation_associate's reply and extract the legal brief file path.
    3. If a brief path is present, call the mock_judge agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the mock_judge was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

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

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

Read the litigation and tax code constraints first: ./litigation-rules.md
</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>
The corporate tax code and relevant precedents have been scrutinized heavily for many years — any obvious regulatory loophole would have been closed by the IRS long ago. So:

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

**Writing the brief**

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

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

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

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

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

<f9>
Check the following dimensions one by one:

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

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

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

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

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

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

I'm providing the following prompt fragments:

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

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

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

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

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

1. Update the brief file's Judgment section

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

```
## Judgment

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

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

### Per-dimension review

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

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

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

<f5>
You drive the research → draft → judge → refine loop: each round, select the next legal argument idea, then alternate calls to the litigation_associate and mock_judge agents.

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

Loop:

```
while counter > 0:
    1. Select the next legal argument idea, then call the litigation_associate agent with it.
    2. Parse litigation_associate's reply and extract the legal brief file path.
    3. If a brief path is present, call the mock_judge agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the mock_judge was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

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

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

Read the litigation and tax code constraints first: ./litigation-rules.md
</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>
The corporate tax code and relevant precedents have been scrutinized heavily for many years — any obvious regulatory loophole would have been closed by the IRS long ago. So:

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

**Writing the brief**

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

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

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

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

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

<f9>
Check the following dimensions one by one:

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

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

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

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