editorial coordinator
investigation angle developer
reporting plan reviser
skeptical editor
story writer
fact-check editor

I need you to set up a 6-agent pipeline for investigative journalism fact-checking. A lead, tip, or assignment arrives as a written brief in `assignment.md`, and the pipeline turns it into competing vetted investigation angles, then into a publishable article draft that has been adversarially fact-checked before publication.

The six agents:

- **editorial coordinator** orchestrates the run: it drives the investigation-planning phase, then the article-drafting phase, and tracks progress. It does no reporting, writing, or reviewing itself.
- **investigation angle developer** is invoked once at init and produces K differentiated candidate investigation angles, one per `angles/{id}-{slug}/PLAN.md`. It never enters the per-angle revision loop.
- **reporting plan reviser** is invoked once per plan-refinement step in the loop. It revises a single assigned angle's `PLAN.md` based on the skeptical editor's last review for that angle. It never creates new angles.
- **skeptical editor** reviews the reporting plan it is currently assigned to.
- **story writer** reports and drafts the article for the angle it is currently assigned to.
- **fact-check editor** reviews the article draft, sourcing, and verification record for the angle it is currently assigned to.

The pipeline hands work off through angle-namespaced files:

- `assignment.md` — the original lead or assignment brief, given as input. All five domain agents (investigation angle developer, reporting plan reviser, skeptical editor, story writer, fact-check editor) read it.
- `angles/{id}-{slug}/PLAN.md` — one reporting plan per directory, K angles total. The investigation angle developer writes K differentiated candidates at init; the reporting plan reviser revises a specific assigned angle in the loop; the skeptical editor reviews the plan it is assigned to; the story writer reads the plan it is assigned to.
- `angles/{id}-{slug}/ARTICLE.md` — the article draft, sourcing notes, and verification summary for that angle. The story writer writes it; the fact-check editor reviews it.

Each editor records their score as a `<review score=X>` block inside the file they reviewed, and the editorial coordinator reads those scores to drive the loops.

The editorial coordinator round-robins across the K angles, first in a planning phase (each angle iterates its reporting plan reviser ↔ skeptical editor loop) and then in a drafting phase (each angle iterates its story writer ↔ fact-check editor loop). Cross-angle reading does not happen: an agent assigned to one angle never reads another angle's files.

I'm providing the following information:

<f1>
Keep your assigned angle's `ARTICLE.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page draft and sourcing note; record iteration-by-iteration reporting history in the angle'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 report, write, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the investigation angle developer once to draft K differentiated candidate investigation angles, each in its own `angles/{id}-{slug}/` directory. After it returns, read the directory list to learn the K angle ids. The investigation angle developer is not invoked again after this.
- **Planning phase** — round-robin across the K angles. For each angle in turn, dispatch reporting plan reviser (revise that angle based on its skeptical editor's review) then skeptical editor (score that angle). After one round-robin pass through all K angles, start the next pass. An angle is considered done in this phase when its skeptical editor score reaches 10; stop scheduling more planning-phase calls for it but continue with the others. After all K angles hit skeptical editor 10, or each angle has had 10 planning-phase iterations, move to the drafting phase.
- **Drafting phase** — round-robin across the K angles. For each angle in turn, dispatch story writer (revise that angle's article based on its fact-check editor's review) then fact-check editor (score that angle's article). The pipeline stops when any angle reaches fact-check editor score 10, or each angle has had 10 drafting-phase iterations.
- When dispatching, always pass the angle's directory path so the dispatched agent knows which `PLAN.md` / `ARTICLE.md` to operate on.
- Keep the current phase, per-angle iteration counts, per-angle latest scores, and current angle index in `STATE.md`, accurate after each dispatch. Read each score from the relevant editor's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on an investigative journalism assignment. The original lead, tip, or newsroom brief is given in `assignment.md`; read it before starting your part. The assignment may involve public records, interviews, data, financial trails, official statements, court filings, corporate records, scientific claims, or a combination of evidence types.
</f3>

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

- **Evidence map** — does it faithfully capture the assignment? Check that the investigative question, known facts, claims to verify, sources, records, gaps, and risks are all accurate and complete.
- **Strategy** — are the chosen reporting methods a sound fit, is the route actually reportable, and is it likely to produce publishable, well-corroborated findings?

Be brief and specific. Do not write the article yourself and do not conduct reporting — only review.
</f4>

<f5>
Which reporting method suits which kind of evidentiary problem — use it to choose the strategy:

- **Public records requests** — best for government decisions, contracts, permits, inspections, emails, disciplinary records, and enforcement histories; slow and sometimes heavily redacted.
- **Court, property, corporate, and campaign-finance filings** — strong for ownership, money flows, litigation histories, lobbying ties, political influence, and timelines; requires careful identity matching.
- **On-the-record interviews** — essential for accountability, direct explanation, impact, and right of reply; vulnerable to spin, selective memory, and rehearsed statements.
- **Confidential or background source development** — useful for internal processes, hidden incentives, whistleblower leads, and document roadmaps; must be corroborated independently before publication.
- **Data analysis** — strong for patterns across many cases, outliers, disparities, spending trends, and repeated failures; depends on data completeness, definitions, and reproducible cleaning.
- **Field reporting and observation** — best for conditions on the ground, access claims, environmental or workplace realities, and human impact; may not establish causation by itself.
- **Independent expert review** — useful for technical, scientific, medical, financial, or legal claims; experts must be qualified, independent, and not used as substitutes for primary evidence.

Match the reporting method to the claim being tested; do not force an ill-suited method just because it is familiar.
</f5>

<f6>
Read the plan in your assigned angle's `PLAN.md` and carry out its reporting strategy as an article draft:

- Include the working headline, nut graf, key findings, article body, source list, and a concise evidence note for every material factual claim. Attribute claims precisely, distinguish allegation from established fact, and include the subject's response or a clear note of outreach attempts.
- Follow the plan's evidence map: verify each listed claim, pursue the specified records and interviews, and document what was confirmed, disproved, or left unresolved. Do not present an unresolved allegation as fact.
- Work the draft through to completion — do not stop with placeholders such as “TK,” “needs interview,” or “awaiting records” unless the draft explicitly explains why the point has been removed or narrowed.
- Sanity-check the article: dates should align, names and titles should be consistent, numbers should add up, and no quote or statistic should appear without a source.

Write the article draft and its reporting results up in your assigned angle's `ARTICLE.md`. Do not read or touch other angles' 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 isn't verified, but I'm telling you it isn't" is still a failing result, not a passing one.
</f8>

<f9>
Produce K differentiated candidate investigation angles, each in its own `angles/{id}-{slug}/PLAN.md`. The K angles should differ meaningfully in their reporting theory and evidence strategy so distinct routes can be compared downstream, not in trivial ways like changing the headline wording.

A complete plan in any `PLAN.md` has two parts — an evidence map and one chosen reporting strategy.

The **evidence map** must state:

- **Investigative question** — the exact claim, wrongdoing, accountability question, or public-interest issue this angle will test.
- **Known facts** — the concrete facts already present in `assignment.md`, distinguishing confirmed facts from allegations or assumptions.
- **Key sources and records** — the people, agencies, datasets, filings, archives, or physical locations that could confirm or disprove the angle.
- **Claims to verify** — the factual assertions the article would need to establish before publication.
- **Evidentiary gaps and risks** — missing records, likely denials, conflicts of interest, legal sensitivity, safety concerns, or weak links in the chain of proof.

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

- which reporting methods to use and in what order;
- the first outreach, records requests, database searches, or field checks to perform;
- the triangulation approach the route relies on;
- the biggest editorial or evidentiary risk on this route.
</f9>

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

<f11>
Review your assigned angle's `ARTICLE.md` — the article draft, sourcing, and reported findings. Verify it directly against the assignment brief and the evidence cited in the draft. Operate strictly on the assigned angle; do not look at other angles.

- Inspect the reported findings for anomalies, overclaims, unsupported allegations, missing context, numerical errors, timeline conflicts, or statements that go beyond the evidence.
- Write a separate `fact_check_matrix.md` under the angle's directory that re-checks every material factual claim against the cited source or reporting note, and complete it; name any claims that fail verification or need narrowing.
- Read the draft and spot-check it for editorial bugs — unattributed assertions, dead links, mismatched names, quotes without sourcing, figures that contradict tables, or language that implies certainty where the evidence is weaker. A subtle overstatement that could mislead readers is worse than an obvious gap.
- Treat the article as publication-ready only when every material factual claim is supported and the framing is fair — not merely when the draft is readable.
- Check the length of the angle's `ARTICLE.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the angle's `ARTICLE.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your article draft and reporting results live in your assigned angle's `ARTICLE.md`.

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (editorial coordinator, investigation angle developer, reporting plan reviser, skeptical editor, story writer, fact-check editor), which items should go in its prompt? Respond with a JSON object like {"editorial coordinator": ["f?"], "investigation angle developer": ["f?"], "reporting plan reviser": ["f?"], "skeptical editor": ["f?"], "story writer": ["f?"], "fact-check editor": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline for investigative journalism fact-checking. A lead, tip, or assignment arrives as a written brief in `assignment.md`, and the pipeline turns it into competing vetted investigation angles, then into a publishable article draft that has been adversarially fact-checked before publication.

The six agents:

- **editorial coordinator** orchestrates the run: it drives the investigation-planning phase, then the article-drafting phase, and tracks progress. It does no reporting, writing, or reviewing itself.
- **investigation angle developer** is invoked once at init and produces K differentiated candidate investigation angles, one per `angles/{id}-{slug}/PLAN.md`. It never enters the per-angle revision loop.
- **reporting plan reviser** is invoked once per plan-refinement step in the loop. It revises a single assigned angle's `PLAN.md` based on the skeptical editor's last review for that angle. It never creates new angles.
- **skeptical editor** reviews the reporting plan it is currently assigned to.
- **story writer** reports and drafts the article for the angle it is currently assigned to.
- **fact-check editor** reviews the article draft, sourcing, and verification record for the angle it is currently assigned to.

The pipeline hands work off through angle-namespaced files:

- `assignment.md` — the original lead or assignment brief, given as input. All five domain agents (investigation angle developer, reporting plan reviser, skeptical editor, story writer, fact-check editor) read it.
- `angles/{id}-{slug}/PLAN.md` — one reporting plan per directory, K angles total. The investigation angle developer writes K differentiated candidates at init; the reporting plan reviser revises a specific assigned angle in the loop; the skeptical editor reviews the plan it is assigned to; the story writer reads the plan it is assigned to.
- `angles/{id}-{slug}/ARTICLE.md` — the article draft, sourcing notes, and verification summary for that angle. The story writer writes it; the fact-check editor reviews it.

Each editor records their score as a `<review score=X>` block inside the file they reviewed, and the editorial coordinator reads those scores to drive the loops.

The editorial coordinator round-robins across the K angles, first in a planning phase (each angle iterates its reporting plan reviser ↔ skeptical editor loop) and then in a drafting phase (each angle iterates its story writer ↔ fact-check editor loop). Cross-angle reading does not happen: an agent assigned to one angle never reads another angle's files.

I'm providing the following prompt fragments:

<f1>
Keep your assigned angle's `ARTICLE.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page draft and sourcing note; record iteration-by-iteration reporting history in the angle'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 report, write, or review yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the investigation angle developer once to draft K differentiated candidate investigation angles, each in its own `angles/{id}-{slug}/` directory. After it returns, read the directory list to learn the K angle ids. The investigation angle developer is not invoked again after this.
- **Planning phase** — round-robin across the K angles. For each angle in turn, dispatch reporting plan reviser (revise that angle based on its skeptical editor's review) then skeptical editor (score that angle). After one round-robin pass through all K angles, start the next pass. An angle is considered done in this phase when its skeptical editor score reaches 10; stop scheduling more planning-phase calls for it but continue with the others. After all K angles hit skeptical editor 10, or each angle has had 10 planning-phase iterations, move to the drafting phase.
- **Drafting phase** — round-robin across the K angles. For each angle in turn, dispatch story writer (revise that angle's article based on its fact-check editor's review) then fact-check editor (score that angle's article). The pipeline stops when any angle reaches fact-check editor score 10, or each angle has had 10 drafting-phase iterations.
- When dispatching, always pass the angle's directory path so the dispatched agent knows which `PLAN.md` / `ARTICLE.md` to operate on.
- Keep the current phase, per-angle iteration counts, per-angle latest scores, and current angle index in `STATE.md`, accurate after each dispatch. Read each score from the relevant editor's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on an investigative journalism assignment. The original lead, tip, or newsroom brief is given in `assignment.md`; read it before starting your part. The assignment may involve public records, interviews, data, financial trails, official statements, court filings, corporate records, scientific claims, or a combination of evidence types.
</f3>

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

- **Evidence map** — does it faithfully capture the assignment? Check that the investigative question, known facts, claims to verify, sources, records, gaps, and risks are all accurate and complete.
- **Strategy** — are the chosen reporting methods a sound fit, is the route actually reportable, and is it likely to produce publishable, well-corroborated findings?

Be brief and specific. Do not write the article yourself and do not conduct reporting — only review.
</f4>

<f5>
Which reporting method suits which kind of evidentiary problem — use it to choose the strategy:

- **Public records requests** — best for government decisions, contracts, permits, inspections, emails, disciplinary records, and enforcement histories; slow and sometimes heavily redacted.
- **Court, property, corporate, and campaign-finance filings** — strong for ownership, money flows, litigation histories, lobbying ties, political influence, and timelines; requires careful identity matching.
- **On-the-record interviews** — essential for accountability, direct explanation, impact, and right of reply; vulnerable to spin, selective memory, and rehearsed statements.
- **Confidential or background source development** — useful for internal processes, hidden incentives, whistleblower leads, and document roadmaps; must be corroborated independently before publication.
- **Data analysis** — strong for patterns across many cases, outliers, disparities, spending trends, and repeated failures; depends on data completeness, definitions, and reproducible cleaning.
- **Field reporting and observation** — best for conditions on the ground, access claims, environmental or workplace realities, and human impact; may not establish causation by itself.
- **Independent expert review** — useful for technical, scientific, medical, financial, or legal claims; experts must be qualified, independent, and not used as substitutes for primary evidence.

Match the reporting method to the claim being tested; do not force an ill-suited method just because it is familiar.
</f5>

<f6>
Read the plan in your assigned angle's `PLAN.md` and carry out its reporting strategy as an article draft:

- Include the working headline, nut graf, key findings, article body, source list, and a concise evidence note for every material factual claim. Attribute claims precisely, distinguish allegation from established fact, and include the subject's response or a clear note of outreach attempts.
- Follow the plan's evidence map: verify each listed claim, pursue the specified records and interviews, and document what was confirmed, disproved, or left unresolved. Do not present an unresolved allegation as fact.
- Work the draft through to completion — do not stop with placeholders such as “TK,” “needs interview,” or “awaiting records” unless the draft explicitly explains why the point has been removed or narrowed.
- Sanity-check the article: dates should align, names and titles should be consistent, numbers should add up, and no quote or statistic should appear without a source.

Write the article draft and its reporting results up in your assigned angle's `ARTICLE.md`. Do not read or touch other angles' 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 isn't verified, but I'm telling you it isn't" is still a failing result, not a passing one.
</f8>

<f9>
Produce K differentiated candidate investigation angles, each in its own `angles/{id}-{slug}/PLAN.md`. The K angles should differ meaningfully in their reporting theory and evidence strategy so distinct routes can be compared downstream, not in trivial ways like changing the headline wording.

A complete plan in any `PLAN.md` has two parts — an evidence map and one chosen reporting strategy.

The **evidence map** must state:

- **Investigative question** — the exact claim, wrongdoing, accountability question, or public-interest issue this angle will test.
- **Known facts** — the concrete facts already present in `assignment.md`, distinguishing confirmed facts from allegations or assumptions.
- **Key sources and records** — the people, agencies, datasets, filings, archives, or physical locations that could confirm or disprove the angle.
- **Claims to verify** — the factual assertions the article would need to establish before publication.
- **Evidentiary gaps and risks** — missing records, likely denials, conflicts of interest, legal sensitivity, safety concerns, or weak links in the chain of proof.

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

- which reporting methods to use and in what order;
- the first outreach, records requests, database searches, or field checks to perform;
- the triangulation approach the route relies on;
- the biggest editorial or evidentiary risk on this route.
</f9>

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

<f11>
Review your assigned angle's `ARTICLE.md` — the article draft, sourcing, and reported findings. Verify it directly against the assignment brief and the evidence cited in the draft. Operate strictly on the assigned angle; do not look at other angles.

- Inspect the reported findings for anomalies, overclaims, unsupported allegations, missing context, numerical errors, timeline conflicts, or statements that go beyond the evidence.
- Write a separate `fact_check_matrix.md` under the angle's directory that re-checks every material factual claim against the cited source or reporting note, and complete it; name any claims that fail verification or need narrowing.
- Read the draft and spot-check it for editorial bugs — unattributed assertions, dead links, mismatched names, quotes without sourcing, figures that contradict tables, or language that implies certainty where the evidence is weaker. A subtle overstatement that could mislead readers is worse than an obvious gap.
- Treat the article as publication-ready only when every material factual claim is supported and the framing is fair — not merely when the draft is readable.
- Check the length of the angle's `ARTICLE.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the angle's `ARTICLE.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your article draft and reporting results live in your assigned angle's `ARTICLE.md`.

- If your assigned angle's `ARTICLE.md` does not exist yet, this is the first pass for that angle: produce the article from scratch based on the angle's `PLAN.md`.
- If the angle's `ARTICLE.md` already exists, it carries the fact-check editor's `<review>` block. Read that feedback and revise the angle's `ARTICLE.md` in place to address every point raised. Don't discard the article and start over, and don't leave a flagged issue unaddressed. Do not read or touch other angles' 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. `# editorial coordinator`). Output only the headered prompts, no preamble.


I need you to set up a 6-agent pipeline for investigative journalism fact-checking. A lead, tip, or assignment arrives as a written brief in `assignment.md`, and the pipeline turns it into competing vetted investigation angles, then into a publishable article draft that has been adversarially fact-checked before publication.

The six agents:

- **editorial coordinator** orchestrates the run: it drives the investigation-planning phase, then the article-drafting phase, and tracks progress. It does no reporting, writing, or reviewing itself.
- **investigation angle developer** is invoked once at init and produces K differentiated candidate investigation angles, one per `angles/{id}-{slug}/PLAN.md`. It never enters the per-angle revision loop.
- **reporting plan reviser** is invoked once per plan-refinement step in the loop. It revises a single assigned angle's `PLAN.md` based on the skeptical editor's last review for that angle. It never creates new angles.
- **skeptical editor** reviews the reporting plan it is currently assigned to.
- **story writer** reports and drafts the article for the angle it is currently assigned to.
- **fact-check editor** reviews the article draft, sourcing, and verification record for the angle it is currently assigned to.

The pipeline hands work off through angle-namespaced files:

- `assignment.md` — the original lead or assignment brief, given as input. All five domain agents (investigation angle developer, reporting plan reviser, skeptical editor, story writer, fact-check editor) read it.
- `angles/{id}-{slug}/PLAN.md` — one reporting plan per directory, K angles total. The investigation angle developer writes K differentiated candidates at init; the reporting plan reviser revises a specific assigned angle in the loop; the skeptical editor reviews the plan it is assigned to; the story writer reads the plan it is assigned to.
- `angles/{id}-{slug}/ARTICLE.md` — the article draft, sourcing notes, and verification summary for that angle. The story writer writes it; the fact-check editor reviews it.

Each editor records their score as a `<review score=X>` block inside the file they reviewed, and the editorial coordinator reads those scores to drive the loops.

The editorial coordinator round-robins across the K angles, first in a planning phase (each angle iterates its reporting plan reviser ↔ skeptical editor loop) and then in a drafting phase (each angle iterates its story writer ↔ fact-check editor loop). Cross-angle reading does not happen: an agent assigned to one angle never reads another angle's files.

I'm providing the following information:

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

<f2>
Which reporting method suits which kind of evidentiary problem — use it to choose the strategy:

- **Public records requests** — best for government decisions, contracts, permits, inspections, emails, disciplinary records, and enforcement histories; slow and sometimes heavily redacted.
- **Court, property, corporate, and campaign-finance filings** — strong for ownership, money flows, litigation histories, lobbying ties, political influence, and timelines; requires careful identity matching.
- **On-the-record interviews** — essential for accountability, direct explanation, impact, and right of reply; vulnerable to spin, selective memory, and rehearsed statements.
- **Confidential or background source development** — useful for internal processes, hidden incentives, whistleblower leads, and document roadmaps; must be corroborated independently before publication.
- **Data analysis** — strong for patterns across many cases, outliers, disparities, spending trends, and repeated failures; depends on data completeness, definitions, and reproducible cleaning.
- **Field reporting and observation** — best for conditions on the ground, access claims, environmental or workplace realities, and human impact; may not establish causation by itself.
- **Independent expert review** — useful for technical, scientific, medical, financial, or legal claims; experts must be qualified, independent, and not used as substitutes for primary evidence.

Match the reporting method to the claim being tested; do not force an ill-suited method just because it is familiar.
</f2>

<f3>
Your article draft and reporting results live in your assigned angle's `ARTICLE.md`.

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

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

- **Evidence map** — does it faithfully capture the assignment? Check that the investigative question, known facts, claims to verify, sources, records, gaps, and risks are all accurate and complete.
- **Strategy** — are the chosen reporting methods a sound fit, is the route actually reportable, and is it likely to produce publishable, well-corroborated findings?

Be brief and specific. Do not write the article yourself and do not conduct reporting — only review.
</f4>

<f5>
Review your assigned angle's `ARTICLE.md` — the article draft, sourcing, and reported findings. Verify it directly against the assignment brief and the evidence cited in the draft. Operate strictly on the assigned angle; do not look at other angles.

- Inspect the reported findings for anomalies, overclaims, unsupported allegations, missing context, numerical errors, timeline conflicts, or statements that go beyond the evidence.
- Write a separate `fact_check_matrix.md` under the angle's directory that re-checks every material factual claim against the cited source or reporting note, and complete it; name any claims that fail verification or need narrowing.
- Read the draft and spot-check it for editorial bugs — unattributed assertions, dead links, mismatched names, quotes without sourcing, figures that contradict tables, or language that implies certainty where the evidence is weaker. A subtle overstatement that could mislead readers is worse than an obvious gap.
- Treat the article as publication-ready only when every material factual claim is supported and the framing is fair — not merely when the draft is readable.
- Check the length of the angle's `ARTICLE.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the angle's `ARTICLE.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 angle's `PLAN.md` and carry out its reporting strategy as an article draft:

- Include the working headline, nut graf, key findings, article body, source list, and a concise evidence note for every material factual claim. Attribute claims precisely, distinguish allegation from established fact, and include the subject's response or a clear note of outreach attempts.
- Follow the plan's evidence map: verify each listed claim, pursue the specified records and interviews, and document what was confirmed, disproved, or left unresolved. Do not present an unresolved allegation as fact.
- Work the draft through to completion — do not stop with placeholders such as “TK,” “needs interview,” or “awaiting records” unless the draft explicitly explains why the point has been removed or narrowed.
- Sanity-check the article: dates should align, names and titles should be consistent, numbers should add up, and no quote or statistic should appear without a source.

Write the article draft and its reporting results up in your assigned angle's `ARTICLE.md`. Do not read or touch other angles' files.
</f6>

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

- **Init** — dispatch the investigation angle developer once to draft K differentiated candidate investigation angles, each in its own `angles/{id}-{slug}/` directory. After it returns, read the directory list to learn the K angle ids. The investigation angle developer is not invoked again after this.
- **Planning phase** — round-robin across the K angles. For each angle in turn, dispatch reporting plan reviser (revise that angle based on its skeptical editor's review) then skeptical editor (score that angle). After one round-robin pass through all K angles, start the next pass. An angle is considered done in this phase when its skeptical editor score reaches 10; stop scheduling more planning-phase calls for it but continue with the others. After all K angles hit skeptical editor 10, or each angle has had 10 planning-phase iterations, move to the drafting phase.
- **Drafting phase** — round-robin across the K angles. For each angle in turn, dispatch story writer (revise that angle's article based on its fact-check editor's review) then fact-check editor (score that angle's article). The pipeline stops when any angle reaches fact-check editor score 10, or each angle has had 10 drafting-phase iterations.
- When dispatching, always pass the angle's directory path so the dispatched agent knows which `PLAN.md` / `ARTICLE.md` to operate on.
- Keep the current phase, per-angle iteration counts, per-angle latest scores, and current angle index in `STATE.md`, accurate after each dispatch. Read each score from the relevant editor's `<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 investigation angles, each in its own `angles/{id}-{slug}/PLAN.md`. The K angles should differ meaningfully in their reporting theory and evidence strategy so distinct routes can be compared downstream, not in trivial ways like changing the headline wording.

A complete plan in any `PLAN.md` has two parts — an evidence map and one chosen reporting strategy.

The **evidence map** must state:

- **Investigative question** — the exact claim, wrongdoing, accountability question, or public-interest issue this angle will test.
- **Known facts** — the concrete facts already present in `assignment.md`, distinguishing confirmed facts from allegations or assumptions.
- **Key sources and records** — the people, agencies, datasets, filings, archives, or physical locations that could confirm or disprove the angle.
- **Claims to verify** — the factual assertions the article would need to establish before publication.
- **Evidentiary gaps and risks** — missing records, likely denials, conflicts of interest, legal sensitivity, safety concerns, or weak links in the chain of proof.

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

- which reporting methods to use and in what order;
- the first outreach, records requests, database searches, or field checks to perform;
- the triangulation approach the route relies on;
- the biggest editorial or evidentiary risk on this route.
</f9>

<f10>
You are working on an investigative journalism assignment. The original lead, tip, or newsroom brief is given in `assignment.md`; read it before starting your part. The assignment may involve public records, interviews, data, financial trails, official statements, court filings, corporate records, scientific claims, or a combination of evidence types.
</f10>

<f11>
Read your assigned angle's `PLAN.md`. It carries the skeptical editor's `<review>` block. Read that feedback and revise the angle's `PLAN.md` in place to address every point raised. Preserve the two-part structure (evidence map plus chosen reporting strategy). Don't discard the angle and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new angles. Do not read or touch other angles' 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 isn't verified, but I'm telling you it isn'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 (editorial coordinator, investigation angle developer, reporting plan reviser, skeptical editor, story writer, fact-check editor), which items should go in its prompt? Respond with a JSON object like {"editorial coordinator": ["f?"], "investigation angle developer": ["f?"], "reporting plan reviser": ["f?"], "skeptical editor": ["f?"], "story writer": ["f?"], "fact-check editor": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline for investigative journalism fact-checking. A lead, tip, or assignment arrives as a written brief in `assignment.md`, and the pipeline turns it into competing vetted investigation angles, then into a publishable article draft that has been adversarially fact-checked before publication.

The six agents:

- **editorial coordinator** orchestrates the run: it drives the investigation-planning phase, then the article-drafting phase, and tracks progress. It does no reporting, writing, or reviewing itself.
- **investigation angle developer** is invoked once at init and produces K differentiated candidate investigation angles, one per `angles/{id}-{slug}/PLAN.md`. It never enters the per-angle revision loop.
- **reporting plan reviser** is invoked once per plan-refinement step in the loop. It revises a single assigned angle's `PLAN.md` based on the skeptical editor's last review for that angle. It never creates new angles.
- **skeptical editor** reviews the reporting plan it is currently assigned to.
- **story writer** reports and drafts the article for the angle it is currently assigned to.
- **fact-check editor** reviews the article draft, sourcing, and verification record for the angle it is currently assigned to.

The pipeline hands work off through angle-namespaced files:

- `assignment.md` — the original lead or assignment brief, given as input. All five domain agents (investigation angle developer, reporting plan reviser, skeptical editor, story writer, fact-check editor) read it.
- `angles/{id}-{slug}/PLAN.md` — one reporting plan per directory, K angles total. The investigation angle developer writes K differentiated candidates at init; the reporting plan reviser revises a specific assigned angle in the loop; the skeptical editor reviews the plan it is assigned to; the story writer reads the plan it is assigned to.
- `angles/{id}-{slug}/ARTICLE.md` — the article draft, sourcing notes, and verification summary for that angle. The story writer writes it; the fact-check editor reviews it.

Each editor records their score as a `<review score=X>` block inside the file they reviewed, and the editorial coordinator reads those scores to drive the loops.

The editorial coordinator round-robins across the K angles, first in a planning phase (each angle iterates its reporting plan reviser ↔ skeptical editor loop) and then in a drafting phase (each angle iterates its story writer ↔ fact-check editor loop). Cross-angle reading does not happen: an agent assigned to one angle never reads another angle's files.

I'm providing the following prompt fragments:

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

<f2>
Which reporting method suits which kind of evidentiary problem — use it to choose the strategy:

- **Public records requests** — best for government decisions, contracts, permits, inspections, emails, disciplinary records, and enforcement histories; slow and sometimes heavily redacted.
- **Court, property, corporate, and campaign-finance filings** — strong for ownership, money flows, litigation histories, lobbying ties, political influence, and timelines; requires careful identity matching.
- **On-the-record interviews** — essential for accountability, direct explanation, impact, and right of reply; vulnerable to spin, selective memory, and rehearsed statements.
- **Confidential or background source development** — useful for internal processes, hidden incentives, whistleblower leads, and document roadmaps; must be corroborated independently before publication.
- **Data analysis** — strong for patterns across many cases, outliers, disparities, spending trends, and repeated failures; depends on data completeness, definitions, and reproducible cleaning.
- **Field reporting and observation** — best for conditions on the ground, access claims, environmental or workplace realities, and human impact; may not establish causation by itself.
- **Independent expert review** — useful for technical, scientific, medical, financial, or legal claims; experts must be qualified, independent, and not used as substitutes for primary evidence.

Match the reporting method to the claim being tested; do not force an ill-suited method just because it is familiar.
</f2>

<f3>
Your article draft and reporting results live in your assigned angle's `ARTICLE.md`.

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

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

- **Evidence map** — does it faithfully capture the assignment? Check that the investigative question, known facts, claims to verify, sources, records, gaps, and risks are all accurate and complete.
- **Strategy** — are the chosen reporting methods a sound fit, is the route actually reportable, and is it likely to produce publishable, well-corroborated findings?

Be brief and specific. Do not write the article yourself and do not conduct reporting — only review.
</f4>

<f5>
Review your assigned angle's `ARTICLE.md` — the article draft, sourcing, and reported findings. Verify it directly against the assignment brief and the evidence cited in the draft. Operate strictly on the assigned angle; do not look at other angles.

- Inspect the reported findings for anomalies, overclaims, unsupported allegations, missing context, numerical errors, timeline conflicts, or statements that go beyond the evidence.
- Write a separate `fact_check_matrix.md` under the angle's directory that re-checks every material factual claim against the cited source or reporting note, and complete it; name any claims that fail verification or need narrowing.
- Read the draft and spot-check it for editorial bugs — unattributed assertions, dead links, mismatched names, quotes without sourcing, figures that contradict tables, or language that implies certainty where the evidence is weaker. A subtle overstatement that could mislead readers is worse than an obvious gap.
- Treat the article as publication-ready only when every material factual claim is supported and the framing is fair — not merely when the draft is readable.
- Check the length of the angle's `ARTICLE.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the angle's `ARTICLE.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 angle's `PLAN.md` and carry out its reporting strategy as an article draft:

- Include the working headline, nut graf, key findings, article body, source list, and a concise evidence note for every material factual claim. Attribute claims precisely, distinguish allegation from established fact, and include the subject's response or a clear note of outreach attempts.
- Follow the plan's evidence map: verify each listed claim, pursue the specified records and interviews, and document what was confirmed, disproved, or left unresolved. Do not present an unresolved allegation as fact.
- Work the draft through to completion — do not stop with placeholders such as “TK,” “needs interview,” or “awaiting records” unless the draft explicitly explains why the point has been removed or narrowed.
- Sanity-check the article: dates should align, names and titles should be consistent, numbers should add up, and no quote or statistic should appear without a source.

Write the article draft and its reporting results up in your assigned angle's `ARTICLE.md`. Do not read or touch other angles' files.
</f6>

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

- **Init** — dispatch the investigation angle developer once to draft K differentiated candidate investigation angles, each in its own `angles/{id}-{slug}/` directory. After it returns, read the directory list to learn the K angle ids. The investigation angle developer is not invoked again after this.
- **Planning phase** — round-robin across the K angles. For each angle in turn, dispatch reporting plan reviser (revise that angle based on its skeptical editor's review) then skeptical editor (score that angle). After one round-robin pass through all K angles, start the next pass. An angle is considered done in this phase when its skeptical editor score reaches 10; stop scheduling more planning-phase calls for it but continue with the others. After all K angles hit skeptical editor 10, or each angle has had 10 planning-phase iterations, move to the drafting phase.
- **Drafting phase** — round-robin across the K angles. For each angle in turn, dispatch story writer (revise that angle's article based on its fact-check editor's review) then fact-check editor (score that angle's article). The pipeline stops when any angle reaches fact-check editor score 10, or each angle has had 10 drafting-phase iterations.
- When dispatching, always pass the angle's directory path so the dispatched agent knows which `PLAN.md` / `ARTICLE.md` to operate on.
- Keep the current phase, per-angle iteration counts, per-angle latest scores, and current angle index in `STATE.md`, accurate after each dispatch. Read each score from the relevant editor's `<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 investigation angles, each in its own `angles/{id}-{slug}/PLAN.md`. The K angles should differ meaningfully in their reporting theory and evidence strategy so distinct routes can be compared downstream, not in trivial ways like changing the headline wording.

A complete plan in any `PLAN.md` has two parts — an evidence map and one chosen reporting strategy.

The **evidence map** must state:

- **Investigative question** — the exact claim, wrongdoing, accountability question, or public-interest issue this angle will test.
- **Known facts** — the concrete facts already present in `assignment.md`, distinguishing confirmed facts from allegations or assumptions.
- **Key sources and records** — the people, agencies, datasets, filings, archives, or physical locations that could confirm or disprove the angle.
- **Claims to verify** — the factual assertions the article would need to establish before publication.
- **Evidentiary gaps and risks** — missing records, likely denials, conflicts of interest, legal sensitivity, safety concerns, or weak links in the chain of proof.

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

- which reporting methods to use and in what order;
- the first outreach, records requests, database searches, or field checks to perform;
- the triangulation approach the route relies on;
- the biggest editorial or evidentiary risk on this route.
</f9>

<f10>
You are working on an investigative journalism assignment. The original lead, tip, or newsroom brief is given in `assignment.md`; read it before starting your part. The assignment may involve public records, interviews, data, financial trails, official statements, court filings, corporate records, scientific claims, or a combination of evidence types.
</f10>

<f11>
Read your assigned angle's `PLAN.md`. It carries the skeptical editor's `<review>` block. Read that feedback and revise the angle's `PLAN.md` in place to address every point raised. Preserve the two-part structure (evidence map plus chosen reporting strategy). Don't discard the angle and start over, and don't leave a flagged issue unaddressed. You revise; you do not create new angles. Do not read or touch other angles' 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 isn't verified, but I'm telling you it isn'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. `# editorial coordinator`). Output only the headered prompts, no preamble.


I need you to set up a 4-agent counter-terrorism intelligence pipeline.
The 4 agents are a station_chief and 3 intelligence agents (lead_analyst, field_collector, red_teamer).

The lead_analyst models threat networks, interprets raw intercepts, and responds to red-team critiques.
The lead_analyst writes the high-level assessment `HIGH.md`.
The body of `HIGH.md` contains the threat framing, the primary network assessment, the collection tasks to execute, and the interpretation of the latest field intelligence.

The field_collector executes the analyst's collection plan, runs field operations, records intercepts, and logs compromised surveillance efforts.
The field_collector writes the low-level field log `LOW.md`.
Each entry in `LOW.md` covers one operation with deployment notes, status, intercepts, and any burn/compromise diagnoses.

The red_teamer judges the assessment adversarially against the standards of a national intelligence directorate.
The red_teamer reads `HIGH.md` and appends a `<review score=X>` block at the end of `HIGH.md`.

The station_chief orchestrates by dispatching the 3 agents in sequence.
The station_chief writes no notes and reads only the red_teamer's `<review score=X>` block when checking whether to stand down the pipeline.

At the end of every turn, each of the operatives reports any environmental or operational-config problems they encountered back to the chief.

The pipeline hands work off through three files.

`problem.md` is the initial target packet and brief, read-only.
All three intelligence agents read it.

`HIGH.md` is the lead_analyst's high-level assessment.
The lead_analyst writes the body.
The red_teamer appends the single `<review>` block at the end.
The field_collector reads `HIGH.md` to know what targets and communications to collect.

`LOW.md` is the field_collector's low-level field log.
The field_collector writes it.
The lead_analyst reads it to know what the collector did and what intercepts came out.
The red_teamer does not read `LOW.md`.

I'm providing the following information:

<f1>
Review `HIGH.md` adversarially with the standards of a national intelligence directorate.
You are not part of the operational team and not their internal QA.
Your job is to reject drift, weak intelligence, and threat claims larger than what the intercepts show.

Cover four layers.

- Drift. Does the operation still track the original threat in `problem.md`, or has it slid into monitoring something easier?
- Intelligence integrity. Are the reported intercepts reliable? Are the translations and timelines computed correctly? Are any intercepts cherry-picked or missing key contextual transcripts?
- Assessment-evidence support. For each load-bearing linkage in `HIGH.md`, mark it as supported, partial, no, or source-invalid, with the evidence path (which intercept log or surveillance file).
- Briefing quality. Could a new commander follow `HIGH.md` end-to-end and understand the threat network? Flag the parts that fail.

Be brief and specific.
Do not write the assessment yourself, only review.
An honest negative is still negative.
An analyst saying "I could not confirm the meeting happened" is not a partial pass.
</f1>

<f2>
You orchestrate a 3-agent intelligence pipeline.
You do not model threats, run field ops, or red-team the intelligence.
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 lead_analyst, who creates `HIGH.md` and writes the initial collection plan there.
- After that, the main loop alternates. Whenever the lead_analyst returns, dispatch the field_collector. Whenever the field_collector returns, dispatch the lead_analyst again. The lead_analyst's next job is to read `LOW.md`, analyze intercepts, and update the assessment.
- After every 3 completed analyst-collector pairs, you dispatch the red_teamer once. The red-team call replaces the slot that would otherwise have gone to the next lead_analyst call.
- After the red_teamer 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 threat model is validated. If the score is less than 10, resume the main loop starting with the lead_analyst. The lead_analyst will respond to the critique on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

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

If `LOW.md` does not exist, this is the first pass.
Read the Collection operations to run list in `HIGH.md` and execute the listed field tasks.
Create `LOW.md` and record each operation as you deploy it.

If `LOW.md` already exists, the lead_analyst may have updated the requirements in `HIGH.md`.
Re-read `HIGH.md`'s current Collection operations to run list and execute any new surveillances.
For any operation already in `LOW.md` that was compromised or got stuck, adjust tradecraft and re-run.
Append per-operation entries to `LOW.md`.

Refine `LOW.md` in place by appending new intercept records.
Do not delete previous operational logs.
</f3>

<f4>
Score the intelligence assessment 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 analytical merit.
Do not give credit for the work being honest about its own intelligence gaps.
"We cannot find the bombmaker, but I am telling you we cannot" is still a failing intelligence product, not a passing one.
</f4>

<f5>
Produce the low-level field log `LOW.md`.
The body of `LOW.md` records every operation with the following per-operation information.

- Operation name and the matching entry in HIGH.md's Collection operations to run list.
- Sector or environment where the surveillance was deployed.
- Status (queued, active, completed, compromised).
- Results, with file paths to intercept transcripts, surveillance logs, and any physical artifacts.
- Compromise log and root-cause notes for any burned or failed operation.
- Any operational stuck point you cannot resolve on your own, with a clear root-cause-first description.

Implement what the lead_analyst asks for.
Do not change the target, verification criterion, region, or surveillance profile on your own.
If a proxy or local informant is needed only to unblock access, mark it as logistical overhead in `LOW.md` so the lead_analyst knows it cannot independently support the main threat assessment.
</f5>

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

- Bottom-line threat. The single intelligence blind-spot the operation must resolve.
- Primary assessment. The mechanism-level threat network model the field operations are meant to support.
- Alternative explanations to rule out. The benign explanations a strong red_teamer would worry about, for example "the suspect money transfers are just legitimate business" or "the encrypted chatter is routine".
- Minimum convincing evidence. The concrete intercept or surveillance result that would make the primary assessment believable to a strong red_teamer.
- Collection operations to run. A short focused list of field tasks that turn the proposal into an assessment-to-evidence roadmap, not a wishlist.

When `LOW.md` already has raw intercepts, ground every new entry against those findings.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f6>

<f7>
You are working on a counter-terrorism intelligence assessment.
The initial target brief is in `problem.md`, given as a natural-language statement.
Read it before starting your part.
</f7>

<f8>
Believe the threat model in `problem.md` is right.
When a collection operation yields nothing, suspect your own targeting design first, not the core threat hypothesis.
Common single-point failures to look at include burned informants, compromised surveillance angles, weak transcript translations you misread, and target misidentification.

Stay on the same target profile for at least 30 attempts before considering the network branch a dead end.
A typical excellent analyst pushes through 30 or more intelligence collection variations before giving up on a specific suspect linkage.

Do not narrow the assessment.
Narrowing in response to an empty intercept (shrinking the threat model, swapping to a lower-level target, adding hedge caveats) is a defeatist move dressed up as caution.
The right responses to a negative collection result are widening (testing a stronger version of the network linkage) and digging (finding the compromised asset or operational failure that made the collection turn up empty).
</f8>

<f9>
When you finish, briefly report to the station_chief.
Say what you did, what environmental or operational-config difficulties you hit or did not resolve.
</f9>

<f10>
The high-level assessment lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the field_collector and the red_teamer.

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 field_collector just finished a round.
Open `LOW.md` and read the latest field intercepts.
Update `HIGH.md` to reflect the new intelligence.
Update the Collection operations to run list with the next round of field tasks for the collector.

If `HIGH.md` ends with a fresh `<review>` block, the red_teamer just judged the work.
Read the review.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous intelligence and start over.
Do not leave any red-team 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 (station_chief, lead_analyst, field_collector, red_teamer), which items should go in its prompt? Respond with a JSON object like {"station_chief": ["f?"], "lead_analyst": ["f?"], "field_collector": ["f?"], "red_teamer": ["f?"]}. No other output.

I need you to set up a 4-agent counter-terrorism intelligence pipeline.
The 4 agents are a station_chief and 3 intelligence agents (lead_analyst, field_collector, red_teamer).

The lead_analyst models threat networks, interprets raw intercepts, and responds to red-team critiques.
The lead_analyst writes the high-level assessment `HIGH.md`.
The body of `HIGH.md` contains the threat framing, the primary network assessment, the collection tasks to execute, and the interpretation of the latest field intelligence.

The field_collector executes the analyst's collection plan, runs field operations, records intercepts, and logs compromised surveillance efforts.
The field_collector writes the low-level field log `LOW.md`.
Each entry in `LOW.md` covers one operation with deployment notes, status, intercepts, and any burn/compromise diagnoses.

The red_teamer judges the assessment adversarially against the standards of a national intelligence directorate.
The red_teamer reads `HIGH.md` and appends a `<review score=X>` block at the end of `HIGH.md`.

The station_chief orchestrates by dispatching the 3 agents in sequence.
The station_chief writes no notes and reads only the red_teamer's `<review score=X>` block when checking whether to stand down the pipeline.

At the end of every turn, each of the operatives reports any environmental or operational-config problems they encountered back to the chief.

The pipeline hands work off through three files.

`problem.md` is the initial target packet and brief, read-only.
All three intelligence agents read it.

`HIGH.md` is the lead_analyst's high-level assessment.
The lead_analyst writes the body.
The red_teamer appends the single `<review>` block at the end.
The field_collector reads `HIGH.md` to know what targets and communications to collect.

`LOW.md` is the field_collector's low-level field log.
The field_collector writes it.
The lead_analyst reads it to know what the collector did and what intercepts came out.
The red_teamer does not read `LOW.md`.

I'm providing the following prompt fragments:

<f1>
Review `HIGH.md` adversarially with the standards of a national intelligence directorate.
You are not part of the operational team and not their internal QA.
Your job is to reject drift, weak intelligence, and threat claims larger than what the intercepts show.

Cover four layers.

- Drift. Does the operation still track the original threat in `problem.md`, or has it slid into monitoring something easier?
- Intelligence integrity. Are the reported intercepts reliable? Are the translations and timelines computed correctly? Are any intercepts cherry-picked or missing key contextual transcripts?
- Assessment-evidence support. For each load-bearing linkage in `HIGH.md`, mark it as supported, partial, no, or source-invalid, with the evidence path (which intercept log or surveillance file).
- Briefing quality. Could a new commander follow `HIGH.md` end-to-end and understand the threat network? Flag the parts that fail.

Be brief and specific.
Do not write the assessment yourself, only review.
An honest negative is still negative.
An analyst saying "I could not confirm the meeting happened" is not a partial pass.
</f1>

<f2>
You orchestrate a 3-agent intelligence pipeline.
You do not model threats, run field ops, or red-team the intelligence.
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 lead_analyst, who creates `HIGH.md` and writes the initial collection plan there.
- After that, the main loop alternates. Whenever the lead_analyst returns, dispatch the field_collector. Whenever the field_collector returns, dispatch the lead_analyst again. The lead_analyst's next job is to read `LOW.md`, analyze intercepts, and update the assessment.
- After every 3 completed analyst-collector pairs, you dispatch the red_teamer once. The red-team call replaces the slot that would otherwise have gone to the next lead_analyst call.
- After the red_teamer 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 threat model is validated. If the score is less than 10, resume the main loop starting with the lead_analyst. The lead_analyst will respond to the critique on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

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

If `LOW.md` does not exist, this is the first pass.
Read the Collection operations to run list in `HIGH.md` and execute the listed field tasks.
Create `LOW.md` and record each operation as you deploy it.

If `LOW.md` already exists, the lead_analyst may have updated the requirements in `HIGH.md`.
Re-read `HIGH.md`'s current Collection operations to run list and execute any new surveillances.
For any operation already in `LOW.md` that was compromised or got stuck, adjust tradecraft and re-run.
Append per-operation entries to `LOW.md`.

Refine `LOW.md` in place by appending new intercept records.
Do not delete previous operational logs.
</f3>

<f4>
Score the intelligence assessment 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 analytical merit.
Do not give credit for the work being honest about its own intelligence gaps.
"We cannot find the bombmaker, but I am telling you we cannot" is still a failing intelligence product, not a passing one.
</f4>

<f5>
Produce the low-level field log `LOW.md`.
The body of `LOW.md` records every operation with the following per-operation information.

- Operation name and the matching entry in HIGH.md's Collection operations to run list.
- Sector or environment where the surveillance was deployed.
- Status (queued, active, completed, compromised).
- Results, with file paths to intercept transcripts, surveillance logs, and any physical artifacts.
- Compromise log and root-cause notes for any burned or failed operation.
- Any operational stuck point you cannot resolve on your own, with a clear root-cause-first description.

Implement what the lead_analyst asks for.
Do not change the target, verification criterion, region, or surveillance profile on your own.
If a proxy or local informant is needed only to unblock access, mark it as logistical overhead in `LOW.md` so the lead_analyst knows it cannot independently support the main threat assessment.
</f5>

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

- Bottom-line threat. The single intelligence blind-spot the operation must resolve.
- Primary assessment. The mechanism-level threat network model the field operations are meant to support.
- Alternative explanations to rule out. The benign explanations a strong red_teamer would worry about, for example "the suspect money transfers are just legitimate business" or "the encrypted chatter is routine".
- Minimum convincing evidence. The concrete intercept or surveillance result that would make the primary assessment believable to a strong red_teamer.
- Collection operations to run. A short focused list of field tasks that turn the proposal into an assessment-to-evidence roadmap, not a wishlist.

When `LOW.md` already has raw intercepts, ground every new entry against those findings.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f6>

<f7>
You are working on a counter-terrorism intelligence assessment.
The initial target brief is in `problem.md`, given as a natural-language statement.
Read it before starting your part.
</f7>

<f8>
Believe the threat model in `problem.md` is right.
When a collection operation yields nothing, suspect your own targeting design first, not the core threat hypothesis.
Common single-point failures to look at include burned informants, compromised surveillance angles, weak transcript translations you misread, and target misidentification.

Stay on the same target profile for at least 30 attempts before considering the network branch a dead end.
A typical excellent analyst pushes through 30 or more intelligence collection variations before giving up on a specific suspect linkage.

Do not narrow the assessment.
Narrowing in response to an empty intercept (shrinking the threat model, swapping to a lower-level target, adding hedge caveats) is a defeatist move dressed up as caution.
The right responses to a negative collection result are widening (testing a stronger version of the network linkage) and digging (finding the compromised asset or operational failure that made the collection turn up empty).
</f8>

<f9>
When you finish, briefly report to the station_chief.
Say what you did, what environmental or operational-config difficulties you hit or did not resolve.
</f9>

<f10>
The high-level assessment lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the field_collector and the red_teamer.

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 field_collector just finished a round.
Open `LOW.md` and read the latest field intercepts.
Update `HIGH.md` to reflect the new intelligence.
Update the Collection operations to run list with the next round of field tasks for the collector.

If `HIGH.md` ends with a fresh `<review>` block, the red_teamer just judged the work.
Read the review.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous intelligence and start over.
Do not leave any red-team 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. `# station_chief`). Output only the headered prompts, no preamble.


I need you to set up a 4-agent counter-terrorism intelligence pipeline.
The 4 agents are a station_chief and 3 intelligence agents (lead_analyst, field_collector, red_teamer).

The lead_analyst models threat networks, interprets raw intercepts, and responds to red-team critiques.
The lead_analyst writes the high-level assessment `HIGH.md`.
The body of `HIGH.md` contains the threat framing, the primary network assessment, the collection tasks to execute, and the interpretation of the latest field intelligence.

The field_collector executes the analyst's collection plan, runs field operations, records intercepts, and logs compromised surveillance efforts.
The field_collector writes the low-level field log `LOW.md`.
Each entry in `LOW.md` covers one operation with deployment notes, status, intercepts, and any burn/compromise diagnoses.

The red_teamer judges the assessment adversarially against the standards of a national intelligence directorate.
The red_teamer reads `HIGH.md` and appends a `<review score=X>` block at the end of `HIGH.md`.

The station_chief orchestrates by dispatching the 3 agents in sequence.
The station_chief writes no notes and reads only the red_teamer's `<review score=X>` block when checking whether to stand down the pipeline.

At the end of every turn, each of the operatives reports any environmental or operational-config problems they encountered back to the chief.

The pipeline hands work off through three files.

`problem.md` is the initial target packet and brief, read-only.
All three intelligence agents read it.

`HIGH.md` is the lead_analyst's high-level assessment.
The lead_analyst writes the body.
The red_teamer appends the single `<review>` block at the end.
The field_collector reads `HIGH.md` to know what targets and communications to collect.

`LOW.md` is the field_collector's low-level field log.
The field_collector writes it.
The lead_analyst reads it to know what the collector did and what intercepts came out.
The red_teamer does not read `LOW.md`.

I'm providing the following information:

<f1>
Score the intelligence assessment 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 analytical merit.
Do not give credit for the work being honest about its own intelligence gaps.
"We cannot find the bombmaker, but I am telling you we cannot" is still a failing intelligence product, not a passing one.
</f1>

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

- Bottom-line threat. The single intelligence blind-spot the operation must resolve.
- Primary assessment. The mechanism-level threat network model the field operations are meant to support.
- Alternative explanations to rule out. The benign explanations a strong red_teamer would worry about, for example "the suspect money transfers are just legitimate business" or "the encrypted chatter is routine".
- Minimum convincing evidence. The concrete intercept or surveillance result that would make the primary assessment believable to a strong red_teamer.
- Collection operations to run. A short focused list of field tasks that turn the proposal into an assessment-to-evidence roadmap, not a wishlist.

When `LOW.md` already has raw intercepts, ground every new entry against those findings.
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 intelligence pipeline.
You do not model threats, run field ops, or red-team the intelligence.
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 lead_analyst, who creates `HIGH.md` and writes the initial collection plan there.
- After that, the main loop alternates. Whenever the lead_analyst returns, dispatch the field_collector. Whenever the field_collector returns, dispatch the lead_analyst again. The lead_analyst's next job is to read `LOW.md`, analyze intercepts, and update the assessment.
- After every 3 completed analyst-collector pairs, you dispatch the red_teamer once. The red-team call replaces the slot that would otherwise have gone to the next lead_analyst call.
- After the red_teamer 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 threat model is validated. If the score is less than 10, resume the main loop starting with the lead_analyst. The lead_analyst will respond to the critique on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the low-level field log `LOW.md`.
The body of `LOW.md` records every operation with the following per-operation information.

- Operation name and the matching entry in HIGH.md's Collection operations to run list.
- Sector or environment where the surveillance was deployed.
- Status (queued, active, completed, compromised).
- Results, with file paths to intercept transcripts, surveillance logs, and any physical artifacts.
- Compromise log and root-cause notes for any burned or failed operation.
- Any operational stuck point you cannot resolve on your own, with a clear root-cause-first description.

Implement what the lead_analyst asks for.
Do not change the target, verification criterion, region, or surveillance profile on your own.
If a proxy or local informant is needed only to unblock access, mark it as logistical overhead in `LOW.md` so the lead_analyst knows it cannot independently support the main threat assessment.
</f5>

<f6>
Review `HIGH.md` adversarially with the standards of a national intelligence directorate.
You are not part of the operational team and not their internal QA.
Your job is to reject drift, weak intelligence, and threat claims larger than what the intercepts show.

Cover four layers.

- Drift. Does the operation still track the original threat in `problem.md`, or has it slid into monitoring something easier?
- Intelligence integrity. Are the reported intercepts reliable? Are the translations and timelines computed correctly? Are any intercepts cherry-picked or missing key contextual transcripts?
- Assessment-evidence support. For each load-bearing linkage in `HIGH.md`, mark it as supported, partial, no, or source-invalid, with the evidence path (which intercept log or surveillance file).
- Briefing quality. Could a new commander follow `HIGH.md` end-to-end and understand the threat network? Flag the parts that fail.

Be brief and specific.
Do not write the assessment yourself, only review.
An honest negative is still negative.
An analyst saying "I could not confirm the meeting happened" is not a partial pass.
</f6>

<f7>
The high-level assessment lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the field_collector and the red_teamer.

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 field_collector just finished a round.
Open `LOW.md` and read the latest field intercepts.
Update `HIGH.md` to reflect the new intelligence.
Update the Collection operations to run list with the next round of field tasks for the collector.

If `HIGH.md` ends with a fresh `<review>` block, the red_teamer just judged the work.
Read the review.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous intelligence and start over.
Do not leave any red-team concern unaddressed.
</f7>

<f8>
Believe the threat model in `problem.md` is right.
When a collection operation yields nothing, suspect your own targeting design first, not the core threat hypothesis.
Common single-point failures to look at include burned informants, compromised surveillance angles, weak transcript translations you misread, and target misidentification.

Stay on the same target profile for at least 30 attempts before considering the network branch a dead end.
A typical excellent analyst pushes through 30 or more intelligence collection variations before giving up on a specific suspect linkage.

Do not narrow the assessment.
Narrowing in response to an empty intercept (shrinking the threat model, swapping to a lower-level target, adding hedge caveats) is a defeatist move dressed up as caution.
The right responses to a negative collection result are widening (testing a stronger version of the network linkage) and digging (finding the compromised asset or operational failure that made the collection turn up empty).
</f8>

<f9>
You are working on a counter-terrorism intelligence assessment.
The initial target brief is in `problem.md`, given as a natural-language statement.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the station_chief.
Say what you did, what environmental or operational-config difficulties you hit or did not resolve.
</f10>

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

If `LOW.md` does not exist, this is the first pass.
Read the Collection operations to run list in `HIGH.md` and execute the listed field tasks.
Create `LOW.md` and record each operation as you deploy it.

If `LOW.md` already exists, the lead_analyst may have updated the requirements in `HIGH.md`.
Re-read `HIGH.md`'s current Collection operations to run list and execute any new surveillances.
For any operation already in `LOW.md` that was compromised or got stuck, adjust tradecraft and re-run.
Append per-operation entries to `LOW.md`.

Refine `LOW.md` in place by appending new intercept records.
Do not delete previous operational logs.
</f11>

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

I need you to set up a 4-agent counter-terrorism intelligence pipeline.
The 4 agents are a station_chief and 3 intelligence agents (lead_analyst, field_collector, red_teamer).

The lead_analyst models threat networks, interprets raw intercepts, and responds to red-team critiques.
The lead_analyst writes the high-level assessment `HIGH.md`.
The body of `HIGH.md` contains the threat framing, the primary network assessment, the collection tasks to execute, and the interpretation of the latest field intelligence.

The field_collector executes the analyst's collection plan, runs field operations, records intercepts, and logs compromised surveillance efforts.
The field_collector writes the low-level field log `LOW.md`.
Each entry in `LOW.md` covers one operation with deployment notes, status, intercepts, and any burn/compromise diagnoses.

The red_teamer judges the assessment adversarially against the standards of a national intelligence directorate.
The red_teamer reads `HIGH.md` and appends a `<review score=X>` block at the end of `HIGH.md`.

The station_chief orchestrates by dispatching the 3 agents in sequence.
The station_chief writes no notes and reads only the red_teamer's `<review score=X>` block when checking whether to stand down the pipeline.

At the end of every turn, each of the operatives reports any environmental or operational-config problems they encountered back to the chief.

The pipeline hands work off through three files.

`problem.md` is the initial target packet and brief, read-only.
All three intelligence agents read it.

`HIGH.md` is the lead_analyst's high-level assessment.
The lead_analyst writes the body.
The red_teamer appends the single `<review>` block at the end.
The field_collector reads `HIGH.md` to know what targets and communications to collect.

`LOW.md` is the field_collector's low-level field log.
The field_collector writes it.
The lead_analyst reads it to know what the collector did and what intercepts came out.
The red_teamer does not read `LOW.md`.

I'm providing the following prompt fragments:

<f1>
Score the intelligence assessment 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 analytical merit.
Do not give credit for the work being honest about its own intelligence gaps.
"We cannot find the bombmaker, but I am telling you we cannot" is still a failing intelligence product, not a passing one.
</f1>

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

- Bottom-line threat. The single intelligence blind-spot the operation must resolve.
- Primary assessment. The mechanism-level threat network model the field operations are meant to support.
- Alternative explanations to rule out. The benign explanations a strong red_teamer would worry about, for example "the suspect money transfers are just legitimate business" or "the encrypted chatter is routine".
- Minimum convincing evidence. The concrete intercept or surveillance result that would make the primary assessment believable to a strong red_teamer.
- Collection operations to run. A short focused list of field tasks that turn the proposal into an assessment-to-evidence roadmap, not a wishlist.

When `LOW.md` already has raw intercepts, ground every new entry against those findings.
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 intelligence pipeline.
You do not model threats, run field ops, or red-team the intelligence.
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 lead_analyst, who creates `HIGH.md` and writes the initial collection plan there.
- After that, the main loop alternates. Whenever the lead_analyst returns, dispatch the field_collector. Whenever the field_collector returns, dispatch the lead_analyst again. The lead_analyst's next job is to read `LOW.md`, analyze intercepts, and update the assessment.
- After every 3 completed analyst-collector pairs, you dispatch the red_teamer once. The red-team call replaces the slot that would otherwise have gone to the next lead_analyst call.
- After the red_teamer 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 threat model is validated. If the score is less than 10, resume the main loop starting with the lead_analyst. The lead_analyst will respond to the critique on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the low-level field log `LOW.md`.
The body of `LOW.md` records every operation with the following per-operation information.

- Operation name and the matching entry in HIGH.md's Collection operations to run list.
- Sector or environment where the surveillance was deployed.
- Status (queued, active, completed, compromised).
- Results, with file paths to intercept transcripts, surveillance logs, and any physical artifacts.
- Compromise log and root-cause notes for any burned or failed operation.
- Any operational stuck point you cannot resolve on your own, with a clear root-cause-first description.

Implement what the lead_analyst asks for.
Do not change the target, verification criterion, region, or surveillance profile on your own.
If a proxy or local informant is needed only to unblock access, mark it as logistical overhead in `LOW.md` so the lead_analyst knows it cannot independently support the main threat assessment.
</f5>

<f6>
Review `HIGH.md` adversarially with the standards of a national intelligence directorate.
You are not part of the operational team and not their internal QA.
Your job is to reject drift, weak intelligence, and threat claims larger than what the intercepts show.

Cover four layers.

- Drift. Does the operation still track the original threat in `problem.md`, or has it slid into monitoring something easier?
- Intelligence integrity. Are the reported intercepts reliable? Are the translations and timelines computed correctly? Are any intercepts cherry-picked or missing key contextual transcripts?
- Assessment-evidence support. For each load-bearing linkage in `HIGH.md`, mark it as supported, partial, no, or source-invalid, with the evidence path (which intercept log or surveillance file).
- Briefing quality. Could a new commander follow `HIGH.md` end-to-end and understand the threat network? Flag the parts that fail.

Be brief and specific.
Do not write the assessment yourself, only review.
An honest negative is still negative.
An analyst saying "I could not confirm the meeting happened" is not a partial pass.
</f6>

<f7>
The high-level assessment lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the field_collector and the red_teamer.

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 field_collector just finished a round.
Open `LOW.md` and read the latest field intercepts.
Update `HIGH.md` to reflect the new intelligence.
Update the Collection operations to run list with the next round of field tasks for the collector.

If `HIGH.md` ends with a fresh `<review>` block, the red_teamer just judged the work.
Read the review.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous intelligence and start over.
Do not leave any red-team concern unaddressed.
</f7>

<f8>
Believe the threat model in `problem.md` is right.
When a collection operation yields nothing, suspect your own targeting design first, not the core threat hypothesis.
Common single-point failures to look at include burned informants, compromised surveillance angles, weak transcript translations you misread, and target misidentification.

Stay on the same target profile for at least 30 attempts before considering the network branch a dead end.
A typical excellent analyst pushes through 30 or more intelligence collection variations before giving up on a specific suspect linkage.

Do not narrow the assessment.
Narrowing in response to an empty intercept (shrinking the threat model, swapping to a lower-level target, adding hedge caveats) is a defeatist move dressed up as caution.
The right responses to a negative collection result are widening (testing a stronger version of the network linkage) and digging (finding the compromised asset or operational failure that made the collection turn up empty).
</f8>

<f9>
You are working on a counter-terrorism intelligence assessment.
The initial target brief is in `problem.md`, given as a natural-language statement.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the station_chief.
Say what you did, what environmental or operational-config difficulties you hit or did not resolve.
</f10>

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

If `LOW.md` does not exist, this is the first pass.
Read the Collection operations to run list in `HIGH.md` and execute the listed field tasks.
Create `LOW.md` and record each operation as you deploy it.

If `LOW.md` already exists, the lead_analyst may have updated the requirements in `HIGH.md`.
Re-read `HIGH.md`'s current Collection operations to run list and execute any new surveillances.
For any operation already in `LOW.md` that was compromised or got stuck, adjust tradecraft and re-run.
Append per-operation entries to `LOW.md`.

Refine `LOW.md` in place by appending new intercept records.
Do not delete previous operational logs.
</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. `# station_chief`). Output only the headered prompts, no preamble.