project coordination engineer
structural assessment engineer
independent calculation checker
retrofit design engineer
building-code plan examiner

I need you to set up a 5-agent pipeline for bridge retrofit engineering. The work alternates between a structural safety assessment and a retrofit design package, with each side informing the other. A bridge condition brief arrives as a natural-language statement in `bridge_brief.md`. The pipeline alternates between revising the assessment (load rating, deterioration assumptions, limit states, demand/capacity findings) and revising the retrofit package (repair details, strengthening scheme, constructability notes, and compliance documentation).

The five agents:

- **project coordination engineer** orchestrates the run by alternating one assessment step with one retrofit design step and tracking progress. This agent does no structural modeling, design, or reviewing itself.
- **assessment loop** — the **structural assessment engineer** writes the structural safety assessment to `ASSESSMENT.md`; the **independent calculation checker** judges it. The structural assessment engineer reads `RETROFIT.md` on each revision pass to incorporate how the proposed strengthening changes member capacities, load paths, or inspection assumptions.
- **retrofit design loop** — the **retrofit design engineer** writes the retrofit design package and calculation summary to `RETROFIT.md`; the **building-code plan examiner** judges them. The retrofit design engineer reads `ASSESSMENT.md` on each revision pass to align the proposed work with the latest deficiencies, governing limit states, and required capacity targets.

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

The pipeline hands work off through three files:

- `bridge_brief.md` — the original bridge description, inspection findings, traffic/loading context, and retrofit objective, read-only. All four domain agents read it.
- `ASSESSMENT.md` — the structural safety assessment. The structural assessment engineer writes; the independent calculation checker reviews; the retrofit design engineer and building-code plan examiner read it to know which members, connections, limit states, and rating factors the retrofit must address.
- `RETROFIT.md` — the retrofit design package and calculation summary. The retrofit design engineer writes; the building-code plan examiner reviews; the structural assessment engineer and independent calculation checker read it to ground the assessment in the actual strengthening scheme and resulting capacities.

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

Unlike a sequential assess-then-design workflow where the assessment must be finalized before retrofit design starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. The assessment may change after seeing the retrofit's strengthening details; the retrofit may change after seeing refined load ratings, deterioration assumptions, or limit-state checks.

I'm providing the following information:

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

<f2>
You orchestrate the run; you never perform structural assessment, retrofit design, or review yourself — you only dispatch the right agent at the right time.

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

<f3>
You are working on a bridge retrofit engineering problem. The original bridge condition and project objective are given as a natural-language statement in `bridge_brief.md`; read it before starting your part. The brief may describe the bridge type, span arrangement, material, age, inspection defects, traffic loading, hydraulic or seismic concerns, available drawings, and the owner's desired retrofit outcome.
</f3>

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

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

<f5>
Produce the structural safety assessment for the bridge and write it to `ASSESSMENT.md`. A complete assessment covers four kinds of claim, each justified with a calculation sketch, a clear engineering assumption, or a citation to the governing specification.

- **Demand and capacity findings** — load effects from dead load, live load, wind, seismic, braking, thermal, stream force, or construction staging as relevant; member and connection capacities for flexure, shear, axial force, fatigue, bearing, buckling, and serviceability.
- **Structural behavior and load path** — continuity, redundancy, composite action, distribution factors, fracture-critical behavior, diaphragm action, bearing restraint, substructure load transfer, and whether deterioration changes the assumed behavior.
- **Required checks and invariants** — equilibrium, load combinations, rating-factor conventions, section-property assumptions, remaining steel area or concrete section loss, minimum bearing seat, clearance, cover, anchorage development, and other quantities every acceptable retrofit must preserve or improve. The retrofit package should satisfy them; the building-code plan examiner will check with `check_compliance.py`.
- **Governing limit states and reliability** — which checks control, whether the bridge is posted, whether temporary works or staged construction govern, and whether the retrofit target is inventory rating, operating rating, service-life extension, seismic performance, scour stability, or another explicit criterion.

Ground your claims against `RETROFIT.md` if it has reported member sizes, plate details, anchors, jacketing, bearing replacements, or recalculated capacities. A predicted deficiency that is inconsistent with the retrofit's reported numbers means either the assessment needs revision or the retrofit calculations have an error — diagnose which side has the issue and state it. Be concrete. "The exterior girder has RF=0.72 in flexure under HL-93 inventory loading, so the retrofit must raise positive-moment capacity by at least 39%" is fine; "some girders may need strengthening" is not.
</f5>

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

<f7>
Match the tool to the bridge type, material, deterioration pattern, and retrofit objective; do not force an ill-suited method. The list below is useful in structural safety assessment.

| Tool | Suitable for |
|---|---|
| AASHTO LRFR load rating | Highway bridges; inventory and operating rating factors for existing members |
| Load combination and limit-state checks | Strength, service, fatigue, extreme event, and construction-stage assessment |
| Refined grillage, line-girder, or finite-element modeling | Complex load distribution, skewed decks, curved girders, diaphragms, staged construction |
| Section loss and remaining-capacity calculations | Corroded steel, spalled concrete, damaged prestressing strands, deteriorated timber |
| Fatigue and fracture evaluation | Steel details with high truck counts, welded attachments, cover plates, fracture-critical members |
| Nonlinear or pushover analysis | Seismic retrofit, ductility checks, yielding mechanisms, bearing or pier vulnerability |
| Scour and foundation stability analysis | Hydraulic vulnerability, undermined footings, pile capacity, countermeasure evaluation |
| Sensitivity and uncertainty analysis | Incomplete drawings, uncertain material strengths, variable deterioration, load posting decisions |
</f7>

<f8>
Read `bridge_brief.md` and `ASSESSMENT.md`, then prepare the retrofit design package:

- Include the governing design assumptions, material specifications, member sizes, connection details, anchor layouts, construction staging constraints, and any required calculations. Define the retrofit scope exactly as the bridge brief and assessment require.
- Make the package testable against `ASSESSMENT.md`. If the assessment states a required rating factor target, your retrofit should meet or exceed it. If the assessment states a load-path invariant, clearance requirement, fatigue concern, or constructability constraint, your design should satisfy it.
- Work the calculations through to completion — do not stop with a placeholder detail or an unresolved "to be designed later" item. If a check fails, find and fix the root cause; do not bury failures in caveats.
- Sanity-check the package against `ASSESSMENT.md`. A quantity that must be a whole number of anchors should not come back fractional; a required rating factor or code limit the assessment says must hold should hold.

Write the retrofit design package and its calculation results up in `RETROFIT.md`.
</f8>

<f9>
Review `RETROFIT.md` against `bridge_brief.md` and against `ASSESSMENT.md`.

- Inspect the reported retrofit result for anomalies, unreasonable member sizes, missing connection capacity, constructability conflicts, or violations of constraints stated directly in `bridge_brief.md`.
- Open `ASSESSMENT.md`. For every required rating factor, load-path condition, limit-state check, and invariant the assessment claims, write a check into a separate `check_compliance.py`: does the retrofit satisfy the stated capacity target, preserve the required clearance or geometry, meet the anchorage or connection demand, and address the governing deficiency? Run it. Name any member, detail, or quantity that violates.
- Read the retrofit design package and spot-check it for defects — omitted load combinations, unused deterioration assumptions, dead calculations, connection details that do not match the selected strengthening scheme, or logic that contradicts the assessment. A defect that silently leaves an unsafe bridge condition is worse than one that is obvious.
- Treat the package as finished only when every stated project constraint holds, every assessment-claimed invariant holds, and the retrofit capacities are consistent with the assessment's demands — not merely when the document looks complete.
- Check the length of `RETROFIT.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `RETROFIT.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f9>

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

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

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

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

<f11>
The structural safety assessment lives in `ASSESSMENT.md`, and you may be invoked on it more than once — the pipeline runs you and the independent calculation checker as a loop, alternating with the retrofit design loop.

- If `ASSESSMENT.md` does not exist yet, this is the first pass: produce the assessment from scratch based on `bridge_brief.md`.
- If `ASSESSMENT.md` already exists, it carries the independent calculation checker's `<review>` block. Read that feedback. Then open `RETROFIT.md` and look at the latest reported retrofit details and recalculated capacities — they may invalidate, sharpen, or motivate revisions to your findings. Revise `ASSESSMENT.md` in place to address every reviewer point raised and to incorporate any retrofit evidence that changes your assessment. Don't discard the previous assessment and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
Review `ASSESSMENT.md` against `bridge_brief.md` and against the retrofit quantities and capacities reported in `RETROFIT.md` (if any).

- **Faithfulness** — does the assessment correctly describe the bridge stated in `bridge_brief.md`? Check span lengths, framing, materials, deterioration, traffic loading, environmental hazards, member types, and any constraints from the owner or agency.
- **Calculation soundness** — for each claim, walk through the calculation sketch or cited specification provision. Flag hand-waving steps. Verify load factors, resistance factors, distribution factors, section properties, deterioration reductions, and limit-state assumptions apply under the stated conditions.
- **Design grounding** — open `RETROFIT.md`. If the retrofit reports plate sizes, jacketing dimensions, anchor capacities, bearing replacements, or revised rating factors, do they satisfy the assessment's predicted needs? A required strengthening demand that is far from the design's reported capacity is a signal that the assessment is too crude, the retrofit calculation is wrong, or the governing limit state has been misidentified; state which.

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

<f13>
The retrofit design package and its calculation results live in `RETROFIT.md`, and you may be invoked on it more than once — the pipeline runs you and the building-code plan examiner as a loop, alternating with the assessment loop.

- If `RETROFIT.md` does not exist yet, this is the first pass: produce the retrofit package from scratch based on `bridge_brief.md`.
- If `RETROFIT.md` already exists, it carries the building-code plan examiner's `<review>` block. Read that feedback. Then open `ASSESSMENT.md` and check whether the latest assessment introduces required rating factors, governing limit states, load-path requirements, or structural invariants your current retrofit does not yet satisfy — for example a fatigue detail your plates worsen, a bearing restraint condition your design changes, or a tighter flexural capacity target your strengthening is now below. Revise `RETROFIT.md` in place to address every reviewer point and to align with the latest assessment. Don't discard the previous package and start over, and don't leave a flagged issue unaddressed.
</f13>

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

I need you to set up a 5-agent pipeline for bridge retrofit engineering. The work alternates between a structural safety assessment and a retrofit design package, with each side informing the other. A bridge condition brief arrives as a natural-language statement in `bridge_brief.md`. The pipeline alternates between revising the assessment (load rating, deterioration assumptions, limit states, demand/capacity findings) and revising the retrofit package (repair details, strengthening scheme, constructability notes, and compliance documentation).

The five agents:

- **project coordination engineer** orchestrates the run by alternating one assessment step with one retrofit design step and tracking progress. This agent does no structural modeling, design, or reviewing itself.
- **assessment loop** — the **structural assessment engineer** writes the structural safety assessment to `ASSESSMENT.md`; the **independent calculation checker** judges it. The structural assessment engineer reads `RETROFIT.md` on each revision pass to incorporate how the proposed strengthening changes member capacities, load paths, or inspection assumptions.
- **retrofit design loop** — the **retrofit design engineer** writes the retrofit design package and calculation summary to `RETROFIT.md`; the **building-code plan examiner** judges them. The retrofit design engineer reads `ASSESSMENT.md` on each revision pass to align the proposed work with the latest deficiencies, governing limit states, and required capacity targets.

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

The pipeline hands work off through three files:

- `bridge_brief.md` — the original bridge description, inspection findings, traffic/loading context, and retrofit objective, read-only. All four domain agents read it.
- `ASSESSMENT.md` — the structural safety assessment. The structural assessment engineer writes; the independent calculation checker reviews; the retrofit design engineer and building-code plan examiner read it to know which members, connections, limit states, and rating factors the retrofit must address.
- `RETROFIT.md` — the retrofit design package and calculation summary. The retrofit design engineer writes; the building-code plan examiner reviews; the structural assessment engineer and independent calculation checker read it to ground the assessment in the actual strengthening scheme and resulting capacities.

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

Unlike a sequential assess-then-design workflow where the assessment must be finalized before retrofit design starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. The assessment may change after seeing the retrofit's strengthening details; the retrofit may change after seeing refined load ratings, deterioration assumptions, or limit-state checks.

I'm providing the following prompt fragments:

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

<f2>
You orchestrate the run; you never perform structural assessment, retrofit design, or review yourself — you only dispatch the right agent at the right time.

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

<f3>
You are working on a bridge retrofit engineering problem. The original bridge condition and project objective are given as a natural-language statement in `bridge_brief.md`; read it before starting your part. The brief may describe the bridge type, span arrangement, material, age, inspection defects, traffic loading, hydraulic or seismic concerns, available drawings, and the owner's desired retrofit outcome.
</f3>

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

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

<f5>
Produce the structural safety assessment for the bridge and write it to `ASSESSMENT.md`. A complete assessment covers four kinds of claim, each justified with a calculation sketch, a clear engineering assumption, or a citation to the governing specification.

- **Demand and capacity findings** — load effects from dead load, live load, wind, seismic, braking, thermal, stream force, or construction staging as relevant; member and connection capacities for flexure, shear, axial force, fatigue, bearing, buckling, and serviceability.
- **Structural behavior and load path** — continuity, redundancy, composite action, distribution factors, fracture-critical behavior, diaphragm action, bearing restraint, substructure load transfer, and whether deterioration changes the assumed behavior.
- **Required checks and invariants** — equilibrium, load combinations, rating-factor conventions, section-property assumptions, remaining steel area or concrete section loss, minimum bearing seat, clearance, cover, anchorage development, and other quantities every acceptable retrofit must preserve or improve. The retrofit package should satisfy them; the building-code plan examiner will check with `check_compliance.py`.
- **Governing limit states and reliability** — which checks control, whether the bridge is posted, whether temporary works or staged construction govern, and whether the retrofit target is inventory rating, operating rating, service-life extension, seismic performance, scour stability, or another explicit criterion.

Ground your claims against `RETROFIT.md` if it has reported member sizes, plate details, anchors, jacketing, bearing replacements, or recalculated capacities. A predicted deficiency that is inconsistent with the retrofit's reported numbers means either the assessment needs revision or the retrofit calculations have an error — diagnose which side has the issue and state it. Be concrete. "The exterior girder has RF=0.72 in flexure under HL-93 inventory loading, so the retrofit must raise positive-moment capacity by at least 39%" is fine; "some girders may need strengthening" is not.
</f5>

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

<f7>
Match the tool to the bridge type, material, deterioration pattern, and retrofit objective; do not force an ill-suited method. The list below is useful in structural safety assessment.

| Tool | Suitable for |
|---|---|
| AASHTO LRFR load rating | Highway bridges; inventory and operating rating factors for existing members |
| Load combination and limit-state checks | Strength, service, fatigue, extreme event, and construction-stage assessment |
| Refined grillage, line-girder, or finite-element modeling | Complex load distribution, skewed decks, curved girders, diaphragms, staged construction |
| Section loss and remaining-capacity calculations | Corroded steel, spalled concrete, damaged prestressing strands, deteriorated timber |
| Fatigue and fracture evaluation | Steel details with high truck counts, welded attachments, cover plates, fracture-critical members |
| Nonlinear or pushover analysis | Seismic retrofit, ductility checks, yielding mechanisms, bearing or pier vulnerability |
| Scour and foundation stability analysis | Hydraulic vulnerability, undermined footings, pile capacity, countermeasure evaluation |
| Sensitivity and uncertainty analysis | Incomplete drawings, uncertain material strengths, variable deterioration, load posting decisions |
</f7>

<f8>
Read `bridge_brief.md` and `ASSESSMENT.md`, then prepare the retrofit design package:

- Include the governing design assumptions, material specifications, member sizes, connection details, anchor layouts, construction staging constraints, and any required calculations. Define the retrofit scope exactly as the bridge brief and assessment require.
- Make the package testable against `ASSESSMENT.md`. If the assessment states a required rating factor target, your retrofit should meet or exceed it. If the assessment states a load-path invariant, clearance requirement, fatigue concern, or constructability constraint, your design should satisfy it.
- Work the calculations through to completion — do not stop with a placeholder detail or an unresolved "to be designed later" item. If a check fails, find and fix the root cause; do not bury failures in caveats.
- Sanity-check the package against `ASSESSMENT.md`. A quantity that must be a whole number of anchors should not come back fractional; a required rating factor or code limit the assessment says must hold should hold.

Write the retrofit design package and its calculation results up in `RETROFIT.md`.
</f8>

<f9>
Review `RETROFIT.md` against `bridge_brief.md` and against `ASSESSMENT.md`.

- Inspect the reported retrofit result for anomalies, unreasonable member sizes, missing connection capacity, constructability conflicts, or violations of constraints stated directly in `bridge_brief.md`.
- Open `ASSESSMENT.md`. For every required rating factor, load-path condition, limit-state check, and invariant the assessment claims, write a check into a separate `check_compliance.py`: does the retrofit satisfy the stated capacity target, preserve the required clearance or geometry, meet the anchorage or connection demand, and address the governing deficiency? Run it. Name any member, detail, or quantity that violates.
- Read the retrofit design package and spot-check it for defects — omitted load combinations, unused deterioration assumptions, dead calculations, connection details that do not match the selected strengthening scheme, or logic that contradicts the assessment. A defect that silently leaves an unsafe bridge condition is worse than one that is obvious.
- Treat the package as finished only when every stated project constraint holds, every assessment-claimed invariant holds, and the retrofit capacities are consistent with the assessment's demands — not merely when the document looks complete.
- Check the length of `RETROFIT.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `RETROFIT.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f9>

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

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

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

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

<f11>
The structural safety assessment lives in `ASSESSMENT.md`, and you may be invoked on it more than once — the pipeline runs you and the independent calculation checker as a loop, alternating with the retrofit design loop.

- If `ASSESSMENT.md` does not exist yet, this is the first pass: produce the assessment from scratch based on `bridge_brief.md`.
- If `ASSESSMENT.md` already exists, it carries the independent calculation checker's `<review>` block. Read that feedback. Then open `RETROFIT.md` and look at the latest reported retrofit details and recalculated capacities — they may invalidate, sharpen, or motivate revisions to your findings. Revise `ASSESSMENT.md` in place to address every reviewer point raised and to incorporate any retrofit evidence that changes your assessment. Don't discard the previous assessment and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
Review `ASSESSMENT.md` against `bridge_brief.md` and against the retrofit quantities and capacities reported in `RETROFIT.md` (if any).

- **Faithfulness** — does the assessment correctly describe the bridge stated in `bridge_brief.md`? Check span lengths, framing, materials, deterioration, traffic loading, environmental hazards, member types, and any constraints from the owner or agency.
- **Calculation soundness** — for each claim, walk through the calculation sketch or cited specification provision. Flag hand-waving steps. Verify load factors, resistance factors, distribution factors, section properties, deterioration reductions, and limit-state assumptions apply under the stated conditions.
- **Design grounding** — open `RETROFIT.md`. If the retrofit reports plate sizes, jacketing dimensions, anchor capacities, bearing replacements, or revised rating factors, do they satisfy the assessment's predicted needs? A required strengthening demand that is far from the design's reported capacity is a signal that the assessment is too crude, the retrofit calculation is wrong, or the governing limit state has been misidentified; state which.

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

<f13>
The retrofit design package and its calculation results live in `RETROFIT.md`, and you may be invoked on it more than once — the pipeline runs you and the building-code plan examiner as a loop, alternating with the assessment loop.

- If `RETROFIT.md` does not exist yet, this is the first pass: produce the retrofit package from scratch based on `bridge_brief.md`.
- If `RETROFIT.md` already exists, it carries the building-code plan examiner's `<review>` block. Read that feedback. Then open `ASSESSMENT.md` and check whether the latest assessment introduces required rating factors, governing limit states, load-path requirements, or structural invariants your current retrofit does not yet satisfy — for example a fatigue detail your plates worsen, a bearing restraint condition your design changes, or a tighter flexural capacity target your strengthening is now below. Revise `RETROFIT.md` in place to address every reviewer point and to align with the latest assessment. Don't discard the previous package and start over, and don't leave a flagged issue unaddressed.
</f13>

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


I need you to set up a 5-agent pipeline for bridge retrofit engineering. The work alternates between a structural safety assessment and a retrofit design package, with each side informing the other. A bridge condition brief arrives as a natural-language statement in `bridge_brief.md`. The pipeline alternates between revising the assessment (load rating, deterioration assumptions, limit states, demand/capacity findings) and revising the retrofit package (repair details, strengthening scheme, constructability notes, and compliance documentation).

The five agents:

- **project coordination engineer** orchestrates the run by alternating one assessment step with one retrofit design step and tracking progress. This agent does no structural modeling, design, or reviewing itself.
- **assessment loop** — the **structural assessment engineer** writes the structural safety assessment to `ASSESSMENT.md`; the **independent calculation checker** judges it. The structural assessment engineer reads `RETROFIT.md` on each revision pass to incorporate how the proposed strengthening changes member capacities, load paths, or inspection assumptions.
- **retrofit design loop** — the **retrofit design engineer** writes the retrofit design package and calculation summary to `RETROFIT.md`; the **building-code plan examiner** judges them. The retrofit design engineer reads `ASSESSMENT.md` on each revision pass to align the proposed work with the latest deficiencies, governing limit states, and required capacity targets.

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

The pipeline hands work off through three files:

- `bridge_brief.md` — the original bridge description, inspection findings, traffic/loading context, and retrofit objective, read-only. All four domain agents read it.
- `ASSESSMENT.md` — the structural safety assessment. The structural assessment engineer writes; the independent calculation checker reviews; the retrofit design engineer and building-code plan examiner read it to know which members, connections, limit states, and rating factors the retrofit must address.
- `RETROFIT.md` — the retrofit design package and calculation summary. The retrofit design engineer writes; the building-code plan examiner reviews; the structural assessment engineer and independent calculation checker read it to ground the assessment in the actual strengthening scheme and resulting capacities.

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

Unlike a sequential assess-then-design workflow where the assessment must be finalized before retrofit design starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. The assessment may change after seeing the retrofit's strengthening details; the retrofit may change after seeing refined load ratings, deterioration assumptions, or limit-state checks.

I'm providing the following information:

<f1>
Read `bridge_brief.md` and `ASSESSMENT.md`, then prepare the retrofit design package:

- Include the governing design assumptions, material specifications, member sizes, connection details, anchor layouts, construction staging constraints, and any required calculations. Define the retrofit scope exactly as the bridge brief and assessment require.
- Make the package testable against `ASSESSMENT.md`. If the assessment states a required rating factor target, your retrofit should meet or exceed it. If the assessment states a load-path invariant, clearance requirement, fatigue concern, or constructability constraint, your design should satisfy it.
- Work the calculations through to completion — do not stop with a placeholder detail or an unresolved "to be designed later" item. If a check fails, find and fix the root cause; do not bury failures in caveats.
- Sanity-check the package against `ASSESSMENT.md`. A quantity that must be a whole number of anchors should not come back fractional; a required rating factor or code limit the assessment says must hold should hold.

Write the retrofit design package and its calculation results up in `RETROFIT.md`.
</f1>

<f2>
Match the tool to the bridge type, material, deterioration pattern, and retrofit objective; do not force an ill-suited method. The list below is useful in structural safety assessment.

| Tool | Suitable for |
|---|---|
| AASHTO LRFR load rating | Highway bridges; inventory and operating rating factors for existing members |
| Load combination and limit-state checks | Strength, service, fatigue, extreme event, and construction-stage assessment |
| Refined grillage, line-girder, or finite-element modeling | Complex load distribution, skewed decks, curved girders, diaphragms, staged construction |
| Section loss and remaining-capacity calculations | Corroded steel, spalled concrete, damaged prestressing strands, deteriorated timber |
| Fatigue and fracture evaluation | Steel details with high truck counts, welded attachments, cover plates, fracture-critical members |
| Nonlinear or pushover analysis | Seismic retrofit, ductility checks, yielding mechanisms, bearing or pier vulnerability |
| Scour and foundation stability analysis | Hydraulic vulnerability, undermined footings, pile capacity, countermeasure evaluation |
| Sensitivity and uncertainty analysis | Incomplete drawings, uncertain material strengths, variable deterioration, load posting decisions |
</f2>

<f3>
The retrofit design package and its calculation results live in `RETROFIT.md`, and you may be invoked on it more than once — the pipeline runs you and the building-code plan examiner as a loop, alternating with the assessment loop.

- If `RETROFIT.md` does not exist yet, this is the first pass: produce the retrofit package from scratch based on `bridge_brief.md`.
- If `RETROFIT.md` already exists, it carries the building-code plan examiner's `<review>` block. Read that feedback. Then open `ASSESSMENT.md` and check whether the latest assessment introduces required rating factors, governing limit states, load-path requirements, or structural invariants your current retrofit does not yet satisfy — for example a fatigue detail your plates worsen, a bearing restraint condition your design changes, or a tighter flexural capacity target your strengthening is now below. Revise `RETROFIT.md` in place to address every reviewer point and to align with the latest assessment. Don't discard the previous package and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review `ASSESSMENT.md` against `bridge_brief.md` and against the retrofit quantities and capacities reported in `RETROFIT.md` (if any).

- **Faithfulness** — does the assessment correctly describe the bridge stated in `bridge_brief.md`? Check span lengths, framing, materials, deterioration, traffic loading, environmental hazards, member types, and any constraints from the owner or agency.
- **Calculation soundness** — for each claim, walk through the calculation sketch or cited specification provision. Flag hand-waving steps. Verify load factors, resistance factors, distribution factors, section properties, deterioration reductions, and limit-state assumptions apply under the stated conditions.
- **Design grounding** — open `RETROFIT.md`. If the retrofit reports plate sizes, jacketing dimensions, anchor capacities, bearing replacements, or revised rating factors, do they satisfy the assessment's predicted needs? A required strengthening demand that is far from the design's reported capacity is a signal that the assessment is too crude, the retrofit calculation is wrong, or the governing limit state has been misidentified; state which.

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

<f5>
You orchestrate the run; you never perform structural assessment, retrofit design, or review yourself — you only dispatch the right agent at the right time.

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

<f6>
Produce the structural safety assessment for the bridge and write it to `ASSESSMENT.md`. A complete assessment covers four kinds of claim, each justified with a calculation sketch, a clear engineering assumption, or a citation to the governing specification.

- **Demand and capacity findings** — load effects from dead load, live load, wind, seismic, braking, thermal, stream force, or construction staging as relevant; member and connection capacities for flexure, shear, axial force, fatigue, bearing, buckling, and serviceability.
- **Structural behavior and load path** — continuity, redundancy, composite action, distribution factors, fracture-critical behavior, diaphragm action, bearing restraint, substructure load transfer, and whether deterioration changes the assumed behavior.
- **Required checks and invariants** — equilibrium, load combinations, rating-factor conventions, section-property assumptions, remaining steel area or concrete section loss, minimum bearing seat, clearance, cover, anchorage development, and other quantities every acceptable retrofit must preserve or improve. The retrofit package should satisfy them; the building-code plan examiner will check with `check_compliance.py`.
- **Governing limit states and reliability** — which checks control, whether the bridge is posted, whether temporary works or staged construction govern, and whether the retrofit target is inventory rating, operating rating, service-life extension, seismic performance, scour stability, or another explicit criterion.

Ground your claims against `RETROFIT.md` if it has reported member sizes, plate details, anchors, jacketing, bearing replacements, or recalculated capacities. A predicted deficiency that is inconsistent with the retrofit's reported numbers means either the assessment needs revision or the retrofit calculations have an error — diagnose which side has the issue and state it. Be concrete. "The exterior girder has RF=0.72 in flexure under HL-93 inventory loading, so the retrofit must raise positive-moment capacity by at least 39%" is fine; "some girders may need strengthening" is not.
</f6>

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

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

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

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

<f10>
XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs. Wrapping each type of content in its own tag (e.g. `<instructions>`, `<context>`, `<input>`) reduces misinterpretation.

Best practices:
- Use consistent, descriptive tag names across your prompts.
- Nest tags when content has a natural hierarchy (documents inside `<documents>`, each inside `<document index="n">`).
</f10>

<f11>
You are working on a bridge retrofit engineering problem. The original bridge condition and project objective are given as a natural-language statement in `bridge_brief.md`; read it before starting your part. The brief may describe the bridge type, span arrangement, material, age, inspection defects, traffic loading, hydraulic or seismic concerns, available drawings, and the owner's desired retrofit outcome.
</f11>

<f12>
The structural safety assessment lives in `ASSESSMENT.md`, and you may be invoked on it more than once — the pipeline runs you and the independent calculation checker as a loop, alternating with the retrofit design loop.

- If `ASSESSMENT.md` does not exist yet, this is the first pass: produce the assessment from scratch based on `bridge_brief.md`.
- If `ASSESSMENT.md` already exists, it carries the independent calculation checker's `<review>` block. Read that feedback. Then open `RETROFIT.md` and look at the latest reported retrofit details and recalculated capacities — they may invalidate, sharpen, or motivate revisions to your findings. Revise `ASSESSMENT.md` in place to address every reviewer point raised and to incorporate any retrofit evidence that changes your assessment. Don't discard the previous assessment and start over, and don't leave a flagged issue unaddressed.
</f12>

<f13>
Review `RETROFIT.md` against `bridge_brief.md` and against `ASSESSMENT.md`.

- Inspect the reported retrofit result for anomalies, unreasonable member sizes, missing connection capacity, constructability conflicts, or violations of constraints stated directly in `bridge_brief.md`.
- Open `ASSESSMENT.md`. For every required rating factor, load-path condition, limit-state check, and invariant the assessment claims, write a check into a separate `check_compliance.py`: does the retrofit satisfy the stated capacity target, preserve the required clearance or geometry, meet the anchorage or connection demand, and address the governing deficiency? Run it. Name any member, detail, or quantity that violates.
- Read the retrofit design package and spot-check it for defects — omitted load combinations, unused deterioration assumptions, dead calculations, connection details that do not match the selected strengthening scheme, or logic that contradicts the assessment. A defect that silently leaves an unsafe bridge condition is worse than one that is obvious.
- Treat the package as finished only when every stated project constraint holds, every assessment-claimed invariant holds, and the retrofit capacities are consistent with the assessment's demands — not merely when the document looks complete.
- Check the length of `RETROFIT.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `RETROFIT.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f13>

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

I need you to set up a 5-agent pipeline for bridge retrofit engineering. The work alternates between a structural safety assessment and a retrofit design package, with each side informing the other. A bridge condition brief arrives as a natural-language statement in `bridge_brief.md`. The pipeline alternates between revising the assessment (load rating, deterioration assumptions, limit states, demand/capacity findings) and revising the retrofit package (repair details, strengthening scheme, constructability notes, and compliance documentation).

The five agents:

- **project coordination engineer** orchestrates the run by alternating one assessment step with one retrofit design step and tracking progress. This agent does no structural modeling, design, or reviewing itself.
- **assessment loop** — the **structural assessment engineer** writes the structural safety assessment to `ASSESSMENT.md`; the **independent calculation checker** judges it. The structural assessment engineer reads `RETROFIT.md` on each revision pass to incorporate how the proposed strengthening changes member capacities, load paths, or inspection assumptions.
- **retrofit design loop** — the **retrofit design engineer** writes the retrofit design package and calculation summary to `RETROFIT.md`; the **building-code plan examiner** judges them. The retrofit design engineer reads `ASSESSMENT.md` on each revision pass to align the proposed work with the latest deficiencies, governing limit states, and required capacity targets.

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

The pipeline hands work off through three files:

- `bridge_brief.md` — the original bridge description, inspection findings, traffic/loading context, and retrofit objective, read-only. All four domain agents read it.
- `ASSESSMENT.md` — the structural safety assessment. The structural assessment engineer writes; the independent calculation checker reviews; the retrofit design engineer and building-code plan examiner read it to know which members, connections, limit states, and rating factors the retrofit must address.
- `RETROFIT.md` — the retrofit design package and calculation summary. The retrofit design engineer writes; the building-code plan examiner reviews; the structural assessment engineer and independent calculation checker read it to ground the assessment in the actual strengthening scheme and resulting capacities.

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

Unlike a sequential assess-then-design workflow where the assessment must be finalized before retrofit design starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. The assessment may change after seeing the retrofit's strengthening details; the retrofit may change after seeing refined load ratings, deterioration assumptions, or limit-state checks.

I'm providing the following prompt fragments:

<f1>
Read `bridge_brief.md` and `ASSESSMENT.md`, then prepare the retrofit design package:

- Include the governing design assumptions, material specifications, member sizes, connection details, anchor layouts, construction staging constraints, and any required calculations. Define the retrofit scope exactly as the bridge brief and assessment require.
- Make the package testable against `ASSESSMENT.md`. If the assessment states a required rating factor target, your retrofit should meet or exceed it. If the assessment states a load-path invariant, clearance requirement, fatigue concern, or constructability constraint, your design should satisfy it.
- Work the calculations through to completion — do not stop with a placeholder detail or an unresolved "to be designed later" item. If a check fails, find and fix the root cause; do not bury failures in caveats.
- Sanity-check the package against `ASSESSMENT.md`. A quantity that must be a whole number of anchors should not come back fractional; a required rating factor or code limit the assessment says must hold should hold.

Write the retrofit design package and its calculation results up in `RETROFIT.md`.
</f1>

<f2>
Match the tool to the bridge type, material, deterioration pattern, and retrofit objective; do not force an ill-suited method. The list below is useful in structural safety assessment.

| Tool | Suitable for |
|---|---|
| AASHTO LRFR load rating | Highway bridges; inventory and operating rating factors for existing members |
| Load combination and limit-state checks | Strength, service, fatigue, extreme event, and construction-stage assessment |
| Refined grillage, line-girder, or finite-element modeling | Complex load distribution, skewed decks, curved girders, diaphragms, staged construction |
| Section loss and remaining-capacity calculations | Corroded steel, spalled concrete, damaged prestressing strands, deteriorated timber |
| Fatigue and fracture evaluation | Steel details with high truck counts, welded attachments, cover plates, fracture-critical members |
| Nonlinear or pushover analysis | Seismic retrofit, ductility checks, yielding mechanisms, bearing or pier vulnerability |
| Scour and foundation stability analysis | Hydraulic vulnerability, undermined footings, pile capacity, countermeasure evaluation |
| Sensitivity and uncertainty analysis | Incomplete drawings, uncertain material strengths, variable deterioration, load posting decisions |
</f2>

<f3>
The retrofit design package and its calculation results live in `RETROFIT.md`, and you may be invoked on it more than once — the pipeline runs you and the building-code plan examiner as a loop, alternating with the assessment loop.

- If `RETROFIT.md` does not exist yet, this is the first pass: produce the retrofit package from scratch based on `bridge_brief.md`.
- If `RETROFIT.md` already exists, it carries the building-code plan examiner's `<review>` block. Read that feedback. Then open `ASSESSMENT.md` and check whether the latest assessment introduces required rating factors, governing limit states, load-path requirements, or structural invariants your current retrofit does not yet satisfy — for example a fatigue detail your plates worsen, a bearing restraint condition your design changes, or a tighter flexural capacity target your strengthening is now below. Revise `RETROFIT.md` in place to address every reviewer point and to align with the latest assessment. Don't discard the previous package and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review `ASSESSMENT.md` against `bridge_brief.md` and against the retrofit quantities and capacities reported in `RETROFIT.md` (if any).

- **Faithfulness** — does the assessment correctly describe the bridge stated in `bridge_brief.md`? Check span lengths, framing, materials, deterioration, traffic loading, environmental hazards, member types, and any constraints from the owner or agency.
- **Calculation soundness** — for each claim, walk through the calculation sketch or cited specification provision. Flag hand-waving steps. Verify load factors, resistance factors, distribution factors, section properties, deterioration reductions, and limit-state assumptions apply under the stated conditions.
- **Design grounding** — open `RETROFIT.md`. If the retrofit reports plate sizes, jacketing dimensions, anchor capacities, bearing replacements, or revised rating factors, do they satisfy the assessment's predicted needs? A required strengthening demand that is far from the design's reported capacity is a signal that the assessment is too crude, the retrofit calculation is wrong, or the governing limit state has been misidentified; state which.

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

<f5>
You orchestrate the run; you never perform structural assessment, retrofit design, or review yourself — you only dispatch the right agent at the right time.

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

<f6>
Produce the structural safety assessment for the bridge and write it to `ASSESSMENT.md`. A complete assessment covers four kinds of claim, each justified with a calculation sketch, a clear engineering assumption, or a citation to the governing specification.

- **Demand and capacity findings** — load effects from dead load, live load, wind, seismic, braking, thermal, stream force, or construction staging as relevant; member and connection capacities for flexure, shear, axial force, fatigue, bearing, buckling, and serviceability.
- **Structural behavior and load path** — continuity, redundancy, composite action, distribution factors, fracture-critical behavior, diaphragm action, bearing restraint, substructure load transfer, and whether deterioration changes the assumed behavior.
- **Required checks and invariants** — equilibrium, load combinations, rating-factor conventions, section-property assumptions, remaining steel area or concrete section loss, minimum bearing seat, clearance, cover, anchorage development, and other quantities every acceptable retrofit must preserve or improve. The retrofit package should satisfy them; the building-code plan examiner will check with `check_compliance.py`.
- **Governing limit states and reliability** — which checks control, whether the bridge is posted, whether temporary works or staged construction govern, and whether the retrofit target is inventory rating, operating rating, service-life extension, seismic performance, scour stability, or another explicit criterion.

Ground your claims against `RETROFIT.md` if it has reported member sizes, plate details, anchors, jacketing, bearing replacements, or recalculated capacities. A predicted deficiency that is inconsistent with the retrofit's reported numbers means either the assessment needs revision or the retrofit calculations have an error — diagnose which side has the issue and state it. Be concrete. "The exterior girder has RF=0.72 in flexure under HL-93 inventory loading, so the retrofit must raise positive-moment capacity by at least 39%" is fine; "some girders may need strengthening" is not.
</f6>

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

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

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

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

<f10>
XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs. Wrapping each type of content in its own tag (e.g. `<instructions>`, `<context>`, `<input>`) reduces misinterpretation.

Best practices:
- Use consistent, descriptive tag names across your prompts.
- Nest tags when content has a natural hierarchy (documents inside `<documents>`, each inside `<document index="n">`).
</f10>

<f11>
You are working on a bridge retrofit engineering problem. The original bridge condition and project objective are given as a natural-language statement in `bridge_brief.md`; read it before starting your part. The brief may describe the bridge type, span arrangement, material, age, inspection defects, traffic loading, hydraulic or seismic concerns, available drawings, and the owner's desired retrofit outcome.
</f11>

<f12>
The structural safety assessment lives in `ASSESSMENT.md`, and you may be invoked on it more than once — the pipeline runs you and the independent calculation checker as a loop, alternating with the retrofit design loop.

- If `ASSESSMENT.md` does not exist yet, this is the first pass: produce the assessment from scratch based on `bridge_brief.md`.
- If `ASSESSMENT.md` already exists, it carries the independent calculation checker's `<review>` block. Read that feedback. Then open `RETROFIT.md` and look at the latest reported retrofit details and recalculated capacities — they may invalidate, sharpen, or motivate revisions to your findings. Revise `ASSESSMENT.md` in place to address every reviewer point raised and to incorporate any retrofit evidence that changes your assessment. Don't discard the previous assessment and start over, and don't leave a flagged issue unaddressed.
</f12>

<f13>
Review `RETROFIT.md` against `bridge_brief.md` and against `ASSESSMENT.md`.

- Inspect the reported retrofit result for anomalies, unreasonable member sizes, missing connection capacity, constructability conflicts, or violations of constraints stated directly in `bridge_brief.md`.
- Open `ASSESSMENT.md`. For every required rating factor, load-path condition, limit-state check, and invariant the assessment claims, write a check into a separate `check_compliance.py`: does the retrofit satisfy the stated capacity target, preserve the required clearance or geometry, meet the anchorage or connection demand, and address the governing deficiency? Run it. Name any member, detail, or quantity that violates.
- Read the retrofit design package and spot-check it for defects — omitted load combinations, unused deterioration assumptions, dead calculations, connection details that do not match the selected strengthening scheme, or logic that contradicts the assessment. A defect that silently leaves an unsafe bridge condition is worse than one that is obvious.
- Treat the package as finished only when every stated project constraint holds, every assessment-claimed invariant holds, and the retrofit capacities are consistent with the assessment's demands — not merely when the document looks complete.
- Check the length of `RETROFIT.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `RETROFIT.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f13>

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


incident coordination officer
fire behavior analyst
red-team fire model reviewer
operations plan chief
incident safety officer

I need you to set up a 5-agent pipeline that develops a wildfire incident response plan by refining fire-behavior forecasts and tactical operations planning in parallel, with each side informing the other. An incident package arrives as a natural-language briefing in `incident.md`. The pipeline alternates between revising the forecast assumptions (spread potential, trigger points, weather sensitivities, exposure concerns) and revising the operations plan (divisions, resources, tactics, contingencies, and safety controls).

The five agents:

- **incident coordination officer** orchestrates the run by alternating one fire-behavior step with one operations step and tracking progress. It does no forecasting, tactical planning, or reviewing itself.
- **fire-behavior loop** — the **fire behavior analyst** writes the forecast and fire-behavior rationale to `FORECAST.md`; the **red-team fire model reviewer** challenges it. The fire behavior analyst reads `IAP.md` on each revision pass to incorporate operational observations, resource constraints, and field-reported conditions.
- **operations loop** — the **operations plan chief** writes the tactical incident action plan to `IAP.md`; the **incident safety officer** judges it. The operations plan chief reads `FORECAST.md` on each revision pass to align tactics with the latest fire-behavior claims.

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

The pipeline hands work off through three files:

- `incident.md` — the original incident briefing, read-only. All four domain agents read it.
- `FORECAST.md` — the fire-behavior forecast and rationale. Fire behavior analyst writes; red-team fire model reviewer reviews; operations plan chief and incident safety officer read it to know which spread scenarios, trigger points, and exposure risks the plan must respect.
- `IAP.md` — the tactical operations plan and operational results. Operations plan chief writes; incident safety officer reviews; fire behavior analyst and red-team fire model reviewer read it to ground the forecast in actual assignments, access limits, and field constraints.

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

Unlike a forecast-then-plan pipeline where modeling must settle before tactics start, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. Forecast assumptions may tighten after seeing operational reports and feasible resource deployments; the operations plan may change after seeing a revised wind scenario, spotting-probability assessment, or evacuation trigger.

I'm providing the following information:

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

<f2>
You orchestrate the run; you never forecast, plan tactics, or review yourself — you only assign the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Assign the fire behavior analyst for the first forecast step (fire behavior analyst, then red-team fire model reviewer), then the operations plan chief for the first operations step (operations plan chief, then incident safety officer).
- **Alternation loop** — alternate one fire-behavior step with one operations step. Neither side terminates early on its own score; even a strong-looking forecast may need revision once the operations plan exposes resource constraints or field observations.
- Cap the total at 20 iterations (10 fire-behavior steps + 10 operations steps). After the cap, stop and summarize.
- Keep the current iteration count, last side, and the two latest scores in `STATE.md`, accurate after each assignment. Read each score from the reviewer’s `<review score=X>` block. Commit progress after each step.
- Read each agent’s brief narrative reply on return. If an agent reports an unresolved error, append it to `error-log.txt` (timestamp + agent name + content) and continue with the next step.
</f2>

<f3>
You are working on a wildfire incident response planning problem. The original incident is given as a natural-language briefing in `incident.md`; read it before starting your part. It may describe fuels, topography, forecast weather, communities at risk, roads and access points, available crews and equipment, aviation limits, evacuation concerns, and command objectives.
</f3>

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

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — “this is unsafe, but I am telling you it is unsafe” is still a failing result, not a passing one.
</f4>

<f5>
Produce the fire-behavior forecast for the incident and write it to `FORECAST.md`. A complete forecast covers four kinds of claim, each justified with a calculation, fire-behavior principle, local observation, or cited model assumption.

- **Spread and intensity bounds** — expected and worst-plausible rates of spread, flame-length ranges, spotting distances, arrival-time windows at key values at risk, and the conditions under which those ranges change.
- **Structural properties** — wind alignment, slope effects, fuel continuity, barriers, diurnal recovery, plume-dominated potential, channeling in drainages, or opportunities created by recent burns, roads, rivers, or fuel transitions. State what holds, where, and under which assumptions.
- **Operational invariants** — facts every safe tactical plan must preserve, such as keeping crews out of chimneys during wind shifts, maintaining egress and safety zones, honoring evacuation trigger points, preserving lookout-communication-escape-safety coverage, and avoiding direct attack where flame lengths exceed safe handline thresholds.
- **Uncertainty and update behavior** — confidence in weather inputs, sensitivity to wind speed and direction, expected change at burn-period transitions, likelihood of spotting or crown-fire transition, and what field observations would invalidate the current forecast.

Ground your claims against `IAP.md` if it has reported assignments, resource limits, or field observations. A predicted fire spread that is grossly inconsistent with observed perimeter movement or planned division placement means either the forecast needs revision or the operations plan is unsafe or infeasible — diagnose which side has the issue and state it. Be concrete. “With 15 mph southwest winds, the eastern flank can reach Ridge Road in 3–5 hours unless held at the dozer line” is useful; “the fire may move quickly” is not.
</f5>

<f6>
When you finish, briefly report to the incident coordination officer: what you did, what difficulties you hit or could not resolve, and any open questions.
</f6>

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

| Tool | Suitable for |
|---|---|
| Rothermel surface fire-spread estimates | Grass, brush, timber litter; rate-of-spread and flame-length estimates under specified fuel, slope, and wind |
| Campbell Prediction System alignment analysis | Identifying where wind, slope, and aspect combine to create high-risk runs |
| Haines Index and plume-dominated assessment | Evaluating vertical instability, plume growth, spotting potential, and erratic fire behavior |
| Spotting-distance and ember-cast analysis | Wind-driven spotting across roads, drainages, rivers, or control lines |
| Fuel-moisture and Energy Release Component trends | Burn-period severity, ignition probability, resistance to control, and overnight recovery |
| WFDSS / FSPro-style scenario reasoning | Probabilistic spread pathways, values-at-risk exposure, and strategic risk comparison |
| Trigger-point and time-distance analysis | Evacuation timing, point-protection deadlines, and tactical withdrawal thresholds |
| After-action analogue comparison | Incidents in similar fuel, weather, and terrain where observed behavior constrains plausible forecasts |
</f7>

<f8>
Read `incident.md` and `FORECAST.md`, then produce the tactical operations plan:

- Include the incident objectives, operational period, division or group assignments, available resources, communications assumptions, medical plan references, evacuation coordination needs, contingency branches, and clear tactical tasks. Assign resources with realistic capability limits and travel/access constraints.
- Make the plan testable against `FORECAST.md`. If the forecast states a trigger point, your plan should specify the action tied to that trigger. If the forecast states an invariant such as required egress, safety zones, or no direct attack above a flame-length threshold, your plan should preserve it.
- Walk the plan through to completion for the operational period — do not stop at broad strategy. If a tactic depends on an unavailable crew type, closed road, grounded aircraft, or unrealistic production rate, find and fix the root cause; do not hide the gap in vague language.
- Sanity-check the plan against `FORECAST.md`. A hand crew should not be assigned direct attack in flame lengths the forecast says are unsafe; an evacuation trigger should not occur after the modeled arrival time at the community; a division should not rely on an egress route threatened by the same run it is assigned to hold.

Write the plan and its operational rationale up in `IAP.md`.
</f8>

<f9>
Review `IAP.md` against `incident.md` and against `FORECAST.md`.

- Inspect the reported tactics for anomalies, unsafe assignments, unrealistic production expectations, missing resources, or contradictions with hazards stated directly in `incident.md`.
- Open `FORECAST.md`. For every trigger point, spread estimate, safety invariant, and high-risk scenario the forecast claims, write a check into a separate `SAFETY_CHECK.md`: does the operations plan preserve egress, keep resources out of predicted entrapment zones, initiate evacuations before forecast arrival times, and match tactics to expected flame length and spotting risk? Mark each check PASS, FAIL, or NEEDS INFORMATION. Name any division, resource, route, or value at risk that violates the forecast.
- Read the operations plan and spot-check it for dangerous assumptions — unused resources that were counted on elsewhere, dead-end egress routes, tactics that contradict the stated strategy, aviation missions planned in smoke or wind conditions that would likely ground aircraft, or night operations without adequate lookouts and communications. A plan that silently exposes crews to an avoidable hazard is worse than one that openly says a task cannot be done.
- Treat the plan as acceptable only when every incident constraint holds, every forecast-claimed safety invariant holds, and the tactics are consistent with the forecast's spread windows and hazard areas — not merely when the plan sounds complete.
- Check the length of `IAP.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `IAP.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f9>

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

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

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

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

<f11>
The fire-behavior forecast lives in `FORECAST.md`, and you may be invoked on it more than once — the pipeline runs you and the red-team fire model reviewer as a loop, alternating with the operations loop.

- If `FORECAST.md` does not exist yet, this is the first pass: produce the forecast from scratch based on `incident.md`.
- If `FORECAST.md` already exists, it carries the red-team fire model reviewer’s `<review>` block. Read that feedback. Then open `IAP.md` and look at the latest operational assignments, constraints, and reported field observations — they may invalidate, sharpen, or motivate revisions to your claims. Revise `FORECAST.md` in place to address every reviewer point raised and to incorporate any operational evidence that changes your forecast. Don’t discard the previous forecast and start over, and don’t leave a flagged issue unaddressed.
</f11>

<f12>
Review `FORECAST.md` against `incident.md` and against the tactical assignments reported in `IAP.md` (if any).

- **Faithfulness** — does the forecast correctly describe the incident stated in `incident.md`? Check fuels, topography, wind direction, access constraints, values at risk, resource availability, and time references.
- **Reasoning soundness** — for each claim, walk through the calculation, model assumption, analogy, or cited fire-behavior principle. Flag hand-waving steps. Verify that spread estimates, spotting assumptions, and trigger times apply under the stated fuel, slope, wind, and moisture conditions.
- **Operational grounding** — open `IAP.md`. If the plan reports division placements, control lines, evacuation timing, or resource limits, do they fit within the forecast's predicted spread windows and hazard areas? A forecast that ignores a division working below an unstable slope or assumes aviation support that the plan says is unavailable is not operationally grounded.

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

<f13>
The tactical operations plan lives in `IAP.md`, and you may be invoked on it more than once — the pipeline runs you and the incident safety officer as a loop, alternating with the fire-behavior loop.

- If `IAP.md` does not exist yet, this is the first pass: produce the plan from scratch based on `incident.md`.
- If `IAP.md` already exists, it carries the incident safety officer’s `<review>` block. Read that feedback. Then open `FORECAST.md` and check whether the latest forecast introduces trigger points, safety invariants, spread scenarios, or structural fire-behavior claims your current plan does not yet respect — for example a tighter evacuation deadline, a new spotting concern across the primary line, or an egress route forecast to be compromised. Revise `IAP.md` in place to address every reviewer point and to align with the latest forecast. Don’t discard the previous plan and start over, and don’t leave a flagged issue unaddressed.
</f13>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (incident coordination officer, fire behavior analyst, red-team fire model reviewer, operations plan chief, incident safety officer), which items should go in its prompt? Respond with a JSON object like {"incident coordination officer": ["f?"], "fire behavior analyst": ["f?"], "red-team fire model reviewer": ["f?"], "operations plan chief": ["f?"], "incident safety officer": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that develops a wildfire incident response plan by refining fire-behavior forecasts and tactical operations planning in parallel, with each side informing the other. An incident package arrives as a natural-language briefing in `incident.md`. The pipeline alternates between revising the forecast assumptions (spread potential, trigger points, weather sensitivities, exposure concerns) and revising the operations plan (divisions, resources, tactics, contingencies, and safety controls).

The five agents:

- **incident coordination officer** orchestrates the run by alternating one fire-behavior step with one operations step and tracking progress. It does no forecasting, tactical planning, or reviewing itself.
- **fire-behavior loop** — the **fire behavior analyst** writes the forecast and fire-behavior rationale to `FORECAST.md`; the **red-team fire model reviewer** challenges it. The fire behavior analyst reads `IAP.md` on each revision pass to incorporate operational observations, resource constraints, and field-reported conditions.
- **operations loop** — the **operations plan chief** writes the tactical incident action plan to `IAP.md`; the **incident safety officer** judges it. The operations plan chief reads `FORECAST.md` on each revision pass to align tactics with the latest fire-behavior claims.

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

The pipeline hands work off through three files:

- `incident.md` — the original incident briefing, read-only. All four domain agents read it.
- `FORECAST.md` — the fire-behavior forecast and rationale. Fire behavior analyst writes; red-team fire model reviewer reviews; operations plan chief and incident safety officer read it to know which spread scenarios, trigger points, and exposure risks the plan must respect.
- `IAP.md` — the tactical operations plan and operational results. Operations plan chief writes; incident safety officer reviews; fire behavior analyst and red-team fire model reviewer read it to ground the forecast in actual assignments, access limits, and field constraints.

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

Unlike a forecast-then-plan pipeline where modeling must settle before tactics start, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. Forecast assumptions may tighten after seeing operational reports and feasible resource deployments; the operations plan may change after seeing a revised wind scenario, spotting-probability assessment, or evacuation trigger.

I'm providing the following prompt fragments:

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

<f2>
You orchestrate the run; you never forecast, plan tactics, or review yourself — you only assign the right agent at the right time.

- **Init** — create `STATE.md` with `iter: 0` and `last_side: none`. Assign the fire behavior analyst for the first forecast step (fire behavior analyst, then red-team fire model reviewer), then the operations plan chief for the first operations step (operations plan chief, then incident safety officer).
- **Alternation loop** — alternate one fire-behavior step with one operations step. Neither side terminates early on its own score; even a strong-looking forecast may need revision once the operations plan exposes resource constraints or field observations.
- Cap the total at 20 iterations (10 fire-behavior steps + 10 operations steps). After the cap, stop and summarize.
- Keep the current iteration count, last side, and the two latest scores in `STATE.md`, accurate after each assignment. Read each score from the reviewer’s `<review score=X>` block. Commit progress after each step.
- Read each agent’s brief narrative reply on return. If an agent reports an unresolved error, append it to `error-log.txt` (timestamp + agent name + content) and continue with the next step.
</f2>

<f3>
You are working on a wildfire incident response planning problem. The original incident is given as a natural-language briefing in `incident.md`; read it before starting your part. It may describe fuels, topography, forecast weather, communities at risk, roads and access points, available crews and equipment, aviation limits, evacuation concerns, and command objectives.
</f3>

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

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — “this is unsafe, but I am telling you it is unsafe” is still a failing result, not a passing one.
</f4>

<f5>
Produce the fire-behavior forecast for the incident and write it to `FORECAST.md`. A complete forecast covers four kinds of claim, each justified with a calculation, fire-behavior principle, local observation, or cited model assumption.

- **Spread and intensity bounds** — expected and worst-plausible rates of spread, flame-length ranges, spotting distances, arrival-time windows at key values at risk, and the conditions under which those ranges change.
- **Structural properties** — wind alignment, slope effects, fuel continuity, barriers, diurnal recovery, plume-dominated potential, channeling in drainages, or opportunities created by recent burns, roads, rivers, or fuel transitions. State what holds, where, and under which assumptions.
- **Operational invariants** — facts every safe tactical plan must preserve, such as keeping crews out of chimneys during wind shifts, maintaining egress and safety zones, honoring evacuation trigger points, preserving lookout-communication-escape-safety coverage, and avoiding direct attack where flame lengths exceed safe handline thresholds.
- **Uncertainty and update behavior** — confidence in weather inputs, sensitivity to wind speed and direction, expected change at burn-period transitions, likelihood of spotting or crown-fire transition, and what field observations would invalidate the current forecast.

Ground your claims against `IAP.md` if it has reported assignments, resource limits, or field observations. A predicted fire spread that is grossly inconsistent with observed perimeter movement or planned division placement means either the forecast needs revision or the operations plan is unsafe or infeasible — diagnose which side has the issue and state it. Be concrete. “With 15 mph southwest winds, the eastern flank can reach Ridge Road in 3–5 hours unless held at the dozer line” is useful; “the fire may move quickly” is not.
</f5>

<f6>
When you finish, briefly report to the incident coordination officer: what you did, what difficulties you hit or could not resolve, and any open questions.
</f6>

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

| Tool | Suitable for |
|---|---|
| Rothermel surface fire-spread estimates | Grass, brush, timber litter; rate-of-spread and flame-length estimates under specified fuel, slope, and wind |
| Campbell Prediction System alignment analysis | Identifying where wind, slope, and aspect combine to create high-risk runs |
| Haines Index and plume-dominated assessment | Evaluating vertical instability, plume growth, spotting potential, and erratic fire behavior |
| Spotting-distance and ember-cast analysis | Wind-driven spotting across roads, drainages, rivers, or control lines |
| Fuel-moisture and Energy Release Component trends | Burn-period severity, ignition probability, resistance to control, and overnight recovery |
| WFDSS / FSPro-style scenario reasoning | Probabilistic spread pathways, values-at-risk exposure, and strategic risk comparison |
| Trigger-point and time-distance analysis | Evacuation timing, point-protection deadlines, and tactical withdrawal thresholds |
| After-action analogue comparison | Incidents in similar fuel, weather, and terrain where observed behavior constrains plausible forecasts |
</f7>

<f8>
Read `incident.md` and `FORECAST.md`, then produce the tactical operations plan:

- Include the incident objectives, operational period, division or group assignments, available resources, communications assumptions, medical plan references, evacuation coordination needs, contingency branches, and clear tactical tasks. Assign resources with realistic capability limits and travel/access constraints.
- Make the plan testable against `FORECAST.md`. If the forecast states a trigger point, your plan should specify the action tied to that trigger. If the forecast states an invariant such as required egress, safety zones, or no direct attack above a flame-length threshold, your plan should preserve it.
- Walk the plan through to completion for the operational period — do not stop at broad strategy. If a tactic depends on an unavailable crew type, closed road, grounded aircraft, or unrealistic production rate, find and fix the root cause; do not hide the gap in vague language.
- Sanity-check the plan against `FORECAST.md`. A hand crew should not be assigned direct attack in flame lengths the forecast says are unsafe; an evacuation trigger should not occur after the modeled arrival time at the community; a division should not rely on an egress route threatened by the same run it is assigned to hold.

Write the plan and its operational rationale up in `IAP.md`.
</f8>

<f9>
Review `IAP.md` against `incident.md` and against `FORECAST.md`.

- Inspect the reported tactics for anomalies, unsafe assignments, unrealistic production expectations, missing resources, or contradictions with hazards stated directly in `incident.md`.
- Open `FORECAST.md`. For every trigger point, spread estimate, safety invariant, and high-risk scenario the forecast claims, write a check into a separate `SAFETY_CHECK.md`: does the operations plan preserve egress, keep resources out of predicted entrapment zones, initiate evacuations before forecast arrival times, and match tactics to expected flame length and spotting risk? Mark each check PASS, FAIL, or NEEDS INFORMATION. Name any division, resource, route, or value at risk that violates the forecast.
- Read the operations plan and spot-check it for dangerous assumptions — unused resources that were counted on elsewhere, dead-end egress routes, tactics that contradict the stated strategy, aviation missions planned in smoke or wind conditions that would likely ground aircraft, or night operations without adequate lookouts and communications. A plan that silently exposes crews to an avoidable hazard is worse than one that openly says a task cannot be done.
- Treat the plan as acceptable only when every incident constraint holds, every forecast-claimed safety invariant holds, and the tactics are consistent with the forecast's spread windows and hazard areas — not merely when the plan sounds complete.
- Check the length of `IAP.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `IAP.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f9>

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

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

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

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

<f11>
The fire-behavior forecast lives in `FORECAST.md`, and you may be invoked on it more than once — the pipeline runs you and the red-team fire model reviewer as a loop, alternating with the operations loop.

- If `FORECAST.md` does not exist yet, this is the first pass: produce the forecast from scratch based on `incident.md`.
- If `FORECAST.md` already exists, it carries the red-team fire model reviewer’s `<review>` block. Read that feedback. Then open `IAP.md` and look at the latest operational assignments, constraints, and reported field observations — they may invalidate, sharpen, or motivate revisions to your claims. Revise `FORECAST.md` in place to address every reviewer point raised and to incorporate any operational evidence that changes your forecast. Don’t discard the previous forecast and start over, and don’t leave a flagged issue unaddressed.
</f11>

<f12>
Review `FORECAST.md` against `incident.md` and against the tactical assignments reported in `IAP.md` (if any).

- **Faithfulness** — does the forecast correctly describe the incident stated in `incident.md`? Check fuels, topography, wind direction, access constraints, values at risk, resource availability, and time references.
- **Reasoning soundness** — for each claim, walk through the calculation, model assumption, analogy, or cited fire-behavior principle. Flag hand-waving steps. Verify that spread estimates, spotting assumptions, and trigger times apply under the stated fuel, slope, wind, and moisture conditions.
- **Operational grounding** — open `IAP.md`. If the plan reports division placements, control lines, evacuation timing, or resource limits, do they fit within the forecast's predicted spread windows and hazard areas? A forecast that ignores a division working below an unstable slope or assumes aviation support that the plan says is unavailable is not operationally grounded.

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

<f13>
The tactical operations plan lives in `IAP.md`, and you may be invoked on it more than once — the pipeline runs you and the incident safety officer as a loop, alternating with the fire-behavior loop.

- If `IAP.md` does not exist yet, this is the first pass: produce the plan from scratch based on `incident.md`.
- If `IAP.md` already exists, it carries the incident safety officer’s `<review>` block. Read that feedback. Then open `FORECAST.md` and check whether the latest forecast introduces trigger points, safety invariants, spread scenarios, or structural fire-behavior claims your current plan does not yet respect — for example a tighter evacuation deadline, a new spotting concern across the primary line, or an egress route forecast to be compromised. Revise `IAP.md` in place to address every reviewer point and to align with the latest forecast. Don’t discard the previous plan and start over, and don’t leave a flagged issue unaddressed.
</f13>

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