I need you to set up a 5-agent cybersecurity pipeline that assesses target systems by developing abstract threat models and concrete red-team exploitation scripts in parallel, with each side informing the other. A system assessment request arrives as a natural-language description in `problem.md`. The pipeline alternates between revising the threat model (attack vectors, invariants, structural vulnerabilities) and revising the exploit scripts (a concrete implementation that tests those defenses).

The five agents:

- **secops-director** orchestrates the run by alternating one threat model step with one exploit step and tracking progress. It does no modeling, scripting, or reviewing itself.
- **threat modeling loop** — the **threat-modeler** writes the abstract threat model to `THEORY.md`; the **security-architect** judges it. The threat-modeler reads `SOLUTION.md` on each revision pass to incorporate empirical execution results from the red team.
- **exploit loop** — the **red-teamer** writes exploit scripts and execution results to `SOLUTION.md`; the **vulnerability-analyst** judges them. The red-teamer reads `THEORY.md` on each revision pass to align the attack paths with the latest theoretical vulnerabilities.

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:

- `problem.md` — the original target system description, read-only. All four domain agents read it.
- `THEORY.md` — the abstract threat model. Threat-modeler writes; security-architect reviews; red-teamer and vulnerability-analyst read it to know which security invariants and attack paths the scripts must evaluate.
- `SOLUTION.md` — the exploit scripts and their results. Red-teamer writes; vulnerability-analyst reviews; threat-modeler and security-architect read it to ground the theoretical model in observed execution data.

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

Unlike a linear assessment pipeline where the model must converge before exploitation starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. The threat model may tighten after seeing the exploit's empirical hurdles; the exploit script may pivot after seeing the threat model's refined attack surfaces.

I'm providing the following information:

<f1>
Read `problem.md` and `THEORY.md`, then implement the red-team exploit scripts:

- Include every import. Create each payload with the correct encoding, define the network targets and memory offsets exactly as the threat model outlines. Execute the script, check the response status, and print both the execution trace and the extracted/compromised data.
- Make the implementation testable against `THEORY.md`. If the model states an attack path requires administrative access, your script should demonstrate acquiring it. If the model defines a security invariant, your script should attempt to bypass or violate it.
- Run the code 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 bury errors under try/except.
- Sanity-check the result against `THEORY.md`. A vulnerability that is supposed to yield a root shell should not just return a low-privilege token; a memory leak the threat model says is accessible should actually be readable.

Write the code and its execution results up in `SOLUTION.md`.
</f1>

<f2>
Match the tool to the target system's architecture; do not force an ill-suited one. The list below is useful in threat modeling and vulnerability analysis.

| Tool | Suitable for |
|---|---|
| Data Flow Analysis | Web/Network architectures; tracing untrusted input to sensitive sinks |
| Attack Trees | Complex systems; modeling multi-step kill chains and prerequisite paths |
| STRIDE Threat Categorization | System architecture; systematic identification of spoofing, tampering, etc. |
| Privilege Escalation Matrices | IAM / RBAC; identifying lateral movement and vertical escalation routes |
| Cryptographic Protocol Analysis | Auth/Encryption; verifying key exchange and secrecy properties |
| Fuzzing Heuristic Modeling | Memory-unsafe code; predicting boundary conditions and crash patterns |
| Taint Analysis | AppSec/Binaries; tracking malicious payload propagation through memory |
| Exploit Mitigation Bypass Analysis | Defended environments; structuring payloads around ASLR/DEP/WAF |
</f2>

<f3>
The exploit scripts and their results live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the vulnerability-analyst as a loop, alternating with the threat modeling loop.

- If `SOLUTION.md` does not exist yet, this is the first pass: produce the exploit script from scratch based on `problem.md`.
- If `SOLUTION.md` already exists, it carries the vulnerability-analyst's `<review>` block. Read that feedback. Then open `THEORY.md` and check whether the latest threat model introduces attack surfaces, invariants, or structural vulnerabilities your current script doesn't yet test — for example a new API endpoint your payload is missing, or an invariant your output hasn't attempted to break. Revise `SOLUTION.md` in place to address every reviewer point and to align with the latest threat model. Don't discard the previous script and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review `THEORY.md` against `problem.md` and against the execution traces reported in `SOLUTION.md` (if any).

- **Faithfulness** — does the threat model correctly describe the architecture stated in `problem.md`? Check component definitions, trust boundaries, and network topologies.
- **Soundness** — for each attack path, walk through the logic. Flag hand-waving steps. Verify cited vulnerabilities apply under the stated system versions and configurations.
- **Empirical grounding** — open `SOLUTION.md`. If the script reports execution outcomes, do they align with the threat model's predicted impact and complexity? An estimated attack complexity that is orders of magnitude off from actual execution time is a signal the model's assumptions are flawed; correct them, or note explicitly that the theoretical complexity is only illustrative.

Be brief and specific. Do not write the threat model yourself — only review. If an attack vector is fundamentally unworkable, say which one and why.
</f4>

<f5>
You orchestrate the run; you never model, script, 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 threat-modeler for the first threat model step (threat-modeler, then security-architect), then the red-teamer for the first exploit step (red-teamer, then vulnerability-analyst).
- **Alternation loop** — alternate one threat model step with one exploit step. Neither side terminates early on its own score; even a perfect-looking threat model may need to revise once the exploit script reports actual execution outcomes.
- Cap the total at 20 iterations (10 threat model steps + 10 exploit 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 abstract threat model for the target system and write it to `THEORY.md`. A complete model covers four kinds of claim, each justified with an architectural proof sketch or a vulnerability citation.

- **Attack Surface & Vectors** — exposed APIs, network ingress points, user trust boundaries, and specific entry parameters.
- **Security Properties** — privilege separation, encryption guarantees, sanitization structural claims, and trust models. State what defenses hold, where they exist, and under which assumptions.
- **Security Invariants** — conditions that the system must maintain (e.g., unauthorized users cannot read protected files, sessions must isolate state, memory boundaries hold). The exploit's output should test these limits; the vulnerability-analyst will check with `verify.py`.
- **Impact & Complexity** — worst-case impact (RCE, data exfiltration, DoS), prerequisite complexity, expected execution time for brute-force methods, or CVSS estimations.

Ground your claims against `SOLUTION.md` if it has reported numbers or execution traces. A predicted attack vector that completely fails to produce a viable exploit means either the threat model needs revision or the script has a bug — diagnose which side has the issue and state it. Be concrete. "The authentication mechanism is vulnerable to a timing attack, succeeding in ~200ms" is fine; "the system has some weaknesses that may help" 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 exploit script fails, but I'm telling you it fails" is still a failing result, not a passing one.
</f7>

<f8>
Keep `SOLUTION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final exploitation 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 secops-director: 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 cybersecurity assessment for a target system, which may be web infrastructure, compiled binaries, network architecture, or a combination. The original system description is given as a natural-language statement in `problem.md`; read it before starting your part.
</f11>

<f12>
The abstract threat model lives in `THEORY.md`, and you may be invoked on it more than once — the pipeline runs you and the security-architect as a loop, alternating with the exploit loop.

- If `THEORY.md` does not exist yet, this is the first pass: produce the threat model from scratch based on `problem.md`.
- If `THEORY.md` already exists, it carries the security-architect's `<review>` block. Read that feedback. Then open `SOLUTION.md` and look at the latest reported execution traces — they may invalidate, sharpen, or motivate revisions to your attack paths. Revise `THEORY.md` in place to address every reviewer point raised and to incorporate any empirical execution data that changes your model. Don't discard the previous model and start over, and don't leave a flagged issue unaddressed.
</f12>

<f13>
Review `SOLUTION.md` against `problem.md` and against `THEORY.md`.

- Inspect the reported execution result for anomalies, failed network connections, or missed targets stated directly in `problem.md`.
- Open `THEORY.md`. For every security invariant the threat model claims, write a check into a separate `verify.py`: does the red-team script's output demonstrably break the invariant, bypass the predicted control, or achieve the modeled impact? Run it. Name any mechanism or state that violates the threat model's expectations.
- Read the exploit code and spot-check it for bugs — unused payloads, dead logic, or mechanisms that contradict the chosen attack vector. A script bug that silently fails to deliver the payload is worse than one that crashes.
- Treat the result as finished only when every targeted access constraint is tested, every threat-model-claimed invariant is evaluated, and the impact is consistent with the model's predictions — not merely when the script runs without error.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.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 (secops-director, threat-modeler, security-architect, red-teamer, vulnerability-analyst), which items should go in its prompt? Respond with a JSON object like {"secops-director": ["f?"], "threat-modeler": ["f?"], "security-architect": ["f?"], "red-teamer": ["f?"], "vulnerability-analyst": ["f?"]}. No other output.

I need you to set up a 5-agent cybersecurity pipeline that assesses target systems by developing abstract threat models and concrete red-team exploitation scripts in parallel, with each side informing the other. A system assessment request arrives as a natural-language description in `problem.md`. The pipeline alternates between revising the threat model (attack vectors, invariants, structural vulnerabilities) and revising the exploit scripts (a concrete implementation that tests those defenses).

The five agents:

- **secops-director** orchestrates the run by alternating one threat model step with one exploit step and tracking progress. It does no modeling, scripting, or reviewing itself.
- **threat modeling loop** — the **threat-modeler** writes the abstract threat model to `THEORY.md`; the **security-architect** judges it. The threat-modeler reads `SOLUTION.md` on each revision pass to incorporate empirical execution results from the red team.
- **exploit loop** — the **red-teamer** writes exploit scripts and execution results to `SOLUTION.md`; the **vulnerability-analyst** judges them. The red-teamer reads `THEORY.md` on each revision pass to align the attack paths with the latest theoretical vulnerabilities.

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:

- `problem.md` — the original target system description, read-only. All four domain agents read it.
- `THEORY.md` — the abstract threat model. Threat-modeler writes; security-architect reviews; red-teamer and vulnerability-analyst read it to know which security invariants and attack paths the scripts must evaluate.
- `SOLUTION.md` — the exploit scripts and their results. Red-teamer writes; vulnerability-analyst reviews; threat-modeler and security-architect read it to ground the theoretical model in observed execution data.

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

Unlike a linear assessment pipeline where the model must converge before exploitation starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. The threat model may tighten after seeing the exploit's empirical hurdles; the exploit script may pivot after seeing the threat model's refined attack surfaces.

I'm providing the following prompt fragments:

<f1>
Read `problem.md` and `THEORY.md`, then implement the red-team exploit scripts:

- Include every import. Create each payload with the correct encoding, define the network targets and memory offsets exactly as the threat model outlines. Execute the script, check the response status, and print both the execution trace and the extracted/compromised data.
- Make the implementation testable against `THEORY.md`. If the model states an attack path requires administrative access, your script should demonstrate acquiring it. If the model defines a security invariant, your script should attempt to bypass or violate it.
- Run the code 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 bury errors under try/except.
- Sanity-check the result against `THEORY.md`. A vulnerability that is supposed to yield a root shell should not just return a low-privilege token; a memory leak the threat model says is accessible should actually be readable.

Write the code and its execution results up in `SOLUTION.md`.
</f1>

<f2>
Match the tool to the target system's architecture; do not force an ill-suited one. The list below is useful in threat modeling and vulnerability analysis.

| Tool | Suitable for |
|---|---|
| Data Flow Analysis | Web/Network architectures; tracing untrusted input to sensitive sinks |
| Attack Trees | Complex systems; modeling multi-step kill chains and prerequisite paths |
| STRIDE Threat Categorization | System architecture; systematic identification of spoofing, tampering, etc. |
| Privilege Escalation Matrices | IAM / RBAC; identifying lateral movement and vertical escalation routes |
| Cryptographic Protocol Analysis | Auth/Encryption; verifying key exchange and secrecy properties |
| Fuzzing Heuristic Modeling | Memory-unsafe code; predicting boundary conditions and crash patterns |
| Taint Analysis | AppSec/Binaries; tracking malicious payload propagation through memory |
| Exploit Mitigation Bypass Analysis | Defended environments; structuring payloads around ASLR/DEP/WAF |
</f2>

<f3>
The exploit scripts and their results live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the vulnerability-analyst as a loop, alternating with the threat modeling loop.

- If `SOLUTION.md` does not exist yet, this is the first pass: produce the exploit script from scratch based on `problem.md`.
- If `SOLUTION.md` already exists, it carries the vulnerability-analyst's `<review>` block. Read that feedback. Then open `THEORY.md` and check whether the latest threat model introduces attack surfaces, invariants, or structural vulnerabilities your current script doesn't yet test — for example a new API endpoint your payload is missing, or an invariant your output hasn't attempted to break. Revise `SOLUTION.md` in place to address every reviewer point and to align with the latest threat model. Don't discard the previous script and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review `THEORY.md` against `problem.md` and against the execution traces reported in `SOLUTION.md` (if any).

- **Faithfulness** — does the threat model correctly describe the architecture stated in `problem.md`? Check component definitions, trust boundaries, and network topologies.
- **Soundness** — for each attack path, walk through the logic. Flag hand-waving steps. Verify cited vulnerabilities apply under the stated system versions and configurations.
- **Empirical grounding** — open `SOLUTION.md`. If the script reports execution outcomes, do they align with the threat model's predicted impact and complexity? An estimated attack complexity that is orders of magnitude off from actual execution time is a signal the model's assumptions are flawed; correct them, or note explicitly that the theoretical complexity is only illustrative.

Be brief and specific. Do not write the threat model yourself — only review. If an attack vector is fundamentally unworkable, say which one and why.
</f4>

<f5>
You orchestrate the run; you never model, script, 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 threat-modeler for the first threat model step (threat-modeler, then security-architect), then the red-teamer for the first exploit step (red-teamer, then vulnerability-analyst).
- **Alternation loop** — alternate one threat model step with one exploit step. Neither side terminates early on its own score; even a perfect-looking threat model may need to revise once the exploit script reports actual execution outcomes.
- Cap the total at 20 iterations (10 threat model steps + 10 exploit 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 abstract threat model for the target system and write it to `THEORY.md`. A complete model covers four kinds of claim, each justified with an architectural proof sketch or a vulnerability citation.

- **Attack Surface & Vectors** — exposed APIs, network ingress points, user trust boundaries, and specific entry parameters.
- **Security Properties** — privilege separation, encryption guarantees, sanitization structural claims, and trust models. State what defenses hold, where they exist, and under which assumptions.
- **Security Invariants** — conditions that the system must maintain (e.g., unauthorized users cannot read protected files, sessions must isolate state, memory boundaries hold). The exploit's output should test these limits; the vulnerability-analyst will check with `verify.py`.
- **Impact & Complexity** — worst-case impact (RCE, data exfiltration, DoS), prerequisite complexity, expected execution time for brute-force methods, or CVSS estimations.

Ground your claims against `SOLUTION.md` if it has reported numbers or execution traces. A predicted attack vector that completely fails to produce a viable exploit means either the threat model needs revision or the script has a bug — diagnose which side has the issue and state it. Be concrete. "The authentication mechanism is vulnerable to a timing attack, succeeding in ~200ms" is fine; "the system has some weaknesses that may help" 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 exploit script fails, but I'm telling you it fails" is still a failing result, not a passing one.
</f7>

<f8>
Keep `SOLUTION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final exploitation 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 secops-director: 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 cybersecurity assessment for a target system, which may be web infrastructure, compiled binaries, network architecture, or a combination. The original system description is given as a natural-language statement in `problem.md`; read it before starting your part.
</f11>

<f12>
The abstract threat model lives in `THEORY.md`, and you may be invoked on it more than once — the pipeline runs you and the security-architect as a loop, alternating with the exploit loop.

- If `THEORY.md` does not exist yet, this is the first pass: produce the threat model from scratch based on `problem.md`.
- If `THEORY.md` already exists, it carries the security-architect's `<review>` block. Read that feedback. Then open `SOLUTION.md` and look at the latest reported execution traces — they may invalidate, sharpen, or motivate revisions to your attack paths. Revise `THEORY.md` in place to address every reviewer point raised and to incorporate any empirical execution data that changes your model. Don't discard the previous model and start over, and don't leave a flagged issue unaddressed.
</f12>

<f13>
Review `SOLUTION.md` against `problem.md` and against `THEORY.md`.

- Inspect the reported execution result for anomalies, failed network connections, or missed targets stated directly in `problem.md`.
- Open `THEORY.md`. For every security invariant the threat model claims, write a check into a separate `verify.py`: does the red-team script's output demonstrably break the invariant, bypass the predicted control, or achieve the modeled impact? Run it. Name any mechanism or state that violates the threat model's expectations.
- Read the exploit code and spot-check it for bugs — unused payloads, dead logic, or mechanisms that contradict the chosen attack vector. A script bug that silently fails to deliver the payload is worse than one that crashes.
- Treat the result as finished only when every targeted access constraint is tested, every threat-model-claimed invariant is evaluated, and the impact is consistent with the model's predictions — not merely when the script runs without error.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.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. `# secops-director`). Output only the headered prompts, no preamble.


chief-engineer aerodynamicist flight-dynamics-evaluator cfd-modeler telemetry-auditor

I need you to set up a 5-agent pipeline that designs aerospace vehicles by alternating between mathematical aerodynamic calculations of performance bounds and computational fluid dynamics (CFD) physical simulations, with each side informing the other. A mission profile and design requirements arrive as a natural-language statement in `problem.md`. The pipeline alternates between revising the aerodynamic math (bounds, flow invariants, aerodynamic claims) and revising the CFD simulation (a mesh and solver setup that achieves those conditions).

The five agents:

- **chief-engineer** orchestrates the run by alternating one aerodynamics step with one CFD step and tracking progress. It does no calculating, meshing, or reviewing itself.
- **aerodynamics loop** — the **aerodynamicist** writes the mathematical aerodynamic calculations to `THEORY.md`; the **flight-dynamics-evaluator** judges it. The aerodynamicist reads `SOLUTION.md` on each revision pass to incorporate empirical CFD evidence.
- **CFD loop** — the **cfd-modeler** writes CFD solver scripts and flow results to `SOLUTION.md`; the **telemetry-auditor** judges them. The cfd-modeler reads `THEORY.md` on each revision pass to align the simulation with the latest mathematical aerodynamic 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:

- `problem.md` — the original mission requirements, read-only. All four domain agents read it.
- `THEORY.md` — the mathematical aerodynamic calculations. Aerodynamicist writes; flight-dynamics-evaluator reviews; cfd-modeler and telemetry-auditor read it to know which aerodynamic bounds and flow invariants the CFD simulation must respect.
- `SOLUTION.md` — the CFD simulation script and flow results. Cfd-modeler writes; telemetry-auditor reviews; aerodynamicist and flight-dynamics-evaluator read it to ground the mathematical theory in observed physical numbers.

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

Unlike a plan-then-code pipeline where the mathematical plan must converge before the CFD starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. Aerodynamic calculations may tighten after seeing CFD's empirical numbers; CFD simulations may correct mesh or solver settings after seeing the math's refined bounds.

I'm providing the following information:

<f1>
Keep `SOLUTION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final mesh configuration, solver setup, and converged results, moving iteration-by-iteration residual 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 calculate aerodynamics, write CFD code, 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 aerodynamicist for the first aerodynamics step (aerodynamicist, then flight-dynamics-evaluator), then the cfd-modeler for the first CFD step (cfd-modeler, then telemetry-auditor).
- **Alternation loop** — alternate one aerodynamic math step with one CFD step. Neither side terminates early on its own score; even perfect-looking math may need to revise once the CFD simulation reports actual flow numbers.
- Cap the total at 20 iterations (10 aerodynamics steps + 10 CFD 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 an aerospace vehicle design problem, which may involve subsonic, transonic, supersonic, or hypersonic flight regimes. The original design requirements and mission profile are given as a natural-language statement in `problem.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 flow field diverges, but I'm telling you it diverges" is still a failing result, not a passing one.
</f4>

<f5>
Produce the theoretical aerodynamic calculations for the vehicle and write it to `THEORY.md`. A complete analysis covers four kinds of claim, each justified with a mathematical derivation or a citation.

- **Performance bounds** — theoretical upper limits on lift-to-drag ratio, lower bounds on wave drag, or maximum structural thermal loads based on isentropic relations.
- **Flow regimes and structural properties** — compressibility effects, expected shockwave detachment, boundary layer transition points, and vehicle cross-sectional area distributions. State what holds, where, and under which assumptions.
- **Invariants** — quantities every physical flow field must preserve (mass conservation laws, stagnation enthalpy, specific heat ratios). The CFD solver's output should satisfy them; the telemetry-auditor will check with `verify.py`.
- **Flow stability and solver convergence** — expected convergence rates for the iterative fluid solvers based on mesh Reynolds numbers, or identifying regions of physical flow instability (e.g., vortex shedding frequencies, flutter margins).

Ground your claims against `SOLUTION.md` if it has reported CFD flow metrics. A predicted drag coefficient that is grossly off from observed CFD numbers means either the aerodynamic calculations need revision or the CFD mesh/solver has a bug — diagnose which side has the issue and state it. Be concrete. "The lift coefficient is bounded above by lifting-line theory, value 1.2" is fine; "the vehicle has some lift" is not.
</f5>

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

<f7>
Match the mathematical tool to the flight regime and vehicle geometry; do not force an ill-suited one. The list below is useful in theoretical aerodynamic analysis.

| Tool | Suitable for |
|---|---|
| Lifting-line theory / Thin airfoil approximations | Subsonic flow; estimating lift distributions, induced drag, and lift curve slopes |
| Oblique shock / Prandtl-Meyer expansion relations | Supersonic regimes; predicting shockwave angles, pressure jumps, and wave drag |
| Whitcomb area rule | Transonic design; wave drag minimization through smooth longitudinal cross-section distributions |
| Navier-Stokes analytical scaling / Blasius solution | Boundary layer analysis; estimating skin friction drag and separation points |
| Isentropic flow and normal shock relations | Compressible aerodynamics; calculating stagnation pressure, temperature, and Mach number changes |
| Panel methods (inviscid) | Low-speed complex geometries; surface pressure distributions before viscous corrections |
| Thermodynamic cycle analysis | Propulsion integration; theoretical thrust, specific impulse, and thermal efficiency limits |
| Linearized perturbation theory | Dynamic stability; computing longitudinal and lateral-directional stability derivatives |
</f7>

<f8>
Read `problem.md` and `THEORY.md`, then implement the CFD simulation script:

- Include every import (e.g., meshing libraries, CFD solver python APIs like SU2 or OpenFOAM wrappers). Generate the mesh with the correct dimensions and boundary conditions, define the fluid properties, and set the turbulence model exactly as the mission requires. Run the simulation, check convergence status, and print both the flow field metrics (lift, drag, moments) and localized peak values.
- Make the simulation testable against `THEORY.md`. If the aerodynamic calculations state a theoretical minimum wave drag D, your CFD should achieve a drag at least D. If the math states a thermodynamic invariant, your output should satisfy it.
- Run the CFD script yourself and watch it through to completion — do not stop while the flow iterations are still converging. If it diverges or crashes, find and fix the root cause; do not bury solver errors under try/except.
- Sanity-check the answer against `THEORY.md`. A Mach number that must be strictly supersonic downstream should not drop to subsonic unphysically; a pressure bound the math says holds should hold.

Write the meshing/solver code and its numerical results up in `SOLUTION.md`.
</f8>

<f9>
Review `SOLUTION.md` against `problem.md` and against `THEORY.md`.

- Inspect the reported CFD results for anomalies, non-physical turbulence values, or boundary condition violations stated directly in `problem.md`.
- Open `THEORY.md`. For every mathematical bound and invariant the aerodynamicist claims, write a check into a separate `verify.py`: does the CFD solver's flow field satisfy the thermodynamic invariant, fall within the predicted lift/drag bounds, achieve the predicted pressure ratio? Run it. Name any variable or node quantity that violates.
- Read the CFD meshing and solver setup code and spot-check it for bugs — coarse mesh densities in high-gradient regions, wrong turbulence models, or timestep logic that contradicts the chosen flow regime. A boundary condition bug that silently degrades the flow field is worse than one that crashes the solver.
- Treat the result as finished only when every boundary condition holds, every mathematically claimed flow invariant holds, and the integrated forces are consistent with the aerodynamic bounds — not merely when the solver converges without error.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.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 mathematical aerodynamic calculations live in `THEORY.md`, and you may be invoked on it more than once — the pipeline runs you and the flight-dynamics-evaluator as a loop, alternating with the CFD loop.

- If `THEORY.md` does not exist yet, this is the first pass: produce the aerodynamic math from scratch based on `problem.md`.
- If `THEORY.md` already exists, it carries the flight-dynamics-evaluator's `<review>` block. Read that feedback. Then open `SOLUTION.md` and look at the latest reported CFD flow numbers — they may invalidate, sharpen, or motivate revisions to your mathematical claims. Revise `THEORY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous calculations and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
Review `THEORY.md` against `problem.md` and against the numbers reported in `SOLUTION.md` (if any).

- **Faithfulness** — do the aerodynamic calculations correctly describe the vehicle mission stated in `problem.md`? Check velocity regimes, atmospheric conditions, and geometric constraints.
- **Math soundness** — for each claim, walk through the equation derivation or citation. Flag hand-waving steps. Verify cited aerodynamic relations apply under the stated assumptions (e.g., no incompressible formulas at Mach 2).
- **Empirical grounding** — open `SOLUTION.md`. If the CFD reports lift and drag forces, do they fall within the math's predicted bounds? An analytical wave drag estimate that is off by orders of magnitude from CFD is a signal the underlying assumption is too weak; tighten it, or note explicitly that the formulation is only illustrative.

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

<f13>
The CFD meshing/solver code and its flow results live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the telemetry-auditor as a loop, alternating with the aerodynamics loop.

- If `SOLUTION.md` does not exist yet, this is the first pass: produce the CFD solution from scratch based on `problem.md`.
- If `SOLUTION.md` already exists, it carries the telemetry-auditor's `<review>` block. Read that feedback. Then open `THEORY.md` and check whether the latest aerodynamic math introduces bounds, invariants, or flow claims your current CFD simulation doesn't yet respect — for example a tighter wave drag bound your solver is now far from achieving, or a thermodynamic invariant your flow field violates. Revise `SOLUTION.md` in place to address every reviewer point and to align with the latest math. Don't discard the previous simulation 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 (chief-engineer, aerodynamicist, flight-dynamics-evaluator, cfd-modeler, telemetry-auditor), which items should go in its prompt? Respond with a JSON object like {"chief-engineer": ["f?"], "aerodynamicist": ["f?"], "flight-dynamics-evaluator": ["f?"], "cfd-modeler": ["f?"], "telemetry-auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that designs aerospace vehicles by alternating between mathematical aerodynamic calculations of performance bounds and computational fluid dynamics (CFD) physical simulations, with each side informing the other. A mission profile and design requirements arrive as a natural-language statement in `problem.md`. The pipeline alternates between revising the aerodynamic math (bounds, flow invariants, aerodynamic claims) and revising the CFD simulation (a mesh and solver setup that achieves those conditions).

The five agents:

- **chief-engineer** orchestrates the run by alternating one aerodynamics step with one CFD step and tracking progress. It does no calculating, meshing, or reviewing itself.
- **aerodynamics loop** — the **aerodynamicist** writes the mathematical aerodynamic calculations to `THEORY.md`; the **flight-dynamics-evaluator** judges it. The aerodynamicist reads `SOLUTION.md` on each revision pass to incorporate empirical CFD evidence.
- **CFD loop** — the **cfd-modeler** writes CFD solver scripts and flow results to `SOLUTION.md`; the **telemetry-auditor** judges them. The cfd-modeler reads `THEORY.md` on each revision pass to align the simulation with the latest mathematical aerodynamic 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:

- `problem.md` — the original mission requirements, read-only. All four domain agents read it.
- `THEORY.md` — the mathematical aerodynamic calculations. Aerodynamicist writes; flight-dynamics-evaluator reviews; cfd-modeler and telemetry-auditor read it to know which aerodynamic bounds and flow invariants the CFD simulation must respect.
- `SOLUTION.md` — the CFD simulation script and flow results. Cfd-modeler writes; telemetry-auditor reviews; aerodynamicist and flight-dynamics-evaluator read it to ground the mathematical theory in observed physical numbers.

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

Unlike a plan-then-code pipeline where the mathematical plan must converge before the CFD starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. Aerodynamic calculations may tighten after seeing CFD's empirical numbers; CFD simulations may correct mesh or solver settings after seeing the math's refined bounds.

I'm providing the following prompt fragments:

<f1>
Keep `SOLUTION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final mesh configuration, solver setup, and converged results, moving iteration-by-iteration residual 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 calculate aerodynamics, write CFD code, 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 aerodynamicist for the first aerodynamics step (aerodynamicist, then flight-dynamics-evaluator), then the cfd-modeler for the first CFD step (cfd-modeler, then telemetry-auditor).
- **Alternation loop** — alternate one aerodynamic math step with one CFD step. Neither side terminates early on its own score; even perfect-looking math may need to revise once the CFD simulation reports actual flow numbers.
- Cap the total at 20 iterations (10 aerodynamics steps + 10 CFD 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 an aerospace vehicle design problem, which may involve subsonic, transonic, supersonic, or hypersonic flight regimes. The original design requirements and mission profile are given as a natural-language statement in `problem.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 flow field diverges, but I'm telling you it diverges" is still a failing result, not a passing one.
</f4>

<f5>
Produce the theoretical aerodynamic calculations for the vehicle and write it to `THEORY.md`. A complete analysis covers four kinds of claim, each justified with a mathematical derivation or a citation.

- **Performance bounds** — theoretical upper limits on lift-to-drag ratio, lower bounds on wave drag, or maximum structural thermal loads based on isentropic relations.
- **Flow regimes and structural properties** — compressibility effects, expected shockwave detachment, boundary layer transition points, and vehicle cross-sectional area distributions. State what holds, where, and under which assumptions.
- **Invariants** — quantities every physical flow field must preserve (mass conservation laws, stagnation enthalpy, specific heat ratios). The CFD solver's output should satisfy them; the telemetry-auditor will check with `verify.py`.
- **Flow stability and solver convergence** — expected convergence rates for the iterative fluid solvers based on mesh Reynolds numbers, or identifying regions of physical flow instability (e.g., vortex shedding frequencies, flutter margins).

Ground your claims against `SOLUTION.md` if it has reported CFD flow metrics. A predicted drag coefficient that is grossly off from observed CFD numbers means either the aerodynamic calculations need revision or the CFD mesh/solver has a bug — diagnose which side has the issue and state it. Be concrete. "The lift coefficient is bounded above by lifting-line theory, value 1.2" is fine; "the vehicle has some lift" is not.
</f5>

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

<f7>
Match the mathematical tool to the flight regime and vehicle geometry; do not force an ill-suited one. The list below is useful in theoretical aerodynamic analysis.

| Tool | Suitable for |
|---|---|
| Lifting-line theory / Thin airfoil approximations | Subsonic flow; estimating lift distributions, induced drag, and lift curve slopes |
| Oblique shock / Prandtl-Meyer expansion relations | Supersonic regimes; predicting shockwave angles, pressure jumps, and wave drag |
| Whitcomb area rule | Transonic design; wave drag minimization through smooth longitudinal cross-section distributions |
| Navier-Stokes analytical scaling / Blasius solution | Boundary layer analysis; estimating skin friction drag and separation points |
| Isentropic flow and normal shock relations | Compressible aerodynamics; calculating stagnation pressure, temperature, and Mach number changes |
| Panel methods (inviscid) | Low-speed complex geometries; surface pressure distributions before viscous corrections |
| Thermodynamic cycle analysis | Propulsion integration; theoretical thrust, specific impulse, and thermal efficiency limits |
| Linearized perturbation theory | Dynamic stability; computing longitudinal and lateral-directional stability derivatives |
</f7>

<f8>
Read `problem.md` and `THEORY.md`, then implement the CFD simulation script:

- Include every import (e.g., meshing libraries, CFD solver python APIs like SU2 or OpenFOAM wrappers). Generate the mesh with the correct dimensions and boundary conditions, define the fluid properties, and set the turbulence model exactly as the mission requires. Run the simulation, check convergence status, and print both the flow field metrics (lift, drag, moments) and localized peak values.
- Make the simulation testable against `THEORY.md`. If the aerodynamic calculations state a theoretical minimum wave drag D, your CFD should achieve a drag at least D. If the math states a thermodynamic invariant, your output should satisfy it.
- Run the CFD script yourself and watch it through to completion — do not stop while the flow iterations are still converging. If it diverges or crashes, find and fix the root cause; do not bury solver errors under try/except.
- Sanity-check the answer against `THEORY.md`. A Mach number that must be strictly supersonic downstream should not drop to subsonic unphysically; a pressure bound the math says holds should hold.

Write the meshing/solver code and its numerical results up in `SOLUTION.md`.
</f8>

<f9>
Review `SOLUTION.md` against `problem.md` and against `THEORY.md`.

- Inspect the reported CFD results for anomalies, non-physical turbulence values, or boundary condition violations stated directly in `problem.md`.
- Open `THEORY.md`. For every mathematical bound and invariant the aerodynamicist claims, write a check into a separate `verify.py`: does the CFD solver's flow field satisfy the thermodynamic invariant, fall within the predicted lift/drag bounds, achieve the predicted pressure ratio? Run it. Name any variable or node quantity that violates.
- Read the CFD meshing and solver setup code and spot-check it for bugs — coarse mesh densities in high-gradient regions, wrong turbulence models, or timestep logic that contradicts the chosen flow regime. A boundary condition bug that silently degrades the flow field is worse than one that crashes the solver.
- Treat the result as finished only when every boundary condition holds, every mathematically claimed flow invariant holds, and the integrated forces are consistent with the aerodynamic bounds — not merely when the solver converges without error.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.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 mathematical aerodynamic calculations live in `THEORY.md`, and you may be invoked on it more than once — the pipeline runs you and the flight-dynamics-evaluator as a loop, alternating with the CFD loop.

- If `THEORY.md` does not exist yet, this is the first pass: produce the aerodynamic math from scratch based on `problem.md`.
- If `THEORY.md` already exists, it carries the flight-dynamics-evaluator's `<review>` block. Read that feedback. Then open `SOLUTION.md` and look at the latest reported CFD flow numbers — they may invalidate, sharpen, or motivate revisions to your mathematical claims. Revise `THEORY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous calculations and start over, and don't leave a flagged issue unaddressed.
</f11>

<f12>
Review `THEORY.md` against `problem.md` and against the numbers reported in `SOLUTION.md` (if any).

- **Faithfulness** — do the aerodynamic calculations correctly describe the vehicle mission stated in `problem.md`? Check velocity regimes, atmospheric conditions, and geometric constraints.
- **Math soundness** — for each claim, walk through the equation derivation or citation. Flag hand-waving steps. Verify cited aerodynamic relations apply under the stated assumptions (e.g., no incompressible formulas at Mach 2).
- **Empirical grounding** — open `SOLUTION.md`. If the CFD reports lift and drag forces, do they fall within the math's predicted bounds? An analytical wave drag estimate that is off by orders of magnitude from CFD is a signal the underlying assumption is too weak; tighten it, or note explicitly that the formulation is only illustrative.

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

<f13>
The CFD meshing/solver code and its flow results live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the telemetry-auditor as a loop, alternating with the aerodynamics loop.

- If `SOLUTION.md` does not exist yet, this is the first pass: produce the CFD solution from scratch based on `problem.md`.
- If `SOLUTION.md` already exists, it carries the telemetry-auditor's `<review>` block. Read that feedback. Then open `THEORY.md` and check whether the latest aerodynamic math introduces bounds, invariants, or flow claims your current CFD simulation doesn't yet respect — for example a tighter wave drag bound your solver is now far from achieving, or a thermodynamic invariant your flow field violates. Revise `SOLUTION.md` in place to address every reviewer point and to align with the latest math. Don't discard the previous simulation 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. `# chief-engineer`). Output only the headered prompts, no preamble.


I need you to set up a 5-agent pipeline that designs aerospace vehicles by alternating between mathematical aerodynamic calculations of performance bounds and computational fluid dynamics (CFD) physical simulations, with each side informing the other. A mission profile and design requirements arrive as a natural-language statement in `problem.md`. The pipeline alternates between revising the aerodynamic math (bounds, flow invariants, aerodynamic claims) and revising the CFD simulation (a mesh and solver setup that achieves those conditions).

The five agents:

- **chief-engineer** orchestrates the run by alternating one aerodynamics step with one CFD step and tracking progress. It does no calculating, meshing, or reviewing itself.
- **aerodynamics loop** — the **aerodynamicist** writes the mathematical aerodynamic calculations to `THEORY.md`; the **flight-dynamics-evaluator** judges it. The aerodynamicist reads `SOLUTION.md` on each revision pass to incorporate empirical CFD evidence.
- **CFD loop** — the **cfd-modeler** writes CFD solver scripts and flow results to `SOLUTION.md`; the **telemetry-auditor** judges them. The cfd-modeler reads `THEORY.md` on each revision pass to align the simulation with the latest mathematical aerodynamic 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:

- `problem.md` — the original mission requirements, read-only. All four domain agents read it.
- `THEORY.md` — the mathematical aerodynamic calculations. Aerodynamicist writes; flight-dynamics-evaluator reviews; cfd-modeler and telemetry-auditor read it to know which aerodynamic bounds and flow invariants the CFD simulation must respect.
- `SOLUTION.md` — the CFD simulation script and flow results. Cfd-modeler writes; telemetry-auditor reviews; aerodynamicist and flight-dynamics-evaluator read it to ground the mathematical theory in observed physical numbers.

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

Unlike a plan-then-code pipeline where the mathematical plan must converge before the CFD starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. Aerodynamic calculations may tighten after seeing CFD's empirical numbers; CFD simulations may correct mesh or solver settings after seeing the math's refined bounds.

I'm providing the following information:

<f1>
Read `problem.md` and `THEORY.md`, then implement the CFD simulation script:

- Include every import (e.g., meshing libraries, CFD solver python APIs like SU2 or OpenFOAM wrappers). Generate the mesh with the correct dimensions and boundary conditions, define the fluid properties, and set the turbulence model exactly as the mission requires. Run the simulation, check convergence status, and print both the flow field metrics (lift, drag, moments) and localized peak values.
- Make the simulation testable against `THEORY.md`. If the aerodynamic calculations state a theoretical minimum wave drag D, your CFD should achieve a drag at least D. If the math states a thermodynamic invariant, your output should satisfy it.
- Run the CFD script yourself and watch it through to completion — do not stop while the flow iterations are still converging. If it diverges or crashes, find and fix the root cause; do not bury solver errors under try/except.
- Sanity-check the answer against `THEORY.md`. A Mach number that must be strictly supersonic downstream should not drop to subsonic unphysically; a pressure bound the math says holds should hold.

Write the meshing/solver code and its numerical results up in `SOLUTION.md`.
</f1>

<f2>
Match the mathematical tool to the flight regime and vehicle geometry; do not force an ill-suited one. The list below is useful in theoretical aerodynamic analysis.

| Tool | Suitable for |
|---|---|
| Lifting-line theory / Thin airfoil approximations | Subsonic flow; estimating lift distributions, induced drag, and lift curve slopes |
| Oblique shock / Prandtl-Meyer expansion relations | Supersonic regimes; predicting shockwave angles, pressure jumps, and wave drag |
| Whitcomb area rule | Transonic design; wave drag minimization through smooth longitudinal cross-section distributions |
| Navier-Stokes analytical scaling / Blasius solution | Boundary layer analysis; estimating skin friction drag and separation points |
| Isentropic flow and normal shock relations | Compressible aerodynamics; calculating stagnation pressure, temperature, and Mach number changes |
| Panel methods (inviscid) | Low-speed complex geometries; surface pressure distributions before viscous corrections |
| Thermodynamic cycle analysis | Propulsion integration; theoretical thrust, specific impulse, and thermal efficiency limits |
| Linearized perturbation theory | Dynamic stability; computing longitudinal and lateral-directional stability derivatives |
</f2>

<f3>
The CFD meshing/solver code and its flow results live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the telemetry-auditor as a loop, alternating with the aerodynamics loop.

- If `SOLUTION.md` does not exist yet, this is the first pass: produce the CFD solution from scratch based on `problem.md`.
- If `SOLUTION.md` already exists, it carries the telemetry-auditor's `<review>` block. Read that feedback. Then open `THEORY.md` and check whether the latest aerodynamic math introduces bounds, invariants, or flow claims your current CFD simulation doesn't yet respect — for example a tighter wave drag bound your solver is now far from achieving, or a thermodynamic invariant your flow field violates. Revise `SOLUTION.md` in place to address every reviewer point and to align with the latest math. Don't discard the previous simulation and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review `THEORY.md` against `problem.md` and against the numbers reported in `SOLUTION.md` (if any).

- **Faithfulness** — do the aerodynamic calculations correctly describe the vehicle mission stated in `problem.md`? Check velocity regimes, atmospheric conditions, and geometric constraints.
- **Math soundness** — for each claim, walk through the equation derivation or citation. Flag hand-waving steps. Verify cited aerodynamic relations apply under the stated assumptions (e.g., no incompressible formulas at Mach 2).
- **Empirical grounding** — open `SOLUTION.md`. If the CFD reports lift and drag forces, do they fall within the math's predicted bounds? An analytical wave drag estimate that is off by orders of magnitude from CFD is a signal the underlying assumption is too weak; tighten it, or note explicitly that the formulation is only illustrative.

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

<f5>
You orchestrate the run; you never calculate aerodynamics, write CFD code, 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 aerodynamicist for the first aerodynamics step (aerodynamicist, then flight-dynamics-evaluator), then the cfd-modeler for the first CFD step (cfd-modeler, then telemetry-auditor).
- **Alternation loop** — alternate one aerodynamic math step with one CFD step. Neither side terminates early on its own score; even perfect-looking math may need to revise once the CFD simulation reports actual flow numbers.
- Cap the total at 20 iterations (10 aerodynamics steps + 10 CFD 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 theoretical aerodynamic calculations for the vehicle and write it to `THEORY.md`. A complete analysis covers four kinds of claim, each justified with a mathematical derivation or a citation.

- **Performance bounds** — theoretical upper limits on lift-to-drag ratio, lower bounds on wave drag, or maximum structural thermal loads based on isentropic relations.
- **Flow regimes and structural properties** — compressibility effects, expected shockwave detachment, boundary layer transition points, and vehicle cross-sectional area distributions. State what holds, where, and under which assumptions.
- **Invariants** — quantities every physical flow field must preserve (mass conservation laws, stagnation enthalpy, specific heat ratios). The CFD solver's output should satisfy them; the telemetry-auditor will check with `verify.py`.
- **Flow stability and solver convergence** — expected convergence rates for the iterative fluid solvers based on mesh Reynolds numbers, or identifying regions of physical flow instability (e.g., vortex shedding frequencies, flutter margins).

Ground your claims against `SOLUTION.md` if it has reported CFD flow metrics. A predicted drag coefficient that is grossly off from observed CFD numbers means either the aerodynamic calculations need revision or the CFD mesh/solver has a bug — diagnose which side has the issue and state it. Be concrete. "The lift coefficient is bounded above by lifting-line theory, value 1.2" is fine; "the vehicle has some lift" 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 flow field diverges, but I'm telling you it diverges" is still a failing result, not a passing one.
</f7>

<f8>
Keep `SOLUTION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final mesh configuration, solver setup, and converged results, moving iteration-by-iteration residual 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 chief-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 an aerospace vehicle design problem, which may involve subsonic, transonic, supersonic, or hypersonic flight regimes. The original design requirements and mission profile are given as a natural-language statement in `problem.md`; read it before starting your part.
</f11>

<f12>
The mathematical aerodynamic calculations live in `THEORY.md`, and you may be invoked on it more than once — the pipeline runs you and the flight-dynamics-evaluator as a loop, alternating with the CFD loop.

- If `THEORY.md` does not exist yet, this is the first pass: produce the aerodynamic math from scratch based on `problem.md`.
- If `THEORY.md` already exists, it carries the flight-dynamics-evaluator's `<review>` block. Read that feedback. Then open `SOLUTION.md` and look at the latest reported CFD flow numbers — they may invalidate, sharpen, or motivate revisions to your mathematical claims. Revise `THEORY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous calculations and start over, and don't leave a flagged issue unaddressed.
</f12>

<f13>
Review `SOLUTION.md` against `problem.md` and against `THEORY.md`.

- Inspect the reported CFD results for anomalies, non-physical turbulence values, or boundary condition violations stated directly in `problem.md`.
- Open `THEORY.md`. For every mathematical bound and invariant the aerodynamicist claims, write a check into a separate `verify.py`: does the CFD solver's flow field satisfy the thermodynamic invariant, fall within the predicted lift/drag bounds, achieve the predicted pressure ratio? Run it. Name any variable or node quantity that violates.
- Read the CFD meshing and solver setup code and spot-check it for bugs — coarse mesh densities in high-gradient regions, wrong turbulence models, or timestep logic that contradicts the chosen flow regime. A boundary condition bug that silently degrades the flow field is worse than one that crashes the solver.
- Treat the result as finished only when every boundary condition holds, every mathematically claimed flow invariant holds, and the integrated forces are consistent with the aerodynamic bounds — not merely when the solver converges without error.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.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 (chief-engineer, aerodynamicist, flight-dynamics-evaluator, cfd-modeler, telemetry-auditor), which items should go in its prompt? Respond with a JSON object like {"chief-engineer": ["f?"], "aerodynamicist": ["f?"], "flight-dynamics-evaluator": ["f?"], "cfd-modeler": ["f?"], "telemetry-auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that designs aerospace vehicles by alternating between mathematical aerodynamic calculations of performance bounds and computational fluid dynamics (CFD) physical simulations, with each side informing the other. A mission profile and design requirements arrive as a natural-language statement in `problem.md`. The pipeline alternates between revising the aerodynamic math (bounds, flow invariants, aerodynamic claims) and revising the CFD simulation (a mesh and solver setup that achieves those conditions).

The five agents:

- **chief-engineer** orchestrates the run by alternating one aerodynamics step with one CFD step and tracking progress. It does no calculating, meshing, or reviewing itself.
- **aerodynamics loop** — the **aerodynamicist** writes the mathematical aerodynamic calculations to `THEORY.md`; the **flight-dynamics-evaluator** judges it. The aerodynamicist reads `SOLUTION.md` on each revision pass to incorporate empirical CFD evidence.
- **CFD loop** — the **cfd-modeler** writes CFD solver scripts and flow results to `SOLUTION.md`; the **telemetry-auditor** judges them. The cfd-modeler reads `THEORY.md` on each revision pass to align the simulation with the latest mathematical aerodynamic 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:

- `problem.md` — the original mission requirements, read-only. All four domain agents read it.
- `THEORY.md` — the mathematical aerodynamic calculations. Aerodynamicist writes; flight-dynamics-evaluator reviews; cfd-modeler and telemetry-auditor read it to know which aerodynamic bounds and flow invariants the CFD simulation must respect.
- `SOLUTION.md` — the CFD simulation script and flow results. Cfd-modeler writes; telemetry-auditor reviews; aerodynamicist and flight-dynamics-evaluator read it to ground the mathematical theory in observed physical numbers.

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

Unlike a plan-then-code pipeline where the mathematical plan must converge before the CFD starts, here neither side ever finishes first. Both loops alternate forever, capped at a fixed iteration count. Aerodynamic calculations may tighten after seeing CFD's empirical numbers; CFD simulations may correct mesh or solver settings after seeing the math's refined bounds.

I'm providing the following prompt fragments:

<f1>
Read `problem.md` and `THEORY.md`, then implement the CFD simulation script:

- Include every import (e.g., meshing libraries, CFD solver python APIs like SU2 or OpenFOAM wrappers). Generate the mesh with the correct dimensions and boundary conditions, define the fluid properties, and set the turbulence model exactly as the mission requires. Run the simulation, check convergence status, and print both the flow field metrics (lift, drag, moments) and localized peak values.
- Make the simulation testable against `THEORY.md`. If the aerodynamic calculations state a theoretical minimum wave drag D, your CFD should achieve a drag at least D. If the math states a thermodynamic invariant, your output should satisfy it.
- Run the CFD script yourself and watch it through to completion — do not stop while the flow iterations are still converging. If it diverges or crashes, find and fix the root cause; do not bury solver errors under try/except.
- Sanity-check the answer against `THEORY.md`. A Mach number that must be strictly supersonic downstream should not drop to subsonic unphysically; a pressure bound the math says holds should hold.

Write the meshing/solver code and its numerical results up in `SOLUTION.md`.
</f1>

<f2>
Match the mathematical tool to the flight regime and vehicle geometry; do not force an ill-suited one. The list below is useful in theoretical aerodynamic analysis.

| Tool | Suitable for |
|---|---|
| Lifting-line theory / Thin airfoil approximations | Subsonic flow; estimating lift distributions, induced drag, and lift curve slopes |
| Oblique shock / Prandtl-Meyer expansion relations | Supersonic regimes; predicting shockwave angles, pressure jumps, and wave drag |
| Whitcomb area rule | Transonic design; wave drag minimization through smooth longitudinal cross-section distributions |
| Navier-Stokes analytical scaling / Blasius solution | Boundary layer analysis; estimating skin friction drag and separation points |
| Isentropic flow and normal shock relations | Compressible aerodynamics; calculating stagnation pressure, temperature, and Mach number changes |
| Panel methods (inviscid) | Low-speed complex geometries; surface pressure distributions before viscous corrections |
| Thermodynamic cycle analysis | Propulsion integration; theoretical thrust, specific impulse, and thermal efficiency limits |
| Linearized perturbation theory | Dynamic stability; computing longitudinal and lateral-directional stability derivatives |
</f2>

<f3>
The CFD meshing/solver code and its flow results live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the telemetry-auditor as a loop, alternating with the aerodynamics loop.

- If `SOLUTION.md` does not exist yet, this is the first pass: produce the CFD solution from scratch based on `problem.md`.
- If `SOLUTION.md` already exists, it carries the telemetry-auditor's `<review>` block. Read that feedback. Then open `THEORY.md` and check whether the latest aerodynamic math introduces bounds, invariants, or flow claims your current CFD simulation doesn't yet respect — for example a tighter wave drag bound your solver is now far from achieving, or a thermodynamic invariant your flow field violates. Revise `SOLUTION.md` in place to address every reviewer point and to align with the latest math. Don't discard the previous simulation and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review `THEORY.md` against `problem.md` and against the numbers reported in `SOLUTION.md` (if any).

- **Faithfulness** — do the aerodynamic calculations correctly describe the vehicle mission stated in `problem.md`? Check velocity regimes, atmospheric conditions, and geometric constraints.
- **Math soundness** — for each claim, walk through the equation derivation or citation. Flag hand-waving steps. Verify cited aerodynamic relations apply under the stated assumptions (e.g., no incompressible formulas at Mach 2).
- **Empirical grounding** — open `SOLUTION.md`. If the CFD reports lift and drag forces, do they fall within the math's predicted bounds? An analytical wave drag estimate that is off by orders of magnitude from CFD is a signal the underlying assumption is too weak; tighten it, or note explicitly that the formulation is only illustrative.

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

<f5>
You orchestrate the run; you never calculate aerodynamics, write CFD code, 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 aerodynamicist for the first aerodynamics step (aerodynamicist, then flight-dynamics-evaluator), then the cfd-modeler for the first CFD step (cfd-modeler, then telemetry-auditor).
- **Alternation loop** — alternate one aerodynamic math step with one CFD step. Neither side terminates early on its own score; even perfect-looking math may need to revise once the CFD simulation reports actual flow numbers.
- Cap the total at 20 iterations (10 aerodynamics steps + 10 CFD 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 theoretical aerodynamic calculations for the vehicle and write it to `THEORY.md`. A complete analysis covers four kinds of claim, each justified with a mathematical derivation or a citation.

- **Performance bounds** — theoretical upper limits on lift-to-drag ratio, lower bounds on wave drag, or maximum structural thermal loads based on isentropic relations.
- **Flow regimes and structural properties** — compressibility effects, expected shockwave detachment, boundary layer transition points, and vehicle cross-sectional area distributions. State what holds, where, and under which assumptions.
- **Invariants** — quantities every physical flow field must preserve (mass conservation laws, stagnation enthalpy, specific heat ratios). The CFD solver's output should satisfy them; the telemetry-auditor will check with `verify.py`.
- **Flow stability and solver convergence** — expected convergence rates for the iterative fluid solvers based on mesh Reynolds numbers, or identifying regions of physical flow instability (e.g., vortex shedding frequencies, flutter margins).

Ground your claims against `SOLUTION.md` if it has reported CFD flow metrics. A predicted drag coefficient that is grossly off from observed CFD numbers means either the aerodynamic calculations need revision or the CFD mesh/solver has a bug — diagnose which side has the issue and state it. Be concrete. "The lift coefficient is bounded above by lifting-line theory, value 1.2" is fine; "the vehicle has some lift" 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 flow field diverges, but I'm telling you it diverges" is still a failing result, not a passing one.
</f7>

<f8>
Keep `SOLUTION.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final mesh configuration, solver setup, and converged results, moving iteration-by-iteration residual 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 chief-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 an aerospace vehicle design problem, which may involve subsonic, transonic, supersonic, or hypersonic flight regimes. The original design requirements and mission profile are given as a natural-language statement in `problem.md`; read it before starting your part.
</f11>

<f12>
The mathematical aerodynamic calculations live in `THEORY.md`, and you may be invoked on it more than once — the pipeline runs you and the flight-dynamics-evaluator as a loop, alternating with the CFD loop.

- If `THEORY.md` does not exist yet, this is the first pass: produce the aerodynamic math from scratch based on `problem.md`.
- If `THEORY.md` already exists, it carries the flight-dynamics-evaluator's `<review>` block. Read that feedback. Then open `SOLUTION.md` and look at the latest reported CFD flow numbers — they may invalidate, sharpen, or motivate revisions to your mathematical claims. Revise `THEORY.md` in place to address every reviewer point raised and to incorporate any empirical evidence that changes your analysis. Don't discard the previous calculations and start over, and don't leave a flagged issue unaddressed.
</f12>

<f13>
Review `SOLUTION.md` against `problem.md` and against `THEORY.md`.

- Inspect the reported CFD results for anomalies, non-physical turbulence values, or boundary condition violations stated directly in `problem.md`.
- Open `THEORY.md`. For every mathematical bound and invariant the aerodynamicist claims, write a check into a separate `verify.py`: does the CFD solver's flow field satisfy the thermodynamic invariant, fall within the predicted lift/drag bounds, achieve the predicted pressure ratio? Run it. Name any variable or node quantity that violates.
- Read the CFD meshing and solver setup code and spot-check it for bugs — coarse mesh densities in high-gradient regions, wrong turbulence models, or timestep logic that contradicts the chosen flow regime. A boundary condition bug that silently degrades the flow field is worse than one that crashes the solver.
- Treat the result as finished only when every boundary condition holds, every mathematically claimed flow invariant holds, and the integrated forces are consistent with the aerodynamic bounds — not merely when the solver converges without error.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.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. `# chief-engineer`). Output only the headered prompts, no preamble.