collections coordinator
provenance hypothesis curator
attribution reviser
forgery-risk examiner
catalog report author
authentication audit reviewer

I need you to set up a 6-agent pipeline that evaluates a museum artifact's authenticity and attribution. An object arrives with a natural-language dossier in `artifact_dossier.md`, and the pipeline turns it into competing provenance hypotheses, a vetted hypothesis, and then a defensible attribution report that has been scrutinized for evidentiary gaps and forgery risks.

The six agents:

- **collections coordinator** orchestrates the run: it drives the hypothesis phase, then the report phase, and tracks progress. It does no attribution research, report writing, or reviewing itself.
- **provenance hypothesis curator** is invoked once at init and produces K differentiated candidate provenance hypotheses, one per `hypotheses/{id}-{slug}/HYPOTHESIS.md`. It never enters the per-hypothesis revision loop.
- **attribution reviser** is invoked once per hypothesis-refinement step in the loop. It revises a single assigned hypothesis's `HYPOTHESIS.md` based on the forgery-risk examiner's last review for that hypothesis. It never creates new hypotheses.
- **forgery-risk examiner** reviews the hypothesis it is currently assigned to.
- **catalog report author** develops the selected line of reasoning into an attribution report for the hypothesis it is currently assigned to.
- **authentication audit reviewer** reviews the attribution report and evidentiary support for the hypothesis it is currently assigned to.

The pipeline hands work off through hypothesis-namespaced files:

- `artifact_dossier.md` — the original object dossier, given as input. All five domain agents (provenance hypothesis curator, attribution reviser, forgery-risk examiner, catalog report author, authentication audit reviewer) read it.
- `hypotheses/{id}-{slug}/HYPOTHESIS.md` — one provenance hypothesis per directory, K hypotheses total. The provenance hypothesis curator writes K differentiated candidates at init; the attribution reviser revises a specific assigned hypothesis in the loop; the forgery-risk examiner reviews the hypothesis it is assigned to; the catalog report author reads the hypothesis it is assigned to.
- `hypotheses/{id}-{slug}/ATTRIBUTION_REPORT.md` — the catalog-style attribution report and evidence assessment for that hypothesis. The catalog report author writes it; the authentication audit reviewer reviews it.

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

The collections coordinator round-robins across the K hypotheses, first in a hypothesis phase (each hypothesis iterates its attribution reviser ↔ forgery-risk examiner loop) and then in a report phase (each hypothesis iterates its catalog report author ↔ authentication audit reviewer loop). Cross-hypothesis reading does not happen: an agent assigned to one hypothesis never reads another hypothesis's files.

I'm providing the following information:

<f1>
Keep your assigned hypothesis's `ATTRIBUTION_REPORT.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page catalog note; record only the final state and move iteration-by-iteration history into the hypothesis's `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 form attributions, write reports, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the provenance hypothesis curator once to draft K differentiated candidate provenance hypotheses, each in its own `hypotheses/{id}-{slug}/` directory. After it returns, read the directory list to learn the K hypothesis ids. The provenance hypothesis curator is not invoked again after this.
- **Hypothesis phase** — round-robin across the K hypotheses. For each hypothesis in turn, dispatch attribution reviser (revise that hypothesis based on its forgery-risk examiner's review) then forgery-risk examiner (score that hypothesis). After one round-robin pass through all K hypotheses, start the next pass. A hypothesis is considered done in this phase when its forgery-risk examiner score reaches 10; stop scheduling more hypothesis-phase calls for it but continue with the others. After all K hypotheses hit forgery-risk examiner 10, or each hypothesis has had 10 hypothesis-phase iterations, move to the report phase.
- **Report phase** — round-robin across the K hypotheses. For each hypothesis in turn, dispatch catalog report author (revise that hypothesis's attribution report based on its authentication audit reviewer's review) then authentication audit reviewer (score that hypothesis's attribution report). The pipeline stops when any hypothesis reaches authentication audit reviewer score 10, or each hypothesis has had 10 report-phase iterations.
- When dispatching, always pass the hypothesis's directory path so the dispatched agent knows which `HYPOTHESIS.md` / `ATTRIBUTION_REPORT.md` to operate on.
- Keep the current phase, per-hypothesis iteration counts, per-hypothesis latest scores, and current hypothesis index in `STATE.md`, accurate after each dispatch. Read each score from the relevant hypothesis's reviewer `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a museum artifact authentication case. The object may involve questions of maker, workshop, period, region, material history, restoration, ownership chain, or later imitation. The original dossier is given as a natural-language file in `artifact_dossier.md`; read it before starting your part.
</f3>

<f4>
Review the hypothesis in your assigned hypothesis's `HYPOTHESIS.md`. Operate strictly on the assigned hypothesis; do not look at other hypotheses.

- **Attribution case** — does it faithfully capture the artifact dossier? Check that the claim type, attribution variables, core claim, and evidence constraints are all accurate.
- **Strategy** — is the chosen mix of provenance research, stylistic comparison, technical examination, and material analysis a sound fit, is the route actually feasible, and is it likely to reach a defensible authentication conclusion?

Be brief and specific. Do not write the attribution report yourself — only review.
</f4>

<f5>
Which authentication approach suits which kind of case — use it to choose one for the strategy:

- **Archival provenance reconstruction** — best when sales records, collection labels, export permits, correspondence, or estate inventories are available; weak when the ownership chain has large undocumented gaps.
- **Connoisseurship and stylistic comparison** — useful for maker, workshop, school, and period attributions; vulnerable to circular comparisons and later imitations that copy surface style.
- **Technical imaging** — infrared reflectography, X-radiography, UV fluorescence, raking light, and microscopy; best for construction sequence, underdrawing, repairs, overpaint, and tool traces.
- **Materials analysis** — pigment, alloy, fiber, wood, ceramic body, binder, or coating analysis; strong for ruling out impossible dates or identifying restoration materials.
- **Scientific dating** — dendrochronology, radiocarbon testing, thermoluminescence, or stratigraphic paint analysis; powerful when the material is suitable, destructive sampling is acceptable, and contamination is controlled.
- **Forgery-risk profiling** — evaluates suspicious provenance gaps, anachronistic materials, artificial aging, market incentives, and inconsistencies across documentation.

Match the authentication approach to the claim type and available evidence; do not force an ill-suited method.
</f5>

<f6>
Read the hypothesis in your assigned hypothesis's `HYPOTHESIS.md` and develop its strategy into a catalog-style attribution report:

- Include every relevant object identifier, physical description, proposed attribution, date range, place, materials, dimensions if available, condition notes, provenance summary, exhibition or publication history if present, and cited evidence. State the core claim and every supporting or limiting piece of evidence exactly as the hypothesis frames it.
- Complete the assessment yourself and follow the evidence through to a conclusion — do not stop at a list of unresolved leads. If a cited source, label, material observation, or comparison creates a contradiction, identify and resolve the root issue; do not hide it behind vague phrasing.
- Sanity-check the attribution: a claim requiring a 16th-century origin should not rely on a synthetic material first available in the 20th century, and a continuous provenance should not skip unexplained decades.

Write the report and its conclusion in your assigned hypothesis's `ATTRIBUTION_REPORT.md`. Do not read or touch other hypotheses' files.
</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 attribution is unsupported, but I'm telling you it is unsupported" is still a failing result, not a passing one.
</f8>

<f9>
Produce K differentiated candidate provenance hypotheses, each in its own `hypotheses/{id}-{slug}/HYPOTHESIS.md`. The K hypotheses should differ meaningfully in attribution route so distinct possibilities can be compared downstream, not in trivial ways like rephrasing the same ownership chain.

A complete hypothesis in any `HYPOTHESIS.md` has two parts — a formalized attribution case and one chosen authentication strategy.

The **attribution case** must state:

- **Claim type** — for example, autograph work by a named maker, workshop production, period copy, later pastiche, regional school attribution, or modern forgery; this must be exact.
- **Object data** — the key physical, stylistic, documentary, and contextual inputs and what each one represents.
- **Attribution variables** — the proposed maker, date range, place of production, workshop relationship, ownership chain, and intervention history, with uncertainty clearly named.
- **Core claim** — the exact attribution or authentication position being advanced.
- **Evidence constraints** — every condition that must hold for the claim to be credible, listed explicitly.

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

- which kinds of evidence or specialist examination to rely on and how to use them;
- the analytical sequence and its key initial assumptions;
- the comparative, archival, material, or technical test the route relies on;
- the biggest risk on this route.
</f9>

<f10>
Read your assigned hypothesis's `HYPOTHESIS.md`. It carries the forgery-risk examiner's `<review>` block. Read that feedback and revise the hypothesis's `HYPOTHESIS.md` in place to address every point raised. Preserve the two-part structure (formalized attribution case plus chosen authentication strategy). Don't discard the hypothesis and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new hypotheses. Do not read or touch other hypotheses' files.
</f10>

<f11>
Review your assigned hypothesis's `ATTRIBUTION_REPORT.md` — the attribution report and its evidentiary conclusion. Verify it directly against the artifact dossier. Operate strictly on the assigned hypothesis; do not look at other hypotheses.

- Inspect the reported conclusion for anomalies, overconfident attributions, unexplained provenance gaps, or evidence that contradicts the claimed date, maker, material, or ownership chain.
- Write a separate `evidence_audit.md` under the hypothesis's directory that re-checks every material claim, provenance link, stylistic comparison, and documentary citation against the reported conclusion; name any claims that lack support or conflict with the dossier.
- Read the attribution report and spot-check it for flaws — unused evidence, dead-end assertions, logic that contradicts what the conclusion says it establishes. A flaw that quietly makes a forged or misattributed object look secure is worse than one that is obvious.
- Treat the conclusion as finished only when every necessary evidence constraint holds and the attribution is sound — not merely when the report reads smoothly.
- Check the length of the hypothesis's `ATTRIBUTION_REPORT.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the hypothesis's `ATTRIBUTION_REPORT.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your attribution report and its conclusion live in your assigned hypothesis's `ATTRIBUTION_REPORT.md`.

- If your assigned hypothesis's `ATTRIBUTION_REPORT.md` does not exist yet, this is the first pass for that hypothesis: produce the report from scratch based on the hypothesis's `HYPOTHESIS.md`.
- If the hypothesis's `ATTRIBUTION_REPORT.md` already exists, it carries the authentication audit reviewer's `<review>` block. Read that feedback and revise the hypothesis's `ATTRIBUTION_REPORT.md` in place to address every point raised. Don't discard the report and start over, and don't leave a flagged issue unaddressed. Do not read or touch other hypotheses' files.
</f12>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (collections coordinator, provenance hypothesis curator, attribution reviser, forgery-risk examiner, catalog report author, authentication audit reviewer), which items should go in its prompt? Respond with a JSON object like {"collections coordinator": ["f?"], "provenance hypothesis curator": ["f?"], "attribution reviser": ["f?"], "forgery-risk examiner": ["f?"], "catalog report author": ["f?"], "authentication audit reviewer": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline that evaluates a museum artifact's authenticity and attribution. An object arrives with a natural-language dossier in `artifact_dossier.md`, and the pipeline turns it into competing provenance hypotheses, a vetted hypothesis, and then a defensible attribution report that has been scrutinized for evidentiary gaps and forgery risks.

The six agents:

- **collections coordinator** orchestrates the run: it drives the hypothesis phase, then the report phase, and tracks progress. It does no attribution research, report writing, or reviewing itself.
- **provenance hypothesis curator** is invoked once at init and produces K differentiated candidate provenance hypotheses, one per `hypotheses/{id}-{slug}/HYPOTHESIS.md`. It never enters the per-hypothesis revision loop.
- **attribution reviser** is invoked once per hypothesis-refinement step in the loop. It revises a single assigned hypothesis's `HYPOTHESIS.md` based on the forgery-risk examiner's last review for that hypothesis. It never creates new hypotheses.
- **forgery-risk examiner** reviews the hypothesis it is currently assigned to.
- **catalog report author** develops the selected line of reasoning into an attribution report for the hypothesis it is currently assigned to.
- **authentication audit reviewer** reviews the attribution report and evidentiary support for the hypothesis it is currently assigned to.

The pipeline hands work off through hypothesis-namespaced files:

- `artifact_dossier.md` — the original object dossier, given as input. All five domain agents (provenance hypothesis curator, attribution reviser, forgery-risk examiner, catalog report author, authentication audit reviewer) read it.
- `hypotheses/{id}-{slug}/HYPOTHESIS.md` — one provenance hypothesis per directory, K hypotheses total. The provenance hypothesis curator writes K differentiated candidates at init; the attribution reviser revises a specific assigned hypothesis in the loop; the forgery-risk examiner reviews the hypothesis it is assigned to; the catalog report author reads the hypothesis it is assigned to.
- `hypotheses/{id}-{slug}/ATTRIBUTION_REPORT.md` — the catalog-style attribution report and evidence assessment for that hypothesis. The catalog report author writes it; the authentication audit reviewer reviews it.

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

The collections coordinator round-robins across the K hypotheses, first in a hypothesis phase (each hypothesis iterates its attribution reviser ↔ forgery-risk examiner loop) and then in a report phase (each hypothesis iterates its catalog report author ↔ authentication audit reviewer loop). Cross-hypothesis reading does not happen: an agent assigned to one hypothesis never reads another hypothesis's files.

I'm providing the following prompt fragments:

<f1>
Keep your assigned hypothesis's `ATTRIBUTION_REPORT.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page catalog note; record only the final state and move iteration-by-iteration history into the hypothesis's `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 form attributions, write reports, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the provenance hypothesis curator once to draft K differentiated candidate provenance hypotheses, each in its own `hypotheses/{id}-{slug}/` directory. After it returns, read the directory list to learn the K hypothesis ids. The provenance hypothesis curator is not invoked again after this.
- **Hypothesis phase** — round-robin across the K hypotheses. For each hypothesis in turn, dispatch attribution reviser (revise that hypothesis based on its forgery-risk examiner's review) then forgery-risk examiner (score that hypothesis). After one round-robin pass through all K hypotheses, start the next pass. A hypothesis is considered done in this phase when its forgery-risk examiner score reaches 10; stop scheduling more hypothesis-phase calls for it but continue with the others. After all K hypotheses hit forgery-risk examiner 10, or each hypothesis has had 10 hypothesis-phase iterations, move to the report phase.
- **Report phase** — round-robin across the K hypotheses. For each hypothesis in turn, dispatch catalog report author (revise that hypothesis's attribution report based on its authentication audit reviewer's review) then authentication audit reviewer (score that hypothesis's attribution report). The pipeline stops when any hypothesis reaches authentication audit reviewer score 10, or each hypothesis has had 10 report-phase iterations.
- When dispatching, always pass the hypothesis's directory path so the dispatched agent knows which `HYPOTHESIS.md` / `ATTRIBUTION_REPORT.md` to operate on.
- Keep the current phase, per-hypothesis iteration counts, per-hypothesis latest scores, and current hypothesis index in `STATE.md`, accurate after each dispatch. Read each score from the relevant hypothesis's reviewer `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a museum artifact authentication case. The object may involve questions of maker, workshop, period, region, material history, restoration, ownership chain, or later imitation. The original dossier is given as a natural-language file in `artifact_dossier.md`; read it before starting your part.
</f3>

<f4>
Review the hypothesis in your assigned hypothesis's `HYPOTHESIS.md`. Operate strictly on the assigned hypothesis; do not look at other hypotheses.

- **Attribution case** — does it faithfully capture the artifact dossier? Check that the claim type, attribution variables, core claim, and evidence constraints are all accurate.
- **Strategy** — is the chosen mix of provenance research, stylistic comparison, technical examination, and material analysis a sound fit, is the route actually feasible, and is it likely to reach a defensible authentication conclusion?

Be brief and specific. Do not write the attribution report yourself — only review.
</f4>

<f5>
Which authentication approach suits which kind of case — use it to choose one for the strategy:

- **Archival provenance reconstruction** — best when sales records, collection labels, export permits, correspondence, or estate inventories are available; weak when the ownership chain has large undocumented gaps.
- **Connoisseurship and stylistic comparison** — useful for maker, workshop, school, and period attributions; vulnerable to circular comparisons and later imitations that copy surface style.
- **Technical imaging** — infrared reflectography, X-radiography, UV fluorescence, raking light, and microscopy; best for construction sequence, underdrawing, repairs, overpaint, and tool traces.
- **Materials analysis** — pigment, alloy, fiber, wood, ceramic body, binder, or coating analysis; strong for ruling out impossible dates or identifying restoration materials.
- **Scientific dating** — dendrochronology, radiocarbon testing, thermoluminescence, or stratigraphic paint analysis; powerful when the material is suitable, destructive sampling is acceptable, and contamination is controlled.
- **Forgery-risk profiling** — evaluates suspicious provenance gaps, anachronistic materials, artificial aging, market incentives, and inconsistencies across documentation.

Match the authentication approach to the claim type and available evidence; do not force an ill-suited method.
</f5>

<f6>
Read the hypothesis in your assigned hypothesis's `HYPOTHESIS.md` and develop its strategy into a catalog-style attribution report:

- Include every relevant object identifier, physical description, proposed attribution, date range, place, materials, dimensions if available, condition notes, provenance summary, exhibition or publication history if present, and cited evidence. State the core claim and every supporting or limiting piece of evidence exactly as the hypothesis frames it.
- Complete the assessment yourself and follow the evidence through to a conclusion — do not stop at a list of unresolved leads. If a cited source, label, material observation, or comparison creates a contradiction, identify and resolve the root issue; do not hide it behind vague phrasing.
- Sanity-check the attribution: a claim requiring a 16th-century origin should not rely on a synthetic material first available in the 20th century, and a continuous provenance should not skip unexplained decades.

Write the report and its conclusion in your assigned hypothesis's `ATTRIBUTION_REPORT.md`. Do not read or touch other hypotheses' files.
</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 attribution is unsupported, but I'm telling you it is unsupported" is still a failing result, not a passing one.
</f8>

<f9>
Produce K differentiated candidate provenance hypotheses, each in its own `hypotheses/{id}-{slug}/HYPOTHESIS.md`. The K hypotheses should differ meaningfully in attribution route so distinct possibilities can be compared downstream, not in trivial ways like rephrasing the same ownership chain.

A complete hypothesis in any `HYPOTHESIS.md` has two parts — a formalized attribution case and one chosen authentication strategy.

The **attribution case** must state:

- **Claim type** — for example, autograph work by a named maker, workshop production, period copy, later pastiche, regional school attribution, or modern forgery; this must be exact.
- **Object data** — the key physical, stylistic, documentary, and contextual inputs and what each one represents.
- **Attribution variables** — the proposed maker, date range, place of production, workshop relationship, ownership chain, and intervention history, with uncertainty clearly named.
- **Core claim** — the exact attribution or authentication position being advanced.
- **Evidence constraints** — every condition that must hold for the claim to be credible, listed explicitly.

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

- which kinds of evidence or specialist examination to rely on and how to use them;
- the analytical sequence and its key initial assumptions;
- the comparative, archival, material, or technical test the route relies on;
- the biggest risk on this route.
</f9>

<f10>
Read your assigned hypothesis's `HYPOTHESIS.md`. It carries the forgery-risk examiner's `<review>` block. Read that feedback and revise the hypothesis's `HYPOTHESIS.md` in place to address every point raised. Preserve the two-part structure (formalized attribution case plus chosen authentication strategy). Don't discard the hypothesis and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new hypotheses. Do not read or touch other hypotheses' files.
</f10>

<f11>
Review your assigned hypothesis's `ATTRIBUTION_REPORT.md` — the attribution report and its evidentiary conclusion. Verify it directly against the artifact dossier. Operate strictly on the assigned hypothesis; do not look at other hypotheses.

- Inspect the reported conclusion for anomalies, overconfident attributions, unexplained provenance gaps, or evidence that contradicts the claimed date, maker, material, or ownership chain.
- Write a separate `evidence_audit.md` under the hypothesis's directory that re-checks every material claim, provenance link, stylistic comparison, and documentary citation against the reported conclusion; name any claims that lack support or conflict with the dossier.
- Read the attribution report and spot-check it for flaws — unused evidence, dead-end assertions, logic that contradicts what the conclusion says it establishes. A flaw that quietly makes a forged or misattributed object look secure is worse than one that is obvious.
- Treat the conclusion as finished only when every necessary evidence constraint holds and the attribution is sound — not merely when the report reads smoothly.
- Check the length of the hypothesis's `ATTRIBUTION_REPORT.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the hypothesis's `ATTRIBUTION_REPORT.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your attribution report and its conclusion live in your assigned hypothesis's `ATTRIBUTION_REPORT.md`.

- If your assigned hypothesis's `ATTRIBUTION_REPORT.md` does not exist yet, this is the first pass for that hypothesis: produce the report from scratch based on the hypothesis's `HYPOTHESIS.md`.
- If the hypothesis's `ATTRIBUTION_REPORT.md` already exists, it carries the authentication audit reviewer's `<review>` block. Read that feedback and revise the hypothesis's `ATTRIBUTION_REPORT.md` in place to address every point raised. Don't discard the report and start over, and don't leave a flagged issue unaddressed. Do not read or touch other hypotheses' files.
</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. `# collections coordinator`). Output only the headered prompts, no preamble.


I need you to set up a 6-agent pipeline that evaluates a museum artifact's authenticity and attribution. An object arrives with a natural-language dossier in `artifact_dossier.md`, and the pipeline turns it into competing provenance hypotheses, a vetted hypothesis, and then a defensible attribution report that has been scrutinized for evidentiary gaps and forgery risks.

The six agents:

- **collections coordinator** orchestrates the run: it drives the hypothesis phase, then the report phase, and tracks progress. It does no attribution research, report writing, or reviewing itself.
- **provenance hypothesis curator** is invoked once at init and produces K differentiated candidate provenance hypotheses, one per `hypotheses/{id}-{slug}/HYPOTHESIS.md`. It never enters the per-hypothesis revision loop.
- **attribution reviser** is invoked once per hypothesis-refinement step in the loop. It revises a single assigned hypothesis's `HYPOTHESIS.md` based on the forgery-risk examiner's last review for that hypothesis. It never creates new hypotheses.
- **forgery-risk examiner** reviews the hypothesis it is currently assigned to.
- **catalog report author** develops the selected line of reasoning into an attribution report for the hypothesis it is currently assigned to.
- **authentication audit reviewer** reviews the attribution report and evidentiary support for the hypothesis it is currently assigned to.

The pipeline hands work off through hypothesis-namespaced files:

- `artifact_dossier.md` — the original object dossier, given as input. All five domain agents (provenance hypothesis curator, attribution reviser, forgery-risk examiner, catalog report author, authentication audit reviewer) read it.
- `hypotheses/{id}-{slug}/HYPOTHESIS.md` — one provenance hypothesis per directory, K hypotheses total. The provenance hypothesis curator writes K differentiated candidates at init; the attribution reviser revises a specific assigned hypothesis in the loop; the forgery-risk examiner reviews the hypothesis it is assigned to; the catalog report author reads the hypothesis it is assigned to.
- `hypotheses/{id}-{slug}/ATTRIBUTION_REPORT.md` — the catalog-style attribution report and evidence assessment for that hypothesis. The catalog report author writes it; the authentication audit reviewer reviews it.

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

The collections coordinator round-robins across the K hypotheses, first in a hypothesis phase (each hypothesis iterates its attribution reviser ↔ forgery-risk examiner loop) and then in a report phase (each hypothesis iterates its catalog report author ↔ authentication audit reviewer loop). Cross-hypothesis reading does not happen: an agent assigned to one hypothesis never reads another hypothesis's files.

I'm providing the following information:

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

<f2>
Which authentication approach suits which kind of case — use it to choose one for the strategy:

- **Archival provenance reconstruction** — best when sales records, collection labels, export permits, correspondence, or estate inventories are available; weak when the ownership chain has large undocumented gaps.
- **Connoisseurship and stylistic comparison** — useful for maker, workshop, school, and period attributions; vulnerable to circular comparisons and later imitations that copy surface style.
- **Technical imaging** — infrared reflectography, X-radiography, UV fluorescence, raking light, and microscopy; best for construction sequence, underdrawing, repairs, overpaint, and tool traces.
- **Materials analysis** — pigment, alloy, fiber, wood, ceramic body, binder, or coating analysis; strong for ruling out impossible dates or identifying restoration materials.
- **Scientific dating** — dendrochronology, radiocarbon testing, thermoluminescence, or stratigraphic paint analysis; powerful when the material is suitable, destructive sampling is acceptable, and contamination is controlled.
- **Forgery-risk profiling** — evaluates suspicious provenance gaps, anachronistic materials, artificial aging, market incentives, and inconsistencies across documentation.

Match the authentication approach to the claim type and available evidence; do not force an ill-suited method.
</f2>

<f3>
Your attribution report and its conclusion live in your assigned hypothesis's `ATTRIBUTION_REPORT.md`.

- If your assigned hypothesis's `ATTRIBUTION_REPORT.md` does not exist yet, this is the first pass for that hypothesis: produce the report from scratch based on the hypothesis's `HYPOTHESIS.md`.
- If the hypothesis's `ATTRIBUTION_REPORT.md` already exists, it carries the authentication audit reviewer's `<review>` block. Read that feedback and revise the hypothesis's `ATTRIBUTION_REPORT.md` in place to address every point raised. Don't discard the report and start over, and don't leave a flagged issue unaddressed. Do not read or touch other hypotheses' files.
</f3>

<f4>
Review the hypothesis in your assigned hypothesis's `HYPOTHESIS.md`. Operate strictly on the assigned hypothesis; do not look at other hypotheses.

- **Attribution case** — does it faithfully capture the artifact dossier? Check that the claim type, attribution variables, core claim, and evidence constraints are all accurate.
- **Strategy** — is the chosen mix of provenance research, stylistic comparison, technical examination, and material analysis a sound fit, is the route actually feasible, and is it likely to reach a defensible authentication conclusion?

Be brief and specific. Do not write the attribution report yourself — only review.
</f4>

<f5>
Review your assigned hypothesis's `ATTRIBUTION_REPORT.md` — the attribution report and its evidentiary conclusion. Verify it directly against the artifact dossier. Operate strictly on the assigned hypothesis; do not look at other hypotheses.

- Inspect the reported conclusion for anomalies, overconfident attributions, unexplained provenance gaps, or evidence that contradicts the claimed date, maker, material, or ownership chain.
- Write a separate `evidence_audit.md` under the hypothesis's directory that re-checks every material claim, provenance link, stylistic comparison, and documentary citation against the reported conclusion; name any claims that lack support or conflict with the dossier.
- Read the attribution report and spot-check it for flaws — unused evidence, dead-end assertions, logic that contradicts what the conclusion says it establishes. A flaw that quietly makes a forged or misattributed object look secure is worse than one that is obvious.
- Treat the conclusion as finished only when every necessary evidence constraint holds and the attribution is sound — not merely when the report reads smoothly.
- Check the length of the hypothesis's `ATTRIBUTION_REPORT.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the hypothesis's `ATTRIBUTION_REPORT.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the hypothesis in your assigned hypothesis's `HYPOTHESIS.md` and develop its strategy into a catalog-style attribution report:

- Include every relevant object identifier, physical description, proposed attribution, date range, place, materials, dimensions if available, condition notes, provenance summary, exhibition or publication history if present, and cited evidence. State the core claim and every supporting or limiting piece of evidence exactly as the hypothesis frames it.
- Complete the assessment yourself and follow the evidence through to a conclusion — do not stop at a list of unresolved leads. If a cited source, label, material observation, or comparison creates a contradiction, identify and resolve the root issue; do not hide it behind vague phrasing.
- Sanity-check the attribution: a claim requiring a 16th-century origin should not rely on a synthetic material first available in the 20th century, and a continuous provenance should not skip unexplained decades.

Write the report and its conclusion in your assigned hypothesis's `ATTRIBUTION_REPORT.md`. Do not read or touch other hypotheses' files.
</f6>

<f7>
You orchestrate the run; you never form attributions, write reports, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the provenance hypothesis curator once to draft K differentiated candidate provenance hypotheses, each in its own `hypotheses/{id}-{slug}/` directory. After it returns, read the directory list to learn the K hypothesis ids. The provenance hypothesis curator is not invoked again after this.
- **Hypothesis phase** — round-robin across the K hypotheses. For each hypothesis in turn, dispatch attribution reviser (revise that hypothesis based on its forgery-risk examiner's review) then forgery-risk examiner (score that hypothesis). After one round-robin pass through all K hypotheses, start the next pass. A hypothesis is considered done in this phase when its forgery-risk examiner score reaches 10; stop scheduling more hypothesis-phase calls for it but continue with the others. After all K hypotheses hit forgery-risk examiner 10, or each hypothesis has had 10 hypothesis-phase iterations, move to the report phase.
- **Report phase** — round-robin across the K hypotheses. For each hypothesis in turn, dispatch catalog report author (revise that hypothesis's attribution report based on its authentication audit reviewer's review) then authentication audit reviewer (score that hypothesis's attribution report). The pipeline stops when any hypothesis reaches authentication audit reviewer score 10, or each hypothesis has had 10 report-phase iterations.
- When dispatching, always pass the hypothesis's directory path so the dispatched agent knows which `HYPOTHESIS.md` / `ATTRIBUTION_REPORT.md` to operate on.
- Keep the current phase, per-hypothesis iteration counts, per-hypothesis latest scores, and current hypothesis index in `STATE.md`, accurate after each dispatch. Read each score from the relevant hypothesis's reviewer `<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 K differentiated candidate provenance hypotheses, each in its own `hypotheses/{id}-{slug}/HYPOTHESIS.md`. The K hypotheses should differ meaningfully in attribution route so distinct possibilities can be compared downstream, not in trivial ways like rephrasing the same ownership chain.

A complete hypothesis in any `HYPOTHESIS.md` has two parts — a formalized attribution case and one chosen authentication strategy.

The **attribution case** must state:

- **Claim type** — for example, autograph work by a named maker, workshop production, period copy, later pastiche, regional school attribution, or modern forgery; this must be exact.
- **Object data** — the key physical, stylistic, documentary, and contextual inputs and what each one represents.
- **Attribution variables** — the proposed maker, date range, place of production, workshop relationship, ownership chain, and intervention history, with uncertainty clearly named.
- **Core claim** — the exact attribution or authentication position being advanced.
- **Evidence constraints** — every condition that must hold for the claim to be credible, listed explicitly.

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

- which kinds of evidence or specialist examination to rely on and how to use them;
- the analytical sequence and its key initial assumptions;
- the comparative, archival, material, or technical test the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on a museum artifact authentication case. The object may involve questions of maker, workshop, period, region, material history, restoration, ownership chain, or later imitation. The original dossier is given as a natural-language file in `artifact_dossier.md`; read it before starting your part.
</f10>

<f11>
Read your assigned hypothesis's `HYPOTHESIS.md`. It carries the forgery-risk examiner's `<review>` block. Read that feedback and revise the hypothesis's `HYPOTHESIS.md` in place to address every point raised. Preserve the two-part structure (formalized attribution case plus chosen authentication strategy). Don't discard the hypothesis and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new hypotheses. Do not read or touch other hypotheses' files.
</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 attribution is unsupported, but I'm telling you it is unsupported" 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 (collections coordinator, provenance hypothesis curator, attribution reviser, forgery-risk examiner, catalog report author, authentication audit reviewer), which items should go in its prompt? Respond with a JSON object like {"collections coordinator": ["f?"], "provenance hypothesis curator": ["f?"], "attribution reviser": ["f?"], "forgery-risk examiner": ["f?"], "catalog report author": ["f?"], "authentication audit reviewer": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline that evaluates a museum artifact's authenticity and attribution. An object arrives with a natural-language dossier in `artifact_dossier.md`, and the pipeline turns it into competing provenance hypotheses, a vetted hypothesis, and then a defensible attribution report that has been scrutinized for evidentiary gaps and forgery risks.

The six agents:

- **collections coordinator** orchestrates the run: it drives the hypothesis phase, then the report phase, and tracks progress. It does no attribution research, report writing, or reviewing itself.
- **provenance hypothesis curator** is invoked once at init and produces K differentiated candidate provenance hypotheses, one per `hypotheses/{id}-{slug}/HYPOTHESIS.md`. It never enters the per-hypothesis revision loop.
- **attribution reviser** is invoked once per hypothesis-refinement step in the loop. It revises a single assigned hypothesis's `HYPOTHESIS.md` based on the forgery-risk examiner's last review for that hypothesis. It never creates new hypotheses.
- **forgery-risk examiner** reviews the hypothesis it is currently assigned to.
- **catalog report author** develops the selected line of reasoning into an attribution report for the hypothesis it is currently assigned to.
- **authentication audit reviewer** reviews the attribution report and evidentiary support for the hypothesis it is currently assigned to.

The pipeline hands work off through hypothesis-namespaced files:

- `artifact_dossier.md` — the original object dossier, given as input. All five domain agents (provenance hypothesis curator, attribution reviser, forgery-risk examiner, catalog report author, authentication audit reviewer) read it.
- `hypotheses/{id}-{slug}/HYPOTHESIS.md` — one provenance hypothesis per directory, K hypotheses total. The provenance hypothesis curator writes K differentiated candidates at init; the attribution reviser revises a specific assigned hypothesis in the loop; the forgery-risk examiner reviews the hypothesis it is assigned to; the catalog report author reads the hypothesis it is assigned to.
- `hypotheses/{id}-{slug}/ATTRIBUTION_REPORT.md` — the catalog-style attribution report and evidence assessment for that hypothesis. The catalog report author writes it; the authentication audit reviewer reviews it.

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

The collections coordinator round-robins across the K hypotheses, first in a hypothesis phase (each hypothesis iterates its attribution reviser ↔ forgery-risk examiner loop) and then in a report phase (each hypothesis iterates its catalog report author ↔ authentication audit reviewer loop). Cross-hypothesis reading does not happen: an agent assigned to one hypothesis never reads another hypothesis's files.

I'm providing the following prompt fragments:

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

<f2>
Which authentication approach suits which kind of case — use it to choose one for the strategy:

- **Archival provenance reconstruction** — best when sales records, collection labels, export permits, correspondence, or estate inventories are available; weak when the ownership chain has large undocumented gaps.
- **Connoisseurship and stylistic comparison** — useful for maker, workshop, school, and period attributions; vulnerable to circular comparisons and later imitations that copy surface style.
- **Technical imaging** — infrared reflectography, X-radiography, UV fluorescence, raking light, and microscopy; best for construction sequence, underdrawing, repairs, overpaint, and tool traces.
- **Materials analysis** — pigment, alloy, fiber, wood, ceramic body, binder, or coating analysis; strong for ruling out impossible dates or identifying restoration materials.
- **Scientific dating** — dendrochronology, radiocarbon testing, thermoluminescence, or stratigraphic paint analysis; powerful when the material is suitable, destructive sampling is acceptable, and contamination is controlled.
- **Forgery-risk profiling** — evaluates suspicious provenance gaps, anachronistic materials, artificial aging, market incentives, and inconsistencies across documentation.

Match the authentication approach to the claim type and available evidence; do not force an ill-suited method.
</f2>

<f3>
Your attribution report and its conclusion live in your assigned hypothesis's `ATTRIBUTION_REPORT.md`.

- If your assigned hypothesis's `ATTRIBUTION_REPORT.md` does not exist yet, this is the first pass for that hypothesis: produce the report from scratch based on the hypothesis's `HYPOTHESIS.md`.
- If the hypothesis's `ATTRIBUTION_REPORT.md` already exists, it carries the authentication audit reviewer's `<review>` block. Read that feedback and revise the hypothesis's `ATTRIBUTION_REPORT.md` in place to address every point raised. Don't discard the report and start over, and don't leave a flagged issue unaddressed. Do not read or touch other hypotheses' files.
</f3>

<f4>
Review the hypothesis in your assigned hypothesis's `HYPOTHESIS.md`. Operate strictly on the assigned hypothesis; do not look at other hypotheses.

- **Attribution case** — does it faithfully capture the artifact dossier? Check that the claim type, attribution variables, core claim, and evidence constraints are all accurate.
- **Strategy** — is the chosen mix of provenance research, stylistic comparison, technical examination, and material analysis a sound fit, is the route actually feasible, and is it likely to reach a defensible authentication conclusion?

Be brief and specific. Do not write the attribution report yourself — only review.
</f4>

<f5>
Review your assigned hypothesis's `ATTRIBUTION_REPORT.md` — the attribution report and its evidentiary conclusion. Verify it directly against the artifact dossier. Operate strictly on the assigned hypothesis; do not look at other hypotheses.

- Inspect the reported conclusion for anomalies, overconfident attributions, unexplained provenance gaps, or evidence that contradicts the claimed date, maker, material, or ownership chain.
- Write a separate `evidence_audit.md` under the hypothesis's directory that re-checks every material claim, provenance link, stylistic comparison, and documentary citation against the reported conclusion; name any claims that lack support or conflict with the dossier.
- Read the attribution report and spot-check it for flaws — unused evidence, dead-end assertions, logic that contradicts what the conclusion says it establishes. A flaw that quietly makes a forged or misattributed object look secure is worse than one that is obvious.
- Treat the conclusion as finished only when every necessary evidence constraint holds and the attribution is sound — not merely when the report reads smoothly.
- Check the length of the hypothesis's `ATTRIBUTION_REPORT.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the hypothesis's `ATTRIBUTION_REPORT.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the hypothesis in your assigned hypothesis's `HYPOTHESIS.md` and develop its strategy into a catalog-style attribution report:

- Include every relevant object identifier, physical description, proposed attribution, date range, place, materials, dimensions if available, condition notes, provenance summary, exhibition or publication history if present, and cited evidence. State the core claim and every supporting or limiting piece of evidence exactly as the hypothesis frames it.
- Complete the assessment yourself and follow the evidence through to a conclusion — do not stop at a list of unresolved leads. If a cited source, label, material observation, or comparison creates a contradiction, identify and resolve the root issue; do not hide it behind vague phrasing.
- Sanity-check the attribution: a claim requiring a 16th-century origin should not rely on a synthetic material first available in the 20th century, and a continuous provenance should not skip unexplained decades.

Write the report and its conclusion in your assigned hypothesis's `ATTRIBUTION_REPORT.md`. Do not read or touch other hypotheses' files.
</f6>

<f7>
You orchestrate the run; you never form attributions, write reports, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the provenance hypothesis curator once to draft K differentiated candidate provenance hypotheses, each in its own `hypotheses/{id}-{slug}/` directory. After it returns, read the directory list to learn the K hypothesis ids. The provenance hypothesis curator is not invoked again after this.
- **Hypothesis phase** — round-robin across the K hypotheses. For each hypothesis in turn, dispatch attribution reviser (revise that hypothesis based on its forgery-risk examiner's review) then forgery-risk examiner (score that hypothesis). After one round-robin pass through all K hypotheses, start the next pass. A hypothesis is considered done in this phase when its forgery-risk examiner score reaches 10; stop scheduling more hypothesis-phase calls for it but continue with the others. After all K hypotheses hit forgery-risk examiner 10, or each hypothesis has had 10 hypothesis-phase iterations, move to the report phase.
- **Report phase** — round-robin across the K hypotheses. For each hypothesis in turn, dispatch catalog report author (revise that hypothesis's attribution report based on its authentication audit reviewer's review) then authentication audit reviewer (score that hypothesis's attribution report). The pipeline stops when any hypothesis reaches authentication audit reviewer score 10, or each hypothesis has had 10 report-phase iterations.
- When dispatching, always pass the hypothesis's directory path so the dispatched agent knows which `HYPOTHESIS.md` / `ATTRIBUTION_REPORT.md` to operate on.
- Keep the current phase, per-hypothesis iteration counts, per-hypothesis latest scores, and current hypothesis index in `STATE.md`, accurate after each dispatch. Read each score from the relevant hypothesis's reviewer `<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 K differentiated candidate provenance hypotheses, each in its own `hypotheses/{id}-{slug}/HYPOTHESIS.md`. The K hypotheses should differ meaningfully in attribution route so distinct possibilities can be compared downstream, not in trivial ways like rephrasing the same ownership chain.

A complete hypothesis in any `HYPOTHESIS.md` has two parts — a formalized attribution case and one chosen authentication strategy.

The **attribution case** must state:

- **Claim type** — for example, autograph work by a named maker, workshop production, period copy, later pastiche, regional school attribution, or modern forgery; this must be exact.
- **Object data** — the key physical, stylistic, documentary, and contextual inputs and what each one represents.
- **Attribution variables** — the proposed maker, date range, place of production, workshop relationship, ownership chain, and intervention history, with uncertainty clearly named.
- **Core claim** — the exact attribution or authentication position being advanced.
- **Evidence constraints** — every condition that must hold for the claim to be credible, listed explicitly.

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

- which kinds of evidence or specialist examination to rely on and how to use them;
- the analytical sequence and its key initial assumptions;
- the comparative, archival, material, or technical test the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on a museum artifact authentication case. The object may involve questions of maker, workshop, period, region, material history, restoration, ownership chain, or later imitation. The original dossier is given as a natural-language file in `artifact_dossier.md`; read it before starting your part.
</f10>

<f11>
Read your assigned hypothesis's `HYPOTHESIS.md`. It carries the forgery-risk examiner's `<review>` block. Read that feedback and revise the hypothesis's `HYPOTHESIS.md` in place to address every point raised. Preserve the two-part structure (formalized attribution case plus chosen authentication strategy). Don't discard the hypothesis and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new hypotheses. Do not read or touch other hypotheses' files.
</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 attribution is unsupported, but I'm telling you it is unsupported" 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. `# collections coordinator`). Output only the headered prompts, no preamble.


case-flow coordinator
diagnostic pathway proposer
care-plan reviser
patient-safety challenger
clinical recommendation writer
medical audit reviewer

I need you to set up a 6-agent pipeline that reviews clinical cases. A case arrives as a structured clinical narrative in `case.md`, and the pipeline turns it into several competing diagnostic and treatment pathways, a safety-vetted care plan, and then a patient-specific care recommendation audited for medical errors, omissions, and contraindications.

The six agents:

- **case-flow coordinator** orchestrates the run: it drives the pathway phase, then the recommendation phase, and tracks progress. It does no clinical reasoning, recommendation writing, or reviewing itself.
- **diagnostic pathway proposer** is invoked once at init and produces K differentiated candidate diagnostic and treatment pathways, one per `pathways/{id}-{slug}/CARE_PLAN.md`. It never enters the per-pathway revision loop.
- **care-plan reviser** is invoked once per care-plan refinement step in the loop. It revises a single assigned pathway's `CARE_PLAN.md` based on the patient-safety challenger's last review for that pathway. It never creates new pathways.
- **patient-safety challenger** reviews the pathway it is currently assigned to.
- **clinical recommendation writer** converts the strategy into a concrete patient-specific care recommendation for the pathway it is currently assigned to.
- **medical audit reviewer** reviews the care recommendation and safety checks for the pathway it is currently assigned to.

The pipeline hands work off through pathway-namespaced files:

- `case.md` — the original clinical case, given as input. All five clinical agents (diagnostic pathway proposer, care-plan reviser, patient-safety challenger, clinical recommendation writer, medical audit reviewer) read it.
- `pathways/{id}-{slug}/CARE_PLAN.md` — one care plan per directory, K pathways total. The diagnostic pathway proposer writes K differentiated candidates at init; the care-plan reviser revises a specific assigned pathway in the loop; the patient-safety challenger reviews the pathway it is assigned to; the clinical recommendation writer reads the pathway it is assigned to.
- `pathways/{id}-{slug}/RECOMMENDATION.md` — the patient-specific care recommendation and supporting rationale for that pathway. The clinical recommendation writer writes it; the medical audit reviewer reviews it.

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

The case-flow coordinator round-robins across the K pathways, first in a pathway phase (each pathway iterates its care-plan reviser ↔ patient-safety challenger loop) and then in a recommendation phase (each pathway iterates its clinical recommendation writer ↔ medical audit reviewer loop). Cross-pathway reading does not happen: an agent assigned to one pathway never reads another pathway's files.

I'm providing the following information:

<f1>
Keep your assigned pathway's `RECOMMENDATION.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 the pathway's `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 perform clinical reasoning, write care recommendations, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the diagnostic pathway proposer once to draft K differentiated candidate pathways, each in its own `pathways/{id}-{slug}/` directory. After it returns, read the directory list to learn the K pathway ids. The diagnostic pathway proposer is not invoked again after this.
- **Pathway phase** — round-robin across the K pathways. For each pathway in turn, dispatch care-plan reviser (revise that pathway based on its patient-safety challenger's review) then patient-safety challenger (score that pathway). After one round-robin pass through all K pathways, start the next pass. A pathway is considered done in this phase when its patient-safety challenger score reaches 10; stop scheduling more pathway-phase calls for it but continue with the others. After all K pathways hit patient-safety challenger 10, or each pathway has had 10 pathway-phase iterations, move to the recommendation phase.
- **Recommendation phase** — round-robin across the K pathways. For each pathway in turn, dispatch clinical recommendation writer (revise that pathway's recommendation based on its medical audit reviewer's review) then medical audit reviewer (score that pathway's recommendation). The pipeline stops when any pathway reaches medical audit reviewer score 10, or each pathway has had 10 recommendation-phase iterations.
- When dispatching, always pass the pathway's directory path so the dispatched agent knows which `CARE_PLAN.md` / `RECOMMENDATION.md` to operate on.
- Keep the current phase, per-pathway iteration counts, per-pathway latest scores, and current pathway index in `STATE.md`, accurate after each dispatch. Read each score from the relevant pathway's reviewer `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a clinical case review. The original case is given as a structured narrative in `case.md`; read it before starting your part. The case may include presenting symptoms, vital signs, exam findings, medical history, medications, allergies, pregnancy status, labs, imaging, prior treatments, social context, and patient preferences.
</f3>

<f4>
Review the care plan in your assigned pathway's `CARE_PLAN.md`. Operate strictly on the assigned pathway; do not look at other pathways.

- **Assessment** — does it faithfully capture the case? Check that the clinical problem type, acuity, patient data, key decisions, objective, and safety constraints are all accurate.
- **Strategy** — are the diagnostic tests, treatments, monitoring, consultations, and escalation thresholds a sound fit; are they implementable; and are they likely to reach a safe and correct clinical recommendation?
- **Safety** — look specifically for missed contraindications, allergy conflicts, drug interactions, renal/hepatic dosing problems, pregnancy concerns, inappropriate disposition, delayed emergency care, and failure to address red flags.

Be brief and specific. Do not write the final care recommendation yourself — only review.
</f4>

<f5>
Which clinical approach suits which kind of case — use it to choose a strategy:

- **Emergency stabilization first** — for airway, breathing, circulation, sepsis, stroke, myocardial infarction, anaphylaxis, severe hypoglycemia, active bleeding, or altered mental status; do not delay immediate treatment for a complete diagnostic workup.
- **Syndrome-based differential diagnosis** — best when the presenting problem is nonspecific, such as chest pain, dyspnea, abdominal pain, fever, syncope, headache, weakness, or confusion; prioritize life-threatening and common causes before rare ones.
- **Guideline-directed disease pathway** — best when the diagnosis is already likely or established, such as asthma exacerbation, heart failure, diabetes, COPD, evaluationulitis, community-acquired pneumonia, UTI, anticoagulation management, or hypertension.
- **Risk-stratified testing** — use validated bedside rules or pretest probability when appropriate, such as Wells/PERC for pulmonary embolism, HEART/TIMI for chest pain, Centor/McIsaac for pharyngitis, Ottawa rules for imaging, or CHA₂DS₂-VASc/HAS-BLED for anticoagulation.
- **Medication-safety reconciliation** — essential when the case involves polypharmacy, anticoagulants, insulin, opioids, sedatives, QT-prolonging drugs, immunosuppressants, renal impairment, hepatic disease, pregnancy, breastfeeding, or documented allergies.
- **Watchful waiting with explicit follow-up** — appropriate only for low-risk, stable patients when immediate testing or treatment is unlikely to change management; it must include red flags, follow-up timing, and a contingency plan.
- **Specialty consultation or transfer** — use when the case exceeds local scope, requires a procedure or inpatient service, involves diagnostic uncertainty with high risk, or has complex comorbidities.

Match the pathway intensity to the patient's acuity and risk; do not force a low-acuity outpatient approach onto an unstable case, and do not expose a low-risk patient to unnecessary invasive testing.
</f5>

<f6>
Read the care plan in your assigned pathway's `CARE_PLAN.md` and convert its strategy into a concrete patient-specific care recommendation:

- Include every clinically relevant component: assessment summary, prioritized diagnoses, diagnostic tests, treatments, medication names and doses when appropriate, monitoring, patient counseling, disposition, follow-up, and escalation criteria.
- Check every recommendation against the case details: allergies, current medications, pregnancy/lactation status, renal and hepatic function, age, vital signs, comorbidities, infection risk, anticoagulation status, and patient preferences.
- Do not hide uncertainty. If a diagnosis is not confirmed, state what finding would confirm or refute it and what should happen next.
- Sanity-check the recommendation: a medication should not contradict an allergy, a dose should be plausible for the patient, an outpatient plan should not ignore unstable vital signs, and a reassurance plan should not miss a red flag.

Write the recommendation and its supporting rationale in your assigned pathway's `RECOMMENDATION.md`. Do not read or touch other pathways' files.
</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 K differentiated candidate diagnostic and treatment pathways, each in its own `pathways/{id}-{slug}/CARE_PLAN.md`. The K pathways should differ meaningfully in their clinical strategy so distinct routes can be compared downstream, not in trivial ways like rewording the same differential or ordering the same tests in a different sentence.

A complete care plan in any `CARE_PLAN.md` has two parts — a formalized clinical assessment and one chosen diagnostic/treatment strategy.

The **assessment** must state:

- **Clinical problem type and acuity** — for example unstable emergency, urgent inpatient workup, outpatient diagnostic clarification, chronic disease optimization, medication adverse event, postoperative complication, and so on; this must be explicit.
- **Patient data** — the key clinical inputs and what each one implies, including age, relevant comorbidities, medications, allergies, vital signs, exam findings, labs, imaging, and risk factors.
- **Key clinical decisions** — the diagnostic and therapeutic choices that must be made, with clear names and timing.
- **Clinical objective** — the exact goal of the pathway, such as ruling out a life-threatening diagnosis, treating the most likely condition safely, preventing deterioration, minimizing medication harm, or arranging appropriate follow-up.
- **Safety constraints** — every relevant contraindication, allergy, drug interaction, renal/hepatic dosing issue, pregnancy/lactation concern, infection-control issue, procedure risk, monitoring requirement, and escalation trigger.

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

- which diagnostic tests, treatments, monitoring steps, and consultations to use, and in what order;
- the clinical algorithm and its key initial thresholds or decision points;
- the guideline principle, bedside rule, risk-stratification tool, or safety workaround the route relies on;
- the biggest risk on this route.
</f9>

<f10>
Read your assigned pathway's `CARE_PLAN.md`. It carries the patient-safety challenger's `<review>` block. Read that feedback and revise the pathway's `CARE_PLAN.md` in place to address every point raised. Preserve the two-part structure (formalized clinical assessment plus chosen diagnostic/treatment strategy). Don't discard the pathway and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new pathways. Do not read or touch other pathways' files.
</f10>

<f11>
Review your assigned pathway's `RECOMMENDATION.md` — the care recommendation and its rationale. Verify it directly against the case statement. Operate strictly on the assigned pathway; do not look at other pathways.

- Inspect the recommendation for anomalies, unsafe treatments, unreasonable doses, missing monitoring, inappropriate disposition, contraindications, or failure to address a dangerous diagnosis.
- Write a separate `audit_checklist.md` under the pathway's directory that re-checks every active medication, test, procedure, monitoring step, and disposition decision against the reported case details, and complete it; name any allergies, drug interactions, contraindications, abnormal vital signs, lab values, or comorbidities that are violated or ignored.
- Read the recommendation and spot-check it for clinical logic errors — copied assumptions not present in the case, unused abnormal findings, omitted red flags, contradictory instructions, or advice that contradicts the stated diagnosis. A subtle recommendation that appears reasonable but increases patient risk is worse than one that clearly fails and gets stopped.
- Treat the result as finished only when the recommendation is internally consistent, addresses the important risks, and has no unresolved contraindication or safety gap — not merely when the document is well written.
- Check the length of the pathway's `RECOMMENDATION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the pathway's `RECOMMENDATION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your care recommendation and its rationale live in your assigned pathway's `RECOMMENDATION.md`.

- If your assigned pathway's `RECOMMENDATION.md` does not exist yet, this is the first pass for that pathway: produce the recommendation from scratch based on the pathway's `CARE_PLAN.md`.
- If the pathway's `RECOMMENDATION.md` already exists, it carries the medical audit reviewer's `<review>` block. Read that feedback and revise the pathway's `RECOMMENDATION.md` in place to address every point raised. Don't discard the recommendation and start over, and don't leave a flagged issue unaddressed. Do not read or touch other pathways' files.
</f12>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (case-flow coordinator, diagnostic pathway proposer, care-plan reviser, patient-safety challenger, clinical recommendation writer, medical audit reviewer), which items should go in its prompt? Respond with a JSON object like {"case-flow coordinator": ["f?"], "diagnostic pathway proposer": ["f?"], "care-plan reviser": ["f?"], "patient-safety challenger": ["f?"], "clinical recommendation writer": ["f?"], "medical audit reviewer": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline that reviews clinical cases. A case arrives as a structured clinical narrative in `case.md`, and the pipeline turns it into several competing diagnostic and treatment pathways, a safety-vetted care plan, and then a patient-specific care recommendation audited for medical errors, omissions, and contraindications.

The six agents:

- **case-flow coordinator** orchestrates the run: it drives the pathway phase, then the recommendation phase, and tracks progress. It does no clinical reasoning, recommendation writing, or reviewing itself.
- **diagnostic pathway proposer** is invoked once at init and produces K differentiated candidate diagnostic and treatment pathways, one per `pathways/{id}-{slug}/CARE_PLAN.md`. It never enters the per-pathway revision loop.
- **care-plan reviser** is invoked once per care-plan refinement step in the loop. It revises a single assigned pathway's `CARE_PLAN.md` based on the patient-safety challenger's last review for that pathway. It never creates new pathways.
- **patient-safety challenger** reviews the pathway it is currently assigned to.
- **clinical recommendation writer** converts the strategy into a concrete patient-specific care recommendation for the pathway it is currently assigned to.
- **medical audit reviewer** reviews the care recommendation and safety checks for the pathway it is currently assigned to.

The pipeline hands work off through pathway-namespaced files:

- `case.md` — the original clinical case, given as input. All five clinical agents (diagnostic pathway proposer, care-plan reviser, patient-safety challenger, clinical recommendation writer, medical audit reviewer) read it.
- `pathways/{id}-{slug}/CARE_PLAN.md` — one care plan per directory, K pathways total. The diagnostic pathway proposer writes K differentiated candidates at init; the care-plan reviser revises a specific assigned pathway in the loop; the patient-safety challenger reviews the pathway it is assigned to; the clinical recommendation writer reads the pathway it is assigned to.
- `pathways/{id}-{slug}/RECOMMENDATION.md` — the patient-specific care recommendation and supporting rationale for that pathway. The clinical recommendation writer writes it; the medical audit reviewer reviews it.

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

The case-flow coordinator round-robins across the K pathways, first in a pathway phase (each pathway iterates its care-plan reviser ↔ patient-safety challenger loop) and then in a recommendation phase (each pathway iterates its clinical recommendation writer ↔ medical audit reviewer loop). Cross-pathway reading does not happen: an agent assigned to one pathway never reads another pathway's files.

I'm providing the following prompt fragments:

<f1>
Keep your assigned pathway's `RECOMMENDATION.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 the pathway's `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 perform clinical reasoning, write care recommendations, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the diagnostic pathway proposer once to draft K differentiated candidate pathways, each in its own `pathways/{id}-{slug}/` directory. After it returns, read the directory list to learn the K pathway ids. The diagnostic pathway proposer is not invoked again after this.
- **Pathway phase** — round-robin across the K pathways. For each pathway in turn, dispatch care-plan reviser (revise that pathway based on its patient-safety challenger's review) then patient-safety challenger (score that pathway). After one round-robin pass through all K pathways, start the next pass. A pathway is considered done in this phase when its patient-safety challenger score reaches 10; stop scheduling more pathway-phase calls for it but continue with the others. After all K pathways hit patient-safety challenger 10, or each pathway has had 10 pathway-phase iterations, move to the recommendation phase.
- **Recommendation phase** — round-robin across the K pathways. For each pathway in turn, dispatch clinical recommendation writer (revise that pathway's recommendation based on its medical audit reviewer's review) then medical audit reviewer (score that pathway's recommendation). The pipeline stops when any pathway reaches medical audit reviewer score 10, or each pathway has had 10 recommendation-phase iterations.
- When dispatching, always pass the pathway's directory path so the dispatched agent knows which `CARE_PLAN.md` / `RECOMMENDATION.md` to operate on.
- Keep the current phase, per-pathway iteration counts, per-pathway latest scores, and current pathway index in `STATE.md`, accurate after each dispatch. Read each score from the relevant pathway's reviewer `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a clinical case review. The original case is given as a structured narrative in `case.md`; read it before starting your part. The case may include presenting symptoms, vital signs, exam findings, medical history, medications, allergies, pregnancy status, labs, imaging, prior treatments, social context, and patient preferences.
</f3>

<f4>
Review the care plan in your assigned pathway's `CARE_PLAN.md`. Operate strictly on the assigned pathway; do not look at other pathways.

- **Assessment** — does it faithfully capture the case? Check that the clinical problem type, acuity, patient data, key decisions, objective, and safety constraints are all accurate.
- **Strategy** — are the diagnostic tests, treatments, monitoring, consultations, and escalation thresholds a sound fit; are they implementable; and are they likely to reach a safe and correct clinical recommendation?
- **Safety** — look specifically for missed contraindications, allergy conflicts, drug interactions, renal/hepatic dosing problems, pregnancy concerns, inappropriate disposition, delayed emergency care, and failure to address red flags.

Be brief and specific. Do not write the final care recommendation yourself — only review.
</f4>

<f5>
Which clinical approach suits which kind of case — use it to choose a strategy:

- **Emergency stabilization first** — for airway, breathing, circulation, sepsis, stroke, myocardial infarction, anaphylaxis, severe hypoglycemia, active bleeding, or altered mental status; do not delay immediate treatment for a complete diagnostic workup.
- **Syndrome-based differential diagnosis** — best when the presenting problem is nonspecific, such as chest pain, dyspnea, abdominal pain, fever, syncope, headache, weakness, or confusion; prioritize life-threatening and common causes before rare ones.
- **Guideline-directed disease pathway** — best when the diagnosis is already likely or established, such as asthma exacerbation, heart failure, diabetes, COPD, evaluationulitis, community-acquired pneumonia, UTI, anticoagulation management, or hypertension.
- **Risk-stratified testing** — use validated bedside rules or pretest probability when appropriate, such as Wells/PERC for pulmonary embolism, HEART/TIMI for chest pain, Centor/McIsaac for pharyngitis, Ottawa rules for imaging, or CHA₂DS₂-VASc/HAS-BLED for anticoagulation.
- **Medication-safety reconciliation** — essential when the case involves polypharmacy, anticoagulants, insulin, opioids, sedatives, QT-prolonging drugs, immunosuppressants, renal impairment, hepatic disease, pregnancy, breastfeeding, or documented allergies.
- **Watchful waiting with explicit follow-up** — appropriate only for low-risk, stable patients when immediate testing or treatment is unlikely to change management; it must include red flags, follow-up timing, and a contingency plan.
- **Specialty consultation or transfer** — use when the case exceeds local scope, requires a procedure or inpatient service, involves diagnostic uncertainty with high risk, or has complex comorbidities.

Match the pathway intensity to the patient's acuity and risk; do not force a low-acuity outpatient approach onto an unstable case, and do not expose a low-risk patient to unnecessary invasive testing.
</f5>

<f6>
Read the care plan in your assigned pathway's `CARE_PLAN.md` and convert its strategy into a concrete patient-specific care recommendation:

- Include every clinically relevant component: assessment summary, prioritized diagnoses, diagnostic tests, treatments, medication names and doses when appropriate, monitoring, patient counseling, disposition, follow-up, and escalation criteria.
- Check every recommendation against the case details: allergies, current medications, pregnancy/lactation status, renal and hepatic function, age, vital signs, comorbidities, infection risk, anticoagulation status, and patient preferences.
- Do not hide uncertainty. If a diagnosis is not confirmed, state what finding would confirm or refute it and what should happen next.
- Sanity-check the recommendation: a medication should not contradict an allergy, a dose should be plausible for the patient, an outpatient plan should not ignore unstable vital signs, and a reassurance plan should not miss a red flag.

Write the recommendation and its supporting rationale in your assigned pathway's `RECOMMENDATION.md`. Do not read or touch other pathways' files.
</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 K differentiated candidate diagnostic and treatment pathways, each in its own `pathways/{id}-{slug}/CARE_PLAN.md`. The K pathways should differ meaningfully in their clinical strategy so distinct routes can be compared downstream, not in trivial ways like rewording the same differential or ordering the same tests in a different sentence.

A complete care plan in any `CARE_PLAN.md` has two parts — a formalized clinical assessment and one chosen diagnostic/treatment strategy.

The **assessment** must state:

- **Clinical problem type and acuity** — for example unstable emergency, urgent inpatient workup, outpatient diagnostic clarification, chronic disease optimization, medication adverse event, postoperative complication, and so on; this must be explicit.
- **Patient data** — the key clinical inputs and what each one implies, including age, relevant comorbidities, medications, allergies, vital signs, exam findings, labs, imaging, and risk factors.
- **Key clinical decisions** — the diagnostic and therapeutic choices that must be made, with clear names and timing.
- **Clinical objective** — the exact goal of the pathway, such as ruling out a life-threatening diagnosis, treating the most likely condition safely, preventing deterioration, minimizing medication harm, or arranging appropriate follow-up.
- **Safety constraints** — every relevant contraindication, allergy, drug interaction, renal/hepatic dosing issue, pregnancy/lactation concern, infection-control issue, procedure risk, monitoring requirement, and escalation trigger.

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

- which diagnostic tests, treatments, monitoring steps, and consultations to use, and in what order;
- the clinical algorithm and its key initial thresholds or decision points;
- the guideline principle, bedside rule, risk-stratification tool, or safety workaround the route relies on;
- the biggest risk on this route.
</f9>

<f10>
Read your assigned pathway's `CARE_PLAN.md`. It carries the patient-safety challenger's `<review>` block. Read that feedback and revise the pathway's `CARE_PLAN.md` in place to address every point raised. Preserve the two-part structure (formalized clinical assessment plus chosen diagnostic/treatment strategy). Don't discard the pathway and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new pathways. Do not read or touch other pathways' files.
</f10>

<f11>
Review your assigned pathway's `RECOMMENDATION.md` — the care recommendation and its rationale. Verify it directly against the case statement. Operate strictly on the assigned pathway; do not look at other pathways.

- Inspect the recommendation for anomalies, unsafe treatments, unreasonable doses, missing monitoring, inappropriate disposition, contraindications, or failure to address a dangerous diagnosis.
- Write a separate `audit_checklist.md` under the pathway's directory that re-checks every active medication, test, procedure, monitoring step, and disposition decision against the reported case details, and complete it; name any allergies, drug interactions, contraindications, abnormal vital signs, lab values, or comorbidities that are violated or ignored.
- Read the recommendation and spot-check it for clinical logic errors — copied assumptions not present in the case, unused abnormal findings, omitted red flags, contradictory instructions, or advice that contradicts the stated diagnosis. A subtle recommendation that appears reasonable but increases patient risk is worse than one that clearly fails and gets stopped.
- Treat the result as finished only when the recommendation is internally consistent, addresses the important risks, and has no unresolved contraindication or safety gap — not merely when the document is well written.
- Check the length of the pathway's `RECOMMENDATION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the pathway's `RECOMMENDATION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your care recommendation and its rationale live in your assigned pathway's `RECOMMENDATION.md`.

- If your assigned pathway's `RECOMMENDATION.md` does not exist yet, this is the first pass for that pathway: produce the recommendation from scratch based on the pathway's `CARE_PLAN.md`.
- If the pathway's `RECOMMENDATION.md` already exists, it carries the medical audit reviewer's `<review>` block. Read that feedback and revise the pathway's `RECOMMENDATION.md` in place to address every point raised. Don't discard the recommendation and start over, and don't leave a flagged issue unaddressed. Do not read or touch other pathways' files.
</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. `# case-flow coordinator`). Output only the headered prompts, no preamble.