I need you to set up a 5-agent pipeline for civil appellate litigation support. A matter arrives as a trial record excerpt and issue statement in `record.md`, and the pipeline turns it into a vetted appellate theory and then a polished, record-supported appellate brief.

The five agents:

- **docket coordinator** orchestrates the run: it drives the theory loop, then the brief loop, and tracks progress. It does no legal analysis, drafting, or reviewing itself.
- **theory loop** — the **appellate strategist** turns the record and issue statement into a coherent appellate theory and briefing strategy; the **red-team appellate counsel** challenges it. They iterate until the theory is sound.
- **brief loop** — the **brief drafter** writes the brief from the vetted theory; the **opposing-counsel brief reviewer** reviews the brief as a hostile reader would. They iterate until the brief is accurate, persuasive, and court-ready.

The pipeline hands work off through three files:

- `record.md` — the trial record excerpt, procedural posture, and issue statement, given as input. All four legal-domain agents read it.
- `THEORY.md` — the appellate theory. The appellate strategist writes it; the red-team appellate counsel reviews it; the brief drafter reads it to draft the brief.
- `BRIEF.md` — the polished appellate brief. The brief drafter writes it; the opposing-counsel brief reviewer reviews it.

Each critic records its score as a `<review score=X>` block inside the file it reviewed, and the docket coordinator reads those scores to drive the loops.

I'm providing the following information:

<f1>
Keep `BRIEF.md` lean and court-ready. Its body — everything except the `<review>` block — must stay under 6000 words (~40KB), roughly the length of a focused principal brief or substantial motion brief; move drafting history, abandoned arguments, and research notes into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
Which appellate route suits which kind of issue — use it to choose the strategy:

- **Pure legal error** — best when the issue is preserved and turns on statutory interpretation, contract interpretation, rule construction, or another question reviewed de novo.
- **Summary judgment or dismissal error** — strong when the record can be framed in the nonmovant's favor and the trial court applied the wrong legal rule or ignored a genuine dispute.
- **Evidentiary or trial-management error** — viable when the ruling was preserved, the standard is abuse of discretion, and the excluded or admitted evidence probably affected the outcome.
- **Jury-instruction error** — useful when the requested instruction correctly stated the law, was supported by the evidence, was refused or misstated, and prejudice can be shown.
- **Sufficiency or weight-of-the-evidence challenge** — difficult on appeal; use only when the record is unusually one-sided or the governing burden of proof creates a clear legal defect.
- **Procedural due process or notice defect** — strong when the record shows lack of notice, denial of a meaningful opportunity to be heard, or a ruling outside the issues actually litigated.
- **Preservation-limited fallback** — use only when the best issue was not cleanly preserved; address forfeiture, plain-error or fundamental-error doctrine if available, and harmless-error risk.

Match the appellate route to the record, the issue, and the standard of review; do not force an argument that the appellate court is unlikely to reach or accept.
</f2>

<f3>
The appellate brief lives in `BRIEF.md`, and you may be invoked on it more than once — the pipeline runs you and the opposing-counsel brief reviewer as a loop.

- If `BRIEF.md` does not exist yet, this is the first pass: produce the brief from scratch.
- If `BRIEF.md` already exists, it carries the opposing-counsel brief reviewer's `<review>` block: read that feedback and revise `BRIEF.md` in place to address every point raised. Don't discard the brief and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review the theory in `THEORY.md`:

- **Appellate analysis** — does it faithfully capture the record and issue statement? Check that the appeal posture, issues presented, standards of review, material facts, governing law, error theory, preservation, prejudice, and remedy are accurate.
- **Strategy** — is the chosen appellate route a sound fit, is it actually briefable from this record, and is it likely to give the appellant the best chance of relief?

Be brief and specific. Do not draft the brief yourself — only review the theory.
</f4>

<f5>
Review `BRIEF.md` — the appellate brief and its supporting citations. Verify it directly against the trial record and issue statement.

- Inspect the argument for anomalies, overstatements, waived issues, unsupported standards of review, unreasonable remedies, or factual assertions that the record does not support.
- Write a separate `cite_check.md` that re-checks every material factual assertion and record citation against `record.md`; name any assertion that lacks support or misstates the cited material.
- Read the brief closely and spot-check it for legal and drafting defects — missing authorities, dead arguments, contradictory positions, abandoned preservation problems, or language that promises more than the record can deliver. A subtle misstatement that invites reversal or sanctions is worse than an obvious typo.
- Treat the brief as finished only when the record support is accurate, the legal theory is coherent, and the requested relief is sound — not merely when the document reads smoothly.
- Check the length of `BRIEF.md`: if it exceeds 40KB, 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.
</f5>

<f6>
Read the theory in `THEORY.md` and draft the appellate brief from it:

- Include all core sections needed for a polished civil appellate brief: caption placeholder if needed, table-ready headings, issue presented, statement of the case, statement of facts, summary of argument, argument, and conclusion.
- Use the chosen theory exactly: frame the issue, state the standard of review, marshal the record facts, cite controlling authority, answer the likely appellee arguments, and request the specified relief.
- Support every material factual assertion with a record citation from `record.md`. Do not invent facts, procedural events, quotations, objections, rulings, or citations.
- Check the brief yourself from start to finish. Fix missing record cites, unsupported legal propositions, internal contradictions, and placeholders. Do not leave TODOs, bracketed guesses, or uncited assertions for someone else.
- Sanity-check the requested relief: it must match the appellate posture and the error theory.

Write the brief in `BRIEF.md`.
</f6>

<f7>
You orchestrate the run; you never analyze the appeal, draft the brief, or review the work yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the appellate strategist to draft the theory.
- **Theory loop** — have the appellate strategist and red-team appellate counsel iterate on the appellate theory and strategy until the red-team appellate counsel scores the theory 10.
- **Brief loop** — once the theory is settled, have the brief drafter and opposing-counsel brief reviewer iterate on the brief until the opposing-counsel brief reviewer scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f7>

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

<f9>
Produce the appellate theory and briefing strategy for the matter and write it to `THEORY.md`. A complete theory has two parts — a formalized appellate analysis and one chosen briefing strategy.

The **analysis** must state:

- **Appeal posture** — final judgment or appealable order, court, parties, and the relief sought on appeal.
- **Issues presented** — the exact questions the appellate court should decide, framed in a way that fits the record.
- **Standard of review** — the governing standard for each issue, with any preservation or harmless-error implications.
- **Material record facts** — the key facts, rulings, objections, motions, and record citations that matter to the appeal.
- **Governing law** — the controlling statutes, rules, and precedent needed for the argument.
- **Theory of error** — precisely what the trial court or opposing party did wrong, why it matters, and how it affected the judgment.
- **Remedy** — reversal, vacatur, remand instructions, modification, new trial, or other specific relief.

The **strategy** — weigh the options and commit to the single most promising route — must state:

- which issue should lead and which arguments should be omitted or subordinated;
- how the standard of review will be handled;
- the core precedent and record facts the argument will rely on;
- the anticipated appellee response and the best answer to it;
- the biggest risk in this appellate route.
</f9>

<f10>
You are working on a civil appeal. The trial record excerpt, procedural posture, judgment or order being appealed, and issue statement are provided in `record.md`; read it before starting your part.
</f10>

<f11>
The appellate theory lives in `THEORY.md`, and you may be invoked on it more than once — the pipeline runs you and the red-team appellate counsel as a loop.

- If `THEORY.md` does not exist yet, this is the first pass: produce the theory from scratch.
- If `THEORY.md` already exists, it carries the red-team appellate counsel's `<review>` block: read that feedback and revise `THEORY.md` in place to address every point raised. Don't discard the theory and start over, and don't leave a flagged issue unaddressed.
</f11>

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

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

I need you to set up a 5-agent pipeline for civil appellate litigation support. A matter arrives as a trial record excerpt and issue statement in `record.md`, and the pipeline turns it into a vetted appellate theory and then a polished, record-supported appellate brief.

The five agents:

- **docket coordinator** orchestrates the run: it drives the theory loop, then the brief loop, and tracks progress. It does no legal analysis, drafting, or reviewing itself.
- **theory loop** — the **appellate strategist** turns the record and issue statement into a coherent appellate theory and briefing strategy; the **red-team appellate counsel** challenges it. They iterate until the theory is sound.
- **brief loop** — the **brief drafter** writes the brief from the vetted theory; the **opposing-counsel brief reviewer** reviews the brief as a hostile reader would. They iterate until the brief is accurate, persuasive, and court-ready.

The pipeline hands work off through three files:

- `record.md` — the trial record excerpt, procedural posture, and issue statement, given as input. All four legal-domain agents read it.
- `THEORY.md` — the appellate theory. The appellate strategist writes it; the red-team appellate counsel reviews it; the brief drafter reads it to draft the brief.
- `BRIEF.md` — the polished appellate brief. The brief drafter writes it; the opposing-counsel brief reviewer reviews it.

Each critic records its score as a `<review score=X>` block inside the file it reviewed, and the docket coordinator reads those scores to drive the loops.

I'm providing the following prompt fragments:

<f1>
Keep `BRIEF.md` lean and court-ready. Its body — everything except the `<review>` block — must stay under 6000 words (~40KB), roughly the length of a focused principal brief or substantial motion brief; move drafting history, abandoned arguments, and research notes into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
Which appellate route suits which kind of issue — use it to choose the strategy:

- **Pure legal error** — best when the issue is preserved and turns on statutory interpretation, contract interpretation, rule construction, or another question reviewed de novo.
- **Summary judgment or dismissal error** — strong when the record can be framed in the nonmovant's favor and the trial court applied the wrong legal rule or ignored a genuine dispute.
- **Evidentiary or trial-management error** — viable when the ruling was preserved, the standard is abuse of discretion, and the excluded or admitted evidence probably affected the outcome.
- **Jury-instruction error** — useful when the requested instruction correctly stated the law, was supported by the evidence, was refused or misstated, and prejudice can be shown.
- **Sufficiency or weight-of-the-evidence challenge** — difficult on appeal; use only when the record is unusually one-sided or the governing burden of proof creates a clear legal defect.
- **Procedural due process or notice defect** — strong when the record shows lack of notice, denial of a meaningful opportunity to be heard, or a ruling outside the issues actually litigated.
- **Preservation-limited fallback** — use only when the best issue was not cleanly preserved; address forfeiture, plain-error or fundamental-error doctrine if available, and harmless-error risk.

Match the appellate route to the record, the issue, and the standard of review; do not force an argument that the appellate court is unlikely to reach or accept.
</f2>

<f3>
The appellate brief lives in `BRIEF.md`, and you may be invoked on it more than once — the pipeline runs you and the opposing-counsel brief reviewer as a loop.

- If `BRIEF.md` does not exist yet, this is the first pass: produce the brief from scratch.
- If `BRIEF.md` already exists, it carries the opposing-counsel brief reviewer's `<review>` block: read that feedback and revise `BRIEF.md` in place to address every point raised. Don't discard the brief and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review the theory in `THEORY.md`:

- **Appellate analysis** — does it faithfully capture the record and issue statement? Check that the appeal posture, issues presented, standards of review, material facts, governing law, error theory, preservation, prejudice, and remedy are accurate.
- **Strategy** — is the chosen appellate route a sound fit, is it actually briefable from this record, and is it likely to give the appellant the best chance of relief?

Be brief and specific. Do not draft the brief yourself — only review the theory.
</f4>

<f5>
Review `BRIEF.md` — the appellate brief and its supporting citations. Verify it directly against the trial record and issue statement.

- Inspect the argument for anomalies, overstatements, waived issues, unsupported standards of review, unreasonable remedies, or factual assertions that the record does not support.
- Write a separate `cite_check.md` that re-checks every material factual assertion and record citation against `record.md`; name any assertion that lacks support or misstates the cited material.
- Read the brief closely and spot-check it for legal and drafting defects — missing authorities, dead arguments, contradictory positions, abandoned preservation problems, or language that promises more than the record can deliver. A subtle misstatement that invites reversal or sanctions is worse than an obvious typo.
- Treat the brief as finished only when the record support is accurate, the legal theory is coherent, and the requested relief is sound — not merely when the document reads smoothly.
- Check the length of `BRIEF.md`: if it exceeds 40KB, 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.
</f5>

<f6>
Read the theory in `THEORY.md` and draft the appellate brief from it:

- Include all core sections needed for a polished civil appellate brief: caption placeholder if needed, table-ready headings, issue presented, statement of the case, statement of facts, summary of argument, argument, and conclusion.
- Use the chosen theory exactly: frame the issue, state the standard of review, marshal the record facts, cite controlling authority, answer the likely appellee arguments, and request the specified relief.
- Support every material factual assertion with a record citation from `record.md`. Do not invent facts, procedural events, quotations, objections, rulings, or citations.
- Check the brief yourself from start to finish. Fix missing record cites, unsupported legal propositions, internal contradictions, and placeholders. Do not leave TODOs, bracketed guesses, or uncited assertions for someone else.
- Sanity-check the requested relief: it must match the appellate posture and the error theory.

Write the brief in `BRIEF.md`.
</f6>

<f7>
You orchestrate the run; you never analyze the appeal, draft the brief, or review the work yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the appellate strategist to draft the theory.
- **Theory loop** — have the appellate strategist and red-team appellate counsel iterate on the appellate theory and strategy until the red-team appellate counsel scores the theory 10.
- **Brief loop** — once the theory is settled, have the brief drafter and opposing-counsel brief reviewer iterate on the brief until the opposing-counsel brief reviewer scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f7>

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

<f9>
Produce the appellate theory and briefing strategy for the matter and write it to `THEORY.md`. A complete theory has two parts — a formalized appellate analysis and one chosen briefing strategy.

The **analysis** must state:

- **Appeal posture** — final judgment or appealable order, court, parties, and the relief sought on appeal.
- **Issues presented** — the exact questions the appellate court should decide, framed in a way that fits the record.
- **Standard of review** — the governing standard for each issue, with any preservation or harmless-error implications.
- **Material record facts** — the key facts, rulings, objections, motions, and record citations that matter to the appeal.
- **Governing law** — the controlling statutes, rules, and precedent needed for the argument.
- **Theory of error** — precisely what the trial court or opposing party did wrong, why it matters, and how it affected the judgment.
- **Remedy** — reversal, vacatur, remand instructions, modification, new trial, or other specific relief.

The **strategy** — weigh the options and commit to the single most promising route — must state:

- which issue should lead and which arguments should be omitted or subordinated;
- how the standard of review will be handled;
- the core precedent and record facts the argument will rely on;
- the anticipated appellee response and the best answer to it;
- the biggest risk in this appellate route.
</f9>

<f10>
You are working on a civil appeal. The trial record excerpt, procedural posture, judgment or order being appealed, and issue statement are provided in `record.md`; read it before starting your part.
</f10>

<f11>
The appellate theory lives in `THEORY.md`, and you may be invoked on it more than once — the pipeline runs you and the red-team appellate counsel as a loop.

- If `THEORY.md` does not exist yet, this is the first pass: produce the theory from scratch.
- If `THEORY.md` already exists, it carries the red-team appellate counsel's `<review>` block: read that feedback and revise `THEORY.md` in place to address every point raised. Don't discard the theory and start over, and don't leave a flagged issue unaddressed.
</f11>

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

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


care-coordination lead
diagnostic consultant
diagnostic safety reviewer
care-plan author
clinical chart auditor

I need you to set up a 5-agent hospital second-opinion workflow that turns a patient presentation into a defensible differential diagnosis and workup strategy, then into a reviewed care-plan note. A case arrives as a clinical presentation in `patient.md`, and the workflow produces a vetted diagnostic plan and then a practical care-plan note that has been checked for missed dangerous diagnoses and contraindications.

The five agents:

- **care-coordination lead** orchestrates the run: it drives the diagnostic loop, then the care-plan loop, and tracks progress. It does no diagnosis, care-plan writing, or auditing itself.
- **diagnostic loop** — the **diagnostic consultant** turns the presentation into a prioritized differential diagnosis and workup strategy; the **diagnostic safety reviewer** reviews it. They iterate until the differential and workup are safe and defensible.
- **care-plan loop** — the **care-plan author** converts the settled diagnostic strategy into a clinical care-plan note; the **clinical chart auditor** reviews the note for safety, consistency, and result. They iterate until the care plan is clinically sound.

The workflow hands work off through three files:

- `patient.md` — the original patient presentation, given as input. All four clinical agents (diagnostic consultant, diagnostic safety reviewer, care-plan author, clinical chart auditor) read it.
- `DIFFERENTIAL.md` — the diagnostic plan. The diagnostic consultant writes it; the diagnostic safety reviewer reviews it; the care-plan author reads it to write the care plan.
- `CARE_PLAN.md` — the care-plan note and its rationale. The care-plan author writes it; the clinical chart auditor reviews it.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, and the care-coordination lead reads those scores to drive the loops.

I'm providing the following information:

<f1>
Keep `CARE_PLAN.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 diagnose, write the care plan, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the diagnostic consultant to draft the diagnostic plan.
- **Diagnostic loop** — have the diagnostic consultant and diagnostic safety reviewer iterate on the differential and workup strategy until the diagnostic safety reviewer scores the plan 10.
- **Care-plan loop** — once the diagnostic plan is settled, have the care-plan author and clinical chart auditor iterate on the care-plan note until the clinical chart auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the reviewer's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a hospital diagnostic second-opinion case. The original presentation is given as a clinical note in `patient.md`; read it before starting your part. Treat the note as the source of truth for the patient's symptoms, exam findings, vitals, labs, imaging, medications, allergies, comorbidities, and care setting.
</f3>

<f4>
Review the diagnostic plan in `DIFFERENTIAL.md`:

- **Clinical model** — does it faithfully capture the patient presentation? Check that the syndrome, acuity, key data, prioritized differential, leading concern, and safety constraints are accurate.
- **Workup strategy** — are the chosen tests, monitoring, consults, decision thresholds, and empiric precautions a sound fit, are they actually implementable in the stated care setting, and are they likely to reach a safe diagnosis?

Be brief and specific. Do not write the care-plan note yourself — only review.
</f4>

<f5>
Which diagnostic approach suits which kind of presentation — use it to choose a safe strategy:

- **Chest pain / possible acute coronary syndrome** — immediate ECG, serial high-sensitivity troponins, risk stratification, and evaluation for alternate killers such as aortic dissection, pulmonary embolism, tension pneumothorax, and esophageal rupture.
- **Focal neurologic deficit / possible stroke** — last-known-well time, glucose check, noncontrast head CT, vascular imaging when indicated, thrombolysis/thrombectomy eligibility, and stroke mimic screen.
- **Dyspnea / hypoxemia** — pulse oximetry trend, chest imaging, ECG, blood gas when needed, BNP/troponin if cardiac cause is plausible, PE risk stratification, and early escalation for respiratory failure.
- **Fever / possible sepsis** — source search, cultures before antibiotics when this does not delay care, lactate, organ dysfunction assessment, early fluids when appropriate, and prompt empiric antimicrobials tailored to source and host risks.
- **Abdominal pain** — pregnancy test when applicable, targeted labs, imaging matched to location and acuity, surgical red-flag screen, and attention to vascular catastrophes in high-risk patients.
- **Syncope / transient loss of consciousness** — orthostatic vitals, ECG, arrhythmia and structural-heart risk assessment, medication review, bleeding screen, and neurologic evaluation only when supported by focal findings.
- **Altered mental status** — glucose, oxygenation, medication/toxin review, infection/metabolic evaluation, neurologic assessment, and rapid treatment of reversible threats.
- **Medication or treatment planning with comorbidities** — check allergies, renal function, hepatic function, QT risk, pregnancy/lactation, anticoagulation, immunosuppression, and drug interactions before recommending therapy.

Match the workup to the clinical syndrome and acuity; do not force a pathway that does not fit the presentation.
</f5>

<f6>
Read the diagnostic plan in `DIFFERENTIAL.md` and implement its strategy as a care-plan note:

- Include the relevant diagnoses or problems, the prioritized differential, ordered or recommended tests, monitoring, consults, empiric treatments if appropriate, disposition criteria, and follow-up actions. Make each recommendation traceable to the patient data and the diagnostic plan.
- Check each medication, test, and procedure against the patient's allergies, comorbidities, pregnancy status if relevant, renal/hepatic function, anticoagulation status, and documented goals of care. Do not hide contraindications or uncertainty.
- Complete the plan yourself and carry it through to a coherent final note — do not stop with placeholders such as “consult team to decide” unless the consult is itself the appropriate next step. If a recommendation conflicts with the patient data, find and fix the root cause.
- Sanity-check the plan: a patient who is unstable should not be assigned routine outpatient follow-up only; a contraindicated medication should not be recommended; a dangerous diagnosis raised in the differential should have an explicit rule-out or mitigation step.

Write the care-plan note and its rationale up in `CARE_PLAN.md`.
</f6>

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

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

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

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

<f8>
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 is unsafe, but I'm telling you it is unsafe" is still a failing result, not a passing one.
</f8>

<f9>
Produce the diagnostic plan for the case and write it to `DIFFERENTIAL.md`. A complete plan has two parts — a formalized clinical problem representation and one chosen workup strategy.

The **problem representation** must state:

- **Clinical syndrome and acuity** — the leading syndrome, severity, time course, and whether the patient appears stable, urgent, or emergent.
- **Key data** — the critical positives and negatives from the history, exam, vitals, labs, imaging, medications, allergies, pregnancy/immunocompromised status if relevant, and risk factors.
- **Prioritized differential diagnosis** — likely diagnoses and dangerous diagnoses that must not be missed, with brief reasoning for and against each.
- **Working diagnosis or leading concern** — the current best explanation, if one can be chosen, and the uncertainty that remains.
- **Constraints and safety boundaries** — comorbidities, contraindications, renal/hepatic limitations, allergy issues, infection-control needs, disposition limits, and red flags that must change management.

The **workup strategy** — weigh the options and commit to the single most defensible route — must state:

- which tests, monitoring steps, consults, and empiric precautions to use, and when to use them;
- the diagnostic algorithm and its key decision thresholds;
- the clinical reasoning or risk-stratification tool the route relies on;
- the biggest risk on this route, including the most important diagnosis that could be missed.
</f9>

<f10>
The diagnostic plan lives in `DIFFERENTIAL.md`, and you may be invoked on it more than once — the workflow runs you and the diagnostic safety reviewer as a loop.

- If `DIFFERENTIAL.md` does not exist yet, this is the first pass: produce the diagnostic plan from scratch.
- If `DIFFERENTIAL.md` already exists, it carries the diagnostic safety reviewer's `<review>` block: read that feedback and revise `DIFFERENTIAL.md` in place to address every point raised. Don't discard the plan and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `CARE_PLAN.md` — the care-plan note and its rationale. Verify it directly against the patient presentation.

- Inspect the reported assessment and plan for anomalies, unreasonable disposition choices, unsafe medication recommendations, omitted monitoring, or contradictions with the patient's vitals, labs, allergies, comorbidities, and goals of care.
- Write a separate `SAFETY_CHECK.md` that re-checks every major recommendation against the reported patient facts and the differential diagnosis, and complete it; name any diagnoses, contraindications, or risk factors that the care plan fails to address.
- Read the care-plan note and spot-check it for clinical bugs — copied-forward data that do not match `patient.md`, unused or ignored abnormal results, dead-end recommendations, or logic that contradicts what the plan says it is trying to do. A flaw that silently makes the plan unsafe is worse than one that is obvious.
- Treat the result as finished only when the dangerous diagnoses have been considered, the recommended workup is appropriate, contraindications have been checked, and the disposition is sound — not merely when the note is well written.
- Check the length of `CARE_PLAN.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `CARE_PLAN.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The care-plan note and its rationale live in `CARE_PLAN.md`, and you may be invoked on it more than once — the workflow runs you and the clinical chart auditor as a loop.

- If `CARE_PLAN.md` does not exist yet, this is the first pass: produce the care-plan note from scratch.
- If `CARE_PLAN.md` already exists, it carries the clinical chart auditor's `<review>` block: read that feedback and revise `CARE_PLAN.md` in place to address every point raised. Don't discard the care plan and start over, and don't leave a flagged issue unaddressed.
</f12>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (care-coordination lead, diagnostic consultant, diagnostic safety reviewer, care-plan author, clinical chart auditor), which items should go in its prompt? Respond with a JSON object like {"care-coordination lead": ["f?"], "diagnostic consultant": ["f?"], "diagnostic safety reviewer": ["f?"], "care-plan author": ["f?"], "clinical chart auditor": ["f?"]}. No other output.

I need you to set up a 5-agent hospital second-opinion workflow that turns a patient presentation into a defensible differential diagnosis and workup strategy, then into a reviewed care-plan note. A case arrives as a clinical presentation in `patient.md`, and the workflow produces a vetted diagnostic plan and then a practical care-plan note that has been checked for missed dangerous diagnoses and contraindications.

The five agents:

- **care-coordination lead** orchestrates the run: it drives the diagnostic loop, then the care-plan loop, and tracks progress. It does no diagnosis, care-plan writing, or auditing itself.
- **diagnostic loop** — the **diagnostic consultant** turns the presentation into a prioritized differential diagnosis and workup strategy; the **diagnostic safety reviewer** reviews it. They iterate until the differential and workup are safe and defensible.
- **care-plan loop** — the **care-plan author** converts the settled diagnostic strategy into a clinical care-plan note; the **clinical chart auditor** reviews the note for safety, consistency, and result. They iterate until the care plan is clinically sound.

The workflow hands work off through three files:

- `patient.md` — the original patient presentation, given as input. All four clinical agents (diagnostic consultant, diagnostic safety reviewer, care-plan author, clinical chart auditor) read it.
- `DIFFERENTIAL.md` — the diagnostic plan. The diagnostic consultant writes it; the diagnostic safety reviewer reviews it; the care-plan author reads it to write the care plan.
- `CARE_PLAN.md` — the care-plan note and its rationale. The care-plan author writes it; the clinical chart auditor reviews it.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, and the care-coordination lead reads those scores to drive the loops.

I'm providing the following prompt fragments:

<f1>
Keep `CARE_PLAN.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 diagnose, write the care plan, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the diagnostic consultant to draft the diagnostic plan.
- **Diagnostic loop** — have the diagnostic consultant and diagnostic safety reviewer iterate on the differential and workup strategy until the diagnostic safety reviewer scores the plan 10.
- **Care-plan loop** — once the diagnostic plan is settled, have the care-plan author and clinical chart auditor iterate on the care-plan note until the clinical chart auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the reviewer's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a hospital diagnostic second-opinion case. The original presentation is given as a clinical note in `patient.md`; read it before starting your part. Treat the note as the source of truth for the patient's symptoms, exam findings, vitals, labs, imaging, medications, allergies, comorbidities, and care setting.
</f3>

<f4>
Review the diagnostic plan in `DIFFERENTIAL.md`:

- **Clinical model** — does it faithfully capture the patient presentation? Check that the syndrome, acuity, key data, prioritized differential, leading concern, and safety constraints are accurate.
- **Workup strategy** — are the chosen tests, monitoring, consults, decision thresholds, and empiric precautions a sound fit, are they actually implementable in the stated care setting, and are they likely to reach a safe diagnosis?

Be brief and specific. Do not write the care-plan note yourself — only review.
</f4>

<f5>
Which diagnostic approach suits which kind of presentation — use it to choose a safe strategy:

- **Chest pain / possible acute coronary syndrome** — immediate ECG, serial high-sensitivity troponins, risk stratification, and evaluation for alternate killers such as aortic dissection, pulmonary embolism, tension pneumothorax, and esophageal rupture.
- **Focal neurologic deficit / possible stroke** — last-known-well time, glucose check, noncontrast head CT, vascular imaging when indicated, thrombolysis/thrombectomy eligibility, and stroke mimic screen.
- **Dyspnea / hypoxemia** — pulse oximetry trend, chest imaging, ECG, blood gas when needed, BNP/troponin if cardiac cause is plausible, PE risk stratification, and early escalation for respiratory failure.
- **Fever / possible sepsis** — source search, cultures before antibiotics when this does not delay care, lactate, organ dysfunction assessment, early fluids when appropriate, and prompt empiric antimicrobials tailored to source and host risks.
- **Abdominal pain** — pregnancy test when applicable, targeted labs, imaging matched to location and acuity, surgical red-flag screen, and attention to vascular catastrophes in high-risk patients.
- **Syncope / transient loss of consciousness** — orthostatic vitals, ECG, arrhythmia and structural-heart risk assessment, medication review, bleeding screen, and neurologic evaluation only when supported by focal findings.
- **Altered mental status** — glucose, oxygenation, medication/toxin review, infection/metabolic evaluation, neurologic assessment, and rapid treatment of reversible threats.
- **Medication or treatment planning with comorbidities** — check allergies, renal function, hepatic function, QT risk, pregnancy/lactation, anticoagulation, immunosuppression, and drug interactions before recommending therapy.

Match the workup to the clinical syndrome and acuity; do not force a pathway that does not fit the presentation.
</f5>

<f6>
Read the diagnostic plan in `DIFFERENTIAL.md` and implement its strategy as a care-plan note:

- Include the relevant diagnoses or problems, the prioritized differential, ordered or recommended tests, monitoring, consults, empiric treatments if appropriate, disposition criteria, and follow-up actions. Make each recommendation traceable to the patient data and the diagnostic plan.
- Check each medication, test, and procedure against the patient's allergies, comorbidities, pregnancy status if relevant, renal/hepatic function, anticoagulation status, and documented goals of care. Do not hide contraindications or uncertainty.
- Complete the plan yourself and carry it through to a coherent final note — do not stop with placeholders such as “consult team to decide” unless the consult is itself the appropriate next step. If a recommendation conflicts with the patient data, find and fix the root cause.
- Sanity-check the plan: a patient who is unstable should not be assigned routine outpatient follow-up only; a contraindicated medication should not be recommended; a dangerous diagnosis raised in the differential should have an explicit rule-out or mitigation step.

Write the care-plan note and its rationale up in `CARE_PLAN.md`.
</f6>

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

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

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

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

<f8>
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 is unsafe, but I'm telling you it is unsafe" is still a failing result, not a passing one.
</f8>

<f9>
Produce the diagnostic plan for the case and write it to `DIFFERENTIAL.md`. A complete plan has two parts — a formalized clinical problem representation and one chosen workup strategy.

The **problem representation** must state:

- **Clinical syndrome and acuity** — the leading syndrome, severity, time course, and whether the patient appears stable, urgent, or emergent.
- **Key data** — the critical positives and negatives from the history, exam, vitals, labs, imaging, medications, allergies, pregnancy/immunocompromised status if relevant, and risk factors.
- **Prioritized differential diagnosis** — likely diagnoses and dangerous diagnoses that must not be missed, with brief reasoning for and against each.
- **Working diagnosis or leading concern** — the current best explanation, if one can be chosen, and the uncertainty that remains.
- **Constraints and safety boundaries** — comorbidities, contraindications, renal/hepatic limitations, allergy issues, infection-control needs, disposition limits, and red flags that must change management.

The **workup strategy** — weigh the options and commit to the single most defensible route — must state:

- which tests, monitoring steps, consults, and empiric precautions to use, and when to use them;
- the diagnostic algorithm and its key decision thresholds;
- the clinical reasoning or risk-stratification tool the route relies on;
- the biggest risk on this route, including the most important diagnosis that could be missed.
</f9>

<f10>
The diagnostic plan lives in `DIFFERENTIAL.md`, and you may be invoked on it more than once — the workflow runs you and the diagnostic safety reviewer as a loop.

- If `DIFFERENTIAL.md` does not exist yet, this is the first pass: produce the diagnostic plan from scratch.
- If `DIFFERENTIAL.md` already exists, it carries the diagnostic safety reviewer's `<review>` block: read that feedback and revise `DIFFERENTIAL.md` in place to address every point raised. Don't discard the plan and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `CARE_PLAN.md` — the care-plan note and its rationale. Verify it directly against the patient presentation.

- Inspect the reported assessment and plan for anomalies, unreasonable disposition choices, unsafe medication recommendations, omitted monitoring, or contradictions with the patient's vitals, labs, allergies, comorbidities, and goals of care.
- Write a separate `SAFETY_CHECK.md` that re-checks every major recommendation against the reported patient facts and the differential diagnosis, and complete it; name any diagnoses, contraindications, or risk factors that the care plan fails to address.
- Read the care-plan note and spot-check it for clinical bugs — copied-forward data that do not match `patient.md`, unused or ignored abnormal results, dead-end recommendations, or logic that contradicts what the plan says it is trying to do. A flaw that silently makes the plan unsafe is worse than one that is obvious.
- Treat the result as finished only when the dangerous diagnoses have been considered, the recommended workup is appropriate, contraindications have been checked, and the disposition is sound — not merely when the note is well written.
- Check the length of `CARE_PLAN.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `CARE_PLAN.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The care-plan note and its rationale live in `CARE_PLAN.md`, and you may be invoked on it more than once — the workflow runs you and the clinical chart auditor as a loop.

- If `CARE_PLAN.md` does not exist yet, this is the first pass: produce the care-plan note from scratch.
- If `CARE_PLAN.md` already exists, it carries the clinical chart auditor's `<review>` block: read that feedback and revise `CARE_PLAN.md` in place to address every point raised. Don't discard the care plan and start over, and don't leave a flagged issue unaddressed.
</f12>

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


I need you to set up a 5-agent hospital second-opinion workflow that turns a patient presentation into a defensible differential diagnosis and workup strategy, then into a reviewed care-plan note. A case arrives as a clinical presentation in `patient.md`, and the workflow produces a vetted diagnostic plan and then a practical care-plan note that has been checked for missed dangerous diagnoses and contraindications.

The five agents:

- **care-coordination lead** orchestrates the run: it drives the diagnostic loop, then the care-plan loop, and tracks progress. It does no diagnosis, care-plan writing, or auditing itself.
- **diagnostic loop** — the **diagnostic consultant** turns the presentation into a prioritized differential diagnosis and workup strategy; the **diagnostic safety reviewer** reviews it. They iterate until the differential and workup are safe and defensible.
- **care-plan loop** — the **care-plan author** converts the settled diagnostic strategy into a clinical care-plan note; the **clinical chart auditor** reviews the note for safety, consistency, and result. They iterate until the care plan is clinically sound.

The workflow hands work off through three files:

- `patient.md` — the original patient presentation, given as input. All four clinical agents (diagnostic consultant, diagnostic safety reviewer, care-plan author, clinical chart auditor) read it.
- `DIFFERENTIAL.md` — the diagnostic plan. The diagnostic consultant writes it; the diagnostic safety reviewer reviews it; the care-plan author reads it to write the care plan.
- `CARE_PLAN.md` — the care-plan note and its rationale. The care-plan author writes it; the clinical chart auditor reviews it.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, and the care-coordination lead reads those scores to drive the loops.

I'm providing the following information:

<f1>
Keep `CARE_PLAN.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>
Which diagnostic approach suits which kind of presentation — use it to choose a safe strategy:

- **Chest pain / possible acute coronary syndrome** — immediate ECG, serial high-sensitivity troponins, risk stratification, and evaluation for alternate killers such as aortic dissection, pulmonary embolism, tension pneumothorax, and esophageal rupture.
- **Focal neurologic deficit / possible stroke** — last-known-well time, glucose check, noncontrast head CT, vascular imaging when indicated, thrombolysis/thrombectomy eligibility, and stroke mimic screen.
- **Dyspnea / hypoxemia** — pulse oximetry trend, chest imaging, ECG, blood gas when needed, BNP/troponin if cardiac cause is plausible, PE risk stratification, and early escalation for respiratory failure.
- **Fever / possible sepsis** — source search, cultures before antibiotics when this does not delay care, lactate, organ dysfunction assessment, early fluids when appropriate, and prompt empiric antimicrobials tailored to source and host risks.
- **Abdominal pain** — pregnancy test when applicable, targeted labs, imaging matched to location and acuity, surgical red-flag screen, and attention to vascular catastrophes in high-risk patients.
- **Syncope / transient loss of consciousness** — orthostatic vitals, ECG, arrhythmia and structural-heart risk assessment, medication review, bleeding screen, and neurologic evaluation only when supported by focal findings.
- **Altered mental status** — glucose, oxygenation, medication/toxin review, infection/metabolic evaluation, neurologic assessment, and rapid treatment of reversible threats.
- **Medication or treatment planning with comorbidities** — check allergies, renal function, hepatic function, QT risk, pregnancy/lactation, anticoagulation, immunosuppression, and drug interactions before recommending therapy.

Match the workup to the clinical syndrome and acuity; do not force a pathway that does not fit the presentation.
</f2>

<f3>
The care-plan note and its rationale live in `CARE_PLAN.md`, and you may be invoked on it more than once — the workflow runs you and the clinical chart auditor as a loop.

- If `CARE_PLAN.md` does not exist yet, this is the first pass: produce the care-plan note from scratch.
- If `CARE_PLAN.md` already exists, it carries the clinical chart auditor's `<review>` block: read that feedback and revise `CARE_PLAN.md` in place to address every point raised. Don't discard the care plan and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review the diagnostic plan in `DIFFERENTIAL.md`:

- **Clinical model** — does it faithfully capture the patient presentation? Check that the syndrome, acuity, key data, prioritized differential, leading concern, and safety constraints are accurate.
- **Workup strategy** — are the chosen tests, monitoring, consults, decision thresholds, and empiric precautions a sound fit, are they actually implementable in the stated care setting, and are they likely to reach a safe diagnosis?

Be brief and specific. Do not write the care-plan note yourself — only review.
</f4>

<f5>
Review `CARE_PLAN.md` — the care-plan note and its rationale. Verify it directly against the patient presentation.

- Inspect the reported assessment and plan for anomalies, unreasonable disposition choices, unsafe medication recommendations, omitted monitoring, or contradictions with the patient's vitals, labs, allergies, comorbidities, and goals of care.
- Write a separate `SAFETY_CHECK.md` that re-checks every major recommendation against the reported patient facts and the differential diagnosis, and complete it; name any diagnoses, contraindications, or risk factors that the care plan fails to address.
- Read the care-plan note and spot-check it for clinical bugs — copied-forward data that do not match `patient.md`, unused or ignored abnormal results, dead-end recommendations, or logic that contradicts what the plan says it is trying to do. A flaw that silently makes the plan unsafe is worse than one that is obvious.
- Treat the result as finished only when the dangerous diagnoses have been considered, the recommended workup is appropriate, contraindications have been checked, and the disposition is sound — not merely when the note is well written.
- Check the length of `CARE_PLAN.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `CARE_PLAN.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the diagnostic plan in `DIFFERENTIAL.md` and implement its strategy as a care-plan note:

- Include the relevant diagnoses or problems, the prioritized differential, ordered or recommended tests, monitoring, consults, empiric treatments if appropriate, disposition criteria, and follow-up actions. Make each recommendation traceable to the patient data and the diagnostic plan.
- Check each medication, test, and procedure against the patient's allergies, comorbidities, pregnancy status if relevant, renal/hepatic function, anticoagulation status, and documented goals of care. Do not hide contraindications or uncertainty.
- Complete the plan yourself and carry it through to a coherent final note — do not stop with placeholders such as “consult team to decide” unless the consult is itself the appropriate next step. If a recommendation conflicts with the patient data, find and fix the root cause.
- Sanity-check the plan: a patient who is unstable should not be assigned routine outpatient follow-up only; a contraindicated medication should not be recommended; a dangerous diagnosis raised in the differential should have an explicit rule-out or mitigation step.

Write the care-plan note and its rationale up in `CARE_PLAN.md`.
</f6>

<f7>
You orchestrate the run; you never diagnose, write the care plan, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the diagnostic consultant to draft the diagnostic plan.
- **Diagnostic loop** — have the diagnostic consultant and diagnostic safety reviewer iterate on the differential and workup strategy until the diagnostic safety reviewer scores the plan 10.
- **Care-plan loop** — once the diagnostic plan is settled, have the care-plan author and clinical chart auditor iterate on the care-plan note until the clinical chart auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the reviewer's `<review score=X>` block. Commit progress after each step.
</f7>

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

<f9>
Produce the diagnostic plan for the case and write it to `DIFFERENTIAL.md`. A complete plan has two parts — a formalized clinical problem representation and one chosen workup strategy.

The **problem representation** must state:

- **Clinical syndrome and acuity** — the leading syndrome, severity, time course, and whether the patient appears stable, urgent, or emergent.
- **Key data** — the critical positives and negatives from the history, exam, vitals, labs, imaging, medications, allergies, pregnancy/immunocompromised status if relevant, and risk factors.
- **Prioritized differential diagnosis** — likely diagnoses and dangerous diagnoses that must not be missed, with brief reasoning for and against each.
- **Working diagnosis or leading concern** — the current best explanation, if one can be chosen, and the uncertainty that remains.
- **Constraints and safety boundaries** — comorbidities, contraindications, renal/hepatic limitations, allergy issues, infection-control needs, disposition limits, and red flags that must change management.

The **workup strategy** — weigh the options and commit to the single most defensible route — must state:

- which tests, monitoring steps, consults, and empiric precautions to use, and when to use them;
- the diagnostic algorithm and its key decision thresholds;
- the clinical reasoning or risk-stratification tool the route relies on;
- the biggest risk on this route, including the most important diagnosis that could be missed.
</f9>

<f10>
You are working on a hospital diagnostic second-opinion case. The original presentation is given as a clinical note in `patient.md`; read it before starting your part. Treat the note as the source of truth for the patient's symptoms, exam findings, vitals, labs, imaging, medications, allergies, comorbidities, and care setting.
</f10>

<f11>
The diagnostic plan lives in `DIFFERENTIAL.md`, and you may be invoked on it more than once — the workflow runs you and the diagnostic safety reviewer as a loop.

- If `DIFFERENTIAL.md` does not exist yet, this is the first pass: produce the diagnostic plan from scratch.
- If `DIFFERENTIAL.md` already exists, it carries the diagnostic safety reviewer's `<review>` block: read that feedback and revise `DIFFERENTIAL.md` in place to address every point raised. Don't discard the plan and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
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 is unsafe, but I'm telling you it is unsafe" is still a failing result, not a passing one.
</f12>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (care-coordination lead, diagnostic consultant, diagnostic safety reviewer, care-plan author, clinical chart auditor), which items should go in its prompt? Respond with a JSON object like {"care-coordination lead": ["f?"], "diagnostic consultant": ["f?"], "diagnostic safety reviewer": ["f?"], "care-plan author": ["f?"], "clinical chart auditor": ["f?"]}. No other output.

I need you to set up a 5-agent hospital second-opinion workflow that turns a patient presentation into a defensible differential diagnosis and workup strategy, then into a reviewed care-plan note. A case arrives as a clinical presentation in `patient.md`, and the workflow produces a vetted diagnostic plan and then a practical care-plan note that has been checked for missed dangerous diagnoses and contraindications.

The five agents:

- **care-coordination lead** orchestrates the run: it drives the diagnostic loop, then the care-plan loop, and tracks progress. It does no diagnosis, care-plan writing, or auditing itself.
- **diagnostic loop** — the **diagnostic consultant** turns the presentation into a prioritized differential diagnosis and workup strategy; the **diagnostic safety reviewer** reviews it. They iterate until the differential and workup are safe and defensible.
- **care-plan loop** — the **care-plan author** converts the settled diagnostic strategy into a clinical care-plan note; the **clinical chart auditor** reviews the note for safety, consistency, and result. They iterate until the care plan is clinically sound.

The workflow hands work off through three files:

- `patient.md` — the original patient presentation, given as input. All four clinical agents (diagnostic consultant, diagnostic safety reviewer, care-plan author, clinical chart auditor) read it.
- `DIFFERENTIAL.md` — the diagnostic plan. The diagnostic consultant writes it; the diagnostic safety reviewer reviews it; the care-plan author reads it to write the care plan.
- `CARE_PLAN.md` — the care-plan note and its rationale. The care-plan author writes it; the clinical chart auditor reviews it.

Each reviewer records its score as a `<review score=X>` block inside the file it reviewed, and the care-coordination lead reads those scores to drive the loops.

I'm providing the following prompt fragments:

<f1>
Keep `CARE_PLAN.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>
Which diagnostic approach suits which kind of presentation — use it to choose a safe strategy:

- **Chest pain / possible acute coronary syndrome** — immediate ECG, serial high-sensitivity troponins, risk stratification, and evaluation for alternate killers such as aortic dissection, pulmonary embolism, tension pneumothorax, and esophageal rupture.
- **Focal neurologic deficit / possible stroke** — last-known-well time, glucose check, noncontrast head CT, vascular imaging when indicated, thrombolysis/thrombectomy eligibility, and stroke mimic screen.
- **Dyspnea / hypoxemia** — pulse oximetry trend, chest imaging, ECG, blood gas when needed, BNP/troponin if cardiac cause is plausible, PE risk stratification, and early escalation for respiratory failure.
- **Fever / possible sepsis** — source search, cultures before antibiotics when this does not delay care, lactate, organ dysfunction assessment, early fluids when appropriate, and prompt empiric antimicrobials tailored to source and host risks.
- **Abdominal pain** — pregnancy test when applicable, targeted labs, imaging matched to location and acuity, surgical red-flag screen, and attention to vascular catastrophes in high-risk patients.
- **Syncope / transient loss of consciousness** — orthostatic vitals, ECG, arrhythmia and structural-heart risk assessment, medication review, bleeding screen, and neurologic evaluation only when supported by focal findings.
- **Altered mental status** — glucose, oxygenation, medication/toxin review, infection/metabolic evaluation, neurologic assessment, and rapid treatment of reversible threats.
- **Medication or treatment planning with comorbidities** — check allergies, renal function, hepatic function, QT risk, pregnancy/lactation, anticoagulation, immunosuppression, and drug interactions before recommending therapy.

Match the workup to the clinical syndrome and acuity; do not force a pathway that does not fit the presentation.
</f2>

<f3>
The care-plan note and its rationale live in `CARE_PLAN.md`, and you may be invoked on it more than once — the workflow runs you and the clinical chart auditor as a loop.

- If `CARE_PLAN.md` does not exist yet, this is the first pass: produce the care-plan note from scratch.
- If `CARE_PLAN.md` already exists, it carries the clinical chart auditor's `<review>` block: read that feedback and revise `CARE_PLAN.md` in place to address every point raised. Don't discard the care plan and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review the diagnostic plan in `DIFFERENTIAL.md`:

- **Clinical model** — does it faithfully capture the patient presentation? Check that the syndrome, acuity, key data, prioritized differential, leading concern, and safety constraints are accurate.
- **Workup strategy** — are the chosen tests, monitoring, consults, decision thresholds, and empiric precautions a sound fit, are they actually implementable in the stated care setting, and are they likely to reach a safe diagnosis?

Be brief and specific. Do not write the care-plan note yourself — only review.
</f4>

<f5>
Review `CARE_PLAN.md` — the care-plan note and its rationale. Verify it directly against the patient presentation.

- Inspect the reported assessment and plan for anomalies, unreasonable disposition choices, unsafe medication recommendations, omitted monitoring, or contradictions with the patient's vitals, labs, allergies, comorbidities, and goals of care.
- Write a separate `SAFETY_CHECK.md` that re-checks every major recommendation against the reported patient facts and the differential diagnosis, and complete it; name any diagnoses, contraindications, or risk factors that the care plan fails to address.
- Read the care-plan note and spot-check it for clinical bugs — copied-forward data that do not match `patient.md`, unused or ignored abnormal results, dead-end recommendations, or logic that contradicts what the plan says it is trying to do. A flaw that silently makes the plan unsafe is worse than one that is obvious.
- Treat the result as finished only when the dangerous diagnoses have been considered, the recommended workup is appropriate, contraindications have been checked, and the disposition is sound — not merely when the note is well written.
- Check the length of `CARE_PLAN.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `CARE_PLAN.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the diagnostic plan in `DIFFERENTIAL.md` and implement its strategy as a care-plan note:

- Include the relevant diagnoses or problems, the prioritized differential, ordered or recommended tests, monitoring, consults, empiric treatments if appropriate, disposition criteria, and follow-up actions. Make each recommendation traceable to the patient data and the diagnostic plan.
- Check each medication, test, and procedure against the patient's allergies, comorbidities, pregnancy status if relevant, renal/hepatic function, anticoagulation status, and documented goals of care. Do not hide contraindications or uncertainty.
- Complete the plan yourself and carry it through to a coherent final note — do not stop with placeholders such as “consult team to decide” unless the consult is itself the appropriate next step. If a recommendation conflicts with the patient data, find and fix the root cause.
- Sanity-check the plan: a patient who is unstable should not be assigned routine outpatient follow-up only; a contraindicated medication should not be recommended; a dangerous diagnosis raised in the differential should have an explicit rule-out or mitigation step.

Write the care-plan note and its rationale up in `CARE_PLAN.md`.
</f6>

<f7>
You orchestrate the run; you never diagnose, write the care plan, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the diagnostic consultant to draft the diagnostic plan.
- **Diagnostic loop** — have the diagnostic consultant and diagnostic safety reviewer iterate on the differential and workup strategy until the diagnostic safety reviewer scores the plan 10.
- **Care-plan loop** — once the diagnostic plan is settled, have the care-plan author and clinical chart auditor iterate on the care-plan note until the clinical chart auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the reviewer's `<review score=X>` block. Commit progress after each step.
</f7>

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

<f9>
Produce the diagnostic plan for the case and write it to `DIFFERENTIAL.md`. A complete plan has two parts — a formalized clinical problem representation and one chosen workup strategy.

The **problem representation** must state:

- **Clinical syndrome and acuity** — the leading syndrome, severity, time course, and whether the patient appears stable, urgent, or emergent.
- **Key data** — the critical positives and negatives from the history, exam, vitals, labs, imaging, medications, allergies, pregnancy/immunocompromised status if relevant, and risk factors.
- **Prioritized differential diagnosis** — likely diagnoses and dangerous diagnoses that must not be missed, with brief reasoning for and against each.
- **Working diagnosis or leading concern** — the current best explanation, if one can be chosen, and the uncertainty that remains.
- **Constraints and safety boundaries** — comorbidities, contraindications, renal/hepatic limitations, allergy issues, infection-control needs, disposition limits, and red flags that must change management.

The **workup strategy** — weigh the options and commit to the single most defensible route — must state:

- which tests, monitoring steps, consults, and empiric precautions to use, and when to use them;
- the diagnostic algorithm and its key decision thresholds;
- the clinical reasoning or risk-stratification tool the route relies on;
- the biggest risk on this route, including the most important diagnosis that could be missed.
</f9>

<f10>
You are working on a hospital diagnostic second-opinion case. The original presentation is given as a clinical note in `patient.md`; read it before starting your part. Treat the note as the source of truth for the patient's symptoms, exam findings, vitals, labs, imaging, medications, allergies, comorbidities, and care setting.
</f10>

<f11>
The diagnostic plan lives in `DIFFERENTIAL.md`, and you may be invoked on it more than once — the workflow runs you and the diagnostic safety reviewer as a loop.

- If `DIFFERENTIAL.md` does not exist yet, this is the first pass: produce the diagnostic plan from scratch.
- If `DIFFERENTIAL.md` already exists, it carries the diagnostic safety reviewer's `<review>` block: read that feedback and revise `DIFFERENTIAL.md` in place to address every point raised. Don't discard the plan and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
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 is unsafe, but I'm telling you it is unsafe" is still a failing result, not a passing one.
</f12>

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


assigning editor
investigative reporter
skeptical investigations editor
story writer
fact-checking editor

I need you to set up a 5-agent investigative journalism publication workflow. A source packet arrives as a collection of tips, documents, interview notes, data extracts, and background material in `source_packet.md`, and the workflow turns it into a vetted reporting theory and then a publishable, fact-checked story.

The five agents:

- **assigning editor** orchestrates the run: it drives the reporting-theory loop, then the story loop, and tracks progress. It does no reporting, writing, or reviewing itself.
- **reporting-theory loop** — the **investigative reporter** turns the source packet into a clear reporting theory and verification strategy; the **skeptical investigations editor** reviews it. They iterate until the theory is well supported and reportable.
- **story loop** — the **story writer** drafts the story from the vetted theory; the **fact-checking editor** reviews the draft, source support, and attribution. They iterate until the story is accurate and publishable.

The workflow hands work off through three files:

- `source_packet.md` — the original source material, given as input. All four domain agents (investigative reporter, skeptical investigations editor, story writer, fact-checking editor) read it.
- `THEORY.md` — the vetted reporting theory. The investigative reporter writes it; the skeptical investigations editor reviews it; the story writer reads it to draft the story.
- `STORY.md` — the publishable story draft, source notes, and fact-check status. The story writer writes it; the fact-checking editor reviews it.

Each editor records the score as a `<review score=X>` block inside the file they reviewed, and the assigning editor reads those scores to drive the loops.

I'm providing the following information:

<f1>
Keep `STORY.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 reporting 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 report, write, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the investigative reporter to draft the theory.
- **Reporting-theory loop** — have the investigative reporter and skeptical investigations editor iterate on the evidence theory and verification strategy until the skeptical investigations editor scores the theory 10.
- **Story loop** — once the theory is settled, have the story writer and fact-checking editor iterate on the draft until the fact-checking editor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the editor's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on an investigative journalism assignment. The original material is given in `source_packet.md`; it may include confidential tips, public records, leaked documents, interview notes, timelines, datasets, prior coverage, and statements from affected parties. Read it before starting your part.
</f3>

<f4>
Review the theory in `THEORY.md`:

- **Evidence theory** — does it faithfully capture the source packet? Check that the story type, known facts, core claims, publication thesis, and evidence gaps are all accurate.
- **Strategy** — is the chosen reporting method and verification sequence a sound fit, is the route actually executable, and is it likely to produce a publishable, well-supported story?

Be brief and specific. Do not draft the story yourself — only review.
</f4>

<f5>
Which reporting route suits which kind of source packet — use it to choose one for the strategy:

- **Public-records buildout** — strongest when the key facts can be verified through filings, budgets, contracts, court records, inspection reports, emails obtained by records request, or meeting minutes; slower when agencies may delay.
- **Document authentication and source corroboration** — best for leaked memos, internal spreadsheets, screenshots, or whistleblower packets; requires provenance checks and at least one independent corroborating source.
- **Data analysis** — best when the source packet includes structured records large enough to reveal patterns; requires cleaning, methodology notes, and reproducibility.
- **Interview-driven reconstruction** — best for misconduct timelines, institutional failures, or events witnessed by many people; needs multiple independent accounts and careful handling of memory conflicts.
- **Right-of-reply and institutional response** — essential when the story names people or organizations accused of wrongdoing; not sufficient by itself to prove the thesis.
- **Legal and ethics review track** — required for high-risk allegations, confidential sources, minors, medical information, sealed records, or potential defamation exposure; it can reshape what can be published.

Match the route to the evidence problem; do not force a method that cannot support the claims.
</f5>

<f6>
Read the theory in `THEORY.md` and implement its strategy as a publishable story draft:

- Include every necessary attribution. State each factual claim with the correct source support, quote accurately, identify anonymous or confidential sourcing limits, preserve chronology, and avoid implying more than the evidence proves.
- Complete the draft and verification work yourself and follow it through to the end — do not stop while key claims are still unchecked. If a claim lacks support, fix the root cause by obtaining support, narrowing the claim, attributing it properly, or removing it; do not hide uncertainty in vague language.
- Sanity-check the story: a claim that depends on a document, dataset, interview, or public record should be traceable to that support, and a number should not appear unless its calculation and units are clear.

Write the story and its verification notes up in `STORY.md`.
</f6>

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

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

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

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

<f8>
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 isn't supported, but I'm saying it isn't supported" is still a failing result, not a passing one.
</f8>

<f9>
Produce the reporting theory for the assignment and write it to `THEORY.md`. A complete theory has two parts — a structured evidence theory and one chosen verification strategy.

The **evidence theory** must state:

- **Story type** — accountability investigation, public-records exposé, data-driven investigation, human-impact feature with investigative findings, enterprise follow-up, and so on; this must be exact.
- **Known facts** — the key confirmed items in the source packet and what each one establishes.
- **Core claims** — the specific factual assertions the story would need to make, with descriptive names.
- **Publication thesis** — the exact claim or finding the story would advance if verified.
- **Evidence gaps and constraints** — every missing source, weak link, legal sensitivity, privacy issue, or attribution limitation, listed explicitly.

The **strategy** — weigh the options and commit to the single most promising reporting route — must state:

- which reporting method to prioritize and how to execute it;
- the verification sequence and its key initial targets;
- the sourcing or corroboration move the route relies on;
- the biggest risk on this route.
</f9>

<f10>
The reporting theory lives in `THEORY.md`, and you may be invoked on it more than once — the workflow runs you and the skeptical investigations editor as a loop.

- If `THEORY.md` does not exist yet, this is the first pass: produce the theory from scratch.
- If `THEORY.md` already exists, it carries the skeptical investigations editor's `<review>` block: read that feedback and revise `THEORY.md` in place to address every point raised. Don't discard the theory and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `STORY.md` — the story draft and its verification notes. Verify it directly against the source packet.

- Inspect the reported findings for anomalies, overstated conclusions, missing context, unreasonable numbers, or claims that go beyond the available evidence.
- Write a separate `VERIFY.md` that re-checks every factual assertion against the cited source support, and complete it; name any claims that lack support, have conflicting support, or need narrower wording.
- Read the story draft and spot-check it for bugs — unused quotes, unattributed facts, dead-end claims, chronology errors, or language that contradicts what the verification notes say. A subtle unsupported implication is worse than an obvious gap.
- Treat the story as finished only when every material claim is supported and the publication thesis is sound — not merely when the draft reads smoothly.
- Check the length of `STORY.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `STORY.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The story draft and verification notes live in `STORY.md`, and you may be invoked on it more than once — the workflow runs you and the fact-checking editor as a loop.

- If `STORY.md` does not exist yet, this is the first pass: produce the story from scratch.
- If `STORY.md` already exists, it carries the fact-checking editor's `<review>` block: read that feedback and revise `STORY.md` in place to address every point raised. Don't discard the story and start over, and don't leave a flagged issue unaddressed.
</f12>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (assigning editor, investigative reporter, skeptical investigations editor, story writer, fact-checking editor), which items should go in its prompt? Respond with a JSON object like {"assigning editor": ["f?"], "investigative reporter": ["f?"], "skeptical investigations editor": ["f?"], "story writer": ["f?"], "fact-checking editor": ["f?"]}. No other output.

I need you to set up a 5-agent investigative journalism publication workflow. A source packet arrives as a collection of tips, documents, interview notes, data extracts, and background material in `source_packet.md`, and the workflow turns it into a vetted reporting theory and then a publishable, fact-checked story.

The five agents:

- **assigning editor** orchestrates the run: it drives the reporting-theory loop, then the story loop, and tracks progress. It does no reporting, writing, or reviewing itself.
- **reporting-theory loop** — the **investigative reporter** turns the source packet into a clear reporting theory and verification strategy; the **skeptical investigations editor** reviews it. They iterate until the theory is well supported and reportable.
- **story loop** — the **story writer** drafts the story from the vetted theory; the **fact-checking editor** reviews the draft, source support, and attribution. They iterate until the story is accurate and publishable.

The workflow hands work off through three files:

- `source_packet.md` — the original source material, given as input. All four domain agents (investigative reporter, skeptical investigations editor, story writer, fact-checking editor) read it.
- `THEORY.md` — the vetted reporting theory. The investigative reporter writes it; the skeptical investigations editor reviews it; the story writer reads it to draft the story.
- `STORY.md` — the publishable story draft, source notes, and fact-check status. The story writer writes it; the fact-checking editor reviews it.

Each editor records the score as a `<review score=X>` block inside the file they reviewed, and the assigning editor reads those scores to drive the loops.

I'm providing the following prompt fragments:

<f1>
Keep `STORY.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 reporting 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 report, write, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the investigative reporter to draft the theory.
- **Reporting-theory loop** — have the investigative reporter and skeptical investigations editor iterate on the evidence theory and verification strategy until the skeptical investigations editor scores the theory 10.
- **Story loop** — once the theory is settled, have the story writer and fact-checking editor iterate on the draft until the fact-checking editor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the editor's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on an investigative journalism assignment. The original material is given in `source_packet.md`; it may include confidential tips, public records, leaked documents, interview notes, timelines, datasets, prior coverage, and statements from affected parties. Read it before starting your part.
</f3>

<f4>
Review the theory in `THEORY.md`:

- **Evidence theory** — does it faithfully capture the source packet? Check that the story type, known facts, core claims, publication thesis, and evidence gaps are all accurate.
- **Strategy** — is the chosen reporting method and verification sequence a sound fit, is the route actually executable, and is it likely to produce a publishable, well-supported story?

Be brief and specific. Do not draft the story yourself — only review.
</f4>

<f5>
Which reporting route suits which kind of source packet — use it to choose one for the strategy:

- **Public-records buildout** — strongest when the key facts can be verified through filings, budgets, contracts, court records, inspection reports, emails obtained by records request, or meeting minutes; slower when agencies may delay.
- **Document authentication and source corroboration** — best for leaked memos, internal spreadsheets, screenshots, or whistleblower packets; requires provenance checks and at least one independent corroborating source.
- **Data analysis** — best when the source packet includes structured records large enough to reveal patterns; requires cleaning, methodology notes, and reproducibility.
- **Interview-driven reconstruction** — best for misconduct timelines, institutional failures, or events witnessed by many people; needs multiple independent accounts and careful handling of memory conflicts.
- **Right-of-reply and institutional response** — essential when the story names people or organizations accused of wrongdoing; not sufficient by itself to prove the thesis.
- **Legal and ethics review track** — required for high-risk allegations, confidential sources, minors, medical information, sealed records, or potential defamation exposure; it can reshape what can be published.

Match the route to the evidence problem; do not force a method that cannot support the claims.
</f5>

<f6>
Read the theory in `THEORY.md` and implement its strategy as a publishable story draft:

- Include every necessary attribution. State each factual claim with the correct source support, quote accurately, identify anonymous or confidential sourcing limits, preserve chronology, and avoid implying more than the evidence proves.
- Complete the draft and verification work yourself and follow it through to the end — do not stop while key claims are still unchecked. If a claim lacks support, fix the root cause by obtaining support, narrowing the claim, attributing it properly, or removing it; do not hide uncertainty in vague language.
- Sanity-check the story: a claim that depends on a document, dataset, interview, or public record should be traceable to that support, and a number should not appear unless its calculation and units are clear.

Write the story and its verification notes up in `STORY.md`.
</f6>

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

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

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

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

<f8>
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 isn't supported, but I'm saying it isn't supported" is still a failing result, not a passing one.
</f8>

<f9>
Produce the reporting theory for the assignment and write it to `THEORY.md`. A complete theory has two parts — a structured evidence theory and one chosen verification strategy.

The **evidence theory** must state:

- **Story type** — accountability investigation, public-records exposé, data-driven investigation, human-impact feature with investigative findings, enterprise follow-up, and so on; this must be exact.
- **Known facts** — the key confirmed items in the source packet and what each one establishes.
- **Core claims** — the specific factual assertions the story would need to make, with descriptive names.
- **Publication thesis** — the exact claim or finding the story would advance if verified.
- **Evidence gaps and constraints** — every missing source, weak link, legal sensitivity, privacy issue, or attribution limitation, listed explicitly.

The **strategy** — weigh the options and commit to the single most promising reporting route — must state:

- which reporting method to prioritize and how to execute it;
- the verification sequence and its key initial targets;
- the sourcing or corroboration move the route relies on;
- the biggest risk on this route.
</f9>

<f10>
The reporting theory lives in `THEORY.md`, and you may be invoked on it more than once — the workflow runs you and the skeptical investigations editor as a loop.

- If `THEORY.md` does not exist yet, this is the first pass: produce the theory from scratch.
- If `THEORY.md` already exists, it carries the skeptical investigations editor's `<review>` block: read that feedback and revise `THEORY.md` in place to address every point raised. Don't discard the theory and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `STORY.md` — the story draft and its verification notes. Verify it directly against the source packet.

- Inspect the reported findings for anomalies, overstated conclusions, missing context, unreasonable numbers, or claims that go beyond the available evidence.
- Write a separate `VERIFY.md` that re-checks every factual assertion against the cited source support, and complete it; name any claims that lack support, have conflicting support, or need narrower wording.
- Read the story draft and spot-check it for bugs — unused quotes, unattributed facts, dead-end claims, chronology errors, or language that contradicts what the verification notes say. A subtle unsupported implication is worse than an obvious gap.
- Treat the story as finished only when every material claim is supported and the publication thesis is sound — not merely when the draft reads smoothly.
- Check the length of `STORY.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `STORY.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The story draft and verification notes live in `STORY.md`, and you may be invoked on it more than once — the workflow runs you and the fact-checking editor as a loop.

- If `STORY.md` does not exist yet, this is the first pass: produce the story from scratch.
- If `STORY.md` already exists, it carries the fact-checking editor's `<review>` block: read that feedback and revise `STORY.md` in place to address every point raised. Don't discard the story and start over, and don't leave a flagged issue unaddressed.
</f12>

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