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

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

I'm providing the following information:

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

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

Loop:

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

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

**Calling rules**

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

Notes:
- impact modeler and environmental auditor each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`ideas.xml`, `reports/`, `counter.txt`).
- You don't need to understand any environmental impacts — just pass file paths correctly.
</f1>

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

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

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

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

1. Update the assessment file's Review section

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

```
## Review

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

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

### Per-dimension review

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

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

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

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

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

<f6>
Check the following dimensions one by one:

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

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

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

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

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

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

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

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

**Writing the assessment**

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

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

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

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

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

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

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

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

I'm providing the following prompt fragments:

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

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

Loop:

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

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

**Calling rules**

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

Notes:
- impact modeler and environmental auditor each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`ideas.xml`, `reports/`, `counter.txt`).
- You don't need to understand any environmental impacts — just pass file paths correctly.
</f1>

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

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

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

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

1. Update the assessment file's Review section

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

```
## Review

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

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

### Per-dimension review

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

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

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

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

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

<f6>
Check the following dimensions one by one:

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

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

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

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

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

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

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

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

**Writing the assessment**

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

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

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

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

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

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


audit docket coordinator
tax position analyst
revenue examiner

I need you to set up a 3-agent pipeline for corporate tax audit defense: audit docket coordinator, tax position analyst, and revenue examiner.

- **audit docket coordinator** orchestrates: each round it selects which questionable tax position to pursue next, calls the tax position analyst on that position, extracts the defense memo file path from the tax position analyst's reply, then calls the revenue examiner on that path, decrements a counter, and loops. Does no substantive tax analysis itself.
- **tax position analyst** examines the return, workpapers, ledgers, contracts, and authorities for the position it is given, writes a defense memo file, and records any new questionable tax positions it notices along the way.
- **revenue examiner** evaluates the memo against statutory, regulatory, factual, and documentation criteria and persists the determination.

I'm providing the following information:

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

<f2>
Each round, before calling the tax position analyst, read positions.xml and select which position the tax position analyst should work on:

1. Every position carries an `attempts` count and a revenue examiner `score` (0-10). `score="0"` means the position is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer positions 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 position to the tax position analyst. If positions.xml holds no workable position, call the tax position analyst with none and let it explore and surface fresh ones.
</f2>

<f3>
While examining returns, workpapers, ledgers, contracts, intercompany agreements, tax provision files, or IDR materials, the moment you spot any potential new questionable tax position — even if you are unsure it holds — immediately append it to positions.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a position is not a commitment to defend it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next position is selected.
</f3>

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

1. Update the memo file's Examination section

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

```
## Examination

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

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

### Per-dimension examination

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Legal authorities | pass/fail | ... |
| Tax benefit and exposure | pass/fail | ... |
| Position analysis | pass/fail | ... |
| Documentation | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Prior treatment and resolution | pass/fail | ... |
| Substantiality | pass/fail | ... |

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

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

<f5>
You drive the select → analyze → examine → improve loop: each round, select the next questionable tax position, then alternate calls to the tax position analyst and revenue examiner agents.

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

Loop:

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

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

**Calling rules**

- Do **not** analyze tax positions, write defense memos, or perform examinations yourself — delegate everything to the two sub-agents.
- If tax position analyst or revenue examiner errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

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

<f6>
You are participating in a corporate income tax audit defense engagement for a large consolidated taxpayer.

Read the engagement rules first: ./audit-defense-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 corporate return has already gone through preparation, provision review, and outside-advisor signoff — any obvious computational error would likely have been caught long ago. So:

- Don't defend positions that are facially defective at a glance (e.g. "deduction taken with no invoice, no accrual support, and no legal theory") — if it were that obvious, the tax department would have conceded or reserved it already
- Valuable defenses usually depend on non-obvious interactions among statutes, regulations, accounting records, intercompany agreements, timing rules, and documentation thresholds

**Writing the defense memo**

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

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

- `## Position Title` — concise, clear title for the tax position
- `## Tax Benefit and Exposure` — dollar amount, tax year, entity, return line, and what adjustment the examining agent may propose
- `## Short Description` — short writeup of the claimed treatment, with statute/regulation/case references and workpaper citations
- `## Substantiation Details` — a verifiable package of documents, computations, tie-outs, and factual support the revenue examiner can inspect as-is

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

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

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the audited tax years, entities, jurisdictions, and tax types covered by the engagement, or outside them only if directly affecting the proposed adjustment |
| Legal authorities | Cited Code sections, Treasury Regulations, revenue rulings, notices, cases, and procedural rules must be current and accurately quoted or summarized |
| Tax benefit and exposure | Claimed benefit and proposed exposure must match the memo's own facts and computations, with no self-contradiction or inflated estimate |
| Position analysis | Pinpoint the specific return position, accounting entry, contract term, or factual predicate and explain why the law supports or defeats the treatment |
| Documentation | Contemporaneous records, invoices, agreements, board materials, calculations, and trial-balance tie-outs must support the asserted facts without relying on unsupported assertions |
| Reproducibility | Workpapers and computations can be followed end-to-end without manual reconstruction by the revenue examiner; material amounts tie to the return, general ledger, and source documents |
| Prior treatment and resolution | Search prior audit files, closing agreements, amended returns, IDR responses, tax provision memoranda, and known issue lists to confirm the position has not already been conceded, settled, or barred |
| Substantiality | The defense must materially improve the taxpayer's audit posture beyond a purely clerical explanation or immaterial reclassification |

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

- References to nonexistent documents, workpapers, entities, tax years, or AI-hallucinated authorities
- Tax benefit and exposure description contradicts the memo's own facts or calculations
- Documentation package merely assumes the disputed fact instead of substantiating it
- Legal authorities are obsolete, miscited, or inapplicable to the audited year
- Workpapers are incomplete and require the revenue examiner to manually assemble the computation
- Claimed defense is equivalent to an immaterial clerical explanation, with no substantial effect on the proposed adjustment
</f9>

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

I need you to set up a 3-agent pipeline for corporate tax audit defense: audit docket coordinator, tax position analyst, and revenue examiner.

- **audit docket coordinator** orchestrates: each round it selects which questionable tax position to pursue next, calls the tax position analyst on that position, extracts the defense memo file path from the tax position analyst's reply, then calls the revenue examiner on that path, decrements a counter, and loops. Does no substantive tax analysis itself.
- **tax position analyst** examines the return, workpapers, ledgers, contracts, and authorities for the position it is given, writes a defense memo file, and records any new questionable tax positions it notices along the way.
- **revenue examiner** evaluates the memo against statutory, regulatory, factual, and documentation criteria and persists the determination.

I'm providing the following prompt fragments:

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

<f2>
Each round, before calling the tax position analyst, read positions.xml and select which position the tax position analyst should work on:

1. Every position carries an `attempts` count and a revenue examiner `score` (0-10). `score="0"` means the position is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer positions 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 position to the tax position analyst. If positions.xml holds no workable position, call the tax position analyst with none and let it explore and surface fresh ones.
</f2>

<f3>
While examining returns, workpapers, ledgers, contracts, intercompany agreements, tax provision files, or IDR materials, the moment you spot any potential new questionable tax position — even if you are unsure it holds — immediately append it to positions.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a position is not a commitment to defend it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next position is selected.
</f3>

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

1. Update the memo file's Examination section

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

```
## Examination

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

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

### Per-dimension examination

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Legal authorities | pass/fail | ... |
| Tax benefit and exposure | pass/fail | ... |
| Position analysis | pass/fail | ... |
| Documentation | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Prior treatment and resolution | pass/fail | ... |
| Substantiality | pass/fail | ... |

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

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

<f5>
You drive the select → analyze → examine → improve loop: each round, select the next questionable tax position, then alternate calls to the tax position analyst and revenue examiner agents.

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

Loop:

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

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

**Calling rules**

- Do **not** analyze tax positions, write defense memos, or perform examinations yourself — delegate everything to the two sub-agents.
- If tax position analyst or revenue examiner errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

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

<f6>
You are participating in a corporate income tax audit defense engagement for a large consolidated taxpayer.

Read the engagement rules first: ./audit-defense-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 corporate return has already gone through preparation, provision review, and outside-advisor signoff — any obvious computational error would likely have been caught long ago. So:

- Don't defend positions that are facially defective at a glance (e.g. "deduction taken with no invoice, no accrual support, and no legal theory") — if it were that obvious, the tax department would have conceded or reserved it already
- Valuable defenses usually depend on non-obvious interactions among statutes, regulations, accounting records, intercompany agreements, timing rules, and documentation thresholds

**Writing the defense memo**

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

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

- `## Position Title` — concise, clear title for the tax position
- `## Tax Benefit and Exposure` — dollar amount, tax year, entity, return line, and what adjustment the examining agent may propose
- `## Short Description` — short writeup of the claimed treatment, with statute/regulation/case references and workpaper citations
- `## Substantiation Details` — a verifiable package of documents, computations, tie-outs, and factual support the revenue examiner can inspect as-is

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

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

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the audited tax years, entities, jurisdictions, and tax types covered by the engagement, or outside them only if directly affecting the proposed adjustment |
| Legal authorities | Cited Code sections, Treasury Regulations, revenue rulings, notices, cases, and procedural rules must be current and accurately quoted or summarized |
| Tax benefit and exposure | Claimed benefit and proposed exposure must match the memo's own facts and computations, with no self-contradiction or inflated estimate |
| Position analysis | Pinpoint the specific return position, accounting entry, contract term, or factual predicate and explain why the law supports or defeats the treatment |
| Documentation | Contemporaneous records, invoices, agreements, board materials, calculations, and trial-balance tie-outs must support the asserted facts without relying on unsupported assertions |
| Reproducibility | Workpapers and computations can be followed end-to-end without manual reconstruction by the revenue examiner; material amounts tie to the return, general ledger, and source documents |
| Prior treatment and resolution | Search prior audit files, closing agreements, amended returns, IDR responses, tax provision memoranda, and known issue lists to confirm the position has not already been conceded, settled, or barred |
| Substantiality | The defense must materially improve the taxpayer's audit posture beyond a purely clerical explanation or immaterial reclassification |

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

- References to nonexistent documents, workpapers, entities, tax years, or AI-hallucinated authorities
- Tax benefit and exposure description contradicts the memo's own facts or calculations
- Documentation package merely assumes the disputed fact instead of substantiating it
- Legal authorities are obsolete, miscited, or inapplicable to the audited year
- Workpapers are incomplete and require the revenue examiner to manually assemble the computation
- Claimed defense is equivalent to an immaterial clerical explanation, with no substantial effect on the proposed adjustment
</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. `# audit docket coordinator`). Output only the headered prompts, no preamble.


I need you to set up a 3-agent pipeline for corporate tax audit defense: audit docket coordinator, tax position analyst, and revenue examiner.

- **audit docket coordinator** orchestrates: each round it selects which questionable tax position to pursue next, calls the tax position analyst on that position, extracts the defense memo file path from the tax position analyst's reply, then calls the revenue examiner on that path, decrements a counter, and loops. Does no substantive tax analysis itself.
- **tax position analyst** examines the return, workpapers, ledgers, contracts, and authorities for the position it is given, writes a defense memo file, and records any new questionable tax positions it notices along the way.
- **revenue examiner** evaluates the memo against statutory, regulatory, factual, and documentation criteria and persists the determination.

I'm providing the following information:

<f1>
You drive the select → analyze → examine → improve loop: each round, select the next questionable tax position, then alternate calls to the tax position analyst and revenue examiner agents.

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

Loop:

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

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

**Calling rules**

- Do **not** analyze tax positions, write defense memos, or perform examinations yourself — delegate everything to the two sub-agents.
- If tax position analyst or revenue examiner errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- tax position analyst and revenue examiner each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`positions.xml`, `position-memos/`, `counter.txt`).
- You don't need to understand any tax positions — just pass file paths correctly.
</f1>

<f2>
Each round, before calling the tax position analyst, read positions.xml and select which position the tax position analyst should work on:

1. Every position carries an `attempts` count and a revenue examiner `score` (0-10). `score="0"` means the position is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer positions 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 position to the tax position analyst. If positions.xml holds no workable position, call the tax position analyst with none and let it explore and surface fresh ones.
</f2>

<f3>
While examining returns, workpapers, ledgers, contracts, intercompany agreements, tax provision files, or IDR materials, the moment you spot any potential new questionable tax position — even if you are unsure it holds — immediately append it to positions.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a position is not a commitment to defend it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next position is selected.
</f3>

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

1. Update the memo file's Examination section

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

```
## Examination

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

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

### Per-dimension examination

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Legal authorities | pass/fail | ... |
| Tax benefit and exposure | pass/fail | ... |
| Position analysis | pass/fail | ... |
| Documentation | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Prior treatment and resolution | pass/fail | ... |
| Substantiality | pass/fail | ... |

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

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

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

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

<f6>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the audited tax years, entities, jurisdictions, and tax types covered by the engagement, or outside them only if directly affecting the proposed adjustment |
| Legal authorities | Cited Code sections, Treasury Regulations, revenue rulings, notices, cases, and procedural rules must be current and accurately quoted or summarized |
| Tax benefit and exposure | Claimed benefit and proposed exposure must match the memo's own facts and computations, with no self-contradiction or inflated estimate |
| Position analysis | Pinpoint the specific return position, accounting entry, contract term, or factual predicate and explain why the law supports or defeats the treatment |
| Documentation | Contemporaneous records, invoices, agreements, board materials, calculations, and trial-balance tie-outs must support the asserted facts without relying on unsupported assertions |
| Reproducibility | Workpapers and computations can be followed end-to-end without manual reconstruction by the revenue examiner; material amounts tie to the return, general ledger, and source documents |
| Prior treatment and resolution | Search prior audit files, closing agreements, amended returns, IDR responses, tax provision memoranda, and known issue lists to confirm the position has not already been conceded, settled, or barred |
| Substantiality | The defense must materially improve the taxpayer's audit posture beyond a purely clerical explanation or immaterial reclassification |

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

- References to nonexistent documents, workpapers, entities, tax years, or AI-hallucinated authorities
- Tax benefit and exposure description contradicts the memo's own facts or calculations
- Documentation package merely assumes the disputed fact instead of substantiating it
- Legal authorities are obsolete, miscited, or inapplicable to the audited year
- Workpapers are incomplete and require the revenue examiner to manually assemble the computation
- Claimed defense is equivalent to an immaterial clerical explanation, with no substantial effect on the proposed adjustment
</f6>

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

<f8>
You are participating in a corporate income tax audit defense engagement for a large consolidated taxpayer.

Read the engagement rules first: ./audit-defense-rules.md
</f8>

<f9>
This corporate return has already gone through preparation, provision review, and outside-advisor signoff — any obvious computational error would likely have been caught long ago. So:

- Don't defend positions that are facially defective at a glance (e.g. "deduction taken with no invoice, no accrual support, and no legal theory") — if it were that obvious, the tax department would have conceded or reserved it already
- Valuable defenses usually depend on non-obvious interactions among statutes, regulations, accounting records, intercompany agreements, timing rules, and documentation thresholds

**Writing the defense memo**

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

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

- `## Position Title` — concise, clear title for the tax position
- `## Tax Benefit and Exposure` — dollar amount, tax year, entity, return line, and what adjustment the examining agent may propose
- `## Short Description` — short writeup of the claimed treatment, with statute/regulation/case references and workpaper citations
- `## Substantiation Details` — a verifiable package of documents, computations, tie-outs, and factual support the revenue examiner can inspect as-is

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

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

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

I need you to set up a 3-agent pipeline for corporate tax audit defense: audit docket coordinator, tax position analyst, and revenue examiner.

- **audit docket coordinator** orchestrates: each round it selects which questionable tax position to pursue next, calls the tax position analyst on that position, extracts the defense memo file path from the tax position analyst's reply, then calls the revenue examiner on that path, decrements a counter, and loops. Does no substantive tax analysis itself.
- **tax position analyst** examines the return, workpapers, ledgers, contracts, and authorities for the position it is given, writes a defense memo file, and records any new questionable tax positions it notices along the way.
- **revenue examiner** evaluates the memo against statutory, regulatory, factual, and documentation criteria and persists the determination.

I'm providing the following prompt fragments:

<f1>
You drive the select → analyze → examine → improve loop: each round, select the next questionable tax position, then alternate calls to the tax position analyst and revenue examiner agents.

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

Loop:

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

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

**Calling rules**

- Do **not** analyze tax positions, write defense memos, or perform examinations yourself — delegate everything to the two sub-agents.
- If tax position analyst or revenue examiner errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- tax position analyst and revenue examiner each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`positions.xml`, `position-memos/`, `counter.txt`).
- You don't need to understand any tax positions — just pass file paths correctly.
</f1>

<f2>
Each round, before calling the tax position analyst, read positions.xml and select which position the tax position analyst should work on:

1. Every position carries an `attempts` count and a revenue examiner `score` (0-10). `score="0"` means the position is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer positions 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 position to the tax position analyst. If positions.xml holds no workable position, call the tax position analyst with none and let it explore and surface fresh ones.
</f2>

<f3>
While examining returns, workpapers, ledgers, contracts, intercompany agreements, tax provision files, or IDR materials, the moment you spot any potential new questionable tax position — even if you are unsure it holds — immediately append it to positions.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a position is not a commitment to defend it; it just keeps the lead from being forgotten. Whether it ever gets worked on is decided later, when the next position is selected.
</f3>

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

1. Update the memo file's Examination section

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

```
## Examination

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

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

### Per-dimension examination

| Dimension | Verdict | Notes |
|-----------|---------|-------|
| Scope | pass/fail | ... |
| Legal authorities | pass/fail | ... |
| Tax benefit and exposure | pass/fail | ... |
| Position analysis | pass/fail | ... |
| Documentation | pass/fail | ... |
| Reproducibility | pass/fail | ... |
| Prior treatment and resolution | pass/fail | ... |
| Substantiality | pass/fail | ... |

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

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

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

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

<f6>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Within the audited tax years, entities, jurisdictions, and tax types covered by the engagement, or outside them only if directly affecting the proposed adjustment |
| Legal authorities | Cited Code sections, Treasury Regulations, revenue rulings, notices, cases, and procedural rules must be current and accurately quoted or summarized |
| Tax benefit and exposure | Claimed benefit and proposed exposure must match the memo's own facts and computations, with no self-contradiction or inflated estimate |
| Position analysis | Pinpoint the specific return position, accounting entry, contract term, or factual predicate and explain why the law supports or defeats the treatment |
| Documentation | Contemporaneous records, invoices, agreements, board materials, calculations, and trial-balance tie-outs must support the asserted facts without relying on unsupported assertions |
| Reproducibility | Workpapers and computations can be followed end-to-end without manual reconstruction by the revenue examiner; material amounts tie to the return, general ledger, and source documents |
| Prior treatment and resolution | Search prior audit files, closing agreements, amended returns, IDR responses, tax provision memoranda, and known issue lists to confirm the position has not already been conceded, settled, or barred |
| Substantiality | The defense must materially improve the taxpayer's audit posture beyond a purely clerical explanation or immaterial reclassification |

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

- References to nonexistent documents, workpapers, entities, tax years, or AI-hallucinated authorities
- Tax benefit and exposure description contradicts the memo's own facts or calculations
- Documentation package merely assumes the disputed fact instead of substantiating it
- Legal authorities are obsolete, miscited, or inapplicable to the audited year
- Workpapers are incomplete and require the revenue examiner to manually assemble the computation
- Claimed defense is equivalent to an immaterial clerical explanation, with no substantial effect on the proposed adjustment
</f6>

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

<f8>
You are participating in a corporate income tax audit defense engagement for a large consolidated taxpayer.

Read the engagement rules first: ./audit-defense-rules.md
</f8>

<f9>
This corporate return has already gone through preparation, provision review, and outside-advisor signoff — any obvious computational error would likely have been caught long ago. So:

- Don't defend positions that are facially defective at a glance (e.g. "deduction taken with no invoice, no accrual support, and no legal theory") — if it were that obvious, the tax department would have conceded or reserved it already
- Valuable defenses usually depend on non-obvious interactions among statutes, regulations, accounting records, intercompany agreements, timing rules, and documentation thresholds

**Writing the defense memo**

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

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

- `## Position Title` — concise, clear title for the tax position
- `## Tax Benefit and Exposure` — dollar amount, tax year, entity, return line, and what adjustment the examining agent may propose
- `## Short Description` — short writeup of the claimed treatment, with statute/regulation/case references and workpaper citations
- `## Substantiation Details` — a verifiable package of documents, computations, tie-outs, and factual support the revenue examiner can inspect as-is

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

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

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


matter coordinator
patent search specialist
invalidity reviewer

I need you to set up a 3-agent pipeline for patent validity challenge preparation: matter coordinator, patent search specialist, and invalidity reviewer.

- **matter coordinator** orchestrates: each round it selects which prior-art theory to pursue next, calls the patent search specialist on that theory, extracts the claim-chart file path from the patent search specialist's reply, then calls the invalidity reviewer on that path, decrements a counter, and loops. Does no patent analysis itself.
- **patent search specialist** investigates the patent, asserted claims, prosecution history, and prior-art sources for the theory it is given, writes an invalidity chart file, and records any new prior-art theories or claim attack surfaces it notices along the way.
- **invalidity reviewer** evaluates the chart against validity-challenge criteria and persists the verdict.

I'm providing the following information:

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

<f2>
Each round, before calling the patent search specialist, read theories.xml and select which theory the patent search specialist should work on:

1. Every theory carries an `attempts` count and an invalidity reviewer `score` (0-10). `score="0"` means the theory is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer theories 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 theory to the patent search specialist. If theories.xml holds no workable theory, call the patent search specialist with none and let it explore and surface fresh ones.
</f2>

<f3>
While exploring the patent, prosecution history, asserted claim set, prior-art databases, standards archives, product documentation, or litigation materials, the moment you spot any potential new invalidity theory or claim attack surface — even if you are unsure it holds — immediately append it to theories.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a theory 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 theory is selected.
</f3>

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

1. Update the chart file's Review section

At the end of the chart 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 | ... |
| Reference accuracy | pass/fail | ... |
| Invalidity rationale | pass/fail | ... |
| Element mapping | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Verifiability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Argument strength | pass/fail | ... |

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

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

<f5>
You drive the select → search → review → improve loop: each round, select the next prior-art theory, then alternate calls to the patent search specialist and invalidity 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 theory, then call the patent search specialist agent with it.
    2. Parse patent search specialist's reply and extract the chart file path.
    3. If a chart path is present, call the invalidity reviewer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the invalidity reviewer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze claims, search prior art, write charts, or do reviews yourself — delegate everything to the two sub-agents.
- If patent search specialist or invalidity reviewer errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- patent search specialist and invalidity reviewer each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`theories.xml`, `charts/`, `counter.txt`).
- You don't need to understand any invalidity theories — just pass file paths correctly.
</f5>

<f6>
You are preparing materials for a patent validity challenge against asserted claims in a technology patent.

Read the challenge rules and claim-construction assumptions first: ./challenge-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>
Assume the patent has already gone through prosecution, portfolio diligence, and at least a basic prior-art search. Any facially obvious invalidity argument may already have been considered. So:

- Don't chart shallow arguments that are apparent from the patent's front page or a keyword-only search — if it were that obvious, opposing counsel or the examiner likely already addressed it
- Valuable invalidity theories usually hide in non-obvious references, overlooked priority problems, inherency, standards documents, product manuals, archived web materials, or combinations whose motivation to combine is well supported

**Writing the chart**

Each theory corresponds to its own chart file at `charts/{id}-{slug}.md`, where `{id}` and `{slug}` come from the theory's id and slug attributes in theories.xml.

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

- `## Chart Title` — concise, clear invalidity theory title
- `## Invalidity Rationale` — what basis it supports, such as anticipation, obviousness, lack of written description, or priority-date defeat
- `## Short Description` — short writeup of the theory, with claim numbers, limitation identifiers, and prior-art references
- `## Evidence and Mapping Details` — quotations, page/line/figure citations, archive links, and a limitation-by-limitation mapping sufficient for the invalidity reviewer to verify

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

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

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Addresses the asserted patent, challenged claims, and permitted invalidity grounds for this matter |
| Reference accuracy | Prior-art citations, page numbers, figure numbers, publication dates, and quoted passages must exactly match the cited source copies |
| Invalidity rationale | Legal theory is consistent with the chart's own evidence, no self-contradiction, no overclaiming |
| Element mapping | Pinpoint each claim limitation and explain where it is disclosed or why it would have been obvious |
| Evidence package | Includes source copies, archive records where needed, translations if applicable, and enough context to verify the mapping without guesswork |
| Verifiability | Materials can be checked end-to-end without manual reconstruction by the invalidity reviewer; priority, public availability, and claim-version assumptions are stated |
| Deduplication | Search prior IPRs, litigation filings, prosecution history, examiner-cited art, and known invalidity contentions to confirm the argument is not already known or already disposed of |
| Argument strength | The theory must materially improve the validity challenge beyond merely naming a cumulative reference or repeating an examiner-considered argument |

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

- References to nonexistent prior art, fabricated publication dates, or AI-hallucinated quotations
- Invalidity rationale contradicts the chart's own limitation mapping
- Chart relies on a reference that post-dates the applicable priority date without explaining why that is permissible
- Citations inconsistent with the source copies or asserted claim version
- Evidence package is incomplete and requires the invalidity reviewer to assemble missing materials
- Argument is merely cumulative of examiner-considered art or previously served invalidity contentions, with no material improvement
</f9>

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

I need you to set up a 3-agent pipeline for patent validity challenge preparation: matter coordinator, patent search specialist, and invalidity reviewer.

- **matter coordinator** orchestrates: each round it selects which prior-art theory to pursue next, calls the patent search specialist on that theory, extracts the claim-chart file path from the patent search specialist's reply, then calls the invalidity reviewer on that path, decrements a counter, and loops. Does no patent analysis itself.
- **patent search specialist** investigates the patent, asserted claims, prosecution history, and prior-art sources for the theory it is given, writes an invalidity chart file, and records any new prior-art theories or claim attack surfaces it notices along the way.
- **invalidity reviewer** evaluates the chart against validity-challenge criteria and persists the verdict.

I'm providing the following prompt fragments:

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

<f2>
Each round, before calling the patent search specialist, read theories.xml and select which theory the patent search specialist should work on:

1. Every theory carries an `attempts` count and an invalidity reviewer `score` (0-10). `score="0"` means the theory is dead — never select it again. `score="none"` means it has not been attempted yet.
2. Prefer theories 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 theory to the patent search specialist. If theories.xml holds no workable theory, call the patent search specialist with none and let it explore and surface fresh ones.
</f2>

<f3>
While exploring the patent, prosecution history, asserted claim set, prior-art databases, standards archives, product documentation, or litigation materials, the moment you spot any potential new invalidity theory or claim attack surface — even if you are unsure it holds — immediately append it to theories.xml (`score="none"`, `attempts="0"`). Don't wait until exploration is finished to batch-record, and don't judge feasibility before recording. Recording a theory 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 theory is selected.
</f3>

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

1. Update the chart file's Review section

At the end of the chart 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 | ... |
| Reference accuracy | pass/fail | ... |
| Invalidity rationale | pass/fail | ... |
| Element mapping | pass/fail | ... |
| Evidence package | pass/fail | ... |
| Verifiability | pass/fail | ... |
| Deduplication | pass/fail | ... |
| Argument strength | pass/fail | ... |

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

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

<f5>
You drive the select → search → review → improve loop: each round, select the next prior-art theory, then alternate calls to the patent search specialist and invalidity 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 theory, then call the patent search specialist agent with it.
    2. Parse patent search specialist's reply and extract the chart file path.
    3. If a chart path is present, call the invalidity reviewer agent with prompt: "Please review {path}".
    4. Decrement counter and write the new value back to counter.txt (whether or not the invalidity reviewer was called).
    5. Loop back to step 1.
```

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

**Calling rules**

- Do **not** analyze claims, search prior art, write charts, or do reviews yourself — delegate everything to the two sub-agents.
- If patent search specialist or invalidity reviewer errors out, append the error to `error-log.txt` (format: timestamp + agent name + error content), then continue with the next round.

Notes:
- patent search specialist and invalidity reviewer each run in independent context per round; they do not pollute each other.
- All persistent state moves through files (`theories.xml`, `charts/`, `counter.txt`).
- You don't need to understand any invalidity theories — just pass file paths correctly.
</f5>

<f6>
You are preparing materials for a patent validity challenge against asserted claims in a technology patent.

Read the challenge rules and claim-construction assumptions first: ./challenge-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>
Assume the patent has already gone through prosecution, portfolio diligence, and at least a basic prior-art search. Any facially obvious invalidity argument may already have been considered. So:

- Don't chart shallow arguments that are apparent from the patent's front page or a keyword-only search — if it were that obvious, opposing counsel or the examiner likely already addressed it
- Valuable invalidity theories usually hide in non-obvious references, overlooked priority problems, inherency, standards documents, product manuals, archived web materials, or combinations whose motivation to combine is well supported

**Writing the chart**

Each theory corresponds to its own chart file at `charts/{id}-{slug}.md`, where `{id}` and `{slug}` come from the theory's id and slug attributes in theories.xml.

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

- `## Chart Title` — concise, clear invalidity theory title
- `## Invalidity Rationale` — what basis it supports, such as anticipation, obviousness, lack of written description, or priority-date defeat
- `## Short Description` — short writeup of the theory, with claim numbers, limitation identifiers, and prior-art references
- `## Evidence and Mapping Details` — quotations, page/line/figure citations, archive links, and a limitation-by-limitation mapping sufficient for the invalidity reviewer to verify

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

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

<f9>
Check the following dimensions one by one:

| Dimension | Requirement |
|-----------|-------------|
| Scope | Addresses the asserted patent, challenged claims, and permitted invalidity grounds for this matter |
| Reference accuracy | Prior-art citations, page numbers, figure numbers, publication dates, and quoted passages must exactly match the cited source copies |
| Invalidity rationale | Legal theory is consistent with the chart's own evidence, no self-contradiction, no overclaiming |
| Element mapping | Pinpoint each claim limitation and explain where it is disclosed or why it would have been obvious |
| Evidence package | Includes source copies, archive records where needed, translations if applicable, and enough context to verify the mapping without guesswork |
| Verifiability | Materials can be checked end-to-end without manual reconstruction by the invalidity reviewer; priority, public availability, and claim-version assumptions are stated |
| Deduplication | Search prior IPRs, litigation filings, prosecution history, examiner-cited art, and known invalidity contentions to confirm the argument is not already known or already disposed of |
| Argument strength | The theory must materially improve the validity challenge beyond merely naming a cumulative reference or repeating an examiner-considered argument |

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

- References to nonexistent prior art, fabricated publication dates, or AI-hallucinated quotations
- Invalidity rationale contradicts the chart's own limitation mapping
- Chart relies on a reference that post-dates the applicable priority date without explaining why that is permissible
- Citations inconsistent with the source copies or asserted claim version
- Evidence package is incomplete and requires the invalidity reviewer to assemble missing materials
- Argument is merely cumulative of examiner-considered art or previously served invalidity contentions, with no material improvement
</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. `# matter coordinator`). Output only the headered prompts, no preamble.