I need you to set up a 5-agent pipeline that develops a clinical trial protocol by evolving the scientific trial rationale and the statistical analysis plan in parallel, with each side informing the other under skeptical ethics, methods, and regulatory review. A trial concept arrives as a natural-language statement in `trial_brief.md`. The pipeline alternates between revising the protocol rationale (clinical question, population, intervention, endpoints, ethical justification, feasibility assumptions) and revising the statistical analysis plan (estimands, hypotheses, sample size, analysis populations, models, missing-data strategy, and sensitivity analyses).

The five agents:

- **trial operations coordinator** orchestrates the run by alternating one protocol-rationale step with one statistical-analysis step and tracking progress. It does no scientific drafting, statistical planning, or reviewing itself.
- **protocol rationale loop** — the **clinical protocol architect** writes the scientific and ethical trial rationale to `PROTOCOL_RATIONALE.md`; the **independent scientific and ethics reviewer** judges it. The clinical protocol architect reads `SAP.md` on each revision pass to incorporate feasibility, power, multiplicity, and analysis-method implications.
- **statistical analysis loop** — the **statistical analysis plan author** writes the statistical analysis plan and its numerical design work to `SAP.md`; the **regulatory methods auditor** judges them. The statistical analysis plan author reads `PROTOCOL_RATIONALE.md` on each revision pass to align the analysis plan with the latest clinical objectives, endpoints, and ethical constraints.

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:

- `trial_brief.md` — the original trial concept, read-only. All four domain agents read it.
- `PROTOCOL_RATIONALE.md` — the scientific and ethical rationale. Clinical protocol architect writes; independent scientific and ethics reviewer reviews; statistical analysis plan author and regulatory methods auditor read it to know which clinical objectives, endpoints, eligibility assumptions, and ethical constraints the analysis plan must respect.
- `SAP.md` — the statistical analysis plan and numerical design work. Statistical analysis plan author writes; regulatory methods auditor reviews; clinical protocol architect and independent scientific and ethics reviewer read it to ground the protocol rationale in observed operating characteristics such as power, type I error control, precision, and feasibility.

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

Unlike a sequential protocol-then-SAP pipeline where the protocol rationale must converge before statistical planning starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. The rationale may tighten after seeing simulated power or multiplicity burdens; the SAP may correct after seeing refined objectives, endpoint definitions, or ethical constraints.

I'm providing the following information:

<f1>
Keep `SAP.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final state 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 the scientific rationale, write the statistical analysis plan, or review the work yourself — you only dispatch the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Dispatch the clinical protocol architect for the first protocol-rationale step (clinical protocol architect, then independent scientific and ethics reviewer), then the statistical analysis plan author for the first statistical-analysis step (statistical analysis plan author, then regulatory methods auditor).
- **Alternation loop** — alternate one protocol-rationale step with one statistical-analysis step. Neither side terminates early on its own score; even a perfect-looking rationale may need to revise once the SAP reports actual operating characteristics.
- Cap the total at 20 iterations (10 protocol-rationale steps + 10 statistical-analysis 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 a clinical trial protocol, which may be interventional, diagnostic, pragmatic, adaptive, randomized, single-arm, cluster-randomized, or a combination. The original trial concept is given as a natural-language statement in `trial_brief.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 doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f4>

<f5>
Produce the scientific and ethical trial rationale and write it to `PROTOCOL_RATIONALE.md`. A complete rationale covers four kinds of claim, each justified with a concise argument, evidence summary, or citation.

- **Benefit-risk and clinical need** — why the study question matters, what uncertainty exists, why the intervention or diagnostic strategy is plausible, and what risks are acceptable in relation to expected knowledge and participant benefit.
- **Design structure** — target population, eligibility criteria, intervention and comparator, visit schedule, randomization or allocation approach, blinding feasibility, endpoint hierarchy, and whether the design is superiority, noninferiority, equivalence, dose-finding, enrichment, adaptive, or pragmatic. State what holds, where, and under which assumptions.
- **Ethical and operational invariants** — conditions every acceptable trial design must preserve, such as equipoise, informed-consent requirements, rescue therapy access, stopping-rule triggers, maximum visit burden, pregnancy precautions, data-safety monitoring, or protection of vulnerable populations. The regulatory methods auditor will check that the SAP does not undermine them.
- **Feasibility or evidence-strength claims** — expected recruitment rate, event rate, retention, adherence, endpoint ascertainment reliability, and whether the planned evidence could support the intended clinical, labeling, guideline, or health-technology-assessment decision.

Ground your claims against `SAP.md` if it has reported numbers. A predicted event rate, sample size, power, or decision threshold that is grossly inconsistent with the statistical plan means either the rationale needs revision or the SAP has a methods problem — diagnose which side has the issue and state it. Be concrete. "The primary endpoint is 28-day hospitalization-free survival, with equipoise supported by two conflicting phase 2 signals and a planned interim safety review after 100 participants" is fine; "the trial has some rationale that may help" is not.
</f5>

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

<f7>
Match the tool to the trial question and evidence base; do not force an ill-suited one. The list below is useful in scientific and ethical protocol analysis.

| Tool | Suitable for |
|---|---|
| PICOT framing and estimand alignment | Clarifying population, intervention, comparator, outcome, timing, intercurrent events, and treatment-policy versus hypothetical questions |
| Equipoise and benefit-risk analysis | Interventional trials with meaningful toxicity, invasive procedures, placebo exposure, or vulnerable participants |
| Causal inference framework and target-trial emulation | Pragmatic trials, real-world evidence components, external controls, treatment switching, or confounding-sensitive questions |
| Endpoint validity and clinical meaningfulness assessment | Surrogate endpoints, composite endpoints, patient-reported outcomes, diagnostic accuracy endpoints, and endpoint adjudication |
| Adaptive-design rationale and decision rules | Dose-finding, enrichment, response-adaptive randomization, sample-size re-estimation, interim futility or efficacy monitoring |
| Feasibility and recruitment modeling | Rare disease, site-limited enrollment, long follow-up, competing trials, or high screen-failure risk |
| Historical-control and external-evidence appraisal | Single-arm oncology, device trials, emergency settings, or contexts where randomization may be difficult |
| Regulatory precedent and guideline mapping | Trials intended to support labeling claims, post-marketing commitments, clinical guidelines, or payer decisions |
</f7>

<f8>
Read `trial_brief.md` and `PROTOCOL_RATIONALE.md`, then produce the statistical analysis plan:

- Include every essential design and analysis element. Define the estimands, endpoints, analysis populations, hypotheses, type I error strategy, sample-size assumptions, randomization scheme, primary model, covariates, subgroup analyses, interim analyses, multiplicity adjustments, missing-data handling, sensitivity analyses, and planned tables or figures. State all thresholds and assumptions explicitly.
- Make the plan testable against `PROTOCOL_RATIONALE.md`. If the rationale requires a maximum participant burden, a prespecified safety stop, or an endpoint hierarchy, your SAP should preserve it. If the rationale claims a clinically meaningful effect size or event rate, your sample-size and power work should be consistent with it.
- Perform the numerical checks yourself and watch them through to completion — do not leave power, precision, or operating-characteristic calculations half-finished. If a calculation fails or gives an implausible answer, find and fix the root cause; do not bury it under vague caveats.
- Sanity-check the SAP against `PROTOCOL_RATIONALE.md`. A binary endpoint should not be analyzed as continuous without justification; an estimand that requires treatment-policy handling should not silently censor rescue medication; a stopping rule the rationale says is mandatory should appear in the analysis plan.

Write the statistical analysis plan and its numerical results up in `SAP.md`.
</f8>

<f9>
Review `SAP.md` against `trial_brief.md` and against `PROTOCOL_RATIONALE.md`.

- Inspect the reported design and analysis results for anomalies, unreasonable sample sizes, unsupported effect sizes, broken type I error control, implausible recruitment assumptions, or endpoint definitions that contradict `trial_brief.md`.
- Open `PROTOCOL_RATIONALE.md`. For every ethical invariant, endpoint hierarchy, feasibility assumption, and clinical claim the rationale makes, write a check into a separate `verify.py`: does the SAP preserve the invariant, use the correct endpoint and population, respect the planned stopping rules, maintain the claimed type I error strategy, and support the stated power or precision? Run it. Name any endpoint, population, threshold, or assumption that violates the rationale.
- Read the SAP and spot-check it for methods bugs — mismatched estimands and analyses, unused stratification factors, contradictory analysis populations, multiplicity gaps, post-randomization exclusions, missing intercurrent-event handling, or sensitivity analyses that do not answer the stated robustness question. A methods flaw that silently biases the estimate is worse than one that is obvious.
- Treat the plan as finished only when every trial requirement holds, every rationale-claimed ethical or design invariant holds, and the operating characteristics are consistent with the rationale's assumptions — not merely when the document is internally polished.
- Check the length of `SAP.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SAP.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 scientific and ethical trial rationale lives in `PROTOCOL_RATIONALE.md`, and you may be invoked on it more than once — the pipeline runs you and the independent scientific and ethics reviewer as a loop, alternating with the statistical analysis loop.

- If `PROTOCOL_RATIONALE.md` does not exist yet, this is the first pass: produce the rationale from scratch based on `trial_brief.md`.
- If `PROTOCOL_RATIONALE.md` already exists, it carries the independent scientific and ethics reviewer's `<review>` block. Read that feedback. Then open `SAP.md` and look at the latest reported design numbers — they may invalidate, sharpen, or motivate revisions to your clinical assumptions, endpoint choices, ethical constraints, or feasibility claims. Revise `PROTOCOL_RATIONALE.md` in place to address every reviewer point raised and to incorporate any statistical evidence that changes your rationale. Don't discard the previous rationale and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
Review `PROTOCOL_RATIONALE.md` against `trial_brief.md` and against the design numbers reported in `SAP.md` (if any).

- **Faithfulness** — does the rationale correctly describe the trial concept stated in `trial_brief.md`? Check the clinical question, population, intervention, comparator, endpoint definitions, follow-up duration, and intended decision context.
- **Scientific and ethical soundness** — for each claim, walk through the evidence summary, ethical argument, or citation. Flag hand-waving steps. Verify that benefit-risk, equipoise, consent, monitoring, and participant-burden claims apply under the stated assumptions.
- **Statistical grounding** — open `SAP.md`. If the SAP reports sample size, power, event-rate assumptions, type I error allocation, interim monitoring, or simulation results, do they support the rationale's predicted feasibility and evidentiary strength? A power calculation that relies on an unrealistic effect size or a recruitment estimate that is off by orders of magnitude is a signal the rationale is too optimistic; tighten it, or note explicitly that the assumption is only exploratory.

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

<f13>
The statistical analysis plan and its numerical design work live in `SAP.md`, and you may be invoked on it more than once — the pipeline runs you and the regulatory methods auditor as a loop, alternating with the protocol rationale loop.

- If `SAP.md` does not exist yet, this is the first pass: produce the plan from scratch based on `trial_brief.md`.
- If `SAP.md` already exists, it carries the regulatory methods auditor's `<review>` block. Read that feedback. Then open `PROTOCOL_RATIONALE.md` and check whether the latest rationale introduces endpoints, ethical invariants, feasibility constraints, or clinical claims your current SAP doesn't yet respect — for example a revised endpoint hierarchy, a mandatory interim safety stop, a stricter estimand, or a recruitment constraint that makes the sample size infeasible. Revise `SAP.md` in place to address every reviewer point and to align with the latest rationale. Don't discard the previous plan 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 (trial operations coordinator, clinical protocol architect, independent scientific and ethics reviewer, statistical analysis plan author, regulatory methods auditor), which items should go in its prompt? Respond with a JSON object like {"trial operations coordinator": ["f?"], "clinical protocol architect": ["f?"], "independent scientific and ethics reviewer": ["f?"], "statistical analysis plan author": ["f?"], "regulatory methods auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that develops a clinical trial protocol by evolving the scientific trial rationale and the statistical analysis plan in parallel, with each side informing the other under skeptical ethics, methods, and regulatory review. A trial concept arrives as a natural-language statement in `trial_brief.md`. The pipeline alternates between revising the protocol rationale (clinical question, population, intervention, endpoints, ethical justification, feasibility assumptions) and revising the statistical analysis plan (estimands, hypotheses, sample size, analysis populations, models, missing-data strategy, and sensitivity analyses).

The five agents:

- **trial operations coordinator** orchestrates the run by alternating one protocol-rationale step with one statistical-analysis step and tracking progress. It does no scientific drafting, statistical planning, or reviewing itself.
- **protocol rationale loop** — the **clinical protocol architect** writes the scientific and ethical trial rationale to `PROTOCOL_RATIONALE.md`; the **independent scientific and ethics reviewer** judges it. The clinical protocol architect reads `SAP.md` on each revision pass to incorporate feasibility, power, multiplicity, and analysis-method implications.
- **statistical analysis loop** — the **statistical analysis plan author** writes the statistical analysis plan and its numerical design work to `SAP.md`; the **regulatory methods auditor** judges them. The statistical analysis plan author reads `PROTOCOL_RATIONALE.md` on each revision pass to align the analysis plan with the latest clinical objectives, endpoints, and ethical constraints.

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:

- `trial_brief.md` — the original trial concept, read-only. All four domain agents read it.
- `PROTOCOL_RATIONALE.md` — the scientific and ethical rationale. Clinical protocol architect writes; independent scientific and ethics reviewer reviews; statistical analysis plan author and regulatory methods auditor read it to know which clinical objectives, endpoints, eligibility assumptions, and ethical constraints the analysis plan must respect.
- `SAP.md` — the statistical analysis plan and numerical design work. Statistical analysis plan author writes; regulatory methods auditor reviews; clinical protocol architect and independent scientific and ethics reviewer read it to ground the protocol rationale in observed operating characteristics such as power, type I error control, precision, and feasibility.

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

Unlike a sequential protocol-then-SAP pipeline where the protocol rationale must converge before statistical planning starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. The rationale may tighten after seeing simulated power or multiplicity burdens; the SAP may correct after seeing refined objectives, endpoint definitions, or ethical constraints.

I'm providing the following prompt fragments:

<f1>
Keep `SAP.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final state 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 the scientific rationale, write the statistical analysis plan, or review the work yourself — you only dispatch the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Dispatch the clinical protocol architect for the first protocol-rationale step (clinical protocol architect, then independent scientific and ethics reviewer), then the statistical analysis plan author for the first statistical-analysis step (statistical analysis plan author, then regulatory methods auditor).
- **Alternation loop** — alternate one protocol-rationale step with one statistical-analysis step. Neither side terminates early on its own score; even a perfect-looking rationale may need to revise once the SAP reports actual operating characteristics.
- Cap the total at 20 iterations (10 protocol-rationale steps + 10 statistical-analysis 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 a clinical trial protocol, which may be interventional, diagnostic, pragmatic, adaptive, randomized, single-arm, cluster-randomized, or a combination. The original trial concept is given as a natural-language statement in `trial_brief.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 doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f4>

<f5>
Produce the scientific and ethical trial rationale and write it to `PROTOCOL_RATIONALE.md`. A complete rationale covers four kinds of claim, each justified with a concise argument, evidence summary, or citation.

- **Benefit-risk and clinical need** — why the study question matters, what uncertainty exists, why the intervention or diagnostic strategy is plausible, and what risks are acceptable in relation to expected knowledge and participant benefit.
- **Design structure** — target population, eligibility criteria, intervention and comparator, visit schedule, randomization or allocation approach, blinding feasibility, endpoint hierarchy, and whether the design is superiority, noninferiority, equivalence, dose-finding, enrichment, adaptive, or pragmatic. State what holds, where, and under which assumptions.
- **Ethical and operational invariants** — conditions every acceptable trial design must preserve, such as equipoise, informed-consent requirements, rescue therapy access, stopping-rule triggers, maximum visit burden, pregnancy precautions, data-safety monitoring, or protection of vulnerable populations. The regulatory methods auditor will check that the SAP does not undermine them.
- **Feasibility or evidence-strength claims** — expected recruitment rate, event rate, retention, adherence, endpoint ascertainment reliability, and whether the planned evidence could support the intended clinical, labeling, guideline, or health-technology-assessment decision.

Ground your claims against `SAP.md` if it has reported numbers. A predicted event rate, sample size, power, or decision threshold that is grossly inconsistent with the statistical plan means either the rationale needs revision or the SAP has a methods problem — diagnose which side has the issue and state it. Be concrete. "The primary endpoint is 28-day hospitalization-free survival, with equipoise supported by two conflicting phase 2 signals and a planned interim safety review after 100 participants" is fine; "the trial has some rationale that may help" is not.
</f5>

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

<f7>
Match the tool to the trial question and evidence base; do not force an ill-suited one. The list below is useful in scientific and ethical protocol analysis.

| Tool | Suitable for |
|---|---|
| PICOT framing and estimand alignment | Clarifying population, intervention, comparator, outcome, timing, intercurrent events, and treatment-policy versus hypothetical questions |
| Equipoise and benefit-risk analysis | Interventional trials with meaningful toxicity, invasive procedures, placebo exposure, or vulnerable participants |
| Causal inference framework and target-trial emulation | Pragmatic trials, real-world evidence components, external controls, treatment switching, or confounding-sensitive questions |
| Endpoint validity and clinical meaningfulness assessment | Surrogate endpoints, composite endpoints, patient-reported outcomes, diagnostic accuracy endpoints, and endpoint adjudication |
| Adaptive-design rationale and decision rules | Dose-finding, enrichment, response-adaptive randomization, sample-size re-estimation, interim futility or efficacy monitoring |
| Feasibility and recruitment modeling | Rare disease, site-limited enrollment, long follow-up, competing trials, or high screen-failure risk |
| Historical-control and external-evidence appraisal | Single-arm oncology, device trials, emergency settings, or contexts where randomization may be difficult |
| Regulatory precedent and guideline mapping | Trials intended to support labeling claims, post-marketing commitments, clinical guidelines, or payer decisions |
</f7>

<f8>
Read `trial_brief.md` and `PROTOCOL_RATIONALE.md`, then produce the statistical analysis plan:

- Include every essential design and analysis element. Define the estimands, endpoints, analysis populations, hypotheses, type I error strategy, sample-size assumptions, randomization scheme, primary model, covariates, subgroup analyses, interim analyses, multiplicity adjustments, missing-data handling, sensitivity analyses, and planned tables or figures. State all thresholds and assumptions explicitly.
- Make the plan testable against `PROTOCOL_RATIONALE.md`. If the rationale requires a maximum participant burden, a prespecified safety stop, or an endpoint hierarchy, your SAP should preserve it. If the rationale claims a clinically meaningful effect size or event rate, your sample-size and power work should be consistent with it.
- Perform the numerical checks yourself and watch them through to completion — do not leave power, precision, or operating-characteristic calculations half-finished. If a calculation fails or gives an implausible answer, find and fix the root cause; do not bury it under vague caveats.
- Sanity-check the SAP against `PROTOCOL_RATIONALE.md`. A binary endpoint should not be analyzed as continuous without justification; an estimand that requires treatment-policy handling should not silently censor rescue medication; a stopping rule the rationale says is mandatory should appear in the analysis plan.

Write the statistical analysis plan and its numerical results up in `SAP.md`.
</f8>

<f9>
Review `SAP.md` against `trial_brief.md` and against `PROTOCOL_RATIONALE.md`.

- Inspect the reported design and analysis results for anomalies, unreasonable sample sizes, unsupported effect sizes, broken type I error control, implausible recruitment assumptions, or endpoint definitions that contradict `trial_brief.md`.
- Open `PROTOCOL_RATIONALE.md`. For every ethical invariant, endpoint hierarchy, feasibility assumption, and clinical claim the rationale makes, write a check into a separate `verify.py`: does the SAP preserve the invariant, use the correct endpoint and population, respect the planned stopping rules, maintain the claimed type I error strategy, and support the stated power or precision? Run it. Name any endpoint, population, threshold, or assumption that violates the rationale.
- Read the SAP and spot-check it for methods bugs — mismatched estimands and analyses, unused stratification factors, contradictory analysis populations, multiplicity gaps, post-randomization exclusions, missing intercurrent-event handling, or sensitivity analyses that do not answer the stated robustness question. A methods flaw that silently biases the estimate is worse than one that is obvious.
- Treat the plan as finished only when every trial requirement holds, every rationale-claimed ethical or design invariant holds, and the operating characteristics are consistent with the rationale's assumptions — not merely when the document is internally polished.
- Check the length of `SAP.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SAP.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 scientific and ethical trial rationale lives in `PROTOCOL_RATIONALE.md`, and you may be invoked on it more than once — the pipeline runs you and the independent scientific and ethics reviewer as a loop, alternating with the statistical analysis loop.

- If `PROTOCOL_RATIONALE.md` does not exist yet, this is the first pass: produce the rationale from scratch based on `trial_brief.md`.
- If `PROTOCOL_RATIONALE.md` already exists, it carries the independent scientific and ethics reviewer's `<review>` block. Read that feedback. Then open `SAP.md` and look at the latest reported design numbers — they may invalidate, sharpen, or motivate revisions to your clinical assumptions, endpoint choices, ethical constraints, or feasibility claims. Revise `PROTOCOL_RATIONALE.md` in place to address every reviewer point raised and to incorporate any statistical evidence that changes your rationale. Don't discard the previous rationale and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
Review `PROTOCOL_RATIONALE.md` against `trial_brief.md` and against the design numbers reported in `SAP.md` (if any).

- **Faithfulness** — does the rationale correctly describe the trial concept stated in `trial_brief.md`? Check the clinical question, population, intervention, comparator, endpoint definitions, follow-up duration, and intended decision context.
- **Scientific and ethical soundness** — for each claim, walk through the evidence summary, ethical argument, or citation. Flag hand-waving steps. Verify that benefit-risk, equipoise, consent, monitoring, and participant-burden claims apply under the stated assumptions.
- **Statistical grounding** — open `SAP.md`. If the SAP reports sample size, power, event-rate assumptions, type I error allocation, interim monitoring, or simulation results, do they support the rationale's predicted feasibility and evidentiary strength? A power calculation that relies on an unrealistic effect size or a recruitment estimate that is off by orders of magnitude is a signal the rationale is too optimistic; tighten it, or note explicitly that the assumption is only exploratory.

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

<f13>
The statistical analysis plan and its numerical design work live in `SAP.md`, and you may be invoked on it more than once — the pipeline runs you and the regulatory methods auditor as a loop, alternating with the protocol rationale loop.

- If `SAP.md` does not exist yet, this is the first pass: produce the plan from scratch based on `trial_brief.md`.
- If `SAP.md` already exists, it carries the regulatory methods auditor's `<review>` block. Read that feedback. Then open `PROTOCOL_RATIONALE.md` and check whether the latest rationale introduces endpoints, ethical invariants, feasibility constraints, or clinical claims your current SAP doesn't yet respect — for example a revised endpoint hierarchy, a mandatory interim safety stop, a stricter estimand, or a recruitment constraint that makes the sample size infeasible. Revise `SAP.md` in place to address every reviewer point and to align with the latest rationale. Don't discard the previous plan 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. `# trial operations coordinator`). Output only the headered prompts, no preamble.


I need you to set up a 5-agent pipeline that develops a clinical trial protocol by evolving the scientific trial rationale and the statistical analysis plan in parallel, with each side informing the other under skeptical ethics, methods, and regulatory review. A trial concept arrives as a natural-language statement in `trial_brief.md`. The pipeline alternates between revising the protocol rationale (clinical question, population, intervention, endpoints, ethical justification, feasibility assumptions) and revising the statistical analysis plan (estimands, hypotheses, sample size, analysis populations, models, missing-data strategy, and sensitivity analyses).

The five agents:

- **trial operations coordinator** orchestrates the run by alternating one protocol-rationale step with one statistical-analysis step and tracking progress. It does no scientific drafting, statistical planning, or reviewing itself.
- **protocol rationale loop** — the **clinical protocol architect** writes the scientific and ethical trial rationale to `PROTOCOL_RATIONALE.md`; the **independent scientific and ethics reviewer** judges it. The clinical protocol architect reads `SAP.md` on each revision pass to incorporate feasibility, power, multiplicity, and analysis-method implications.
- **statistical analysis loop** — the **statistical analysis plan author** writes the statistical analysis plan and its numerical design work to `SAP.md`; the **regulatory methods auditor** judges them. The statistical analysis plan author reads `PROTOCOL_RATIONALE.md` on each revision pass to align the analysis plan with the latest clinical objectives, endpoints, and ethical constraints.

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:

- `trial_brief.md` — the original trial concept, read-only. All four domain agents read it.
- `PROTOCOL_RATIONALE.md` — the scientific and ethical rationale. Clinical protocol architect writes; independent scientific and ethics reviewer reviews; statistical analysis plan author and regulatory methods auditor read it to know which clinical objectives, endpoints, eligibility assumptions, and ethical constraints the analysis plan must respect.
- `SAP.md` — the statistical analysis plan and numerical design work. Statistical analysis plan author writes; regulatory methods auditor reviews; clinical protocol architect and independent scientific and ethics reviewer read it to ground the protocol rationale in observed operating characteristics such as power, type I error control, precision, and feasibility.

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

Unlike a sequential protocol-then-SAP pipeline where the protocol rationale must converge before statistical planning starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. The rationale may tighten after seeing simulated power or multiplicity burdens; the SAP may correct after seeing refined objectives, endpoint definitions, or ethical constraints.

I'm providing the following information:

<f1>
Read `trial_brief.md` and `PROTOCOL_RATIONALE.md`, then produce the statistical analysis plan:

- Include every essential design and analysis element. Define the estimands, endpoints, analysis populations, hypotheses, type I error strategy, sample-size assumptions, randomization scheme, primary model, covariates, subgroup analyses, interim analyses, multiplicity adjustments, missing-data handling, sensitivity analyses, and planned tables or figures. State all thresholds and assumptions explicitly.
- Make the plan testable against `PROTOCOL_RATIONALE.md`. If the rationale requires a maximum participant burden, a prespecified safety stop, or an endpoint hierarchy, your SAP should preserve it. If the rationale claims a clinically meaningful effect size or event rate, your sample-size and power work should be consistent with it.
- Perform the numerical checks yourself and watch them through to completion — do not leave power, precision, or operating-characteristic calculations half-finished. If a calculation fails or gives an implausible answer, find and fix the root cause; do not bury it under vague caveats.
- Sanity-check the SAP against `PROTOCOL_RATIONALE.md`. A binary endpoint should not be analyzed as continuous without justification; an estimand that requires treatment-policy handling should not silently censor rescue medication; a stopping rule the rationale says is mandatory should appear in the analysis plan.

Write the statistical analysis plan and its numerical results up in `SAP.md`.
</f1>

<f2>
Match the tool to the trial question and evidence base; do not force an ill-suited one. The list below is useful in scientific and ethical protocol analysis.

| Tool | Suitable for |
|---|---|
| PICOT framing and estimand alignment | Clarifying population, intervention, comparator, outcome, timing, intercurrent events, and treatment-policy versus hypothetical questions |
| Equipoise and benefit-risk analysis | Interventional trials with meaningful toxicity, invasive procedures, placebo exposure, or vulnerable participants |
| Causal inference framework and target-trial emulation | Pragmatic trials, real-world evidence components, external controls, treatment switching, or confounding-sensitive questions |
| Endpoint validity and clinical meaningfulness assessment | Surrogate endpoints, composite endpoints, patient-reported outcomes, diagnostic accuracy endpoints, and endpoint adjudication |
| Adaptive-design rationale and decision rules | Dose-finding, enrichment, response-adaptive randomization, sample-size re-estimation, interim futility or efficacy monitoring |
| Feasibility and recruitment modeling | Rare disease, site-limited enrollment, long follow-up, competing trials, or high screen-failure risk |
| Historical-control and external-evidence appraisal | Single-arm oncology, device trials, emergency settings, or contexts where randomization may be difficult |
| Regulatory precedent and guideline mapping | Trials intended to support labeling claims, post-marketing commitments, clinical guidelines, or payer decisions |
</f2>

<f3>
The statistical analysis plan and its numerical design work live in `SAP.md`, and you may be invoked on it more than once — the pipeline runs you and the regulatory methods auditor as a loop, alternating with the protocol rationale loop.

- If `SAP.md` does not exist yet, this is the first pass: produce the plan from scratch based on `trial_brief.md`.
- If `SAP.md` already exists, it carries the regulatory methods auditor's `<review>` block. Read that feedback. Then open `PROTOCOL_RATIONALE.md` and check whether the latest rationale introduces endpoints, ethical invariants, feasibility constraints, or clinical claims your current SAP doesn't yet respect — for example a revised endpoint hierarchy, a mandatory interim safety stop, a stricter estimand, or a recruitment constraint that makes the sample size infeasible. Revise `SAP.md` in place to address every reviewer point and to align with the latest rationale. Don't discard the previous plan and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review `PROTOCOL_RATIONALE.md` against `trial_brief.md` and against the design numbers reported in `SAP.md` (if any).

- **Faithfulness** — does the rationale correctly describe the trial concept stated in `trial_brief.md`? Check the clinical question, population, intervention, comparator, endpoint definitions, follow-up duration, and intended decision context.
- **Scientific and ethical soundness** — for each claim, walk through the evidence summary, ethical argument, or citation. Flag hand-waving steps. Verify that benefit-risk, equipoise, consent, monitoring, and participant-burden claims apply under the stated assumptions.
- **Statistical grounding** — open `SAP.md`. If the SAP reports sample size, power, event-rate assumptions, type I error allocation, interim monitoring, or simulation results, do they support the rationale's predicted feasibility and evidentiary strength? A power calculation that relies on an unrealistic effect size or a recruitment estimate that is off by orders of magnitude is a signal the rationale is too optimistic; tighten it, or note explicitly that the assumption is only exploratory.

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

<f5>
You orchestrate the run; you never draft the scientific rationale, write the statistical analysis plan, or review the work yourself — you only dispatch the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Dispatch the clinical protocol architect for the first protocol-rationale step (clinical protocol architect, then independent scientific and ethics reviewer), then the statistical analysis plan author for the first statistical-analysis step (statistical analysis plan author, then regulatory methods auditor).
- **Alternation loop** — alternate one protocol-rationale step with one statistical-analysis step. Neither side terminates early on its own score; even a perfect-looking rationale may need to revise once the SAP reports actual operating characteristics.
- Cap the total at 20 iterations (10 protocol-rationale steps + 10 statistical-analysis 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 scientific and ethical trial rationale and write it to `PROTOCOL_RATIONALE.md`. A complete rationale covers four kinds of claim, each justified with a concise argument, evidence summary, or citation.

- **Benefit-risk and clinical need** — why the study question matters, what uncertainty exists, why the intervention or diagnostic strategy is plausible, and what risks are acceptable in relation to expected knowledge and participant benefit.
- **Design structure** — target population, eligibility criteria, intervention and comparator, visit schedule, randomization or allocation approach, blinding feasibility, endpoint hierarchy, and whether the design is superiority, noninferiority, equivalence, dose-finding, enrichment, adaptive, or pragmatic. State what holds, where, and under which assumptions.
- **Ethical and operational invariants** — conditions every acceptable trial design must preserve, such as equipoise, informed-consent requirements, rescue therapy access, stopping-rule triggers, maximum visit burden, pregnancy precautions, data-safety monitoring, or protection of vulnerable populations. The regulatory methods auditor will check that the SAP does not undermine them.
- **Feasibility or evidence-strength claims** — expected recruitment rate, event rate, retention, adherence, endpoint ascertainment reliability, and whether the planned evidence could support the intended clinical, labeling, guideline, or health-technology-assessment decision.

Ground your claims against `SAP.md` if it has reported numbers. A predicted event rate, sample size, power, or decision threshold that is grossly inconsistent with the statistical plan means either the rationale needs revision or the SAP has a methods problem — diagnose which side has the issue and state it. Be concrete. "The primary endpoint is 28-day hospitalization-free survival, with equipoise supported by two conflicting phase 2 signals and a planned interim safety review after 100 participants" is fine; "the trial has some rationale that may help" 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 doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f7>

<f8>
Keep `SAP.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final state 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 trial operations coordinator: 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 clinical trial protocol, which may be interventional, diagnostic, pragmatic, adaptive, randomized, single-arm, cluster-randomized, or a combination. The original trial concept is given as a natural-language statement in `trial_brief.md`; read it before starting your part.
</f11>

<f12>
The scientific and ethical trial rationale lives in `PROTOCOL_RATIONALE.md`, and you may be invoked on it more than once — the pipeline runs you and the independent scientific and ethics reviewer as a loop, alternating with the statistical analysis loop.

- If `PROTOCOL_RATIONALE.md` does not exist yet, this is the first pass: produce the rationale from scratch based on `trial_brief.md`.
- If `PROTOCOL_RATIONALE.md` already exists, it carries the independent scientific and ethics reviewer's `<review>` block. Read that feedback. Then open `SAP.md` and look at the latest reported design numbers — they may invalidate, sharpen, or motivate revisions to your clinical assumptions, endpoint choices, ethical constraints, or feasibility claims. Revise `PROTOCOL_RATIONALE.md` in place to address every reviewer point raised and to incorporate any statistical evidence that changes your rationale. Don't discard the previous rationale and start over, and don't leave a flagged issue unaddressed.
</f12>

<f13>
Review `SAP.md` against `trial_brief.md` and against `PROTOCOL_RATIONALE.md`.

- Inspect the reported design and analysis results for anomalies, unreasonable sample sizes, unsupported effect sizes, broken type I error control, implausible recruitment assumptions, or endpoint definitions that contradict `trial_brief.md`.
- Open `PROTOCOL_RATIONALE.md`. For every ethical invariant, endpoint hierarchy, feasibility assumption, and clinical claim the rationale makes, write a check into a separate `verify.py`: does the SAP preserve the invariant, use the correct endpoint and population, respect the planned stopping rules, maintain the claimed type I error strategy, and support the stated power or precision? Run it. Name any endpoint, population, threshold, or assumption that violates the rationale.
- Read the SAP and spot-check it for methods bugs — mismatched estimands and analyses, unused stratification factors, contradictory analysis populations, multiplicity gaps, post-randomization exclusions, missing intercurrent-event handling, or sensitivity analyses that do not answer the stated robustness question. A methods flaw that silently biases the estimate is worse than one that is obvious.
- Treat the plan as finished only when every trial requirement holds, every rationale-claimed ethical or design invariant holds, and the operating characteristics are consistent with the rationale's assumptions — not merely when the document is internally polished.
- Check the length of `SAP.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SAP.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 (trial operations coordinator, clinical protocol architect, independent scientific and ethics reviewer, statistical analysis plan author, regulatory methods auditor), which items should go in its prompt? Respond with a JSON object like {"trial operations coordinator": ["f?"], "clinical protocol architect": ["f?"], "independent scientific and ethics reviewer": ["f?"], "statistical analysis plan author": ["f?"], "regulatory methods auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that develops a clinical trial protocol by evolving the scientific trial rationale and the statistical analysis plan in parallel, with each side informing the other under skeptical ethics, methods, and regulatory review. A trial concept arrives as a natural-language statement in `trial_brief.md`. The pipeline alternates between revising the protocol rationale (clinical question, population, intervention, endpoints, ethical justification, feasibility assumptions) and revising the statistical analysis plan (estimands, hypotheses, sample size, analysis populations, models, missing-data strategy, and sensitivity analyses).

The five agents:

- **trial operations coordinator** orchestrates the run by alternating one protocol-rationale step with one statistical-analysis step and tracking progress. It does no scientific drafting, statistical planning, or reviewing itself.
- **protocol rationale loop** — the **clinical protocol architect** writes the scientific and ethical trial rationale to `PROTOCOL_RATIONALE.md`; the **independent scientific and ethics reviewer** judges it. The clinical protocol architect reads `SAP.md` on each revision pass to incorporate feasibility, power, multiplicity, and analysis-method implications.
- **statistical analysis loop** — the **statistical analysis plan author** writes the statistical analysis plan and its numerical design work to `SAP.md`; the **regulatory methods auditor** judges them. The statistical analysis plan author reads `PROTOCOL_RATIONALE.md` on each revision pass to align the analysis plan with the latest clinical objectives, endpoints, and ethical constraints.

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:

- `trial_brief.md` — the original trial concept, read-only. All four domain agents read it.
- `PROTOCOL_RATIONALE.md` — the scientific and ethical rationale. Clinical protocol architect writes; independent scientific and ethics reviewer reviews; statistical analysis plan author and regulatory methods auditor read it to know which clinical objectives, endpoints, eligibility assumptions, and ethical constraints the analysis plan must respect.
- `SAP.md` — the statistical analysis plan and numerical design work. Statistical analysis plan author writes; regulatory methods auditor reviews; clinical protocol architect and independent scientific and ethics reviewer read it to ground the protocol rationale in observed operating characteristics such as power, type I error control, precision, and feasibility.

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

Unlike a sequential protocol-then-SAP pipeline where the protocol rationale must converge before statistical planning starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. The rationale may tighten after seeing simulated power or multiplicity burdens; the SAP may correct after seeing refined objectives, endpoint definitions, or ethical constraints.

I'm providing the following prompt fragments:

<f1>
Read `trial_brief.md` and `PROTOCOL_RATIONALE.md`, then produce the statistical analysis plan:

- Include every essential design and analysis element. Define the estimands, endpoints, analysis populations, hypotheses, type I error strategy, sample-size assumptions, randomization scheme, primary model, covariates, subgroup analyses, interim analyses, multiplicity adjustments, missing-data handling, sensitivity analyses, and planned tables or figures. State all thresholds and assumptions explicitly.
- Make the plan testable against `PROTOCOL_RATIONALE.md`. If the rationale requires a maximum participant burden, a prespecified safety stop, or an endpoint hierarchy, your SAP should preserve it. If the rationale claims a clinically meaningful effect size or event rate, your sample-size and power work should be consistent with it.
- Perform the numerical checks yourself and watch them through to completion — do not leave power, precision, or operating-characteristic calculations half-finished. If a calculation fails or gives an implausible answer, find and fix the root cause; do not bury it under vague caveats.
- Sanity-check the SAP against `PROTOCOL_RATIONALE.md`. A binary endpoint should not be analyzed as continuous without justification; an estimand that requires treatment-policy handling should not silently censor rescue medication; a stopping rule the rationale says is mandatory should appear in the analysis plan.

Write the statistical analysis plan and its numerical results up in `SAP.md`.
</f1>

<f2>
Match the tool to the trial question and evidence base; do not force an ill-suited one. The list below is useful in scientific and ethical protocol analysis.

| Tool | Suitable for |
|---|---|
| PICOT framing and estimand alignment | Clarifying population, intervention, comparator, outcome, timing, intercurrent events, and treatment-policy versus hypothetical questions |
| Equipoise and benefit-risk analysis | Interventional trials with meaningful toxicity, invasive procedures, placebo exposure, or vulnerable participants |
| Causal inference framework and target-trial emulation | Pragmatic trials, real-world evidence components, external controls, treatment switching, or confounding-sensitive questions |
| Endpoint validity and clinical meaningfulness assessment | Surrogate endpoints, composite endpoints, patient-reported outcomes, diagnostic accuracy endpoints, and endpoint adjudication |
| Adaptive-design rationale and decision rules | Dose-finding, enrichment, response-adaptive randomization, sample-size re-estimation, interim futility or efficacy monitoring |
| Feasibility and recruitment modeling | Rare disease, site-limited enrollment, long follow-up, competing trials, or high screen-failure risk |
| Historical-control and external-evidence appraisal | Single-arm oncology, device trials, emergency settings, or contexts where randomization may be difficult |
| Regulatory precedent and guideline mapping | Trials intended to support labeling claims, post-marketing commitments, clinical guidelines, or payer decisions |
</f2>

<f3>
The statistical analysis plan and its numerical design work live in `SAP.md`, and you may be invoked on it more than once — the pipeline runs you and the regulatory methods auditor as a loop, alternating with the protocol rationale loop.

- If `SAP.md` does not exist yet, this is the first pass: produce the plan from scratch based on `trial_brief.md`.
- If `SAP.md` already exists, it carries the regulatory methods auditor's `<review>` block. Read that feedback. Then open `PROTOCOL_RATIONALE.md` and check whether the latest rationale introduces endpoints, ethical invariants, feasibility constraints, or clinical claims your current SAP doesn't yet respect — for example a revised endpoint hierarchy, a mandatory interim safety stop, a stricter estimand, or a recruitment constraint that makes the sample size infeasible. Revise `SAP.md` in place to address every reviewer point and to align with the latest rationale. Don't discard the previous plan and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review `PROTOCOL_RATIONALE.md` against `trial_brief.md` and against the design numbers reported in `SAP.md` (if any).

- **Faithfulness** — does the rationale correctly describe the trial concept stated in `trial_brief.md`? Check the clinical question, population, intervention, comparator, endpoint definitions, follow-up duration, and intended decision context.
- **Scientific and ethical soundness** — for each claim, walk through the evidence summary, ethical argument, or citation. Flag hand-waving steps. Verify that benefit-risk, equipoise, consent, monitoring, and participant-burden claims apply under the stated assumptions.
- **Statistical grounding** — open `SAP.md`. If the SAP reports sample size, power, event-rate assumptions, type I error allocation, interim monitoring, or simulation results, do they support the rationale's predicted feasibility and evidentiary strength? A power calculation that relies on an unrealistic effect size or a recruitment estimate that is off by orders of magnitude is a signal the rationale is too optimistic; tighten it, or note explicitly that the assumption is only exploratory.

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

<f5>
You orchestrate the run; you never draft the scientific rationale, write the statistical analysis plan, or review the work yourself — you only dispatch the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Dispatch the clinical protocol architect for the first protocol-rationale step (clinical protocol architect, then independent scientific and ethics reviewer), then the statistical analysis plan author for the first statistical-analysis step (statistical analysis plan author, then regulatory methods auditor).
- **Alternation loop** — alternate one protocol-rationale step with one statistical-analysis step. Neither side terminates early on its own score; even a perfect-looking rationale may need to revise once the SAP reports actual operating characteristics.
- Cap the total at 20 iterations (10 protocol-rationale steps + 10 statistical-analysis 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 scientific and ethical trial rationale and write it to `PROTOCOL_RATIONALE.md`. A complete rationale covers four kinds of claim, each justified with a concise argument, evidence summary, or citation.

- **Benefit-risk and clinical need** — why the study question matters, what uncertainty exists, why the intervention or diagnostic strategy is plausible, and what risks are acceptable in relation to expected knowledge and participant benefit.
- **Design structure** — target population, eligibility criteria, intervention and comparator, visit schedule, randomization or allocation approach, blinding feasibility, endpoint hierarchy, and whether the design is superiority, noninferiority, equivalence, dose-finding, enrichment, adaptive, or pragmatic. State what holds, where, and under which assumptions.
- **Ethical and operational invariants** — conditions every acceptable trial design must preserve, such as equipoise, informed-consent requirements, rescue therapy access, stopping-rule triggers, maximum visit burden, pregnancy precautions, data-safety monitoring, or protection of vulnerable populations. The regulatory methods auditor will check that the SAP does not undermine them.
- **Feasibility or evidence-strength claims** — expected recruitment rate, event rate, retention, adherence, endpoint ascertainment reliability, and whether the planned evidence could support the intended clinical, labeling, guideline, or health-technology-assessment decision.

Ground your claims against `SAP.md` if it has reported numbers. A predicted event rate, sample size, power, or decision threshold that is grossly inconsistent with the statistical plan means either the rationale needs revision or the SAP has a methods problem — diagnose which side has the issue and state it. Be concrete. "The primary endpoint is 28-day hospitalization-free survival, with equipoise supported by two conflicting phase 2 signals and a planned interim safety review after 100 participants" is fine; "the trial has some rationale that may help" 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 doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f7>

<f8>
Keep `SAP.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final state 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 trial operations coordinator: 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 clinical trial protocol, which may be interventional, diagnostic, pragmatic, adaptive, randomized, single-arm, cluster-randomized, or a combination. The original trial concept is given as a natural-language statement in `trial_brief.md`; read it before starting your part.
</f11>

<f12>
The scientific and ethical trial rationale lives in `PROTOCOL_RATIONALE.md`, and you may be invoked on it more than once — the pipeline runs you and the independent scientific and ethics reviewer as a loop, alternating with the statistical analysis loop.

- If `PROTOCOL_RATIONALE.md` does not exist yet, this is the first pass: produce the rationale from scratch based on `trial_brief.md`.
- If `PROTOCOL_RATIONALE.md` already exists, it carries the independent scientific and ethics reviewer's `<review>` block. Read that feedback. Then open `SAP.md` and look at the latest reported design numbers — they may invalidate, sharpen, or motivate revisions to your clinical assumptions, endpoint choices, ethical constraints, or feasibility claims. Revise `PROTOCOL_RATIONALE.md` in place to address every reviewer point raised and to incorporate any statistical evidence that changes your rationale. Don't discard the previous rationale and start over, and don't leave a flagged issue unaddressed.
</f12>

<f13>
Review `SAP.md` against `trial_brief.md` and against `PROTOCOL_RATIONALE.md`.

- Inspect the reported design and analysis results for anomalies, unreasonable sample sizes, unsupported effect sizes, broken type I error control, implausible recruitment assumptions, or endpoint definitions that contradict `trial_brief.md`.
- Open `PROTOCOL_RATIONALE.md`. For every ethical invariant, endpoint hierarchy, feasibility assumption, and clinical claim the rationale makes, write a check into a separate `verify.py`: does the SAP preserve the invariant, use the correct endpoint and population, respect the planned stopping rules, maintain the claimed type I error strategy, and support the stated power or precision? Run it. Name any endpoint, population, threshold, or assumption that violates the rationale.
- Read the SAP and spot-check it for methods bugs — mismatched estimands and analyses, unused stratification factors, contradictory analysis populations, multiplicity gaps, post-randomization exclusions, missing intercurrent-event handling, or sensitivity analyses that do not answer the stated robustness question. A methods flaw that silently biases the estimate is worse than one that is obvious.
- Treat the plan as finished only when every trial requirement holds, every rationale-claimed ethical or design invariant holds, and the operating characteristics are consistent with the rationale's assumptions — not merely when the document is internally polished.
- Check the length of `SAP.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SAP.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. `# trial operations coordinator`). Output only the headered prompts, no preamble.


litigation workflow coordinator
case theory counsel
devil's-advocate legal reviewer
appellate brief drafter
opposing-counsel brief examiner

I need you to set up a 5-agent pipeline for appellate litigation preparation. The team develops a case theory and a draft appellate brief in parallel, with each side informing the other. The case materials arrive as a record-and-issues packet in `record.md`. The pipeline alternates between revising the case theory (standard of review, doctrinal path, preservation, evidentiary fit, and remedies) and revising the draft brief (a filing-ready argument that implements those choices).

The five agents:

- **litigation workflow coordinator** orchestrates the run by alternating one case-theory step with one brief-drafting step and tracking progress. It does no legal analysis, drafting, cite-checking, or reviewing itself.
- **case-theory loop** — the **case theory counsel** writes the litigation theory to `CASE_THEORY.md`; the **devil's-advocate legal reviewer** judges it. The case theory counsel reads `BRIEF.md` on each revision pass to incorporate what the draft reveals about record gaps, weak authorities, and argument feasibility.
- **brief loop** — the **appellate brief drafter** writes the draft appellate brief and supporting citation notes to `BRIEF.md`; the **opposing-counsel brief examiner** judges them. The appellate brief drafter reads `CASE_THEORY.md` on each revision pass to align the brief with the latest strategic theory.

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:

- `record.md` — the original case packet, read-only. All four domain agents read it.
- `CASE_THEORY.md` — the case theory. Case theory counsel writes; devil's-advocate legal reviewer reviews; appellate brief drafter and opposing-counsel brief examiner read it to know which standards, doctrines, preservation positions, and remedies the brief must respect.
- `BRIEF.md` — the draft appellate brief and citation support. Appellate brief drafter writes; opposing-counsel brief examiner reviews; case theory counsel and devil's-advocate legal reviewer read it to ground the theory in actual authorities, record citations, and drafting constraints.

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

Unlike a strategy-then-drafting pipeline where the case theory must settle before the brief starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. The case theory may tighten after the draft exposes a preservation problem or adverse precedent; the brief may change after the theory refines the standard of review, narrows the issue, or changes the requested relief.

I'm providing the following information:

<f1>
Keep `BRIEF.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a compact internal appellate draft; record only the current filing-ready position 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 analyze, draft, cite-check, 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 case theory counsel for the first case-theory step (case theory counsel, then devil's-advocate legal reviewer), then the appellate brief drafter for the first brief step (appellate brief drafter, then opposing-counsel brief examiner).
- **Alternation loop** — alternate one case-theory step with one brief step. Neither side terminates early on its own score; even a perfect-looking theory may need to revise once the draft exposes citation, preservation, or record problems.
- Cap the total at 20 iterations (10 case-theory steps + 10 brief 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 an appellate matter. The case may involve civil, criminal, administrative, constitutional, statutory, or mixed issues. The original case packet is given in `record.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 candid about its own shortcomings — “this argument probably fails, but I am telling you it fails” is still a failing work product, not a passing one.
</f4>

<f5>
Produce the case theory for the appeal and write it to `CASE_THEORY.md`. A complete theory covers four kinds of claim, each justified with record support, controlling authority, or a clear litigation judgment.

- **Issue framing and relief** — identify the appellate issues, the precise ruling or judgment being challenged, the requested disposition, and any fallback relief.
- **Doctrinal path** — state the governing rule, standard of review, burden allocation, elements, exceptions, and any threshold doctrines such as jurisdiction, mootness, waiver, forfeiture, exhaustion, harmless error, or preservation.
- **Record anchors** — identify the facts and procedural events every viable argument must preserve: objections made or not made, transcript pages, trial-court findings, exhibits, agency findings, and judgment language.
- **Risk and response** — identify adverse precedent, bad facts, likely waiver arguments, harmless-error theories, credibility obstacles, and the best answer to each.

Ground your theory against `BRIEF.md` if it has exposed drafting constraints or citation problems. If a theory depends on an authority the brief cannot support, or on a fact the record does not actually contain, the theory needs revision. Be concrete. “Abuse-of-discretion review applies to the evidentiary ruling, but the embedded Rule 702 interpretation is reviewed de novo under Smith v. Jones” is useful; “we have a strong fairness argument” is not.
</f5>

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

<f7>
Match the legal tool to the case structure; do not force an ill-suited one. The list below is useful in appellate case-theory analysis.

| Tool | Suitable for |
|---|---|
| Standard-of-review leverage | Issues where de novo review, clear-error review, abuse-of-discretion review, or substantial-evidence review changes the likelihood of reversal |
| Preservation and waiver analysis | Arguments vulnerable to forfeiture, invited error, exhaustion, failure to object, inadequate briefing, or jurisdictional default |
| Statutory interpretation canons | Textual disputes involving plain meaning, whole-act rule, expressio unius, ejusdem generis, surplusage, constitutional avoidance, or agency deference |
| Constitutional tiers and burden shifting | Equal protection, due process, First Amendment, search-and-seizure, confrontation, or other rights-based appeals |
| Harmless-error and prejudice analysis | Trial error, evidentiary error, instructional error, sentencing error, or administrative procedural error where reversal depends on effect |
| Record-based fact reconstruction | Appeals where transcript chronology, exhibits, findings, objections, or agency record citations determine viability |
| Adverse-precedent distinction | Cases controlled or threatened by unfavorable authority that must be distinguished, limited, preserved for higher review, or candidly confronted |
| Remedy and jurisdiction mapping | Appeals involving finality, appealability, remand scope, vacatur, resentencing, injunctions, mandamus, or administrative remand |
</f7>

<f8>
Read `record.md` and `CASE_THEORY.md`, then draft the appellate brief:

- Include the required appellate components appropriate to the matter: jurisdictional statement, issues presented, statement of the case, statement of facts, summary of argument, argument headings, standard of review, conclusion, and any necessary certificate or addendum notes.
- Make the draft testable against `CASE_THEORY.md`. If the theory depends on de novo review, the brief should state and support that standard. If the theory identifies a preservation point, the brief should cite the record page where it happened. If the theory chooses a fallback remedy, the conclusion should request it.
- Cite controlling authority accurately and use precise record citations. Do not rely on invented cases, vague “see generally” support, or facts not found in `record.md`.
- Read the draft through as if filing it. If an argument contradicts the record, omits an element, misstates the standard of review, or ignores adverse authority, fix the root cause rather than hiding it in a footnote.
- Sanity-check the brief against `CASE_THEORY.md`. A fact that must be preserved should have a record cite; a doctrine the theory says controls should appear in the argument; a requested remedy should match the identified error.

Write the draft brief and its citation notes in `BRIEF.md`.
</f8>

<f9>
Review `BRIEF.md` against `record.md` and against `CASE_THEORY.md`.

- Inspect the draft for anomalies, unsupported factual assertions, unreasonable remedy requests, contradictions with the procedural posture, or arguments that the appellate court cannot reach.
- Open `CASE_THEORY.md`. For every standard of review, preservation claim, doctrinal element, adverse-precedent distinction, and requested remedy the theory claims, create a separate `audit.md`: does the brief support it with authority, pin cites, record citations, and argument text? Name any fact, case, doctrine, or remedy that fails the audit.
- Read the brief closely and spot-check it for legal-drafting bugs — missing elements, miscited authority, record cites that do not support the sentence, arguments that waive better points, or rhetoric that contradicts the selected theory. A subtle misstatement that invites an appellee's waiver or harmless-error response is worse than an obvious typo.
- Treat the draft as finished only when every reachable issue is supported, every theory-claimed record anchor is cited, every doctrinal element is argued, and the requested relief is consistent with the theory — not merely when the document reads smoothly.
- Check the length of `BRIEF.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `BRIEF.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 case theory lives in `CASE_THEORY.md`, and you may be invoked on it more than once — the pipeline runs you and the devil's-advocate legal reviewer as a loop, alternating with the brief loop.

- If `CASE_THEORY.md` does not exist yet, this is the first pass: produce the theory from scratch based on `record.md`.
- If `CASE_THEORY.md` already exists, it carries the devil's-advocate legal reviewer's `<review>` block. Read that feedback. Then open `BRIEF.md` and look at the latest draft, authorities, record citations, and citation notes — they may invalidate, sharpen, or motivate revisions to your theory. Revise `CASE_THEORY.md` in place to address every reviewer point raised and to incorporate any drafting evidence that changes your analysis. Don't discard the previous theory and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
Review `CASE_THEORY.md` against `record.md` and against the draft arguments and citation support reported in `BRIEF.md` (if any).

- **Faithfulness** — does the theory correctly describe the case in `record.md`? Check procedural posture, parties, rulings, issue preservation, facts, record citations, and requested relief.
- **Doctrinal soundness** — for each legal claim, walk through the cited authority or reasoning. Flag unsupported leaps, wrong standards of review, missing elements, jurisdictional defects, or failure to confront controlling adverse precedent.
- **Draft grounding** — open `BRIEF.md`. If the draft cites authorities or record pages, do they support the theory's route to reversal or affirmance? A theory that cannot be translated into a supported brief is not merely “strategic”; it is unstable. Tighten it, or note explicitly that the draft exposes a record or authority problem.

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

<f13>
The draft appellate brief and citation notes live in `BRIEF.md`, and you may be invoked on it more than once — the pipeline runs you and the opposing-counsel brief examiner as a loop, alternating with the case-theory loop.

- If `BRIEF.md` does not exist yet, this is the first pass: produce the brief from scratch based on `record.md`.
- If `BRIEF.md` already exists, it carries the opposing-counsel brief examiner's `<review>` block. Read that feedback. Then open `CASE_THEORY.md` and check whether the latest theory introduces standards of review, preservation positions, adverse-precedent distinctions, record anchors, or remedy choices your current draft does not yet support — for example a changed harmless-error response, a newly identified jurisdictional defect, or a record citation your argument lacks. Revise `BRIEF.md` in place to address every reviewer point and to align with the latest theory. Don't discard the previous draft 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 (litigation workflow coordinator, case theory counsel, devil's-advocate legal reviewer, appellate brief drafter, opposing-counsel brief examiner), which items should go in its prompt? Respond with a JSON object like {"litigation workflow coordinator": ["f?"], "case theory counsel": ["f?"], "devil's-advocate legal reviewer": ["f?"], "appellate brief drafter": ["f?"], "opposing-counsel brief examiner": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline for appellate litigation preparation. The team develops a case theory and a draft appellate brief in parallel, with each side informing the other. The case materials arrive as a record-and-issues packet in `record.md`. The pipeline alternates between revising the case theory (standard of review, doctrinal path, preservation, evidentiary fit, and remedies) and revising the draft brief (a filing-ready argument that implements those choices).

The five agents:

- **litigation workflow coordinator** orchestrates the run by alternating one case-theory step with one brief-drafting step and tracking progress. It does no legal analysis, drafting, cite-checking, or reviewing itself.
- **case-theory loop** — the **case theory counsel** writes the litigation theory to `CASE_THEORY.md`; the **devil's-advocate legal reviewer** judges it. The case theory counsel reads `BRIEF.md` on each revision pass to incorporate what the draft reveals about record gaps, weak authorities, and argument feasibility.
- **brief loop** — the **appellate brief drafter** writes the draft appellate brief and supporting citation notes to `BRIEF.md`; the **opposing-counsel brief examiner** judges them. The appellate brief drafter reads `CASE_THEORY.md` on each revision pass to align the brief with the latest strategic theory.

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:

- `record.md` — the original case packet, read-only. All four domain agents read it.
- `CASE_THEORY.md` — the case theory. Case theory counsel writes; devil's-advocate legal reviewer reviews; appellate brief drafter and opposing-counsel brief examiner read it to know which standards, doctrines, preservation positions, and remedies the brief must respect.
- `BRIEF.md` — the draft appellate brief and citation support. Appellate brief drafter writes; opposing-counsel brief examiner reviews; case theory counsel and devil's-advocate legal reviewer read it to ground the theory in actual authorities, record citations, and drafting constraints.

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

Unlike a strategy-then-drafting pipeline where the case theory must settle before the brief starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. The case theory may tighten after the draft exposes a preservation problem or adverse precedent; the brief may change after the theory refines the standard of review, narrows the issue, or changes the requested relief.

I'm providing the following prompt fragments:

<f1>
Keep `BRIEF.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a compact internal appellate draft; record only the current filing-ready position 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 analyze, draft, cite-check, 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 case theory counsel for the first case-theory step (case theory counsel, then devil's-advocate legal reviewer), then the appellate brief drafter for the first brief step (appellate brief drafter, then opposing-counsel brief examiner).
- **Alternation loop** — alternate one case-theory step with one brief step. Neither side terminates early on its own score; even a perfect-looking theory may need to revise once the draft exposes citation, preservation, or record problems.
- Cap the total at 20 iterations (10 case-theory steps + 10 brief 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 an appellate matter. The case may involve civil, criminal, administrative, constitutional, statutory, or mixed issues. The original case packet is given in `record.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 candid about its own shortcomings — “this argument probably fails, but I am telling you it fails” is still a failing work product, not a passing one.
</f4>

<f5>
Produce the case theory for the appeal and write it to `CASE_THEORY.md`. A complete theory covers four kinds of claim, each justified with record support, controlling authority, or a clear litigation judgment.

- **Issue framing and relief** — identify the appellate issues, the precise ruling or judgment being challenged, the requested disposition, and any fallback relief.
- **Doctrinal path** — state the governing rule, standard of review, burden allocation, elements, exceptions, and any threshold doctrines such as jurisdiction, mootness, waiver, forfeiture, exhaustion, harmless error, or preservation.
- **Record anchors** — identify the facts and procedural events every viable argument must preserve: objections made or not made, transcript pages, trial-court findings, exhibits, agency findings, and judgment language.
- **Risk and response** — identify adverse precedent, bad facts, likely waiver arguments, harmless-error theories, credibility obstacles, and the best answer to each.

Ground your theory against `BRIEF.md` if it has exposed drafting constraints or citation problems. If a theory depends on an authority the brief cannot support, or on a fact the record does not actually contain, the theory needs revision. Be concrete. “Abuse-of-discretion review applies to the evidentiary ruling, but the embedded Rule 702 interpretation is reviewed de novo under Smith v. Jones” is useful; “we have a strong fairness argument” is not.
</f5>

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

<f7>
Match the legal tool to the case structure; do not force an ill-suited one. The list below is useful in appellate case-theory analysis.

| Tool | Suitable for |
|---|---|
| Standard-of-review leverage | Issues where de novo review, clear-error review, abuse-of-discretion review, or substantial-evidence review changes the likelihood of reversal |
| Preservation and waiver analysis | Arguments vulnerable to forfeiture, invited error, exhaustion, failure to object, inadequate briefing, or jurisdictional default |
| Statutory interpretation canons | Textual disputes involving plain meaning, whole-act rule, expressio unius, ejusdem generis, surplusage, constitutional avoidance, or agency deference |
| Constitutional tiers and burden shifting | Equal protection, due process, First Amendment, search-and-seizure, confrontation, or other rights-based appeals |
| Harmless-error and prejudice analysis | Trial error, evidentiary error, instructional error, sentencing error, or administrative procedural error where reversal depends on effect |
| Record-based fact reconstruction | Appeals where transcript chronology, exhibits, findings, objections, or agency record citations determine viability |
| Adverse-precedent distinction | Cases controlled or threatened by unfavorable authority that must be distinguished, limited, preserved for higher review, or candidly confronted |
| Remedy and jurisdiction mapping | Appeals involving finality, appealability, remand scope, vacatur, resentencing, injunctions, mandamus, or administrative remand |
</f7>

<f8>
Read `record.md` and `CASE_THEORY.md`, then draft the appellate brief:

- Include the required appellate components appropriate to the matter: jurisdictional statement, issues presented, statement of the case, statement of facts, summary of argument, argument headings, standard of review, conclusion, and any necessary certificate or addendum notes.
- Make the draft testable against `CASE_THEORY.md`. If the theory depends on de novo review, the brief should state and support that standard. If the theory identifies a preservation point, the brief should cite the record page where it happened. If the theory chooses a fallback remedy, the conclusion should request it.
- Cite controlling authority accurately and use precise record citations. Do not rely on invented cases, vague “see generally” support, or facts not found in `record.md`.
- Read the draft through as if filing it. If an argument contradicts the record, omits an element, misstates the standard of review, or ignores adverse authority, fix the root cause rather than hiding it in a footnote.
- Sanity-check the brief against `CASE_THEORY.md`. A fact that must be preserved should have a record cite; a doctrine the theory says controls should appear in the argument; a requested remedy should match the identified error.

Write the draft brief and its citation notes in `BRIEF.md`.
</f8>

<f9>
Review `BRIEF.md` against `record.md` and against `CASE_THEORY.md`.

- Inspect the draft for anomalies, unsupported factual assertions, unreasonable remedy requests, contradictions with the procedural posture, or arguments that the appellate court cannot reach.
- Open `CASE_THEORY.md`. For every standard of review, preservation claim, doctrinal element, adverse-precedent distinction, and requested remedy the theory claims, create a separate `audit.md`: does the brief support it with authority, pin cites, record citations, and argument text? Name any fact, case, doctrine, or remedy that fails the audit.
- Read the brief closely and spot-check it for legal-drafting bugs — missing elements, miscited authority, record cites that do not support the sentence, arguments that waive better points, or rhetoric that contradicts the selected theory. A subtle misstatement that invites an appellee's waiver or harmless-error response is worse than an obvious typo.
- Treat the draft as finished only when every reachable issue is supported, every theory-claimed record anchor is cited, every doctrinal element is argued, and the requested relief is consistent with the theory — not merely when the document reads smoothly.
- Check the length of `BRIEF.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `BRIEF.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 case theory lives in `CASE_THEORY.md`, and you may be invoked on it more than once — the pipeline runs you and the devil's-advocate legal reviewer as a loop, alternating with the brief loop.

- If `CASE_THEORY.md` does not exist yet, this is the first pass: produce the theory from scratch based on `record.md`.
- If `CASE_THEORY.md` already exists, it carries the devil's-advocate legal reviewer's `<review>` block. Read that feedback. Then open `BRIEF.md` and look at the latest draft, authorities, record citations, and citation notes — they may invalidate, sharpen, or motivate revisions to your theory. Revise `CASE_THEORY.md` in place to address every reviewer point raised and to incorporate any drafting evidence that changes your analysis. Don't discard the previous theory and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
Review `CASE_THEORY.md` against `record.md` and against the draft arguments and citation support reported in `BRIEF.md` (if any).

- **Faithfulness** — does the theory correctly describe the case in `record.md`? Check procedural posture, parties, rulings, issue preservation, facts, record citations, and requested relief.
- **Doctrinal soundness** — for each legal claim, walk through the cited authority or reasoning. Flag unsupported leaps, wrong standards of review, missing elements, jurisdictional defects, or failure to confront controlling adverse precedent.
- **Draft grounding** — open `BRIEF.md`. If the draft cites authorities or record pages, do they support the theory's route to reversal or affirmance? A theory that cannot be translated into a supported brief is not merely “strategic”; it is unstable. Tighten it, or note explicitly that the draft exposes a record or authority problem.

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

<f13>
The draft appellate brief and citation notes live in `BRIEF.md`, and you may be invoked on it more than once — the pipeline runs you and the opposing-counsel brief examiner as a loop, alternating with the case-theory loop.

- If `BRIEF.md` does not exist yet, this is the first pass: produce the brief from scratch based on `record.md`.
- If `BRIEF.md` already exists, it carries the opposing-counsel brief examiner's `<review>` block. Read that feedback. Then open `CASE_THEORY.md` and check whether the latest theory introduces standards of review, preservation positions, adverse-precedent distinctions, record anchors, or remedy choices your current draft does not yet support — for example a changed harmless-error response, a newly identified jurisdictional defect, or a record citation your argument lacks. Revise `BRIEF.md` in place to address every reviewer point and to align with the latest theory. Don't discard the previous draft 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. `# litigation workflow coordinator`). Output only the headered prompts, no preamble.