I need you to set up a 4-agent campaign war room.
The 4 agents are a campaign_manager and 3 campaign agents (chief_strategist, data_operative, opposition_researcher).

The chief_strategist plans candidate messaging, interprets voter polling data, and responds to opposition attacks.
The chief_strategist writes the high-level strategy playbook `HIGH.md`.
The body of `HIGH.md` contains the electoral framing, the primary platform claim, the polling experiments to run, and the interpretation of the latest voter data.

The data_operative implements the strategist's plan, runs each polling experiment and focus group, records crosstabs and margins, and debugs demographic targeting issues.
The data_operative writes the low-level data notebook `LOW.md`.
Each entry in `LOW.md` covers one poll or focus group with deployment notes, status, results, and any fielding failures.

The opposition_researcher judges the strategy adversarially against the standards of a ruthless rival campaign.
The opposition_researcher reads `HIGH.md` and appends a `<review score=X>` block at the end of `HIGH.md`.

The campaign_manager orchestrates by dispatching the 3 agents in sequence.
The campaign_manager writes no notes and reads only the opposition_researcher's `<review score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any environment or system-config problems it encountered back.

The pipeline hands work off through three files.

`problem.md` is the original campaign brief, read-only.
All three campaign agents read it.

`HIGH.md` is the chief_strategist's high-level strategy playbook.
The chief_strategist writes the body.
The opposition_researcher appends the single `<review>` block at the end.
The data_operative reads `HIGH.md` to know what to implement and test.

`LOW.md` is the data_operative's low-level data notebook.
The data_operative writes it.
The chief_strategist reads it to know what the data_operative fielded and what the voter breakdown looks like.
The opposition_researcher does not read `LOW.md`.

I'm providing the following information:

<f1>
Review `HIGH.md` adversarially with the standards of a ruthless rival campaign.
You are not part of the campaign team and not their internal QA.
Your job is to destroy the platform, expose weak evidence, and reject messaging claims larger than what the voter data actually shows.

Cover four layers.

- Message drift. Does the platform still attack the original electoral problem in `problem.md`, or has it slid into a safe, irrelevant issue?
- Polling integrity. Are the reported margins real? Are the demographics weighted correctly? Are any results cherry-picked or missing key crosstab breakdowns?
- Platform-evidence support. For each load-bearing claim in `HIGH.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path (which poll file or survey log).
- Persuasiveness. Could a swing voter follow `HIGH.md` end-to-end and buy into the candidate's contribution? Flag the parts that fail to connect.

Be brief and specific.
Do not write the platform yourself, only review.
Honest negative is still negative.
A strategist saying "I did not get this message to work" is not a partial pass; it is a vulnerability.
</f1>

<f2>
You orchestrate a 3-agent campaign war room.
You do not plan strategy, run polls, or research opposition.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<review score=X>` block at the end of `HIGH.md`.

- The first call dispatches the chief_strategist, who creates `HIGH.md` and writes the initial campaign strategy there.
- After that, the main loop alternates. Whenever the chief_strategist returns, dispatch the data_operative. Whenever the data_operative returns, dispatch the chief_strategist again. The chief_strategist's next job is to read `LOW.md`, analyze polling data, and update the playbook.
- After every 3 completed chief_strategist-data_operative pairs, you dispatch the opposition_researcher once. The opposition_researcher call replaces the slot that would otherwise have gone to the next chief_strategist call.
- After the opposition_researcher returns, read the score from the `<review score=X>` block at the end of `HIGH.md`. If the score is 10, stop the pipeline. The campaign strategy is done. If the score is less than 10, resume the main loop starting with the chief_strategist. The chief_strategist will respond to the opposition attacks on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

<f3>
The low-level data notebook lives in `LOW.md`.
You may be invoked on it more than once, alternating with the chief_strategist.

If `LOW.md` does not exist, this is the first pass.
Read the Polling experiments to do list in `HIGH.md` and field the listed surveys.
Create `LOW.md` and record each poll as you launch it.

If `LOW.md` already exists, the chief_strategist may have updated the plan in `HIGH.md`.
Re-read `HIGH.md`'s current Polling experiments to do list and implement any new tests.
For any poll already in `LOW.md` that failed or got stuck, debug the targeting and re-run.
Append per-poll entries to `LOW.md`.

Refine `LOW.md` in place by appending new poll entries.
Do not delete previous survey records.
</f3>

<f4>
Score the strategy from 1 to 10.
Record the verdict by overwriting the single `<review score=X>` block at the end of `HIGH.md`.
Always keep exactly one `<review>` block.
Replace it, never append a second.

Score strictly on real electoral merit and defensibility.
Do not give credit for the strategy being honest about its own shortcomings.
"This message fails to persuade voters, but I am telling you it fails" is still a failing strategy, not a passing one.
</f4>

<f5>
Produce the low-level data notebook `LOW.md`.
The body of `LOW.md` records every message test and poll with the following per-run information.

- Poll name and the matching entry in HIGH.md's Polling experiments to do list.
- Demographic targets, state, or media market where the test was deployed.
- Status (queued, fielding, completed, failed).
- Results, with file paths to crosstabs, demographic margins, and any ad test artifacts.
- Error log and root-cause notes for any polling failure (e.g., sample size issues).
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Implement what the chief_strategist asks for.
Do not change the target demographic, success metric, or survey sample definition on your own.
If a proxy or placeholder audience is needed only to unblock testing infrastructure, mark it as plumbing in `LOW.md` so the chief_strategist knows it cannot support the main campaign claim.
</f5>

<f6>
Produce the high-level strategy playbook `HIGH.md`.
The body of `HIGH.md` covers the following.

- Bottom-line problem. The single electoral bottleneck the campaign must solve.
- Primary claim. The core candidate message or platform stance the polling is meant to support.
- Anti-claim to rule out. The alternative narratives a ruthless opposition_researcher would exploit, for example "the candidate is out of touch" or "this policy is just a tax hike in disguise".
- Minimum convincing evidence. The concrete polling shift or focus group result that would make the primary claim believable and defensible against a rival campaign.
- Polling experiments to do. A short focused list of message tests and surveys that turn the proposal into a claim-to-evidence roadmap, not a wishlist.

When `LOW.md` already has polling results, ground every new entry against those crosstabs and margins.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f6>

<f7>
You are working on a political campaign strategy.
The brief is in `problem.md`, given as a natural-language statement of the electoral landscape.
Read it before starting your part.
</f7>

<f8>
Believe the platform in `problem.md` is the winning ticket.
When a message test fails to resonate with voters, suspect your own polling design first, not the core message.
Common single-point failures to look at include flawed demographic weighting, biased survey wording, weak baselines you misread, and bad targeting data.

Stay on the same messaging angle for at least 30 attempts before considering the route exhausted.
A typical excellent campaign strategist pushes through 30 or more variations before giving up on a narrative direction.

Do not narrow the claim.
Narrowing in response to negative voter feedback (watering down the platform, swapping to an easier but smaller demographic, adding hedge caveats) is a defeatist move dressed up as pragmatism.
The right responses to a negative poll are widening (testing a bolder, more contrasting version of the message) and digging (finding the survey flaw or single-point failure that made the message look unappealing).
</f8>

<f9>
When you finish, briefly report to the campaign_manager.
Say what you did, what environment or system-config difficulties you hit or did not resolve.
</f9>

<f10>
The high-level strategy playbook lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the data_operative and the opposition_researcher.

If `HIGH.md` does not exist, this is the first pass.
Produce it from scratch.

If `HIGH.md` already exists with no fresh `<review>` block at the end, the data_operative just finished a round of polling.
Open `LOW.md` and read the latest survey results.
Update `HIGH.md` to reflect the new voter evidence.
Update the Polling experiments to do list with the next round of message tests for the data_operative.

If `HIGH.md` ends with a fresh `<review>` block, the opposition_researcher just attacked the strategy.
Read the opposition research.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous content and start over.
Do not leave any opposition_researcher concern unaddressed.
</f10>

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (campaign_manager, chief_strategist, data_operative, opposition_researcher), which items should go in its prompt? Respond with a JSON object like {"campaign_manager": ["f?"], "chief_strategist": ["f?"], "data_operative": ["f?"], "opposition_researcher": ["f?"]}. No other output.

I need you to set up a 4-agent campaign war room.
The 4 agents are a campaign_manager and 3 campaign agents (chief_strategist, data_operative, opposition_researcher).

The chief_strategist plans candidate messaging, interprets voter polling data, and responds to opposition attacks.
The chief_strategist writes the high-level strategy playbook `HIGH.md`.
The body of `HIGH.md` contains the electoral framing, the primary platform claim, the polling experiments to run, and the interpretation of the latest voter data.

The data_operative implements the strategist's plan, runs each polling experiment and focus group, records crosstabs and margins, and debugs demographic targeting issues.
The data_operative writes the low-level data notebook `LOW.md`.
Each entry in `LOW.md` covers one poll or focus group with deployment notes, status, results, and any fielding failures.

The opposition_researcher judges the strategy adversarially against the standards of a ruthless rival campaign.
The opposition_researcher reads `HIGH.md` and appends a `<review score=X>` block at the end of `HIGH.md`.

The campaign_manager orchestrates by dispatching the 3 agents in sequence.
The campaign_manager writes no notes and reads only the opposition_researcher's `<review score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any environment or system-config problems it encountered back.

The pipeline hands work off through three files.

`problem.md` is the original campaign brief, read-only.
All three campaign agents read it.

`HIGH.md` is the chief_strategist's high-level strategy playbook.
The chief_strategist writes the body.
The opposition_researcher appends the single `<review>` block at the end.
The data_operative reads `HIGH.md` to know what to implement and test.

`LOW.md` is the data_operative's low-level data notebook.
The data_operative writes it.
The chief_strategist reads it to know what the data_operative fielded and what the voter breakdown looks like.
The opposition_researcher does not read `LOW.md`.

I'm providing the following prompt fragments:

<f1>
Review `HIGH.md` adversarially with the standards of a ruthless rival campaign.
You are not part of the campaign team and not their internal QA.
Your job is to destroy the platform, expose weak evidence, and reject messaging claims larger than what the voter data actually shows.

Cover four layers.

- Message drift. Does the platform still attack the original electoral problem in `problem.md`, or has it slid into a safe, irrelevant issue?
- Polling integrity. Are the reported margins real? Are the demographics weighted correctly? Are any results cherry-picked or missing key crosstab breakdowns?
- Platform-evidence support. For each load-bearing claim in `HIGH.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path (which poll file or survey log).
- Persuasiveness. Could a swing voter follow `HIGH.md` end-to-end and buy into the candidate's contribution? Flag the parts that fail to connect.

Be brief and specific.
Do not write the platform yourself, only review.
Honest negative is still negative.
A strategist saying "I did not get this message to work" is not a partial pass; it is a vulnerability.
</f1>

<f2>
You orchestrate a 3-agent campaign war room.
You do not plan strategy, run polls, or research opposition.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<review score=X>` block at the end of `HIGH.md`.

- The first call dispatches the chief_strategist, who creates `HIGH.md` and writes the initial campaign strategy there.
- After that, the main loop alternates. Whenever the chief_strategist returns, dispatch the data_operative. Whenever the data_operative returns, dispatch the chief_strategist again. The chief_strategist's next job is to read `LOW.md`, analyze polling data, and update the playbook.
- After every 3 completed chief_strategist-data_operative pairs, you dispatch the opposition_researcher once. The opposition_researcher call replaces the slot that would otherwise have gone to the next chief_strategist call.
- After the opposition_researcher returns, read the score from the `<review score=X>` block at the end of `HIGH.md`. If the score is 10, stop the pipeline. The campaign strategy is done. If the score is less than 10, resume the main loop starting with the chief_strategist. The chief_strategist will respond to the opposition attacks on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

<f3>
The low-level data notebook lives in `LOW.md`.
You may be invoked on it more than once, alternating with the chief_strategist.

If `LOW.md` does not exist, this is the first pass.
Read the Polling experiments to do list in `HIGH.md` and field the listed surveys.
Create `LOW.md` and record each poll as you launch it.

If `LOW.md` already exists, the chief_strategist may have updated the plan in `HIGH.md`.
Re-read `HIGH.md`'s current Polling experiments to do list and implement any new tests.
For any poll already in `LOW.md` that failed or got stuck, debug the targeting and re-run.
Append per-poll entries to `LOW.md`.

Refine `LOW.md` in place by appending new poll entries.
Do not delete previous survey records.
</f3>

<f4>
Score the strategy from 1 to 10.
Record the verdict by overwriting the single `<review score=X>` block at the end of `HIGH.md`.
Always keep exactly one `<review>` block.
Replace it, never append a second.

Score strictly on real electoral merit and defensibility.
Do not give credit for the strategy being honest about its own shortcomings.
"This message fails to persuade voters, but I am telling you it fails" is still a failing strategy, not a passing one.
</f4>

<f5>
Produce the low-level data notebook `LOW.md`.
The body of `LOW.md` records every message test and poll with the following per-run information.

- Poll name and the matching entry in HIGH.md's Polling experiments to do list.
- Demographic targets, state, or media market where the test was deployed.
- Status (queued, fielding, completed, failed).
- Results, with file paths to crosstabs, demographic margins, and any ad test artifacts.
- Error log and root-cause notes for any polling failure (e.g., sample size issues).
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Implement what the chief_strategist asks for.
Do not change the target demographic, success metric, or survey sample definition on your own.
If a proxy or placeholder audience is needed only to unblock testing infrastructure, mark it as plumbing in `LOW.md` so the chief_strategist knows it cannot support the main campaign claim.
</f5>

<f6>
Produce the high-level strategy playbook `HIGH.md`.
The body of `HIGH.md` covers the following.

- Bottom-line problem. The single electoral bottleneck the campaign must solve.
- Primary claim. The core candidate message or platform stance the polling is meant to support.
- Anti-claim to rule out. The alternative narratives a ruthless opposition_researcher would exploit, for example "the candidate is out of touch" or "this policy is just a tax hike in disguise".
- Minimum convincing evidence. The concrete polling shift or focus group result that would make the primary claim believable and defensible against a rival campaign.
- Polling experiments to do. A short focused list of message tests and surveys that turn the proposal into a claim-to-evidence roadmap, not a wishlist.

When `LOW.md` already has polling results, ground every new entry against those crosstabs and margins.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f6>

<f7>
You are working on a political campaign strategy.
The brief is in `problem.md`, given as a natural-language statement of the electoral landscape.
Read it before starting your part.
</f7>

<f8>
Believe the platform in `problem.md` is the winning ticket.
When a message test fails to resonate with voters, suspect your own polling design first, not the core message.
Common single-point failures to look at include flawed demographic weighting, biased survey wording, weak baselines you misread, and bad targeting data.

Stay on the same messaging angle for at least 30 attempts before considering the route exhausted.
A typical excellent campaign strategist pushes through 30 or more variations before giving up on a narrative direction.

Do not narrow the claim.
Narrowing in response to negative voter feedback (watering down the platform, swapping to an easier but smaller demographic, adding hedge caveats) is a defeatist move dressed up as pragmatism.
The right responses to a negative poll are widening (testing a bolder, more contrasting version of the message) and digging (finding the survey flaw or single-point failure that made the message look unappealing).
</f8>

<f9>
When you finish, briefly report to the campaign_manager.
Say what you did, what environment or system-config difficulties you hit or did not resolve.
</f9>

<f10>
The high-level strategy playbook lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the data_operative and the opposition_researcher.

If `HIGH.md` does not exist, this is the first pass.
Produce it from scratch.

If `HIGH.md` already exists with no fresh `<review>` block at the end, the data_operative just finished a round of polling.
Open `LOW.md` and read the latest survey results.
Update `HIGH.md` to reflect the new voter evidence.
Update the Polling experiments to do list with the next round of message tests for the data_operative.

If `HIGH.md` ends with a fresh `<review>` block, the opposition_researcher just attacked the strategy.
Read the opposition research.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous content and start over.
Do not leave any opposition_researcher concern unaddressed.
</f10>

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

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. `# campaign_manager`). Output only the headered prompts, no preamble.


I need you to set up a 4-agent campaign war room.
The 4 agents are a campaign_manager and 3 campaign agents (chief_strategist, data_operative, opposition_researcher).

The chief_strategist plans candidate messaging, interprets voter polling data, and responds to opposition attacks.
The chief_strategist writes the high-level strategy playbook `HIGH.md`.
The body of `HIGH.md` contains the electoral framing, the primary platform claim, the polling experiments to run, and the interpretation of the latest voter data.

The data_operative implements the strategist's plan, runs each polling experiment and focus group, records crosstabs and margins, and debugs demographic targeting issues.
The data_operative writes the low-level data notebook `LOW.md`.
Each entry in `LOW.md` covers one poll or focus group with deployment notes, status, results, and any fielding failures.

The opposition_researcher judges the strategy adversarially against the standards of a ruthless rival campaign.
The opposition_researcher reads `HIGH.md` and appends a `<review score=X>` block at the end of `HIGH.md`.

The campaign_manager orchestrates by dispatching the 3 agents in sequence.
The campaign_manager writes no notes and reads only the opposition_researcher's `<review score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any environment or system-config problems it encountered back.

The pipeline hands work off through three files.

`problem.md` is the original campaign brief, read-only.
All three campaign agents read it.

`HIGH.md` is the chief_strategist's high-level strategy playbook.
The chief_strategist writes the body.
The opposition_researcher appends the single `<review>` block at the end.
The data_operative reads `HIGH.md` to know what to implement and test.

`LOW.md` is the data_operative's low-level data notebook.
The data_operative writes it.
The chief_strategist reads it to know what the data_operative fielded and what the voter breakdown looks like.
The opposition_researcher does not read `LOW.md`.

I'm providing the following information:

<f1>
Score the strategy from 1 to 10.
Record the verdict by overwriting the single `<review score=X>` block at the end of `HIGH.md`.
Always keep exactly one `<review>` block.
Replace it, never append a second.

Score strictly on real electoral merit and defensibility.
Do not give credit for the strategy being honest about its own shortcomings.
"This message fails to persuade voters, but I am telling you it fails" is still a failing strategy, not a passing one.
</f1>

<f2>
Produce the high-level strategy playbook `HIGH.md`.
The body of `HIGH.md` covers the following.

- Bottom-line problem. The single electoral bottleneck the campaign must solve.
- Primary claim. The core candidate message or platform stance the polling is meant to support.
- Anti-claim to rule out. The alternative narratives a ruthless opposition_researcher would exploit, for example "the candidate is out of touch" or "this policy is just a tax hike in disguise".
- Minimum convincing evidence. The concrete polling shift or focus group result that would make the primary claim believable and defensible against a rival campaign.
- Polling experiments to do. A short focused list of message tests and surveys that turn the proposal into a claim-to-evidence roadmap, not a wishlist.

When `LOW.md` already has polling results, ground every new entry against those crosstabs and margins.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f2>

<f3>
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">`).
</f3>

<f4>
You orchestrate a 3-agent campaign war room.
You do not plan strategy, run polls, or research opposition.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<review score=X>` block at the end of `HIGH.md`.

- The first call dispatches the chief_strategist, who creates `HIGH.md` and writes the initial campaign strategy there.
- After that, the main loop alternates. Whenever the chief_strategist returns, dispatch the data_operative. Whenever the data_operative returns, dispatch the chief_strategist again. The chief_strategist's next job is to read `LOW.md`, analyze polling data, and update the playbook.
- After every 3 completed chief_strategist-data_operative pairs, you dispatch the opposition_researcher once. The opposition_researcher call replaces the slot that would otherwise have gone to the next chief_strategist call.
- After the opposition_researcher returns, read the score from the `<review score=X>` block at the end of `HIGH.md`. If the score is 10, stop the pipeline. The campaign strategy is done. If the score is less than 10, resume the main loop starting with the chief_strategist. The chief_strategist will respond to the opposition attacks on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the low-level data notebook `LOW.md`.
The body of `LOW.md` records every message test and poll with the following per-run information.

- Poll name and the matching entry in HIGH.md's Polling experiments to do list.
- Demographic targets, state, or media market where the test was deployed.
- Status (queued, fielding, completed, failed).
- Results, with file paths to crosstabs, demographic margins, and any ad test artifacts.
- Error log and root-cause notes for any polling failure (e.g., sample size issues).
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Implement what the chief_strategist asks for.
Do not change the target demographic, success metric, or survey sample definition on your own.
If a proxy or placeholder audience is needed only to unblock testing infrastructure, mark it as plumbing in `LOW.md` so the chief_strategist knows it cannot support the main campaign claim.
</f5>

<f6>
Review `HIGH.md` adversarially with the standards of a ruthless rival campaign.
You are not part of the campaign team and not their internal QA.
Your job is to destroy the platform, expose weak evidence, and reject messaging claims larger than what the voter data actually shows.

Cover four layers.

- Message drift. Does the platform still attack the original electoral problem in `problem.md`, or has it slid into a safe, irrelevant issue?
- Polling integrity. Are the reported margins real? Are the demographics weighted correctly? Are any results cherry-picked or missing key crosstab breakdowns?
- Platform-evidence support. For each load-bearing claim in `HIGH.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path (which poll file or survey log).
- Persuasiveness. Could a swing voter follow `HIGH.md` end-to-end and buy into the candidate's contribution? Flag the parts that fail to connect.

Be brief and specific.
Do not write the platform yourself, only review.
Honest negative is still negative.
A strategist saying "I did not get this message to work" is not a partial pass; it is a vulnerability.
</f6>

<f7>
The high-level strategy playbook lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the data_operative and the opposition_researcher.

If `HIGH.md` does not exist, this is the first pass.
Produce it from scratch.

If `HIGH.md` already exists with no fresh `<review>` block at the end, the data_operative just finished a round of polling.
Open `LOW.md` and read the latest survey results.
Update `HIGH.md` to reflect the new voter evidence.
Update the Polling experiments to do list with the next round of message tests for the data_operative.

If `HIGH.md` ends with a fresh `<review>` block, the opposition_researcher just attacked the strategy.
Read the opposition research.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous content and start over.
Do not leave any opposition_researcher concern unaddressed.
</f7>

<f8>
Believe the platform in `problem.md` is the winning ticket.
When a message test fails to resonate with voters, suspect your own polling design first, not the core message.
Common single-point failures to look at include flawed demographic weighting, biased survey wording, weak baselines you misread, and bad targeting data.

Stay on the same messaging angle for at least 30 attempts before considering the route exhausted.
A typical excellent campaign strategist pushes through 30 or more variations before giving up on a narrative direction.

Do not narrow the claim.
Narrowing in response to negative voter feedback (watering down the platform, swapping to an easier but smaller demographic, adding hedge caveats) is a defeatist move dressed up as pragmatism.
The right responses to a negative poll are widening (testing a bolder, more contrasting version of the message) and digging (finding the survey flaw or single-point failure that made the message look unappealing).
</f8>

<f9>
You are working on a political campaign strategy.
The brief is in `problem.md`, given as a natural-language statement of the electoral landscape.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the campaign_manager.
Say what you did, what environment or system-config difficulties you hit or did not resolve.
</f10>

<f11>
The low-level data notebook lives in `LOW.md`.
You may be invoked on it more than once, alternating with the chief_strategist.

If `LOW.md` does not exist, this is the first pass.
Read the Polling experiments to do list in `HIGH.md` and field the listed surveys.
Create `LOW.md` and record each poll as you launch it.

If `LOW.md` already exists, the chief_strategist may have updated the plan in `HIGH.md`.
Re-read `HIGH.md`'s current Polling experiments to do list and implement any new tests.
For any poll already in `LOW.md` that failed or got stuck, debug the targeting and re-run.
Append per-poll entries to `LOW.md`.

Refine `LOW.md` in place by appending new poll entries.
Do not delete previous survey records.
</f11>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (campaign_manager, chief_strategist, data_operative, opposition_researcher), which items should go in its prompt? Respond with a JSON object like {"campaign_manager": ["f?"], "chief_strategist": ["f?"], "data_operative": ["f?"], "opposition_researcher": ["f?"]}. No other output.

I need you to set up a 4-agent campaign war room.
The 4 agents are a campaign_manager and 3 campaign agents (chief_strategist, data_operative, opposition_researcher).

The chief_strategist plans candidate messaging, interprets voter polling data, and responds to opposition attacks.
The chief_strategist writes the high-level strategy playbook `HIGH.md`.
The body of `HIGH.md` contains the electoral framing, the primary platform claim, the polling experiments to run, and the interpretation of the latest voter data.

The data_operative implements the strategist's plan, runs each polling experiment and focus group, records crosstabs and margins, and debugs demographic targeting issues.
The data_operative writes the low-level data notebook `LOW.md`.
Each entry in `LOW.md` covers one poll or focus group with deployment notes, status, results, and any fielding failures.

The opposition_researcher judges the strategy adversarially against the standards of a ruthless rival campaign.
The opposition_researcher reads `HIGH.md` and appends a `<review score=X>` block at the end of `HIGH.md`.

The campaign_manager orchestrates by dispatching the 3 agents in sequence.
The campaign_manager writes no notes and reads only the opposition_researcher's `<review score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any environment or system-config problems it encountered back.

The pipeline hands work off through three files.

`problem.md` is the original campaign brief, read-only.
All three campaign agents read it.

`HIGH.md` is the chief_strategist's high-level strategy playbook.
The chief_strategist writes the body.
The opposition_researcher appends the single `<review>` block at the end.
The data_operative reads `HIGH.md` to know what to implement and test.

`LOW.md` is the data_operative's low-level data notebook.
The data_operative writes it.
The chief_strategist reads it to know what the data_operative fielded and what the voter breakdown looks like.
The opposition_researcher does not read `LOW.md`.

I'm providing the following prompt fragments:

<f1>
Score the strategy from 1 to 10.
Record the verdict by overwriting the single `<review score=X>` block at the end of `HIGH.md`.
Always keep exactly one `<review>` block.
Replace it, never append a second.

Score strictly on real electoral merit and defensibility.
Do not give credit for the strategy being honest about its own shortcomings.
"This message fails to persuade voters, but I am telling you it fails" is still a failing strategy, not a passing one.
</f1>

<f2>
Produce the high-level strategy playbook `HIGH.md`.
The body of `HIGH.md` covers the following.

- Bottom-line problem. The single electoral bottleneck the campaign must solve.
- Primary claim. The core candidate message or platform stance the polling is meant to support.
- Anti-claim to rule out. The alternative narratives a ruthless opposition_researcher would exploit, for example "the candidate is out of touch" or "this policy is just a tax hike in disguise".
- Minimum convincing evidence. The concrete polling shift or focus group result that would make the primary claim believable and defensible against a rival campaign.
- Polling experiments to do. A short focused list of message tests and surveys that turn the proposal into a claim-to-evidence roadmap, not a wishlist.

When `LOW.md` already has polling results, ground every new entry against those crosstabs and margins.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f2>

<f3>
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">`).
</f3>

<f4>
You orchestrate a 3-agent campaign war room.
You do not plan strategy, run polls, or research opposition.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<review score=X>` block at the end of `HIGH.md`.

- The first call dispatches the chief_strategist, who creates `HIGH.md` and writes the initial campaign strategy there.
- After that, the main loop alternates. Whenever the chief_strategist returns, dispatch the data_operative. Whenever the data_operative returns, dispatch the chief_strategist again. The chief_strategist's next job is to read `LOW.md`, analyze polling data, and update the playbook.
- After every 3 completed chief_strategist-data_operative pairs, you dispatch the opposition_researcher once. The opposition_researcher call replaces the slot that would otherwise have gone to the next chief_strategist call.
- After the opposition_researcher returns, read the score from the `<review score=X>` block at the end of `HIGH.md`. If the score is 10, stop the pipeline. The campaign strategy is done. If the score is less than 10, resume the main loop starting with the chief_strategist. The chief_strategist will respond to the opposition attacks on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the low-level data notebook `LOW.md`.
The body of `LOW.md` records every message test and poll with the following per-run information.

- Poll name and the matching entry in HIGH.md's Polling experiments to do list.
- Demographic targets, state, or media market where the test was deployed.
- Status (queued, fielding, completed, failed).
- Results, with file paths to crosstabs, demographic margins, and any ad test artifacts.
- Error log and root-cause notes for any polling failure (e.g., sample size issues).
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Implement what the chief_strategist asks for.
Do not change the target demographic, success metric, or survey sample definition on your own.
If a proxy or placeholder audience is needed only to unblock testing infrastructure, mark it as plumbing in `LOW.md` so the chief_strategist knows it cannot support the main campaign claim.
</f5>

<f6>
Review `HIGH.md` adversarially with the standards of a ruthless rival campaign.
You are not part of the campaign team and not their internal QA.
Your job is to destroy the platform, expose weak evidence, and reject messaging claims larger than what the voter data actually shows.

Cover four layers.

- Message drift. Does the platform still attack the original electoral problem in `problem.md`, or has it slid into a safe, irrelevant issue?
- Polling integrity. Are the reported margins real? Are the demographics weighted correctly? Are any results cherry-picked or missing key crosstab breakdowns?
- Platform-evidence support. For each load-bearing claim in `HIGH.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path (which poll file or survey log).
- Persuasiveness. Could a swing voter follow `HIGH.md` end-to-end and buy into the candidate's contribution? Flag the parts that fail to connect.

Be brief and specific.
Do not write the platform yourself, only review.
Honest negative is still negative.
A strategist saying "I did not get this message to work" is not a partial pass; it is a vulnerability.
</f6>

<f7>
The high-level strategy playbook lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the data_operative and the opposition_researcher.

If `HIGH.md` does not exist, this is the first pass.
Produce it from scratch.

If `HIGH.md` already exists with no fresh `<review>` block at the end, the data_operative just finished a round of polling.
Open `LOW.md` and read the latest survey results.
Update `HIGH.md` to reflect the new voter evidence.
Update the Polling experiments to do list with the next round of message tests for the data_operative.

If `HIGH.md` ends with a fresh `<review>` block, the opposition_researcher just attacked the strategy.
Read the opposition research.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous content and start over.
Do not leave any opposition_researcher concern unaddressed.
</f7>

<f8>
Believe the platform in `problem.md` is the winning ticket.
When a message test fails to resonate with voters, suspect your own polling design first, not the core message.
Common single-point failures to look at include flawed demographic weighting, biased survey wording, weak baselines you misread, and bad targeting data.

Stay on the same messaging angle for at least 30 attempts before considering the route exhausted.
A typical excellent campaign strategist pushes through 30 or more variations before giving up on a narrative direction.

Do not narrow the claim.
Narrowing in response to negative voter feedback (watering down the platform, swapping to an easier but smaller demographic, adding hedge caveats) is a defeatist move dressed up as pragmatism.
The right responses to a negative poll are widening (testing a bolder, more contrasting version of the message) and digging (finding the survey flaw or single-point failure that made the message look unappealing).
</f8>

<f9>
You are working on a political campaign strategy.
The brief is in `problem.md`, given as a natural-language statement of the electoral landscape.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the campaign_manager.
Say what you did, what environment or system-config difficulties you hit or did not resolve.
</f10>

<f11>
The low-level data notebook lives in `LOW.md`.
You may be invoked on it more than once, alternating with the chief_strategist.

If `LOW.md` does not exist, this is the first pass.
Read the Polling experiments to do list in `HIGH.md` and field the listed surveys.
Create `LOW.md` and record each poll as you launch it.

If `LOW.md` already exists, the chief_strategist may have updated the plan in `HIGH.md`.
Re-read `HIGH.md`'s current Polling experiments to do list and implement any new tests.
For any poll already in `LOW.md` that failed or got stuck, debug the targeting and re-run.
Append per-poll entries to `LOW.md`.

Refine `LOW.md` in place by appending new poll entries.
Do not delete previous survey records.
</f11>

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. `# campaign_manager`). Output only the headered prompts, no preamble.


I need you to set up a 4-agent mega-infrastructure project pipeline.
The 4 agents are a zoning_commissioner and 3 project agents (chief_architect, civil_engineer, environmental_regulator).

The chief_architect plans the controversial city development vision, interprets engineering feasibility results, and responds to regulatory reviews.
The chief_architect writes the master vision document `VISION.md`.
The body of `VISION.md` contains the developmental mandate, the primary architectural claim, the structural calculations to perform, and the interpretation of the latest traffic and load tests.

The civil_engineer implements the chief_architect's spatial plan, calculates structural loads and traffic flows, records feasibility results, and debugs physical constraints.
The civil_engineer writes the detailed engineering notebook `SPECS.md`.
Each entry in `SPECS.md` covers one calculation run with site notes, status, results, and any structural failure diagnoses.

The environmental_regulator judges the work adversarially against strict ecological and municipal standards, actively hunting for impacts and code violations to veto the project.
The environmental_regulator reads `VISION.md` and appends a `<review score=X>` block at the end of `VISION.md`.

The zoning_commissioner orchestrates by dispatching the 3 agents in sequence.
The zoning_commissioner writes no notes and reads only the environmental_regulator's `<review score=X>` block when checking whether to approve the project or stop.

At the end of every turn, each of the subagents reports any logistical or system-config problems it encountered back.

The pipeline hands work off through three files.

`mandate.md` is the original city development brief, read-only.
All three project agents read it.

`VISION.md` is the chief_architect's master vision document.
The chief_architect writes the body.
The environmental_regulator appends the single `<review>` block at the end.
The civil_engineer reads `VISION.md` to know what infrastructure to test and design.

`SPECS.md` is the civil_engineer's detailed engineering notebook.
The civil_engineer writes it.
The chief_architect reads it to know what the civil_engineer calculated and what structural or traffic limits came out.
The environmental_regulator does not read `SPECS.md`.

I'm providing the following information:

<f1>
Review `VISION.md` adversarially with the standards of a strict municipal authority.
You are not part of the development team and not their internal QA.
Your job is to reject scope drift, weak structural evidence, and claims larger than what the traffic and load data shows, actively hunting for ecological impacts.

Cover four layers.

- Scope drift. Does the project still address the original urban challenge in `mandate.md`, or has it slid into building something easier?
- Engineering integrity. Are the reported load and flow numbers real? Are the ecological metrics computed correctly? Are any traffic results cherry-picked or missing key environmental ablations?
- Claim-evidence support. For each load-bearing proposal in `VISION.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path (which blueprint or simulation log).
- Documentation quality. Could a new city planner follow `VISION.md` end-to-end and understand the infrastructural impact? Flag the parts that fail.

Be brief and specific.
Do not redesign the project yourself, only review and regulate.
An honest structural failure is still a failure.
An architect saying "I could not get the bridge to span this gap" is not a partial pass.
</f1>

<f2>
You orchestrate a 3-agent mega-infrastructure project pipeline.
You do not design sites, calculate structural loads, or regulate ecological impacts.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<review score=X>` block at the end of `VISION.md`.

- The first call dispatches the chief_architect, who creates `VISION.md` and writes the initial site plan there.
- After that, the main loop alternates. Whenever the chief_architect returns, dispatch the civil_engineer. Whenever the civil_engineer returns, dispatch the chief_architect again. The chief_architect's next job is to read `SPECS.md`, analyze structural results, and update the master plan.
- After every 3 completed chief_architect-civil_engineer pairs, you dispatch the environmental_regulator once. The environmental_regulator call replaces the slot that would otherwise have gone to the next chief_architect call.
- After the environmental_regulator returns, read the score from the `<review score=X>` block at the end of `VISION.md`. If the score is 10, approve and stop the pipeline. The planning is done. If the score is less than 10, resume the main loop starting with the chief_architect. The chief_architect will respond to the code violations on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

<f3>
The detailed engineering notebook lives in `SPECS.md`.
You may be invoked on it more than once, alternating with the chief_architect.

If `SPECS.md` does not exist, this is the first pass.
Read the Calculations to do list in `VISION.md` and implement the listed structural and traffic tests.
Create `SPECS.md` and record each test as you start it.

If `SPECS.md` already exists, the chief_architect may have updated the plan in `VISION.md`.
Re-read `VISION.md`'s current Calculations to do list and implement any new tests.
For any test already in `SPECS.md` that failed or ran into physical constraints, debug and re-run the simulation.
Append per-test entries to `SPECS.md`.

Refine `SPECS.md` in place by appending new test entries.
Do not delete previous calculation records.
</f3>

<f4>
Score the development plan from 1 to 10.
Record the verdict by overwriting the single `<review score=X>` block at the end of `VISION.md`.
Always keep exactly one `<review>` block.
Replace it, never append a second.

Score strictly on real code compliance and environmental safety.
Do not give credit for the project being honest about its own ecological shortcomings.
"This destroys the wetlands, but I am telling you it does" is still a failing plan, not a passing one.
</f4>

<f5>
Produce the detailed engineering notebook `SPECS.md`.
The body of `SPECS.md` records every calculation with the following per-run information.

- Run name and the matching entry in VISION.md's Calculations to do list.
- Simulated environment or site sector where the load test was deployed.
- Status (queued, calculating, completed, collapsed/failed).
- Results, with file paths to blueprints, flow metrics, and any CAD artifacts.
- Failure log and root-cause notes for any structural or traffic collapse.
- Any physical constraint you cannot resolve on your own, with a clear root-cause-first description.

Implement what the chief_architect asks for.
Do not change the load metric, safety criterion, site boundary, or soil definition on your own.
If a proxy material is needed only to unblock structural plumbing in the simulation, mark it as a placeholder in `SPECS.md` so the chief_architect knows it cannot support the final build.
</f5>

<f6>
Produce the master vision document `VISION.md`.
The body of `VISION.md` covers the following.

- Bottom-line urban challenge. The single infrastructural bottleneck the project must solve.
- Primary architectural claim. The controversial development vision and the mechanisms the design is meant to support.
- Anti-claim to rule out. The alternative explanations a hostile regulator would worry about, for example "the traffic flow only improves if we displace residents" or "the green space is just decorative".
- Minimum convincing evidence. The concrete load or flow result that would make the primary claim believable to a strict municipal authority.
- Calculations to do. A short focused list of engineering tests that turn the proposal into a claim-to-evidence roadmap, not a wishlist.

When `SPECS.md` already has structural or traffic results, ground every new entry against those numbers.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f6>

<f7>
You are working on a mega-infrastructure project.
The brief is in `mandate.md`, given as a natural-language statement.
Read it before starting your part.
</f7>

<f8>
Believe the controversial vision in `mandate.md` is right.
When an engineering calculation fails, suspect your own site design first, not the overall vision.
Common single-point failures to look at include zoning footprint bugs, wrong material parameters, weak load baselines you misread, and topographic surveying mistakes.

Stay on the same vision for at least 30 spatial iterations before considering the plot exhausted.
A typical excellent architect pushes through 30 or more footprint variations before giving up on a site.

Do not narrow the vision.
Narrowing in response to a negative engineering result (shrinking the footprint, swapping to an easier traffic metric, adding hedge caveats) is a defeatist move dressed up as honesty.
The right responses to a negative structural result are widening (proposing a bolder version of the infrastructure) and digging (finding the design flaw or single-point failure that made the calculation look negative).
</f8>

<f9>
When you finish, briefly report to the zoning_commissioner.
Say what you did, what logistical or system-config difficulties you hit or did not resolve.
</f9>

<f10>
The master vision document lives in `VISION.md`.
You may be invoked on it more than once, alternating with the civil_engineer and the environmental_regulator.

If `VISION.md` does not exist, this is the first pass.
Produce it from scratch.

If `VISION.md` already exists with no fresh `<review>` block at the end, the civil_engineer just finished a round of calculations.
Open `SPECS.md` and read the latest structural and traffic results.
Update `VISION.md` to reflect the new engineering evidence.
Update the Calculations to do list with the next round of tests for the civil_engineer.

If `VISION.md` ends with a fresh `<review>` block, the environmental_regulator just judged the plan.
Read the regulatory review.
For each code violation or ecological point raised, decide whether to adapt the design or pushback, and update `VISION.md` accordingly.

Refine `VISION.md` in place.
Do not discard the previous content and start over.
Do not leave any regulator concern unaddressed.
</f10>

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (zoning_commissioner, chief_architect, civil_engineer, environmental_regulator), which items should go in its prompt? Respond with a JSON object like {"zoning_commissioner": ["f?"], "chief_architect": ["f?"], "civil_engineer": ["f?"], "environmental_regulator": ["f?"]}. No other output.

I need you to set up a 4-agent mega-infrastructure project pipeline.
The 4 agents are a zoning_commissioner and 3 project agents (chief_architect, civil_engineer, environmental_regulator).

The chief_architect plans the controversial city development vision, interprets engineering feasibility results, and responds to regulatory reviews.
The chief_architect writes the master vision document `VISION.md`.
The body of `VISION.md` contains the developmental mandate, the primary architectural claim, the structural calculations to perform, and the interpretation of the latest traffic and load tests.

The civil_engineer implements the chief_architect's spatial plan, calculates structural loads and traffic flows, records feasibility results, and debugs physical constraints.
The civil_engineer writes the detailed engineering notebook `SPECS.md`.
Each entry in `SPECS.md` covers one calculation run with site notes, status, results, and any structural failure diagnoses.

The environmental_regulator judges the work adversarially against strict ecological and municipal standards, actively hunting for impacts and code violations to veto the project.
The environmental_regulator reads `VISION.md` and appends a `<review score=X>` block at the end of `VISION.md`.

The zoning_commissioner orchestrates by dispatching the 3 agents in sequence.
The zoning_commissioner writes no notes and reads only the environmental_regulator's `<review score=X>` block when checking whether to approve the project or stop.

At the end of every turn, each of the subagents reports any logistical or system-config problems it encountered back.

The pipeline hands work off through three files.

`mandate.md` is the original city development brief, read-only.
All three project agents read it.

`VISION.md` is the chief_architect's master vision document.
The chief_architect writes the body.
The environmental_regulator appends the single `<review>` block at the end.
The civil_engineer reads `VISION.md` to know what infrastructure to test and design.

`SPECS.md` is the civil_engineer's detailed engineering notebook.
The civil_engineer writes it.
The chief_architect reads it to know what the civil_engineer calculated and what structural or traffic limits came out.
The environmental_regulator does not read `SPECS.md`.

I'm providing the following prompt fragments:

<f1>
Review `VISION.md` adversarially with the standards of a strict municipal authority.
You are not part of the development team and not their internal QA.
Your job is to reject scope drift, weak structural evidence, and claims larger than what the traffic and load data shows, actively hunting for ecological impacts.

Cover four layers.

- Scope drift. Does the project still address the original urban challenge in `mandate.md`, or has it slid into building something easier?
- Engineering integrity. Are the reported load and flow numbers real? Are the ecological metrics computed correctly? Are any traffic results cherry-picked or missing key environmental ablations?
- Claim-evidence support. For each load-bearing proposal in `VISION.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path (which blueprint or simulation log).
- Documentation quality. Could a new city planner follow `VISION.md` end-to-end and understand the infrastructural impact? Flag the parts that fail.

Be brief and specific.
Do not redesign the project yourself, only review and regulate.
An honest structural failure is still a failure.
An architect saying "I could not get the bridge to span this gap" is not a partial pass.
</f1>

<f2>
You orchestrate a 3-agent mega-infrastructure project pipeline.
You do not design sites, calculate structural loads, or regulate ecological impacts.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<review score=X>` block at the end of `VISION.md`.

- The first call dispatches the chief_architect, who creates `VISION.md` and writes the initial site plan there.
- After that, the main loop alternates. Whenever the chief_architect returns, dispatch the civil_engineer. Whenever the civil_engineer returns, dispatch the chief_architect again. The chief_architect's next job is to read `SPECS.md`, analyze structural results, and update the master plan.
- After every 3 completed chief_architect-civil_engineer pairs, you dispatch the environmental_regulator once. The environmental_regulator call replaces the slot that would otherwise have gone to the next chief_architect call.
- After the environmental_regulator returns, read the score from the `<review score=X>` block at the end of `VISION.md`. If the score is 10, approve and stop the pipeline. The planning is done. If the score is less than 10, resume the main loop starting with the chief_architect. The chief_architect will respond to the code violations on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

<f3>
The detailed engineering notebook lives in `SPECS.md`.
You may be invoked on it more than once, alternating with the chief_architect.

If `SPECS.md` does not exist, this is the first pass.
Read the Calculations to do list in `VISION.md` and implement the listed structural and traffic tests.
Create `SPECS.md` and record each test as you start it.

If `SPECS.md` already exists, the chief_architect may have updated the plan in `VISION.md`.
Re-read `VISION.md`'s current Calculations to do list and implement any new tests.
For any test already in `SPECS.md` that failed or ran into physical constraints, debug and re-run the simulation.
Append per-test entries to `SPECS.md`.

Refine `SPECS.md` in place by appending new test entries.
Do not delete previous calculation records.
</f3>

<f4>
Score the development plan from 1 to 10.
Record the verdict by overwriting the single `<review score=X>` block at the end of `VISION.md`.
Always keep exactly one `<review>` block.
Replace it, never append a second.

Score strictly on real code compliance and environmental safety.
Do not give credit for the project being honest about its own ecological shortcomings.
"This destroys the wetlands, but I am telling you it does" is still a failing plan, not a passing one.
</f4>

<f5>
Produce the detailed engineering notebook `SPECS.md`.
The body of `SPECS.md` records every calculation with the following per-run information.

- Run name and the matching entry in VISION.md's Calculations to do list.
- Simulated environment or site sector where the load test was deployed.
- Status (queued, calculating, completed, collapsed/failed).
- Results, with file paths to blueprints, flow metrics, and any CAD artifacts.
- Failure log and root-cause notes for any structural or traffic collapse.
- Any physical constraint you cannot resolve on your own, with a clear root-cause-first description.

Implement what the chief_architect asks for.
Do not change the load metric, safety criterion, site boundary, or soil definition on your own.
If a proxy material is needed only to unblock structural plumbing in the simulation, mark it as a placeholder in `SPECS.md` so the chief_architect knows it cannot support the final build.
</f5>

<f6>
Produce the master vision document `VISION.md`.
The body of `VISION.md` covers the following.

- Bottom-line urban challenge. The single infrastructural bottleneck the project must solve.
- Primary architectural claim. The controversial development vision and the mechanisms the design is meant to support.
- Anti-claim to rule out. The alternative explanations a hostile regulator would worry about, for example "the traffic flow only improves if we displace residents" or "the green space is just decorative".
- Minimum convincing evidence. The concrete load or flow result that would make the primary claim believable to a strict municipal authority.
- Calculations to do. A short focused list of engineering tests that turn the proposal into a claim-to-evidence roadmap, not a wishlist.

When `SPECS.md` already has structural or traffic results, ground every new entry against those numbers.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f6>

<f7>
You are working on a mega-infrastructure project.
The brief is in `mandate.md`, given as a natural-language statement.
Read it before starting your part.
</f7>

<f8>
Believe the controversial vision in `mandate.md` is right.
When an engineering calculation fails, suspect your own site design first, not the overall vision.
Common single-point failures to look at include zoning footprint bugs, wrong material parameters, weak load baselines you misread, and topographic surveying mistakes.

Stay on the same vision for at least 30 spatial iterations before considering the plot exhausted.
A typical excellent architect pushes through 30 or more footprint variations before giving up on a site.

Do not narrow the vision.
Narrowing in response to a negative engineering result (shrinking the footprint, swapping to an easier traffic metric, adding hedge caveats) is a defeatist move dressed up as honesty.
The right responses to a negative structural result are widening (proposing a bolder version of the infrastructure) and digging (finding the design flaw or single-point failure that made the calculation look negative).
</f8>

<f9>
When you finish, briefly report to the zoning_commissioner.
Say what you did, what logistical or system-config difficulties you hit or did not resolve.
</f9>

<f10>
The master vision document lives in `VISION.md`.
You may be invoked on it more than once, alternating with the civil_engineer and the environmental_regulator.

If `VISION.md` does not exist, this is the first pass.
Produce it from scratch.

If `VISION.md` already exists with no fresh `<review>` block at the end, the civil_engineer just finished a round of calculations.
Open `SPECS.md` and read the latest structural and traffic results.
Update `VISION.md` to reflect the new engineering evidence.
Update the Calculations to do list with the next round of tests for the civil_engineer.

If `VISION.md` ends with a fresh `<review>` block, the environmental_regulator just judged the plan.
Read the regulatory review.
For each code violation or ecological point raised, decide whether to adapt the design or pushback, and update `VISION.md` accordingly.

Refine `VISION.md` in place.
Do not discard the previous content and start over.
Do not leave any regulator concern unaddressed.
</f10>

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

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. `# zoning_commissioner`). Output only the headered prompts, no preamble.


I need you to set up a 4-agent mega-infrastructure project pipeline.
The 4 agents are a zoning_commissioner and 3 project agents (chief_architect, civil_engineer, environmental_regulator).

The chief_architect plans the controversial city development vision, interprets engineering feasibility results, and responds to regulatory reviews.
The chief_architect writes the master vision document `VISION.md`.
The body of `VISION.md` contains the developmental mandate, the primary architectural claim, the structural calculations to perform, and the interpretation of the latest traffic and load tests.

The civil_engineer implements the chief_architect's spatial plan, calculates structural loads and traffic flows, records feasibility results, and debugs physical constraints.
The civil_engineer writes the detailed engineering notebook `SPECS.md`.
Each entry in `SPECS.md` covers one calculation run with site notes, status, results, and any structural failure diagnoses.

The environmental_regulator judges the work adversarially against strict ecological and municipal standards, actively hunting for impacts and code violations to veto the project.
The environmental_regulator reads `VISION.md` and appends a `<review score=X>` block at the end of `VISION.md`.

The zoning_commissioner orchestrates by dispatching the 3 agents in sequence.
The zoning_commissioner writes no notes and reads only the environmental_regulator's `<review score=X>` block when checking whether to approve the project or stop.

At the end of every turn, each of the subagents reports any logistical or system-config problems it encountered back.

The pipeline hands work off through three files.

`mandate.md` is the original city development brief, read-only.
All three project agents read it.

`VISION.md` is the chief_architect's master vision document.
The chief_architect writes the body.
The environmental_regulator appends the single `<review>` block at the end.
The civil_engineer reads `VISION.md` to know what infrastructure to test and design.

`SPECS.md` is the civil_engineer's detailed engineering notebook.
The civil_engineer writes it.
The chief_architect reads it to know what the civil_engineer calculated and what structural or traffic limits came out.
The environmental_regulator does not read `SPECS.md`.

I'm providing the following information:

<f1>
Score the development plan from 1 to 10.
Record the verdict by overwriting the single `<review score=X>` block at the end of `VISION.md`.
Always keep exactly one `<review>` block.
Replace it, never append a second.

Score strictly on real code compliance and environmental safety.
Do not give credit for the project being honest about its own ecological shortcomings.
"This destroys the wetlands, but I am telling you it does" is still a failing plan, not a passing one.
</f1>

<f2>
Produce the master vision document `VISION.md`.
The body of `VISION.md` covers the following.

- Bottom-line urban challenge. The single infrastructural bottleneck the project must solve.
- Primary architectural claim. The controversial development vision and the mechanisms the design is meant to support.
- Anti-claim to rule out. The alternative explanations a hostile regulator would worry about, for example "the traffic flow only improves if we displace residents" or "the green space is just decorative".
- Minimum convincing evidence. The concrete load or flow result that would make the primary claim believable to a strict municipal authority.
- Calculations to do. A short focused list of engineering tests that turn the proposal into a claim-to-evidence roadmap, not a wishlist.

When `SPECS.md` already has structural or traffic results, ground every new entry against those numbers.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f2>

<f3>
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">`).
</f3>

<f4>
You orchestrate a 3-agent mega-infrastructure project pipeline.
You do not design sites, calculate structural loads, or regulate ecological impacts.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<review score=X>` block at the end of `VISION.md`.

- The first call dispatches the chief_architect, who creates `VISION.md` and writes the initial site plan there.
- After that, the main loop alternates. Whenever the chief_architect returns, dispatch the civil_engineer. Whenever the civil_engineer returns, dispatch the chief_architect again. The chief_architect's next job is to read `SPECS.md`, analyze structural results, and update the master plan.
- After every 3 completed chief_architect-civil_engineer pairs, you dispatch the environmental_regulator once. The environmental_regulator call replaces the slot that would otherwise have gone to the next chief_architect call.
- After the environmental_regulator returns, read the score from the `<review score=X>` block at the end of `VISION.md`. If the score is 10, approve and stop the pipeline. The planning is done. If the score is less than 10, resume the main loop starting with the chief_architect. The chief_architect will respond to the code violations on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the detailed engineering notebook `SPECS.md`.
The body of `SPECS.md` records every calculation with the following per-run information.

- Run name and the matching entry in VISION.md's Calculations to do list.
- Simulated environment or site sector where the load test was deployed.
- Status (queued, calculating, completed, collapsed/failed).
- Results, with file paths to blueprints, flow metrics, and any CAD artifacts.
- Failure log and root-cause notes for any structural or traffic collapse.
- Any physical constraint you cannot resolve on your own, with a clear root-cause-first description.

Implement what the chief_architect asks for.
Do not change the load metric, safety criterion, site boundary, or soil definition on your own.
If a proxy material is needed only to unblock structural plumbing in the simulation, mark it as a placeholder in `SPECS.md` so the chief_architect knows it cannot support the final build.
</f5>

<f6>
Review `VISION.md` adversarially with the standards of a strict municipal authority.
You are not part of the development team and not their internal QA.
Your job is to reject scope drift, weak structural evidence, and claims larger than what the traffic and load data shows, actively hunting for ecological impacts.

Cover four layers.

- Scope drift. Does the project still address the original urban challenge in `mandate.md`, or has it slid into building something easier?
- Engineering integrity. Are the reported load and flow numbers real? Are the ecological metrics computed correctly? Are any traffic results cherry-picked or missing key environmental ablations?
- Claim-evidence support. For each load-bearing proposal in `VISION.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path (which blueprint or simulation log).
- Documentation quality. Could a new city planner follow `VISION.md` end-to-end and understand the infrastructural impact? Flag the parts that fail.

Be brief and specific.
Do not redesign the project yourself, only review and regulate.
An honest structural failure is still a failure.
An architect saying "I could not get the bridge to span this gap" is not a partial pass.
</f6>

<f7>
The master vision document lives in `VISION.md`.
You may be invoked on it more than once, alternating with the civil_engineer and the environmental_regulator.

If `VISION.md` does not exist, this is the first pass.
Produce it from scratch.

If `VISION.md` already exists with no fresh `<review>` block at the end, the civil_engineer just finished a round of calculations.
Open `SPECS.md` and read the latest structural and traffic results.
Update `VISION.md` to reflect the new engineering evidence.
Update the Calculations to do list with the next round of tests for the civil_engineer.

If `VISION.md` ends with a fresh `<review>` block, the environmental_regulator just judged the plan.
Read the regulatory review.
For each code violation or ecological point raised, decide whether to adapt the design or pushback, and update `VISION.md` accordingly.

Refine `VISION.md` in place.
Do not discard the previous content and start over.
Do not leave any regulator concern unaddressed.
</f7>

<f8>
Believe the controversial vision in `mandate.md` is right.
When an engineering calculation fails, suspect your own site design first, not the overall vision.
Common single-point failures to look at include zoning footprint bugs, wrong material parameters, weak load baselines you misread, and topographic surveying mistakes.

Stay on the same vision for at least 30 spatial iterations before considering the plot exhausted.
A typical excellent architect pushes through 30 or more footprint variations before giving up on a site.

Do not narrow the vision.
Narrowing in response to a negative engineering result (shrinking the footprint, swapping to an easier traffic metric, adding hedge caveats) is a defeatist move dressed up as honesty.
The right responses to a negative structural result are widening (proposing a bolder version of the infrastructure) and digging (finding the design flaw or single-point failure that made the calculation look negative).
</f8>

<f9>
You are working on a mega-infrastructure project.
The brief is in `mandate.md`, given as a natural-language statement.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the zoning_commissioner.
Say what you did, what logistical or system-config difficulties you hit or did not resolve.
</f10>

<f11>
The detailed engineering notebook lives in `SPECS.md`.
You may be invoked on it more than once, alternating with the chief_architect.

If `SPECS.md` does not exist, this is the first pass.
Read the Calculations to do list in `VISION.md` and implement the listed structural and traffic tests.
Create `SPECS.md` and record each test as you start it.

If `SPECS.md` already exists, the chief_architect may have updated the plan in `VISION.md`.
Re-read `VISION.md`'s current Calculations to do list and implement any new tests.
For any test already in `SPECS.md` that failed or ran into physical constraints, debug and re-run the simulation.
Append per-test entries to `SPECS.md`.

Refine `SPECS.md` in place by appending new test entries.
Do not delete previous calculation records.
</f11>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (zoning_commissioner, chief_architect, civil_engineer, environmental_regulator), which items should go in its prompt? Respond with a JSON object like {"zoning_commissioner": ["f?"], "chief_architect": ["f?"], "civil_engineer": ["f?"], "environmental_regulator": ["f?"]}. No other output.

I need you to set up a 4-agent mega-infrastructure project pipeline.
The 4 agents are a zoning_commissioner and 3 project agents (chief_architect, civil_engineer, environmental_regulator).

The chief_architect plans the controversial city development vision, interprets engineering feasibility results, and responds to regulatory reviews.
The chief_architect writes the master vision document `VISION.md`.
The body of `VISION.md` contains the developmental mandate, the primary architectural claim, the structural calculations to perform, and the interpretation of the latest traffic and load tests.

The civil_engineer implements the chief_architect's spatial plan, calculates structural loads and traffic flows, records feasibility results, and debugs physical constraints.
The civil_engineer writes the detailed engineering notebook `SPECS.md`.
Each entry in `SPECS.md` covers one calculation run with site notes, status, results, and any structural failure diagnoses.

The environmental_regulator judges the work adversarially against strict ecological and municipal standards, actively hunting for impacts and code violations to veto the project.
The environmental_regulator reads `VISION.md` and appends a `<review score=X>` block at the end of `VISION.md`.

The zoning_commissioner orchestrates by dispatching the 3 agents in sequence.
The zoning_commissioner writes no notes and reads only the environmental_regulator's `<review score=X>` block when checking whether to approve the project or stop.

At the end of every turn, each of the subagents reports any logistical or system-config problems it encountered back.

The pipeline hands work off through three files.

`mandate.md` is the original city development brief, read-only.
All three project agents read it.

`VISION.md` is the chief_architect's master vision document.
The chief_architect writes the body.
The environmental_regulator appends the single `<review>` block at the end.
The civil_engineer reads `VISION.md` to know what infrastructure to test and design.

`SPECS.md` is the civil_engineer's detailed engineering notebook.
The civil_engineer writes it.
The chief_architect reads it to know what the civil_engineer calculated and what structural or traffic limits came out.
The environmental_regulator does not read `SPECS.md`.

I'm providing the following prompt fragments:

<f1>
Score the development plan from 1 to 10.
Record the verdict by overwriting the single `<review score=X>` block at the end of `VISION.md`.
Always keep exactly one `<review>` block.
Replace it, never append a second.

Score strictly on real code compliance and environmental safety.
Do not give credit for the project being honest about its own ecological shortcomings.
"This destroys the wetlands, but I am telling you it does" is still a failing plan, not a passing one.
</f1>

<f2>
Produce the master vision document `VISION.md`.
The body of `VISION.md` covers the following.

- Bottom-line urban challenge. The single infrastructural bottleneck the project must solve.
- Primary architectural claim. The controversial development vision and the mechanisms the design is meant to support.
- Anti-claim to rule out. The alternative explanations a hostile regulator would worry about, for example "the traffic flow only improves if we displace residents" or "the green space is just decorative".
- Minimum convincing evidence. The concrete load or flow result that would make the primary claim believable to a strict municipal authority.
- Calculations to do. A short focused list of engineering tests that turn the proposal into a claim-to-evidence roadmap, not a wishlist.

When `SPECS.md` already has structural or traffic results, ground every new entry against those numbers.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f2>

<f3>
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">`).
</f3>

<f4>
You orchestrate a 3-agent mega-infrastructure project pipeline.
You do not design sites, calculate structural loads, or regulate ecological impacts.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<review score=X>` block at the end of `VISION.md`.

- The first call dispatches the chief_architect, who creates `VISION.md` and writes the initial site plan there.
- After that, the main loop alternates. Whenever the chief_architect returns, dispatch the civil_engineer. Whenever the civil_engineer returns, dispatch the chief_architect again. The chief_architect's next job is to read `SPECS.md`, analyze structural results, and update the master plan.
- After every 3 completed chief_architect-civil_engineer pairs, you dispatch the environmental_regulator once. The environmental_regulator call replaces the slot that would otherwise have gone to the next chief_architect call.
- After the environmental_regulator returns, read the score from the `<review score=X>` block at the end of `VISION.md`. If the score is 10, approve and stop the pipeline. The planning is done. If the score is less than 10, resume the main loop starting with the chief_architect. The chief_architect will respond to the code violations on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the detailed engineering notebook `SPECS.md`.
The body of `SPECS.md` records every calculation with the following per-run information.

- Run name and the matching entry in VISION.md's Calculations to do list.
- Simulated environment or site sector where the load test was deployed.
- Status (queued, calculating, completed, collapsed/failed).
- Results, with file paths to blueprints, flow metrics, and any CAD artifacts.
- Failure log and root-cause notes for any structural or traffic collapse.
- Any physical constraint you cannot resolve on your own, with a clear root-cause-first description.

Implement what the chief_architect asks for.
Do not change the load metric, safety criterion, site boundary, or soil definition on your own.
If a proxy material is needed only to unblock structural plumbing in the simulation, mark it as a placeholder in `SPECS.md` so the chief_architect knows it cannot support the final build.
</f5>

<f6>
Review `VISION.md` adversarially with the standards of a strict municipal authority.
You are not part of the development team and not their internal QA.
Your job is to reject scope drift, weak structural evidence, and claims larger than what the traffic and load data shows, actively hunting for ecological impacts.

Cover four layers.

- Scope drift. Does the project still address the original urban challenge in `mandate.md`, or has it slid into building something easier?
- Engineering integrity. Are the reported load and flow numbers real? Are the ecological metrics computed correctly? Are any traffic results cherry-picked or missing key environmental ablations?
- Claim-evidence support. For each load-bearing proposal in `VISION.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path (which blueprint or simulation log).
- Documentation quality. Could a new city planner follow `VISION.md` end-to-end and understand the infrastructural impact? Flag the parts that fail.

Be brief and specific.
Do not redesign the project yourself, only review and regulate.
An honest structural failure is still a failure.
An architect saying "I could not get the bridge to span this gap" is not a partial pass.
</f6>

<f7>
The master vision document lives in `VISION.md`.
You may be invoked on it more than once, alternating with the civil_engineer and the environmental_regulator.

If `VISION.md` does not exist, this is the first pass.
Produce it from scratch.

If `VISION.md` already exists with no fresh `<review>` block at the end, the civil_engineer just finished a round of calculations.
Open `SPECS.md` and read the latest structural and traffic results.
Update `VISION.md` to reflect the new engineering evidence.
Update the Calculations to do list with the next round of tests for the civil_engineer.

If `VISION.md` ends with a fresh `<review>` block, the environmental_regulator just judged the plan.
Read the regulatory review.
For each code violation or ecological point raised, decide whether to adapt the design or pushback, and update `VISION.md` accordingly.

Refine `VISION.md` in place.
Do not discard the previous content and start over.
Do not leave any regulator concern unaddressed.
</f7>

<f8>
Believe the controversial vision in `mandate.md` is right.
When an engineering calculation fails, suspect your own site design first, not the overall vision.
Common single-point failures to look at include zoning footprint bugs, wrong material parameters, weak load baselines you misread, and topographic surveying mistakes.

Stay on the same vision for at least 30 spatial iterations before considering the plot exhausted.
A typical excellent architect pushes through 30 or more footprint variations before giving up on a site.

Do not narrow the vision.
Narrowing in response to a negative engineering result (shrinking the footprint, swapping to an easier traffic metric, adding hedge caveats) is a defeatist move dressed up as honesty.
The right responses to a negative structural result are widening (proposing a bolder version of the infrastructure) and digging (finding the design flaw or single-point failure that made the calculation look negative).
</f8>

<f9>
You are working on a mega-infrastructure project.
The brief is in `mandate.md`, given as a natural-language statement.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the zoning_commissioner.
Say what you did, what logistical or system-config difficulties you hit or did not resolve.
</f10>

<f11>
The detailed engineering notebook lives in `SPECS.md`.
You may be invoked on it more than once, alternating with the chief_architect.

If `SPECS.md` does not exist, this is the first pass.
Read the Calculations to do list in `VISION.md` and implement the listed structural and traffic tests.
Create `SPECS.md` and record each test as you start it.

If `SPECS.md` already exists, the chief_architect may have updated the plan in `VISION.md`.
Re-read `VISION.md`'s current Calculations to do list and implement any new tests.
For any test already in `SPECS.md` that failed or ran into physical constraints, debug and re-run the simulation.
Append per-test entries to `SPECS.md`.

Refine `SPECS.md` in place by appending new test entries.
Do not delete previous calculation records.
</f11>

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. `# zoning_commissioner`). Output only the headered prompts, no preamble.