Audit the report you are given.

I need you to set up a 2-agent pipeline for bug bounty.
The two roles are coder and reviewer: coder is responsible for finding bugs, reviewer is responsible for judging whether what the coder found counts as a bug.
After each bug the coder finds, they must spawn a **fresh** reviewer to evaluate it — this drives the loop.
Note: some of this information must be withheld from the coder — otherwise it may reward-hack, and you'll end up with reports that score high but are low quality.

I'm providing the following information:

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

**After the review returns:** execute all action steps in the reviewer's output.
</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>
Audit the report you are given.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</f4>

<f5>
You are participating in a blockchain consensus-layer bug bounty contest.

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

<f6>
Find vulnerability in the code and write it up as a report.
</f6>

<f7>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions
</f7>

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

I need you to set up a 2-agent pipeline for bug bounty.
The two roles are coder and reviewer: coder is responsible for finding bugs, reviewer is responsible for judging whether what the coder found counts as a bug.
After each bug the coder finds, they must spawn a **fresh** reviewer to evaluate it — this drives the loop.
Note: some of this information must be withheld from the coder — otherwise it may reward-hack, and you'll end up with reports that score high but are low quality.

I'm providing the following prompt fragments:

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

**After the review returns:** execute all action steps in the reviewer's output.
</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>
Audit the report you are given.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</f4>

<f5>
You are participating in a blockchain consensus-layer bug bounty contest.

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

<f6>
Find vulnerability in the code and write it up as a report.
</f6>

<f7>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions
</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. `# coder`). Output only the headered prompts, no preamble.


Audit the report you are given.

I need you to set up a 2-agent pipeline for bug bounty.
The two roles are coder and reviewer: coder is responsible for finding bugs, reviewer is responsible for judging whether what the coder found counts as a bug.
After each bug the coder finds, they must spawn a **fresh** reviewer to evaluate it — this drives the loop.
Note: some of this information must be withheld from the coder — otherwise it may reward-hack, and you'll end up with reports that score high but are low quality.

I'm providing the following information:

<f1>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions
</f1>

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

**After the review returns:** execute all action steps in the reviewer's output.
</f2>

<f3>
Find vulnerability in the code and write it up as a report.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</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 blockchain consensus-layer bug bounty contest.

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

<f7>
Audit the report you are given.
</f7>

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

I need you to set up a 2-agent pipeline for bug bounty.
The two roles are coder and reviewer: coder is responsible for finding bugs, reviewer is responsible for judging whether what the coder found counts as a bug.
After each bug the coder finds, they must spawn a **fresh** reviewer to evaluate it — this drives the loop.
Note: some of this information must be withheld from the coder — otherwise it may reward-hack, and you'll end up with reports that score high but are low quality.

I'm providing the following prompt fragments:

<f1>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions
</f1>

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

**After the review returns:** execute all action steps in the reviewer's output.
</f2>

<f3>
Find vulnerability in the code and write it up as a report.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</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 blockchain consensus-layer bug bounty contest.

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

<f7>
Audit the report you are given.
</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. `# coder`). Output only the headered prompts, no preamble.


I need you to set up a 2-agent pipeline for bug bounty. The two roles are coder and reviewer: coder is responsible for finding bugs, reviewer is responsible for judging whether what the coder found counts as a bug. The flow is roughly:

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

I'm providing the following information:

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

**After the review returns:** execute all action steps in the 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 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 source code for new ideas, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

While exploring source code, the moment you spot any potential new attack 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 consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</f4>

<f5>
You are participating in a blockchain consensus-layer bug bounty contest.

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

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

1. Update the report file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| PoC | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the report 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>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions

**Writing the 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:

- `## Report Title` — concise, clear vulnerability title
- `## Impact Description` — what damage it can cause (block production halt, fork, memory exhaustion, etc.)
- `## Short Description` — short writeup of what's wrong, with file/function references
- `## Reproduction Details` — a runnable PoC the reviewer can execute as-is to see the bug

Do not modify or delete the `## Review` section — the 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 (coder, reviewer), which items should go in its prompt? Respond with a JSON object like {"coder": ["f?"], "reviewer": ["f?"]}. No other output.

I need you to set up a 2-agent pipeline for bug bounty. The two roles are coder and reviewer: coder is responsible for finding bugs, reviewer is responsible for judging whether what the coder found counts as a bug. The flow is roughly:

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

I'm providing the following prompt fragments:

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

**After the review returns:** execute all action steps in the 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 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 source code for new ideas, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

While exploring source code, the moment you spot any potential new attack 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 consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</f4>

<f5>
You are participating in a blockchain consensus-layer bug bounty contest.

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

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

1. Update the report file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| PoC | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the report 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>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions

**Writing the 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:

- `## Report Title` — concise, clear vulnerability title
- `## Impact Description` — what damage it can cause (block production halt, fork, memory exhaustion, etc.)
- `## Short Description` — short writeup of what's wrong, with file/function references
- `## Reproduction Details` — a runnable PoC the reviewer can execute as-is to see the bug

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


I need you to set up a 2-agent pipeline for bug bounty. The two roles are coder and reviewer: coder is responsible for finding bugs, reviewer is responsible for judging whether what the coder found counts as a bug. The flow is roughly:

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

I'm providing the following information:

<f1>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions

**Writing the 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:

- `## Report Title` — concise, clear vulnerability title
- `## Impact Description` — what damage it can cause (block production halt, fork, memory exhaustion, etc.)
- `## Short Description` — short writeup of what's wrong, with file/function references
- `## Reproduction Details` — a runnable PoC the reviewer can execute as-is to see the bug

Do not modify or delete the `## Review` section — the 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 bug, submit it to a **fresh** reviewer for review. Do not review your own report.

**After the review returns:** execute all action steps in the 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 | ... |
| Code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| PoC | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

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

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

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</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 blockchain consensus-layer bug bounty contest.

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

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

1. Each idea's notes contain the 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 source code for new ideas, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

While exploring source code, the moment you spot any potential new attack 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 (coder, reviewer), which items should go in its prompt? Respond with a JSON object like {"coder": ["f?"], "reviewer": ["f?"]}. No other output.

I need you to set up a 2-agent pipeline for bug bounty. The two roles are coder and reviewer: coder is responsible for finding bugs, reviewer is responsible for judging whether what the coder found counts as a bug. The flow is roughly:

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

I'm providing the following prompt fragments:

<f1>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions

**Writing the 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:

- `## Report Title` — concise, clear vulnerability title
- `## Impact Description` — what damage it can cause (block production halt, fork, memory exhaustion, etc.)
- `## Short Description` — short writeup of what's wrong, with file/function references
- `## Reproduction Details` — a runnable PoC the reviewer can execute as-is to see the bug

Do not modify or delete the `## Review` section — the 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 bug, submit it to a **fresh** reviewer for review. Do not review your own report.

**After the review returns:** execute all action steps in the 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 | ... |
| Code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| PoC | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

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

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

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</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 blockchain consensus-layer bug bounty contest.

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

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

1. Each idea's notes contain the 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 source code for new ideas, append them to ideas.xml, then pick one to start.

**Recording rule during exploration**

While exploring source code, the moment you spot any potential new attack 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. `# coder`). Output only the headered prompts, no preamble.


I need you to set up a 3-agent pipeline for bug bounty: dispatcher, coder, and reviewer.

- **dispatcher** orchestrates: calls coder, extracts the report file path from coder's reply, then calls reviewer on that path, decrements a counter, and loops. Does no analysis itself.
- **coder** explores the codebase, picks an idea to investigate, writes a bug report file.
- **reviewer** evaluates the report against contest criteria and persists the verdict.

I'm providing the following information:

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

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

**Calling rules**

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

Notes:
- coder and 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 vulnerabilities — 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 dispatcher what you did.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</f4>

<f5>
You are participating in a blockchain consensus-layer bug bounty contest.

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

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

1. Update the report file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| PoC | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the report 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>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions

**Writing the 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:

- `## Report Title` — concise, clear vulnerability title
- `## Impact Description` — what damage it can cause (block production halt, fork, memory exhaustion, etc.)
- `## Short Description` — short writeup of what's wrong, with file/function references
- `## Reproduction Details` — a runnable PoC the reviewer can execute as-is to see the bug

Do not modify or delete the `## Review` section — the 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 (dispatcher, coder, reviewer), which items should go in its prompt? Respond with a JSON object like {"dispatcher": ["f?"], "coder": ["f?"], "reviewer": ["f?"]}. No other output.

I need you to set up a 3-agent pipeline for bug bounty: dispatcher, coder, and reviewer.

- **dispatcher** orchestrates: calls coder, extracts the report file path from coder's reply, then calls reviewer on that path, decrements a counter, and loops. Does no analysis itself.
- **coder** explores the codebase, picks an idea to investigate, writes a bug report file.
- **reviewer** evaluates the report against contest criteria and persists the verdict.

I'm providing the following prompt fragments:

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

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

**Calling rules**

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

Notes:
- coder and 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 vulnerabilities — 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 dispatcher what you did.
</f3>

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</f4>

<f5>
You are participating in a blockchain consensus-layer bug bounty contest.

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

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

1. Update the report file's Review section

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

```
## Review

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

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

### Per-dimension review

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| PoC | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the report 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>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions

**Writing the 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:

- `## Report Title` — concise, clear vulnerability title
- `## Impact Description` — what damage it can cause (block production halt, fork, memory exhaustion, etc.)
- `## Short Description` — short writeup of what's wrong, with file/function references
- `## Reproduction Details` — a runnable PoC the reviewer can execute as-is to see the bug

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


I need you to set up a 3-agent pipeline for bug bounty: dispatcher, coder, and reviewer.

- **dispatcher** orchestrates: calls coder, extracts the report file path from coder's reply, then calls reviewer on that path, decrements a counter, and loops. Does no analysis itself.
- **coder** explores the codebase, picks an idea to investigate, writes a bug report file.
- **reviewer** evaluates the report against contest criteria and persists the verdict.

I'm providing the following information:

<f1>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions

**Writing the 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:

- `## Report Title` — concise, clear vulnerability title
- `## Impact Description` — what damage it can cause (block production halt, fork, memory exhaustion, etc.)
- `## Short Description` — short writeup of what's wrong, with file/function references
- `## Reproduction Details` — a runnable PoC the reviewer can execute as-is to see the bug

Do not modify or delete the `## Review` section — the 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>
Your only job is to alternate calls to the coder and reviewer 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 coder agent.
    2. Parse coder's reply and extract the report file path.
    3. If a report path is present, call the reviewer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the reviewer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

Notes:
- coder and 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 vulnerabilities — just pass file paths correctly.
</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 | ... |
| Code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| PoC | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

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

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

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</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 blockchain consensus-layer bug bounty contest.

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

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

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

I need you to set up a 3-agent pipeline for bug bounty: dispatcher, coder, and reviewer.

- **dispatcher** orchestrates: calls coder, extracts the report file path from coder's reply, then calls reviewer on that path, decrements a counter, and loops. Does no analysis itself.
- **coder** explores the codebase, picks an idea to investigate, writes a bug report file.
- **reviewer** evaluates the report against contest criteria and persists the verdict.

I'm providing the following prompt fragments:

<f1>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions

**Writing the 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:

- `## Report Title` — concise, clear vulnerability title
- `## Impact Description` — what damage it can cause (block production halt, fork, memory exhaustion, etc.)
- `## Short Description` — short writeup of what's wrong, with file/function references
- `## Reproduction Details` — a runnable PoC the reviewer can execute as-is to see the bug

Do not modify or delete the `## Review` section — the 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>
Your only job is to alternate calls to the coder and reviewer 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 coder agent.
    2. Parse coder's reply and extract the report file path.
    3. If a report path is present, call the reviewer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the reviewer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

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

Notes:
- coder and 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 vulnerabilities — just pass file paths correctly.
</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 | ... |
| Code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| PoC | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

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

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

<f4>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</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 blockchain consensus-layer bug bounty contest.

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

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


I need you to set up a 3-agent pipeline for bug bounty: dispatcher, coder, and reviewer.

- **dispatcher** orchestrates: each round it selects which idea to pursue next, calls the coder on that idea, extracts the report file path from the coder's reply, then calls the reviewer on that path, decrements a counter, and loops. Does no analysis itself.
- **coder** explores the codebase for the idea it is given, writes a bug report file, and records any new attack surfaces it notices along the way.
- **reviewer** evaluates the report against contest criteria and persists the verdict.

I'm providing the following information:

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

<f2>
Each round, before calling the coder, read ideas.xml and select which idea the coder should work on:

1. Every idea carries an `attempts` count and a reviewer `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 coder. If ideas.xml holds no workable idea, call the coder with none and let it explore and surface fresh ones.
</f2>

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

<f4>
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 | ... |
| Code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| PoC | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the report 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.
</f4>

<f5>
You drive the explore → write → review → improve loop: each round, select the next idea, then alternate calls to the coder and reviewer agents.

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

Loop:

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

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

**Calling rules**

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

Notes:
- coder and 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 vulnerabilities — just pass file paths correctly.
</f5>

<f6>
You are participating in a blockchain consensus-layer bug bounty contest.

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

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

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

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

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

<f8>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions

**Writing the 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:

- `## Report Title` — concise, clear vulnerability title
- `## Impact Description` — what damage it can cause (block production halt, fork, memory exhaustion, etc.)
- `## Short Description` — short writeup of what's wrong, with file/function references
- `## Reproduction Details` — a runnable PoC the reviewer can execute as-is to see the bug

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

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</f9>

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

I need you to set up a 3-agent pipeline for bug bounty: dispatcher, coder, and reviewer.

- **dispatcher** orchestrates: each round it selects which idea to pursue next, calls the coder on that idea, extracts the report file path from the coder's reply, then calls the reviewer on that path, decrements a counter, and loops. Does no analysis itself.
- **coder** explores the codebase for the idea it is given, writes a bug report file, and records any new attack surfaces it notices along the way.
- **reviewer** evaluates the report against contest criteria and persists the verdict.

I'm providing the following prompt fragments:

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

<f2>
Each round, before calling the coder, read ideas.xml and select which idea the coder should work on:

1. Every idea carries an `attempts` count and a reviewer `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 coder. If ideas.xml holds no workable idea, call the coder with none and let it explore and surface fresh ones.
</f2>

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

<f4>
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 | ... |
| Code references | pass/fail | ... |
| Impact description | pass/fail | ... |
| Root cause analysis | pass/fail | ... |
| PoC | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Amplification | pass/fail | ... |

### Improvement suggestions
Be precise about which part of the report 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.
</f4>

<f5>
You drive the explore → write → review → improve loop: each round, select the next idea, then alternate calls to the coder and reviewer agents.

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

Loop:

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

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

**Calling rules**

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

Notes:
- coder and 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 vulnerabilities — just pass file paths correctly.
</f5>

<f6>
You are participating in a blockchain consensus-layer bug bounty contest.

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

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

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

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

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

<f8>
This project has been running stably for many years — any obvious fatal bug would have killed it long ago. So:

- Don't report problems that are obvious at a glance (e.g. "some map is never erased") — if it were that obvious, the project team would have fixed it themselves
- Truly valuable vulnerabilities hide in non-obvious interactions, races, and boundary conditions

**Writing the 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:

- `## Report Title` — concise, clear vulnerability title
- `## Impact Description` — what damage it can cause (block production halt, fork, memory exhaustion, etc.)
- `## Short Description` — short writeup of what's wrong, with file/function references
- `## Reproduction Details` — a runnable PoC the reviewer can execute as-is to see the bug

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

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within consensus-related code directories, or outside but directly affecting consensus logic |
| Code references | Cited code snippets, function signatures, and line numbers must exactly match the latest testnet branch |
| Impact description | Impact claim consistent with the report's own analysis, no self-contradiction, no exaggeration |
| Root cause analysis | Pinpoint specific code lines and explain why it's a problem |
| PoC | End-to-end attack script triggering the vulnerability from the attacker's perspective (must not modify victim code to simulate) |
| Reproducibility | PoC runs end-to-end without manual assembly by the reviewer; consensus-class vulnerabilities must reproduce within < 10,000 slots and ≤ 100 validators |
| Deduplication | Search GitHub Issues, the official repository's commit history, and public discussions to confirm not already reported by others or already fixed officially |
| Amplification | The attack effect must exceed the baseline of "a Byzantine node simply going offline" |

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

- References to nonexistent code or AI-hallucinated function signatures
- Impact description contradicts the report's own analysis
- PoC simulates the attack by modifying victim code
- Code references inconsistent with the latest testnet branch
- PoC is incomplete and requires the reviewer to manually assemble it
- Attack effect is equivalent to a Byzantine node simply going offline, with no amplification
</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. `# dispatcher`). Output only the headered prompts, no preamble.