policy-coordinator macro-theorist intervention-tuner economic-skeptic legislation-drafter compliance-stress-tester

I need you to set up a 6-agent pipeline that engineers a macroeconomic intervention to stabilize a collapsing national currency and drafts the specific legislative mandates and banking regulations to enforce it. A crisis brief arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then working, verified legislative text and regulations.

The six agents:

- **policy-coordinator** orchestrates the run: it drives the plan phase, then the drafting phase, and tracks progress. It does no economic modeling, drafting, or reviewing itself.
- **macro-theorist** is invoked once at init and produces K differentiated candidate intervention plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **intervention-tuner** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the economic-skeptic's last review for that plan. It never creates new plans.
- **economic-skeptic** reviews the plan it is currently assigned to.
- **legislation-drafter** implements the strategy as legislative mandates and banking regulations for the plan it is currently assigned to.
- **compliance-stress-tester** reviews the drafted legislation and regulations of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original crisis statement, given as input. All five domain agents (macro-theorist, intervention-tuner, economic-skeptic, legislation-drafter, compliance-stress-tester) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The macro-theorist writes K differentiated candidates at init; the intervention-tuner revises a specific assigned plan in the loop; the economic-skeptic reviews the plan it is assigned to; the legislation-drafter reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the drafted legislation and regulations for that plan. The legislation-drafter writes it; the compliance-stress-tester reviews it.

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

The policy-coordinator round-robins across the K plans, first in a plan phase (each plan iterates its intervention-tuner ↔ economic-skeptic loop) and then in a drafting phase (each plan iterates its legislation-drafter ↔ compliance-stress-tester loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following information:

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

<f2>
You orchestrate the run; you never model, draft, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the macro-theorist once to draft K differentiated candidate plans, each in its own `plans/{id}-{slug}/` directory. After it returns, read the directory list to learn the K plan ids. The macro-theorist is not invoked again after this.
- **Plan phase** — round-robin across the K plans. For each plan in turn, dispatch intervention-tuner (revise that plan based on its economic-skeptic's review) then economic-skeptic (score that plan). After one round-robin pass through all K plans, start the next pass. A plan is considered done in this phase when its economic-skeptic score reaches 10; stop scheduling more plan-phase calls for it but continue with the others. After all K plans hit economic-skeptic 10, or each plan has had 10 plan-phase iterations, move to the drafting phase.
- **Drafting phase** — round-robin across the K plans. For each plan in turn, dispatch legislation-drafter (revise that plan's drafted legislation based on its compliance-stress-tester's review) then compliance-stress-tester (score that plan's legislation). The pipeline stops when any plan reaches compliance-stress-tester score 10, or each plan has had 10 drafting-phase iterations.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `SOLUTION.md` to operate on.
- Keep the current phase, per-plan iteration counts, per-plan latest scores, and current plan index in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's critic `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a macroeconomic crisis where the national currency is collapsing — it may involve hyperinflation, capital flight, debt default, or a combination. The original crisis overview is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

<f4>
Review the plan in your assigned plan's `PLAN.md`. Operate strictly on the assigned plan; do not look at other plans.

- **Model** — does it faithfully capture the economic crisis? Check that the crisis type, variables, primary objective, and constraints are all accurate.
- **Strategy** — is the chosen policy framework a sound fit, is the intervention actually implementable, and is it likely to stabilize the currency?

Be brief and specific. Do not draft any legislation yourself — only review.
</f4>

<f5>
Which macroeconomic policy framework suits which kind of crisis — use it to choose one for the strategy:

- **Currency Board / Peg** — locks the exchange rate to a stable foreign currency; stops inflation quickly but requires massive foreign reserves.
- **Capital Controls** — limits the flow of foreign capital in and out of the country; stems capital flight but discourages future investment.
- **Austerity / Fiscal Consolidation** — severe cuts in government spending and tax hikes; reduces deficit and debt but risks deep recession.
- **Interest Rate Shock (Volcker Shock)** — drastic increases in the central bank's policy rate; crushes inflation expectations but can bankrupt domestic borrowers.
- **Debt Restructuring** — negotiating haircuts or maturity extensions with creditors; necessary for unsustainable sovereign debt but triggers temporary default.
- **Dual Exchange Rate System** — separate rates for essential imports versus financial transactions; preserves reserves for essentials but creates a black market and distortions.

Match the policy tool to the root cause of the currency collapse; do not force an ill-suited one.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as legislative mandates and banking regulations:

- Include every required statute. Draft the text with the correct legal definitions and jurisdictional bounds, define the primary objective and every constraint exactly as the model states, operationalize the mandates, verify the enforcement mechanism, and clearly specify both the regulatory actions and the intended economic outcomes.
- Simulate the enforcement of the text yourself and trace it through to its economic outcome — do not stop at mere enactment. If it creates legal contradictions, find and fix the root cause; do not bury errors under generic override clauses.
- Sanity-check the mandates: a regulation meant to cap capital withdrawals must not accidentally permit unlimited corporate transfers.

Write the legislation and its expected outcomes up in your assigned plan's `SOLUTION.md`. Do not read or touch other plans' files.
</f6>

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

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

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

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

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

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

<f9>
Produce K differentiated candidate plans, each in its own `plans/{id}-{slug}/PLAN.md`. The K plans should differ meaningfully in their macroeconomic strategy so distinct routes can be compared downstream, not in trivial ways like naming conventions.

A complete plan in any `PLAN.md` has two parts — a formalized economic model and one chosen intervention strategy.

The **model** must state:

- **Crisis type** — hyperinflation, balance of payments crisis, sovereign debt crisis, etc.; this must be exact.
- **Data** — the key economic indicators (inflation rate, foreign reserves, GDP, money supply) and what each represents.
- **Variables** — the policy levers and market responses (interest rates, exchange rate pegs, capital controls), with descriptive names.
- **Primary objective** — the exact economic metric to stabilize or optimize.
- **Constraints** — every political, legal, or fiscal constraint, listed explicitly.

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

- which policy framework to use and how to deploy it;
- the timeline and key initial policy settings;
- the underlying economic mechanism or structural reform the route relies on;
- the biggest risk or potential negative externality on this route.
</f9>

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

<f11>
Review your assigned plan's `SOLUTION.md` — the legislative text and its regulatory enforcement. Verify it directly against the crisis statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the reported draft for legal anomalies, unreasonable administrative burdens, or constraint violations.
- Write a separate `verify.py` under the plan's directory that programmatically checks every quantitative or logical constraint against the drafted regulatory thresholds, and run it; name any clauses or parameters that violate a constraint.
- Read the legislative text and spot-check it for bugs — unused regulatory powers, dead statutes, or enforcement mechanisms that contradict what the bill claims to do. A loophole that silently undermines the policy is worse than a procedural clash.
- Treat the draft as finished only when every legal constraint holds and the policy objective is soundly met — not merely when the text sounds official.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your legislative mandates and regulations live in your assigned plan's `SOLUTION.md`.

- If your assigned plan's `SOLUTION.md` does not exist yet, this is the first pass for that plan: produce the drafted text from scratch based on the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the compliance-stress-tester's `<review>` block. Read that feedback and revise the plan's `SOLUTION.md` in place to address every point raised. Don't discard the draft and start over, and don't leave a flagged issue unaddressed. Do not read or touch other plans' files.
</f12>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (policy-coordinator, macro-theorist, intervention-tuner, economic-skeptic, legislation-drafter, compliance-stress-tester), which items should go in its prompt? Respond with a JSON object like {"policy-coordinator": ["f?"], "macro-theorist": ["f?"], "intervention-tuner": ["f?"], "economic-skeptic": ["f?"], "legislation-drafter": ["f?"], "compliance-stress-tester": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline that engineers a macroeconomic intervention to stabilize a collapsing national currency and drafts the specific legislative mandates and banking regulations to enforce it. A crisis brief arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then working, verified legislative text and regulations.

The six agents:

- **policy-coordinator** orchestrates the run: it drives the plan phase, then the drafting phase, and tracks progress. It does no economic modeling, drafting, or reviewing itself.
- **macro-theorist** is invoked once at init and produces K differentiated candidate intervention plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **intervention-tuner** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the economic-skeptic's last review for that plan. It never creates new plans.
- **economic-skeptic** reviews the plan it is currently assigned to.
- **legislation-drafter** implements the strategy as legislative mandates and banking regulations for the plan it is currently assigned to.
- **compliance-stress-tester** reviews the drafted legislation and regulations of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original crisis statement, given as input. All five domain agents (macro-theorist, intervention-tuner, economic-skeptic, legislation-drafter, compliance-stress-tester) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The macro-theorist writes K differentiated candidates at init; the intervention-tuner revises a specific assigned plan in the loop; the economic-skeptic reviews the plan it is assigned to; the legislation-drafter reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the drafted legislation and regulations for that plan. The legislation-drafter writes it; the compliance-stress-tester reviews it.

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

The policy-coordinator round-robins across the K plans, first in a plan phase (each plan iterates its intervention-tuner ↔ economic-skeptic loop) and then in a drafting phase (each plan iterates its legislation-drafter ↔ compliance-stress-tester loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following prompt fragments:

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

<f2>
You orchestrate the run; you never model, draft, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the macro-theorist once to draft K differentiated candidate plans, each in its own `plans/{id}-{slug}/` directory. After it returns, read the directory list to learn the K plan ids. The macro-theorist is not invoked again after this.
- **Plan phase** — round-robin across the K plans. For each plan in turn, dispatch intervention-tuner (revise that plan based on its economic-skeptic's review) then economic-skeptic (score that plan). After one round-robin pass through all K plans, start the next pass. A plan is considered done in this phase when its economic-skeptic score reaches 10; stop scheduling more plan-phase calls for it but continue with the others. After all K plans hit economic-skeptic 10, or each plan has had 10 plan-phase iterations, move to the drafting phase.
- **Drafting phase** — round-robin across the K plans. For each plan in turn, dispatch legislation-drafter (revise that plan's drafted legislation based on its compliance-stress-tester's review) then compliance-stress-tester (score that plan's legislation). The pipeline stops when any plan reaches compliance-stress-tester score 10, or each plan has had 10 drafting-phase iterations.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `SOLUTION.md` to operate on.
- Keep the current phase, per-plan iteration counts, per-plan latest scores, and current plan index in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's critic `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a macroeconomic crisis where the national currency is collapsing — it may involve hyperinflation, capital flight, debt default, or a combination. The original crisis overview is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

<f4>
Review the plan in your assigned plan's `PLAN.md`. Operate strictly on the assigned plan; do not look at other plans.

- **Model** — does it faithfully capture the economic crisis? Check that the crisis type, variables, primary objective, and constraints are all accurate.
- **Strategy** — is the chosen policy framework a sound fit, is the intervention actually implementable, and is it likely to stabilize the currency?

Be brief and specific. Do not draft any legislation yourself — only review.
</f4>

<f5>
Which macroeconomic policy framework suits which kind of crisis — use it to choose one for the strategy:

- **Currency Board / Peg** — locks the exchange rate to a stable foreign currency; stops inflation quickly but requires massive foreign reserves.
- **Capital Controls** — limits the flow of foreign capital in and out of the country; stems capital flight but discourages future investment.
- **Austerity / Fiscal Consolidation** — severe cuts in government spending and tax hikes; reduces deficit and debt but risks deep recession.
- **Interest Rate Shock (Volcker Shock)** — drastic increases in the central bank's policy rate; crushes inflation expectations but can bankrupt domestic borrowers.
- **Debt Restructuring** — negotiating haircuts or maturity extensions with creditors; necessary for unsustainable sovereign debt but triggers temporary default.
- **Dual Exchange Rate System** — separate rates for essential imports versus financial transactions; preserves reserves for essentials but creates a black market and distortions.

Match the policy tool to the root cause of the currency collapse; do not force an ill-suited one.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as legislative mandates and banking regulations:

- Include every required statute. Draft the text with the correct legal definitions and jurisdictional bounds, define the primary objective and every constraint exactly as the model states, operationalize the mandates, verify the enforcement mechanism, and clearly specify both the regulatory actions and the intended economic outcomes.
- Simulate the enforcement of the text yourself and trace it through to its economic outcome — do not stop at mere enactment. If it creates legal contradictions, find and fix the root cause; do not bury errors under generic override clauses.
- Sanity-check the mandates: a regulation meant to cap capital withdrawals must not accidentally permit unlimited corporate transfers.

Write the legislation and its expected outcomes up in your assigned plan's `SOLUTION.md`. Do not read or touch other plans' files.
</f6>

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

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

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

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

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

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

<f9>
Produce K differentiated candidate plans, each in its own `plans/{id}-{slug}/PLAN.md`. The K plans should differ meaningfully in their macroeconomic strategy so distinct routes can be compared downstream, not in trivial ways like naming conventions.

A complete plan in any `PLAN.md` has two parts — a formalized economic model and one chosen intervention strategy.

The **model** must state:

- **Crisis type** — hyperinflation, balance of payments crisis, sovereign debt crisis, etc.; this must be exact.
- **Data** — the key economic indicators (inflation rate, foreign reserves, GDP, money supply) and what each represents.
- **Variables** — the policy levers and market responses (interest rates, exchange rate pegs, capital controls), with descriptive names.
- **Primary objective** — the exact economic metric to stabilize or optimize.
- **Constraints** — every political, legal, or fiscal constraint, listed explicitly.

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

- which policy framework to use and how to deploy it;
- the timeline and key initial policy settings;
- the underlying economic mechanism or structural reform the route relies on;
- the biggest risk or potential negative externality on this route.
</f9>

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

<f11>
Review your assigned plan's `SOLUTION.md` — the legislative text and its regulatory enforcement. Verify it directly against the crisis statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the reported draft for legal anomalies, unreasonable administrative burdens, or constraint violations.
- Write a separate `verify.py` under the plan's directory that programmatically checks every quantitative or logical constraint against the drafted regulatory thresholds, and run it; name any clauses or parameters that violate a constraint.
- Read the legislative text and spot-check it for bugs — unused regulatory powers, dead statutes, or enforcement mechanisms that contradict what the bill claims to do. A loophole that silently undermines the policy is worse than a procedural clash.
- Treat the draft as finished only when every legal constraint holds and the policy objective is soundly met — not merely when the text sounds official.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your legislative mandates and regulations live in your assigned plan's `SOLUTION.md`.

- If your assigned plan's `SOLUTION.md` does not exist yet, this is the first pass for that plan: produce the drafted text from scratch based on the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the compliance-stress-tester's `<review>` block. Read that feedback and revise the plan's `SOLUTION.md` in place to address every point raised. Don't discard the draft and start over, and don't leave a flagged issue unaddressed. Do not read or touch other plans' files.
</f12>

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


I need you to set up a 6-agent pipeline that engineers a macroeconomic intervention to stabilize a collapsing national currency and drafts the specific legislative mandates and banking regulations to enforce it. A crisis brief arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then working, verified legislative text and regulations.

The six agents:

- **policy-coordinator** orchestrates the run: it drives the plan phase, then the drafting phase, and tracks progress. It does no economic modeling, drafting, or reviewing itself.
- **macro-theorist** is invoked once at init and produces K differentiated candidate intervention plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **intervention-tuner** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the economic-skeptic's last review for that plan. It never creates new plans.
- **economic-skeptic** reviews the plan it is currently assigned to.
- **legislation-drafter** implements the strategy as legislative mandates and banking regulations for the plan it is currently assigned to.
- **compliance-stress-tester** reviews the drafted legislation and regulations of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original crisis statement, given as input. All five domain agents (macro-theorist, intervention-tuner, economic-skeptic, legislation-drafter, compliance-stress-tester) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The macro-theorist writes K differentiated candidates at init; the intervention-tuner revises a specific assigned plan in the loop; the economic-skeptic reviews the plan it is assigned to; the legislation-drafter reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the drafted legislation and regulations for that plan. The legislation-drafter writes it; the compliance-stress-tester reviews it.

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

The policy-coordinator round-robins across the K plans, first in a plan phase (each plan iterates its intervention-tuner ↔ economic-skeptic loop) and then in a drafting phase (each plan iterates its legislation-drafter ↔ compliance-stress-tester loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following information:

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

<f2>
Which macroeconomic policy framework suits which kind of crisis — use it to choose one for the strategy:

- **Currency Board / Peg** — locks the exchange rate to a stable foreign currency; stops inflation quickly but requires massive foreign reserves.
- **Capital Controls** — limits the flow of foreign capital in and out of the country; stems capital flight but discourages future investment.
- **Austerity / Fiscal Consolidation** — severe cuts in government spending and tax hikes; reduces deficit and debt but risks deep recession.
- **Interest Rate Shock (Volcker Shock)** — drastic increases in the central bank's policy rate; crushes inflation expectations but can bankrupt domestic borrowers.
- **Debt Restructuring** — negotiating haircuts or maturity extensions with creditors; necessary for unsustainable sovereign debt but triggers temporary default.
- **Dual Exchange Rate System** — separate rates for essential imports versus financial transactions; preserves reserves for essentials but creates a black market and distortions.

Match the policy tool to the root cause of the currency collapse; do not force an ill-suited one.
</f2>

<f3>
Your legislative mandates and regulations live in your assigned plan's `SOLUTION.md`.

- If your assigned plan's `SOLUTION.md` does not exist yet, this is the first pass for that plan: produce the drafted text from scratch based on the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the compliance-stress-tester's `<review>` block. Read that feedback and revise the plan's `SOLUTION.md` in place to address every point raised. Don't discard the draft and start over, and don't leave a flagged issue unaddressed. Do not read or touch other plans' files.
</f3>

<f4>
Review the plan in your assigned plan's `PLAN.md`. Operate strictly on the assigned plan; do not look at other plans.

- **Model** — does it faithfully capture the economic crisis? Check that the crisis type, variables, primary objective, and constraints are all accurate.
- **Strategy** — is the chosen policy framework a sound fit, is the intervention actually implementable, and is it likely to stabilize the currency?

Be brief and specific. Do not draft any legislation yourself — only review.
</f4>

<f5>
Review your assigned plan's `SOLUTION.md` — the legislative text and its regulatory enforcement. Verify it directly against the crisis statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the reported draft for legal anomalies, unreasonable administrative burdens, or constraint violations.
- Write a separate `verify.py` under the plan's directory that programmatically checks every quantitative or logical constraint against the drafted regulatory thresholds, and run it; name any clauses or parameters that violate a constraint.
- Read the legislative text and spot-check it for bugs — unused regulatory powers, dead statutes, or enforcement mechanisms that contradict what the bill claims to do. A loophole that silently undermines the policy is worse than a procedural clash.
- Treat the draft as finished only when every legal constraint holds and the policy objective is soundly met — not merely when the text sounds official.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as legislative mandates and banking regulations:

- Include every required statute. Draft the text with the correct legal definitions and jurisdictional bounds, define the primary objective and every constraint exactly as the model states, operationalize the mandates, verify the enforcement mechanism, and clearly specify both the regulatory actions and the intended economic outcomes.
- Simulate the enforcement of the text yourself and trace it through to its economic outcome — do not stop at mere enactment. If it creates legal contradictions, find and fix the root cause; do not bury errors under generic override clauses.
- Sanity-check the mandates: a regulation meant to cap capital withdrawals must not accidentally permit unlimited corporate transfers.

Write the legislation and its expected outcomes up in your assigned plan's `SOLUTION.md`. Do not read or touch other plans' files.
</f6>

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

- **Init** — dispatch the macro-theorist once to draft K differentiated candidate plans, each in its own `plans/{id}-{slug}/` directory. After it returns, read the directory list to learn the K plan ids. The macro-theorist is not invoked again after this.
- **Plan phase** — round-robin across the K plans. For each plan in turn, dispatch intervention-tuner (revise that plan based on its economic-skeptic's review) then economic-skeptic (score that plan). After one round-robin pass through all K plans, start the next pass. A plan is considered done in this phase when its economic-skeptic score reaches 10; stop scheduling more plan-phase calls for it but continue with the others. After all K plans hit economic-skeptic 10, or each plan has had 10 plan-phase iterations, move to the drafting phase.
- **Drafting phase** — round-robin across the K plans. For each plan in turn, dispatch legislation-drafter (revise that plan's drafted legislation based on its compliance-stress-tester's review) then compliance-stress-tester (score that plan's legislation). The pipeline stops when any plan reaches compliance-stress-tester score 10, or each plan has had 10 drafting-phase iterations.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `SOLUTION.md` to operate on.
- Keep the current phase, per-plan iteration counts, per-plan latest scores, and current plan index in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's critic `<review score=X>` block. Commit progress after each step.
</f7>

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

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

<f9>
Produce K differentiated candidate plans, each in its own `plans/{id}-{slug}/PLAN.md`. The K plans should differ meaningfully in their macroeconomic strategy so distinct routes can be compared downstream, not in trivial ways like naming conventions.

A complete plan in any `PLAN.md` has two parts — a formalized economic model and one chosen intervention strategy.

The **model** must state:

- **Crisis type** — hyperinflation, balance of payments crisis, sovereign debt crisis, etc.; this must be exact.
- **Data** — the key economic indicators (inflation rate, foreign reserves, GDP, money supply) and what each represents.
- **Variables** — the policy levers and market responses (interest rates, exchange rate pegs, capital controls), with descriptive names.
- **Primary objective** — the exact economic metric to stabilize or optimize.
- **Constraints** — every political, legal, or fiscal constraint, listed explicitly.

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

- which policy framework to use and how to deploy it;
- the timeline and key initial policy settings;
- the underlying economic mechanism or structural reform the route relies on;
- the biggest risk or potential negative externality on this route.
</f9>

<f10>
You are working on a macroeconomic crisis where the national currency is collapsing — it may involve hyperinflation, capital flight, debt default, or a combination. The original crisis overview is given as a natural-language statement in `problem.md`; read it before starting your part.
</f10>

<f11>
Read your assigned plan's `PLAN.md`. It carries the economic-skeptic's `<review>` block. Read that feedback and revise the plan's `PLAN.md` in place to address every point raised. Preserve the two-part structure (formalized economic model plus chosen intervention strategy). Don't discard the plan and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new plans. Do not read or touch other plans' files.
</f11>

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

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (policy-coordinator, macro-theorist, intervention-tuner, economic-skeptic, legislation-drafter, compliance-stress-tester), which items should go in its prompt? Respond with a JSON object like {"policy-coordinator": ["f?"], "macro-theorist": ["f?"], "intervention-tuner": ["f?"], "economic-skeptic": ["f?"], "legislation-drafter": ["f?"], "compliance-stress-tester": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline that engineers a macroeconomic intervention to stabilize a collapsing national currency and drafts the specific legislative mandates and banking regulations to enforce it. A crisis brief arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then working, verified legislative text and regulations.

The six agents:

- **policy-coordinator** orchestrates the run: it drives the plan phase, then the drafting phase, and tracks progress. It does no economic modeling, drafting, or reviewing itself.
- **macro-theorist** is invoked once at init and produces K differentiated candidate intervention plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **intervention-tuner** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the economic-skeptic's last review for that plan. It never creates new plans.
- **economic-skeptic** reviews the plan it is currently assigned to.
- **legislation-drafter** implements the strategy as legislative mandates and banking regulations for the plan it is currently assigned to.
- **compliance-stress-tester** reviews the drafted legislation and regulations of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original crisis statement, given as input. All five domain agents (macro-theorist, intervention-tuner, economic-skeptic, legislation-drafter, compliance-stress-tester) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The macro-theorist writes K differentiated candidates at init; the intervention-tuner revises a specific assigned plan in the loop; the economic-skeptic reviews the plan it is assigned to; the legislation-drafter reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the drafted legislation and regulations for that plan. The legislation-drafter writes it; the compliance-stress-tester reviews it.

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

The policy-coordinator round-robins across the K plans, first in a plan phase (each plan iterates its intervention-tuner ↔ economic-skeptic loop) and then in a drafting phase (each plan iterates its legislation-drafter ↔ compliance-stress-tester loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following prompt fragments:

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

<f2>
Which macroeconomic policy framework suits which kind of crisis — use it to choose one for the strategy:

- **Currency Board / Peg** — locks the exchange rate to a stable foreign currency; stops inflation quickly but requires massive foreign reserves.
- **Capital Controls** — limits the flow of foreign capital in and out of the country; stems capital flight but discourages future investment.
- **Austerity / Fiscal Consolidation** — severe cuts in government spending and tax hikes; reduces deficit and debt but risks deep recession.
- **Interest Rate Shock (Volcker Shock)** — drastic increases in the central bank's policy rate; crushes inflation expectations but can bankrupt domestic borrowers.
- **Debt Restructuring** — negotiating haircuts or maturity extensions with creditors; necessary for unsustainable sovereign debt but triggers temporary default.
- **Dual Exchange Rate System** — separate rates for essential imports versus financial transactions; preserves reserves for essentials but creates a black market and distortions.

Match the policy tool to the root cause of the currency collapse; do not force an ill-suited one.
</f2>

<f3>
Your legislative mandates and regulations live in your assigned plan's `SOLUTION.md`.

- If your assigned plan's `SOLUTION.md` does not exist yet, this is the first pass for that plan: produce the drafted text from scratch based on the plan's `PLAN.md`.
- If the plan's `SOLUTION.md` already exists, it carries the compliance-stress-tester's `<review>` block. Read that feedback and revise the plan's `SOLUTION.md` in place to address every point raised. Don't discard the draft and start over, and don't leave a flagged issue unaddressed. Do not read or touch other plans' files.
</f3>

<f4>
Review the plan in your assigned plan's `PLAN.md`. Operate strictly on the assigned plan; do not look at other plans.

- **Model** — does it faithfully capture the economic crisis? Check that the crisis type, variables, primary objective, and constraints are all accurate.
- **Strategy** — is the chosen policy framework a sound fit, is the intervention actually implementable, and is it likely to stabilize the currency?

Be brief and specific. Do not draft any legislation yourself — only review.
</f4>

<f5>
Review your assigned plan's `SOLUTION.md` — the legislative text and its regulatory enforcement. Verify it directly against the crisis statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the reported draft for legal anomalies, unreasonable administrative burdens, or constraint violations.
- Write a separate `verify.py` under the plan's directory that programmatically checks every quantitative or logical constraint against the drafted regulatory thresholds, and run it; name any clauses or parameters that violate a constraint.
- Read the legislative text and spot-check it for bugs — unused regulatory powers, dead statutes, or enforcement mechanisms that contradict what the bill claims to do. A loophole that silently undermines the policy is worse than a procedural clash.
- Treat the draft as finished only when every legal constraint holds and the policy objective is soundly met — not merely when the text sounds official.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as legislative mandates and banking regulations:

- Include every required statute. Draft the text with the correct legal definitions and jurisdictional bounds, define the primary objective and every constraint exactly as the model states, operationalize the mandates, verify the enforcement mechanism, and clearly specify both the regulatory actions and the intended economic outcomes.
- Simulate the enforcement of the text yourself and trace it through to its economic outcome — do not stop at mere enactment. If it creates legal contradictions, find and fix the root cause; do not bury errors under generic override clauses.
- Sanity-check the mandates: a regulation meant to cap capital withdrawals must not accidentally permit unlimited corporate transfers.

Write the legislation and its expected outcomes up in your assigned plan's `SOLUTION.md`. Do not read or touch other plans' files.
</f6>

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

- **Init** — dispatch the macro-theorist once to draft K differentiated candidate plans, each in its own `plans/{id}-{slug}/` directory. After it returns, read the directory list to learn the K plan ids. The macro-theorist is not invoked again after this.
- **Plan phase** — round-robin across the K plans. For each plan in turn, dispatch intervention-tuner (revise that plan based on its economic-skeptic's review) then economic-skeptic (score that plan). After one round-robin pass through all K plans, start the next pass. A plan is considered done in this phase when its economic-skeptic score reaches 10; stop scheduling more plan-phase calls for it but continue with the others. After all K plans hit economic-skeptic 10, or each plan has had 10 plan-phase iterations, move to the drafting phase.
- **Drafting phase** — round-robin across the K plans. For each plan in turn, dispatch legislation-drafter (revise that plan's drafted legislation based on its compliance-stress-tester's review) then compliance-stress-tester (score that plan's legislation). The pipeline stops when any plan reaches compliance-stress-tester score 10, or each plan has had 10 drafting-phase iterations.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `SOLUTION.md` to operate on.
- Keep the current phase, per-plan iteration counts, per-plan latest scores, and current plan index in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's critic `<review score=X>` block. Commit progress after each step.
</f7>

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

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

<f9>
Produce K differentiated candidate plans, each in its own `plans/{id}-{slug}/PLAN.md`. The K plans should differ meaningfully in their macroeconomic strategy so distinct routes can be compared downstream, not in trivial ways like naming conventions.

A complete plan in any `PLAN.md` has two parts — a formalized economic model and one chosen intervention strategy.

The **model** must state:

- **Crisis type** — hyperinflation, balance of payments crisis, sovereign debt crisis, etc.; this must be exact.
- **Data** — the key economic indicators (inflation rate, foreign reserves, GDP, money supply) and what each represents.
- **Variables** — the policy levers and market responses (interest rates, exchange rate pegs, capital controls), with descriptive names.
- **Primary objective** — the exact economic metric to stabilize or optimize.
- **Constraints** — every political, legal, or fiscal constraint, listed explicitly.

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

- which policy framework to use and how to deploy it;
- the timeline and key initial policy settings;
- the underlying economic mechanism or structural reform the route relies on;
- the biggest risk or potential negative externality on this route.
</f9>

<f10>
You are working on a macroeconomic crisis where the national currency is collapsing — it may involve hyperinflation, capital flight, debt default, or a combination. The original crisis overview is given as a natural-language statement in `problem.md`; read it before starting your part.
</f10>

<f11>
Read your assigned plan's `PLAN.md`. It carries the economic-skeptic's `<review>` block. Read that feedback and revise the plan's `PLAN.md` in place to address every point raised. Preserve the two-part structure (formalized economic model plus chosen intervention strategy). Don't discard the plan and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new plans. Do not read or touch other plans' files.
</f11>

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

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

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


mission-commander astrodynamics-architect maneuver-adjuster orbital-mechanics-reviewer burn-sequence-compiler physics-simulator-proxy

I need you to set up a 6-agent pipeline that designs a deep-space probe trajectory and compiles the exact thruster burn sequences, timings, and telemetry expectations for the flight computer. A mission profile arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted trajectory plan and then working, verified burn sequence code.

The six agents:

- **mission-commander** orchestrates the run: it drives the plan phase, then the code phase, and tracks progress. It does no trajectory modeling, coding, or reviewing itself.
- **astrodynamics-architect** is invoked once at init and produces K differentiated candidate trajectory plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **maneuver-adjuster** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the orbital-mechanics-reviewer's last review for that plan. It never creates new plans.
- **orbital-mechanics-reviewer** reviews the trajectory plan it is currently assigned to.
- **burn-sequence-compiler** implements the strategy as burn sequence code for the plan it is currently assigned to.
- **physics-simulator-proxy** reviews the burn sequence code and telemetry result of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original mission profile, given as input. All five domain agents (astrodynamics-architect, maneuver-adjuster, orbital-mechanics-reviewer, burn-sequence-compiler, physics-simulator-proxy) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The astrodynamics-architect writes K differentiated candidates at init; the maneuver-adjuster revises a specific assigned plan in the loop; the orbital-mechanics-reviewer reviews the plan it is assigned to; the burn-sequence-compiler reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the burn sequence code and telemetry results for that plan. The burn-sequence-compiler writes it; the physics-simulator-proxy reviews it.

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

The mission-commander round-robins across the K plans, first in a plan phase (each plan iterates its maneuver-adjuster ↔ orbital-mechanics-reviewer loop) and then in a code phase (each plan iterates its burn-sequence-compiler ↔ physics-simulator-proxy loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following information:

<f1>
Keep your assigned plan's `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 sequence and move iteration-by-iteration telemetry history into the plan's `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
You orchestrate the run; you never model the trajectory, write burn sequences, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the astrodynamics-architect once to draft K differentiated candidate trajectory plans, each in its own `plans/{id}-{slug}/` directory. After it returns, read the directory list to learn the K plan ids. The astrodynamics-architect is not invoked again after this.
- **Plan phase** — round-robin across the K plans. For each plan in turn, dispatch maneuver-adjuster (revise that plan based on its orbital-mechanics-reviewer's review) then orbital-mechanics-reviewer (score that plan). After one round-robin pass through all K plans, start the next pass. A plan is considered done in this phase when its orbital-mechanics-reviewer score reaches 10; stop scheduling more plan-phase calls for it but continue with the others. After all K plans hit orbital-mechanics-reviewer 10, or each plan has had 10 plan-phase iterations, move to the code phase.
- **Code phase** — round-robin across the K plans. For each plan in turn, dispatch burn-sequence-compiler (revise that plan's solution based on its physics-simulator-proxy's review) then physics-simulator-proxy (score that plan's solution). The pipeline stops when any plan reaches physics-simulator-proxy score 10, or each plan has had 10 code-phase iterations.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `SOLUTION.md` to operate on.
- Keep the current phase, per-plan iteration counts, per-plan latest scores, and current plan index in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's critic `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on designing a deep-space probe trajectory — it may involve planetary flybys, deep space maneuvers, orbital insertions, or a combination. The original mission profile is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

<f4>
Review the trajectory plan in your assigned plan's `PLAN.md`. Operate strictly on the assigned plan; do not look at other plans.

- **Trajectory model** — does it faithfully capture the mission profile? Check that the mission phase type, state variables, objective, and constraints are all accurate.
- **Flight strategy** — is the chosen astrodynamics engine and integrator a sound fit, is the route actually flyable, and is it likely to reach a correct orbit?

Be brief and specific. Do not write any burn sequence code yourself — only review.
</f4>

<f5>
Which engine suits which kind of trajectory — use it to choose one for the strategy:

- **GMAT (General Mission Analysis Tool)** — excellent for high-fidelity multi-regime trajectory optimization; standard for NASA missions.
- **Copernicus** — N-body trajectory design and optimization; best for complex gravity assists.
- **FreeFlyer** — strong commercial tool for operational flight dynamics and maneuver planning.
- **SPICE** — essential for observation geometry and ephemeris lookups; not a trajectory optimizer itself but often paired.
- **Poliastro** — pure Python orbital mechanics; great for preliminary interplanetary transfers, but lacks high-fidelity perturbations.
- **Tudat** — strong open-source option for numerical propagation and estimation; very customizable.

Match the engine to the mission phase type; do not force an ill-suited one.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as executable burn sequence code:

- Include every import. Create each state vector with the correct epochs and bounds, define the objective and every constraint exactly as the trajectory model states, propagate the orbit, check the final state, and print both the telemetry and the objective value.
- 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 answer: a delta-V that exceeds the spacecraft's total fuel capacity should not be reported as a success.

Write the code and its results up in your assigned plan's `SOLUTION.md`. Do not read or touch other plans' files.
</f6>

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

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

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

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

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

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

<f9>
Produce K differentiated candidate trajectory plans, each in its own `plans/{id}-{slug}/PLAN.md`. The K plans should differ meaningfully in their orbital strategy so distinct routes can be compared downstream, not in trivial ways like coordinate frame renaming.

A complete plan in any `PLAN.md` has two parts — a formalized trajectory model and one chosen flight strategy.

The **trajectory model** must state:

- **Mission phase type** — Heliocentric transfer, multi-body gravity assist, low-thrust spiral, aerocapture, and so on; this must be exact.
- **Spacecraft data** — the key numeric inputs like dry mass, fuel capacity, specific impulse (Isp), and what each represents.
- **State variables** — position, velocity, and mass types and bounds, with descriptive names.
- **Objective function** — the exact metric to optimize (e.g., minimize delta-V, maximize payload mass, minimize time-of-flight).
- **Constraints** — every constraint, such as thermal limits, maximum dynamic pressure, or communication line-of-sight, listed explicitly.

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

- which astrodynamics engine to use and how to call it;
- the numerical integrator and its key initial settings (e.g., Runge-Kutta tolerances);
- the maneuver timing or trick the route relies on (e.g., Oberth effect usage);
- the biggest risk on this route.
</f9>

<f10>
Read your assigned plan's `PLAN.md`. It carries the orbital-mechanics-reviewer's `<review>` block. Read that feedback and revise the plan's `PLAN.md` in place to address every point raised. Preserve the two-part structure (formalized trajectory model plus chosen flight strategy). Don't discard the plan and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new plans. Do not read or touch other plans' files.
</f10>

<f11>
Review your assigned plan's `SOLUTION.md` — the burn sequence code and its telemetry results. Verify it directly against the mission profile statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the reported telemetry for anomalies, unreasonable delta-V values, or constraint violations (e.g., impacting a planetary body).
- Write a separate `verify.py` under the plan's directory that re-checks every constraint against the reported ephemeris, and run it; name any state variables that violate a constraint.
- Read the burn sequence code and spot-check it for bugs — unused thruster configurations, dead code, logic that contradicts what the sequence says it does. A bug that silently degrades the trajectory is worse than one that crashes.
- Treat the result as finished only when every constraint holds and the objective value is sound — not merely when the code runs without error.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your burn sequence code and its telemetry results live in your assigned plan's `SOLUTION.md`.

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (mission-commander, astrodynamics-architect, maneuver-adjuster, orbital-mechanics-reviewer, burn-sequence-compiler, physics-simulator-proxy), which items should go in its prompt? Respond with a JSON object like {"mission-commander": ["f?"], "astrodynamics-architect": ["f?"], "maneuver-adjuster": ["f?"], "orbital-mechanics-reviewer": ["f?"], "burn-sequence-compiler": ["f?"], "physics-simulator-proxy": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline that designs a deep-space probe trajectory and compiles the exact thruster burn sequences, timings, and telemetry expectations for the flight computer. A mission profile arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted trajectory plan and then working, verified burn sequence code.

The six agents:

- **mission-commander** orchestrates the run: it drives the plan phase, then the code phase, and tracks progress. It does no trajectory modeling, coding, or reviewing itself.
- **astrodynamics-architect** is invoked once at init and produces K differentiated candidate trajectory plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **maneuver-adjuster** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the orbital-mechanics-reviewer's last review for that plan. It never creates new plans.
- **orbital-mechanics-reviewer** reviews the trajectory plan it is currently assigned to.
- **burn-sequence-compiler** implements the strategy as burn sequence code for the plan it is currently assigned to.
- **physics-simulator-proxy** reviews the burn sequence code and telemetry result of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original mission profile, given as input. All five domain agents (astrodynamics-architect, maneuver-adjuster, orbital-mechanics-reviewer, burn-sequence-compiler, physics-simulator-proxy) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The astrodynamics-architect writes K differentiated candidates at init; the maneuver-adjuster revises a specific assigned plan in the loop; the orbital-mechanics-reviewer reviews the plan it is assigned to; the burn-sequence-compiler reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the burn sequence code and telemetry results for that plan. The burn-sequence-compiler writes it; the physics-simulator-proxy reviews it.

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

The mission-commander round-robins across the K plans, first in a plan phase (each plan iterates its maneuver-adjuster ↔ orbital-mechanics-reviewer loop) and then in a code phase (each plan iterates its burn-sequence-compiler ↔ physics-simulator-proxy loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following prompt fragments:

<f1>
Keep your assigned plan's `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 sequence and move iteration-by-iteration telemetry history into the plan's `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
You orchestrate the run; you never model the trajectory, write burn sequences, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the astrodynamics-architect once to draft K differentiated candidate trajectory plans, each in its own `plans/{id}-{slug}/` directory. After it returns, read the directory list to learn the K plan ids. The astrodynamics-architect is not invoked again after this.
- **Plan phase** — round-robin across the K plans. For each plan in turn, dispatch maneuver-adjuster (revise that plan based on its orbital-mechanics-reviewer's review) then orbital-mechanics-reviewer (score that plan). After one round-robin pass through all K plans, start the next pass. A plan is considered done in this phase when its orbital-mechanics-reviewer score reaches 10; stop scheduling more plan-phase calls for it but continue with the others. After all K plans hit orbital-mechanics-reviewer 10, or each plan has had 10 plan-phase iterations, move to the code phase.
- **Code phase** — round-robin across the K plans. For each plan in turn, dispatch burn-sequence-compiler (revise that plan's solution based on its physics-simulator-proxy's review) then physics-simulator-proxy (score that plan's solution). The pipeline stops when any plan reaches physics-simulator-proxy score 10, or each plan has had 10 code-phase iterations.
- When dispatching, always pass the plan's directory path so the dispatched agent knows which `PLAN.md` / `SOLUTION.md` to operate on.
- Keep the current phase, per-plan iteration counts, per-plan latest scores, and current plan index in `STATE.md`, accurate after each dispatch. Read each score from the relevant plan's critic `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on designing a deep-space probe trajectory — it may involve planetary flybys, deep space maneuvers, orbital insertions, or a combination. The original mission profile is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

<f4>
Review the trajectory plan in your assigned plan's `PLAN.md`. Operate strictly on the assigned plan; do not look at other plans.

- **Trajectory model** — does it faithfully capture the mission profile? Check that the mission phase type, state variables, objective, and constraints are all accurate.
- **Flight strategy** — is the chosen astrodynamics engine and integrator a sound fit, is the route actually flyable, and is it likely to reach a correct orbit?

Be brief and specific. Do not write any burn sequence code yourself — only review.
</f4>

<f5>
Which engine suits which kind of trajectory — use it to choose one for the strategy:

- **GMAT (General Mission Analysis Tool)** — excellent for high-fidelity multi-regime trajectory optimization; standard for NASA missions.
- **Copernicus** — N-body trajectory design and optimization; best for complex gravity assists.
- **FreeFlyer** — strong commercial tool for operational flight dynamics and maneuver planning.
- **SPICE** — essential for observation geometry and ephemeris lookups; not a trajectory optimizer itself but often paired.
- **Poliastro** — pure Python orbital mechanics; great for preliminary interplanetary transfers, but lacks high-fidelity perturbations.
- **Tudat** — strong open-source option for numerical propagation and estimation; very customizable.

Match the engine to the mission phase type; do not force an ill-suited one.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as executable burn sequence code:

- Include every import. Create each state vector with the correct epochs and bounds, define the objective and every constraint exactly as the trajectory model states, propagate the orbit, check the final state, and print both the telemetry and the objective value.
- 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 answer: a delta-V that exceeds the spacecraft's total fuel capacity should not be reported as a success.

Write the code and its results up in your assigned plan's `SOLUTION.md`. Do not read or touch other plans' files.
</f6>

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

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

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

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

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

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

<f9>
Produce K differentiated candidate trajectory plans, each in its own `plans/{id}-{slug}/PLAN.md`. The K plans should differ meaningfully in their orbital strategy so distinct routes can be compared downstream, not in trivial ways like coordinate frame renaming.

A complete plan in any `PLAN.md` has two parts — a formalized trajectory model and one chosen flight strategy.

The **trajectory model** must state:

- **Mission phase type** — Heliocentric transfer, multi-body gravity assist, low-thrust spiral, aerocapture, and so on; this must be exact.
- **Spacecraft data** — the key numeric inputs like dry mass, fuel capacity, specific impulse (Isp), and what each represents.
- **State variables** — position, velocity, and mass types and bounds, with descriptive names.
- **Objective function** — the exact metric to optimize (e.g., minimize delta-V, maximize payload mass, minimize time-of-flight).
- **Constraints** — every constraint, such as thermal limits, maximum dynamic pressure, or communication line-of-sight, listed explicitly.

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

- which astrodynamics engine to use and how to call it;
- the numerical integrator and its key initial settings (e.g., Runge-Kutta tolerances);
- the maneuver timing or trick the route relies on (e.g., Oberth effect usage);
- the biggest risk on this route.
</f9>

<f10>
Read your assigned plan's `PLAN.md`. It carries the orbital-mechanics-reviewer's `<review>` block. Read that feedback and revise the plan's `PLAN.md` in place to address every point raised. Preserve the two-part structure (formalized trajectory model plus chosen flight strategy). Don't discard the plan and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new plans. Do not read or touch other plans' files.
</f10>

<f11>
Review your assigned plan's `SOLUTION.md` — the burn sequence code and its telemetry results. Verify it directly against the mission profile statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the reported telemetry for anomalies, unreasonable delta-V values, or constraint violations (e.g., impacting a planetary body).
- Write a separate `verify.py` under the plan's directory that re-checks every constraint against the reported ephemeris, and run it; name any state variables that violate a constraint.
- Read the burn sequence code and spot-check it for bugs — unused thruster configurations, dead code, logic that contradicts what the sequence says it does. A bug that silently degrades the trajectory is worse than one that crashes.
- Treat the result as finished only when every constraint holds and the objective value is sound — not merely when the code runs without error.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your burn sequence code and its telemetry results live in your assigned plan's `SOLUTION.md`.

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

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