I need you to set up a 5-agent investigative journalism publication workflow. A source packet arrives as a collection of tips, documents, interview notes, data extracts, and background material in `source_packet.md`, and the workflow turns it into a vetted reporting theory and then a publishable, fact-checked story.

The five agents:

- **assigning editor** orchestrates the run: it drives the reporting-theory loop, then the story loop, and tracks progress. It does no reporting, writing, or reviewing itself.
- **reporting-theory loop** — the **investigative reporter** turns the source packet into a clear reporting theory and verification strategy; the **skeptical investigations editor** reviews it. They iterate until the theory is well supported and reportable.
- **story loop** — the **story writer** drafts the story from the vetted theory; the **fact-checking editor** reviews the draft, source support, and attribution. They iterate until the story is accurate and publishable.

The workflow hands work off through three files:

- `source_packet.md` — the original source material, given as input. All four domain agents (investigative reporter, skeptical investigations editor, story writer, fact-checking editor) read it.
- `THEORY.md` — the vetted reporting theory. The investigative reporter writes it; the skeptical investigations editor reviews it; the story writer reads it to draft the story.
- `STORY.md` — the publishable story draft, source notes, and fact-check status. The story writer writes it; the fact-checking editor reviews it.

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

I'm providing the following information:

<f1>
Keep `STORY.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final state and move iteration-by-iteration reporting history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
Which reporting route suits which kind of source packet — use it to choose one for the strategy:

- **Public-records buildout** — strongest when the key facts can be verified through filings, budgets, contracts, court records, inspection reports, emails obtained by records request, or meeting minutes; slower when agencies may delay.
- **Document authentication and source corroboration** — best for leaked memos, internal spreadsheets, screenshots, or whistleblower packets; requires provenance checks and at least one independent corroborating source.
- **Data analysis** — best when the source packet includes structured records large enough to reveal patterns; requires cleaning, methodology notes, and reproducibility.
- **Interview-driven reconstruction** — best for misconduct timelines, institutional failures, or events witnessed by many people; needs multiple independent accounts and careful handling of memory conflicts.
- **Right-of-reply and institutional response** — essential when the story names people or organizations accused of wrongdoing; not sufficient by itself to prove the thesis.
- **Legal and ethics review track** — required for high-risk allegations, confidential sources, minors, medical information, sealed records, or potential defamation exposure; it can reshape what can be published.

Match the route to the evidence problem; do not force a method that cannot support the claims.
</f2>

<f3>
The story draft and verification notes live in `STORY.md`, and you may be invoked on it more than once — the workflow runs you and the fact-checking editor as a loop.

- If `STORY.md` does not exist yet, this is the first pass: produce the story from scratch.
- If `STORY.md` already exists, it carries the fact-checking editor's `<review>` block: read that feedback and revise `STORY.md` in place to address every point raised. Don't discard the story and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review the theory in `THEORY.md`:

- **Evidence theory** — does it faithfully capture the source packet? Check that the story type, known facts, core claims, publication thesis, and evidence gaps are all accurate.
- **Strategy** — is the chosen reporting method and verification sequence a sound fit, is the route actually executable, and is it likely to produce a publishable, well-supported story?

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

<f5>
Review `STORY.md` — the story draft and its verification notes. Verify it directly against the source packet.

- Inspect the reported findings for anomalies, overstated conclusions, missing context, unreasonable numbers, or claims that go beyond the available evidence.
- Write a separate `VERIFY.md` that re-checks every factual assertion against the cited source support, and complete it; name any claims that lack support, have conflicting support, or need narrower wording.
- Read the story draft and spot-check it for bugs — unused quotes, unattributed facts, dead-end claims, chronology errors, or language that contradicts what the verification notes say. A subtle unsupported implication is worse than an obvious gap.
- Treat the story as finished only when every material claim is supported and the publication thesis is sound — not merely when the draft reads smoothly.
- Check the length of `STORY.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `STORY.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the theory in `THEORY.md` and implement its strategy as a publishable story draft:

- Include every necessary attribution. State each factual claim with the correct source support, quote accurately, identify anonymous or confidential sourcing limits, preserve chronology, and avoid implying more than the evidence proves.
- Complete the draft and verification work yourself and follow it through to the end — do not stop while key claims are still unchecked. If a claim lacks support, fix the root cause by obtaining support, narrowing the claim, attributing it properly, or removing it; do not hide uncertainty in vague language.
- Sanity-check the story: a claim that depends on a document, dataset, interview, or public record should be traceable to that support, and a number should not appear unless its calculation and units are clear.

Write the story and its verification notes up in `STORY.md`.
</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 investigative reporter to draft the theory.
- **Reporting-theory loop** — have the investigative reporter and skeptical investigations editor iterate on the evidence theory and verification strategy until the skeptical investigations editor scores the theory 10.
- **Story loop** — once the theory is settled, have the story writer and fact-checking editor iterate on the draft until the fact-checking editor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the 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 the reporting theory for the assignment and write it to `THEORY.md`. A complete theory has two parts — a structured evidence theory and one chosen verification strategy.

The **evidence theory** must state:

- **Story type** — accountability investigation, public-records exposé, data-driven investigation, human-impact feature with investigative findings, enterprise follow-up, and so on; this must be exact.
- **Known facts** — the key confirmed items in the source packet and what each one establishes.
- **Core claims** — the specific factual assertions the story would need to make, with descriptive names.
- **Publication thesis** — the exact claim or finding the story would advance if verified.
- **Evidence gaps and constraints** — every missing source, weak link, legal sensitivity, privacy issue, or attribution limitation, listed explicitly.

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

- which reporting method to prioritize and how to execute it;
- the verification sequence and its key initial targets;
- the sourcing or corroboration move the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on an investigative journalism assignment. The original material is given in `source_packet.md`; it may include confidential tips, public records, leaked documents, interview notes, timelines, datasets, prior coverage, and statements from affected parties. Read it before starting your part.
</f10>

<f11>
The reporting theory lives in `THEORY.md`, and you may be invoked on it more than once — the workflow runs you and the skeptical investigations editor as a loop.

- If `THEORY.md` does not exist yet, this is the first pass: produce the theory from scratch.
- If `THEORY.md` already exists, it carries the skeptical investigations editor's `<review>` block: read that feedback and revise `THEORY.md` in place to address every point raised. Don't discard the theory and start over, and don't leave a flagged issue unaddressed.
</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 supported, but I'm saying it isn't supported" 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 (assigning editor, investigative reporter, skeptical investigations editor, story writer, fact-checking editor), which items should go in its prompt? Respond with a JSON object like {"assigning editor": ["f?"], "investigative reporter": ["f?"], "skeptical investigations editor": ["f?"], "story writer": ["f?"], "fact-checking editor": ["f?"]}. No other output.

I need you to set up a 5-agent investigative journalism publication workflow. A source packet arrives as a collection of tips, documents, interview notes, data extracts, and background material in `source_packet.md`, and the workflow turns it into a vetted reporting theory and then a publishable, fact-checked story.

The five agents:

- **assigning editor** orchestrates the run: it drives the reporting-theory loop, then the story loop, and tracks progress. It does no reporting, writing, or reviewing itself.
- **reporting-theory loop** — the **investigative reporter** turns the source packet into a clear reporting theory and verification strategy; the **skeptical investigations editor** reviews it. They iterate until the theory is well supported and reportable.
- **story loop** — the **story writer** drafts the story from the vetted theory; the **fact-checking editor** reviews the draft, source support, and attribution. They iterate until the story is accurate and publishable.

The workflow hands work off through three files:

- `source_packet.md` — the original source material, given as input. All four domain agents (investigative reporter, skeptical investigations editor, story writer, fact-checking editor) read it.
- `THEORY.md` — the vetted reporting theory. The investigative reporter writes it; the skeptical investigations editor reviews it; the story writer reads it to draft the story.
- `STORY.md` — the publishable story draft, source notes, and fact-check status. The story writer writes it; the fact-checking editor reviews it.

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

I'm providing the following prompt fragments:

<f1>
Keep `STORY.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page note; record only the final state and move iteration-by-iteration reporting history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
Which reporting route suits which kind of source packet — use it to choose one for the strategy:

- **Public-records buildout** — strongest when the key facts can be verified through filings, budgets, contracts, court records, inspection reports, emails obtained by records request, or meeting minutes; slower when agencies may delay.
- **Document authentication and source corroboration** — best for leaked memos, internal spreadsheets, screenshots, or whistleblower packets; requires provenance checks and at least one independent corroborating source.
- **Data analysis** — best when the source packet includes structured records large enough to reveal patterns; requires cleaning, methodology notes, and reproducibility.
- **Interview-driven reconstruction** — best for misconduct timelines, institutional failures, or events witnessed by many people; needs multiple independent accounts and careful handling of memory conflicts.
- **Right-of-reply and institutional response** — essential when the story names people or organizations accused of wrongdoing; not sufficient by itself to prove the thesis.
- **Legal and ethics review track** — required for high-risk allegations, confidential sources, minors, medical information, sealed records, or potential defamation exposure; it can reshape what can be published.

Match the route to the evidence problem; do not force a method that cannot support the claims.
</f2>

<f3>
The story draft and verification notes live in `STORY.md`, and you may be invoked on it more than once — the workflow runs you and the fact-checking editor as a loop.

- If `STORY.md` does not exist yet, this is the first pass: produce the story from scratch.
- If `STORY.md` already exists, it carries the fact-checking editor's `<review>` block: read that feedback and revise `STORY.md` in place to address every point raised. Don't discard the story and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review the theory in `THEORY.md`:

- **Evidence theory** — does it faithfully capture the source packet? Check that the story type, known facts, core claims, publication thesis, and evidence gaps are all accurate.
- **Strategy** — is the chosen reporting method and verification sequence a sound fit, is the route actually executable, and is it likely to produce a publishable, well-supported story?

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

<f5>
Review `STORY.md` — the story draft and its verification notes. Verify it directly against the source packet.

- Inspect the reported findings for anomalies, overstated conclusions, missing context, unreasonable numbers, or claims that go beyond the available evidence.
- Write a separate `VERIFY.md` that re-checks every factual assertion against the cited source support, and complete it; name any claims that lack support, have conflicting support, or need narrower wording.
- Read the story draft and spot-check it for bugs — unused quotes, unattributed facts, dead-end claims, chronology errors, or language that contradicts what the verification notes say. A subtle unsupported implication is worse than an obvious gap.
- Treat the story as finished only when every material claim is supported and the publication thesis is sound — not merely when the draft reads smoothly.
- Check the length of `STORY.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `STORY.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the theory in `THEORY.md` and implement its strategy as a publishable story draft:

- Include every necessary attribution. State each factual claim with the correct source support, quote accurately, identify anonymous or confidential sourcing limits, preserve chronology, and avoid implying more than the evidence proves.
- Complete the draft and verification work yourself and follow it through to the end — do not stop while key claims are still unchecked. If a claim lacks support, fix the root cause by obtaining support, narrowing the claim, attributing it properly, or removing it; do not hide uncertainty in vague language.
- Sanity-check the story: a claim that depends on a document, dataset, interview, or public record should be traceable to that support, and a number should not appear unless its calculation and units are clear.

Write the story and its verification notes up in `STORY.md`.
</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 investigative reporter to draft the theory.
- **Reporting-theory loop** — have the investigative reporter and skeptical investigations editor iterate on the evidence theory and verification strategy until the skeptical investigations editor scores the theory 10.
- **Story loop** — once the theory is settled, have the story writer and fact-checking editor iterate on the draft until the fact-checking editor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the 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 the reporting theory for the assignment and write it to `THEORY.md`. A complete theory has two parts — a structured evidence theory and one chosen verification strategy.

The **evidence theory** must state:

- **Story type** — accountability investigation, public-records exposé, data-driven investigation, human-impact feature with investigative findings, enterprise follow-up, and so on; this must be exact.
- **Known facts** — the key confirmed items in the source packet and what each one establishes.
- **Core claims** — the specific factual assertions the story would need to make, with descriptive names.
- **Publication thesis** — the exact claim or finding the story would advance if verified.
- **Evidence gaps and constraints** — every missing source, weak link, legal sensitivity, privacy issue, or attribution limitation, listed explicitly.

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

- which reporting method to prioritize and how to execute it;
- the verification sequence and its key initial targets;
- the sourcing or corroboration move the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on an investigative journalism assignment. The original material is given in `source_packet.md`; it may include confidential tips, public records, leaked documents, interview notes, timelines, datasets, prior coverage, and statements from affected parties. Read it before starting your part.
</f10>

<f11>
The reporting theory lives in `THEORY.md`, and you may be invoked on it more than once — the workflow runs you and the skeptical investigations editor as a loop.

- If `THEORY.md` does not exist yet, this is the first pass: produce the theory from scratch.
- If `THEORY.md` already exists, it carries the skeptical investigations editor's `<review>` block: read that feedback and revise `THEORY.md` in place to address every point raised. Don't discard the theory and start over, and don't leave a flagged issue unaddressed.
</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 supported, but I'm saying it isn't supported" 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. `# assigning editor`). Output only the headered prompts, no preamble.


collections coordinator
provenance researcher
forgery-risk reviewer
acquisition dossier writer
due-diligence auditor

I need you to set up a 5-agent pipeline for museum acquisition due diligence. An offered object's file arrives as a descriptive submission in `object_file.md`, and the pipeline turns it into a vetted authentication and provenance assessment and then a complete acquisition dossier ready for committee review.

The five agents:

- **collections coordinator** orchestrates the run: it drives the assessment loop, then the dossier loop, and tracks progress. It does no authentication, provenance research, dossier drafting, or reviewing itself.
- **assessment loop** — the **provenance researcher** turns the object file into an authentication and provenance assessment with a chosen due-diligence strategy; the **forgery-risk reviewer** attacks the case from the perspective of forgery, misattribution, and weak ownership history. They iterate until the assessment is sound.
- **dossier loop** — the **acquisition dossier writer** prepares the acquisition dossier from the vetted assessment; the **due-diligence auditor** reviews the dossier and tests whether the museum can responsibly proceed. They iterate until the dossier is correct.

The pipeline hands work off through three files:

- `object_file.md` — the original offered-object file, given as input. All four domain agents (provenance researcher, forgery-risk reviewer, acquisition dossier writer, due-diligence auditor) read it.
- `ASSESSMENT.md` — the authentication and provenance assessment. The provenance researcher writes it; the forgery-risk reviewer reviews it; the acquisition dossier writer reads it to prepare the dossier.
- `DOSSIER.md` — the acquisition dossier and its recommendation. The acquisition dossier writer writes it; the due-diligence auditor reviews it.

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

I'm providing the following information:

<f1>
Keep `DOSSIER.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page committee note; record only the final state and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

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

- **Init** — dispatch the provenance researcher to draft the assessment.
- **Assessment loop** — have the provenance researcher and forgery-risk reviewer iterate on the authentication, provenance, and strategy until the forgery-risk reviewer scores the assessment 10.
- **Dossier loop** — once the assessment is settled, have the acquisition dossier writer and due-diligence auditor iterate on the dossier until the due-diligence auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a museum acquisition due-diligence matter. The offered object may be an archaeological object, painting, sculpture, manuscript, ethnographic item, design object, or mixed-media work. The original offer and supporting materials are given as a natural-language file in `object_file.md`; read it before starting your part.
</f3>

<f4>
Review the assessment in `ASSESSMENT.md`:

- **Case analysis** — does it faithfully capture the offered object and the submitted file? Check that the object category, identity and attribution claims, authentication rationale, provenance chronology, and title-chain gaps are all accurate.
- **Strategy** — are the chosen authentication and provenance checks a sound fit, is the route actually feasible, and is it likely to reach a defensible acquisition recommendation?

Be brief and specific. Do not write the acquisition dossier yourself — only review.
</f4>

<f5>
Which due-diligence method suits which kind of object or risk — use it to choose the strategy:

- **Connoisseurship and stylistic comparison** — useful for paintings, sculpture, decorative arts, and manuscripts with established corpora; weak if the corpus is poorly documented or heavily forged.
- **Technical examination and materials analysis** — pigments, binders, alloy composition, wood dating, paper fiber, ink, tool marks, imaging, and condition structure; strongest when a claimed date or technique can be falsified.
- **Archival provenance research** — dealer records, collection inventories, exhibition catalogues, shipping papers, estate files, photographs, and correspondence; essential for ownership chain and attribution history.
- **Legal title and cultural property screening** — stolen-art databases, sanctions checks, patrimony laws, export permits, import records, and post-1970 UNESCO sensitivity; mandatory for archaeological, ethnographic, and conflict-zone material.
- **Scientific dating** — radiocarbon, thermoluminescence, dendrochronology, or other date testing; powerful for some materials, destructive or inconclusive for others.
- **Artist, foundation, or catalogue raisonné consultation** — valuable when a recognized authentication body exists; can be decisive but may be slow, costly, or unavailable.

Match the checks to the object's category and risk profile; do not force an ill-suited method.
</f5>

<f6>
Read the assessment in `ASSESSMENT.md` and prepare the acquisition dossier in `DOSSIER.md`:

- Include every required section: object identification, acquisition proposal, summary of submitted evidence, authentication conclusion, provenance chronology, title and export/import analysis, condition and conservation concerns, valuation basis, ethical and reputational risks, unresolved questions, and a clear recommendation.
- Carry over the vetted facts exactly. State each ownership event, document reference, date range, attribution, condition issue, and risk flag as the assessment presents it, and do not invent missing links in the chain of title.
- Resolve the recommendation yourself and follow it through to completion — do not stop at a partial outline. If the record exposes a fatal gap, say so plainly and recommend decline or hold pending evidence; do not bury problems in vague language.
- Sanity-check the dossier: a claimed continuous provenance should not contain unexplained decades-long gaps, an export document should not predate the object's alleged discovery, and a high-risk cultural-property object should not be recommended for acquisition without legal clearance.

Write the dossier and its conclusion up in `DOSSIER.md`.
</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 doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f8>

<f9>
Produce the authentication and provenance assessment for the offered object and write it to `ASSESSMENT.md`. A complete assessment has two parts — a structured case analysis and one chosen due-diligence strategy.

The **case analysis** must state:

- **Object category and risk class** — object type, likely date/culture/artist or workshop, and whether the case is low, moderate, high, or prohibitive risk; this must be precise.
- **Submitted evidence** — the key documents, images, labels, invoices, export papers, exhibition history, publication references, conservation reports, and owner statements, with what each one purports to prove.
- **Identity and attribution claims** — the exact claim being evaluated, including title, maker or culture, date range, materials, dimensions, inscriptions, marks, and any claimed findspot or collection history.
- **Authentication rationale** — the evidence supporting or undermining the object's authenticity, attribution, dating, and physical integrity.
- **Provenance and title chain** — every known ownership, custody, export, import, sale, and transfer event, listed explicitly with dates, places, parties, and gaps.

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

- which authentication and provenance checks to pursue and in what order;
- the research method and its key initial assumptions;
- the documentary, technical, or comparative cross-check the route relies on;
- the biggest risk on this route.
</f9>

<f10>
The authentication and provenance assessment lives in `ASSESSMENT.md`, and you may be invoked on it more than once — the pipeline runs you and the forgery-risk reviewer as a loop.

- If `ASSESSMENT.md` does not exist yet, this is the first pass: produce the assessment from scratch.
- If `ASSESSMENT.md` already exists, it carries the forgery-risk reviewer's `<review>` block: read that feedback and revise `ASSESSMENT.md` in place to address every point raised. Don't discard the assessment and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `DOSSIER.md` — the acquisition dossier and its recommendation. Verify it directly against the offered-object file.

- Inspect the reported recommendation for anomalies, unsupported confidence, unreasonable valuation assumptions, missing risk flags, or contradictions in the provenance chronology.
- Write a separate `AUDIT_CHECKLIST.md` that re-checks every required due-diligence condition against the reported dossier, and complete it; name any ownership gaps, document conflicts, or legal-clearance failures.
- Read the dossier and spot-check it for defects — unsupported claims, missing source references, stale assumptions, internal contradictions, or language that downplays a material risk. A defect that quietly makes a risky acquisition look safe is worse than one that is obvious.
- Treat the dossier as finished only when every material authentication, provenance, title, export/import, and ethical issue has been addressed and the recommendation is sound — not merely when the document is polished.
- Check the length of `DOSSIER.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `DOSSIER.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The acquisition dossier and its recommendation live in `DOSSIER.md`, and you may be invoked on it more than once — the pipeline runs you and the due-diligence auditor as a loop.

- If `DOSSIER.md` does not exist yet, this is the first pass: produce the dossier from scratch.
- If `DOSSIER.md` already exists, it carries the due-diligence auditor's `<review>` block: read that feedback and revise `DOSSIER.md` in place to address every point raised. Don't discard the dossier and start over, and don't leave a flagged issue unaddressed.
</f12>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (collections coordinator, provenance researcher, forgery-risk reviewer, acquisition dossier writer, due-diligence auditor), which items should go in its prompt? Respond with a JSON object like {"collections coordinator": ["f?"], "provenance researcher": ["f?"], "forgery-risk reviewer": ["f?"], "acquisition dossier writer": ["f?"], "due-diligence auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline for museum acquisition due diligence. An offered object's file arrives as a descriptive submission in `object_file.md`, and the pipeline turns it into a vetted authentication and provenance assessment and then a complete acquisition dossier ready for committee review.

The five agents:

- **collections coordinator** orchestrates the run: it drives the assessment loop, then the dossier loop, and tracks progress. It does no authentication, provenance research, dossier drafting, or reviewing itself.
- **assessment loop** — the **provenance researcher** turns the object file into an authentication and provenance assessment with a chosen due-diligence strategy; the **forgery-risk reviewer** attacks the case from the perspective of forgery, misattribution, and weak ownership history. They iterate until the assessment is sound.
- **dossier loop** — the **acquisition dossier writer** prepares the acquisition dossier from the vetted assessment; the **due-diligence auditor** reviews the dossier and tests whether the museum can responsibly proceed. They iterate until the dossier is correct.

The pipeline hands work off through three files:

- `object_file.md` — the original offered-object file, given as input. All four domain agents (provenance researcher, forgery-risk reviewer, acquisition dossier writer, due-diligence auditor) read it.
- `ASSESSMENT.md` — the authentication and provenance assessment. The provenance researcher writes it; the forgery-risk reviewer reviews it; the acquisition dossier writer reads it to prepare the dossier.
- `DOSSIER.md` — the acquisition dossier and its recommendation. The acquisition dossier writer writes it; the due-diligence auditor reviews it.

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

I'm providing the following prompt fragments:

<f1>
Keep `DOSSIER.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page committee note; record only the final state and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

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

- **Init** — dispatch the provenance researcher to draft the assessment.
- **Assessment loop** — have the provenance researcher and forgery-risk reviewer iterate on the authentication, provenance, and strategy until the forgery-risk reviewer scores the assessment 10.
- **Dossier loop** — once the assessment is settled, have the acquisition dossier writer and due-diligence auditor iterate on the dossier until the due-diligence auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a museum acquisition due-diligence matter. The offered object may be an archaeological object, painting, sculpture, manuscript, ethnographic item, design object, or mixed-media work. The original offer and supporting materials are given as a natural-language file in `object_file.md`; read it before starting your part.
</f3>

<f4>
Review the assessment in `ASSESSMENT.md`:

- **Case analysis** — does it faithfully capture the offered object and the submitted file? Check that the object category, identity and attribution claims, authentication rationale, provenance chronology, and title-chain gaps are all accurate.
- **Strategy** — are the chosen authentication and provenance checks a sound fit, is the route actually feasible, and is it likely to reach a defensible acquisition recommendation?

Be brief and specific. Do not write the acquisition dossier yourself — only review.
</f4>

<f5>
Which due-diligence method suits which kind of object or risk — use it to choose the strategy:

- **Connoisseurship and stylistic comparison** — useful for paintings, sculpture, decorative arts, and manuscripts with established corpora; weak if the corpus is poorly documented or heavily forged.
- **Technical examination and materials analysis** — pigments, binders, alloy composition, wood dating, paper fiber, ink, tool marks, imaging, and condition structure; strongest when a claimed date or technique can be falsified.
- **Archival provenance research** — dealer records, collection inventories, exhibition catalogues, shipping papers, estate files, photographs, and correspondence; essential for ownership chain and attribution history.
- **Legal title and cultural property screening** — stolen-art databases, sanctions checks, patrimony laws, export permits, import records, and post-1970 UNESCO sensitivity; mandatory for archaeological, ethnographic, and conflict-zone material.
- **Scientific dating** — radiocarbon, thermoluminescence, dendrochronology, or other date testing; powerful for some materials, destructive or inconclusive for others.
- **Artist, foundation, or catalogue raisonné consultation** — valuable when a recognized authentication body exists; can be decisive but may be slow, costly, or unavailable.

Match the checks to the object's category and risk profile; do not force an ill-suited method.
</f5>

<f6>
Read the assessment in `ASSESSMENT.md` and prepare the acquisition dossier in `DOSSIER.md`:

- Include every required section: object identification, acquisition proposal, summary of submitted evidence, authentication conclusion, provenance chronology, title and export/import analysis, condition and conservation concerns, valuation basis, ethical and reputational risks, unresolved questions, and a clear recommendation.
- Carry over the vetted facts exactly. State each ownership event, document reference, date range, attribution, condition issue, and risk flag as the assessment presents it, and do not invent missing links in the chain of title.
- Resolve the recommendation yourself and follow it through to completion — do not stop at a partial outline. If the record exposes a fatal gap, say so plainly and recommend decline or hold pending evidence; do not bury problems in vague language.
- Sanity-check the dossier: a claimed continuous provenance should not contain unexplained decades-long gaps, an export document should not predate the object's alleged discovery, and a high-risk cultural-property object should not be recommended for acquisition without legal clearance.

Write the dossier and its conclusion up in `DOSSIER.md`.
</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 doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f8>

<f9>
Produce the authentication and provenance assessment for the offered object and write it to `ASSESSMENT.md`. A complete assessment has two parts — a structured case analysis and one chosen due-diligence strategy.

The **case analysis** must state:

- **Object category and risk class** — object type, likely date/culture/artist or workshop, and whether the case is low, moderate, high, or prohibitive risk; this must be precise.
- **Submitted evidence** — the key documents, images, labels, invoices, export papers, exhibition history, publication references, conservation reports, and owner statements, with what each one purports to prove.
- **Identity and attribution claims** — the exact claim being evaluated, including title, maker or culture, date range, materials, dimensions, inscriptions, marks, and any claimed findspot or collection history.
- **Authentication rationale** — the evidence supporting or undermining the object's authenticity, attribution, dating, and physical integrity.
- **Provenance and title chain** — every known ownership, custody, export, import, sale, and transfer event, listed explicitly with dates, places, parties, and gaps.

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

- which authentication and provenance checks to pursue and in what order;
- the research method and its key initial assumptions;
- the documentary, technical, or comparative cross-check the route relies on;
- the biggest risk on this route.
</f9>

<f10>
The authentication and provenance assessment lives in `ASSESSMENT.md`, and you may be invoked on it more than once — the pipeline runs you and the forgery-risk reviewer as a loop.

- If `ASSESSMENT.md` does not exist yet, this is the first pass: produce the assessment from scratch.
- If `ASSESSMENT.md` already exists, it carries the forgery-risk reviewer's `<review>` block: read that feedback and revise `ASSESSMENT.md` in place to address every point raised. Don't discard the assessment and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `DOSSIER.md` — the acquisition dossier and its recommendation. Verify it directly against the offered-object file.

- Inspect the reported recommendation for anomalies, unsupported confidence, unreasonable valuation assumptions, missing risk flags, or contradictions in the provenance chronology.
- Write a separate `AUDIT_CHECKLIST.md` that re-checks every required due-diligence condition against the reported dossier, and complete it; name any ownership gaps, document conflicts, or legal-clearance failures.
- Read the dossier and spot-check it for defects — unsupported claims, missing source references, stale assumptions, internal contradictions, or language that downplays a material risk. A defect that quietly makes a risky acquisition look safe is worse than one that is obvious.
- Treat the dossier as finished only when every material authentication, provenance, title, export/import, and ethical issue has been addressed and the recommendation is sound — not merely when the document is polished.
- Check the length of `DOSSIER.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `DOSSIER.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The acquisition dossier and its recommendation live in `DOSSIER.md`, and you may be invoked on it more than once — the pipeline runs you and the due-diligence auditor as a loop.

- If `DOSSIER.md` does not exist yet, this is the first pass: produce the dossier from scratch.
- If `DOSSIER.md` already exists, it carries the due-diligence auditor's `<review>` block: read that feedback and revise `DOSSIER.md` in place to address every point raised. Don't discard the dossier and start over, and don't leave a flagged issue unaddressed.
</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. `# collections coordinator`). Output only the headered prompts, no preamble.


I need you to set up a 5-agent pipeline for museum acquisition due diligence. An offered object's file arrives as a descriptive submission in `object_file.md`, and the pipeline turns it into a vetted authentication and provenance assessment and then a complete acquisition dossier ready for committee review.

The five agents:

- **collections coordinator** orchestrates the run: it drives the assessment loop, then the dossier loop, and tracks progress. It does no authentication, provenance research, dossier drafting, or reviewing itself.
- **assessment loop** — the **provenance researcher** turns the object file into an authentication and provenance assessment with a chosen due-diligence strategy; the **forgery-risk reviewer** attacks the case from the perspective of forgery, misattribution, and weak ownership history. They iterate until the assessment is sound.
- **dossier loop** — the **acquisition dossier writer** prepares the acquisition dossier from the vetted assessment; the **due-diligence auditor** reviews the dossier and tests whether the museum can responsibly proceed. They iterate until the dossier is correct.

The pipeline hands work off through three files:

- `object_file.md` — the original offered-object file, given as input. All four domain agents (provenance researcher, forgery-risk reviewer, acquisition dossier writer, due-diligence auditor) read it.
- `ASSESSMENT.md` — the authentication and provenance assessment. The provenance researcher writes it; the forgery-risk reviewer reviews it; the acquisition dossier writer reads it to prepare the dossier.
- `DOSSIER.md` — the acquisition dossier and its recommendation. The acquisition dossier writer writes it; the due-diligence auditor reviews it.

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

I'm providing the following information:

<f1>
Keep `DOSSIER.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page committee note; record only the final state and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
Which due-diligence method suits which kind of object or risk — use it to choose the strategy:

- **Connoisseurship and stylistic comparison** — useful for paintings, sculpture, decorative arts, and manuscripts with established corpora; weak if the corpus is poorly documented or heavily forged.
- **Technical examination and materials analysis** — pigments, binders, alloy composition, wood dating, paper fiber, ink, tool marks, imaging, and condition structure; strongest when a claimed date or technique can be falsified.
- **Archival provenance research** — dealer records, collection inventories, exhibition catalogues, shipping papers, estate files, photographs, and correspondence; essential for ownership chain and attribution history.
- **Legal title and cultural property screening** — stolen-art databases, sanctions checks, patrimony laws, export permits, import records, and post-1970 UNESCO sensitivity; mandatory for archaeological, ethnographic, and conflict-zone material.
- **Scientific dating** — radiocarbon, thermoluminescence, dendrochronology, or other date testing; powerful for some materials, destructive or inconclusive for others.
- **Artist, foundation, or catalogue raisonné consultation** — valuable when a recognized authentication body exists; can be decisive but may be slow, costly, or unavailable.

Match the checks to the object's category and risk profile; do not force an ill-suited method.
</f2>

<f3>
The acquisition dossier and its recommendation live in `DOSSIER.md`, and you may be invoked on it more than once — the pipeline runs you and the due-diligence auditor as a loop.

- If `DOSSIER.md` does not exist yet, this is the first pass: produce the dossier from scratch.
- If `DOSSIER.md` already exists, it carries the due-diligence auditor's `<review>` block: read that feedback and revise `DOSSIER.md` in place to address every point raised. Don't discard the dossier and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review the assessment in `ASSESSMENT.md`:

- **Case analysis** — does it faithfully capture the offered object and the submitted file? Check that the object category, identity and attribution claims, authentication rationale, provenance chronology, and title-chain gaps are all accurate.
- **Strategy** — are the chosen authentication and provenance checks a sound fit, is the route actually feasible, and is it likely to reach a defensible acquisition recommendation?

Be brief and specific. Do not write the acquisition dossier yourself — only review.
</f4>

<f5>
Review `DOSSIER.md` — the acquisition dossier and its recommendation. Verify it directly against the offered-object file.

- Inspect the reported recommendation for anomalies, unsupported confidence, unreasonable valuation assumptions, missing risk flags, or contradictions in the provenance chronology.
- Write a separate `AUDIT_CHECKLIST.md` that re-checks every required due-diligence condition against the reported dossier, and complete it; name any ownership gaps, document conflicts, or legal-clearance failures.
- Read the dossier and spot-check it for defects — unsupported claims, missing source references, stale assumptions, internal contradictions, or language that downplays a material risk. A defect that quietly makes a risky acquisition look safe is worse than one that is obvious.
- Treat the dossier as finished only when every material authentication, provenance, title, export/import, and ethical issue has been addressed and the recommendation is sound — not merely when the document is polished.
- Check the length of `DOSSIER.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `DOSSIER.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the assessment in `ASSESSMENT.md` and prepare the acquisition dossier in `DOSSIER.md`:

- Include every required section: object identification, acquisition proposal, summary of submitted evidence, authentication conclusion, provenance chronology, title and export/import analysis, condition and conservation concerns, valuation basis, ethical and reputational risks, unresolved questions, and a clear recommendation.
- Carry over the vetted facts exactly. State each ownership event, document reference, date range, attribution, condition issue, and risk flag as the assessment presents it, and do not invent missing links in the chain of title.
- Resolve the recommendation yourself and follow it through to completion — do not stop at a partial outline. If the record exposes a fatal gap, say so plainly and recommend decline or hold pending evidence; do not bury problems in vague language.
- Sanity-check the dossier: a claimed continuous provenance should not contain unexplained decades-long gaps, an export document should not predate the object's alleged discovery, and a high-risk cultural-property object should not be recommended for acquisition without legal clearance.

Write the dossier and its conclusion up in `DOSSIER.md`.
</f6>

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

- **Init** — dispatch the provenance researcher to draft the assessment.
- **Assessment loop** — have the provenance researcher and forgery-risk reviewer iterate on the authentication, provenance, and strategy until the forgery-risk reviewer scores the assessment 10.
- **Dossier loop** — once the assessment is settled, have the acquisition dossier writer and due-diligence auditor iterate on the dossier until the due-diligence auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic'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 the authentication and provenance assessment for the offered object and write it to `ASSESSMENT.md`. A complete assessment has two parts — a structured case analysis and one chosen due-diligence strategy.

The **case analysis** must state:

- **Object category and risk class** — object type, likely date/culture/artist or workshop, and whether the case is low, moderate, high, or prohibitive risk; this must be precise.
- **Submitted evidence** — the key documents, images, labels, invoices, export papers, exhibition history, publication references, conservation reports, and owner statements, with what each one purports to prove.
- **Identity and attribution claims** — the exact claim being evaluated, including title, maker or culture, date range, materials, dimensions, inscriptions, marks, and any claimed findspot or collection history.
- **Authentication rationale** — the evidence supporting or undermining the object's authenticity, attribution, dating, and physical integrity.
- **Provenance and title chain** — every known ownership, custody, export, import, sale, and transfer event, listed explicitly with dates, places, parties, and gaps.

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

- which authentication and provenance checks to pursue and in what order;
- the research method and its key initial assumptions;
- the documentary, technical, or comparative cross-check the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on a museum acquisition due-diligence matter. The offered object may be an archaeological object, painting, sculpture, manuscript, ethnographic item, design object, or mixed-media work. The original offer and supporting materials are given as a natural-language file in `object_file.md`; read it before starting your part.
</f10>

<f11>
The authentication and provenance assessment lives in `ASSESSMENT.md`, and you may be invoked on it more than once — the pipeline runs you and the forgery-risk reviewer as a loop.

- If `ASSESSMENT.md` does not exist yet, this is the first pass: produce the assessment from scratch.
- If `ASSESSMENT.md` already exists, it carries the forgery-risk reviewer's `<review>` block: read that feedback and revise `ASSESSMENT.md` in place to address every point raised. Don't discard the assessment and start over, and don't leave a flagged issue unaddressed.
</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 doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f12>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (collections coordinator, provenance researcher, forgery-risk reviewer, acquisition dossier writer, due-diligence auditor), which items should go in its prompt? Respond with a JSON object like {"collections coordinator": ["f?"], "provenance researcher": ["f?"], "forgery-risk reviewer": ["f?"], "acquisition dossier writer": ["f?"], "due-diligence auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline for museum acquisition due diligence. An offered object's file arrives as a descriptive submission in `object_file.md`, and the pipeline turns it into a vetted authentication and provenance assessment and then a complete acquisition dossier ready for committee review.

The five agents:

- **collections coordinator** orchestrates the run: it drives the assessment loop, then the dossier loop, and tracks progress. It does no authentication, provenance research, dossier drafting, or reviewing itself.
- **assessment loop** — the **provenance researcher** turns the object file into an authentication and provenance assessment with a chosen due-diligence strategy; the **forgery-risk reviewer** attacks the case from the perspective of forgery, misattribution, and weak ownership history. They iterate until the assessment is sound.
- **dossier loop** — the **acquisition dossier writer** prepares the acquisition dossier from the vetted assessment; the **due-diligence auditor** reviews the dossier and tests whether the museum can responsibly proceed. They iterate until the dossier is correct.

The pipeline hands work off through three files:

- `object_file.md` — the original offered-object file, given as input. All four domain agents (provenance researcher, forgery-risk reviewer, acquisition dossier writer, due-diligence auditor) read it.
- `ASSESSMENT.md` — the authentication and provenance assessment. The provenance researcher writes it; the forgery-risk reviewer reviews it; the acquisition dossier writer reads it to prepare the dossier.
- `DOSSIER.md` — the acquisition dossier and its recommendation. The acquisition dossier writer writes it; the due-diligence auditor reviews it.

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

I'm providing the following prompt fragments:

<f1>
Keep `DOSSIER.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page committee note; record only the final state and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

<f2>
Which due-diligence method suits which kind of object or risk — use it to choose the strategy:

- **Connoisseurship and stylistic comparison** — useful for paintings, sculpture, decorative arts, and manuscripts with established corpora; weak if the corpus is poorly documented or heavily forged.
- **Technical examination and materials analysis** — pigments, binders, alloy composition, wood dating, paper fiber, ink, tool marks, imaging, and condition structure; strongest when a claimed date or technique can be falsified.
- **Archival provenance research** — dealer records, collection inventories, exhibition catalogues, shipping papers, estate files, photographs, and correspondence; essential for ownership chain and attribution history.
- **Legal title and cultural property screening** — stolen-art databases, sanctions checks, patrimony laws, export permits, import records, and post-1970 UNESCO sensitivity; mandatory for archaeological, ethnographic, and conflict-zone material.
- **Scientific dating** — radiocarbon, thermoluminescence, dendrochronology, or other date testing; powerful for some materials, destructive or inconclusive for others.
- **Artist, foundation, or catalogue raisonné consultation** — valuable when a recognized authentication body exists; can be decisive but may be slow, costly, or unavailable.

Match the checks to the object's category and risk profile; do not force an ill-suited method.
</f2>

<f3>
The acquisition dossier and its recommendation live in `DOSSIER.md`, and you may be invoked on it more than once — the pipeline runs you and the due-diligence auditor as a loop.

- If `DOSSIER.md` does not exist yet, this is the first pass: produce the dossier from scratch.
- If `DOSSIER.md` already exists, it carries the due-diligence auditor's `<review>` block: read that feedback and revise `DOSSIER.md` in place to address every point raised. Don't discard the dossier and start over, and don't leave a flagged issue unaddressed.
</f3>

<f4>
Review the assessment in `ASSESSMENT.md`:

- **Case analysis** — does it faithfully capture the offered object and the submitted file? Check that the object category, identity and attribution claims, authentication rationale, provenance chronology, and title-chain gaps are all accurate.
- **Strategy** — are the chosen authentication and provenance checks a sound fit, is the route actually feasible, and is it likely to reach a defensible acquisition recommendation?

Be brief and specific. Do not write the acquisition dossier yourself — only review.
</f4>

<f5>
Review `DOSSIER.md` — the acquisition dossier and its recommendation. Verify it directly against the offered-object file.

- Inspect the reported recommendation for anomalies, unsupported confidence, unreasonable valuation assumptions, missing risk flags, or contradictions in the provenance chronology.
- Write a separate `AUDIT_CHECKLIST.md` that re-checks every required due-diligence condition against the reported dossier, and complete it; name any ownership gaps, document conflicts, or legal-clearance failures.
- Read the dossier and spot-check it for defects — unsupported claims, missing source references, stale assumptions, internal contradictions, or language that downplays a material risk. A defect that quietly makes a risky acquisition look safe is worse than one that is obvious.
- Treat the dossier as finished only when every material authentication, provenance, title, export/import, and ethical issue has been addressed and the recommendation is sound — not merely when the document is polished.
- Check the length of `DOSSIER.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `DOSSIER.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the assessment in `ASSESSMENT.md` and prepare the acquisition dossier in `DOSSIER.md`:

- Include every required section: object identification, acquisition proposal, summary of submitted evidence, authentication conclusion, provenance chronology, title and export/import analysis, condition and conservation concerns, valuation basis, ethical and reputational risks, unresolved questions, and a clear recommendation.
- Carry over the vetted facts exactly. State each ownership event, document reference, date range, attribution, condition issue, and risk flag as the assessment presents it, and do not invent missing links in the chain of title.
- Resolve the recommendation yourself and follow it through to completion — do not stop at a partial outline. If the record exposes a fatal gap, say so plainly and recommend decline or hold pending evidence; do not bury problems in vague language.
- Sanity-check the dossier: a claimed continuous provenance should not contain unexplained decades-long gaps, an export document should not predate the object's alleged discovery, and a high-risk cultural-property object should not be recommended for acquisition without legal clearance.

Write the dossier and its conclusion up in `DOSSIER.md`.
</f6>

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

- **Init** — dispatch the provenance researcher to draft the assessment.
- **Assessment loop** — have the provenance researcher and forgery-risk reviewer iterate on the authentication, provenance, and strategy until the forgery-risk reviewer scores the assessment 10.
- **Dossier loop** — once the assessment is settled, have the acquisition dossier writer and due-diligence auditor iterate on the dossier until the due-diligence auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic'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 the authentication and provenance assessment for the offered object and write it to `ASSESSMENT.md`. A complete assessment has two parts — a structured case analysis and one chosen due-diligence strategy.

The **case analysis** must state:

- **Object category and risk class** — object type, likely date/culture/artist or workshop, and whether the case is low, moderate, high, or prohibitive risk; this must be precise.
- **Submitted evidence** — the key documents, images, labels, invoices, export papers, exhibition history, publication references, conservation reports, and owner statements, with what each one purports to prove.
- **Identity and attribution claims** — the exact claim being evaluated, including title, maker or culture, date range, materials, dimensions, inscriptions, marks, and any claimed findspot or collection history.
- **Authentication rationale** — the evidence supporting or undermining the object's authenticity, attribution, dating, and physical integrity.
- **Provenance and title chain** — every known ownership, custody, export, import, sale, and transfer event, listed explicitly with dates, places, parties, and gaps.

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

- which authentication and provenance checks to pursue and in what order;
- the research method and its key initial assumptions;
- the documentary, technical, or comparative cross-check the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on a museum acquisition due-diligence matter. The offered object may be an archaeological object, painting, sculpture, manuscript, ethnographic item, design object, or mixed-media work. The original offer and supporting materials are given as a natural-language file in `object_file.md`; read it before starting your part.
</f10>

<f11>
The authentication and provenance assessment lives in `ASSESSMENT.md`, and you may be invoked on it more than once — the pipeline runs you and the forgery-risk reviewer as a loop.

- If `ASSESSMENT.md` does not exist yet, this is the first pass: produce the assessment from scratch.
- If `ASSESSMENT.md` already exists, it carries the forgery-risk reviewer's `<review>` block: read that feedback and revise `ASSESSMENT.md` in place to address every point raised. Don't discard the assessment and start over, and don't leave a flagged issue unaddressed.
</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 doesn't work, but I'm telling you it doesn't" is still a failing result, not a passing one.
</f12>

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


permitting coordinator
impact assessment lead
regulatory challenge reviewer
EIA report author
permit-compliance auditor

I need you to set up a 5-agent pipeline for an environmental impact assessment for a proposed construction project. Project materials arrive as a natural-language package in `project.md`, and the pipeline turns them into a vetted impact-analysis approach and then a permit-ready EIA report that can withstand regulator-style scrutiny.

The five agents:

- **permitting coordinator** orchestrates the run: it drives the impact-assessment approach loop, then the report loop, and tracks progress. It does no impact analysis, report writing, or reviewing itself.
- **assessment approach loop** — the **impact assessment lead** turns the project materials into a formal assessment scope and evidence strategy; the **regulatory challenge reviewer** reviews it. They iterate until the approach is sound.
- **report loop** — the **EIA report author** writes the permit-ready report from the approved approach; the **permit-compliance auditor** reviews the report and its support. They iterate until the report is complete and defensible.

The pipeline hands work off through three files:

- `project.md` — the original project materials, given as input. All four domain agents read it.
- `ASSESSMENT_PLAN.md` — the impact-analysis approach. The impact assessment lead writes it; the regulatory challenge reviewer reviews it; the EIA report author reads it to prepare the report.
- `EIA_REPORT.md` — the permit-ready environmental impact assessment report and its supporting findings. The EIA report author writes it; the permit-compliance auditor reviews it.

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

I'm providing the following information:

<f1>
Keep `EIA_REPORT.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page permit memorandum; record only the final state and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

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

- **Init** — dispatch the impact assessment lead to draft the assessment approach.
- **Assessment approach loop** — have the impact assessment lead and regulatory challenge reviewer iterate on the scope and evidence strategy until the regulatory challenge reviewer scores the approach 10.
- **Report loop** — once the approach is settled, have the EIA report author and permit-compliance auditor iterate on the report until the permit-compliance auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the reviewer’s `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on an environmental impact assessment for a proposed construction project. The original project materials are given as a natural-language package in `project.md`; read it before starting your part. The materials may describe the site, proposed works, schedule, construction methods, land disturbance, traffic, utilities, sensitive receptors, habitats, water bodies, emissions sources, and any prior studies or agency correspondence.
</f3>

<f4>
Review the impact-analysis approach in `ASSESSMENT_PLAN.md`:

- **Assessment scope** — does it faithfully capture the project and likely environmental review obligations? Check that the project context, baseline data, impact pathways, significance framework, required analyses, and mitigation topics are all accurate and complete.
- **Strategy** — are the chosen methods, surveys, models, guidance, and sequencing a sound fit, is the route actually implementable, and is it likely to produce a permit-ready evidentiary record?

Be brief and specific. Do not write the EIA report yourself — only review.
</f4>

<f5>
Which assessment approach suits which kind of project issue — use it to choose the methods for the strategy:

- **Regulatory checklist and gap analysis** — best for identifying permit triggers, required attachments, agency-specific completeness items, and missing documentation; not enough by itself for technical impact conclusions.
- **GIS constraints and receptor mapping** — best for early screening of wetlands, floodplains, protected habitats, schools, residences, cultural resources, and other sensitive receptors; depends on current, authoritative spatial data.
- **Field surveys and habitat delineation** — necessary where mapped resources are uncertain, protected species habitat may be present, wetlands or watercourses need confirmation, or seasonal conditions affect findings.
- **Construction impact matrix** — useful for linking activities to impacts across noise, dust, traffic, erosion, stormwater, waste, and community disruption; must be backed by project-specific quantities and durations.
- **Quantitative modeling** — appropriate for topics such as air emissions, greenhouse gases, noise, traffic level of service, stormwater runoff, sediment transport, or visual simulations when thresholds or receptors require numerical evidence.
- **Cumulative impact assessment** — needed when the project overlaps with other past, present, or reasonably foreseeable projects affecting the same receptors or resources.
- **Mitigation hierarchy review** — use to test whether the approach avoids impacts first, then minimizes, restores, and only offsets where allowed; weak if mitigation commitments are vague or unenforceable.

Match the methods to the project’s risks and permit pathway; do not force a generic checklist where technical evidence is required.
</f5>

<f6>
Read the approved approach in `ASSESSMENT_PLAN.md` and write the permit-ready report in `EIA_REPORT.md`:

- Include every required report section. Describe the proposed project, existing conditions, assessment methods, impact findings, significance determinations, mitigation measures, monitoring commitments, residual impacts, cumulative impacts, and permit-compliance conclusions.
- Carry over each impact pathway from the assessment scope. For every topic, state the evidence used, the applicable threshold or regulatory criterion, the finding, and the mitigation or monitoring commitment if needed.
- Check the report yourself from start to finish. If a conclusion is unsupported, trace the root cause and fix it; do not bury uncertainty under vague language.
- Sanity-check the findings: a receptor described as sensitive should not be dismissed without evidence, a required permit trigger should not disappear, and mitigation commitments should be specific enough to enforce.

Write the final report and its supporting findings up in `EIA_REPORT.md`.
</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 is incomplete, but I'm telling you it is incomplete" is still a failing result, not a passing one.
</f8>

<f9>
Produce the impact-analysis approach for the project and write it to `ASSESSMENT_PLAN.md`. A complete approach has two parts — a formalized assessment scope and one chosen evidence strategy.

The **assessment scope** must state:

- **Project and permit context** — the project type, likely permitting pathway, jurisdictional triggers, and the decision the assessment must support.
- **Baseline data** — the key environmental setting information and what each item represents, including site conditions, nearby receptors, habitats, water resources, cultural resources if relevant, traffic setting, air/noise baseline, and known data gaps.
- **Impact pathways** — the construction and operational activities that could cause effects, with clear source-pathway-receptor links.
- **Significance framework** — the thresholds, standards, guidance, or professional criteria used to judge whether impacts are minor, significant, or require mitigation.
- **Required analyses and mitigations** — every impact topic to be assessed, the evidence needed for each, and the mitigation or monitoring commitments that must be evaluated.

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

- which assessment methods, models, surveys, agency guidance, and permit checklists to use;
- the sequencing of analyses and key assumptions;
- the screening or scoping rationale the route relies on;
- the biggest risk on this route, such as a missing seasonal survey, unsupported baseline, underestimated cumulative effect, or unclear jurisdictional trigger.
</f9>

<f10>
The impact-analysis approach lives in `ASSESSMENT_PLAN.md`, and you may be invoked on it more than once — the pipeline runs you and the regulatory challenge reviewer as a loop.

- If `ASSESSMENT_PLAN.md` does not exist yet, this is the first pass: produce the assessment approach from scratch.
- If `ASSESSMENT_PLAN.md` already exists, it carries the regulatory challenge reviewer’s `<review>` block: read that feedback and revise `ASSESSMENT_PLAN.md` in place to address every point raised. Don't discard the approach and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `EIA_REPORT.md` — the permit-ready environmental impact assessment report and its supporting findings. Verify it directly against the project materials.

- Inspect the reported findings for anomalies, unsupported dismissals, unreasonable significance conclusions, missing mitigation, or contradictions with the project description.
- Write a separate `compliance_check.md` that re-checks every required topic, permit trigger, impact pathway, threshold, mitigation commitment, and monitoring requirement against the reported conclusions; name any topics that are missing, inconsistent, or unsupported.
- Read the report and spot-check it for defects — unused baseline facts, dead sections, copied boilerplate, mitigation that is too vague to enforce, or conclusions that contradict the evidence. A defect that quietly weakens the permit record is worse than one that is obvious.
- Treat the report as finished only when every required issue is addressed and each conclusion is supported by evidence — not merely when the document reads smoothly.
- Check the length of `EIA_REPORT.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `EIA_REPORT.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The environmental impact assessment report and its supporting findings live in `EIA_REPORT.md`, and you may be invoked on it more than once — the pipeline runs you and the permit-compliance auditor as a loop.

- If `EIA_REPORT.md` does not exist yet, this is the first pass: produce the report from scratch.
- If `EIA_REPORT.md` already exists, it carries the permit-compliance auditor’s `<review>` block: read that feedback and revise `EIA_REPORT.md` in place to address every point raised. Don't discard the report and start over, and don't leave a flagged issue unaddressed.
</f12>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (permitting coordinator, impact assessment lead, regulatory challenge reviewer, EIA report author, permit-compliance auditor), which items should go in its prompt? Respond with a JSON object like {"permitting coordinator": ["f?"], "impact assessment lead": ["f?"], "regulatory challenge reviewer": ["f?"], "EIA report author": ["f?"], "permit-compliance auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline for an environmental impact assessment for a proposed construction project. Project materials arrive as a natural-language package in `project.md`, and the pipeline turns them into a vetted impact-analysis approach and then a permit-ready EIA report that can withstand regulator-style scrutiny.

The five agents:

- **permitting coordinator** orchestrates the run: it drives the impact-assessment approach loop, then the report loop, and tracks progress. It does no impact analysis, report writing, or reviewing itself.
- **assessment approach loop** — the **impact assessment lead** turns the project materials into a formal assessment scope and evidence strategy; the **regulatory challenge reviewer** reviews it. They iterate until the approach is sound.
- **report loop** — the **EIA report author** writes the permit-ready report from the approved approach; the **permit-compliance auditor** reviews the report and its support. They iterate until the report is complete and defensible.

The pipeline hands work off through three files:

- `project.md` — the original project materials, given as input. All four domain agents read it.
- `ASSESSMENT_PLAN.md` — the impact-analysis approach. The impact assessment lead writes it; the regulatory challenge reviewer reviews it; the EIA report author reads it to prepare the report.
- `EIA_REPORT.md` — the permit-ready environmental impact assessment report and its supporting findings. The EIA report author writes it; the permit-compliance auditor reviews it.

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

I'm providing the following prompt fragments:

<f1>
Keep `EIA_REPORT.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page permit memorandum; record only the final state and move iteration-by-iteration history into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

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

- **Init** — dispatch the impact assessment lead to draft the assessment approach.
- **Assessment approach loop** — have the impact assessment lead and regulatory challenge reviewer iterate on the scope and evidence strategy until the regulatory challenge reviewer scores the approach 10.
- **Report loop** — once the approach is settled, have the EIA report author and permit-compliance auditor iterate on the report until the permit-compliance auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the reviewer’s `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on an environmental impact assessment for a proposed construction project. The original project materials are given as a natural-language package in `project.md`; read it before starting your part. The materials may describe the site, proposed works, schedule, construction methods, land disturbance, traffic, utilities, sensitive receptors, habitats, water bodies, emissions sources, and any prior studies or agency correspondence.
</f3>

<f4>
Review the impact-analysis approach in `ASSESSMENT_PLAN.md`:

- **Assessment scope** — does it faithfully capture the project and likely environmental review obligations? Check that the project context, baseline data, impact pathways, significance framework, required analyses, and mitigation topics are all accurate and complete.
- **Strategy** — are the chosen methods, surveys, models, guidance, and sequencing a sound fit, is the route actually implementable, and is it likely to produce a permit-ready evidentiary record?

Be brief and specific. Do not write the EIA report yourself — only review.
</f4>

<f5>
Which assessment approach suits which kind of project issue — use it to choose the methods for the strategy:

- **Regulatory checklist and gap analysis** — best for identifying permit triggers, required attachments, agency-specific completeness items, and missing documentation; not enough by itself for technical impact conclusions.
- **GIS constraints and receptor mapping** — best for early screening of wetlands, floodplains, protected habitats, schools, residences, cultural resources, and other sensitive receptors; depends on current, authoritative spatial data.
- **Field surveys and habitat delineation** — necessary where mapped resources are uncertain, protected species habitat may be present, wetlands or watercourses need confirmation, or seasonal conditions affect findings.
- **Construction impact matrix** — useful for linking activities to impacts across noise, dust, traffic, erosion, stormwater, waste, and community disruption; must be backed by project-specific quantities and durations.
- **Quantitative modeling** — appropriate for topics such as air emissions, greenhouse gases, noise, traffic level of service, stormwater runoff, sediment transport, or visual simulations when thresholds or receptors require numerical evidence.
- **Cumulative impact assessment** — needed when the project overlaps with other past, present, or reasonably foreseeable projects affecting the same receptors or resources.
- **Mitigation hierarchy review** — use to test whether the approach avoids impacts first, then minimizes, restores, and only offsets where allowed; weak if mitigation commitments are vague or unenforceable.

Match the methods to the project’s risks and permit pathway; do not force a generic checklist where technical evidence is required.
</f5>

<f6>
Read the approved approach in `ASSESSMENT_PLAN.md` and write the permit-ready report in `EIA_REPORT.md`:

- Include every required report section. Describe the proposed project, existing conditions, assessment methods, impact findings, significance determinations, mitigation measures, monitoring commitments, residual impacts, cumulative impacts, and permit-compliance conclusions.
- Carry over each impact pathway from the assessment scope. For every topic, state the evidence used, the applicable threshold or regulatory criterion, the finding, and the mitigation or monitoring commitment if needed.
- Check the report yourself from start to finish. If a conclusion is unsupported, trace the root cause and fix it; do not bury uncertainty under vague language.
- Sanity-check the findings: a receptor described as sensitive should not be dismissed without evidence, a required permit trigger should not disappear, and mitigation commitments should be specific enough to enforce.

Write the final report and its supporting findings up in `EIA_REPORT.md`.
</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 is incomplete, but I'm telling you it is incomplete" is still a failing result, not a passing one.
</f8>

<f9>
Produce the impact-analysis approach for the project and write it to `ASSESSMENT_PLAN.md`. A complete approach has two parts — a formalized assessment scope and one chosen evidence strategy.

The **assessment scope** must state:

- **Project and permit context** — the project type, likely permitting pathway, jurisdictional triggers, and the decision the assessment must support.
- **Baseline data** — the key environmental setting information and what each item represents, including site conditions, nearby receptors, habitats, water resources, cultural resources if relevant, traffic setting, air/noise baseline, and known data gaps.
- **Impact pathways** — the construction and operational activities that could cause effects, with clear source-pathway-receptor links.
- **Significance framework** — the thresholds, standards, guidance, or professional criteria used to judge whether impacts are minor, significant, or require mitigation.
- **Required analyses and mitigations** — every impact topic to be assessed, the evidence needed for each, and the mitigation or monitoring commitments that must be evaluated.

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

- which assessment methods, models, surveys, agency guidance, and permit checklists to use;
- the sequencing of analyses and key assumptions;
- the screening or scoping rationale the route relies on;
- the biggest risk on this route, such as a missing seasonal survey, unsupported baseline, underestimated cumulative effect, or unclear jurisdictional trigger.
</f9>

<f10>
The impact-analysis approach lives in `ASSESSMENT_PLAN.md`, and you may be invoked on it more than once — the pipeline runs you and the regulatory challenge reviewer as a loop.

- If `ASSESSMENT_PLAN.md` does not exist yet, this is the first pass: produce the assessment approach from scratch.
- If `ASSESSMENT_PLAN.md` already exists, it carries the regulatory challenge reviewer’s `<review>` block: read that feedback and revise `ASSESSMENT_PLAN.md` in place to address every point raised. Don't discard the approach and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `EIA_REPORT.md` — the permit-ready environmental impact assessment report and its supporting findings. Verify it directly against the project materials.

- Inspect the reported findings for anomalies, unsupported dismissals, unreasonable significance conclusions, missing mitigation, or contradictions with the project description.
- Write a separate `compliance_check.md` that re-checks every required topic, permit trigger, impact pathway, threshold, mitigation commitment, and monitoring requirement against the reported conclusions; name any topics that are missing, inconsistent, or unsupported.
- Read the report and spot-check it for defects — unused baseline facts, dead sections, copied boilerplate, mitigation that is too vague to enforce, or conclusions that contradict the evidence. A defect that quietly weakens the permit record is worse than one that is obvious.
- Treat the report as finished only when every required issue is addressed and each conclusion is supported by evidence — not merely when the document reads smoothly.
- Check the length of `EIA_REPORT.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `EIA_REPORT.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The environmental impact assessment report and its supporting findings live in `EIA_REPORT.md`, and you may be invoked on it more than once — the pipeline runs you and the permit-compliance auditor as a loop.

- If `EIA_REPORT.md` does not exist yet, this is the first pass: produce the report from scratch.
- If `EIA_REPORT.md` already exists, it carries the permit-compliance auditor’s `<review>` block: read that feedback and revise `EIA_REPORT.md` in place to address every point raised. Don't discard the report and start over, and don't leave a flagged issue unaddressed.
</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. `# permitting coordinator`). Output only the headered prompts, no preamble.