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

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

<f11>
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.
</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 (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>
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.
</f2>

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

<f11>
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.
</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. `# case-flow coordinator`). Output only the headered prompts, no preamble.


project coordinator
structural scheme designer
design revision engineer
code-compliance examiner
calculation package engineer
independent structural reviewer

I need you to set up a 6-agent pipeline for structural building design compliance. A project arrives as a natural-language design brief in `project_brief.md`, and the pipeline turns it into vetted alternative structural schemes, then into a working calculation package that is independently reviewed for building-code violations and engineering risks.

The six agents:

- **project coordinator** orchestrates the run: it drives the scheme phase, then the calculation phase, and tracks progress. It does no engineering design, calculation production, or reviewing itself.
- **structural scheme designer** is invoked once at init and produces K differentiated candidate structural schemes, one per `schemes/{id}-{slug}/SCHEME.md`. It never enters the per-scheme revision loop.
- **design revision engineer** is invoked once per scheme-revision step in the loop. It revises a single assigned scheme's `SCHEME.md` based on the code-compliance examiner's last review for that scheme. It never creates new schemes.
- **code-compliance examiner** reviews the scheme it is currently assigned to.
- **calculation package engineer** develops the structural calculations and compliance package for the scheme it is currently assigned to.
- **independent structural reviewer** reviews the calculation package and compliance result of the scheme it is currently assigned to.

The pipeline hands work off through scheme-namespaced files:

- `project_brief.md` — the original project brief, given as input. All five domain agents (structural scheme designer, design revision engineer, code-compliance examiner, calculation package engineer, independent structural reviewer) read it.
- `schemes/{id}-{slug}/SCHEME.md` — one structural scheme per directory, K schemes total. The structural scheme designer writes K differentiated candidates at init; the design revision engineer revises a specific assigned scheme in the loop; the code-compliance examiner reviews the scheme it is assigned to; the calculation package engineer reads the scheme it is assigned to.
- `schemes/{id}-{slug}/CALC_PACKAGE.md` — the calculation package, code checks, and compliance conclusions for that scheme. The calculation package engineer writes it; the independent structural reviewer reviews it.

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

The project coordinator round-robins across the K schemes, first in a scheme phase (each scheme iterates its design revision engineer ↔ code-compliance examiner loop) and then in a calculation phase (each scheme iterates its calculation package engineer ↔ independent structural reviewer loop). Cross-scheme reading does not happen: an agent assigned to one scheme never reads another scheme's files.

I'm providing the following information:

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

- **Init** — dispatch the structural scheme designer once to draft K differentiated candidate schemes, each in its own `schemes/{id}-{slug}/` directory. After it returns, read the directory list to learn the K scheme ids. The structural scheme designer is not invoked again after this.
- **Scheme phase** — round-robin across the K schemes. For each scheme in turn, dispatch design revision engineer (revise that scheme based on its code-compliance examiner's review) then code-compliance examiner (score that scheme). After one round-robin pass through all K schemes, start the next pass. A scheme is considered done in this phase when its code-compliance examiner score reaches 10; stop scheduling more scheme-phase calls for it but continue with the others. After all K schemes hit code-compliance examiner 10, or each scheme has had 10 scheme-phase iterations, move to the calculation phase.
- **Calculation phase** — round-robin across the K schemes. For each scheme in turn, dispatch calculation package engineer (revise that scheme's calculation package based on its independent structural reviewer's review) then independent structural reviewer (score that scheme's calculation package). The pipeline stops when any scheme reaches independent structural reviewer score 10, or each scheme has had 10 calculation-phase iterations.
- When dispatching, always pass the scheme's directory path so the dispatched agent knows which `SCHEME.md` / `CALC_PACKAGE.md` to operate on.
- Keep the current phase, per-scheme iteration counts, per-scheme latest scores, and current scheme index in `STATE.md`, accurate after each dispatch. Read each score from the relevant scheme's reviewer `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a structural building design compliance project. The work may involve steel, reinforced concrete, timber, masonry, foundations, lateral-force-resisting systems, existing-building constraints, or a combination. The original project brief is given as a natural-language statement in `project_brief.md`; read it before starting your part.
</f3>

<f4>
Review the scheme in your assigned scheme's `SCHEME.md`. Operate strictly on the assigned scheme; do not look at other schemes.

- **Structural basis** — does it faithfully capture the project brief? Check that the code basis, design data, structural system, load path, governing loads, serviceability limits, and compliance requirements are all accurate.
- **Strategy** — is the chosen structural system and analysis workflow a sound fit, is the route actually developable into calculations, and is it likely to satisfy strength, stability, serviceability, and detailing requirements?

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

<f5>
Which structural scheme and compliance route suits which kind of project — use it to choose and evaluate the strategy:

- **Steel composite framing with moment frames** — good for open floor plans and moderate-to-long spans; requires careful drift, connection, strong-column/weak-beam, panel-zone, and fireproofing checks.
- **Steel braced frames with simple gravity framing** — efficient for regular buildings with acceptable brace locations; watch brace buckling, collector forces, connection demands, architectural conflicts, and seismic detailing category.
- **Reinforced concrete flat plate or two-way slab with shear walls** — good for repetitive residential or hotel layouts; check punching shear, wall boundary elements, diaphragm transfer, creep/deflection, and construction sequencing.
- **Concrete moment frames** — useful where walls or braces are not acceptable; often drift- and detailing-governed, with significant confinement and joint shear requirements in high seismic zones.
- **Mass timber or glulam framing** — attractive for lower- to mid-rise buildings and exposed structures; check vibration, fire rating, connection ductility, diaphragm behavior, moisture protection, and code height/area limits.
- **Masonry bearing walls with wood or steel diaphragms** — economical for low-rise regular buildings; sensitive to wall slenderness, out-of-plane anchorage, diaphragm flexibility, lintels, and seismic detailing.
- **Shallow foundations** — suitable when soil bearing and settlement are favorable; check bearing pressure, sliding, overturning, uplift, punching, frost depth, and differential settlement.
- **Deep foundations or mat foundations** — use where shallow bearing is inadequate or lateral/uplift demands are high; check group effects, settlement, pile cap design, constructability, and geotechnical recommendations.
- **Existing-building alteration or retrofit** — demands verification of the existing load path and member capacities; do not assume undocumented reserve strength, and identify intrusive investigation needs.

Match the scheme and compliance strategy to the project type, hazards, material constraints, and available code path; do not force an ill-suited structural system.
</f5>

<f6>
Read the scheme in your assigned scheme's `SCHEME.md` and develop its strategy into a complete structural calculation package:

- Include the applicable code references, design assumptions, material strengths, load takedowns, load combinations, analysis model description, member checks, connection or anchorage checks, diaphragm/collector checks, foundation checks, serviceability checks, and final demand/capacity ratios.
- Create each calculation with traceable inputs and units. State every formula or code equation used, define each variable, carry units through the calculation, and show governing results clearly.
- If you use spreadsheets, scripts, or finite-element/modeling outputs, include enough detail for the reviewer to reproduce the result: input values, modeling assumptions, boundary conditions, load cases, combinations, result extraction, and version or tool name.
- Run any analysis script, spreadsheet export, or model check yourself and watch it through to completion — do not stop while it is still running. If it errors or produces unstable results, find and fix the root cause; do not hide problems with unexplained overrides.
- Sanity-check the answer: a member that is obviously overloaded, a drift that exceeds the code limit, a foundation reaction that does not balance the applied loads, or a unit conversion that changes orders of magnitude must be corrected before submission.

Write the calculation package and its results up in your assigned scheme's `CALC_PACKAGE.md`. Do not read or touch other schemes' 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 does not comply, but I'm telling you it does not comply" is still a failing result, not a passing one.
</f8>

<f9>
Produce K differentiated candidate structural schemes, each in its own `schemes/{id}-{slug}/SCHEME.md`. The K schemes should differ meaningfully in structural concept, gravity system, lateral system, materials, foundation approach, or load-path strategy so distinct routes can be compared downstream, not in trivial ways like changing member labels.

A complete scheme in any `SCHEME.md` has two parts — a formalized structural basis and one chosen compliance strategy.

The **structural basis** must state:

- **Project and code basis** — applicable building code and referenced standards such as IBC, ASCE 7, AISC 360/341, ACI 318, NDS, TMS 402, local amendments, risk category, occupancy, seismic design category, wind exposure, and any project-specific performance criteria.
- **Design data** — key numeric inputs and what each one represents, including spans, story heights, tributary areas, dead loads, live loads, roof loads, snow loads, wind pressures, seismic parameters, soil bearing values, and deflection or drift limits.
- **Structural system** — the proposed gravity system, lateral-force-resisting system, diaphragm concept, foundation type, material grades, and preliminary member families.
- **Load path** — how vertical loads, diaphragm forces, collectors, chords, overturning, shear, and foundation reactions are transferred through the structure.
- **Compliance requirements** — every major strength, stability, serviceability, detailing, fire-resistance, robustness, and foundation check that must be satisfied.

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

- which analysis method, design standard, and calculation workflow to use;
- the governing load combinations and key initial member sizes or assumptions;
- the structural simplification, bracing concept, diaphragm assumption, or detailing approach the route relies on;
- the biggest engineering or code-compliance risk on this route.
</f9>

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

<f11>
Review your assigned scheme's `CALC_PACKAGE.md` — the structural calculations and compliance results. Verify it directly against the project brief. Operate strictly on the assigned scheme; do not look at other schemes.

- Inspect the reported results for anomalies, unreasonable reactions, impossible member capacities, excessive drifts or deflections, missing load combinations, or apparent code violations.
- Write a separate `verify.py` under the scheme's directory that independently re-checks the reported governing demands, capacities, demand/capacity ratios, load combinations, drift or deflection limits, and foundation equilibrium from the values stated in the package, and run it; name any members, load cases, or checks that fail.
- Read the calculation package and spot-check it for errors — unused assumptions, dead calculations, unit mistakes, copied member sizes that contradict the scheme, omitted stability checks, or logic that contradicts what the package says it proves. A calculation error that silently understates demand or overstates capacity is worse than one that is obviously incomplete.
- Treat the result as finished only when every stated code check passes, the load path is complete, serviceability limits are satisfied, and the compliance conclusion is sound — not merely when the package is formatted cleanly.
- Check the length of the scheme's `CALC_PACKAGE.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the scheme's `CALC_PACKAGE.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your structural calculations and compliance results live in your assigned scheme's `CALC_PACKAGE.md`.

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (project coordinator, structural scheme designer, design revision engineer, code-compliance examiner, calculation package engineer, independent structural reviewer), which items should go in its prompt? Respond with a JSON object like {"project coordinator": ["f?"], "structural scheme designer": ["f?"], "design revision engineer": ["f?"], "code-compliance examiner": ["f?"], "calculation package engineer": ["f?"], "independent structural reviewer": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline for structural building design compliance. A project arrives as a natural-language design brief in `project_brief.md`, and the pipeline turns it into vetted alternative structural schemes, then into a working calculation package that is independently reviewed for building-code violations and engineering risks.

The six agents:

- **project coordinator** orchestrates the run: it drives the scheme phase, then the calculation phase, and tracks progress. It does no engineering design, calculation production, or reviewing itself.
- **structural scheme designer** is invoked once at init and produces K differentiated candidate structural schemes, one per `schemes/{id}-{slug}/SCHEME.md`. It never enters the per-scheme revision loop.
- **design revision engineer** is invoked once per scheme-revision step in the loop. It revises a single assigned scheme's `SCHEME.md` based on the code-compliance examiner's last review for that scheme. It never creates new schemes.
- **code-compliance examiner** reviews the scheme it is currently assigned to.
- **calculation package engineer** develops the structural calculations and compliance package for the scheme it is currently assigned to.
- **independent structural reviewer** reviews the calculation package and compliance result of the scheme it is currently assigned to.

The pipeline hands work off through scheme-namespaced files:

- `project_brief.md` — the original project brief, given as input. All five domain agents (structural scheme designer, design revision engineer, code-compliance examiner, calculation package engineer, independent structural reviewer) read it.
- `schemes/{id}-{slug}/SCHEME.md` — one structural scheme per directory, K schemes total. The structural scheme designer writes K differentiated candidates at init; the design revision engineer revises a specific assigned scheme in the loop; the code-compliance examiner reviews the scheme it is assigned to; the calculation package engineer reads the scheme it is assigned to.
- `schemes/{id}-{slug}/CALC_PACKAGE.md` — the calculation package, code checks, and compliance conclusions for that scheme. The calculation package engineer writes it; the independent structural reviewer reviews it.

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

The project coordinator round-robins across the K schemes, first in a scheme phase (each scheme iterates its design revision engineer ↔ code-compliance examiner loop) and then in a calculation phase (each scheme iterates its calculation package engineer ↔ independent structural reviewer loop). Cross-scheme reading does not happen: an agent assigned to one scheme never reads another scheme's files.

I'm providing the following prompt fragments:

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

- **Init** — dispatch the structural scheme designer once to draft K differentiated candidate schemes, each in its own `schemes/{id}-{slug}/` directory. After it returns, read the directory list to learn the K scheme ids. The structural scheme designer is not invoked again after this.
- **Scheme phase** — round-robin across the K schemes. For each scheme in turn, dispatch design revision engineer (revise that scheme based on its code-compliance examiner's review) then code-compliance examiner (score that scheme). After one round-robin pass through all K schemes, start the next pass. A scheme is considered done in this phase when its code-compliance examiner score reaches 10; stop scheduling more scheme-phase calls for it but continue with the others. After all K schemes hit code-compliance examiner 10, or each scheme has had 10 scheme-phase iterations, move to the calculation phase.
- **Calculation phase** — round-robin across the K schemes. For each scheme in turn, dispatch calculation package engineer (revise that scheme's calculation package based on its independent structural reviewer's review) then independent structural reviewer (score that scheme's calculation package). The pipeline stops when any scheme reaches independent structural reviewer score 10, or each scheme has had 10 calculation-phase iterations.
- When dispatching, always pass the scheme's directory path so the dispatched agent knows which `SCHEME.md` / `CALC_PACKAGE.md` to operate on.
- Keep the current phase, per-scheme iteration counts, per-scheme latest scores, and current scheme index in `STATE.md`, accurate after each dispatch. Read each score from the relevant scheme's reviewer `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a structural building design compliance project. The work may involve steel, reinforced concrete, timber, masonry, foundations, lateral-force-resisting systems, existing-building constraints, or a combination. The original project brief is given as a natural-language statement in `project_brief.md`; read it before starting your part.
</f3>

<f4>
Review the scheme in your assigned scheme's `SCHEME.md`. Operate strictly on the assigned scheme; do not look at other schemes.

- **Structural basis** — does it faithfully capture the project brief? Check that the code basis, design data, structural system, load path, governing loads, serviceability limits, and compliance requirements are all accurate.
- **Strategy** — is the chosen structural system and analysis workflow a sound fit, is the route actually developable into calculations, and is it likely to satisfy strength, stability, serviceability, and detailing requirements?

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

<f5>
Which structural scheme and compliance route suits which kind of project — use it to choose and evaluate the strategy:

- **Steel composite framing with moment frames** — good for open floor plans and moderate-to-long spans; requires careful drift, connection, strong-column/weak-beam, panel-zone, and fireproofing checks.
- **Steel braced frames with simple gravity framing** — efficient for regular buildings with acceptable brace locations; watch brace buckling, collector forces, connection demands, architectural conflicts, and seismic detailing category.
- **Reinforced concrete flat plate or two-way slab with shear walls** — good for repetitive residential or hotel layouts; check punching shear, wall boundary elements, diaphragm transfer, creep/deflection, and construction sequencing.
- **Concrete moment frames** — useful where walls or braces are not acceptable; often drift- and detailing-governed, with significant confinement and joint shear requirements in high seismic zones.
- **Mass timber or glulam framing** — attractive for lower- to mid-rise buildings and exposed structures; check vibration, fire rating, connection ductility, diaphragm behavior, moisture protection, and code height/area limits.
- **Masonry bearing walls with wood or steel diaphragms** — economical for low-rise regular buildings; sensitive to wall slenderness, out-of-plane anchorage, diaphragm flexibility, lintels, and seismic detailing.
- **Shallow foundations** — suitable when soil bearing and settlement are favorable; check bearing pressure, sliding, overturning, uplift, punching, frost depth, and differential settlement.
- **Deep foundations or mat foundations** — use where shallow bearing is inadequate or lateral/uplift demands are high; check group effects, settlement, pile cap design, constructability, and geotechnical recommendations.
- **Existing-building alteration or retrofit** — demands verification of the existing load path and member capacities; do not assume undocumented reserve strength, and identify intrusive investigation needs.

Match the scheme and compliance strategy to the project type, hazards, material constraints, and available code path; do not force an ill-suited structural system.
</f5>

<f6>
Read the scheme in your assigned scheme's `SCHEME.md` and develop its strategy into a complete structural calculation package:

- Include the applicable code references, design assumptions, material strengths, load takedowns, load combinations, analysis model description, member checks, connection or anchorage checks, diaphragm/collector checks, foundation checks, serviceability checks, and final demand/capacity ratios.
- Create each calculation with traceable inputs and units. State every formula or code equation used, define each variable, carry units through the calculation, and show governing results clearly.
- If you use spreadsheets, scripts, or finite-element/modeling outputs, include enough detail for the reviewer to reproduce the result: input values, modeling assumptions, boundary conditions, load cases, combinations, result extraction, and version or tool name.
- Run any analysis script, spreadsheet export, or model check yourself and watch it through to completion — do not stop while it is still running. If it errors or produces unstable results, find and fix the root cause; do not hide problems with unexplained overrides.
- Sanity-check the answer: a member that is obviously overloaded, a drift that exceeds the code limit, a foundation reaction that does not balance the applied loads, or a unit conversion that changes orders of magnitude must be corrected before submission.

Write the calculation package and its results up in your assigned scheme's `CALC_PACKAGE.md`. Do not read or touch other schemes' 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 does not comply, but I'm telling you it does not comply" is still a failing result, not a passing one.
</f8>

<f9>
Produce K differentiated candidate structural schemes, each in its own `schemes/{id}-{slug}/SCHEME.md`. The K schemes should differ meaningfully in structural concept, gravity system, lateral system, materials, foundation approach, or load-path strategy so distinct routes can be compared downstream, not in trivial ways like changing member labels.

A complete scheme in any `SCHEME.md` has two parts — a formalized structural basis and one chosen compliance strategy.

The **structural basis** must state:

- **Project and code basis** — applicable building code and referenced standards such as IBC, ASCE 7, AISC 360/341, ACI 318, NDS, TMS 402, local amendments, risk category, occupancy, seismic design category, wind exposure, and any project-specific performance criteria.
- **Design data** — key numeric inputs and what each one represents, including spans, story heights, tributary areas, dead loads, live loads, roof loads, snow loads, wind pressures, seismic parameters, soil bearing values, and deflection or drift limits.
- **Structural system** — the proposed gravity system, lateral-force-resisting system, diaphragm concept, foundation type, material grades, and preliminary member families.
- **Load path** — how vertical loads, diaphragm forces, collectors, chords, overturning, shear, and foundation reactions are transferred through the structure.
- **Compliance requirements** — every major strength, stability, serviceability, detailing, fire-resistance, robustness, and foundation check that must be satisfied.

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

- which analysis method, design standard, and calculation workflow to use;
- the governing load combinations and key initial member sizes or assumptions;
- the structural simplification, bracing concept, diaphragm assumption, or detailing approach the route relies on;
- the biggest engineering or code-compliance risk on this route.
</f9>

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

<f11>
Review your assigned scheme's `CALC_PACKAGE.md` — the structural calculations and compliance results. Verify it directly against the project brief. Operate strictly on the assigned scheme; do not look at other schemes.

- Inspect the reported results for anomalies, unreasonable reactions, impossible member capacities, excessive drifts or deflections, missing load combinations, or apparent code violations.
- Write a separate `verify.py` under the scheme's directory that independently re-checks the reported governing demands, capacities, demand/capacity ratios, load combinations, drift or deflection limits, and foundation equilibrium from the values stated in the package, and run it; name any members, load cases, or checks that fail.
- Read the calculation package and spot-check it for errors — unused assumptions, dead calculations, unit mistakes, copied member sizes that contradict the scheme, omitted stability checks, or logic that contradicts what the package says it proves. A calculation error that silently understates demand or overstates capacity is worse than one that is obviously incomplete.
- Treat the result as finished only when every stated code check passes, the load path is complete, serviceability limits are satisfied, and the compliance conclusion is sound — not merely when the package is formatted cleanly.
- Check the length of the scheme's `CALC_PACKAGE.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the scheme's `CALC_PACKAGE.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your structural calculations and compliance results live in your assigned scheme's `CALC_PACKAGE.md`.

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


I need you to set up a 6-agent pipeline for structural building design compliance. A project arrives as a natural-language design brief in `project_brief.md`, and the pipeline turns it into vetted alternative structural schemes, then into a working calculation package that is independently reviewed for building-code violations and engineering risks.

The six agents:

- **project coordinator** orchestrates the run: it drives the scheme phase, then the calculation phase, and tracks progress. It does no engineering design, calculation production, or reviewing itself.
- **structural scheme designer** is invoked once at init and produces K differentiated candidate structural schemes, one per `schemes/{id}-{slug}/SCHEME.md`. It never enters the per-scheme revision loop.
- **design revision engineer** is invoked once per scheme-revision step in the loop. It revises a single assigned scheme's `SCHEME.md` based on the code-compliance examiner's last review for that scheme. It never creates new schemes.
- **code-compliance examiner** reviews the scheme it is currently assigned to.
- **calculation package engineer** develops the structural calculations and compliance package for the scheme it is currently assigned to.
- **independent structural reviewer** reviews the calculation package and compliance result of the scheme it is currently assigned to.

The pipeline hands work off through scheme-namespaced files:

- `project_brief.md` — the original project brief, given as input. All five domain agents (structural scheme designer, design revision engineer, code-compliance examiner, calculation package engineer, independent structural reviewer) read it.
- `schemes/{id}-{slug}/SCHEME.md` — one structural scheme per directory, K schemes total. The structural scheme designer writes K differentiated candidates at init; the design revision engineer revises a specific assigned scheme in the loop; the code-compliance examiner reviews the scheme it is assigned to; the calculation package engineer reads the scheme it is assigned to.
- `schemes/{id}-{slug}/CALC_PACKAGE.md` — the calculation package, code checks, and compliance conclusions for that scheme. The calculation package engineer writes it; the independent structural reviewer reviews it.

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

The project coordinator round-robins across the K schemes, first in a scheme phase (each scheme iterates its design revision engineer ↔ code-compliance examiner loop) and then in a calculation phase (each scheme iterates its calculation package engineer ↔ independent structural reviewer loop). Cross-scheme reading does not happen: an agent assigned to one scheme never reads another scheme's files.

I'm providing the following information:

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

<f2>
Which structural scheme and compliance route suits which kind of project — use it to choose and evaluate the strategy:

- **Steel composite framing with moment frames** — good for open floor plans and moderate-to-long spans; requires careful drift, connection, strong-column/weak-beam, panel-zone, and fireproofing checks.
- **Steel braced frames with simple gravity framing** — efficient for regular buildings with acceptable brace locations; watch brace buckling, collector forces, connection demands, architectural conflicts, and seismic detailing category.
- **Reinforced concrete flat plate or two-way slab with shear walls** — good for repetitive residential or hotel layouts; check punching shear, wall boundary elements, diaphragm transfer, creep/deflection, and construction sequencing.
- **Concrete moment frames** — useful where walls or braces are not acceptable; often drift- and detailing-governed, with significant confinement and joint shear requirements in high seismic zones.
- **Mass timber or glulam framing** — attractive for lower- to mid-rise buildings and exposed structures; check vibration, fire rating, connection ductility, diaphragm behavior, moisture protection, and code height/area limits.
- **Masonry bearing walls with wood or steel diaphragms** — economical for low-rise regular buildings; sensitive to wall slenderness, out-of-plane anchorage, diaphragm flexibility, lintels, and seismic detailing.
- **Shallow foundations** — suitable when soil bearing and settlement are favorable; check bearing pressure, sliding, overturning, uplift, punching, frost depth, and differential settlement.
- **Deep foundations or mat foundations** — use where shallow bearing is inadequate or lateral/uplift demands are high; check group effects, settlement, pile cap design, constructability, and geotechnical recommendations.
- **Existing-building alteration or retrofit** — demands verification of the existing load path and member capacities; do not assume undocumented reserve strength, and identify intrusive investigation needs.

Match the scheme and compliance strategy to the project type, hazards, material constraints, and available code path; do not force an ill-suited structural system.
</f2>

<f3>
Your structural calculations and compliance results live in your assigned scheme's `CALC_PACKAGE.md`.

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

<f4>
Review the scheme in your assigned scheme's `SCHEME.md`. Operate strictly on the assigned scheme; do not look at other schemes.

- **Structural basis** — does it faithfully capture the project brief? Check that the code basis, design data, structural system, load path, governing loads, serviceability limits, and compliance requirements are all accurate.
- **Strategy** — is the chosen structural system and analysis workflow a sound fit, is the route actually developable into calculations, and is it likely to satisfy strength, stability, serviceability, and detailing requirements?

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

<f5>
Review your assigned scheme's `CALC_PACKAGE.md` — the structural calculations and compliance results. Verify it directly against the project brief. Operate strictly on the assigned scheme; do not look at other schemes.

- Inspect the reported results for anomalies, unreasonable reactions, impossible member capacities, excessive drifts or deflections, missing load combinations, or apparent code violations.
- Write a separate `verify.py` under the scheme's directory that independently re-checks the reported governing demands, capacities, demand/capacity ratios, load combinations, drift or deflection limits, and foundation equilibrium from the values stated in the package, and run it; name any members, load cases, or checks that fail.
- Read the calculation package and spot-check it for errors — unused assumptions, dead calculations, unit mistakes, copied member sizes that contradict the scheme, omitted stability checks, or logic that contradicts what the package says it proves. A calculation error that silently understates demand or overstates capacity is worse than one that is obviously incomplete.
- Treat the result as finished only when every stated code check passes, the load path is complete, serviceability limits are satisfied, and the compliance conclusion is sound — not merely when the package is formatted cleanly.
- Check the length of the scheme's `CALC_PACKAGE.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the scheme's `CALC_PACKAGE.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the scheme in your assigned scheme's `SCHEME.md` and develop its strategy into a complete structural calculation package:

- Include the applicable code references, design assumptions, material strengths, load takedowns, load combinations, analysis model description, member checks, connection or anchorage checks, diaphragm/collector checks, foundation checks, serviceability checks, and final demand/capacity ratios.
- Create each calculation with traceable inputs and units. State every formula or code equation used, define each variable, carry units through the calculation, and show governing results clearly.
- If you use spreadsheets, scripts, or finite-element/modeling outputs, include enough detail for the reviewer to reproduce the result: input values, modeling assumptions, boundary conditions, load cases, combinations, result extraction, and version or tool name.
- Run any analysis script, spreadsheet export, or model check yourself and watch it through to completion — do not stop while it is still running. If it errors or produces unstable results, find and fix the root cause; do not hide problems with unexplained overrides.
- Sanity-check the answer: a member that is obviously overloaded, a drift that exceeds the code limit, a foundation reaction that does not balance the applied loads, or a unit conversion that changes orders of magnitude must be corrected before submission.

Write the calculation package and its results up in your assigned scheme's `CALC_PACKAGE.md`. Do not read or touch other schemes' files.
</f6>

<f7>
You orchestrate the run; you never design, calculate, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the structural scheme designer once to draft K differentiated candidate schemes, each in its own `schemes/{id}-{slug}/` directory. After it returns, read the directory list to learn the K scheme ids. The structural scheme designer is not invoked again after this.
- **Scheme phase** — round-robin across the K schemes. For each scheme in turn, dispatch design revision engineer (revise that scheme based on its code-compliance examiner's review) then code-compliance examiner (score that scheme). After one round-robin pass through all K schemes, start the next pass. A scheme is considered done in this phase when its code-compliance examiner score reaches 10; stop scheduling more scheme-phase calls for it but continue with the others. After all K schemes hit code-compliance examiner 10, or each scheme has had 10 scheme-phase iterations, move to the calculation phase.
- **Calculation phase** — round-robin across the K schemes. For each scheme in turn, dispatch calculation package engineer (revise that scheme's calculation package based on its independent structural reviewer's review) then independent structural reviewer (score that scheme's calculation package). The pipeline stops when any scheme reaches independent structural reviewer score 10, or each scheme has had 10 calculation-phase iterations.
- When dispatching, always pass the scheme's directory path so the dispatched agent knows which `SCHEME.md` / `CALC_PACKAGE.md` to operate on.
- Keep the current phase, per-scheme iteration counts, per-scheme latest scores, and current scheme index in `STATE.md`, accurate after each dispatch. Read each score from the relevant scheme'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 structural schemes, each in its own `schemes/{id}-{slug}/SCHEME.md`. The K schemes should differ meaningfully in structural concept, gravity system, lateral system, materials, foundation approach, or load-path strategy so distinct routes can be compared downstream, not in trivial ways like changing member labels.

A complete scheme in any `SCHEME.md` has two parts — a formalized structural basis and one chosen compliance strategy.

The **structural basis** must state:

- **Project and code basis** — applicable building code and referenced standards such as IBC, ASCE 7, AISC 360/341, ACI 318, NDS, TMS 402, local amendments, risk category, occupancy, seismic design category, wind exposure, and any project-specific performance criteria.
- **Design data** — key numeric inputs and what each one represents, including spans, story heights, tributary areas, dead loads, live loads, roof loads, snow loads, wind pressures, seismic parameters, soil bearing values, and deflection or drift limits.
- **Structural system** — the proposed gravity system, lateral-force-resisting system, diaphragm concept, foundation type, material grades, and preliminary member families.
- **Load path** — how vertical loads, diaphragm forces, collectors, chords, overturning, shear, and foundation reactions are transferred through the structure.
- **Compliance requirements** — every major strength, stability, serviceability, detailing, fire-resistance, robustness, and foundation check that must be satisfied.

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

- which analysis method, design standard, and calculation workflow to use;
- the governing load combinations and key initial member sizes or assumptions;
- the structural simplification, bracing concept, diaphragm assumption, or detailing approach the route relies on;
- the biggest engineering or code-compliance risk on this route.
</f9>

<f10>
You are working on a structural building design compliance project. The work may involve steel, reinforced concrete, timber, masonry, foundations, lateral-force-resisting systems, existing-building constraints, or a combination. The original project brief is given as a natural-language statement in `project_brief.md`; read it before starting your part.
</f10>

<f11>
Read your assigned scheme's `SCHEME.md`. It carries the code-compliance examiner's `<review>` block. Read that feedback and revise the scheme's `SCHEME.md` in place to address every point raised. Preserve the two-part structure (formalized structural basis plus chosen compliance strategy). Don't discard the scheme and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new schemes. Do not read or touch other schemes' 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 does not comply, but I'm telling you it does not comply" 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 (project coordinator, structural scheme designer, design revision engineer, code-compliance examiner, calculation package engineer, independent structural reviewer), which items should go in its prompt? Respond with a JSON object like {"project coordinator": ["f?"], "structural scheme designer": ["f?"], "design revision engineer": ["f?"], "code-compliance examiner": ["f?"], "calculation package engineer": ["f?"], "independent structural reviewer": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline for structural building design compliance. A project arrives as a natural-language design brief in `project_brief.md`, and the pipeline turns it into vetted alternative structural schemes, then into a working calculation package that is independently reviewed for building-code violations and engineering risks.

The six agents:

- **project coordinator** orchestrates the run: it drives the scheme phase, then the calculation phase, and tracks progress. It does no engineering design, calculation production, or reviewing itself.
- **structural scheme designer** is invoked once at init and produces K differentiated candidate structural schemes, one per `schemes/{id}-{slug}/SCHEME.md`. It never enters the per-scheme revision loop.
- **design revision engineer** is invoked once per scheme-revision step in the loop. It revises a single assigned scheme's `SCHEME.md` based on the code-compliance examiner's last review for that scheme. It never creates new schemes.
- **code-compliance examiner** reviews the scheme it is currently assigned to.
- **calculation package engineer** develops the structural calculations and compliance package for the scheme it is currently assigned to.
- **independent structural reviewer** reviews the calculation package and compliance result of the scheme it is currently assigned to.

The pipeline hands work off through scheme-namespaced files:

- `project_brief.md` — the original project brief, given as input. All five domain agents (structural scheme designer, design revision engineer, code-compliance examiner, calculation package engineer, independent structural reviewer) read it.
- `schemes/{id}-{slug}/SCHEME.md` — one structural scheme per directory, K schemes total. The structural scheme designer writes K differentiated candidates at init; the design revision engineer revises a specific assigned scheme in the loop; the code-compliance examiner reviews the scheme it is assigned to; the calculation package engineer reads the scheme it is assigned to.
- `schemes/{id}-{slug}/CALC_PACKAGE.md` — the calculation package, code checks, and compliance conclusions for that scheme. The calculation package engineer writes it; the independent structural reviewer reviews it.

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

The project coordinator round-robins across the K schemes, first in a scheme phase (each scheme iterates its design revision engineer ↔ code-compliance examiner loop) and then in a calculation phase (each scheme iterates its calculation package engineer ↔ independent structural reviewer loop). Cross-scheme reading does not happen: an agent assigned to one scheme never reads another scheme's files.

I'm providing the following prompt fragments:

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

<f2>
Which structural scheme and compliance route suits which kind of project — use it to choose and evaluate the strategy:

- **Steel composite framing with moment frames** — good for open floor plans and moderate-to-long spans; requires careful drift, connection, strong-column/weak-beam, panel-zone, and fireproofing checks.
- **Steel braced frames with simple gravity framing** — efficient for regular buildings with acceptable brace locations; watch brace buckling, collector forces, connection demands, architectural conflicts, and seismic detailing category.
- **Reinforced concrete flat plate or two-way slab with shear walls** — good for repetitive residential or hotel layouts; check punching shear, wall boundary elements, diaphragm transfer, creep/deflection, and construction sequencing.
- **Concrete moment frames** — useful where walls or braces are not acceptable; often drift- and detailing-governed, with significant confinement and joint shear requirements in high seismic zones.
- **Mass timber or glulam framing** — attractive for lower- to mid-rise buildings and exposed structures; check vibration, fire rating, connection ductility, diaphragm behavior, moisture protection, and code height/area limits.
- **Masonry bearing walls with wood or steel diaphragms** — economical for low-rise regular buildings; sensitive to wall slenderness, out-of-plane anchorage, diaphragm flexibility, lintels, and seismic detailing.
- **Shallow foundations** — suitable when soil bearing and settlement are favorable; check bearing pressure, sliding, overturning, uplift, punching, frost depth, and differential settlement.
- **Deep foundations or mat foundations** — use where shallow bearing is inadequate or lateral/uplift demands are high; check group effects, settlement, pile cap design, constructability, and geotechnical recommendations.
- **Existing-building alteration or retrofit** — demands verification of the existing load path and member capacities; do not assume undocumented reserve strength, and identify intrusive investigation needs.

Match the scheme and compliance strategy to the project type, hazards, material constraints, and available code path; do not force an ill-suited structural system.
</f2>

<f3>
Your structural calculations and compliance results live in your assigned scheme's `CALC_PACKAGE.md`.

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

<f4>
Review the scheme in your assigned scheme's `SCHEME.md`. Operate strictly on the assigned scheme; do not look at other schemes.

- **Structural basis** — does it faithfully capture the project brief? Check that the code basis, design data, structural system, load path, governing loads, serviceability limits, and compliance requirements are all accurate.
- **Strategy** — is the chosen structural system and analysis workflow a sound fit, is the route actually developable into calculations, and is it likely to satisfy strength, stability, serviceability, and detailing requirements?

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

<f5>
Review your assigned scheme's `CALC_PACKAGE.md` — the structural calculations and compliance results. Verify it directly against the project brief. Operate strictly on the assigned scheme; do not look at other schemes.

- Inspect the reported results for anomalies, unreasonable reactions, impossible member capacities, excessive drifts or deflections, missing load combinations, or apparent code violations.
- Write a separate `verify.py` under the scheme's directory that independently re-checks the reported governing demands, capacities, demand/capacity ratios, load combinations, drift or deflection limits, and foundation equilibrium from the values stated in the package, and run it; name any members, load cases, or checks that fail.
- Read the calculation package and spot-check it for errors — unused assumptions, dead calculations, unit mistakes, copied member sizes that contradict the scheme, omitted stability checks, or logic that contradicts what the package says it proves. A calculation error that silently understates demand or overstates capacity is worse than one that is obviously incomplete.
- Treat the result as finished only when every stated code check passes, the load path is complete, serviceability limits are satisfied, and the compliance conclusion is sound — not merely when the package is formatted cleanly.
- Check the length of the scheme's `CALC_PACKAGE.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the scheme's `CALC_PACKAGE.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the scheme in your assigned scheme's `SCHEME.md` and develop its strategy into a complete structural calculation package:

- Include the applicable code references, design assumptions, material strengths, load takedowns, load combinations, analysis model description, member checks, connection or anchorage checks, diaphragm/collector checks, foundation checks, serviceability checks, and final demand/capacity ratios.
- Create each calculation with traceable inputs and units. State every formula or code equation used, define each variable, carry units through the calculation, and show governing results clearly.
- If you use spreadsheets, scripts, or finite-element/modeling outputs, include enough detail for the reviewer to reproduce the result: input values, modeling assumptions, boundary conditions, load cases, combinations, result extraction, and version or tool name.
- Run any analysis script, spreadsheet export, or model check yourself and watch it through to completion — do not stop while it is still running. If it errors or produces unstable results, find and fix the root cause; do not hide problems with unexplained overrides.
- Sanity-check the answer: a member that is obviously overloaded, a drift that exceeds the code limit, a foundation reaction that does not balance the applied loads, or a unit conversion that changes orders of magnitude must be corrected before submission.

Write the calculation package and its results up in your assigned scheme's `CALC_PACKAGE.md`. Do not read or touch other schemes' files.
</f6>

<f7>
You orchestrate the run; you never design, calculate, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the structural scheme designer once to draft K differentiated candidate schemes, each in its own `schemes/{id}-{slug}/` directory. After it returns, read the directory list to learn the K scheme ids. The structural scheme designer is not invoked again after this.
- **Scheme phase** — round-robin across the K schemes. For each scheme in turn, dispatch design revision engineer (revise that scheme based on its code-compliance examiner's review) then code-compliance examiner (score that scheme). After one round-robin pass through all K schemes, start the next pass. A scheme is considered done in this phase when its code-compliance examiner score reaches 10; stop scheduling more scheme-phase calls for it but continue with the others. After all K schemes hit code-compliance examiner 10, or each scheme has had 10 scheme-phase iterations, move to the calculation phase.
- **Calculation phase** — round-robin across the K schemes. For each scheme in turn, dispatch calculation package engineer (revise that scheme's calculation package based on its independent structural reviewer's review) then independent structural reviewer (score that scheme's calculation package). The pipeline stops when any scheme reaches independent structural reviewer score 10, or each scheme has had 10 calculation-phase iterations.
- When dispatching, always pass the scheme's directory path so the dispatched agent knows which `SCHEME.md` / `CALC_PACKAGE.md` to operate on.
- Keep the current phase, per-scheme iteration counts, per-scheme latest scores, and current scheme index in `STATE.md`, accurate after each dispatch. Read each score from the relevant scheme'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 structural schemes, each in its own `schemes/{id}-{slug}/SCHEME.md`. The K schemes should differ meaningfully in structural concept, gravity system, lateral system, materials, foundation approach, or load-path strategy so distinct routes can be compared downstream, not in trivial ways like changing member labels.

A complete scheme in any `SCHEME.md` has two parts — a formalized structural basis and one chosen compliance strategy.

The **structural basis** must state:

- **Project and code basis** — applicable building code and referenced standards such as IBC, ASCE 7, AISC 360/341, ACI 318, NDS, TMS 402, local amendments, risk category, occupancy, seismic design category, wind exposure, and any project-specific performance criteria.
- **Design data** — key numeric inputs and what each one represents, including spans, story heights, tributary areas, dead loads, live loads, roof loads, snow loads, wind pressures, seismic parameters, soil bearing values, and deflection or drift limits.
- **Structural system** — the proposed gravity system, lateral-force-resisting system, diaphragm concept, foundation type, material grades, and preliminary member families.
- **Load path** — how vertical loads, diaphragm forces, collectors, chords, overturning, shear, and foundation reactions are transferred through the structure.
- **Compliance requirements** — every major strength, stability, serviceability, detailing, fire-resistance, robustness, and foundation check that must be satisfied.

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

- which analysis method, design standard, and calculation workflow to use;
- the governing load combinations and key initial member sizes or assumptions;
- the structural simplification, bracing concept, diaphragm assumption, or detailing approach the route relies on;
- the biggest engineering or code-compliance risk on this route.
</f9>

<f10>
You are working on a structural building design compliance project. The work may involve steel, reinforced concrete, timber, masonry, foundations, lateral-force-resisting systems, existing-building constraints, or a combination. The original project brief is given as a natural-language statement in `project_brief.md`; read it before starting your part.
</f10>

<f11>
Read your assigned scheme's `SCHEME.md`. It carries the code-compliance examiner's `<review>` block. Read that feedback and revise the scheme's `SCHEME.md` in place to address every point raised. Preserve the two-part structure (formalized structural basis plus chosen compliance strategy). Don't discard the scheme and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new schemes. Do not read or touch other schemes' 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 does not comply, but I'm telling you it does not comply" 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. `# project coordinator`). Output only the headered prompts, no preamble.