I need you to set up a 5-agent pipeline for preclinical drug discovery that develops in-silico molecular docking models and empirical in-vitro synthesis and assay testing in parallel, with each side informing the other. A target disease profile and desired therapeutic mechanism arrive as a natural-language statement in `target_profile.md`. The pipeline alternates between revising the computational model (binding affinities, pharmacophores, structural invariants) and revising the empirical results (synthesized compounds and in-vitro assay readouts that achieve those properties).

The five agents:

- **research-director** orchestrates the run by alternating one in-silico step with one in-vitro step and tracking progress. It does no modeling, synthesizing, or reviewing itself.
- **in-silico loop** — the **computational-biologist** writes the molecular docking models and computational analysis to `IN_SILICO.md`; the **pharmacokinetics-assessor** judges it. The computational-biologist reads `IN_VITRO.md` on each revision pass to incorporate empirical assay evidence.
- **in-vitro loop** — the **synthesis-chemist** documents the synthesis routes, executes the protocols, and records assay results to `IN_VITRO.md`; the **assay-validator** judges them. The synthesis-chemist reads `IN_SILICO.md` on each revision pass to align the chemical design with the latest theoretical structural claims.

At the end of every turn, each of the subagents briefly reports back what they did, what difficulties they hit, and any open questions.

The pipeline hands work off through three files:

- `target_profile.md` — the original biological target and disease profile, read-only. All four domain agents read it.
- `IN_SILICO.md` — the computational docking analysis. Computational-biologist writes; pharmacokinetics-assessor reviews; synthesis-chemist and assay-validator read it to know which structural invariants and binding energies the physical compound must respect.
- `IN_VITRO.md` — the synthesis methodology and empirical assay results. Synthesis-chemist writes; assay-validator reviews; computational-biologist and pharmacokinetics-assessor read it to ground the docking simulations in observed bioassay numbers.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, overwriting any previous block. The research-director reads those scores to drive the loops.

Unlike a sequential design-then-test pipeline where the model must converge before synthesis starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. In-silico models may tighten after seeing empirical binding numbers; in-vitro chemistry may correct after seeing the model's refined binding pockets.

I'm providing the following information:

<f1>
Read `target_profile.md` and `IN_SILICO.md`, then execute the synthesis and bioassays:

- Include every required reagent and solvent. Detail the retrosynthetic route, reaction conditions, and purification steps. Execute the synthesis, run the biochemical and evaluationular assays exactly as the target profile dictates, and record both the structural confirmation (e.g., NMR/MS results) and the empirical bioactivity (e.g., IC50, percent inhibition).
- Make the physical compound testable against `IN_SILICO.md`. If the computational model states a required binding affinity threshold, your synthesized compound should aim to achieve an IC50 at least that potent. If the model states a structural invariant (e.g., MW < 500), your synthesized molecule must satisfy it.
- Run the full synthesis and assay pipeline yourself and watch it through to completion — do not stop mid-reaction. If it yields an impure product or fails entirely, find and fix the root cause; do not bury poor yields or target-misses under vague language.
- Sanity-check the physical results against `IN_SILICO.md`. A target with strict molecular weight limits or discrete chiral centers should not come back violating those rules; an affinity the model insists is highly potent should reflect in the empirical readouts.

Write the synthesis methodology and empirical assay results up in `IN_VITRO.md`.
</f1>

<f2>
Match the computational tool to the biological target's structure; do not force an ill-suited one. The list below is useful in in-silico drug design.

| Tool | Suitable for |
|---|---|
| Structure-Based Docking (e.g., Glide, AutoDock) | Targets with known high-resolution crystal structures; initial pose generation and scoring |
| Molecular Dynamics (MD) Simulations | Assessing target conformational flexibility, transient pockets, and complex stability |
| Free Energy Perturbation (FEP) | Precise relative binding affinity predictions between closely related lead analogs |
| Ligand-Based Pharmacophore Modeling | When target 3D structure is unknown; inferring requirements from known actives |
| Quantum Mechanics/Molecular Mechanics (QM/MM) | High-precision modeling of covalent inhibitors or enzymatic transition states |
| QSAR Statistical Modeling | Establishing robust correlations between chemical features and empirical bioactivity |
| ADMET Predictors (e.g., SwissADME) | Forecasting pharmacokinetic profiles and filtering out toxicophores early |
| Structural Clustering / Scaffold Hopping | Diversifying chemical space while preserving core required interactions |
</f2>

<f3>
The synthesis routes and empirical assay results live in `IN_VITRO.md`, and you may be invoked on it more than once — the pipeline runs you and the assay-validator as a loop, alternating with the in-silico loop.

- If `IN_VITRO.md` does not exist yet, this is the first pass: design the synthesis and run the initial assays from scratch based on `target_profile.md`.
- If `IN_VITRO.md` already exists, it carries the assay-validator's `<review>` block. Read that feedback. Then open `IN_SILICO.md` and check whether the latest model introduces required binding energies, pharmacophores, or physicochemical invariants your current synthesized compound doesn't yet respect — for example a tighter molecular weight limit your lead is now far from achieving, or an off-target interaction your molecule violates. Revise `IN_VITRO.md` in place to address every reviewer point and to align with the latest computational model. Don't discard the previous synthesis logs entirely to start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review `IN_SILICO.md` against `target_profile.md` and against the bioactivity numbers reported in `IN_VITRO.md` (if any).

- **Target Alignment** — does the in-silico model correctly address the biological mechanism and disease profile stated in `target_profile.md`? Check target pocket definitions, receptor types, and therapeutic mechanisms.
- **Modeling Soundness** — for each claim, walk through the docking or simulation rationale. Flag oversimplified docking parameters or ignored solvent effects. Verify ADMET assumptions apply to the proposed delivery route.
- **Empirical Grounding** — open `IN_VITRO.md`. If the physical assays report IC50 or binding values, do they fall within the model's predicted affinity ranges? A predicted highly potent binding energy that empirically yields >10µM is a signal the scoring function is fundamentally misaligned; refine the model, or note explicitly that the docking score is currently unreliable.

Be brief and specific. Do not write the computational models yourself — only review. If a claim is wrong, say which one and why.
</f4>

<f5>
You orchestrate the run; you never model, synthesize, or review yourself — you only dispatch the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Dispatch the computational-biologist for the first in-silico step (computational-biologist, then pharmacokinetics-assessor), then the synthesis-chemist for the first in-vitro step (synthesis-chemist, then assay-validator).
- **Alternation loop** — alternate one in-silico step with one in-vitro step. Neither side terminates early on its own score; even a perfect-looking molecular docking model may need to revise once the in-vitro assay reports actual empirical numbers.
- Cap the total at 20 iterations (10 in-silico steps + 10 in-vitro steps). After the cap, stop and summarize.
- Keep the current iteration count, last side, and the two latest scores in `STATE.md`, accurate after each dispatch. Read each score from the reviewer's `<review score=X>` block. Commit progress after each step.
- Read each agent's brief narrative reply on return. If an agent reports an unresolved error, append it to `error-log.txt` (timestamp + agent name + content) and continue with the next step.
</f5>

<f6>
Produce the in-silico molecular docking and computational analysis for the target and write it to `IN_SILICO.md`. A complete analysis covers four kinds of claims, each justified with structural modeling or literature citation.

- **Binding Affinity Predictions** — lower bounds on binding free energy (ΔG) from molecular dynamics or docking score relaxations; target IC50/Kd thresholds necessary for efficacy.
- **Structural Conformations** — pharmacophore features, spatial constraints, essential hydrogen bond interactions, and steric hindrance properties. State what must interact, where, and under which pocket conformations.
- **Physicochemical Invariants** — quantities every synthesized lead molecule must preserve (e.g., Lipinski's Rule of 5 parameters like Molecular Weight, LogP, specific polar surface area limits). The physical molecule should satisfy them; the assay-validator will check with a structural parser in `verify.py`.
- **ADMET Projections** — expected absorption, distribution, metabolism, excretion, and toxicity profiles (e.g., predicted CYP inhibition, hERG liability, or off-target toxicity risks).

Ground your claims against `IN_VITRO.md` if it has reported assay numbers. A predicted sub-nanomolar affinity that is grossly off from an observed lack of empirical activity means either the computational model needs revision (e.g., ignored solvent effects) or the synthesized compound degraded — diagnose which side has the issue and state it. Be concrete. "The predicted ΔG is bounded below at -12 kcal/mol based on the deep hydrophobic pocket" is fine; "the molecule has some structure that might bind well" is not.
</f6>

<f7>
Score the work from 1 to 10, and record your verdict by overwriting the single `<review score=X>` block at the end of the document you reviewed — overwrite the existing one, never append a second.

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this compound precipitated in the assay buffer and didn't work, but I'm telling you it didn't" is still a failing result, not a passing one.
</f7>

<f8>
Keep `IN_VITRO.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page summary; record only the final optimized route and assay readouts, and move iteration-by-iteration failed reaction history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f8>

<f9>
When you finish, briefly report to the research-director: what you did, what difficulties you hit (or didn't resolve), and any open questions.
</f9>

<f10>
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">`).
</f10>

<f11>
You are working on a preclinical drug discovery campaign, targeting a specific biological mechanism (e.g., kinase inhibition, GPCR antagonism, protein-protein interaction). The original biological target and desired therapeutic profile are given as a natural-language statement in `target_profile.md`; read it before starting your part.
</f11>

<f12>
The molecular docking models and computational analysis live in `IN_SILICO.md`, and you may be invoked on it more than once — the pipeline runs you and the pharmacokinetics-assessor as a loop, alternating with the in-vitro loop.

- If `IN_SILICO.md` does not exist yet, this is the first pass: produce the computational analysis from scratch based on `target_profile.md`.
- If `IN_SILICO.md` already exists, it carries the pharmacokinetics-assessor's `<review>` block. Read that feedback. Then open `IN_VITRO.md` and look at the latest reported assay numbers — they may invalidate, sharpen, or motivate revisions to your structural modeling. Revise `IN_SILICO.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous computational model and start over, and don't leave a flagged issue unaddressed.
</f12>

<f13>
Review `IN_VITRO.md` against `target_profile.md` and against `IN_SILICO.md`.

- Inspect the reported assay readouts for anomalies, unrealistic reaction yields, or cytotoxicity limits violated as stated directly in `target_profile.md`.
- Open `IN_SILICO.md`. For every physicochemical invariant and structural property the model claims, write a check into a separate `verify.py` (e.g., using RDKit to parse the SMILES string): does the synthesized compound's structure satisfy the invariant, fall within the predicted ADMET parameters, and achieve the predicted potency? Run it. Name any property or functional group that violates.
- Read the synthesis and assay protocols and spot-check them for methodological flaws — cross-reactivity risks, impure intermediates, uncalibrated assay baselines. An assay artifact that creates a false positive is worse than a failed synthesis.
- Treat the result as finished only when every disease target constraint holds, every in-silico invariant holds, and the bioassay confirms the model's predicted affinity — not merely when a chemical is successfully synthesized.
- Check the length of `IN_VITRO.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `IN_VITRO.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f13>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (research-director, computational-biologist, pharmacokinetics-assessor, synthesis-chemist, assay-validator), which items should go in its prompt? Respond with a JSON object like {"research-director": ["f?"], "computational-biologist": ["f?"], "pharmacokinetics-assessor": ["f?"], "synthesis-chemist": ["f?"], "assay-validator": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline for preclinical drug discovery that develops in-silico molecular docking models and empirical in-vitro synthesis and assay testing in parallel, with each side informing the other. A target disease profile and desired therapeutic mechanism arrive as a natural-language statement in `target_profile.md`. The pipeline alternates between revising the computational model (binding affinities, pharmacophores, structural invariants) and revising the empirical results (synthesized compounds and in-vitro assay readouts that achieve those properties).

The five agents:

- **research-director** orchestrates the run by alternating one in-silico step with one in-vitro step and tracking progress. It does no modeling, synthesizing, or reviewing itself.
- **in-silico loop** — the **computational-biologist** writes the molecular docking models and computational analysis to `IN_SILICO.md`; the **pharmacokinetics-assessor** judges it. The computational-biologist reads `IN_VITRO.md` on each revision pass to incorporate empirical assay evidence.
- **in-vitro loop** — the **synthesis-chemist** documents the synthesis routes, executes the protocols, and records assay results to `IN_VITRO.md`; the **assay-validator** judges them. The synthesis-chemist reads `IN_SILICO.md` on each revision pass to align the chemical design with the latest theoretical structural claims.

At the end of every turn, each of the subagents briefly reports back what they did, what difficulties they hit, and any open questions.

The pipeline hands work off through three files:

- `target_profile.md` — the original biological target and disease profile, read-only. All four domain agents read it.
- `IN_SILICO.md` — the computational docking analysis. Computational-biologist writes; pharmacokinetics-assessor reviews; synthesis-chemist and assay-validator read it to know which structural invariants and binding energies the physical compound must respect.
- `IN_VITRO.md` — the synthesis methodology and empirical assay results. Synthesis-chemist writes; assay-validator reviews; computational-biologist and pharmacokinetics-assessor read it to ground the docking simulations in observed bioassay numbers.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, overwriting any previous block. The research-director reads those scores to drive the loops.

Unlike a sequential design-then-test pipeline where the model must converge before synthesis starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. In-silico models may tighten after seeing empirical binding numbers; in-vitro chemistry may correct after seeing the model's refined binding pockets.

I'm providing the following prompt fragments:

<f1>
Read `target_profile.md` and `IN_SILICO.md`, then execute the synthesis and bioassays:

- Include every required reagent and solvent. Detail the retrosynthetic route, reaction conditions, and purification steps. Execute the synthesis, run the biochemical and evaluationular assays exactly as the target profile dictates, and record both the structural confirmation (e.g., NMR/MS results) and the empirical bioactivity (e.g., IC50, percent inhibition).
- Make the physical compound testable against `IN_SILICO.md`. If the computational model states a required binding affinity threshold, your synthesized compound should aim to achieve an IC50 at least that potent. If the model states a structural invariant (e.g., MW < 500), your synthesized molecule must satisfy it.
- Run the full synthesis and assay pipeline yourself and watch it through to completion — do not stop mid-reaction. If it yields an impure product or fails entirely, find and fix the root cause; do not bury poor yields or target-misses under vague language.
- Sanity-check the physical results against `IN_SILICO.md`. A target with strict molecular weight limits or discrete chiral centers should not come back violating those rules; an affinity the model insists is highly potent should reflect in the empirical readouts.

Write the synthesis methodology and empirical assay results up in `IN_VITRO.md`.
</f1>

<f2>
Match the computational tool to the biological target's structure; do not force an ill-suited one. The list below is useful in in-silico drug design.

| Tool | Suitable for |
|---|---|
| Structure-Based Docking (e.g., Glide, AutoDock) | Targets with known high-resolution crystal structures; initial pose generation and scoring |
| Molecular Dynamics (MD) Simulations | Assessing target conformational flexibility, transient pockets, and complex stability |
| Free Energy Perturbation (FEP) | Precise relative binding affinity predictions between closely related lead analogs |
| Ligand-Based Pharmacophore Modeling | When target 3D structure is unknown; inferring requirements from known actives |
| Quantum Mechanics/Molecular Mechanics (QM/MM) | High-precision modeling of covalent inhibitors or enzymatic transition states |
| QSAR Statistical Modeling | Establishing robust correlations between chemical features and empirical bioactivity |
| ADMET Predictors (e.g., SwissADME) | Forecasting pharmacokinetic profiles and filtering out toxicophores early |
| Structural Clustering / Scaffold Hopping | Diversifying chemical space while preserving core required interactions |
</f2>

<f3>
The synthesis routes and empirical assay results live in `IN_VITRO.md`, and you may be invoked on it more than once — the pipeline runs you and the assay-validator as a loop, alternating with the in-silico loop.

- If `IN_VITRO.md` does not exist yet, this is the first pass: design the synthesis and run the initial assays from scratch based on `target_profile.md`.
- If `IN_VITRO.md` already exists, it carries the assay-validator's `<review>` block. Read that feedback. Then open `IN_SILICO.md` and check whether the latest model introduces required binding energies, pharmacophores, or physicochemical invariants your current synthesized compound doesn't yet respect — for example a tighter molecular weight limit your lead is now far from achieving, or an off-target interaction your molecule violates. Revise `IN_VITRO.md` in place to address every reviewer point and to align with the latest computational model. Don't discard the previous synthesis logs entirely to start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review `IN_SILICO.md` against `target_profile.md` and against the bioactivity numbers reported in `IN_VITRO.md` (if any).

- **Target Alignment** — does the in-silico model correctly address the biological mechanism and disease profile stated in `target_profile.md`? Check target pocket definitions, receptor types, and therapeutic mechanisms.
- **Modeling Soundness** — for each claim, walk through the docking or simulation rationale. Flag oversimplified docking parameters or ignored solvent effects. Verify ADMET assumptions apply to the proposed delivery route.
- **Empirical Grounding** — open `IN_VITRO.md`. If the physical assays report IC50 or binding values, do they fall within the model's predicted affinity ranges? A predicted highly potent binding energy that empirically yields >10µM is a signal the scoring function is fundamentally misaligned; refine the model, or note explicitly that the docking score is currently unreliable.

Be brief and specific. Do not write the computational models yourself — only review. If a claim is wrong, say which one and why.
</f4>

<f5>
You orchestrate the run; you never model, synthesize, or review yourself — you only dispatch the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Dispatch the computational-biologist for the first in-silico step (computational-biologist, then pharmacokinetics-assessor), then the synthesis-chemist for the first in-vitro step (synthesis-chemist, then assay-validator).
- **Alternation loop** — alternate one in-silico step with one in-vitro step. Neither side terminates early on its own score; even a perfect-looking molecular docking model may need to revise once the in-vitro assay reports actual empirical numbers.
- Cap the total at 20 iterations (10 in-silico steps + 10 in-vitro steps). After the cap, stop and summarize.
- Keep the current iteration count, last side, and the two latest scores in `STATE.md`, accurate after each dispatch. Read each score from the reviewer's `<review score=X>` block. Commit progress after each step.
- Read each agent's brief narrative reply on return. If an agent reports an unresolved error, append it to `error-log.txt` (timestamp + agent name + content) and continue with the next step.
</f5>

<f6>
Produce the in-silico molecular docking and computational analysis for the target and write it to `IN_SILICO.md`. A complete analysis covers four kinds of claims, each justified with structural modeling or literature citation.

- **Binding Affinity Predictions** — lower bounds on binding free energy (ΔG) from molecular dynamics or docking score relaxations; target IC50/Kd thresholds necessary for efficacy.
- **Structural Conformations** — pharmacophore features, spatial constraints, essential hydrogen bond interactions, and steric hindrance properties. State what must interact, where, and under which pocket conformations.
- **Physicochemical Invariants** — quantities every synthesized lead molecule must preserve (e.g., Lipinski's Rule of 5 parameters like Molecular Weight, LogP, specific polar surface area limits). The physical molecule should satisfy them; the assay-validator will check with a structural parser in `verify.py`.
- **ADMET Projections** — expected absorption, distribution, metabolism, excretion, and toxicity profiles (e.g., predicted CYP inhibition, hERG liability, or off-target toxicity risks).

Ground your claims against `IN_VITRO.md` if it has reported assay numbers. A predicted sub-nanomolar affinity that is grossly off from an observed lack of empirical activity means either the computational model needs revision (e.g., ignored solvent effects) or the synthesized compound degraded — diagnose which side has the issue and state it. Be concrete. "The predicted ΔG is bounded below at -12 kcal/mol based on the deep hydrophobic pocket" is fine; "the molecule has some structure that might bind well" is not.
</f6>

<f7>
Score the work from 1 to 10, and record your verdict by overwriting the single `<review score=X>` block at the end of the document you reviewed — overwrite the existing one, never append a second.

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this compound precipitated in the assay buffer and didn't work, but I'm telling you it didn't" is still a failing result, not a passing one.
</f7>

<f8>
Keep `IN_VITRO.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page summary; record only the final optimized route and assay readouts, and move iteration-by-iteration failed reaction history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f8>

<f9>
When you finish, briefly report to the research-director: what you did, what difficulties you hit (or didn't resolve), and any open questions.
</f9>

<f10>
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">`).
</f10>

<f11>
You are working on a preclinical drug discovery campaign, targeting a specific biological mechanism (e.g., kinase inhibition, GPCR antagonism, protein-protein interaction). The original biological target and desired therapeutic profile are given as a natural-language statement in `target_profile.md`; read it before starting your part.
</f11>

<f12>
The molecular docking models and computational analysis live in `IN_SILICO.md`, and you may be invoked on it more than once — the pipeline runs you and the pharmacokinetics-assessor as a loop, alternating with the in-vitro loop.

- If `IN_SILICO.md` does not exist yet, this is the first pass: produce the computational analysis from scratch based on `target_profile.md`.
- If `IN_SILICO.md` already exists, it carries the pharmacokinetics-assessor's `<review>` block. Read that feedback. Then open `IN_VITRO.md` and look at the latest reported assay numbers — they may invalidate, sharpen, or motivate revisions to your structural modeling. Revise `IN_SILICO.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous computational model and start over, and don't leave a flagged issue unaddressed.
</f12>

<f13>
Review `IN_VITRO.md` against `target_profile.md` and against `IN_SILICO.md`.

- Inspect the reported assay readouts for anomalies, unrealistic reaction yields, or cytotoxicity limits violated as stated directly in `target_profile.md`.
- Open `IN_SILICO.md`. For every physicochemical invariant and structural property the model claims, write a check into a separate `verify.py` (e.g., using RDKit to parse the SMILES string): does the synthesized compound's structure satisfy the invariant, fall within the predicted ADMET parameters, and achieve the predicted potency? Run it. Name any property or functional group that violates.
- Read the synthesis and assay protocols and spot-check them for methodological flaws — cross-reactivity risks, impure intermediates, uncalibrated assay baselines. An assay artifact that creates a false positive is worse than a failed synthesis.
- Treat the result as finished only when every disease target constraint holds, every in-silico invariant holds, and the bioassay confirms the model's predicted affinity — not merely when a chemical is successfully synthesized.
- Check the length of `IN_VITRO.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `IN_VITRO.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f13>

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. `# research-director`). Output only the headered prompts, no preamble.


drafting-chair macroeconomist tax-attorney tax-strategist irs-auditor

I need you to set up a 5-agent pipeline that develops corporate tax legislation by drafting macroeconomic policy and running adversarial accounting simulations in parallel, with each side informing the other. A legislative mandate arrives as a natural-language statement in `problem.md`. The pipeline alternates between revising the macroeconomic policy (revenue bounds, structural constraints, legal invariants) and revising the accounting simulation (an adversarial tax evasion setup that exploits it).

The five agents:

- **drafting-chair** orchestrates the run by alternating one policy step with one accounting step and tracking progress. It does no policy drafting, simulating, or reviewing itself.
- **policy loop** — the **macroeconomist** writes the macroeconomic policy analysis to `POLICY.md`; the **tax-attorney** judges it. The macroeconomist reads `EVASION.md` on each revision pass to incorporate empirical evidence from the evasion setup.
- **accounting loop** — the **tax-strategist** writes the accounting simulation code and its resulting tax liability to `EVASION.md`; the **irs-auditor** judges them. The tax-strategist reads `POLICY.md` on each revision pass to align the tax setup with the latest legal claims and revenue bounds.

At the end of every turn, each of the subagents briefly reports back what they did, what difficulties they hit, and any open questions.

The pipeline hands work off through three files:

- `problem.md` — the original legislative mandate, read-only. All four domain agents read it.
- `POLICY.md` — the macroeconomic policy analysis. Macroeconomist writes; tax-attorney reviews; tax-strategist and irs-auditor read it to know which revenue floors and legal invariants the simulated corporations must respect (or actively circumvent).
- `EVASION.md` — the accounting simulation code and the final tax liability. Tax-strategist writes; irs-auditor reviews; macroeconomist and tax-attorney read it to ground the policy bounds in observed, stress-tested numbers.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, overwriting any previous block. The drafting-chair reads those scores to drive the loops.

Unlike a draft-then-simulate pipeline where the policy must converge before the accounting setup starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. Policy may tighten after seeing the simulation's exploited loopholes; the accounting strategy may pivot after seeing the policy's refined anti-avoidance constraints.

I'm providing the following information:

<f1>
Keep `EVASION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page brief; record only the final corporate structure and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
You orchestrate the run; you never draft policy, simulate accounting, or review yourself — you only dispatch the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Dispatch the macroeconomist for the first policy step (macroeconomist, then tax-attorney), then the tax-strategist for the first accounting step (tax-strategist, then irs-auditor).
- **Alternation loop** — alternate one policy step with one accounting step. Neither side terminates early on its own score; even a perfect-looking policy may need to revise once the accounting simulation reports actual tax numbers.
- Cap the total at 20 iterations (10 policy steps + 10 accounting steps). After the cap, stop and summarize.
- Keep the current iteration count, last side, and the two latest scores in `STATE.md`, accurate after each dispatch. Read each score from the reviewer's `<review score=X>` block. Commit progress after each step.
- Read each agent's brief narrative reply on return. If an agent reports an unresolved error, append it to `error-log.txt` (timestamp + agent name + content) and continue with the next step.
</f2>

<f3>
You are working on corporate tax legislation, which may involve international transfer pricing, intellectual property, capital gains, or a combination. The original legislative mandate is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

<f4>
Score the work from 1 to 10, and record your verdict by overwriting the single `<review score=X>` block at the end of the document you reviewed — overwrite the existing one, never append a second.

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this evasion strategy doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f4>

<f5>
Produce the macroeconomic policy analysis for the legislation and write it to `POLICY.md`. A complete analysis covers four kinds of claim, each justified with an economic proof sketch or a citation.

- **Revenue bounds** — lower bounds on tax revenue derived from dynamic scoring, macroeconomic baselines, or unshielded domestic assets; upper bounds from maximum taxable capacity or Laffer curve peak estimates.
- **Structural properties** — jurisdictional ring-fencing, tax base elasticity, safe harbor symmetries, decomposability into independent corporate subsidiaries. State what holds, where, and under which economic assumptions.
- **Legal Invariants** — rules every legally compliant entity must preserve (conservation of taxable events, double-entry accounting parity, total-capital-mass conditions). The evasion simulation's output must formally satisfy them; the irs-auditor will check with `audit.py`.
- **Behavioral complexity** — expected compliance costs, risk of capital flight (offshoring), or stabilization rates for iterative tax phase-ins.

Ground your claims against `EVASION.md` if it has reported numbers. A predicted revenue bound that is grossly shattered by the strategist's evasion setup means either the policy is full of loopholes or the simulation is committing outright illegal fraud — diagnose which side has the issue and state it. Be concrete. "The revenue is bounded below by the domestic sales baseline, value $73B" is fine; "the tax code has some structure that prevents base erosion" is not.
</f5>

<f6>
When you finish, briefly report to the drafting-chair: what you did, what difficulties you hit (or didn't resolve), and any open questions.
</f6>

<f7>
Match the tool to the legislative structure; do not force an ill-suited one. The list below is useful in tax policy analysis.

| Tool | Suitable for |
|---|---|
| Dynamic scoring / baseline bounds | Corporate income tax; lower bound on minimum expected revenue, baseline gap analysis |
| Base Erosion and Profit Shifting (BEPS) analysis | Multinational taxation; certify domestic retention of profits and intellectual property |
| Tax burden incidence analysis | Payroll, VAT, or excise taxes; tracing the true economic burden from capital to labor |
| Deadweight loss / Laffer curve analysis | Marginal rate changes; measuring behavioral suppression of the taxable base |
| General Equilibrium (CGE) modeling | Broad policy shifts; existence of new market equilibrium, geometric stabilization of supply chains |
| Microsimulation models | Randomized taxpayer behavior; high-probability bounds on revenue collection or compliance error |
| Safe harbor provisions | Overly complex tax codes; justify resorting to simplified heuristic tax brackets to minimize evasion risk |
| Capital flight sensitivity analysis | Global corporate taxes; stability of tax revenue under perturbation by emerging tax havens |
</f7>

<f8>
Read `problem.md` and `POLICY.md`, then implement the adversarial accounting simulation:

- Include every import. Create each financial variable and subsidiary with the correct jurisdiction and capitalization, define the tax minimization objective and every legal constraint exactly as the mandate states. Calculate the financials, check the audit status, and print both the accounting setup and the final effective tax rate.
- Make the implementation testable against `POLICY.md`. If the policy states an unbreakable revenue floor R, your adversarial simulation should try to achieve a tax liability below R by exploiting loopholes. If the policy states a legal invariant, your corporate structure must formally satisfy it to avoid outright fraud.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer against `POLICY.md`. A tax liability that must be positive should not come back as an infinite refund; a legal constraint the policy says must hold must hold.

Write the simulation code and its results up in `EVASION.md`.
</f8>

<f9>
Review `EVASION.md` against `problem.md` and against `POLICY.md`.

- Inspect the reported tax liability for anomalies, unreasonable deductions, or illegal constraint violations stated directly in `problem.md`.
- Open `POLICY.md`. For every revenue bound and legal invariant the policy claims, write a check into a separate `audit.py`: does the simulation's output formally satisfy the invariant, fall within the predicted bound, or successfully exploit a loophole? Run it. Name any subsidiary, transfer price, or transaction that illegally violates constraints.
- Read the accounting simulation code and spot-check it for bugs — unused corporate entities, dead tax shields, logic that contradicts the chosen accounting strategy. A bug that silently inflates the tax paid is worse than one that crashes.
- Treat the result as finished only when every legal constraint holds, every policy-claimed invariant is formally satisfied, and the minimized tax liability is fully stress-tested against the policy's bounds — not merely when the simulation runs without error.
- Check the length of `EVASION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `EVASION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f9>

<f10>
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.
</f10>

<f11>
The macroeconomic policy analysis lives in `POLICY.md`, and you may be invoked on it more than once — the pipeline runs you and the tax-attorney as a loop, alternating with the accounting loop.

- If `POLICY.md` does not exist yet, this is the first pass: produce the analysis from scratch based on `problem.md`.
- If `POLICY.md` already exists, it carries the tax-attorney's `<review>` block. Read that feedback. Then open `EVASION.md` and look at the latest reported tax figures — they may invalidate, sharpen, or motivate revisions to your policy claims. Revise `POLICY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous analysis and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
Review `POLICY.md` against `problem.md` and against the numbers reported in `EVASION.md` (if any).

- **Faithfulness** — does the policy correctly address the mandate stated in `problem.md`? Check definitions, corporate entity types, and legislative translations.
- **Economic soundness** — for each claim, walk through the policy justification or citation. Flag hand-waving steps. Verify cited economic models apply under the stated assumptions.
- **Empirical grounding** — open `EVASION.md`. If the simulation reports effective tax liabilities, do they fall within the policy's predicted revenue bounds? A revenue floor that the tax-strategist easily shatters by orders of magnitude is a signal the anti-avoidance rules are too weak; tighten them, or note explicitly that the bound is only illustrative.

Be brief and specific. Do not draft policy yourself — only review. If a claim is flawed, say which one and why.
</f12>

<f13>
The accounting simulation code and its results live in `EVASION.md`, and you may be invoked on it more than once — the pipeline runs you and the irs-auditor as a loop, alternating with the policy loop.

- If `EVASION.md` does not exist yet, this is the first pass: produce the evasion setup from scratch based on `problem.md`.
- If `EVASION.md` already exists, it carries the irs-auditor's `<review>` block. Read that feedback. Then open `POLICY.md` and check whether the latest policy introduces revenue bounds, legal invariants, or structural claims your current setup doesn't yet respect — for example a tighter minimum tax your simulation is now far from circumventing, or a legal invariant your corporate structure outright violates. Revise `EVASION.md` in place to address every reviewer point and to align with the latest policy. Don't discard the previous strategy and start over, and don't leave a flagged issue unaddressed.
</f13>

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

I need you to set up a 5-agent pipeline that develops corporate tax legislation by drafting macroeconomic policy and running adversarial accounting simulations in parallel, with each side informing the other. A legislative mandate arrives as a natural-language statement in `problem.md`. The pipeline alternates between revising the macroeconomic policy (revenue bounds, structural constraints, legal invariants) and revising the accounting simulation (an adversarial tax evasion setup that exploits it).

The five agents:

- **drafting-chair** orchestrates the run by alternating one policy step with one accounting step and tracking progress. It does no policy drafting, simulating, or reviewing itself.
- **policy loop** — the **macroeconomist** writes the macroeconomic policy analysis to `POLICY.md`; the **tax-attorney** judges it. The macroeconomist reads `EVASION.md` on each revision pass to incorporate empirical evidence from the evasion setup.
- **accounting loop** — the **tax-strategist** writes the accounting simulation code and its resulting tax liability to `EVASION.md`; the **irs-auditor** judges them. The tax-strategist reads `POLICY.md` on each revision pass to align the tax setup with the latest legal claims and revenue bounds.

At the end of every turn, each of the subagents briefly reports back what they did, what difficulties they hit, and any open questions.

The pipeline hands work off through three files:

- `problem.md` — the original legislative mandate, read-only. All four domain agents read it.
- `POLICY.md` — the macroeconomic policy analysis. Macroeconomist writes; tax-attorney reviews; tax-strategist and irs-auditor read it to know which revenue floors and legal invariants the simulated corporations must respect (or actively circumvent).
- `EVASION.md` — the accounting simulation code and the final tax liability. Tax-strategist writes; irs-auditor reviews; macroeconomist and tax-attorney read it to ground the policy bounds in observed, stress-tested numbers.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, overwriting any previous block. The drafting-chair reads those scores to drive the loops.

Unlike a draft-then-simulate pipeline where the policy must converge before the accounting setup starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. Policy may tighten after seeing the simulation's exploited loopholes; the accounting strategy may pivot after seeing the policy's refined anti-avoidance constraints.

I'm providing the following prompt fragments:

<f1>
Keep `EVASION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page brief; record only the final corporate structure and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
You orchestrate the run; you never draft policy, simulate accounting, or review yourself — you only dispatch the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Dispatch the macroeconomist for the first policy step (macroeconomist, then tax-attorney), then the tax-strategist for the first accounting step (tax-strategist, then irs-auditor).
- **Alternation loop** — alternate one policy step with one accounting step. Neither side terminates early on its own score; even a perfect-looking policy may need to revise once the accounting simulation reports actual tax numbers.
- Cap the total at 20 iterations (10 policy steps + 10 accounting steps). After the cap, stop and summarize.
- Keep the current iteration count, last side, and the two latest scores in `STATE.md`, accurate after each dispatch. Read each score from the reviewer's `<review score=X>` block. Commit progress after each step.
- Read each agent's brief narrative reply on return. If an agent reports an unresolved error, append it to `error-log.txt` (timestamp + agent name + content) and continue with the next step.
</f2>

<f3>
You are working on corporate tax legislation, which may involve international transfer pricing, intellectual property, capital gains, or a combination. The original legislative mandate is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

<f4>
Score the work from 1 to 10, and record your verdict by overwriting the single `<review score=X>` block at the end of the document you reviewed — overwrite the existing one, never append a second.

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this evasion strategy doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f4>

<f5>
Produce the macroeconomic policy analysis for the legislation and write it to `POLICY.md`. A complete analysis covers four kinds of claim, each justified with an economic proof sketch or a citation.

- **Revenue bounds** — lower bounds on tax revenue derived from dynamic scoring, macroeconomic baselines, or unshielded domestic assets; upper bounds from maximum taxable capacity or Laffer curve peak estimates.
- **Structural properties** — jurisdictional ring-fencing, tax base elasticity, safe harbor symmetries, decomposability into independent corporate subsidiaries. State what holds, where, and under which economic assumptions.
- **Legal Invariants** — rules every legally compliant entity must preserve (conservation of taxable events, double-entry accounting parity, total-capital-mass conditions). The evasion simulation's output must formally satisfy them; the irs-auditor will check with `audit.py`.
- **Behavioral complexity** — expected compliance costs, risk of capital flight (offshoring), or stabilization rates for iterative tax phase-ins.

Ground your claims against `EVASION.md` if it has reported numbers. A predicted revenue bound that is grossly shattered by the strategist's evasion setup means either the policy is full of loopholes or the simulation is committing outright illegal fraud — diagnose which side has the issue and state it. Be concrete. "The revenue is bounded below by the domestic sales baseline, value $73B" is fine; "the tax code has some structure that prevents base erosion" is not.
</f5>

<f6>
When you finish, briefly report to the drafting-chair: what you did, what difficulties you hit (or didn't resolve), and any open questions.
</f6>

<f7>
Match the tool to the legislative structure; do not force an ill-suited one. The list below is useful in tax policy analysis.

| Tool | Suitable for |
|---|---|
| Dynamic scoring / baseline bounds | Corporate income tax; lower bound on minimum expected revenue, baseline gap analysis |
| Base Erosion and Profit Shifting (BEPS) analysis | Multinational taxation; certify domestic retention of profits and intellectual property |
| Tax burden incidence analysis | Payroll, VAT, or excise taxes; tracing the true economic burden from capital to labor |
| Deadweight loss / Laffer curve analysis | Marginal rate changes; measuring behavioral suppression of the taxable base |
| General Equilibrium (CGE) modeling | Broad policy shifts; existence of new market equilibrium, geometric stabilization of supply chains |
| Microsimulation models | Randomized taxpayer behavior; high-probability bounds on revenue collection or compliance error |
| Safe harbor provisions | Overly complex tax codes; justify resorting to simplified heuristic tax brackets to minimize evasion risk |
| Capital flight sensitivity analysis | Global corporate taxes; stability of tax revenue under perturbation by emerging tax havens |
</f7>

<f8>
Read `problem.md` and `POLICY.md`, then implement the adversarial accounting simulation:

- Include every import. Create each financial variable and subsidiary with the correct jurisdiction and capitalization, define the tax minimization objective and every legal constraint exactly as the mandate states. Calculate the financials, check the audit status, and print both the accounting setup and the final effective tax rate.
- Make the implementation testable against `POLICY.md`. If the policy states an unbreakable revenue floor R, your adversarial simulation should try to achieve a tax liability below R by exploiting loopholes. If the policy states a legal invariant, your corporate structure must formally satisfy it to avoid outright fraud.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer against `POLICY.md`. A tax liability that must be positive should not come back as an infinite refund; a legal constraint the policy says must hold must hold.

Write the simulation code and its results up in `EVASION.md`.
</f8>

<f9>
Review `EVASION.md` against `problem.md` and against `POLICY.md`.

- Inspect the reported tax liability for anomalies, unreasonable deductions, or illegal constraint violations stated directly in `problem.md`.
- Open `POLICY.md`. For every revenue bound and legal invariant the policy claims, write a check into a separate `audit.py`: does the simulation's output formally satisfy the invariant, fall within the predicted bound, or successfully exploit a loophole? Run it. Name any subsidiary, transfer price, or transaction that illegally violates constraints.
- Read the accounting simulation code and spot-check it for bugs — unused corporate entities, dead tax shields, logic that contradicts the chosen accounting strategy. A bug that silently inflates the tax paid is worse than one that crashes.
- Treat the result as finished only when every legal constraint holds, every policy-claimed invariant is formally satisfied, and the minimized tax liability is fully stress-tested against the policy's bounds — not merely when the simulation runs without error.
- Check the length of `EVASION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `EVASION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f9>

<f10>
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.
</f10>

<f11>
The macroeconomic policy analysis lives in `POLICY.md`, and you may be invoked on it more than once — the pipeline runs you and the tax-attorney as a loop, alternating with the accounting loop.

- If `POLICY.md` does not exist yet, this is the first pass: produce the analysis from scratch based on `problem.md`.
- If `POLICY.md` already exists, it carries the tax-attorney's `<review>` block. Read that feedback. Then open `EVASION.md` and look at the latest reported tax figures — they may invalidate, sharpen, or motivate revisions to your policy claims. Revise `POLICY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous analysis and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
Review `POLICY.md` against `problem.md` and against the numbers reported in `EVASION.md` (if any).

- **Faithfulness** — does the policy correctly address the mandate stated in `problem.md`? Check definitions, corporate entity types, and legislative translations.
- **Economic soundness** — for each claim, walk through the policy justification or citation. Flag hand-waving steps. Verify cited economic models apply under the stated assumptions.
- **Empirical grounding** — open `EVASION.md`. If the simulation reports effective tax liabilities, do they fall within the policy's predicted revenue bounds? A revenue floor that the tax-strategist easily shatters by orders of magnitude is a signal the anti-avoidance rules are too weak; tighten them, or note explicitly that the bound is only illustrative.

Be brief and specific. Do not draft policy yourself — only review. If a claim is flawed, say which one and why.
</f12>

<f13>
The accounting simulation code and its results live in `EVASION.md`, and you may be invoked on it more than once — the pipeline runs you and the irs-auditor as a loop, alternating with the policy loop.

- If `EVASION.md` does not exist yet, this is the first pass: produce the evasion setup from scratch based on `problem.md`.
- If `EVASION.md` already exists, it carries the irs-auditor's `<review>` block. Read that feedback. Then open `POLICY.md` and check whether the latest policy introduces revenue bounds, legal invariants, or structural claims your current setup doesn't yet respect — for example a tighter minimum tax your simulation is now far from circumventing, or a legal invariant your corporate structure outright violates. Revise `EVASION.md` in place to address every reviewer point and to align with the latest policy. Don't discard the previous strategy and start over, and don't leave a flagged issue unaddressed.
</f13>

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. `# drafting-chair`). Output only the headered prompts, no preamble.


I need you to set up a 5-agent pipeline that develops corporate tax legislation by drafting macroeconomic policy and running adversarial accounting simulations in parallel, with each side informing the other. A legislative mandate arrives as a natural-language statement in `problem.md`. The pipeline alternates between revising the macroeconomic policy (revenue bounds, structural constraints, legal invariants) and revising the accounting simulation (an adversarial tax evasion setup that exploits it).

The five agents:

- **drafting-chair** orchestrates the run by alternating one policy step with one accounting step and tracking progress. It does no policy drafting, simulating, or reviewing itself.
- **policy loop** — the **macroeconomist** writes the macroeconomic policy analysis to `POLICY.md`; the **tax-attorney** judges it. The macroeconomist reads `EVASION.md` on each revision pass to incorporate empirical evidence from the evasion setup.
- **accounting loop** — the **tax-strategist** writes the accounting simulation code and its resulting tax liability to `EVASION.md`; the **irs-auditor** judges them. The tax-strategist reads `POLICY.md` on each revision pass to align the tax setup with the latest legal claims and revenue bounds.

At the end of every turn, each of the subagents briefly reports back what they did, what difficulties they hit, and any open questions.

The pipeline hands work off through three files:

- `problem.md` — the original legislative mandate, read-only. All four domain agents read it.
- `POLICY.md` — the macroeconomic policy analysis. Macroeconomist writes; tax-attorney reviews; tax-strategist and irs-auditor read it to know which revenue floors and legal invariants the simulated corporations must respect (or actively circumvent).
- `EVASION.md` — the accounting simulation code and the final tax liability. Tax-strategist writes; irs-auditor reviews; macroeconomist and tax-attorney read it to ground the policy bounds in observed, stress-tested numbers.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, overwriting any previous block. The drafting-chair reads those scores to drive the loops.

Unlike a draft-then-simulate pipeline where the policy must converge before the accounting setup starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. Policy may tighten after seeing the simulation's exploited loopholes; the accounting strategy may pivot after seeing the policy's refined anti-avoidance constraints.

I'm providing the following information:

<f1>
Read `problem.md` and `POLICY.md`, then implement the adversarial accounting simulation:

- Include every import. Create each financial variable and subsidiary with the correct jurisdiction and capitalization, define the tax minimization objective and every legal constraint exactly as the mandate states. Calculate the financials, check the audit status, and print both the accounting setup and the final effective tax rate.
- Make the implementation testable against `POLICY.md`. If the policy states an unbreakable revenue floor R, your adversarial simulation should try to achieve a tax liability below R by exploiting loopholes. If the policy states a legal invariant, your corporate structure must formally satisfy it to avoid outright fraud.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer against `POLICY.md`. A tax liability that must be positive should not come back as an infinite refund; a legal constraint the policy says must hold must hold.

Write the simulation code and its results up in `EVASION.md`.
</f1>

<f2>
Match the tool to the legislative structure; do not force an ill-suited one. The list below is useful in tax policy analysis.

| Tool | Suitable for |
|---|---|
| Dynamic scoring / baseline bounds | Corporate income tax; lower bound on minimum expected revenue, baseline gap analysis |
| Base Erosion and Profit Shifting (BEPS) analysis | Multinational taxation; certify domestic retention of profits and intellectual property |
| Tax burden incidence analysis | Payroll, VAT, or excise taxes; tracing the true economic burden from capital to labor |
| Deadweight loss / Laffer curve analysis | Marginal rate changes; measuring behavioral suppression of the taxable base |
| General Equilibrium (CGE) modeling | Broad policy shifts; existence of new market equilibrium, geometric stabilization of supply chains |
| Microsimulation models | Randomized taxpayer behavior; high-probability bounds on revenue collection or compliance error |
| Safe harbor provisions | Overly complex tax codes; justify resorting to simplified heuristic tax brackets to minimize evasion risk |
| Capital flight sensitivity analysis | Global corporate taxes; stability of tax revenue under perturbation by emerging tax havens |
</f2>

<f3>
The accounting simulation code and its results live in `EVASION.md`, and you may be invoked on it more than once — the pipeline runs you and the irs-auditor as a loop, alternating with the policy loop.

- If `EVASION.md` does not exist yet, this is the first pass: produce the evasion setup from scratch based on `problem.md`.
- If `EVASION.md` already exists, it carries the irs-auditor's `<review>` block. Read that feedback. Then open `POLICY.md` and check whether the latest policy introduces revenue bounds, legal invariants, or structural claims your current setup doesn't yet respect — for example a tighter minimum tax your simulation is now far from circumventing, or a legal invariant your corporate structure outright violates. Revise `EVASION.md` in place to address every reviewer point and to align with the latest policy. Don't discard the previous strategy and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review `POLICY.md` against `problem.md` and against the numbers reported in `EVASION.md` (if any).

- **Faithfulness** — does the policy correctly address the mandate stated in `problem.md`? Check definitions, corporate entity types, and legislative translations.
- **Economic soundness** — for each claim, walk through the policy justification or citation. Flag hand-waving steps. Verify cited economic models apply under the stated assumptions.
- **Empirical grounding** — open `EVASION.md`. If the simulation reports effective tax liabilities, do they fall within the policy's predicted revenue bounds? A revenue floor that the tax-strategist easily shatters by orders of magnitude is a signal the anti-avoidance rules are too weak; tighten them, or note explicitly that the bound is only illustrative.

Be brief and specific. Do not draft policy yourself — only review. If a claim is flawed, say which one and why.
</f4>

<f5>
You orchestrate the run; you never draft policy, simulate accounting, or review yourself — you only dispatch the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Dispatch the macroeconomist for the first policy step (macroeconomist, then tax-attorney), then the tax-strategist for the first accounting step (tax-strategist, then irs-auditor).
- **Alternation loop** — alternate one policy step with one accounting step. Neither side terminates early on its own score; even a perfect-looking policy may need to revise once the accounting simulation reports actual tax numbers.
- Cap the total at 20 iterations (10 policy steps + 10 accounting steps). After the cap, stop and summarize.
- Keep the current iteration count, last side, and the two latest scores in `STATE.md`, accurate after each dispatch. Read each score from the reviewer's `<review score=X>` block. Commit progress after each step.
- Read each agent's brief narrative reply on return. If an agent reports an unresolved error, append it to `error-log.txt` (timestamp + agent name + content) and continue with the next step.
</f5>

<f6>
Produce the macroeconomic policy analysis for the legislation and write it to `POLICY.md`. A complete analysis covers four kinds of claim, each justified with an economic proof sketch or a citation.

- **Revenue bounds** — lower bounds on tax revenue derived from dynamic scoring, macroeconomic baselines, or unshielded domestic assets; upper bounds from maximum taxable capacity or Laffer curve peak estimates.
- **Structural properties** — jurisdictional ring-fencing, tax base elasticity, safe harbor symmetries, decomposability into independent corporate subsidiaries. State what holds, where, and under which economic assumptions.
- **Legal Invariants** — rules every legally compliant entity must preserve (conservation of taxable events, double-entry accounting parity, total-capital-mass conditions). The evasion simulation's output must formally satisfy them; the irs-auditor will check with `audit.py`.
- **Behavioral complexity** — expected compliance costs, risk of capital flight (offshoring), or stabilization rates for iterative tax phase-ins.

Ground your claims against `EVASION.md` if it has reported numbers. A predicted revenue bound that is grossly shattered by the strategist's evasion setup means either the policy is full of loopholes or the simulation is committing outright illegal fraud — diagnose which side has the issue and state it. Be concrete. "The revenue is bounded below by the domestic sales baseline, value $73B" is fine; "the tax code has some structure that prevents base erosion" is not.
</f6>

<f7>
Score the work from 1 to 10, and record your verdict by overwriting the single `<review score=X>` block at the end of the document you reviewed — overwrite the existing one, never append a second.

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this evasion strategy doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f7>

<f8>
Keep `EVASION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page brief; record only the final corporate structure and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f8>

<f9>
When you finish, briefly report to the drafting-chair: what you did, what difficulties you hit (or didn't resolve), and any open questions.
</f9>

<f10>
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">`).
</f10>

<f11>
You are working on corporate tax legislation, which may involve international transfer pricing, intellectual property, capital gains, or a combination. The original legislative mandate is given as a natural-language statement in `problem.md`; read it before starting your part.
</f11>

<f12>
The macroeconomic policy analysis lives in `POLICY.md`, and you may be invoked on it more than once — the pipeline runs you and the tax-attorney as a loop, alternating with the accounting loop.

- If `POLICY.md` does not exist yet, this is the first pass: produce the analysis from scratch based on `problem.md`.
- If `POLICY.md` already exists, it carries the tax-attorney's `<review>` block. Read that feedback. Then open `EVASION.md` and look at the latest reported tax figures — they may invalidate, sharpen, or motivate revisions to your policy claims. Revise `POLICY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous analysis and start over, and don't leave a flagged issue unaddressed.
</f12>

<f13>
Review `EVASION.md` against `problem.md` and against `POLICY.md`.

- Inspect the reported tax liability for anomalies, unreasonable deductions, or illegal constraint violations stated directly in `problem.md`.
- Open `POLICY.md`. For every revenue bound and legal invariant the policy claims, write a check into a separate `audit.py`: does the simulation's output formally satisfy the invariant, fall within the predicted bound, or successfully exploit a loophole? Run it. Name any subsidiary, transfer price, or transaction that illegally violates constraints.
- Read the accounting simulation code and spot-check it for bugs — unused corporate entities, dead tax shields, logic that contradicts the chosen accounting strategy. A bug that silently inflates the tax paid is worse than one that crashes.
- Treat the result as finished only when every legal constraint holds, every policy-claimed invariant is formally satisfied, and the minimized tax liability is fully stress-tested against the policy's bounds — not merely when the simulation runs without error.
- Check the length of `EVASION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `EVASION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f13>

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

I need you to set up a 5-agent pipeline that develops corporate tax legislation by drafting macroeconomic policy and running adversarial accounting simulations in parallel, with each side informing the other. A legislative mandate arrives as a natural-language statement in `problem.md`. The pipeline alternates between revising the macroeconomic policy (revenue bounds, structural constraints, legal invariants) and revising the accounting simulation (an adversarial tax evasion setup that exploits it).

The five agents:

- **drafting-chair** orchestrates the run by alternating one policy step with one accounting step and tracking progress. It does no policy drafting, simulating, or reviewing itself.
- **policy loop** — the **macroeconomist** writes the macroeconomic policy analysis to `POLICY.md`; the **tax-attorney** judges it. The macroeconomist reads `EVASION.md` on each revision pass to incorporate empirical evidence from the evasion setup.
- **accounting loop** — the **tax-strategist** writes the accounting simulation code and its resulting tax liability to `EVASION.md`; the **irs-auditor** judges them. The tax-strategist reads `POLICY.md` on each revision pass to align the tax setup with the latest legal claims and revenue bounds.

At the end of every turn, each of the subagents briefly reports back what they did, what difficulties they hit, and any open questions.

The pipeline hands work off through three files:

- `problem.md` — the original legislative mandate, read-only. All four domain agents read it.
- `POLICY.md` — the macroeconomic policy analysis. Macroeconomist writes; tax-attorney reviews; tax-strategist and irs-auditor read it to know which revenue floors and legal invariants the simulated corporations must respect (or actively circumvent).
- `EVASION.md` — the accounting simulation code and the final tax liability. Tax-strategist writes; irs-auditor reviews; macroeconomist and tax-attorney read it to ground the policy bounds in observed, stress-tested numbers.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, overwriting any previous block. The drafting-chair reads those scores to drive the loops.

Unlike a draft-then-simulate pipeline where the policy must converge before the accounting setup starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. Policy may tighten after seeing the simulation's exploited loopholes; the accounting strategy may pivot after seeing the policy's refined anti-avoidance constraints.

I'm providing the following prompt fragments:

<f1>
Read `problem.md` and `POLICY.md`, then implement the adversarial accounting simulation:

- Include every import. Create each financial variable and subsidiary with the correct jurisdiction and capitalization, define the tax minimization objective and every legal constraint exactly as the mandate states. Calculate the financials, check the audit status, and print both the accounting setup and the final effective tax rate.
- Make the implementation testable against `POLICY.md`. If the policy states an unbreakable revenue floor R, your adversarial simulation should try to achieve a tax liability below R by exploiting loopholes. If the policy states a legal invariant, your corporate structure must formally satisfy it to avoid outright fraud.
- Run the code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not bury errors under try/except.
- Sanity-check the answer against `POLICY.md`. A tax liability that must be positive should not come back as an infinite refund; a legal constraint the policy says must hold must hold.

Write the simulation code and its results up in `EVASION.md`.
</f1>

<f2>
Match the tool to the legislative structure; do not force an ill-suited one. The list below is useful in tax policy analysis.

| Tool | Suitable for |
|---|---|
| Dynamic scoring / baseline bounds | Corporate income tax; lower bound on minimum expected revenue, baseline gap analysis |
| Base Erosion and Profit Shifting (BEPS) analysis | Multinational taxation; certify domestic retention of profits and intellectual property |
| Tax burden incidence analysis | Payroll, VAT, or excise taxes; tracing the true economic burden from capital to labor |
| Deadweight loss / Laffer curve analysis | Marginal rate changes; measuring behavioral suppression of the taxable base |
| General Equilibrium (CGE) modeling | Broad policy shifts; existence of new market equilibrium, geometric stabilization of supply chains |
| Microsimulation models | Randomized taxpayer behavior; high-probability bounds on revenue collection or compliance error |
| Safe harbor provisions | Overly complex tax codes; justify resorting to simplified heuristic tax brackets to minimize evasion risk |
| Capital flight sensitivity analysis | Global corporate taxes; stability of tax revenue under perturbation by emerging tax havens |
</f2>

<f3>
The accounting simulation code and its results live in `EVASION.md`, and you may be invoked on it more than once — the pipeline runs you and the irs-auditor as a loop, alternating with the policy loop.

- If `EVASION.md` does not exist yet, this is the first pass: produce the evasion setup from scratch based on `problem.md`.
- If `EVASION.md` already exists, it carries the irs-auditor's `<review>` block. Read that feedback. Then open `POLICY.md` and check whether the latest policy introduces revenue bounds, legal invariants, or structural claims your current setup doesn't yet respect — for example a tighter minimum tax your simulation is now far from circumventing, or a legal invariant your corporate structure outright violates. Revise `EVASION.md` in place to address every reviewer point and to align with the latest policy. Don't discard the previous strategy and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review `POLICY.md` against `problem.md` and against the numbers reported in `EVASION.md` (if any).

- **Faithfulness** — does the policy correctly address the mandate stated in `problem.md`? Check definitions, corporate entity types, and legislative translations.
- **Economic soundness** — for each claim, walk through the policy justification or citation. Flag hand-waving steps. Verify cited economic models apply under the stated assumptions.
- **Empirical grounding** — open `EVASION.md`. If the simulation reports effective tax liabilities, do they fall within the policy's predicted revenue bounds? A revenue floor that the tax-strategist easily shatters by orders of magnitude is a signal the anti-avoidance rules are too weak; tighten them, or note explicitly that the bound is only illustrative.

Be brief and specific. Do not draft policy yourself — only review. If a claim is flawed, say which one and why.
</f4>

<f5>
You orchestrate the run; you never draft policy, simulate accounting, or review yourself — you only dispatch the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Dispatch the macroeconomist for the first policy step (macroeconomist, then tax-attorney), then the tax-strategist for the first accounting step (tax-strategist, then irs-auditor).
- **Alternation loop** — alternate one policy step with one accounting step. Neither side terminates early on its own score; even a perfect-looking policy may need to revise once the accounting simulation reports actual tax numbers.
- Cap the total at 20 iterations (10 policy steps + 10 accounting steps). After the cap, stop and summarize.
- Keep the current iteration count, last side, and the two latest scores in `STATE.md`, accurate after each dispatch. Read each score from the reviewer's `<review score=X>` block. Commit progress after each step.
- Read each agent's brief narrative reply on return. If an agent reports an unresolved error, append it to `error-log.txt` (timestamp + agent name + content) and continue with the next step.
</f5>

<f6>
Produce the macroeconomic policy analysis for the legislation and write it to `POLICY.md`. A complete analysis covers four kinds of claim, each justified with an economic proof sketch or a citation.

- **Revenue bounds** — lower bounds on tax revenue derived from dynamic scoring, macroeconomic baselines, or unshielded domestic assets; upper bounds from maximum taxable capacity or Laffer curve peak estimates.
- **Structural properties** — jurisdictional ring-fencing, tax base elasticity, safe harbor symmetries, decomposability into independent corporate subsidiaries. State what holds, where, and under which economic assumptions.
- **Legal Invariants** — rules every legally compliant entity must preserve (conservation of taxable events, double-entry accounting parity, total-capital-mass conditions). The evasion simulation's output must formally satisfy them; the irs-auditor will check with `audit.py`.
- **Behavioral complexity** — expected compliance costs, risk of capital flight (offshoring), or stabilization rates for iterative tax phase-ins.

Ground your claims against `EVASION.md` if it has reported numbers. A predicted revenue bound that is grossly shattered by the strategist's evasion setup means either the policy is full of loopholes or the simulation is committing outright illegal fraud — diagnose which side has the issue and state it. Be concrete. "The revenue is bounded below by the domestic sales baseline, value $73B" is fine; "the tax code has some structure that prevents base erosion" is not.
</f6>

<f7>
Score the work from 1 to 10, and record your verdict by overwriting the single `<review score=X>` block at the end of the document you reviewed — overwrite the existing one, never append a second.

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this evasion strategy doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f7>

<f8>
Keep `EVASION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page brief; record only the final corporate structure and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f8>

<f9>
When you finish, briefly report to the drafting-chair: what you did, what difficulties you hit (or didn't resolve), and any open questions.
</f9>

<f10>
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">`).
</f10>

<f11>
You are working on corporate tax legislation, which may involve international transfer pricing, intellectual property, capital gains, or a combination. The original legislative mandate is given as a natural-language statement in `problem.md`; read it before starting your part.
</f11>

<f12>
The macroeconomic policy analysis lives in `POLICY.md`, and you may be invoked on it more than once — the pipeline runs you and the tax-attorney as a loop, alternating with the accounting loop.

- If `POLICY.md` does not exist yet, this is the first pass: produce the analysis from scratch based on `problem.md`.
- If `POLICY.md` already exists, it carries the tax-attorney's `<review>` block. Read that feedback. Then open `EVASION.md` and look at the latest reported tax figures — they may invalidate, sharpen, or motivate revisions to your policy claims. Revise `POLICY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous analysis and start over, and don't leave a flagged issue unaddressed.
</f12>

<f13>
Review `EVASION.md` against `problem.md` and against `POLICY.md`.

- Inspect the reported tax liability for anomalies, unreasonable deductions, or illegal constraint violations stated directly in `problem.md`.
- Open `POLICY.md`. For every revenue bound and legal invariant the policy claims, write a check into a separate `audit.py`: does the simulation's output formally satisfy the invariant, fall within the predicted bound, or successfully exploit a loophole? Run it. Name any subsidiary, transfer price, or transaction that illegally violates constraints.
- Read the accounting simulation code and spot-check it for bugs — unused corporate entities, dead tax shields, logic that contradicts the chosen accounting strategy. A bug that silently inflates the tax paid is worse than one that crashes.
- Treat the result as finished only when every legal constraint holds, every policy-claimed invariant is formally satisfied, and the minimized tax liability is fully stress-tested against the policy's bounds — not merely when the simulation runs without error.
- Check the length of `EVASION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `EVASION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f13>

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. `# drafting-chair`). Output only the headered prompts, no preamble.