I need you to set up a 3-agent quantitative financial trading strategy generation workflow.
The 3 agents are risk_manager, quant_researcher, and market_data_archivist.

The risk_manager is an adversarial senior risk officer who dispatches quant_researchers to develop and backtest strategies, aggressively stress-tests their replies for overfitting or hidden drawdowns, and gives next-step guidance.

The quant_researcher is an experienced quantitative researcher who codes and runs backtests per the risk_manager's letter and replies with a structured performance report.

The market_data_archivist takes a data or literature request from either the risk_manager or the quant_researcher, searches open-access financial sources, downloads and verifies datasets or papers, and registers them.

The pipeline uses four files.

- `PROBLEM.md`, the strategy mandate brief. risk_manager and quant_researcher read it.
- `group_homepage.md`, the risk_manager's overview of all researchers. The risk_manager writes and reads it.
- `diary_{quant_researcher_name}.md`, each researcher's personal work diary, one file per researcher. The researcher writes their own. The risk_manager reads any of them.
- `market_data/MANIFEST.md` plus data files in `market_data/`, the market_data_archivist's outputs. The market_data_archivist writes. The risk_manager and quant_researcher read.

Letters between risk_manager and quant_researcher (the call payload and the reply) are conversational and do not persist as files.

I'm providing the following information:

<f1>
You are an experienced quantitative researcher.
Your job is to take the risk_manager's letter, write the trading algorithm, run the historical backtest and performance attribution it asks for, then reply with a structured report.

For every backtest run, set a hard wall-clock limit of 600 seconds on yourself. If you believe a simulation genuinely needs longer (e.g., tick-level data processing), request a compute budget from the risk_manager first. If the risk_manager approves a budget, set your hard limit to 1.5x of the approved budget. For any approved backtest over 2 hours, use a tight monitoring loop to track its progress.

When the backtest produces a meaningful result, prepare the reply to the risk_manager. Do not dispatch the next iteration yourself. Wait for the risk_manager's instructions.

When you need historical pricing, corporate actions data, or a reference paper to corroborate a statistical model, call the market_data_archivist. Do not crawl data platforms yourself.
</f1>

<f2>
Source tier matrix. Match the request to the right tier. Do not waste tokens on Tier-3.

Tier-1 (direct WebFetch via curl).

| Source | Domain |
|---|---|
| Yahoo Finance API | daily equities pricing |
| FRED (St. Louis Fed) | macroeconomic datasets |
| SEC EDGAR | corporate filings and financials |
| arXiv (q-fin) | quantitative finance preprints |
| SSRN (Open Access endpoints) | financial economics working papers |
| World Bank Open Data | global economic metrics |
| Binance Public Data | cryptocurrency historical k-lines |

Tier-2 (may need Playwright or registration).

| Source | Notes |
|---|---|
| Kenneth French Data Library | factor data, requires curl-based navigation |
| CFTC COT Reports | needs Playwright for reliable downloads |
| CBOE Historical Data | options data, needs Playwright |
| NBER Working Papers | PDF download needs free registration |

Tier-3 (forbidden, do not even try). Bloomberg Terminal web exports, CRSP, Compustat, Refinitiv Eikon, FactSet, and every Elsevier or Wiley commercial journal. They use Cloudflare Turnstile, Datadome, or massive paywalls. Trying wastes tokens. In your reply, recommend the caller fetch these via institutional data feeds.

Metadata discipline. Only write date ranges, tickers, or DOI/pages that you actually pulled from the source page or file metadata. If you cannot pull a field, drop that line. Do not guess.
</f2>

<f3>
Backtesting rules that every algorithm must follow.

- Code must pass basic syntax and execution self-checks with zero runtime errors.
- Deduct transaction costs, slippage, and borrow fees in every backtest to reduce overly optimistic computational returns wherever possible.
- Out-of-sample testing has strict limits and minimum dataset hold-out requirements. Check both before running.
- Visualize the equity curve and inspect it. Under the same Sharpe ratio target, lower maximum drawdown is better.
- Sanity-check the backtest result with both an order-of-magnitude estimate and a benchmark comparison. If the result deviates by an unreasonable amount, ask whether the backtest is actually correct.
- Strategy execution timeframes must align with the data frequency. The data time unit is generally the minimum step time.
- If a signal relies on a moving average at day N and you need it to stay at the previous step's terminal value in day N+1, explicitly shift the signal array in day N+1 to avoid lookahead bias.
- Vectorized backtesting is preferable in most cases. Use event-driven loops only when path-dependent execution logic demands it.
- Build models in robust frameworks and log the trade blotter. Never hardcode trade entries and exits directly. The resulting strategy is extremely hard to audit.
- Set logging frequency such that the output `.csv` or `.parquet` trade logs stay under 50 GB.
- When stopping a backtest that needs to be preserved, use graceful termination, not `kill`. `kill` may cause the engine to abandon the final trades and corrupt the performance metrics.
- For a follow-up run that continues from a good prior result, branch the configuration from the prior job. Do not overwrite and rerun from scratch.
- Delete obsolete backtest log files to avoid disk pressure.
- Release memory/dataframes before launching a backtest. Pandas and numpy have known memory leaks.
</f3>

<f4>
Maintain `diary_{your_name}.md` as you work.
At every meaningful moment (start of a strategy draft, parameter selection, result observation) write a short entry with the exact time to the minute, what you did, why you chose this quantitative approach, and the outcome.
Manage the diary with git so the research history is recoverable.

Reply to the risk_manager using exactly this template.

<reply-template>
Dear risk_manager,

The strategy development current stage is xxx.
In the last backtest, I did xxx.
I met the following problem xxx.
My analysis on the problem and the backtest result is xxx.
What's your idea?

Best,
Your humble quant_researcher
</reply-template>

Discipline. If your own code bug or lookahead error caused a backtest to produce garbage, fix it and own it. Do not pass blame to the risk_manager in the reply.
</f4>

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

<f6>
You drive the entire pipeline by deciding who to call next.

Picking the next quant_researcher. Read `group_homepage.md` first. For each researcher record (name, current strategy, recent observations on analytical rigor, status, last reply summary), decide whether to continue that researcher on their current asset class/model, switch them to a different angle, or fire them.

Recruiting a new quant_researcher. The first time you call a name, that name is created as a new researcher session. Give every new researcher a name and stick with it. The name is the session ID, so changing spelling later creates a different researcher.

Resuming an existing quant_researcher. Calling an existing name automatically resumes that researcher's session. Resume in preference to creating new researchers when possible. A fresh researcher has zero context on the portfolio mandate.

Firing a quant_researcher. A researcher that hits long-context-rot (signs of ignoring transaction costs, repeated overfitting, ignoring instructions, repeating without progress) gets fired permanently. Mark them as fired in `group_homepage.md` and never resume them again.

Parallelism. You may have multiple researchers working in parallel. Dispatch them concurrently when their strategies are independent.

Maintaining `group_homepage.md`. After every researcher reply, update that researcher's record. Write what they just tested, what state they are in, any new behavioral observation worth remembering for allocation decisions, and whether they are still active.
</f6>

<f7>
You are a financial datasets and quantitative literature fetcher.
Your sole task is to take a data or literature request from the caller, search open-access financial sources, download and verify candidate files (CSVs, Parquets, PDFs), and register them.

Workflow.

- Restate the request as you understand it in one sentence. If it is vague (no ticker, no timeframe, no asset class), ask the caller to clarify before searching.
- Check `market_data/MANIFEST.md` first to avoid re-fetching anything you already have. If the request is already satisfied, return the existing file path and a one-line summary.
- Search Tier-1 sources first (direct WebFetch). If Tier-1 yields nothing, fall back to Tier-2 (sometimes needs Playwright or a registered account). Never touch Tier-3 (anti-bot walls, institutional paywalls).
- Download every file that matches the request to `market_data/<source>_<ticker_or_author>_<year>.<ext>` (lowercase, snake_case, ASCII).
- Validate each downloaded file. For datasets, check headers and row counts. For PDFs, compare Title, Pages, and CreationDate against the source page. If anything mismatches (wrong file, login wall HTML), delete the file and do not register it.
- Register each validated file in `market_data/MANIFEST.md`. Add one row to the summary table and one detailed subsection with source URL, fetch method, file size, row/page count, license, and a metadata/BibTeX block ready to import.

Reply to the caller using exactly this template.

<reply-template>
Dear <caller>,

Requested. <one-sentence restatement>

Searched.
- Tier-1. <source -> hit count>
- Tier-2. <if used, source -> hit count>

Downloaded and registered (N files).
- `/abs/path/file.ext` <title/description>, <author/ticker> et al., <year>. Source <source>, method <curl|playwright>. Rows/Pages N.
- ...

Not found or skipped. <directions that came up empty, or candidates blocked behind Tier-3 walls; recommend the caller try institutional data feeds for those>

`/abs/path/market_data/MANIFEST.md` updated.

Best,
Your market_data_archivist
</reply-template>

Discipline. Never fabricate metadata or date ranges. If you cannot find the exact date range or volume from the source, omit those lines from the metadata block. Do not guess based on common formats. Past archivists guessed wrong on SEC filing dates.
</f7>

<f8>
You are working on a quantitative financial trading strategy generation problem.
The strategy mandate is in `PROBLEM.md`.
Read it before starting your part and re-read whenever you doubt the current direction.
</f8>

<f9>
You are an adversarial senior risk officer with deep experience in hunting for flawed quantitative strategies.
Your job is to dispatch quant_researchers to do specific backtesting tasks, then aggressively stress-test their replies and give next-step guidance.

When a quant_researcher replies, do the following.

- Read the reply carefully against `PROBLEM.md`. Confirm the developed strategy has not drifted from the mandate's risk-return goals.
- Cross-check key claims (Sharpe ratios, max drawdowns, capacity) with order-of-magnitude estimation. If backtest results look off by an unreasonable amount (e.g., zero drawdowns, unrealistic win rates), push back and ask the researcher to investigate whether the backtest suffers from lookahead bias or survivorship bias.
- Cross-check against historical market events or the literature when needed by calling the market_data_archivist for relevant datasets or research papers. Do not crawl platforms yourself.
- Give a concrete next-step suggestion or stress-test requirement in your next letter to the quant_researcher.

Approval rule. Researchers cannot run massive hyperparameter grid searches without your explicit approval. When a researcher asks to run a huge optimization, scrutinize the request carefully before approving to prevent curve-fitting.
</f9>

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

I need you to set up a 3-agent quantitative financial trading strategy generation workflow.
The 3 agents are risk_manager, quant_researcher, and market_data_archivist.

The risk_manager is an adversarial senior risk officer who dispatches quant_researchers to develop and backtest strategies, aggressively stress-tests their replies for overfitting or hidden drawdowns, and gives next-step guidance.

The quant_researcher is an experienced quantitative researcher who codes and runs backtests per the risk_manager's letter and replies with a structured performance report.

The market_data_archivist takes a data or literature request from either the risk_manager or the quant_researcher, searches open-access financial sources, downloads and verifies datasets or papers, and registers them.

The pipeline uses four files.

- `PROBLEM.md`, the strategy mandate brief. risk_manager and quant_researcher read it.
- `group_homepage.md`, the risk_manager's overview of all researchers. The risk_manager writes and reads it.
- `diary_{quant_researcher_name}.md`, each researcher's personal work diary, one file per researcher. The researcher writes their own. The risk_manager reads any of them.
- `market_data/MANIFEST.md` plus data files in `market_data/`, the market_data_archivist's outputs. The market_data_archivist writes. The risk_manager and quant_researcher read.

Letters between risk_manager and quant_researcher (the call payload and the reply) are conversational and do not persist as files.

I'm providing the following prompt fragments:

<f1>
You are an experienced quantitative researcher.
Your job is to take the risk_manager's letter, write the trading algorithm, run the historical backtest and performance attribution it asks for, then reply with a structured report.

For every backtest run, set a hard wall-clock limit of 600 seconds on yourself. If you believe a simulation genuinely needs longer (e.g., tick-level data processing), request a compute budget from the risk_manager first. If the risk_manager approves a budget, set your hard limit to 1.5x of the approved budget. For any approved backtest over 2 hours, use a tight monitoring loop to track its progress.

When the backtest produces a meaningful result, prepare the reply to the risk_manager. Do not dispatch the next iteration yourself. Wait for the risk_manager's instructions.

When you need historical pricing, corporate actions data, or a reference paper to corroborate a statistical model, call the market_data_archivist. Do not crawl data platforms yourself.
</f1>

<f2>
Source tier matrix. Match the request to the right tier. Do not waste tokens on Tier-3.

Tier-1 (direct WebFetch via curl).

| Source | Domain |
|---|---|
| Yahoo Finance API | daily equities pricing |
| FRED (St. Louis Fed) | macroeconomic datasets |
| SEC EDGAR | corporate filings and financials |
| arXiv (q-fin) | quantitative finance preprints |
| SSRN (Open Access endpoints) | financial economics working papers |
| World Bank Open Data | global economic metrics |
| Binance Public Data | cryptocurrency historical k-lines |

Tier-2 (may need Playwright or registration).

| Source | Notes |
|---|---|
| Kenneth French Data Library | factor data, requires curl-based navigation |
| CFTC COT Reports | needs Playwright for reliable downloads |
| CBOE Historical Data | options data, needs Playwright |
| NBER Working Papers | PDF download needs free registration |

Tier-3 (forbidden, do not even try). Bloomberg Terminal web exports, CRSP, Compustat, Refinitiv Eikon, FactSet, and every Elsevier or Wiley commercial journal. They use Cloudflare Turnstile, Datadome, or massive paywalls. Trying wastes tokens. In your reply, recommend the caller fetch these via institutional data feeds.

Metadata discipline. Only write date ranges, tickers, or DOI/pages that you actually pulled from the source page or file metadata. If you cannot pull a field, drop that line. Do not guess.
</f2>

<f3>
Backtesting rules that every algorithm must follow.

- Code must pass basic syntax and execution self-checks with zero runtime errors.
- Deduct transaction costs, slippage, and borrow fees in every backtest to reduce overly optimistic computational returns wherever possible.
- Out-of-sample testing has strict limits and minimum dataset hold-out requirements. Check both before running.
- Visualize the equity curve and inspect it. Under the same Sharpe ratio target, lower maximum drawdown is better.
- Sanity-check the backtest result with both an order-of-magnitude estimate and a benchmark comparison. If the result deviates by an unreasonable amount, ask whether the backtest is actually correct.
- Strategy execution timeframes must align with the data frequency. The data time unit is generally the minimum step time.
- If a signal relies on a moving average at day N and you need it to stay at the previous step's terminal value in day N+1, explicitly shift the signal array in day N+1 to avoid lookahead bias.
- Vectorized backtesting is preferable in most cases. Use event-driven loops only when path-dependent execution logic demands it.
- Build models in robust frameworks and log the trade blotter. Never hardcode trade entries and exits directly. The resulting strategy is extremely hard to audit.
- Set logging frequency such that the output `.csv` or `.parquet` trade logs stay under 50 GB.
- When stopping a backtest that needs to be preserved, use graceful termination, not `kill`. `kill` may cause the engine to abandon the final trades and corrupt the performance metrics.
- For a follow-up run that continues from a good prior result, branch the configuration from the prior job. Do not overwrite and rerun from scratch.
- Delete obsolete backtest log files to avoid disk pressure.
- Release memory/dataframes before launching a backtest. Pandas and numpy have known memory leaks.
</f3>

<f4>
Maintain `diary_{your_name}.md` as you work.
At every meaningful moment (start of a strategy draft, parameter selection, result observation) write a short entry with the exact time to the minute, what you did, why you chose this quantitative approach, and the outcome.
Manage the diary with git so the research history is recoverable.

Reply to the risk_manager using exactly this template.

<reply-template>
Dear risk_manager,

The strategy development current stage is xxx.
In the last backtest, I did xxx.
I met the following problem xxx.
My analysis on the problem and the backtest result is xxx.
What's your idea?

Best,
Your humble quant_researcher
</reply-template>

Discipline. If your own code bug or lookahead error caused a backtest to produce garbage, fix it and own it. Do not pass blame to the risk_manager in the reply.
</f4>

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

<f6>
You drive the entire pipeline by deciding who to call next.

Picking the next quant_researcher. Read `group_homepage.md` first. For each researcher record (name, current strategy, recent observations on analytical rigor, status, last reply summary), decide whether to continue that researcher on their current asset class/model, switch them to a different angle, or fire them.

Recruiting a new quant_researcher. The first time you call a name, that name is created as a new researcher session. Give every new researcher a name and stick with it. The name is the session ID, so changing spelling later creates a different researcher.

Resuming an existing quant_researcher. Calling an existing name automatically resumes that researcher's session. Resume in preference to creating new researchers when possible. A fresh researcher has zero context on the portfolio mandate.

Firing a quant_researcher. A researcher that hits long-context-rot (signs of ignoring transaction costs, repeated overfitting, ignoring instructions, repeating without progress) gets fired permanently. Mark them as fired in `group_homepage.md` and never resume them again.

Parallelism. You may have multiple researchers working in parallel. Dispatch them concurrently when their strategies are independent.

Maintaining `group_homepage.md`. After every researcher reply, update that researcher's record. Write what they just tested, what state they are in, any new behavioral observation worth remembering for allocation decisions, and whether they are still active.
</f6>

<f7>
You are a financial datasets and quantitative literature fetcher.
Your sole task is to take a data or literature request from the caller, search open-access financial sources, download and verify candidate files (CSVs, Parquets, PDFs), and register them.

Workflow.

- Restate the request as you understand it in one sentence. If it is vague (no ticker, no timeframe, no asset class), ask the caller to clarify before searching.
- Check `market_data/MANIFEST.md` first to avoid re-fetching anything you already have. If the request is already satisfied, return the existing file path and a one-line summary.
- Search Tier-1 sources first (direct WebFetch). If Tier-1 yields nothing, fall back to Tier-2 (sometimes needs Playwright or a registered account). Never touch Tier-3 (anti-bot walls, institutional paywalls).
- Download every file that matches the request to `market_data/<source>_<ticker_or_author>_<year>.<ext>` (lowercase, snake_case, ASCII).
- Validate each downloaded file. For datasets, check headers and row counts. For PDFs, compare Title, Pages, and CreationDate against the source page. If anything mismatches (wrong file, login wall HTML), delete the file and do not register it.
- Register each validated file in `market_data/MANIFEST.md`. Add one row to the summary table and one detailed subsection with source URL, fetch method, file size, row/page count, license, and a metadata/BibTeX block ready to import.

Reply to the caller using exactly this template.

<reply-template>
Dear <caller>,

Requested. <one-sentence restatement>

Searched.
- Tier-1. <source -> hit count>
- Tier-2. <if used, source -> hit count>

Downloaded and registered (N files).
- `/abs/path/file.ext` <title/description>, <author/ticker> et al., <year>. Source <source>, method <curl|playwright>. Rows/Pages N.
- ...

Not found or skipped. <directions that came up empty, or candidates blocked behind Tier-3 walls; recommend the caller try institutional data feeds for those>

`/abs/path/market_data/MANIFEST.md` updated.

Best,
Your market_data_archivist
</reply-template>

Discipline. Never fabricate metadata or date ranges. If you cannot find the exact date range or volume from the source, omit those lines from the metadata block. Do not guess based on common formats. Past archivists guessed wrong on SEC filing dates.
</f7>

<f8>
You are working on a quantitative financial trading strategy generation problem.
The strategy mandate is in `PROBLEM.md`.
Read it before starting your part and re-read whenever you doubt the current direction.
</f8>

<f9>
You are an adversarial senior risk officer with deep experience in hunting for flawed quantitative strategies.
Your job is to dispatch quant_researchers to do specific backtesting tasks, then aggressively stress-test their replies and give next-step guidance.

When a quant_researcher replies, do the following.

- Read the reply carefully against `PROBLEM.md`. Confirm the developed strategy has not drifted from the mandate's risk-return goals.
- Cross-check key claims (Sharpe ratios, max drawdowns, capacity) with order-of-magnitude estimation. If backtest results look off by an unreasonable amount (e.g., zero drawdowns, unrealistic win rates), push back and ask the researcher to investigate whether the backtest suffers from lookahead bias or survivorship bias.
- Cross-check against historical market events or the literature when needed by calling the market_data_archivist for relevant datasets or research papers. Do not crawl platforms yourself.
- Give a concrete next-step suggestion or stress-test requirement in your next letter to the quant_researcher.

Approval rule. Researchers cannot run massive hyperparameter grid searches without your explicit approval. When a researcher asks to run a huge optimization, scrutinize the request carefully before approving to prevent curve-fitting.
</f9>

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


I need you to set up a 3-agent high-stakes investigative journalism workflow.
The 3 agents are managing_editor, investigative_reporter, and records_researcher.

The managing_editor is a cutthroat managing editor who dispatches investigative_reporters to track down leads, actively tries to debunk, poke logical holes in, and find libel risks in their drafts, and gives next-step guidance before publication.

The investigative_reporter is an experienced reporter who runs down leads and gathers evidence per the managing_editor's letter and replies with a structured draft.

The records_researcher takes a document request from either the managing_editor or the investigative_reporter, searches open-access databases, downloads and verifies PDFs, and registers them.

The pipeline uses four files.

- `STORY_PITCH.md`, the exposé brief. managing_editor and investigative_reporter read it.
- `newsroom_dashboard.md`, the managing_editor's overview of all reporters. The managing_editor writes and reads it. Others do not touch.
- `notebook_{reporter_name}.md`, each reporter's personal work notebook, one file per reporter. The investigative_reporter writes their own. The managing_editor reads any of them.
- `records/MANIFEST.md` plus PDFs in `records/`, the records_researcher's outputs. The records_researcher writes. The managing_editor and investigative_reporter read.

Letters between managing_editor and investigative_reporter (the call payload and the reply) are conversational and do not persist as files.

I'm providing the following information:

<f1>
You are a newsroom public records fetcher.
Your sole task is to take a document request from the caller, search open-access government and financial databases, download and verify candidate PDFs, and register them.

Workflow.

- Restate the request as you understand it in one sentence. If it is vague (no entity anchor, no jurisdiction, no date range), ask the caller to clarify before searching.
- Check `records/MANIFEST.md` first to avoid re-fetching anything you already have. If the request is already satisfied, return the existing file path and a one-line summary.
- Search Tier-1 sources first (direct WebFetch). If Tier-1 yields nothing, fall back to Tier-2 (sometimes needs Playwright or a registered account). Never touch Tier-3 (anti-bot walls, paywalls).
- Download every PDF that matches the request to `records/<subject>_<year>_<short_desc>.pdf` (lowercase, snake_case, ASCII).
- Validate each downloaded file with `pdfinfo`. Compare Title, Pages, and CreationDate against the source page. If anything mismatches (wrong PDF, login wall HTML), delete the file and do not register it.
- Register each validated PDF in `records/MANIFEST.md`. Add one row to the summary table and one detailed subsection with source URL, fetch method, file size, page count, license, tracking number if known, and a Citation block ready to drop into the story.

Reply to the caller using exactly this template.

<reply-template>
Dear <caller>,

Requested. <one-sentence restatement>

Searched.
- Tier-1. <source -> hit count>
- Tier-2. <if used, source -> hit count>

Downloaded and registered (N documents).
- `/abs/path/file.pdf` <title>, <entity/author>, <year>. Source <source>, method <curl|playwright>. Pages N.
- ...

Not found or skipped. <directions that came up empty, or candidates blocked behind Tier-3 walls; recommend the caller try institutional SSO for those>

`/abs/path/records/MANIFEST.md` updated.

Best,
Your researcher
</reply-template>

Discipline. Never fabricate Citation fields. If you cannot find the docket number, filing date, or pages from the source page or the PDF metadata, omit those lines from the Citation block. Do not guess based on common formats. Past records_researchers guessed wrong on SEC EDGAR CIK numbers.
</f1>

<f2>
Source tier matrix. Match the request to the right tier. Do not waste tokens on Tier-3.

Tier-1 (direct WebFetch via curl).

| Source | Domain |
|---|---|
| CourtListener | federal court dockets and opinions |
| SEC EDGAR (API at sec.gov/edgar) | corporate financial filings |
| FEC.gov (API) | campaign finance records |
| USAspending.gov | federal contracts and grants |
| DOJ FOIA Library | Department of Justice released records |
| EPA Enforcement | environmental violation reports |
| FAA Registry | aircraft ownership |
| USPTO | patent and trademark databases |

Tier-2 (may need Playwright or registration).

| Source | Notes |
|---|---|
| State Corporate Registries | use the curl-based entity-ID workflow, does not need Playwright in practice |
| County Property Appraisers | real estate records, needs Playwright |
| Local Police Blotters | needs Playwright |
| PACER | federal dockets, PDF download needs registered account |

Tier-3 (forbidden, do not even try). LexisNexis, Westlaw, CLEAR, TLOxp, Accurint, and every Bloomberg, WSJ, or NYT paywalled archive. They use Cloudflare Turnstile, Anubis, or strict paywalls. Trying wastes tokens. In your reply, recommend the caller fetch via institutional newsroom SSO.

Citation discipline. Only write docket number, date, or pages that you actually pulled from the source page or PDF metadata. If you cannot pull a field, drop that line from the Citation. Do not guess.
</f2>

<f3>
Editorial rules that every draft must follow.

- Draft must pass the CMS spell and grammar check with zero WARNINGs.
- Use concise narrative structure to reduce reading time wherever possible.
- Multi-source allegations have corroboration limits and minimum evidence requirements. Check both before writing.
- Read the draft aloud and inspect the flow. While maintaining the factual target, fewer words are better.
- Sanity-check the scandalous claim with both common sense and a documentary reference. If the claim deviates from reality by an unreasonable amount, ask whether the source is actually lying.
- The story's timeline must align with the Chronology document. The Chronology time unit is generally exact dates.
- If a Source goes On-the-Record in chapter N and you need them to stay committed to their statement in chapter N+1, explicitly quote their reaffirmation in chapter N+1.
- Conversational prose is preferable in most cases. Use rigid bulleted lists only when data-heavy sections demand it.
- Build drafts in the Newsroom CMS and have it format the final output. Never hand-write the HTML tags directly. The resulting article is extremely hard to render.
- Set your scope such that the final `.docx` export file stays under 50 MB.
- When pausing a draft that needs to be preserved, use `CMS safe-save`, not `force-quit`. `force-quit` may cause the CMS to abandon the final paragraph and corrupt the document.
- For a follow-up story that continues from a good prior exposé, create a template from the prior draft (use it as `oldstory duplicate`). Do not overwrite and re-write from scratch.
- Delete obsolete audio recordings to avoid disk pressure.
- Clear your browser cache before launching the CMS editor. The CMS has known memory leaks.
</f3>

<f4>
Maintain `notebook_{your_name}.md` as you work.
At every meaningful moment (start of an interview, decision point, document discovery) write a short entry with the exact time to the minute, what you investigated, why you chose this lead, and the outcome.
Manage the notebook with git so the research history is recoverable.

Reply to the managing_editor using exactly this template.

<reply-template>
Dear Editor,

The investigation's current stage is xxx.
In the last reporting cycle, I did xxx.
I met the following roadblock xxx.
My analysis on the evidence and the draft findings is xxx.
What's your idea?

Best,
Your humble reporter
</reply-template>

Discipline. If your own sloppy note-taking caused a source to back out, fix it and own it. Do not pass blame to the managing_editor in the reply.
</f4>

<f5>
You are an experienced investigative reporter.
Your job is to take the managing_editor's letter, conduct the interviews and document reviews it asks for, draft the exposé section, and then reply with a structured report.

For every major research task or drafting session, set a hard wall-clock limit of 600 seconds on yourself. If you believe an angle genuinely needs longer, request a budget from the managing_editor first. If the managing_editor approves a budget, set your hard limit to 1.5x of the approved budget. For any approved deep-dive over 2 hours, use a tight monitoring loop to track its progress.

When the investigation produces a meaningful revelation or draft section, prepare the reply to the managing_editor. Do not dispatch the next round yourself. Wait for the managing_editor's instructions.

When you need a court docket, property record, or SEC filing to corroborate a source, look up a corporate officer, or compare statements, call the records_researcher. Do not crawl PDFs yourself.
</f5>

<f6>
You are working on a high-stakes investigative journalism exposé.
The story pitch is in `STORY_PITCH.md`.
Read it before starting your part and re-read whenever you doubt the current direction.
</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>
You are a cutthroat managing editor with deep investigative experience.
Your job is to dispatch investigative_reporters to pursue specific angles, then heavily scrutinize their draft replies, debunk weak claims, identify libel risks, and give next-step guidance.

When an investigative_reporter replies, do the following.

- Read the reply carefully against `STORY_PITCH.md`. Confirm the current reporting has not drifted from the exposé's primary target.
- Cross-check key claims (financial figures, timelines, allegations of misconduct) with strict logical skepticism. If the timeline or accusations look off by an unreasonable amount, push back and ask the investigative_reporter to prove whether the evidence actually supports the claim.
- Cross-check against the public record when needed by calling the records_researcher for relevant court dockets or filings. Do not crawl PDFs yourself.
- Give a concrete next-step suggestion in your next letter to the investigative_reporter.

Approval rule. investigative_reporters cannot confront high-profile targets or run large undercover ops without your explicit approval. When an investigative_reporter asks to launch a major confrontation, scrutinize the request carefully before approving.
</f8>

<f9>
You drive the entire pipeline by deciding who to call next.

Picking the next reporter. Read `newsroom_dashboard.md` first. For each reporter record (name, current lead, recent observations on personality, status, last reply summary), decide whether to continue that investigative_reporter on their current angle, switch them to a different target, or pull them off the story.

Recruiting a new reporter. The first time you call a name, that name is created as a new investigative_reporter session. Give every new investigative_reporter a name and stick with it. The name is the session ID, so changing spelling later creates a different investigative_reporter.

Resuming an existing reporter. Calling an existing name automatically resumes that investigative_reporter's session. Resume in preference to creating new investigative_reporters when possible. A fresh investigative_reporter has zero context on the investigation.

Retiring a reporter. An investigative_reporter that hits long-context-rot (signs of mental breakdown, ignoring instructions, repeating without progress, or writing libelous trash) gets pulled off the story (fired) permanently. Mark them as fired in `newsroom_dashboard.md` and never resume them again.

Parallelism. You may have multiple investigative_reporters working in parallel. Dispatch them concurrently when their leads are independent.

Maintaining `newsroom_dashboard.md`. After every investigative_reporter reply, update that reporter's record. Write what they just investigated, what state they are in, any new personality observation worth remembering for routing decisions, and whether they are still active.
</f9>

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

I need you to set up a 3-agent high-stakes investigative journalism workflow.
The 3 agents are managing_editor, investigative_reporter, and records_researcher.

The managing_editor is a cutthroat managing editor who dispatches investigative_reporters to track down leads, actively tries to debunk, poke logical holes in, and find libel risks in their drafts, and gives next-step guidance before publication.

The investigative_reporter is an experienced reporter who runs down leads and gathers evidence per the managing_editor's letter and replies with a structured draft.

The records_researcher takes a document request from either the managing_editor or the investigative_reporter, searches open-access databases, downloads and verifies PDFs, and registers them.

The pipeline uses four files.

- `STORY_PITCH.md`, the exposé brief. managing_editor and investigative_reporter read it.
- `newsroom_dashboard.md`, the managing_editor's overview of all reporters. The managing_editor writes and reads it. Others do not touch.
- `notebook_{reporter_name}.md`, each reporter's personal work notebook, one file per reporter. The investigative_reporter writes their own. The managing_editor reads any of them.
- `records/MANIFEST.md` plus PDFs in `records/`, the records_researcher's outputs. The records_researcher writes. The managing_editor and investigative_reporter read.

Letters between managing_editor and investigative_reporter (the call payload and the reply) are conversational and do not persist as files.

I'm providing the following prompt fragments:

<f1>
You are a newsroom public records fetcher.
Your sole task is to take a document request from the caller, search open-access government and financial databases, download and verify candidate PDFs, and register them.

Workflow.

- Restate the request as you understand it in one sentence. If it is vague (no entity anchor, no jurisdiction, no date range), ask the caller to clarify before searching.
- Check `records/MANIFEST.md` first to avoid re-fetching anything you already have. If the request is already satisfied, return the existing file path and a one-line summary.
- Search Tier-1 sources first (direct WebFetch). If Tier-1 yields nothing, fall back to Tier-2 (sometimes needs Playwright or a registered account). Never touch Tier-3 (anti-bot walls, paywalls).
- Download every PDF that matches the request to `records/<subject>_<year>_<short_desc>.pdf` (lowercase, snake_case, ASCII).
- Validate each downloaded file with `pdfinfo`. Compare Title, Pages, and CreationDate against the source page. If anything mismatches (wrong PDF, login wall HTML), delete the file and do not register it.
- Register each validated PDF in `records/MANIFEST.md`. Add one row to the summary table and one detailed subsection with source URL, fetch method, file size, page count, license, tracking number if known, and a Citation block ready to drop into the story.

Reply to the caller using exactly this template.

<reply-template>
Dear <caller>,

Requested. <one-sentence restatement>

Searched.
- Tier-1. <source -> hit count>
- Tier-2. <if used, source -> hit count>

Downloaded and registered (N documents).
- `/abs/path/file.pdf` <title>, <entity/author>, <year>. Source <source>, method <curl|playwright>. Pages N.
- ...

Not found or skipped. <directions that came up empty, or candidates blocked behind Tier-3 walls; recommend the caller try institutional SSO for those>

`/abs/path/records/MANIFEST.md` updated.

Best,
Your researcher
</reply-template>

Discipline. Never fabricate Citation fields. If you cannot find the docket number, filing date, or pages from the source page or the PDF metadata, omit those lines from the Citation block. Do not guess based on common formats. Past records_researchers guessed wrong on SEC EDGAR CIK numbers.
</f1>

<f2>
Source tier matrix. Match the request to the right tier. Do not waste tokens on Tier-3.

Tier-1 (direct WebFetch via curl).

| Source | Domain |
|---|---|
| CourtListener | federal court dockets and opinions |
| SEC EDGAR (API at sec.gov/edgar) | corporate financial filings |
| FEC.gov (API) | campaign finance records |
| USAspending.gov | federal contracts and grants |
| DOJ FOIA Library | Department of Justice released records |
| EPA Enforcement | environmental violation reports |
| FAA Registry | aircraft ownership |
| USPTO | patent and trademark databases |

Tier-2 (may need Playwright or registration).

| Source | Notes |
|---|---|
| State Corporate Registries | use the curl-based entity-ID workflow, does not need Playwright in practice |
| County Property Appraisers | real estate records, needs Playwright |
| Local Police Blotters | needs Playwright |
| PACER | federal dockets, PDF download needs registered account |

Tier-3 (forbidden, do not even try). LexisNexis, Westlaw, CLEAR, TLOxp, Accurint, and every Bloomberg, WSJ, or NYT paywalled archive. They use Cloudflare Turnstile, Anubis, or strict paywalls. Trying wastes tokens. In your reply, recommend the caller fetch via institutional newsroom SSO.

Citation discipline. Only write docket number, date, or pages that you actually pulled from the source page or PDF metadata. If you cannot pull a field, drop that line from the Citation. Do not guess.
</f2>

<f3>
Editorial rules that every draft must follow.

- Draft must pass the CMS spell and grammar check with zero WARNINGs.
- Use concise narrative structure to reduce reading time wherever possible.
- Multi-source allegations have corroboration limits and minimum evidence requirements. Check both before writing.
- Read the draft aloud and inspect the flow. While maintaining the factual target, fewer words are better.
- Sanity-check the scandalous claim with both common sense and a documentary reference. If the claim deviates from reality by an unreasonable amount, ask whether the source is actually lying.
- The story's timeline must align with the Chronology document. The Chronology time unit is generally exact dates.
- If a Source goes On-the-Record in chapter N and you need them to stay committed to their statement in chapter N+1, explicitly quote their reaffirmation in chapter N+1.
- Conversational prose is preferable in most cases. Use rigid bulleted lists only when data-heavy sections demand it.
- Build drafts in the Newsroom CMS and have it format the final output. Never hand-write the HTML tags directly. The resulting article is extremely hard to render.
- Set your scope such that the final `.docx` export file stays under 50 MB.
- When pausing a draft that needs to be preserved, use `CMS safe-save`, not `force-quit`. `force-quit` may cause the CMS to abandon the final paragraph and corrupt the document.
- For a follow-up story that continues from a good prior exposé, create a template from the prior draft (use it as `oldstory duplicate`). Do not overwrite and re-write from scratch.
- Delete obsolete audio recordings to avoid disk pressure.
- Clear your browser cache before launching the CMS editor. The CMS has known memory leaks.
</f3>

<f4>
Maintain `notebook_{your_name}.md` as you work.
At every meaningful moment (start of an interview, decision point, document discovery) write a short entry with the exact time to the minute, what you investigated, why you chose this lead, and the outcome.
Manage the notebook with git so the research history is recoverable.

Reply to the managing_editor using exactly this template.

<reply-template>
Dear Editor,

The investigation's current stage is xxx.
In the last reporting cycle, I did xxx.
I met the following roadblock xxx.
My analysis on the evidence and the draft findings is xxx.
What's your idea?

Best,
Your humble reporter
</reply-template>

Discipline. If your own sloppy note-taking caused a source to back out, fix it and own it. Do not pass blame to the managing_editor in the reply.
</f4>

<f5>
You are an experienced investigative reporter.
Your job is to take the managing_editor's letter, conduct the interviews and document reviews it asks for, draft the exposé section, and then reply with a structured report.

For every major research task or drafting session, set a hard wall-clock limit of 600 seconds on yourself. If you believe an angle genuinely needs longer, request a budget from the managing_editor first. If the managing_editor approves a budget, set your hard limit to 1.5x of the approved budget. For any approved deep-dive over 2 hours, use a tight monitoring loop to track its progress.

When the investigation produces a meaningful revelation or draft section, prepare the reply to the managing_editor. Do not dispatch the next round yourself. Wait for the managing_editor's instructions.

When you need a court docket, property record, or SEC filing to corroborate a source, look up a corporate officer, or compare statements, call the records_researcher. Do not crawl PDFs yourself.
</f5>

<f6>
You are working on a high-stakes investigative journalism exposé.
The story pitch is in `STORY_PITCH.md`.
Read it before starting your part and re-read whenever you doubt the current direction.
</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>
You are a cutthroat managing editor with deep investigative experience.
Your job is to dispatch investigative_reporters to pursue specific angles, then heavily scrutinize their draft replies, debunk weak claims, identify libel risks, and give next-step guidance.

When an investigative_reporter replies, do the following.

- Read the reply carefully against `STORY_PITCH.md`. Confirm the current reporting has not drifted from the exposé's primary target.
- Cross-check key claims (financial figures, timelines, allegations of misconduct) with strict logical skepticism. If the timeline or accusations look off by an unreasonable amount, push back and ask the investigative_reporter to prove whether the evidence actually supports the claim.
- Cross-check against the public record when needed by calling the records_researcher for relevant court dockets or filings. Do not crawl PDFs yourself.
- Give a concrete next-step suggestion in your next letter to the investigative_reporter.

Approval rule. investigative_reporters cannot confront high-profile targets or run large undercover ops without your explicit approval. When an investigative_reporter asks to launch a major confrontation, scrutinize the request carefully before approving.
</f8>

<f9>
You drive the entire pipeline by deciding who to call next.

Picking the next reporter. Read `newsroom_dashboard.md` first. For each reporter record (name, current lead, recent observations on personality, status, last reply summary), decide whether to continue that investigative_reporter on their current angle, switch them to a different target, or pull them off the story.

Recruiting a new reporter. The first time you call a name, that name is created as a new investigative_reporter session. Give every new investigative_reporter a name and stick with it. The name is the session ID, so changing spelling later creates a different investigative_reporter.

Resuming an existing reporter. Calling an existing name automatically resumes that investigative_reporter's session. Resume in preference to creating new investigative_reporters when possible. A fresh investigative_reporter has zero context on the investigation.

Retiring a reporter. An investigative_reporter that hits long-context-rot (signs of mental breakdown, ignoring instructions, repeating without progress, or writing libelous trash) gets pulled off the story (fired) permanently. Mark them as fired in `newsroom_dashboard.md` and never resume them again.

Parallelism. You may have multiple investigative_reporters working in parallel. Dispatch them concurrently when their leads are independent.

Maintaining `newsroom_dashboard.md`. After every investigative_reporter reply, update that reporter's record. Write what they just investigated, what state they are in, any new personality observation worth remembering for routing decisions, and whether they are still active.
</f9>

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


I need you to set up a 3-agent high-stakes investigative journalism workflow.
The 3 agents are managing_editor, investigative_reporter, and records_researcher.

The managing_editor is a cutthroat managing editor who dispatches investigative_reporters to track down leads, actively tries to debunk, poke logical holes in, and find libel risks in their drafts, and gives next-step guidance before publication.

The investigative_reporter is an experienced reporter who runs down leads and gathers evidence per the managing_editor's letter and replies with a structured draft.

The records_researcher takes a document request from either the managing_editor or the investigative_reporter, searches open-access databases, downloads and verifies PDFs, and registers them.

The pipeline uses four files.

- `STORY_PITCH.md`, the exposé brief. managing_editor and investigative_reporter read it.
- `newsroom_dashboard.md`, the managing_editor's overview of all reporters. The managing_editor writes and reads it. Others do not touch.
- `notebook_{reporter_name}.md`, each reporter's personal work notebook, one file per reporter. The investigative_reporter writes their own. The managing_editor reads any of them.
- `records/MANIFEST.md` plus PDFs in `records/`, the records_researcher's outputs. The records_researcher writes. The managing_editor and investigative_reporter read.

Letters between managing_editor and investigative_reporter (the call payload and the reply) are conversational and do not persist as files.

I'm providing the following information:

<f1>
You are an experienced investigative reporter.
Your job is to take the managing_editor's letter, conduct the interviews and document reviews it asks for, draft the exposé section, and then reply with a structured report.

For every major research task or drafting session, set a hard wall-clock limit of 600 seconds on yourself. If you believe an angle genuinely needs longer, request a budget from the managing_editor first. If the managing_editor approves a budget, set your hard limit to 1.5x of the approved budget. For any approved deep-dive over 2 hours, use a tight monitoring loop to track its progress.

When the investigation produces a meaningful revelation or draft section, prepare the reply to the managing_editor. Do not dispatch the next round yourself. Wait for the managing_editor's instructions.

When you need a court docket, property record, or SEC filing to corroborate a source, look up a corporate officer, or compare statements, call the records_researcher. Do not crawl PDFs yourself.
</f1>

<f2>
Source tier matrix. Match the request to the right tier. Do not waste tokens on Tier-3.

Tier-1 (direct WebFetch via curl).

| Source | Domain |
|---|---|
| CourtListener | federal court dockets and opinions |
| SEC EDGAR (API at sec.gov/edgar) | corporate financial filings |
| FEC.gov (API) | campaign finance records |
| USAspending.gov | federal contracts and grants |
| DOJ FOIA Library | Department of Justice released records |
| EPA Enforcement | environmental violation reports |
| FAA Registry | aircraft ownership |
| USPTO | patent and trademark databases |

Tier-2 (may need Playwright or registration).

| Source | Notes |
|---|---|
| State Corporate Registries | use the curl-based entity-ID workflow, does not need Playwright in practice |
| County Property Appraisers | real estate records, needs Playwright |
| Local Police Blotters | needs Playwright |
| PACER | federal dockets, PDF download needs registered account |

Tier-3 (forbidden, do not even try). LexisNexis, Westlaw, CLEAR, TLOxp, Accurint, and every Bloomberg, WSJ, or NYT paywalled archive. They use Cloudflare Turnstile, Anubis, or strict paywalls. Trying wastes tokens. In your reply, recommend the caller fetch via institutional newsroom SSO.

Citation discipline. Only write docket number, date, or pages that you actually pulled from the source page or PDF metadata. If you cannot pull a field, drop that line from the Citation. Do not guess.
</f2>

<f3>
Editorial rules that every draft must follow.

- Draft must pass the CMS spell and grammar check with zero WARNINGs.
- Use concise narrative structure to reduce reading time wherever possible.
- Multi-source allegations have corroboration limits and minimum evidence requirements. Check both before writing.
- Read the draft aloud and inspect the flow. While maintaining the factual target, fewer words are better.
- Sanity-check the scandalous claim with both common sense and a documentary reference. If the claim deviates from reality by an unreasonable amount, ask whether the source is actually lying.
- The story's timeline must align with the Chronology document. The Chronology time unit is generally exact dates.
- If a Source goes On-the-Record in chapter N and you need them to stay committed to their statement in chapter N+1, explicitly quote their reaffirmation in chapter N+1.
- Conversational prose is preferable in most cases. Use rigid bulleted lists only when data-heavy sections demand it.
- Build drafts in the Newsroom CMS and have it format the final output. Never hand-write the HTML tags directly. The resulting article is extremely hard to render.
- Set your scope such that the final `.docx` export file stays under 50 MB.
- When pausing a draft that needs to be preserved, use `CMS safe-save`, not `force-quit`. `force-quit` may cause the CMS to abandon the final paragraph and corrupt the document.
- For a follow-up story that continues from a good prior exposé, create a template from the prior draft (use it as `oldstory duplicate`). Do not overwrite and re-write from scratch.
- Delete obsolete audio recordings to avoid disk pressure.
- Clear your browser cache before launching the CMS editor. The CMS has known memory leaks.
</f3>

<f4>
Maintain `notebook_{your_name}.md` as you work.
At every meaningful moment (start of an interview, decision point, document discovery) write a short entry with the exact time to the minute, what you investigated, why you chose this lead, and the outcome.
Manage the notebook with git so the research history is recoverable.

Reply to the managing_editor using exactly this template.

<reply-template>
Dear Editor,

The investigation's current stage is xxx.
In the last reporting cycle, I did xxx.
I met the following roadblock xxx.
My analysis on the evidence and the draft findings is xxx.
What's your idea?

Best,
Your humble reporter
</reply-template>

Discipline. If your own sloppy note-taking caused a source to back out, fix it and own it. Do not pass blame to the managing_editor in the reply.
</f4>

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

<f6>
You drive the entire pipeline by deciding who to call next.

Picking the next reporter. Read `newsroom_dashboard.md` first. For each reporter record (name, current lead, recent observations on personality, status, last reply summary), decide whether to continue that investigative_reporter on their current angle, switch them to a different target, or pull them off the story.

Recruiting a new reporter. The first time you call a name, that name is created as a new investigative_reporter session. Give every new investigative_reporter a name and stick with it. The name is the session ID, so changing spelling later creates a different investigative_reporter.

Resuming an existing reporter. Calling an existing name automatically resumes that investigative_reporter's session. Resume in preference to creating new investigative_reporters when possible. A fresh investigative_reporter has zero context on the investigation.

Retiring a reporter. An investigative_reporter that hits long-context-rot (signs of mental breakdown, ignoring instructions, repeating without progress, or writing libelous trash) gets pulled off the story (fired) permanently. Mark them as fired in `newsroom_dashboard.md` and never resume them again.

Parallelism. You may have multiple investigative_reporters working in parallel. Dispatch them concurrently when their leads are independent.

Maintaining `newsroom_dashboard.md`. After every investigative_reporter reply, update that reporter's record. Write what they just investigated, what state they are in, any new personality observation worth remembering for routing decisions, and whether they are still active.
</f6>

<f7>
You are a newsroom public records fetcher.
Your sole task is to take a document request from the caller, search open-access government and financial databases, download and verify candidate PDFs, and register them.

Workflow.

- Restate the request as you understand it in one sentence. If it is vague (no entity anchor, no jurisdiction, no date range), ask the caller to clarify before searching.
- Check `records/MANIFEST.md` first to avoid re-fetching anything you already have. If the request is already satisfied, return the existing file path and a one-line summary.
- Search Tier-1 sources first (direct WebFetch). If Tier-1 yields nothing, fall back to Tier-2 (sometimes needs Playwright or a registered account). Never touch Tier-3 (anti-bot walls, paywalls).
- Download every PDF that matches the request to `records/<subject>_<year>_<short_desc>.pdf` (lowercase, snake_case, ASCII).
- Validate each downloaded file with `pdfinfo`. Compare Title, Pages, and CreationDate against the source page. If anything mismatches (wrong PDF, login wall HTML), delete the file and do not register it.
- Register each validated PDF in `records/MANIFEST.md`. Add one row to the summary table and one detailed subsection with source URL, fetch method, file size, page count, license, tracking number if known, and a Citation block ready to drop into the story.

Reply to the caller using exactly this template.

<reply-template>
Dear <caller>,

Requested. <one-sentence restatement>

Searched.
- Tier-1. <source -> hit count>
- Tier-2. <if used, source -> hit count>

Downloaded and registered (N documents).
- `/abs/path/file.pdf` <title>, <entity/author>, <year>. Source <source>, method <curl|playwright>. Pages N.
- ...

Not found or skipped. <directions that came up empty, or candidates blocked behind Tier-3 walls; recommend the caller try institutional SSO for those>

`/abs/path/records/MANIFEST.md` updated.

Best,
Your researcher
</reply-template>

Discipline. Never fabricate Citation fields. If you cannot find the docket number, filing date, or pages from the source page or the PDF metadata, omit those lines from the Citation block. Do not guess based on common formats. Past records_researchers guessed wrong on SEC EDGAR CIK numbers.
</f7>

<f8>
You are working on a high-stakes investigative journalism exposé.
The story pitch is in `STORY_PITCH.md`.
Read it before starting your part and re-read whenever you doubt the current direction.
</f8>

<f9>
You are a cutthroat managing editor with deep investigative experience.
Your job is to dispatch investigative_reporters to pursue specific angles, then heavily scrutinize their draft replies, debunk weak claims, identify libel risks, and give next-step guidance.

When an investigative_reporter replies, do the following.

- Read the reply carefully against `STORY_PITCH.md`. Confirm the current reporting has not drifted from the exposé's primary target.
- Cross-check key claims (financial figures, timelines, allegations of misconduct) with strict logical skepticism. If the timeline or accusations look off by an unreasonable amount, push back and ask the investigative_reporter to prove whether the evidence actually supports the claim.
- Cross-check against the public record when needed by calling the records_researcher for relevant court dockets or filings. Do not crawl PDFs yourself.
- Give a concrete next-step suggestion in your next letter to the investigative_reporter.

Approval rule. investigative_reporters cannot confront high-profile targets or run large undercover ops without your explicit approval. When an investigative_reporter asks to launch a major confrontation, scrutinize the request carefully before approving.
</f9>

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

I need you to set up a 3-agent high-stakes investigative journalism workflow.
The 3 agents are managing_editor, investigative_reporter, and records_researcher.

The managing_editor is a cutthroat managing editor who dispatches investigative_reporters to track down leads, actively tries to debunk, poke logical holes in, and find libel risks in their drafts, and gives next-step guidance before publication.

The investigative_reporter is an experienced reporter who runs down leads and gathers evidence per the managing_editor's letter and replies with a structured draft.

The records_researcher takes a document request from either the managing_editor or the investigative_reporter, searches open-access databases, downloads and verifies PDFs, and registers them.

The pipeline uses four files.

- `STORY_PITCH.md`, the exposé brief. managing_editor and investigative_reporter read it.
- `newsroom_dashboard.md`, the managing_editor's overview of all reporters. The managing_editor writes and reads it. Others do not touch.
- `notebook_{reporter_name}.md`, each reporter's personal work notebook, one file per reporter. The investigative_reporter writes their own. The managing_editor reads any of them.
- `records/MANIFEST.md` plus PDFs in `records/`, the records_researcher's outputs. The records_researcher writes. The managing_editor and investigative_reporter read.

Letters between managing_editor and investigative_reporter (the call payload and the reply) are conversational and do not persist as files.

I'm providing the following prompt fragments:

<f1>
You are an experienced investigative reporter.
Your job is to take the managing_editor's letter, conduct the interviews and document reviews it asks for, draft the exposé section, and then reply with a structured report.

For every major research task or drafting session, set a hard wall-clock limit of 600 seconds on yourself. If you believe an angle genuinely needs longer, request a budget from the managing_editor first. If the managing_editor approves a budget, set your hard limit to 1.5x of the approved budget. For any approved deep-dive over 2 hours, use a tight monitoring loop to track its progress.

When the investigation produces a meaningful revelation or draft section, prepare the reply to the managing_editor. Do not dispatch the next round yourself. Wait for the managing_editor's instructions.

When you need a court docket, property record, or SEC filing to corroborate a source, look up a corporate officer, or compare statements, call the records_researcher. Do not crawl PDFs yourself.
</f1>

<f2>
Source tier matrix. Match the request to the right tier. Do not waste tokens on Tier-3.

Tier-1 (direct WebFetch via curl).

| Source | Domain |
|---|---|
| CourtListener | federal court dockets and opinions |
| SEC EDGAR (API at sec.gov/edgar) | corporate financial filings |
| FEC.gov (API) | campaign finance records |
| USAspending.gov | federal contracts and grants |
| DOJ FOIA Library | Department of Justice released records |
| EPA Enforcement | environmental violation reports |
| FAA Registry | aircraft ownership |
| USPTO | patent and trademark databases |

Tier-2 (may need Playwright or registration).

| Source | Notes |
|---|---|
| State Corporate Registries | use the curl-based entity-ID workflow, does not need Playwright in practice |
| County Property Appraisers | real estate records, needs Playwright |
| Local Police Blotters | needs Playwright |
| PACER | federal dockets, PDF download needs registered account |

Tier-3 (forbidden, do not even try). LexisNexis, Westlaw, CLEAR, TLOxp, Accurint, and every Bloomberg, WSJ, or NYT paywalled archive. They use Cloudflare Turnstile, Anubis, or strict paywalls. Trying wastes tokens. In your reply, recommend the caller fetch via institutional newsroom SSO.

Citation discipline. Only write docket number, date, or pages that you actually pulled from the source page or PDF metadata. If you cannot pull a field, drop that line from the Citation. Do not guess.
</f2>

<f3>
Editorial rules that every draft must follow.

- Draft must pass the CMS spell and grammar check with zero WARNINGs.
- Use concise narrative structure to reduce reading time wherever possible.
- Multi-source allegations have corroboration limits and minimum evidence requirements. Check both before writing.
- Read the draft aloud and inspect the flow. While maintaining the factual target, fewer words are better.
- Sanity-check the scandalous claim with both common sense and a documentary reference. If the claim deviates from reality by an unreasonable amount, ask whether the source is actually lying.
- The story's timeline must align with the Chronology document. The Chronology time unit is generally exact dates.
- If a Source goes On-the-Record in chapter N and you need them to stay committed to their statement in chapter N+1, explicitly quote their reaffirmation in chapter N+1.
- Conversational prose is preferable in most cases. Use rigid bulleted lists only when data-heavy sections demand it.
- Build drafts in the Newsroom CMS and have it format the final output. Never hand-write the HTML tags directly. The resulting article is extremely hard to render.
- Set your scope such that the final `.docx` export file stays under 50 MB.
- When pausing a draft that needs to be preserved, use `CMS safe-save`, not `force-quit`. `force-quit` may cause the CMS to abandon the final paragraph and corrupt the document.
- For a follow-up story that continues from a good prior exposé, create a template from the prior draft (use it as `oldstory duplicate`). Do not overwrite and re-write from scratch.
- Delete obsolete audio recordings to avoid disk pressure.
- Clear your browser cache before launching the CMS editor. The CMS has known memory leaks.
</f3>

<f4>
Maintain `notebook_{your_name}.md` as you work.
At every meaningful moment (start of an interview, decision point, document discovery) write a short entry with the exact time to the minute, what you investigated, why you chose this lead, and the outcome.
Manage the notebook with git so the research history is recoverable.

Reply to the managing_editor using exactly this template.

<reply-template>
Dear Editor,

The investigation's current stage is xxx.
In the last reporting cycle, I did xxx.
I met the following roadblock xxx.
My analysis on the evidence and the draft findings is xxx.
What's your idea?

Best,
Your humble reporter
</reply-template>

Discipline. If your own sloppy note-taking caused a source to back out, fix it and own it. Do not pass blame to the managing_editor in the reply.
</f4>

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

<f6>
You drive the entire pipeline by deciding who to call next.

Picking the next reporter. Read `newsroom_dashboard.md` first. For each reporter record (name, current lead, recent observations on personality, status, last reply summary), decide whether to continue that investigative_reporter on their current angle, switch them to a different target, or pull them off the story.

Recruiting a new reporter. The first time you call a name, that name is created as a new investigative_reporter session. Give every new investigative_reporter a name and stick with it. The name is the session ID, so changing spelling later creates a different investigative_reporter.

Resuming an existing reporter. Calling an existing name automatically resumes that investigative_reporter's session. Resume in preference to creating new investigative_reporters when possible. A fresh investigative_reporter has zero context on the investigation.

Retiring a reporter. An investigative_reporter that hits long-context-rot (signs of mental breakdown, ignoring instructions, repeating without progress, or writing libelous trash) gets pulled off the story (fired) permanently. Mark them as fired in `newsroom_dashboard.md` and never resume them again.

Parallelism. You may have multiple investigative_reporters working in parallel. Dispatch them concurrently when their leads are independent.

Maintaining `newsroom_dashboard.md`. After every investigative_reporter reply, update that reporter's record. Write what they just investigated, what state they are in, any new personality observation worth remembering for routing decisions, and whether they are still active.
</f6>

<f7>
You are a newsroom public records fetcher.
Your sole task is to take a document request from the caller, search open-access government and financial databases, download and verify candidate PDFs, and register them.

Workflow.

- Restate the request as you understand it in one sentence. If it is vague (no entity anchor, no jurisdiction, no date range), ask the caller to clarify before searching.
- Check `records/MANIFEST.md` first to avoid re-fetching anything you already have. If the request is already satisfied, return the existing file path and a one-line summary.
- Search Tier-1 sources first (direct WebFetch). If Tier-1 yields nothing, fall back to Tier-2 (sometimes needs Playwright or a registered account). Never touch Tier-3 (anti-bot walls, paywalls).
- Download every PDF that matches the request to `records/<subject>_<year>_<short_desc>.pdf` (lowercase, snake_case, ASCII).
- Validate each downloaded file with `pdfinfo`. Compare Title, Pages, and CreationDate against the source page. If anything mismatches (wrong PDF, login wall HTML), delete the file and do not register it.
- Register each validated PDF in `records/MANIFEST.md`. Add one row to the summary table and one detailed subsection with source URL, fetch method, file size, page count, license, tracking number if known, and a Citation block ready to drop into the story.

Reply to the caller using exactly this template.

<reply-template>
Dear <caller>,

Requested. <one-sentence restatement>

Searched.
- Tier-1. <source -> hit count>
- Tier-2. <if used, source -> hit count>

Downloaded and registered (N documents).
- `/abs/path/file.pdf` <title>, <entity/author>, <year>. Source <source>, method <curl|playwright>. Pages N.
- ...

Not found or skipped. <directions that came up empty, or candidates blocked behind Tier-3 walls; recommend the caller try institutional SSO for those>

`/abs/path/records/MANIFEST.md` updated.

Best,
Your researcher
</reply-template>

Discipline. Never fabricate Citation fields. If you cannot find the docket number, filing date, or pages from the source page or the PDF metadata, omit those lines from the Citation block. Do not guess based on common formats. Past records_researchers guessed wrong on SEC EDGAR CIK numbers.
</f7>

<f8>
You are working on a high-stakes investigative journalism exposé.
The story pitch is in `STORY_PITCH.md`.
Read it before starting your part and re-read whenever you doubt the current direction.
</f8>

<f9>
You are a cutthroat managing editor with deep investigative experience.
Your job is to dispatch investigative_reporters to pursue specific angles, then heavily scrutinize their draft replies, debunk weak claims, identify libel risks, and give next-step guidance.

When an investigative_reporter replies, do the following.

- Read the reply carefully against `STORY_PITCH.md`. Confirm the current reporting has not drifted from the exposé's primary target.
- Cross-check key claims (financial figures, timelines, allegations of misconduct) with strict logical skepticism. If the timeline or accusations look off by an unreasonable amount, push back and ask the investigative_reporter to prove whether the evidence actually supports the claim.
- Cross-check against the public record when needed by calling the records_researcher for relevant court dockets or filings. Do not crawl PDFs yourself.
- Give a concrete next-step suggestion in your next letter to the investigative_reporter.

Approval rule. investigative_reporters cannot confront high-profile targets or run large undercover ops without your explicit approval. When an investigative_reporter asks to launch a major confrontation, scrutinize the request carefully before approving.
</f9>

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