mission operations coordinator
anomaly analyst
fault-review board member
recovery procedure engineer
flight-safety verifier

I need you to set up a 5-agent pipeline that responds to spacecraft anomalies by developing fault-cause analysis and recovery procedures in parallel, with each side informing the other under independent mission-safety review. An anomaly arrives as a natural-language incident report in `anomaly.md`. The pipeline alternates between revising the fault analysis (candidate causes, discriminating telemetry, hazard claims, operational constraints) and revising the recovery procedure (the command sequence, go/no-go gates, contingency branches, and expected telemetry response).

The five agents:

- **mission operations coordinator** orchestrates the run by alternating one analysis step with one recovery-procedure step and tracking progress. It does no diagnosis, procedure authoring, or safety review itself.
- **fault analysis loop** — the **anomaly analyst** writes the fault-cause analysis to `CAUSE_ANALYSIS.md`; the **fault-review board member** judges it. The anomaly analyst reads `RECOVERY_PROCEDURE.md` on each revision pass to incorporate test outcomes, simulator results, and operational evidence.
- **recovery procedure loop** — the **recovery procedure engineer** writes the recovery commands and execution results to `RECOVERY_PROCEDURE.md`; the **flight-safety verifier** judges them. The recovery procedure engineer reads `CAUSE_ANALYSIS.md` on each revision pass to align the procedure with the latest fault hypotheses and safety constraints.

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

The pipeline hands work off through plan-namespaced files:

- `anomaly.md` — the original anomaly report, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing response plan per directory, K plans total, given as input (read-only). All four domain agents read the `PLAN.md` of the plan they are currently assigned to.
- `plans/{id}-{slug}/CAUSE_ANALYSIS.md` — the fault-cause analysis for that plan. Anomaly analyst writes; fault-review board member reviews; recovery procedure engineer and flight-safety verifier read it.
- `plans/{id}-{slug}/RECOVERY_PROCEDURE.md` — the recovery procedure and its test or execution results for that plan. Recovery procedure engineer writes; flight-safety verifier reviews; anomaly analyst and fault-review board member read it.

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

Each plan develops independently. Cross-read between `CAUSE_ANALYSIS.md` and `RECOVERY_PROCEDURE.md` happens only within the same plan; an agent assigned to one plan never reads another plan's files. The mission operations coordinator round-robins across the K plans: each plan gets one analysis step plus one recovery-procedure step per full cycle.

Within each plan, neither fault-cause analysis nor recovery procedure finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. The analysis may tighten after seeing the plan's simulator traces or procedure outcomes; the procedure may change after seeing the plan's refined fault tree, telemetry discriminators, or hazard controls.

I'm providing the following information:

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

<f2>
You orchestrate the run; you never diagnose, author recovery procedures, or review mission safety yourself — you only assign the right agent at the right time.

- **Init** — discover the K plan directories under `plans/{id}-{slug}/`. Create `STATE.md` with `iter: 0`, `current_plan_idx: 0`, and a per-plan record holding each plan's id, last side, and latest analysis/procedure scores.
- **Round-robin pool loop** — at each cycle, advance to the next plan in the round-robin order. For that plan, assign one analysis step (anomaly analyst, then fault-review board member) and one recovery-procedure step (recovery procedure engineer, then flight-safety verifier); then move to the next plan. After all K plans have each had one cycle, loop back to the first plan.
- When assigning work, always pass the plan's directory path so the assigned agent knows which `PLAN.md` / `CAUSE_ANALYSIS.md` / `RECOVERY_PROCEDURE.md` to operate on.
- Neither side terminates early on its own score within a plan; even a perfect-looking fault analysis may need to revise once the procedure reports simulator outcomes or telemetry. The pool keeps cycling even after individual plans look done.
- Cap the total at 20 × K dispatches (10 analysis + 10 recovery-procedure steps per plan, summed across K plans). After the cap, stop and summarize per plan.
- Keep the current iteration count, current plan index, and per-plan latest scores in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's reviewer `<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 + plan id + agent name + content) and continue with the next assignment.
</f2>

<f3>
You are working on a spacecraft anomaly response, which may involve attitude control, power, thermal, propulsion, communications, avionics, payload, or flight-software behavior. The original anomaly is given as a natural-language incident report in `anomaly.md`; read it before starting your part.
</f3>

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

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

<f5>
Produce the fault-cause analysis for the plan the mission operations coordinator has assigned you to this round, and write it to that plan's `CAUSE_ANALYSIS.md` (under `plans/{id}-{slug}/CAUSE_ANALYSIS.md`). A complete analysis covers four kinds of claim, each justified with telemetry evidence, engineering rationale, or a cited mission rule.

- **Candidate causes and likelihoods** — plausible root causes such as sensor degradation, actuator saturation, latch-up, thermal drift, bus undervoltage, propellant feed issue, configuration error, or flight-software state-machine fault. Rank them and explain what evidence supports or weakens each one.
- **Structural dependencies** — subsystem coupling, redundancy paths, command authority, fault-protection interactions, mode dependencies, thermal or power cross-coupling, and any single-point failures. State what holds, where, and under which operating assumptions.
- **Safety constraints and invariants** — quantities every safe recovery must preserve, such as battery state-of-charge floor, attitude keep-out zones, momentum envelope, thermal limits, pressure limits, command inhibits, link-margin thresholds, and payload safing requirements. The recovery procedure's output should satisfy them; the flight-safety verifier will check with `verify.py`.
- **Risk, timeline, or convergence** — time-to-loss-of-function estimates, fault growth rates, expected stabilization timeline, required ground contact windows, probability of escalation, or criteria for declaring the response stabilized.

Ground your claims against the plan's `RECOVERY_PROCEDURE.md` if it has reported simulator results, telemetry snapshots, or dry-run outcomes. A predicted telemetry signature that is grossly inconsistent with observed numbers means either the analysis needs revision or the recovery procedure has a defect — diagnose which side has the issue and state it. Be concrete. "Battery bus sag below 25.5 V during wheel desaturation points to a power-transient cause" is fine; "there may be a spacecraft issue" is not. Do not read or aggregate across other plans' files.
</f5>

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

<f7>
Match the tool to the anomaly structure; do not force an ill-suited one. The list below is useful in spacecraft fault-cause analysis.

| Tool | Suitable for |
|---|---|
| Fault tree analysis / event tree analysis | Enumerating root-cause paths, common-cause failures, and escalation chains |
| FMEA / FMECA | Ranking component failure modes by severity, likelihood, detectability, and mission effect |
| Telemetry trend and residual analysis | Detecting sensor drift, actuator degradation, thermal runaway, power transients, or control-loop mismatch |
| Bayesian diagnosis / belief updating | Updating root-cause likelihoods as new telemetry, simulator runs, or command outcomes arrive |
| State-machine and mode-transition analysis | Flight-software mode errors, safing entry logic, command inhibits, and autonomous fault-protection behavior |
| Control-system stability margins | Attitude-control oscillations, reaction-wheel saturation, thruster pulse response, and closed-loop recovery safety |
| Hazard analysis and fault containment regions | Identifying keep-out conditions, inhibit rules, irreversible actions, and safe operational envelopes |
| Sensitivity / what-if analysis | Stability of the diagnosis and recovery path under telemetry uncertainty, delayed contact, or degraded sensors |
</f7>

<f8>
You operate on the plan the mission operations coordinator has assigned you to this round. Read `anomaly.md`, your assigned plan's `PLAN.md`, and your assigned plan's `CAUSE_ANALYSIS.md`, then implement the recovery procedure:

- Include every command, prerequisite, parameter value, command authorization, expected telemetry response, and hold point. Define the operational objective and every safety constraint exactly as the anomaly report and response plan state them. Specify command timing, required ground-station coverage, required spacecraft mode, and abort criteria.
- Make the procedure testable against the plan's `CAUSE_ANALYSIS.md`. If the analysis states a battery-voltage floor, momentum limit, thermal ceiling, pressure bound, attitude keep-out zone, or command inhibit, your procedure should preserve it. If the analysis states a diagnostic telemetry signature, your procedure should collect the data needed to confirm or reject it.
- Run the procedure through the available simulator, command-sequence validator, or table-top dry run yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not hide failures behind vague "operator discretion" language.
- Sanity-check the result against the plan's `CAUSE_ANALYSIS.md`. A latch state that must be binary should not be reported as ambiguous; a hazard limit the analysis says must hold should hold; a recovery step that depends on sun-pointing should not be scheduled during an eclipse interval.

Write the procedure and its results up in your assigned plan's `RECOVERY_PROCEDURE.md`. Do not read or write any other plan's files.
</f8>

<f9>
Review your assigned plan's `RECOVERY_PROCEDURE.md` against `anomaly.md`, against the plan's `PLAN.md`, and against the plan's `CAUSE_ANALYSIS.md`. Operate strictly on the assigned plan's files; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable telemetry values, unsafe mode transitions, or constraint violations stated directly in `anomaly.md` or in the plan's `PLAN.md`.
- Open the plan's `CAUSE_ANALYSIS.md`. For every bound, safety constraint, and invariant the analysis claims, write a check into a separate `verify.py` under the plan's directory: does the procedure's reported output preserve the invariant, stay within the predicted safety envelope, collect the required diagnostic telemetry, and avoid prohibited command states? Run it. Name any variable or quantity that violates.
- Read the recovery procedure and spot-check it for defects — unused prerequisites, missing inhibits, dead branches, commands that contradict the chosen recovery strategy, or telemetry checks that occur after the irreversible step they were supposed to gate. A defect that silently leaves the spacecraft in a degraded or unsafe state is worse than one that stops the procedure.
- Treat the result as finished only when every mission constraint holds, every analysis-claimed safety invariant holds, and the recovery outcome is consistent with the analysis's fault signatures and margins — not merely when the command sequence validates syntactically.
- Check the length of the plan's `RECOVERY_PROCEDURE.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `RECOVERY_PROCEDURE.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>
You operate on the plan the mission operations coordinator has assigned you to this round. Your fault-cause analysis lives in that plan's `CAUSE_ANALYSIS.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the fault-review board member as a loop, alternating with that plan's recovery-procedure loop, while the mission operations coordinator round-robins across plans.

- If your assigned plan's `CAUSE_ANALYSIS.md` does not exist yet, this is the first pass for that plan: produce the analysis from scratch based on `anomaly.md` and the plan's `PLAN.md`.
- If the plan's `CAUSE_ANALYSIS.md` already exists, it carries the fault-review board member's `<review>` block. Read that feedback. Then open the plan's `RECOVERY_PROCEDURE.md` and look at the latest reported simulator results, telemetry snapshots, or dry-run outcomes — they may invalidate, sharpen, or motivate revisions to your fault hypotheses and safety constraints. Revise the plan's `CAUSE_ANALYSIS.md` in place to address every reviewer point raised and to incorporate any operational evidence that changes your analysis. Don't discard the previous analysis and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f11>

<f12>
Review your assigned plan's `CAUSE_ANALYSIS.md` against `anomaly.md`, against the plan's `PLAN.md`, and against the telemetry, simulator results, or dry-run outcomes reported in the plan's `RECOVERY_PROCEDURE.md` (if any). Operate strictly on the assigned plan's files; do not look at other plans.

- **Faithfulness** — does the analysis correctly describe the anomaly stated in `anomaly.md` under the response concept set by the plan's `PLAN.md`? Check subsystem definitions, telemetry channel names, spacecraft mode assumptions, command constraints, and environmental conditions.
- **Evidence soundness** — for each claim, walk through the telemetry evidence, engineering rationale, or cited mission rule. Flag hand-waving steps. Verify that thresholds, trend interpretations, and causal links apply under the stated assumptions.
- **Operational grounding** — open the plan's `RECOVERY_PROCEDURE.md`. If the procedure reports simulator results, telemetry snapshots, or dry-run outcomes, do they fit within the analysis's predicted signatures and safety margins? A diagnostic threshold that is missed by orders of magnitude is a signal the fault model is too weak; refine it, or note explicitly that the threshold is only illustrative.

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

<f13>
You operate on the plan the mission operations coordinator has assigned you to this round. Your recovery procedure and its results live in that plan's `RECOVERY_PROCEDURE.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the flight-safety verifier as a loop, alternating with that plan's fault analysis loop, while the mission operations coordinator round-robins across plans.

- If your assigned plan's `RECOVERY_PROCEDURE.md` does not exist yet, this is the first pass for that plan: produce the procedure from scratch based on `anomaly.md` and the plan's `PLAN.md`.
- If the plan's `RECOVERY_PROCEDURE.md` already exists, it carries the flight-safety verifier's `<review>` block. Read that feedback. Then open the plan's `CAUSE_ANALYSIS.md` and check whether the latest analysis introduces safety limits, invariants, diagnostic signatures, or structural claims your current procedure doesn't yet respect — for example a tighter battery state-of-charge floor your procedure now approaches too closely, or an attitude keep-out constraint your command sequence violates. Revise the plan's `RECOVERY_PROCEDURE.md` in place to address every reviewer point and to align with the latest analysis. Don't discard the previous procedure and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f13>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (mission operations coordinator, anomaly analyst, fault-review board member, recovery procedure engineer, flight-safety verifier), which items should go in its prompt? Respond with a JSON object like {"mission operations coordinator": ["f?"], "anomaly analyst": ["f?"], "fault-review board member": ["f?"], "recovery procedure engineer": ["f?"], "flight-safety verifier": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that responds to spacecraft anomalies by developing fault-cause analysis and recovery procedures in parallel, with each side informing the other under independent mission-safety review. An anomaly arrives as a natural-language incident report in `anomaly.md`. The pipeline alternates between revising the fault analysis (candidate causes, discriminating telemetry, hazard claims, operational constraints) and revising the recovery procedure (the command sequence, go/no-go gates, contingency branches, and expected telemetry response).

The five agents:

- **mission operations coordinator** orchestrates the run by alternating one analysis step with one recovery-procedure step and tracking progress. It does no diagnosis, procedure authoring, or safety review itself.
- **fault analysis loop** — the **anomaly analyst** writes the fault-cause analysis to `CAUSE_ANALYSIS.md`; the **fault-review board member** judges it. The anomaly analyst reads `RECOVERY_PROCEDURE.md` on each revision pass to incorporate test outcomes, simulator results, and operational evidence.
- **recovery procedure loop** — the **recovery procedure engineer** writes the recovery commands and execution results to `RECOVERY_PROCEDURE.md`; the **flight-safety verifier** judges them. The recovery procedure engineer reads `CAUSE_ANALYSIS.md` on each revision pass to align the procedure with the latest fault hypotheses and safety constraints.

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

The pipeline hands work off through plan-namespaced files:

- `anomaly.md` — the original anomaly report, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing response plan per directory, K plans total, given as input (read-only). All four domain agents read the `PLAN.md` of the plan they are currently assigned to.
- `plans/{id}-{slug}/CAUSE_ANALYSIS.md` — the fault-cause analysis for that plan. Anomaly analyst writes; fault-review board member reviews; recovery procedure engineer and flight-safety verifier read it.
- `plans/{id}-{slug}/RECOVERY_PROCEDURE.md` — the recovery procedure and its test or execution results for that plan. Recovery procedure engineer writes; flight-safety verifier reviews; anomaly analyst and fault-review board member read it.

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

Each plan develops independently. Cross-read between `CAUSE_ANALYSIS.md` and `RECOVERY_PROCEDURE.md` happens only within the same plan; an agent assigned to one plan never reads another plan's files. The mission operations coordinator round-robins across the K plans: each plan gets one analysis step plus one recovery-procedure step per full cycle.

Within each plan, neither fault-cause analysis nor recovery procedure finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. The analysis may tighten after seeing the plan's simulator traces or procedure outcomes; the procedure may change after seeing the plan's refined fault tree, telemetry discriminators, or hazard controls.

I'm providing the following prompt fragments:

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

<f2>
You orchestrate the run; you never diagnose, author recovery procedures, or review mission safety yourself — you only assign the right agent at the right time.

- **Init** — discover the K plan directories under `plans/{id}-{slug}/`. Create `STATE.md` with `iter: 0`, `current_plan_idx: 0`, and a per-plan record holding each plan's id, last side, and latest analysis/procedure scores.
- **Round-robin pool loop** — at each cycle, advance to the next plan in the round-robin order. For that plan, assign one analysis step (anomaly analyst, then fault-review board member) and one recovery-procedure step (recovery procedure engineer, then flight-safety verifier); then move to the next plan. After all K plans have each had one cycle, loop back to the first plan.
- When assigning work, always pass the plan's directory path so the assigned agent knows which `PLAN.md` / `CAUSE_ANALYSIS.md` / `RECOVERY_PROCEDURE.md` to operate on.
- Neither side terminates early on its own score within a plan; even a perfect-looking fault analysis may need to revise once the procedure reports simulator outcomes or telemetry. The pool keeps cycling even after individual plans look done.
- Cap the total at 20 × K dispatches (10 analysis + 10 recovery-procedure steps per plan, summed across K plans). After the cap, stop and summarize per plan.
- Keep the current iteration count, current plan index, and per-plan latest scores in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's reviewer `<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 + plan id + agent name + content) and continue with the next assignment.
</f2>

<f3>
You are working on a spacecraft anomaly response, which may involve attitude control, power, thermal, propulsion, communications, avionics, payload, or flight-software behavior. The original anomaly is given as a natural-language incident report in `anomaly.md`; read it before starting your part.
</f3>

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

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

<f5>
Produce the fault-cause analysis for the plan the mission operations coordinator has assigned you to this round, and write it to that plan's `CAUSE_ANALYSIS.md` (under `plans/{id}-{slug}/CAUSE_ANALYSIS.md`). A complete analysis covers four kinds of claim, each justified with telemetry evidence, engineering rationale, or a cited mission rule.

- **Candidate causes and likelihoods** — plausible root causes such as sensor degradation, actuator saturation, latch-up, thermal drift, bus undervoltage, propellant feed issue, configuration error, or flight-software state-machine fault. Rank them and explain what evidence supports or weakens each one.
- **Structural dependencies** — subsystem coupling, redundancy paths, command authority, fault-protection interactions, mode dependencies, thermal or power cross-coupling, and any single-point failures. State what holds, where, and under which operating assumptions.
- **Safety constraints and invariants** — quantities every safe recovery must preserve, such as battery state-of-charge floor, attitude keep-out zones, momentum envelope, thermal limits, pressure limits, command inhibits, link-margin thresholds, and payload safing requirements. The recovery procedure's output should satisfy them; the flight-safety verifier will check with `verify.py`.
- **Risk, timeline, or convergence** — time-to-loss-of-function estimates, fault growth rates, expected stabilization timeline, required ground contact windows, probability of escalation, or criteria for declaring the response stabilized.

Ground your claims against the plan's `RECOVERY_PROCEDURE.md` if it has reported simulator results, telemetry snapshots, or dry-run outcomes. A predicted telemetry signature that is grossly inconsistent with observed numbers means either the analysis needs revision or the recovery procedure has a defect — diagnose which side has the issue and state it. Be concrete. "Battery bus sag below 25.5 V during wheel desaturation points to a power-transient cause" is fine; "there may be a spacecraft issue" is not. Do not read or aggregate across other plans' files.
</f5>

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

<f7>
Match the tool to the anomaly structure; do not force an ill-suited one. The list below is useful in spacecraft fault-cause analysis.

| Tool | Suitable for |
|---|---|
| Fault tree analysis / event tree analysis | Enumerating root-cause paths, common-cause failures, and escalation chains |
| FMEA / FMECA | Ranking component failure modes by severity, likelihood, detectability, and mission effect |
| Telemetry trend and residual analysis | Detecting sensor drift, actuator degradation, thermal runaway, power transients, or control-loop mismatch |
| Bayesian diagnosis / belief updating | Updating root-cause likelihoods as new telemetry, simulator runs, or command outcomes arrive |
| State-machine and mode-transition analysis | Flight-software mode errors, safing entry logic, command inhibits, and autonomous fault-protection behavior |
| Control-system stability margins | Attitude-control oscillations, reaction-wheel saturation, thruster pulse response, and closed-loop recovery safety |
| Hazard analysis and fault containment regions | Identifying keep-out conditions, inhibit rules, irreversible actions, and safe operational envelopes |
| Sensitivity / what-if analysis | Stability of the diagnosis and recovery path under telemetry uncertainty, delayed contact, or degraded sensors |
</f7>

<f8>
You operate on the plan the mission operations coordinator has assigned you to this round. Read `anomaly.md`, your assigned plan's `PLAN.md`, and your assigned plan's `CAUSE_ANALYSIS.md`, then implement the recovery procedure:

- Include every command, prerequisite, parameter value, command authorization, expected telemetry response, and hold point. Define the operational objective and every safety constraint exactly as the anomaly report and response plan state them. Specify command timing, required ground-station coverage, required spacecraft mode, and abort criteria.
- Make the procedure testable against the plan's `CAUSE_ANALYSIS.md`. If the analysis states a battery-voltage floor, momentum limit, thermal ceiling, pressure bound, attitude keep-out zone, or command inhibit, your procedure should preserve it. If the analysis states a diagnostic telemetry signature, your procedure should collect the data needed to confirm or reject it.
- Run the procedure through the available simulator, command-sequence validator, or table-top dry run yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not hide failures behind vague "operator discretion" language.
- Sanity-check the result against the plan's `CAUSE_ANALYSIS.md`. A latch state that must be binary should not be reported as ambiguous; a hazard limit the analysis says must hold should hold; a recovery step that depends on sun-pointing should not be scheduled during an eclipse interval.

Write the procedure and its results up in your assigned plan's `RECOVERY_PROCEDURE.md`. Do not read or write any other plan's files.
</f8>

<f9>
Review your assigned plan's `RECOVERY_PROCEDURE.md` against `anomaly.md`, against the plan's `PLAN.md`, and against the plan's `CAUSE_ANALYSIS.md`. Operate strictly on the assigned plan's files; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable telemetry values, unsafe mode transitions, or constraint violations stated directly in `anomaly.md` or in the plan's `PLAN.md`.
- Open the plan's `CAUSE_ANALYSIS.md`. For every bound, safety constraint, and invariant the analysis claims, write a check into a separate `verify.py` under the plan's directory: does the procedure's reported output preserve the invariant, stay within the predicted safety envelope, collect the required diagnostic telemetry, and avoid prohibited command states? Run it. Name any variable or quantity that violates.
- Read the recovery procedure and spot-check it for defects — unused prerequisites, missing inhibits, dead branches, commands that contradict the chosen recovery strategy, or telemetry checks that occur after the irreversible step they were supposed to gate. A defect that silently leaves the spacecraft in a degraded or unsafe state is worse than one that stops the procedure.
- Treat the result as finished only when every mission constraint holds, every analysis-claimed safety invariant holds, and the recovery outcome is consistent with the analysis's fault signatures and margins — not merely when the command sequence validates syntactically.
- Check the length of the plan's `RECOVERY_PROCEDURE.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `RECOVERY_PROCEDURE.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>
You operate on the plan the mission operations coordinator has assigned you to this round. Your fault-cause analysis lives in that plan's `CAUSE_ANALYSIS.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the fault-review board member as a loop, alternating with that plan's recovery-procedure loop, while the mission operations coordinator round-robins across plans.

- If your assigned plan's `CAUSE_ANALYSIS.md` does not exist yet, this is the first pass for that plan: produce the analysis from scratch based on `anomaly.md` and the plan's `PLAN.md`.
- If the plan's `CAUSE_ANALYSIS.md` already exists, it carries the fault-review board member's `<review>` block. Read that feedback. Then open the plan's `RECOVERY_PROCEDURE.md` and look at the latest reported simulator results, telemetry snapshots, or dry-run outcomes — they may invalidate, sharpen, or motivate revisions to your fault hypotheses and safety constraints. Revise the plan's `CAUSE_ANALYSIS.md` in place to address every reviewer point raised and to incorporate any operational evidence that changes your analysis. Don't discard the previous analysis and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f11>

<f12>
Review your assigned plan's `CAUSE_ANALYSIS.md` against `anomaly.md`, against the plan's `PLAN.md`, and against the telemetry, simulator results, or dry-run outcomes reported in the plan's `RECOVERY_PROCEDURE.md` (if any). Operate strictly on the assigned plan's files; do not look at other plans.

- **Faithfulness** — does the analysis correctly describe the anomaly stated in `anomaly.md` under the response concept set by the plan's `PLAN.md`? Check subsystem definitions, telemetry channel names, spacecraft mode assumptions, command constraints, and environmental conditions.
- **Evidence soundness** — for each claim, walk through the telemetry evidence, engineering rationale, or cited mission rule. Flag hand-waving steps. Verify that thresholds, trend interpretations, and causal links apply under the stated assumptions.
- **Operational grounding** — open the plan's `RECOVERY_PROCEDURE.md`. If the procedure reports simulator results, telemetry snapshots, or dry-run outcomes, do they fit within the analysis's predicted signatures and safety margins? A diagnostic threshold that is missed by orders of magnitude is a signal the fault model is too weak; refine it, or note explicitly that the threshold is only illustrative.

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

<f13>
You operate on the plan the mission operations coordinator has assigned you to this round. Your recovery procedure and its results live in that plan's `RECOVERY_PROCEDURE.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the flight-safety verifier as a loop, alternating with that plan's fault analysis loop, while the mission operations coordinator round-robins across plans.

- If your assigned plan's `RECOVERY_PROCEDURE.md` does not exist yet, this is the first pass for that plan: produce the procedure from scratch based on `anomaly.md` and the plan's `PLAN.md`.
- If the plan's `RECOVERY_PROCEDURE.md` already exists, it carries the flight-safety verifier's `<review>` block. Read that feedback. Then open the plan's `CAUSE_ANALYSIS.md` and check whether the latest analysis introduces safety limits, invariants, diagnostic signatures, or structural claims your current procedure doesn't yet respect — for example a tighter battery state-of-charge floor your procedure now approaches too closely, or an attitude keep-out constraint your command sequence violates. Revise the plan's `RECOVERY_PROCEDURE.md` in place to address every reviewer point and to align with the latest analysis. Don't discard the previous procedure and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</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. `# mission operations coordinator`). Output only the headered prompts, no preamble.


I need you to set up a 5-agent pipeline that responds to spacecraft anomalies by developing fault-cause analysis and recovery procedures in parallel, with each side informing the other under independent mission-safety review. An anomaly arrives as a natural-language incident report in `anomaly.md`. The pipeline alternates between revising the fault analysis (candidate causes, discriminating telemetry, hazard claims, operational constraints) and revising the recovery procedure (the command sequence, go/no-go gates, contingency branches, and expected telemetry response).

The five agents:

- **mission operations coordinator** orchestrates the run by alternating one analysis step with one recovery-procedure step and tracking progress. It does no diagnosis, procedure authoring, or safety review itself.
- **fault analysis loop** — the **anomaly analyst** writes the fault-cause analysis to `CAUSE_ANALYSIS.md`; the **fault-review board member** judges it. The anomaly analyst reads `RECOVERY_PROCEDURE.md` on each revision pass to incorporate test outcomes, simulator results, and operational evidence.
- **recovery procedure loop** — the **recovery procedure engineer** writes the recovery commands and execution results to `RECOVERY_PROCEDURE.md`; the **flight-safety verifier** judges them. The recovery procedure engineer reads `CAUSE_ANALYSIS.md` on each revision pass to align the procedure with the latest fault hypotheses and safety constraints.

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

The pipeline hands work off through plan-namespaced files:

- `anomaly.md` — the original anomaly report, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing response plan per directory, K plans total, given as input (read-only). All four domain agents read the `PLAN.md` of the plan they are currently assigned to.
- `plans/{id}-{slug}/CAUSE_ANALYSIS.md` — the fault-cause analysis for that plan. Anomaly analyst writes; fault-review board member reviews; recovery procedure engineer and flight-safety verifier read it.
- `plans/{id}-{slug}/RECOVERY_PROCEDURE.md` — the recovery procedure and its test or execution results for that plan. Recovery procedure engineer writes; flight-safety verifier reviews; anomaly analyst and fault-review board member read it.

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

Each plan develops independently. Cross-read between `CAUSE_ANALYSIS.md` and `RECOVERY_PROCEDURE.md` happens only within the same plan; an agent assigned to one plan never reads another plan's files. The mission operations coordinator round-robins across the K plans: each plan gets one analysis step plus one recovery-procedure step per full cycle.

Within each plan, neither fault-cause analysis nor recovery procedure finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. The analysis may tighten after seeing the plan's simulator traces or procedure outcomes; the procedure may change after seeing the plan's refined fault tree, telemetry discriminators, or hazard controls.

I'm providing the following information:

<f1>
You operate on the plan the mission operations coordinator has assigned you to this round. Read `anomaly.md`, your assigned plan's `PLAN.md`, and your assigned plan's `CAUSE_ANALYSIS.md`, then implement the recovery procedure:

- Include every command, prerequisite, parameter value, command authorization, expected telemetry response, and hold point. Define the operational objective and every safety constraint exactly as the anomaly report and response plan state them. Specify command timing, required ground-station coverage, required spacecraft mode, and abort criteria.
- Make the procedure testable against the plan's `CAUSE_ANALYSIS.md`. If the analysis states a battery-voltage floor, momentum limit, thermal ceiling, pressure bound, attitude keep-out zone, or command inhibit, your procedure should preserve it. If the analysis states a diagnostic telemetry signature, your procedure should collect the data needed to confirm or reject it.
- Run the procedure through the available simulator, command-sequence validator, or table-top dry run yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not hide failures behind vague "operator discretion" language.
- Sanity-check the result against the plan's `CAUSE_ANALYSIS.md`. A latch state that must be binary should not be reported as ambiguous; a hazard limit the analysis says must hold should hold; a recovery step that depends on sun-pointing should not be scheduled during an eclipse interval.

Write the procedure and its results up in your assigned plan's `RECOVERY_PROCEDURE.md`. Do not read or write any other plan's files.
</f1>

<f2>
Match the tool to the anomaly structure; do not force an ill-suited one. The list below is useful in spacecraft fault-cause analysis.

| Tool | Suitable for |
|---|---|
| Fault tree analysis / event tree analysis | Enumerating root-cause paths, common-cause failures, and escalation chains |
| FMEA / FMECA | Ranking component failure modes by severity, likelihood, detectability, and mission effect |
| Telemetry trend and residual analysis | Detecting sensor drift, actuator degradation, thermal runaway, power transients, or control-loop mismatch |
| Bayesian diagnosis / belief updating | Updating root-cause likelihoods as new telemetry, simulator runs, or command outcomes arrive |
| State-machine and mode-transition analysis | Flight-software mode errors, safing entry logic, command inhibits, and autonomous fault-protection behavior |
| Control-system stability margins | Attitude-control oscillations, reaction-wheel saturation, thruster pulse response, and closed-loop recovery safety |
| Hazard analysis and fault containment regions | Identifying keep-out conditions, inhibit rules, irreversible actions, and safe operational envelopes |
| Sensitivity / what-if analysis | Stability of the diagnosis and recovery path under telemetry uncertainty, delayed contact, or degraded sensors |
</f2>

<f3>
You operate on the plan the mission operations coordinator has assigned you to this round. Your recovery procedure and its results live in that plan's `RECOVERY_PROCEDURE.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the flight-safety verifier as a loop, alternating with that plan's fault analysis loop, while the mission operations coordinator round-robins across plans.

- If your assigned plan's `RECOVERY_PROCEDURE.md` does not exist yet, this is the first pass for that plan: produce the procedure from scratch based on `anomaly.md` and the plan's `PLAN.md`.
- If the plan's `RECOVERY_PROCEDURE.md` already exists, it carries the flight-safety verifier's `<review>` block. Read that feedback. Then open the plan's `CAUSE_ANALYSIS.md` and check whether the latest analysis introduces safety limits, invariants, diagnostic signatures, or structural claims your current procedure doesn't yet respect — for example a tighter battery state-of-charge floor your procedure now approaches too closely, or an attitude keep-out constraint your command sequence violates. Revise the plan's `RECOVERY_PROCEDURE.md` in place to address every reviewer point and to align with the latest analysis. Don't discard the previous procedure and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f3>

<f4>
Review your assigned plan's `CAUSE_ANALYSIS.md` against `anomaly.md`, against the plan's `PLAN.md`, and against the telemetry, simulator results, or dry-run outcomes reported in the plan's `RECOVERY_PROCEDURE.md` (if any). Operate strictly on the assigned plan's files; do not look at other plans.

- **Faithfulness** — does the analysis correctly describe the anomaly stated in `anomaly.md` under the response concept set by the plan's `PLAN.md`? Check subsystem definitions, telemetry channel names, spacecraft mode assumptions, command constraints, and environmental conditions.
- **Evidence soundness** — for each claim, walk through the telemetry evidence, engineering rationale, or cited mission rule. Flag hand-waving steps. Verify that thresholds, trend interpretations, and causal links apply under the stated assumptions.
- **Operational grounding** — open the plan's `RECOVERY_PROCEDURE.md`. If the procedure reports simulator results, telemetry snapshots, or dry-run outcomes, do they fit within the analysis's predicted signatures and safety margins? A diagnostic threshold that is missed by orders of magnitude is a signal the fault model is too weak; refine it, or note explicitly that the threshold is only illustrative.

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

<f5>
You orchestrate the run; you never diagnose, author recovery procedures, or review mission safety yourself — you only assign the right agent at the right time.

- **Init** — discover the K plan directories under `plans/{id}-{slug}/`. Create `STATE.md` with `iter: 0`, `current_plan_idx: 0`, and a per-plan record holding each plan's id, last side, and latest analysis/procedure scores.
- **Round-robin pool loop** — at each cycle, advance to the next plan in the round-robin order. For that plan, assign one analysis step (anomaly analyst, then fault-review board member) and one recovery-procedure step (recovery procedure engineer, then flight-safety verifier); then move to the next plan. After all K plans have each had one cycle, loop back to the first plan.
- When assigning work, always pass the plan's directory path so the assigned agent knows which `PLAN.md` / `CAUSE_ANALYSIS.md` / `RECOVERY_PROCEDURE.md` to operate on.
- Neither side terminates early on its own score within a plan; even a perfect-looking fault analysis may need to revise once the procedure reports simulator outcomes or telemetry. The pool keeps cycling even after individual plans look done.
- Cap the total at 20 × K dispatches (10 analysis + 10 recovery-procedure steps per plan, summed across K plans). After the cap, stop and summarize per plan.
- Keep the current iteration count, current plan index, and per-plan latest scores in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's reviewer `<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 + plan id + agent name + content) and continue with the next assignment.
</f5>

<f6>
Produce the fault-cause analysis for the plan the mission operations coordinator has assigned you to this round, and write it to that plan's `CAUSE_ANALYSIS.md` (under `plans/{id}-{slug}/CAUSE_ANALYSIS.md`). A complete analysis covers four kinds of claim, each justified with telemetry evidence, engineering rationale, or a cited mission rule.

- **Candidate causes and likelihoods** — plausible root causes such as sensor degradation, actuator saturation, latch-up, thermal drift, bus undervoltage, propellant feed issue, configuration error, or flight-software state-machine fault. Rank them and explain what evidence supports or weakens each one.
- **Structural dependencies** — subsystem coupling, redundancy paths, command authority, fault-protection interactions, mode dependencies, thermal or power cross-coupling, and any single-point failures. State what holds, where, and under which operating assumptions.
- **Safety constraints and invariants** — quantities every safe recovery must preserve, such as battery state-of-charge floor, attitude keep-out zones, momentum envelope, thermal limits, pressure limits, command inhibits, link-margin thresholds, and payload safing requirements. The recovery procedure's output should satisfy them; the flight-safety verifier will check with `verify.py`.
- **Risk, timeline, or convergence** — time-to-loss-of-function estimates, fault growth rates, expected stabilization timeline, required ground contact windows, probability of escalation, or criteria for declaring the response stabilized.

Ground your claims against the plan's `RECOVERY_PROCEDURE.md` if it has reported simulator results, telemetry snapshots, or dry-run outcomes. A predicted telemetry signature that is grossly inconsistent with observed numbers means either the analysis needs revision or the recovery procedure has a defect — diagnose which side has the issue and state it. Be concrete. "Battery bus sag below 25.5 V during wheel desaturation points to a power-transient cause" is fine; "there may be a spacecraft issue" is not. Do not read or aggregate across other plans' files.
</f6>

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

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

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

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

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

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

<f11>
You are working on a spacecraft anomaly response, which may involve attitude control, power, thermal, propulsion, communications, avionics, payload, or flight-software behavior. The original anomaly is given as a natural-language incident report in `anomaly.md`; read it before starting your part.
</f11>

<f12>
You operate on the plan the mission operations coordinator has assigned you to this round. Your fault-cause analysis lives in that plan's `CAUSE_ANALYSIS.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the fault-review board member as a loop, alternating with that plan's recovery-procedure loop, while the mission operations coordinator round-robins across plans.

- If your assigned plan's `CAUSE_ANALYSIS.md` does not exist yet, this is the first pass for that plan: produce the analysis from scratch based on `anomaly.md` and the plan's `PLAN.md`.
- If the plan's `CAUSE_ANALYSIS.md` already exists, it carries the fault-review board member's `<review>` block. Read that feedback. Then open the plan's `RECOVERY_PROCEDURE.md` and look at the latest reported simulator results, telemetry snapshots, or dry-run outcomes — they may invalidate, sharpen, or motivate revisions to your fault hypotheses and safety constraints. Revise the plan's `CAUSE_ANALYSIS.md` in place to address every reviewer point raised and to incorporate any operational evidence that changes your analysis. Don't discard the previous analysis and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f12>

<f13>
Review your assigned plan's `RECOVERY_PROCEDURE.md` against `anomaly.md`, against the plan's `PLAN.md`, and against the plan's `CAUSE_ANALYSIS.md`. Operate strictly on the assigned plan's files; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable telemetry values, unsafe mode transitions, or constraint violations stated directly in `anomaly.md` or in the plan's `PLAN.md`.
- Open the plan's `CAUSE_ANALYSIS.md`. For every bound, safety constraint, and invariant the analysis claims, write a check into a separate `verify.py` under the plan's directory: does the procedure's reported output preserve the invariant, stay within the predicted safety envelope, collect the required diagnostic telemetry, and avoid prohibited command states? Run it. Name any variable or quantity that violates.
- Read the recovery procedure and spot-check it for defects — unused prerequisites, missing inhibits, dead branches, commands that contradict the chosen recovery strategy, or telemetry checks that occur after the irreversible step they were supposed to gate. A defect that silently leaves the spacecraft in a degraded or unsafe state is worse than one that stops the procedure.
- Treat the result as finished only when every mission constraint holds, every analysis-claimed safety invariant holds, and the recovery outcome is consistent with the analysis's fault signatures and margins — not merely when the command sequence validates syntactically.
- Check the length of the plan's `RECOVERY_PROCEDURE.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `RECOVERY_PROCEDURE.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 (mission operations coordinator, anomaly analyst, fault-review board member, recovery procedure engineer, flight-safety verifier), which items should go in its prompt? Respond with a JSON object like {"mission operations coordinator": ["f?"], "anomaly analyst": ["f?"], "fault-review board member": ["f?"], "recovery procedure engineer": ["f?"], "flight-safety verifier": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that responds to spacecraft anomalies by developing fault-cause analysis and recovery procedures in parallel, with each side informing the other under independent mission-safety review. An anomaly arrives as a natural-language incident report in `anomaly.md`. The pipeline alternates between revising the fault analysis (candidate causes, discriminating telemetry, hazard claims, operational constraints) and revising the recovery procedure (the command sequence, go/no-go gates, contingency branches, and expected telemetry response).

The five agents:

- **mission operations coordinator** orchestrates the run by alternating one analysis step with one recovery-procedure step and tracking progress. It does no diagnosis, procedure authoring, or safety review itself.
- **fault analysis loop** — the **anomaly analyst** writes the fault-cause analysis to `CAUSE_ANALYSIS.md`; the **fault-review board member** judges it. The anomaly analyst reads `RECOVERY_PROCEDURE.md` on each revision pass to incorporate test outcomes, simulator results, and operational evidence.
- **recovery procedure loop** — the **recovery procedure engineer** writes the recovery commands and execution results to `RECOVERY_PROCEDURE.md`; the **flight-safety verifier** judges them. The recovery procedure engineer reads `CAUSE_ANALYSIS.md` on each revision pass to align the procedure with the latest fault hypotheses and safety constraints.

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

The pipeline hands work off through plan-namespaced files:

- `anomaly.md` — the original anomaly report, read-only. All four domain agents read it.
- `plans/{id}-{slug}/PLAN.md` — one pre-existing response plan per directory, K plans total, given as input (read-only). All four domain agents read the `PLAN.md` of the plan they are currently assigned to.
- `plans/{id}-{slug}/CAUSE_ANALYSIS.md` — the fault-cause analysis for that plan. Anomaly analyst writes; fault-review board member reviews; recovery procedure engineer and flight-safety verifier read it.
- `plans/{id}-{slug}/RECOVERY_PROCEDURE.md` — the recovery procedure and its test or execution results for that plan. Recovery procedure engineer writes; flight-safety verifier reviews; anomaly analyst and fault-review board member read it.

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

Each plan develops independently. Cross-read between `CAUSE_ANALYSIS.md` and `RECOVERY_PROCEDURE.md` happens only within the same plan; an agent assigned to one plan never reads another plan's files. The mission operations coordinator round-robins across the K plans: each plan gets one analysis step plus one recovery-procedure step per full cycle.

Within each plan, neither fault-cause analysis nor recovery procedure finishes first. Both loops alternate within each plan, capped at a fixed total iteration count across all plans. The analysis may tighten after seeing the plan's simulator traces or procedure outcomes; the procedure may change after seeing the plan's refined fault tree, telemetry discriminators, or hazard controls.

I'm providing the following prompt fragments:

<f1>
You operate on the plan the mission operations coordinator has assigned you to this round. Read `anomaly.md`, your assigned plan's `PLAN.md`, and your assigned plan's `CAUSE_ANALYSIS.md`, then implement the recovery procedure:

- Include every command, prerequisite, parameter value, command authorization, expected telemetry response, and hold point. Define the operational objective and every safety constraint exactly as the anomaly report and response plan state them. Specify command timing, required ground-station coverage, required spacecraft mode, and abort criteria.
- Make the procedure testable against the plan's `CAUSE_ANALYSIS.md`. If the analysis states a battery-voltage floor, momentum limit, thermal ceiling, pressure bound, attitude keep-out zone, or command inhibit, your procedure should preserve it. If the analysis states a diagnostic telemetry signature, your procedure should collect the data needed to confirm or reject it.
- Run the procedure through the available simulator, command-sequence validator, or table-top dry run yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause; do not hide failures behind vague "operator discretion" language.
- Sanity-check the result against the plan's `CAUSE_ANALYSIS.md`. A latch state that must be binary should not be reported as ambiguous; a hazard limit the analysis says must hold should hold; a recovery step that depends on sun-pointing should not be scheduled during an eclipse interval.

Write the procedure and its results up in your assigned plan's `RECOVERY_PROCEDURE.md`. Do not read or write any other plan's files.
</f1>

<f2>
Match the tool to the anomaly structure; do not force an ill-suited one. The list below is useful in spacecraft fault-cause analysis.

| Tool | Suitable for |
|---|---|
| Fault tree analysis / event tree analysis | Enumerating root-cause paths, common-cause failures, and escalation chains |
| FMEA / FMECA | Ranking component failure modes by severity, likelihood, detectability, and mission effect |
| Telemetry trend and residual analysis | Detecting sensor drift, actuator degradation, thermal runaway, power transients, or control-loop mismatch |
| Bayesian diagnosis / belief updating | Updating root-cause likelihoods as new telemetry, simulator runs, or command outcomes arrive |
| State-machine and mode-transition analysis | Flight-software mode errors, safing entry logic, command inhibits, and autonomous fault-protection behavior |
| Control-system stability margins | Attitude-control oscillations, reaction-wheel saturation, thruster pulse response, and closed-loop recovery safety |
| Hazard analysis and fault containment regions | Identifying keep-out conditions, inhibit rules, irreversible actions, and safe operational envelopes |
| Sensitivity / what-if analysis | Stability of the diagnosis and recovery path under telemetry uncertainty, delayed contact, or degraded sensors |
</f2>

<f3>
You operate on the plan the mission operations coordinator has assigned you to this round. Your recovery procedure and its results live in that plan's `RECOVERY_PROCEDURE.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the flight-safety verifier as a loop, alternating with that plan's fault analysis loop, while the mission operations coordinator round-robins across plans.

- If your assigned plan's `RECOVERY_PROCEDURE.md` does not exist yet, this is the first pass for that plan: produce the procedure from scratch based on `anomaly.md` and the plan's `PLAN.md`.
- If the plan's `RECOVERY_PROCEDURE.md` already exists, it carries the flight-safety verifier's `<review>` block. Read that feedback. Then open the plan's `CAUSE_ANALYSIS.md` and check whether the latest analysis introduces safety limits, invariants, diagnostic signatures, or structural claims your current procedure doesn't yet respect — for example a tighter battery state-of-charge floor your procedure now approaches too closely, or an attitude keep-out constraint your command sequence violates. Revise the plan's `RECOVERY_PROCEDURE.md` in place to address every reviewer point and to align with the latest analysis. Don't discard the previous procedure and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f3>

<f4>
Review your assigned plan's `CAUSE_ANALYSIS.md` against `anomaly.md`, against the plan's `PLAN.md`, and against the telemetry, simulator results, or dry-run outcomes reported in the plan's `RECOVERY_PROCEDURE.md` (if any). Operate strictly on the assigned plan's files; do not look at other plans.

- **Faithfulness** — does the analysis correctly describe the anomaly stated in `anomaly.md` under the response concept set by the plan's `PLAN.md`? Check subsystem definitions, telemetry channel names, spacecraft mode assumptions, command constraints, and environmental conditions.
- **Evidence soundness** — for each claim, walk through the telemetry evidence, engineering rationale, or cited mission rule. Flag hand-waving steps. Verify that thresholds, trend interpretations, and causal links apply under the stated assumptions.
- **Operational grounding** — open the plan's `RECOVERY_PROCEDURE.md`. If the procedure reports simulator results, telemetry snapshots, or dry-run outcomes, do they fit within the analysis's predicted signatures and safety margins? A diagnostic threshold that is missed by orders of magnitude is a signal the fault model is too weak; refine it, or note explicitly that the threshold is only illustrative.

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

<f5>
You orchestrate the run; you never diagnose, author recovery procedures, or review mission safety yourself — you only assign the right agent at the right time.

- **Init** — discover the K plan directories under `plans/{id}-{slug}/`. Create `STATE.md` with `iter: 0`, `current_plan_idx: 0`, and a per-plan record holding each plan's id, last side, and latest analysis/procedure scores.
- **Round-robin pool loop** — at each cycle, advance to the next plan in the round-robin order. For that plan, assign one analysis step (anomaly analyst, then fault-review board member) and one recovery-procedure step (recovery procedure engineer, then flight-safety verifier); then move to the next plan. After all K plans have each had one cycle, loop back to the first plan.
- When assigning work, always pass the plan's directory path so the assigned agent knows which `PLAN.md` / `CAUSE_ANALYSIS.md` / `RECOVERY_PROCEDURE.md` to operate on.
- Neither side terminates early on its own score within a plan; even a perfect-looking fault analysis may need to revise once the procedure reports simulator outcomes or telemetry. The pool keeps cycling even after individual plans look done.
- Cap the total at 20 × K dispatches (10 analysis + 10 recovery-procedure steps per plan, summed across K plans). After the cap, stop and summarize per plan.
- Keep the current iteration count, current plan index, and per-plan latest scores in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's reviewer `<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 + plan id + agent name + content) and continue with the next assignment.
</f5>

<f6>
Produce the fault-cause analysis for the plan the mission operations coordinator has assigned you to this round, and write it to that plan's `CAUSE_ANALYSIS.md` (under `plans/{id}-{slug}/CAUSE_ANALYSIS.md`). A complete analysis covers four kinds of claim, each justified with telemetry evidence, engineering rationale, or a cited mission rule.

- **Candidate causes and likelihoods** — plausible root causes such as sensor degradation, actuator saturation, latch-up, thermal drift, bus undervoltage, propellant feed issue, configuration error, or flight-software state-machine fault. Rank them and explain what evidence supports or weakens each one.
- **Structural dependencies** — subsystem coupling, redundancy paths, command authority, fault-protection interactions, mode dependencies, thermal or power cross-coupling, and any single-point failures. State what holds, where, and under which operating assumptions.
- **Safety constraints and invariants** — quantities every safe recovery must preserve, such as battery state-of-charge floor, attitude keep-out zones, momentum envelope, thermal limits, pressure limits, command inhibits, link-margin thresholds, and payload safing requirements. The recovery procedure's output should satisfy them; the flight-safety verifier will check with `verify.py`.
- **Risk, timeline, or convergence** — time-to-loss-of-function estimates, fault growth rates, expected stabilization timeline, required ground contact windows, probability of escalation, or criteria for declaring the response stabilized.

Ground your claims against the plan's `RECOVERY_PROCEDURE.md` if it has reported simulator results, telemetry snapshots, or dry-run outcomes. A predicted telemetry signature that is grossly inconsistent with observed numbers means either the analysis needs revision or the recovery procedure has a defect — diagnose which side has the issue and state it. Be concrete. "Battery bus sag below 25.5 V during wheel desaturation points to a power-transient cause" is fine; "there may be a spacecraft issue" is not. Do not read or aggregate across other plans' files.
</f6>

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

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

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

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

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

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

<f11>
You are working on a spacecraft anomaly response, which may involve attitude control, power, thermal, propulsion, communications, avionics, payload, or flight-software behavior. The original anomaly is given as a natural-language incident report in `anomaly.md`; read it before starting your part.
</f11>

<f12>
You operate on the plan the mission operations coordinator has assigned you to this round. Your fault-cause analysis lives in that plan's `CAUSE_ANALYSIS.md`. You may be invoked on the same plan more than once — within each plan the pipeline runs you and the fault-review board member as a loop, alternating with that plan's recovery-procedure loop, while the mission operations coordinator round-robins across plans.

- If your assigned plan's `CAUSE_ANALYSIS.md` does not exist yet, this is the first pass for that plan: produce the analysis from scratch based on `anomaly.md` and the plan's `PLAN.md`.
- If the plan's `CAUSE_ANALYSIS.md` already exists, it carries the fault-review board member's `<review>` block. Read that feedback. Then open the plan's `RECOVERY_PROCEDURE.md` and look at the latest reported simulator results, telemetry snapshots, or dry-run outcomes — they may invalidate, sharpen, or motivate revisions to your fault hypotheses and safety constraints. Revise the plan's `CAUSE_ANALYSIS.md` in place to address every reviewer point raised and to incorporate any operational evidence that changes your analysis. Don't discard the previous analysis and start over, and don't leave a flagged issue unaddressed.
- Do not read or touch other plans' files.
</f12>

<f13>
Review your assigned plan's `RECOVERY_PROCEDURE.md` against `anomaly.md`, against the plan's `PLAN.md`, and against the plan's `CAUSE_ANALYSIS.md`. Operate strictly on the assigned plan's files; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable telemetry values, unsafe mode transitions, or constraint violations stated directly in `anomaly.md` or in the plan's `PLAN.md`.
- Open the plan's `CAUSE_ANALYSIS.md`. For every bound, safety constraint, and invariant the analysis claims, write a check into a separate `verify.py` under the plan's directory: does the procedure's reported output preserve the invariant, stay within the predicted safety envelope, collect the required diagnostic telemetry, and avoid prohibited command states? Run it. Name any variable or quantity that violates.
- Read the recovery procedure and spot-check it for defects — unused prerequisites, missing inhibits, dead branches, commands that contradict the chosen recovery strategy, or telemetry checks that occur after the irreversible step they were supposed to gate. A defect that silently leaves the spacecraft in a degraded or unsafe state is worse than one that stops the procedure.
- Treat the result as finished only when every mission constraint holds, every analysis-claimed safety invariant holds, and the recovery outcome is consistent with the analysis's fault signatures and margins — not merely when the command sequence validates syntactically.
- Check the length of the plan's `RECOVERY_PROCEDURE.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `RECOVERY_PROCEDURE.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. `# mission operations coordinator`). Output only the headered prompts, no preamble.