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

<f3>
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.
</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>
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.
</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>
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.
</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 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>
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.
</f10>

<f11>
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.
</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 is incomplete, but I'm telling you it is incomplete" 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 (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>
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.
</f2>

<f3>
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.
</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>
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.
</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>
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.
</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 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>
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.
</f10>

<f11>
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.
</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 is incomplete, but I'm telling you it is incomplete" 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. `# permitting coordinator`). Output only the headered prompts, no preamble.


litigation-manager lead-strategist argument-developer moot-court-judge motion-drafter opposing-counsel-proxy

I need you to set up a 6-agent pipeline that drafts a comprehensive legal defense strategy and finalizes the exact court motions to survive summary judgment in a high-stakes corporate litigation case. A case arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then fully drafted, verified court motions.

The six agents:

- **litigation-manager** orchestrates the run: it drives the plan phase, then the drafting phase, and tracks progress. It does no legal analysis, drafting, or reviewing itself.
- **lead-strategist** is invoked once at init and produces K differentiated candidate plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **argument-developer** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the moot-court-judge's last review for that plan. It never creates new plans.
- **moot-court-judge** reviews the plan it is currently assigned to.
- **motion-drafter** drafts the court motions for the plan it is currently assigned to.
- **opposing-counsel-proxy** reviews the drafted motions and arguments of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original case statement, given as input. All five domain agents (lead-strategist, argument-developer, moot-court-judge, motion-drafter, opposing-counsel-proxy) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The lead-strategist writes K differentiated candidates at init; the argument-developer revises a specific assigned plan in the loop; the moot-court-judge reviews the plan it is assigned to; the motion-drafter reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the drafted motions and arguments for that plan. The motion-drafter writes it; the opposing-counsel-proxy reviews it.

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

The litigation-manager round-robins across the K plans, first in a plan phase (each plan iterates its argument-developer ↔ moot-court-judge loop) and then in a drafting phase (each plan iterates its motion-drafter ↔ opposing-counsel-proxy loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following information:

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

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

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

<f3>
You are working on a high-stakes corporate litigation case — it may involve breach of contract, antitrust, intellectual property, or a combination. The original case fact pattern is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

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

- **Case theory** — does it faithfully capture the case? Check that the litigation type, legal elements, vulnerabilities, and defenses are all accurate.
- **Strategy** — is the chosen precedent and procedural mechanism a sound fit, is the route actually arguable in court, and is it likely to survive summary judgment?

Be brief and specific. Do not write any motion drafts yourself — only review.
</f4>

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

- **Chevron / Loper Bright** — Administrative law and agency deference only; no private contract support.
- **Twombly / Iqbal** — Pleading standards for all federal civil claims; the broadest coverage for early dismissal.
- **Alice / Mayo** — Patent eligibility and abstract ideas.
- **Rule 12(b)(6) versus Rule 56** — Use 12(b)(6) for facial insufficiency; Rule 56 when relying on undisputed facts to defeat claims pre-trial.
- **Statute of Limitations / Laches** — The strongest absolute bar for stale claims; fails if tolling applies.
- **Force Majeure / Impracticability** — Contractual non-performance defense.

Match the precedent to the litigation type; do not force an ill-suited one.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as drafted court motions:

- Include every required section. Draft the introduction, define the statement of undisputed material facts and every legal argument exactly as the case theory states, construct the argument, cite the law, and draft the conclusion and proposed order.
- Read through the drafted motion yourself and verify it against the local rules — do not stop while it is incomplete. If an argument is legally unsupported, find and fix the root cause; do not bury weak points under aggressive rhetoric.
- Sanity-check the logic: a timeline that must be chronological should not jump around confusingly.

Write the motions and their supporting memos up in your assigned plan's `SOLUTION.md`. Do not read or touch other plans' files.
</f6>

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

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

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

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

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

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

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

A complete plan in any `PLAN.md` has two parts — a formalized case theory and one chosen defense strategy.

The **case theory** must state:

- **Litigation type** — Antitrust, IP infringement, breach of contract, etc.; this must be exact.
- **Evidence** — the key factual inputs and what each document or testimony represents.
- **Legal elements** — the elements the plaintiff must prove, with descriptive definitions.
- **Vulnerabilities** — the exact weaknesses in the plaintiff's arguments to exploit.
- **Defenses** — every affirmative defense, listed explicitly.

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

- which legal precedent to use and how to apply it;
- the procedural mechanism and its key initial arguments;
- the legal nuance or procedural trick the route relies on;
- the biggest risk on this route.
</f9>

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

<f11>
Review your assigned plan's `SOLUTION.md` — the drafted court motions and arguments. Verify it directly against the case statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the drafted arguments for logical leaps, misstated facts, or waived defenses.
- Write a separate `verify.py` script under the plan's directory that parses the citations and cross-checks every legal element against the drafted arguments, and run it; name any claims that lack a proper defense.
- Read the drafted motions and spot-check them for flaws — unused precedents, dead-end arguments, rhetoric that contradicts what the brief claims it proves. A legal flaw that silently weakens the defense is worse than a formatting error.
- Treat the draft as finished only when every legal element is defended and the core argument is sound — not merely when the document is fully formatted.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your drafted court motions and arguments live in your assigned plan's `SOLUTION.md`.

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (litigation-manager, lead-strategist, argument-developer, moot-court-judge, motion-drafter, opposing-counsel-proxy), which items should go in its prompt? Respond with a JSON object like {"litigation-manager": ["f?"], "lead-strategist": ["f?"], "argument-developer": ["f?"], "moot-court-judge": ["f?"], "motion-drafter": ["f?"], "opposing-counsel-proxy": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline that drafts a comprehensive legal defense strategy and finalizes the exact court motions to survive summary judgment in a high-stakes corporate litigation case. A case arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then fully drafted, verified court motions.

The six agents:

- **litigation-manager** orchestrates the run: it drives the plan phase, then the drafting phase, and tracks progress. It does no legal analysis, drafting, or reviewing itself.
- **lead-strategist** is invoked once at init and produces K differentiated candidate plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **argument-developer** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the moot-court-judge's last review for that plan. It never creates new plans.
- **moot-court-judge** reviews the plan it is currently assigned to.
- **motion-drafter** drafts the court motions for the plan it is currently assigned to.
- **opposing-counsel-proxy** reviews the drafted motions and arguments of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original case statement, given as input. All five domain agents (lead-strategist, argument-developer, moot-court-judge, motion-drafter, opposing-counsel-proxy) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The lead-strategist writes K differentiated candidates at init; the argument-developer revises a specific assigned plan in the loop; the moot-court-judge reviews the plan it is assigned to; the motion-drafter reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the drafted motions and arguments for that plan. The motion-drafter writes it; the opposing-counsel-proxy reviews it.

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

The litigation-manager round-robins across the K plans, first in a plan phase (each plan iterates its argument-developer ↔ moot-court-judge loop) and then in a drafting phase (each plan iterates its motion-drafter ↔ opposing-counsel-proxy loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following prompt fragments:

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

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

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

<f3>
You are working on a high-stakes corporate litigation case — it may involve breach of contract, antitrust, intellectual property, or a combination. The original case fact pattern is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

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

- **Case theory** — does it faithfully capture the case? Check that the litigation type, legal elements, vulnerabilities, and defenses are all accurate.
- **Strategy** — is the chosen precedent and procedural mechanism a sound fit, is the route actually arguable in court, and is it likely to survive summary judgment?

Be brief and specific. Do not write any motion drafts yourself — only review.
</f4>

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

- **Chevron / Loper Bright** — Administrative law and agency deference only; no private contract support.
- **Twombly / Iqbal** — Pleading standards for all federal civil claims; the broadest coverage for early dismissal.
- **Alice / Mayo** — Patent eligibility and abstract ideas.
- **Rule 12(b)(6) versus Rule 56** — Use 12(b)(6) for facial insufficiency; Rule 56 when relying on undisputed facts to defeat claims pre-trial.
- **Statute of Limitations / Laches** — The strongest absolute bar for stale claims; fails if tolling applies.
- **Force Majeure / Impracticability** — Contractual non-performance defense.

Match the precedent to the litigation type; do not force an ill-suited one.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as drafted court motions:

- Include every required section. Draft the introduction, define the statement of undisputed material facts and every legal argument exactly as the case theory states, construct the argument, cite the law, and draft the conclusion and proposed order.
- Read through the drafted motion yourself and verify it against the local rules — do not stop while it is incomplete. If an argument is legally unsupported, find and fix the root cause; do not bury weak points under aggressive rhetoric.
- Sanity-check the logic: a timeline that must be chronological should not jump around confusingly.

Write the motions and their supporting memos up in your assigned plan's `SOLUTION.md`. Do not read or touch other plans' files.
</f6>

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

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

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

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

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

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

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

A complete plan in any `PLAN.md` has two parts — a formalized case theory and one chosen defense strategy.

The **case theory** must state:

- **Litigation type** — Antitrust, IP infringement, breach of contract, etc.; this must be exact.
- **Evidence** — the key factual inputs and what each document or testimony represents.
- **Legal elements** — the elements the plaintiff must prove, with descriptive definitions.
- **Vulnerabilities** — the exact weaknesses in the plaintiff's arguments to exploit.
- **Defenses** — every affirmative defense, listed explicitly.

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

- which legal precedent to use and how to apply it;
- the procedural mechanism and its key initial arguments;
- the legal nuance or procedural trick the route relies on;
- the biggest risk on this route.
</f9>

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

<f11>
Review your assigned plan's `SOLUTION.md` — the drafted court motions and arguments. Verify it directly against the case statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the drafted arguments for logical leaps, misstated facts, or waived defenses.
- Write a separate `verify.py` script under the plan's directory that parses the citations and cross-checks every legal element against the drafted arguments, and run it; name any claims that lack a proper defense.
- Read the drafted motions and spot-check them for flaws — unused precedents, dead-end arguments, rhetoric that contradicts what the brief claims it proves. A legal flaw that silently weakens the defense is worse than a formatting error.
- Treat the draft as finished only when every legal element is defended and the core argument is sound — not merely when the document is fully formatted.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your drafted court motions and arguments live in your assigned plan's `SOLUTION.md`.

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

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


I need you to set up a 6-agent pipeline that drafts a comprehensive legal defense strategy and finalizes the exact court motions to survive summary judgment in a high-stakes corporate litigation case. A case arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then fully drafted, verified court motions.

The six agents:

- **litigation-manager** orchestrates the run: it drives the plan phase, then the drafting phase, and tracks progress. It does no legal analysis, drafting, or reviewing itself.
- **lead-strategist** is invoked once at init and produces K differentiated candidate plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **argument-developer** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the moot-court-judge's last review for that plan. It never creates new plans.
- **moot-court-judge** reviews the plan it is currently assigned to.
- **motion-drafter** drafts the court motions for the plan it is currently assigned to.
- **opposing-counsel-proxy** reviews the drafted motions and arguments of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original case statement, given as input. All five domain agents (lead-strategist, argument-developer, moot-court-judge, motion-drafter, opposing-counsel-proxy) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The lead-strategist writes K differentiated candidates at init; the argument-developer revises a specific assigned plan in the loop; the moot-court-judge reviews the plan it is assigned to; the motion-drafter reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the drafted motions and arguments for that plan. The motion-drafter writes it; the opposing-counsel-proxy reviews it.

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

The litigation-manager round-robins across the K plans, first in a plan phase (each plan iterates its argument-developer ↔ moot-court-judge loop) and then in a drafting phase (each plan iterates its motion-drafter ↔ opposing-counsel-proxy loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following information:

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

<f2>
Which precedent suits which kind of litigation — use it to choose one for the strategy:

- **Chevron / Loper Bright** — Administrative law and agency deference only; no private contract support.
- **Twombly / Iqbal** — Pleading standards for all federal civil claims; the broadest coverage for early dismissal.
- **Alice / Mayo** — Patent eligibility and abstract ideas.
- **Rule 12(b)(6) versus Rule 56** — Use 12(b)(6) for facial insufficiency; Rule 56 when relying on undisputed facts to defeat claims pre-trial.
- **Statute of Limitations / Laches** — The strongest absolute bar for stale claims; fails if tolling applies.
- **Force Majeure / Impracticability** — Contractual non-performance defense.

Match the precedent to the litigation type; do not force an ill-suited one.
</f2>

<f3>
Your drafted court motions and arguments live in your assigned plan's `SOLUTION.md`.

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

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

- **Case theory** — does it faithfully capture the case? Check that the litigation type, legal elements, vulnerabilities, and defenses are all accurate.
- **Strategy** — is the chosen precedent and procedural mechanism a sound fit, is the route actually arguable in court, and is it likely to survive summary judgment?

Be brief and specific. Do not write any motion drafts yourself — only review.
</f4>

<f5>
Review your assigned plan's `SOLUTION.md` — the drafted court motions and arguments. Verify it directly against the case statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the drafted arguments for logical leaps, misstated facts, or waived defenses.
- Write a separate `verify.py` script under the plan's directory that parses the citations and cross-checks every legal element against the drafted arguments, and run it; name any claims that lack a proper defense.
- Read the drafted motions and spot-check them for flaws — unused precedents, dead-end arguments, rhetoric that contradicts what the brief claims it proves. A legal flaw that silently weakens the defense is worse than a formatting error.
- Treat the draft as finished only when every legal element is defended and the core argument is sound — not merely when the document is fully formatted.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as drafted court motions:

- Include every required section. Draft the introduction, define the statement of undisputed material facts and every legal argument exactly as the case theory states, construct the argument, cite the law, and draft the conclusion and proposed order.
- Read through the drafted motion yourself and verify it against the local rules — do not stop while it is incomplete. If an argument is legally unsupported, find and fix the root cause; do not bury weak points under aggressive rhetoric.
- Sanity-check the logic: a timeline that must be chronological should not jump around confusingly.

Write the motions and their supporting memos up in your assigned plan's `SOLUTION.md`. Do not read or touch other plans' files.
</f6>

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

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

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

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

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

A complete plan in any `PLAN.md` has two parts — a formalized case theory and one chosen defense strategy.

The **case theory** must state:

- **Litigation type** — Antitrust, IP infringement, breach of contract, etc.; this must be exact.
- **Evidence** — the key factual inputs and what each document or testimony represents.
- **Legal elements** — the elements the plaintiff must prove, with descriptive definitions.
- **Vulnerabilities** — the exact weaknesses in the plaintiff's arguments to exploit.
- **Defenses** — every affirmative defense, listed explicitly.

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

- which legal precedent to use and how to apply it;
- the procedural mechanism and its key initial arguments;
- the legal nuance or procedural trick the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on a high-stakes corporate litigation case — it may involve breach of contract, antitrust, intellectual property, or a combination. The original case fact pattern is given as a natural-language statement in `problem.md`; read it before starting your part.
</f10>

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

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

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this argument fails, but I'm telling you it fails" 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 (litigation-manager, lead-strategist, argument-developer, moot-court-judge, motion-drafter, opposing-counsel-proxy), which items should go in its prompt? Respond with a JSON object like {"litigation-manager": ["f?"], "lead-strategist": ["f?"], "argument-developer": ["f?"], "moot-court-judge": ["f?"], "motion-drafter": ["f?"], "opposing-counsel-proxy": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline that drafts a comprehensive legal defense strategy and finalizes the exact court motions to survive summary judgment in a high-stakes corporate litigation case. A case arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted plan and then fully drafted, verified court motions.

The six agents:

- **litigation-manager** orchestrates the run: it drives the plan phase, then the drafting phase, and tracks progress. It does no legal analysis, drafting, or reviewing itself.
- **lead-strategist** is invoked once at init and produces K differentiated candidate plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **argument-developer** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the moot-court-judge's last review for that plan. It never creates new plans.
- **moot-court-judge** reviews the plan it is currently assigned to.
- **motion-drafter** drafts the court motions for the plan it is currently assigned to.
- **opposing-counsel-proxy** reviews the drafted motions and arguments of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original case statement, given as input. All five domain agents (lead-strategist, argument-developer, moot-court-judge, motion-drafter, opposing-counsel-proxy) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The lead-strategist writes K differentiated candidates at init; the argument-developer revises a specific assigned plan in the loop; the moot-court-judge reviews the plan it is assigned to; the motion-drafter reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the drafted motions and arguments for that plan. The motion-drafter writes it; the opposing-counsel-proxy reviews it.

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

The litigation-manager round-robins across the K plans, first in a plan phase (each plan iterates its argument-developer ↔ moot-court-judge loop) and then in a drafting phase (each plan iterates its motion-drafter ↔ opposing-counsel-proxy loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following prompt fragments:

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

<f2>
Which precedent suits which kind of litigation — use it to choose one for the strategy:

- **Chevron / Loper Bright** — Administrative law and agency deference only; no private contract support.
- **Twombly / Iqbal** — Pleading standards for all federal civil claims; the broadest coverage for early dismissal.
- **Alice / Mayo** — Patent eligibility and abstract ideas.
- **Rule 12(b)(6) versus Rule 56** — Use 12(b)(6) for facial insufficiency; Rule 56 when relying on undisputed facts to defeat claims pre-trial.
- **Statute of Limitations / Laches** — The strongest absolute bar for stale claims; fails if tolling applies.
- **Force Majeure / Impracticability** — Contractual non-performance defense.

Match the precedent to the litigation type; do not force an ill-suited one.
</f2>

<f3>
Your drafted court motions and arguments live in your assigned plan's `SOLUTION.md`.

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

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

- **Case theory** — does it faithfully capture the case? Check that the litigation type, legal elements, vulnerabilities, and defenses are all accurate.
- **Strategy** — is the chosen precedent and procedural mechanism a sound fit, is the route actually arguable in court, and is it likely to survive summary judgment?

Be brief and specific. Do not write any motion drafts yourself — only review.
</f4>

<f5>
Review your assigned plan's `SOLUTION.md` — the drafted court motions and arguments. Verify it directly against the case statement. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the drafted arguments for logical leaps, misstated facts, or waived defenses.
- Write a separate `verify.py` script under the plan's directory that parses the citations and cross-checks every legal element against the drafted arguments, and run it; name any claims that lack a proper defense.
- Read the drafted motions and spot-check them for flaws — unused precedents, dead-end arguments, rhetoric that contradicts what the brief claims it proves. A legal flaw that silently weakens the defense is worse than a formatting error.
- Treat the draft as finished only when every legal element is defended and the core argument is sound — not merely when the document is fully formatted.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as drafted court motions:

- Include every required section. Draft the introduction, define the statement of undisputed material facts and every legal argument exactly as the case theory states, construct the argument, cite the law, and draft the conclusion and proposed order.
- Read through the drafted motion yourself and verify it against the local rules — do not stop while it is incomplete. If an argument is legally unsupported, find and fix the root cause; do not bury weak points under aggressive rhetoric.
- Sanity-check the logic: a timeline that must be chronological should not jump around confusingly.

Write the motions and their supporting memos up in your assigned plan's `SOLUTION.md`. Do not read or touch other plans' files.
</f6>

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

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

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

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

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

A complete plan in any `PLAN.md` has two parts — a formalized case theory and one chosen defense strategy.

The **case theory** must state:

- **Litigation type** — Antitrust, IP infringement, breach of contract, etc.; this must be exact.
- **Evidence** — the key factual inputs and what each document or testimony represents.
- **Legal elements** — the elements the plaintiff must prove, with descriptive definitions.
- **Vulnerabilities** — the exact weaknesses in the plaintiff's arguments to exploit.
- **Defenses** — every affirmative defense, listed explicitly.

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

- which legal precedent to use and how to apply it;
- the procedural mechanism and its key initial arguments;
- the legal nuance or procedural trick the route relies on;
- the biggest risk on this route.
</f9>

<f10>
You are working on a high-stakes corporate litigation case — it may involve breach of contract, antitrust, intellectual property, or a combination. The original case fact pattern is given as a natural-language statement in `problem.md`; read it before starting your part.
</f10>

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

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

Score strictly on real merit. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this argument fails, but I'm telling you it fails" 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. `# litigation-manager`). Output only the headered prompts, no preamble.


research-director pathway-architect molecule-optimizer binding-skeptic protocol-author toxicology-auditor

I need you to set up a 6-agent pipeline that designs a novel biochemical therapeutic targeting a specific evaluationular receptor and details the rigorous laboratory synthesis protocol to safely produce it. A therapeutic target arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted molecular design plan and then a working, verified synthesis protocol.

The six agents:

- **research-director** orchestrates the run: it drives the plan phase, then the protocol phase, and tracks progress. It does no molecular design, protocol authoring, or reviewing itself.
- **pathway-architect** is invoked once at init and produces K differentiated candidate plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **molecule-optimizer** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the binding-skeptic's last review for that plan. It never creates new plans.
- **binding-skeptic** reviews the plan it is currently assigned to.
- **protocol-author** implements the strategy as a synthesis protocol for the plan it is currently assigned to.
- **toxicology-auditor** reviews the synthesis protocol and resultant yields/purity of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original therapeutic target description, given as input. All five domain agents (pathway-architect, molecule-optimizer, binding-skeptic, protocol-author, toxicology-auditor) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The pathway-architect writes K differentiated candidates at init; the molecule-optimizer revises a specific assigned plan in the loop; the binding-skeptic reviews the plan it is assigned to; the protocol-author reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the laboratory synthesis protocol and simulated results for that plan. The protocol-author writes it; the toxicology-auditor reviews it.

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

The research-director round-robins across the K plans, first in a plan phase (each plan iterates its molecule-optimizer ↔ binding-skeptic loop) and then in a protocol phase (each plan iterates its protocol-author ↔ toxicology-auditor loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following information:

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

<f2>
You orchestrate the run; you never design molecules, author protocols, or review yourself — you only dispatch the right agent at the right time.

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

<f3>
You are working on designing a novel biochemical therapeutic targeting a specific evaluationular receptor — it may involve small molecules, peptides, monoclonal antibodies, or a combination. The original therapeutic target description is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

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

- **Molecular design** — does it faithfully capture the target therapeutic profile? Check that the therapeutic modality, active motifs, binding mechanism, and design constraints are all accurate.
- **Strategy** — is the chosen synthesis platform and reaction sequence a sound fit, is the route actually implementable in a lab, and is it likely to safely reach the correct molecule?

Be brief and specific. Do not write any synthesis protocols yourself — only review.
</f4>

<f5>
Which synthesis or modeling platform suits which kind of therapeutic — use it to choose one for the strategy:

- **AutoDock Vina** — Small molecule docking and binding only; no large protein support.
- **Rosetta** — Peptides, mAbs, and complex protein structures; the broadest coverage for macro-molecules.
- **CRISPR-Cas9 Expression** — Biological synthesis of proteins; not for synthetic small molecules.
- **Solid-Phase Peptide Synthesis (SPPS)** — Top performance on linear peptides; requires hazardous reagents; not for full-sized antibodies.
- **Click Chemistry** — The strongest option for highly specific conjugations (like ADCs); can be slower or lower yield than standard bioconjugation if not optimized.
- **GROMACS** — Large-scale molecular dynamics and solvated systems.

Match the platform to the therapeutic modality; do not force an ill-suited one.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as a rigorous laboratory synthesis protocol:

- Include every reagent and solvent. Detail each reaction step with the correct stoichiometry, temperatures, and times. Define the purification steps and analytical checks exactly as the molecular design dictates, simulate the protocol, check the simulated purity and yield, and print both the chemical profile and the final yield percentage.
- Run the simulation yourself and watch it through to completion — do not stop while it is still running. If it errors (e.g., thermal runaway or precipitation), find and fix the root cause; do not bury errors under ignored warnings.
- Sanity-check the answer: an atom count in the molecular formula that must be a whole number should not come back as a physically impossible fraction, and the theoretical yield must not exceed 100%.

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

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

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

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

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

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

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

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

A complete plan in any `PLAN.md` has two parts — a formalized molecular design and one chosen synthesis strategy.

The **molecular design** must state:

- **Therapeutic modality** — Small molecule, peptide, mAb, ADC, etc.; this must be exact.
- **Target receptor** — the key evaluationular receptor inputs and what domain it binds to.
- **Active motifs** — their structures and intended binding affinities, with descriptive names.
- **Binding mechanism** — the exact mechanism of action to optimize.
- **Design constraints** — every constraint (e.g., molecular weight limits, logP, toxicity thresholds), listed explicitly.

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

- which biochemical synthesis or expression platform to use and how to run it;
- the core reactions and key initial reaction conditions (e.g., temperature, solvents);
- the specific chemical reformulation, catalyst, or biological expression trick the route relies on;
- the biggest safety or yield risk on this route.
</f9>

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

<f11>
Review your assigned plan's `SOLUTION.md` — the laboratory synthesis protocol and its simulated results. Verify it directly against the therapeutic target description. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable yields, or toxicity/design constraint violations.
- Write a separate `verify.py` under the plan's directory that programmatically re-checks every molecular design constraint against the reported solution's chemical properties, and run it; name any components that violate a constraint.
- Read the synthesis protocol and spot-check it for bugs — unused reagents, dead-end reactions, laboratory logic that contradicts what the solution says it does. A procedural flaw that silently degrades the purity is worse than one that overtly fails the simulation.
- Treat the result as finished only when every design constraint holds and the yield/purity is sound — not merely when the simulation runs without error.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your laboratory synthesis protocol and its results live in your assigned plan's `SOLUTION.md`.

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (research-director, pathway-architect, molecule-optimizer, binding-skeptic, protocol-author, toxicology-auditor), which items should go in its prompt? Respond with a JSON object like {"research-director": ["f?"], "pathway-architect": ["f?"], "molecule-optimizer": ["f?"], "binding-skeptic": ["f?"], "protocol-author": ["f?"], "toxicology-auditor": ["f?"]}. No other output.

I need you to set up a 6-agent pipeline that designs a novel biochemical therapeutic targeting a specific evaluationular receptor and details the rigorous laboratory synthesis protocol to safely produce it. A therapeutic target arrives as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted molecular design plan and then a working, verified synthesis protocol.

The six agents:

- **research-director** orchestrates the run: it drives the plan phase, then the protocol phase, and tracks progress. It does no molecular design, protocol authoring, or reviewing itself.
- **pathway-architect** is invoked once at init and produces K differentiated candidate plans, one per `plans/{id}-{slug}/PLAN.md`. It never enters the per-plan revision loop.
- **molecule-optimizer** is invoked once per plan-refinement step in the loop. It revises a single assigned plan's `PLAN.md` based on the binding-skeptic's last review for that plan. It never creates new plans.
- **binding-skeptic** reviews the plan it is currently assigned to.
- **protocol-author** implements the strategy as a synthesis protocol for the plan it is currently assigned to.
- **toxicology-auditor** reviews the synthesis protocol and resultant yields/purity of the plan it is currently assigned to.

The pipeline hands work off through plan-namespaced files:

- `problem.md` — the original therapeutic target description, given as input. All five domain agents (pathway-architect, molecule-optimizer, binding-skeptic, protocol-author, toxicology-auditor) read it.
- `plans/{id}-{slug}/PLAN.md` — one plan per directory, K plans total. The pathway-architect writes K differentiated candidates at init; the molecule-optimizer revises a specific assigned plan in the loop; the binding-skeptic reviews the plan it is assigned to; the protocol-author reads the plan it is assigned to.
- `plans/{id}-{slug}/SOLUTION.md` — the laboratory synthesis protocol and simulated results for that plan. The protocol-author writes it; the toxicology-auditor reviews it.

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

The research-director round-robins across the K plans, first in a plan phase (each plan iterates its molecule-optimizer ↔ binding-skeptic loop) and then in a protocol phase (each plan iterates its protocol-author ↔ toxicology-auditor loop). Cross-plan reading does not happen: an agent assigned to one plan never reads another plan's files.

I'm providing the following prompt fragments:

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

<f2>
You orchestrate the run; you never design molecules, author protocols, or review yourself — you only dispatch the right agent at the right time.

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

<f3>
You are working on designing a novel biochemical therapeutic targeting a specific evaluationular receptor — it may involve small molecules, peptides, monoclonal antibodies, or a combination. The original therapeutic target description is given as a natural-language statement in `problem.md`; read it before starting your part.
</f3>

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

- **Molecular design** — does it faithfully capture the target therapeutic profile? Check that the therapeutic modality, active motifs, binding mechanism, and design constraints are all accurate.
- **Strategy** — is the chosen synthesis platform and reaction sequence a sound fit, is the route actually implementable in a lab, and is it likely to safely reach the correct molecule?

Be brief and specific. Do not write any synthesis protocols yourself — only review.
</f4>

<f5>
Which synthesis or modeling platform suits which kind of therapeutic — use it to choose one for the strategy:

- **AutoDock Vina** — Small molecule docking and binding only; no large protein support.
- **Rosetta** — Peptides, mAbs, and complex protein structures; the broadest coverage for macro-molecules.
- **CRISPR-Cas9 Expression** — Biological synthesis of proteins; not for synthetic small molecules.
- **Solid-Phase Peptide Synthesis (SPPS)** — Top performance on linear peptides; requires hazardous reagents; not for full-sized antibodies.
- **Click Chemistry** — The strongest option for highly specific conjugations (like ADCs); can be slower or lower yield than standard bioconjugation if not optimized.
- **GROMACS** — Large-scale molecular dynamics and solvated systems.

Match the platform to the therapeutic modality; do not force an ill-suited one.
</f5>

<f6>
Read the plan in your assigned plan's `PLAN.md` and implement its strategy as a rigorous laboratory synthesis protocol:

- Include every reagent and solvent. Detail each reaction step with the correct stoichiometry, temperatures, and times. Define the purification steps and analytical checks exactly as the molecular design dictates, simulate the protocol, check the simulated purity and yield, and print both the chemical profile and the final yield percentage.
- Run the simulation yourself and watch it through to completion — do not stop while it is still running. If it errors (e.g., thermal runaway or precipitation), find and fix the root cause; do not bury errors under ignored warnings.
- Sanity-check the answer: an atom count in the molecular formula that must be a whole number should not come back as a physically impossible fraction, and the theoretical yield must not exceed 100%.

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

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

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

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

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

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

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

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

A complete plan in any `PLAN.md` has two parts — a formalized molecular design and one chosen synthesis strategy.

The **molecular design** must state:

- **Therapeutic modality** — Small molecule, peptide, mAb, ADC, etc.; this must be exact.
- **Target receptor** — the key evaluationular receptor inputs and what domain it binds to.
- **Active motifs** — their structures and intended binding affinities, with descriptive names.
- **Binding mechanism** — the exact mechanism of action to optimize.
- **Design constraints** — every constraint (e.g., molecular weight limits, logP, toxicity thresholds), listed explicitly.

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

- which biochemical synthesis or expression platform to use and how to run it;
- the core reactions and key initial reaction conditions (e.g., temperature, solvents);
- the specific chemical reformulation, catalyst, or biological expression trick the route relies on;
- the biggest safety or yield risk on this route.
</f9>

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

<f11>
Review your assigned plan's `SOLUTION.md` — the laboratory synthesis protocol and its simulated results. Verify it directly against the therapeutic target description. Operate strictly on the assigned plan; do not look at other plans.

- Inspect the reported result for anomalies, unreasonable yields, or toxicity/design constraint violations.
- Write a separate `verify.py` under the plan's directory that programmatically re-checks every molecular design constraint against the reported solution's chemical properties, and run it; name any components that violate a constraint.
- Read the synthesis protocol and spot-check it for bugs — unused reagents, dead-end reactions, laboratory logic that contradicts what the solution says it does. A procedural flaw that silently degrades the purity is worse than one that overtly fails the simulation.
- Treat the result as finished only when every design constraint holds and the yield/purity is sound — not merely when the simulation runs without error.
- Check the length of the plan's `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of the plan's `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
Your laboratory synthesis protocol and its results live in your assigned plan's `SOLUTION.md`.

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

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