I need you to set up a 5-agent pipeline that performs skyscraper structural engineering where extreme environmental constraints dictate the design. A site brief and client requirements arrive as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted conceptual load-bearing plan and then detailed, verified material and structural blueprints.

The five agents:

- **project-coordinator** orchestrates the run: it drives the concept loop, then the detailing loop, and tracks progress. It does no structural modeling, detailing, or inspecting itself.
- **concept loop** — the **concept-architect** turns the site constraints into a formal structural model and load-bearing strategy; the **feasibility-board** reviews it. They iterate until the concept is physically sound.
- **detailing loop** — the **structural-detailer** translates the strategy into detailed blueprints; the **building-code-inspector** reviews the blueprints and simulation results. They iterate until the structure is safe and code-compliant.

The pipeline hands work off through three files:

- `problem.md` — the original site and project brief, given as input. All four domain agents (concept-architect, feasibility-board, structural-detailer, building-code-inspector) read it.
- `PLAN.md` — the conceptual plan. The concept-architect writes it; the feasibility-board reviews it; the structural-detailer reads it to detail it.
- `SOLUTION.md` — the detailed structural blueprints and simulation results. The structural-detailer writes it; the building-code-inspector reviews it.

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

I'm providing the following information:

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

<f2>
Which system suits which kind of environmental constraint — use it to choose one for the strategy:

- **Framed-tube** — great for standard high-rises up to 60 stories; limited flexibility for large exterior windows.
- **Diagrid** — excellent for unique geometries and tall towers requiring column-free perimeters; highly efficient against lateral loads.
- **Core-and-outrigger** — the standard for supertalls; links a stiff concrete core to perimeter columns to massively resist wind overturning moments.
- **Mega-frame / Super-column** — the strongest option for megatall skyscrapers; concentrates loads into massive corner columns.
- **Base isolation** — specialized for extreme seismic zones; decouples the superstructure from the substructure to absorb ground shear.
- **Tuned mass damper** — critical for mitigating wind-induced sway in highly slender towers; does not provide base structural support.

Match the structural system to the site's environmental constraints; do not force an ill-suited system on an extreme wind or earthquake zone.
</f2>

<f3>
The structural blueprints and simulation results live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the building-code-inspector as a loop.

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

<f4>
Review the conceptual plan in `PLAN.md`:

- **Model** — does it faithfully capture the site constraints? Check that the building height, environmental data, structural objectives, and load limits are all accurate to the brief.
- **Strategy** — is the chosen structural system and stabilization technique a sound fit, is the conceptual framing actually buildable, and is it likely to withstand the environmental forces?

Be brief and specific. Do not draft any structural blueprints yourself — only review the concept.
</f4>

<f5>
Review `SOLUTION.md` — the detailed structural blueprints and simulation results. Verify it directly against the site brief and zoning laws.

- Inspect the reported simulation results for anomalies, unreasonable deflections, or material stress limit violations.
- Write a separate `verify.py` that recalculates every major load constraint against the reported beam and column dimensions, and run it; name any structural members that violate a yield strength or deflection limit.
- Read the blueprints and spot-check them for physics and zoning bugs — inadequate foundation depths, unbraced slender columns, structural logic that contradicts what the strategy says it does. A flaw that silently compromises building safety is worse than a simulation that just crashes.
- Treat the blueprints as finished only when every physics and zoning constraint holds and the structural behavior is safe — not merely when the FEA software runs without error.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the conceptual plan in `PLAN.md` and implement its strategy as detailed material and structural blueprints:

- Detail every component. Specify beam sizes with correct material grades and yield strengths, define the foundation depth and joint connections exactly as the model demands, run the finite-element analysis (FEA) simulations, check the deflection and stress limits, and print both the member specifications and the maximum displacement values.
- Run the structural simulations yourself and watch them through to completion — do not stop while a load case is still processing. If it flags a localized failure or overstress, find and fix the root cause (e.g., increase member size); do not bury physics errors.
- Sanity-check the blueprints: a steel beam flange or rebar diameter must correspond to standard, manufacturable dimensions, not mathematically fractional millimeters.

Write the detailed specifications and simulation results up in `SOLUTION.md`.
</f6>

<f7>
You orchestrate the run; you never model, detail, or inspect yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the concept-architect to draft the conceptual plan.
- **Concept loop** — have the concept-architect and feasibility-board iterate on the model and structural strategy until the feasibility-board scores the plan 10.
- **Detailing loop** — once the concept is settled, have the structural-detailer and building-code-inspector iterate on the blueprints until the building-code-inspector scores them 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 inspector or board'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 conceptual load-bearing plan for the building and write it to `PLAN.md`. A complete plan has two parts — a formalized load model and one chosen structural strategy.

The **model** must state:

- **Building constraints** — exact height, zoning envelope, and usage type; this must be exact.
- **Environmental data** — the key wind speeds, seismic zone ratings, soil bearing capacity, and what each dictates.
- **Primary support variables** — core placement, column grid spacing, and floor-to-floor heights, with descriptive labels.
- **Structural objective** — the exact performance goal to optimize (e.g., minimizing sway, minimizing steel tonnage, maximizing leasable area).
- **Load constraints** — every specific live, dead, wind, and seismic load requirement, listed explicitly.

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

- which primary structural system to use and how it anchors to the foundation;
- the specific lateral load-resisting or stabilization technique;
- the material adaptations or structural tricks the route relies on;
- the biggest structural failure risk on this route.
</f9>

<f10>
You are working on a skyscraper structural engineering project — it may face extreme seismic activity, hurricane-force winds, poor soil conditions, or a combination. The original site constraints, environmental hazards, and zoning laws are given as a natural-language statement in `problem.md`; read it before starting your part.
</f10>

<f11>
The conceptual plan lives in `PLAN.md`, and you may be invoked on it more than once — the pipeline runs you and the feasibility-board as a loop.

- If `PLAN.md` does not exist yet, this is the first pass: produce the plan from scratch.
- If `PLAN.md` already exists, it carries the feasibility-board's `<review>` block: read that feedback and revise `PLAN.md` in place to address every point raised. Don't discard the plan 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 structural integrity and compliance. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this beam will buckle, but I'm telling you it will buckle" is still a failing design, 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 (project-coordinator, concept-architect, feasibility-board, structural-detailer, building-code-inspector), which items should go in its prompt? Respond with a JSON object like {"project-coordinator": ["f?"], "concept-architect": ["f?"], "feasibility-board": ["f?"], "structural-detailer": ["f?"], "building-code-inspector": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that performs skyscraper structural engineering where extreme environmental constraints dictate the design. A site brief and client requirements arrive as a natural-language statement in `problem.md`, and the pipeline turns it into a vetted conceptual load-bearing plan and then detailed, verified material and structural blueprints.

The five agents:

- **project-coordinator** orchestrates the run: it drives the concept loop, then the detailing loop, and tracks progress. It does no structural modeling, detailing, or inspecting itself.
- **concept loop** — the **concept-architect** turns the site constraints into a formal structural model and load-bearing strategy; the **feasibility-board** reviews it. They iterate until the concept is physically sound.
- **detailing loop** — the **structural-detailer** translates the strategy into detailed blueprints; the **building-code-inspector** reviews the blueprints and simulation results. They iterate until the structure is safe and code-compliant.

The pipeline hands work off through three files:

- `problem.md` — the original site and project brief, given as input. All four domain agents (concept-architect, feasibility-board, structural-detailer, building-code-inspector) read it.
- `PLAN.md` — the conceptual plan. The concept-architect writes it; the feasibility-board reviews it; the structural-detailer reads it to detail it.
- `SOLUTION.md` — the detailed structural blueprints and simulation results. The structural-detailer writes it; the building-code-inspector reviews it.

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

I'm providing the following prompt fragments:

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

<f2>
Which system suits which kind of environmental constraint — use it to choose one for the strategy:

- **Framed-tube** — great for standard high-rises up to 60 stories; limited flexibility for large exterior windows.
- **Diagrid** — excellent for unique geometries and tall towers requiring column-free perimeters; highly efficient against lateral loads.
- **Core-and-outrigger** — the standard for supertalls; links a stiff concrete core to perimeter columns to massively resist wind overturning moments.
- **Mega-frame / Super-column** — the strongest option for megatall skyscrapers; concentrates loads into massive corner columns.
- **Base isolation** — specialized for extreme seismic zones; decouples the superstructure from the substructure to absorb ground shear.
- **Tuned mass damper** — critical for mitigating wind-induced sway in highly slender towers; does not provide base structural support.

Match the structural system to the site's environmental constraints; do not force an ill-suited system on an extreme wind or earthquake zone.
</f2>

<f3>
The structural blueprints and simulation results live in `SOLUTION.md`, and you may be invoked on it more than once — the pipeline runs you and the building-code-inspector as a loop.

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

<f4>
Review the conceptual plan in `PLAN.md`:

- **Model** — does it faithfully capture the site constraints? Check that the building height, environmental data, structural objectives, and load limits are all accurate to the brief.
- **Strategy** — is the chosen structural system and stabilization technique a sound fit, is the conceptual framing actually buildable, and is it likely to withstand the environmental forces?

Be brief and specific. Do not draft any structural blueprints yourself — only review the concept.
</f4>

<f5>
Review `SOLUTION.md` — the detailed structural blueprints and simulation results. Verify it directly against the site brief and zoning laws.

- Inspect the reported simulation results for anomalies, unreasonable deflections, or material stress limit violations.
- Write a separate `verify.py` that recalculates every major load constraint against the reported beam and column dimensions, and run it; name any structural members that violate a yield strength or deflection limit.
- Read the blueprints and spot-check them for physics and zoning bugs — inadequate foundation depths, unbraced slender columns, structural logic that contradicts what the strategy says it does. A flaw that silently compromises building safety is worse than a simulation that just crashes.
- Treat the blueprints as finished only when every physics and zoning constraint holds and the structural behavior is safe — not merely when the FEA software runs without error.
- Check the length of `SOLUTION.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `SOLUTION.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the conceptual plan in `PLAN.md` and implement its strategy as detailed material and structural blueprints:

- Detail every component. Specify beam sizes with correct material grades and yield strengths, define the foundation depth and joint connections exactly as the model demands, run the finite-element analysis (FEA) simulations, check the deflection and stress limits, and print both the member specifications and the maximum displacement values.
- Run the structural simulations yourself and watch them through to completion — do not stop while a load case is still processing. If it flags a localized failure or overstress, find and fix the root cause (e.g., increase member size); do not bury physics errors.
- Sanity-check the blueprints: a steel beam flange or rebar diameter must correspond to standard, manufacturable dimensions, not mathematically fractional millimeters.

Write the detailed specifications and simulation results up in `SOLUTION.md`.
</f6>

<f7>
You orchestrate the run; you never model, detail, or inspect yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the concept-architect to draft the conceptual plan.
- **Concept loop** — have the concept-architect and feasibility-board iterate on the model and structural strategy until the feasibility-board scores the plan 10.
- **Detailing loop** — once the concept is settled, have the structural-detailer and building-code-inspector iterate on the blueprints until the building-code-inspector scores them 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 inspector or board'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 conceptual load-bearing plan for the building and write it to `PLAN.md`. A complete plan has two parts — a formalized load model and one chosen structural strategy.

The **model** must state:

- **Building constraints** — exact height, zoning envelope, and usage type; this must be exact.
- **Environmental data** — the key wind speeds, seismic zone ratings, soil bearing capacity, and what each dictates.
- **Primary support variables** — core placement, column grid spacing, and floor-to-floor heights, with descriptive labels.
- **Structural objective** — the exact performance goal to optimize (e.g., minimizing sway, minimizing steel tonnage, maximizing leasable area).
- **Load constraints** — every specific live, dead, wind, and seismic load requirement, listed explicitly.

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

- which primary structural system to use and how it anchors to the foundation;
- the specific lateral load-resisting or stabilization technique;
- the material adaptations or structural tricks the route relies on;
- the biggest structural failure risk on this route.
</f9>

<f10>
You are working on a skyscraper structural engineering project — it may face extreme seismic activity, hurricane-force winds, poor soil conditions, or a combination. The original site constraints, environmental hazards, and zoning laws are given as a natural-language statement in `problem.md`; read it before starting your part.
</f10>

<f11>
The conceptual plan lives in `PLAN.md`, and you may be invoked on it more than once — the pipeline runs you and the feasibility-board as a loop.

- If `PLAN.md` does not exist yet, this is the first pass: produce the plan from scratch.
- If `PLAN.md` already exists, it carries the feasibility-board's `<review>` block: read that feedback and revise `PLAN.md` in place to address every point raised. Don't discard the plan 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 structural integrity and compliance. Do not give any credit for a piece of work merely being honest about its own shortcomings — "this beam will buckle, but I'm telling you it will buckle" is still a failing design, 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. `# project-coordinator`). Output only the headered prompts, no preamble.


deal-orchestrator valuation-strategist investment-committee-skeptic term-sheet-drafter due-diligence-auditor

I need you to set up a 5-agent pipeline that executes hostile corporate takeover planning. A target's market vulnerabilities arrive as a natural-language dossier in `target_dossier.md`, and the pipeline turns it into a vetted acquisition thesis and then a legally binding deal structure and financial model.

The five agents:

- **deal-orchestrator** orchestrates the run: it drives the thesis loop, then the deal loop, and tracks progress. It does no valuation, drafting, or reviewing itself.
- **thesis loop** — the **valuation-strategist** turns the target's vulnerabilities into a formal vulnerability assessment and an acquisition strategy; the **investment-committee-skeptic** reviews it. They iterate until the thesis is ironclad.
- **deal loop** — the **term-sheet-drafter** implements the strategy as a computational financial model that generates the binding terms; the **due-diligence-auditor** reviews the code, the terms, and the financial output. They iterate until the deal structure is financially sound and legally binding.

The pipeline hands work off through three files:

- `target_dossier.md` — the original target market data, given as input. All four domain agents (valuation-strategist, investment-committee-skeptic, term-sheet-drafter, due-diligence-auditor) read it.
- `THESIS.md` — the acquisition thesis. The valuation-strategist writes it; the investment-committee-skeptic reviews it; the term-sheet-drafter reads it to implement it.
- `TERM_SHEET.md` — the financial modeling code, the deal structure, and its results. The term-sheet-drafter writes it; the due-diligence-auditor reviews it.

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

I'm providing the following information:

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

<f2>
You orchestrate the run; you never assess vulnerabilities, draft terms, or audit diligence yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the valuation-strategist to draft the thesis.
- **Thesis loop** — have the valuation-strategist and investment-committee-skeptic iterate on the vulnerability model and acquisition strategy until the investment-committee-skeptic scores the thesis 10.
- **Deal loop** — once the thesis is settled, have the term-sheet-drafter and due-diligence-auditor iterate on the financial model and deal terms until the due-diligence-auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the reviewer's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are planning a hostile corporate takeover — it may rely on heavy leverage, proxy battles, tender offers, or a combination. The original target market vulnerabilities are given as a natural-language statement in `target_dossier.md`; read it before starting your part.
</f3>

<f4>
Review the acquisition thesis in `THESIS.md`:

- **Model** — does it faithfully capture the target's market vulnerabilities? Check that the target profile, decision variables, objective metric, and financial constraints are all accurate.
- **Strategy** — is the chosen acquisition vehicle a sound fit, is the hostile route actually implementable legally, and is it likely to result in a successful takeover?

Be brief and specific. Do not write any modeling code or term sheet clauses yourself — only review.
</f4>

<f5>
Which takeover vehicle suits which kind of target — use it to choose one for the strategy:

- **Leveraged Buyout (LBO)** — High-cash-flow targets only; not for distressed or cash-burning startups.
- **Two-Tier Tender Offer** — Broadest coverage for public entities; applies immediate pressure to shareholders independent of the board.
- **Proxy Fight** — Replaces hostile management; requires low capital but high existing shareholder dissatisfaction.
- **Creeping Takeover** — Gradual open market buys; best for bypassing immediate takeover premiums; triggers early-warning disclosures.
- **Bear Hug** — Forces target board's fiduciary duty; highly public, best for targets with deeply undervalued assets but entrenched boards.
- **Debt-to-Equity Swap** — Heavily distressed targets only; bypasses traditional equity holders entirely.

Match the acquisition vehicle to the target's specific vulnerabilities; do not force an ill-suited approach.
</f5>

<f6>
Read the thesis in `THESIS.md` and implement its strategy as a quantitative financial model generating the binding deal terms:

- Include every import for your modeling tools. Create each financial variable with the correct type and bounds, define the objective function and every debt covenant exactly as the model states, solve the valuation model, check the financing status, and print both the final term sheet structure and the objective value.
- Run the modeling code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause of the financial or legal conflict; do not bury errors under try/except.
- Sanity-check the result: an offer premium that must be positive should not calculate out as a market discount.

Write the modeling code, the generated clauses, and the financial results up in `TERM_SHEET.md`.
</f6>

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

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

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

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

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

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

<f9>
Produce the acquisition thesis for the target and write it to `THESIS.md`. A complete thesis has two parts — a formalized vulnerability model and one chosen acquisition strategy.

The **model** must state:

- **Target profile** — Conglomerate, distressed asset, mature cash-cow, tech-growth, etc.; this must be exact.
- **Data** — the key financial inputs (EBITDA, debt load, market cap) and what each represents.
- **Decision variables** — the financial and legal levers (offer price, debt tranches, board seats) with descriptive names and limits.
- **Objective function** — the exact metric to optimize (e.g., maximize post-merger IRR, minimize acquisition premium).
- **Constraints** — every financial and legal constraint (covenants, regulatory caps, poison pill thresholds), listed explicitly.

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

- which acquisition vehicle to use and how to execute it;
- the core tactical steps and key initial parameters (e.g., initial stake accumulation limit);
- the financial loophole or legal restructuring trick the route relies on;
- the biggest market or regulatory risk on this route.
</f9>

<f10>
The acquisition thesis lives in `THESIS.md`, and you may be invoked on it more than once — the pipeline runs you and the investment-committee-skeptic as a loop.

- If `THESIS.md` does not exist yet, this is the first pass: produce the thesis from scratch.
- If `THESIS.md` already exists, it carries the investment-committee-skeptic's `<review>` block: read that feedback and revise `THESIS.md` in place to address every liability or flaw raised. Don't discard the thesis and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `TERM_SHEET.md` — the financial modeling code, generated terms, and its results. Verify it directly against the target dossier.

- Inspect the reported deal structure for hidden liabilities, unreasonable equity valuations, or covenant violations.
- Write a separate `verify.py` that recalculates every financial constraint and debt covenant against the reported terms, and run it; name any financial variables that violate a constraint.
- Read the financial modeling code and spot-check it for bugs — unused debt tranches, dead legal clauses, logic that contradicts what the term sheet says it does. A bug that silently degrades the post-merger valuation is worse than one that crashes the script.
- Treat the deal structure as finished only when every covenant holds and the objective valuation is sound — not merely when the modeling code runs without error.
- Check the length of `TERM_SHEET.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `TERM_SHEET.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The financial modeling code and deal terms live in `TERM_SHEET.md`, and you may be invoked on it more than once — the pipeline runs you and the due-diligence-auditor as a loop.

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (deal-orchestrator, valuation-strategist, investment-committee-skeptic, term-sheet-drafter, due-diligence-auditor), which items should go in its prompt? Respond with a JSON object like {"deal-orchestrator": ["f?"], "valuation-strategist": ["f?"], "investment-committee-skeptic": ["f?"], "term-sheet-drafter": ["f?"], "due-diligence-auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that executes hostile corporate takeover planning. A target's market vulnerabilities arrive as a natural-language dossier in `target_dossier.md`, and the pipeline turns it into a vetted acquisition thesis and then a legally binding deal structure and financial model.

The five agents:

- **deal-orchestrator** orchestrates the run: it drives the thesis loop, then the deal loop, and tracks progress. It does no valuation, drafting, or reviewing itself.
- **thesis loop** — the **valuation-strategist** turns the target's vulnerabilities into a formal vulnerability assessment and an acquisition strategy; the **investment-committee-skeptic** reviews it. They iterate until the thesis is ironclad.
- **deal loop** — the **term-sheet-drafter** implements the strategy as a computational financial model that generates the binding terms; the **due-diligence-auditor** reviews the code, the terms, and the financial output. They iterate until the deal structure is financially sound and legally binding.

The pipeline hands work off through three files:

- `target_dossier.md` — the original target market data, given as input. All four domain agents (valuation-strategist, investment-committee-skeptic, term-sheet-drafter, due-diligence-auditor) read it.
- `THESIS.md` — the acquisition thesis. The valuation-strategist writes it; the investment-committee-skeptic reviews it; the term-sheet-drafter reads it to implement it.
- `TERM_SHEET.md` — the financial modeling code, the deal structure, and its results. The term-sheet-drafter writes it; the due-diligence-auditor reviews it.

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

I'm providing the following prompt fragments:

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

<f2>
You orchestrate the run; you never assess vulnerabilities, draft terms, or audit diligence yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the valuation-strategist to draft the thesis.
- **Thesis loop** — have the valuation-strategist and investment-committee-skeptic iterate on the vulnerability model and acquisition strategy until the investment-committee-skeptic scores the thesis 10.
- **Deal loop** — once the thesis is settled, have the term-sheet-drafter and due-diligence-auditor iterate on the financial model and deal terms until the due-diligence-auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the reviewer's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are planning a hostile corporate takeover — it may rely on heavy leverage, proxy battles, tender offers, or a combination. The original target market vulnerabilities are given as a natural-language statement in `target_dossier.md`; read it before starting your part.
</f3>

<f4>
Review the acquisition thesis in `THESIS.md`:

- **Model** — does it faithfully capture the target's market vulnerabilities? Check that the target profile, decision variables, objective metric, and financial constraints are all accurate.
- **Strategy** — is the chosen acquisition vehicle a sound fit, is the hostile route actually implementable legally, and is it likely to result in a successful takeover?

Be brief and specific. Do not write any modeling code or term sheet clauses yourself — only review.
</f4>

<f5>
Which takeover vehicle suits which kind of target — use it to choose one for the strategy:

- **Leveraged Buyout (LBO)** — High-cash-flow targets only; not for distressed or cash-burning startups.
- **Two-Tier Tender Offer** — Broadest coverage for public entities; applies immediate pressure to shareholders independent of the board.
- **Proxy Fight** — Replaces hostile management; requires low capital but high existing shareholder dissatisfaction.
- **Creeping Takeover** — Gradual open market buys; best for bypassing immediate takeover premiums; triggers early-warning disclosures.
- **Bear Hug** — Forces target board's fiduciary duty; highly public, best for targets with deeply undervalued assets but entrenched boards.
- **Debt-to-Equity Swap** — Heavily distressed targets only; bypasses traditional equity holders entirely.

Match the acquisition vehicle to the target's specific vulnerabilities; do not force an ill-suited approach.
</f5>

<f6>
Read the thesis in `THESIS.md` and implement its strategy as a quantitative financial model generating the binding deal terms:

- Include every import for your modeling tools. Create each financial variable with the correct type and bounds, define the objective function and every debt covenant exactly as the model states, solve the valuation model, check the financing status, and print both the final term sheet structure and the objective value.
- Run the modeling code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause of the financial or legal conflict; do not bury errors under try/except.
- Sanity-check the result: an offer premium that must be positive should not calculate out as a market discount.

Write the modeling code, the generated clauses, and the financial results up in `TERM_SHEET.md`.
</f6>

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

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

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

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

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

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

<f9>
Produce the acquisition thesis for the target and write it to `THESIS.md`. A complete thesis has two parts — a formalized vulnerability model and one chosen acquisition strategy.

The **model** must state:

- **Target profile** — Conglomerate, distressed asset, mature cash-cow, tech-growth, etc.; this must be exact.
- **Data** — the key financial inputs (EBITDA, debt load, market cap) and what each represents.
- **Decision variables** — the financial and legal levers (offer price, debt tranches, board seats) with descriptive names and limits.
- **Objective function** — the exact metric to optimize (e.g., maximize post-merger IRR, minimize acquisition premium).
- **Constraints** — every financial and legal constraint (covenants, regulatory caps, poison pill thresholds), listed explicitly.

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

- which acquisition vehicle to use and how to execute it;
- the core tactical steps and key initial parameters (e.g., initial stake accumulation limit);
- the financial loophole or legal restructuring trick the route relies on;
- the biggest market or regulatory risk on this route.
</f9>

<f10>
The acquisition thesis lives in `THESIS.md`, and you may be invoked on it more than once — the pipeline runs you and the investment-committee-skeptic as a loop.

- If `THESIS.md` does not exist yet, this is the first pass: produce the thesis from scratch.
- If `THESIS.md` already exists, it carries the investment-committee-skeptic's `<review>` block: read that feedback and revise `THESIS.md` in place to address every liability or flaw raised. Don't discard the thesis and start over, and don't leave a flagged issue unaddressed.
</f10>

<f11>
Review `TERM_SHEET.md` — the financial modeling code, generated terms, and its results. Verify it directly against the target dossier.

- Inspect the reported deal structure for hidden liabilities, unreasonable equity valuations, or covenant violations.
- Write a separate `verify.py` that recalculates every financial constraint and debt covenant against the reported terms, and run it; name any financial variables that violate a constraint.
- Read the financial modeling code and spot-check it for bugs — unused debt tranches, dead legal clauses, logic that contradicts what the term sheet says it does. A bug that silently degrades the post-merger valuation is worse than one that crashes the script.
- Treat the deal structure as finished only when every covenant holds and the objective valuation is sound — not merely when the modeling code runs without error.
- Check the length of `TERM_SHEET.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `TERM_SHEET.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The financial modeling code and deal terms live in `TERM_SHEET.md`, and you may be invoked on it more than once — the pipeline runs you and the due-diligence-auditor as a loop.

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

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


I need you to set up a 5-agent pipeline that executes hostile corporate takeover planning. A target's market vulnerabilities arrive as a natural-language dossier in `target_dossier.md`, and the pipeline turns it into a vetted acquisition thesis and then a legally binding deal structure and financial model.

The five agents:

- **deal-orchestrator** orchestrates the run: it drives the thesis loop, then the deal loop, and tracks progress. It does no valuation, drafting, or reviewing itself.
- **thesis loop** — the **valuation-strategist** turns the target's vulnerabilities into a formal vulnerability assessment and an acquisition strategy; the **investment-committee-skeptic** reviews it. They iterate until the thesis is ironclad.
- **deal loop** — the **term-sheet-drafter** implements the strategy as a computational financial model that generates the binding terms; the **due-diligence-auditor** reviews the code, the terms, and the financial output. They iterate until the deal structure is financially sound and legally binding.

The pipeline hands work off through three files:

- `target_dossier.md` — the original target market data, given as input. All four domain agents (valuation-strategist, investment-committee-skeptic, term-sheet-drafter, due-diligence-auditor) read it.
- `THESIS.md` — the acquisition thesis. The valuation-strategist writes it; the investment-committee-skeptic reviews it; the term-sheet-drafter reads it to implement it.
- `TERM_SHEET.md` — the financial modeling code, the deal structure, and its results. The term-sheet-drafter writes it; the due-diligence-auditor reviews it.

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

I'm providing the following information:

<f1>
Keep `TERM_SHEET.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page memorandum; record only the final binding structure and move negotiation/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 takeover vehicle suits which kind of target — use it to choose one for the strategy:

- **Leveraged Buyout (LBO)** — High-cash-flow targets only; not for distressed or cash-burning startups.
- **Two-Tier Tender Offer** — Broadest coverage for public entities; applies immediate pressure to shareholders independent of the board.
- **Proxy Fight** — Replaces hostile management; requires low capital but high existing shareholder dissatisfaction.
- **Creeping Takeover** — Gradual open market buys; best for bypassing immediate takeover premiums; triggers early-warning disclosures.
- **Bear Hug** — Forces target board's fiduciary duty; highly public, best for targets with deeply undervalued assets but entrenched boards.
- **Debt-to-Equity Swap** — Heavily distressed targets only; bypasses traditional equity holders entirely.

Match the acquisition vehicle to the target's specific vulnerabilities; do not force an ill-suited approach.
</f2>

<f3>
The financial modeling code and deal terms live in `TERM_SHEET.md`, and you may be invoked on it more than once — the pipeline runs you and the due-diligence-auditor as a loop.

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

<f4>
Review the acquisition thesis in `THESIS.md`:

- **Model** — does it faithfully capture the target's market vulnerabilities? Check that the target profile, decision variables, objective metric, and financial constraints are all accurate.
- **Strategy** — is the chosen acquisition vehicle a sound fit, is the hostile route actually implementable legally, and is it likely to result in a successful takeover?

Be brief and specific. Do not write any modeling code or term sheet clauses yourself — only review.
</f4>

<f5>
Review `TERM_SHEET.md` — the financial modeling code, generated terms, and its results. Verify it directly against the target dossier.

- Inspect the reported deal structure for hidden liabilities, unreasonable equity valuations, or covenant violations.
- Write a separate `verify.py` that recalculates every financial constraint and debt covenant against the reported terms, and run it; name any financial variables that violate a constraint.
- Read the financial modeling code and spot-check it for bugs — unused debt tranches, dead legal clauses, logic that contradicts what the term sheet says it does. A bug that silently degrades the post-merger valuation is worse than one that crashes the script.
- Treat the deal structure as finished only when every covenant holds and the objective valuation is sound — not merely when the modeling code runs without error.
- Check the length of `TERM_SHEET.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `TERM_SHEET.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the thesis in `THESIS.md` and implement its strategy as a quantitative financial model generating the binding deal terms:

- Include every import for your modeling tools. Create each financial variable with the correct type and bounds, define the objective function and every debt covenant exactly as the model states, solve the valuation model, check the financing status, and print both the final term sheet structure and the objective value.
- Run the modeling code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause of the financial or legal conflict; do not bury errors under try/except.
- Sanity-check the result: an offer premium that must be positive should not calculate out as a market discount.

Write the modeling code, the generated clauses, and the financial results up in `TERM_SHEET.md`.
</f6>

<f7>
You orchestrate the run; you never assess vulnerabilities, draft terms, or audit diligence yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the valuation-strategist to draft the thesis.
- **Thesis loop** — have the valuation-strategist and investment-committee-skeptic iterate on the vulnerability model and acquisition strategy until the investment-committee-skeptic scores the thesis 10.
- **Deal loop** — once the thesis is settled, have the term-sheet-drafter and due-diligence-auditor iterate on the financial model and deal terms until the due-diligence-auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the 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 acquisition thesis for the target and write it to `THESIS.md`. A complete thesis has two parts — a formalized vulnerability model and one chosen acquisition strategy.

The **model** must state:

- **Target profile** — Conglomerate, distressed asset, mature cash-cow, tech-growth, etc.; this must be exact.
- **Data** — the key financial inputs (EBITDA, debt load, market cap) and what each represents.
- **Decision variables** — the financial and legal levers (offer price, debt tranches, board seats) with descriptive names and limits.
- **Objective function** — the exact metric to optimize (e.g., maximize post-merger IRR, minimize acquisition premium).
- **Constraints** — every financial and legal constraint (covenants, regulatory caps, poison pill thresholds), listed explicitly.

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

- which acquisition vehicle to use and how to execute it;
- the core tactical steps and key initial parameters (e.g., initial stake accumulation limit);
- the financial loophole or legal restructuring trick the route relies on;
- the biggest market or regulatory risk on this route.
</f9>

<f10>
You are planning a hostile corporate takeover — it may rely on heavy leverage, proxy battles, tender offers, or a combination. The original target market vulnerabilities are given as a natural-language statement in `target_dossier.md`; read it before starting your part.
</f10>

<f11>
The acquisition thesis lives in `THESIS.md`, and you may be invoked on it more than once — the pipeline runs you and the investment-committee-skeptic as a loop.

- If `THESIS.md` does not exist yet, this is the first pass: produce the thesis from scratch.
- If `THESIS.md` already exists, it carries the investment-committee-skeptic's `<review>` block: read that feedback and revise `THESIS.md` in place to address every liability or flaw raised. Don't discard the thesis 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 leverage model doesn't close, but I'm telling you it doesn't" is still a failing term sheet, 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 (deal-orchestrator, valuation-strategist, investment-committee-skeptic, term-sheet-drafter, due-diligence-auditor), which items should go in its prompt? Respond with a JSON object like {"deal-orchestrator": ["f?"], "valuation-strategist": ["f?"], "investment-committee-skeptic": ["f?"], "term-sheet-drafter": ["f?"], "due-diligence-auditor": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline that executes hostile corporate takeover planning. A target's market vulnerabilities arrive as a natural-language dossier in `target_dossier.md`, and the pipeline turns it into a vetted acquisition thesis and then a legally binding deal structure and financial model.

The five agents:

- **deal-orchestrator** orchestrates the run: it drives the thesis loop, then the deal loop, and tracks progress. It does no valuation, drafting, or reviewing itself.
- **thesis loop** — the **valuation-strategist** turns the target's vulnerabilities into a formal vulnerability assessment and an acquisition strategy; the **investment-committee-skeptic** reviews it. They iterate until the thesis is ironclad.
- **deal loop** — the **term-sheet-drafter** implements the strategy as a computational financial model that generates the binding terms; the **due-diligence-auditor** reviews the code, the terms, and the financial output. They iterate until the deal structure is financially sound and legally binding.

The pipeline hands work off through three files:

- `target_dossier.md` — the original target market data, given as input. All four domain agents (valuation-strategist, investment-committee-skeptic, term-sheet-drafter, due-diligence-auditor) read it.
- `THESIS.md` — the acquisition thesis. The valuation-strategist writes it; the investment-committee-skeptic reviews it; the term-sheet-drafter reads it to implement it.
- `TERM_SHEET.md` — the financial modeling code, the deal structure, and its results. The term-sheet-drafter writes it; the due-diligence-auditor reviews it.

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

I'm providing the following prompt fragments:

<f1>
Keep `TERM_SHEET.md` lean. Its body — everything except the `<review>` block — must stay under 3000 words (~20KB), about a four-page memorandum; record only the final binding structure and move negotiation/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 takeover vehicle suits which kind of target — use it to choose one for the strategy:

- **Leveraged Buyout (LBO)** — High-cash-flow targets only; not for distressed or cash-burning startups.
- **Two-Tier Tender Offer** — Broadest coverage for public entities; applies immediate pressure to shareholders independent of the board.
- **Proxy Fight** — Replaces hostile management; requires low capital but high existing shareholder dissatisfaction.
- **Creeping Takeover** — Gradual open market buys; best for bypassing immediate takeover premiums; triggers early-warning disclosures.
- **Bear Hug** — Forces target board's fiduciary duty; highly public, best for targets with deeply undervalued assets but entrenched boards.
- **Debt-to-Equity Swap** — Heavily distressed targets only; bypasses traditional equity holders entirely.

Match the acquisition vehicle to the target's specific vulnerabilities; do not force an ill-suited approach.
</f2>

<f3>
The financial modeling code and deal terms live in `TERM_SHEET.md`, and you may be invoked on it more than once — the pipeline runs you and the due-diligence-auditor as a loop.

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

<f4>
Review the acquisition thesis in `THESIS.md`:

- **Model** — does it faithfully capture the target's market vulnerabilities? Check that the target profile, decision variables, objective metric, and financial constraints are all accurate.
- **Strategy** — is the chosen acquisition vehicle a sound fit, is the hostile route actually implementable legally, and is it likely to result in a successful takeover?

Be brief and specific. Do not write any modeling code or term sheet clauses yourself — only review.
</f4>

<f5>
Review `TERM_SHEET.md` — the financial modeling code, generated terms, and its results. Verify it directly against the target dossier.

- Inspect the reported deal structure for hidden liabilities, unreasonable equity valuations, or covenant violations.
- Write a separate `verify.py` that recalculates every financial constraint and debt covenant against the reported terms, and run it; name any financial variables that violate a constraint.
- Read the financial modeling code and spot-check it for bugs — unused debt tranches, dead legal clauses, logic that contradicts what the term sheet says it does. A bug that silently degrades the post-merger valuation is worse than one that crashes the script.
- Treat the deal structure as finished only when every covenant holds and the objective valuation is sound — not merely when the modeling code runs without error.
- Check the length of `TERM_SHEET.md`: if it exceeds 20KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `TERM_SHEET.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f5>

<f6>
Read the thesis in `THESIS.md` and implement its strategy as a quantitative financial model generating the binding deal terms:

- Include every import for your modeling tools. Create each financial variable with the correct type and bounds, define the objective function and every debt covenant exactly as the model states, solve the valuation model, check the financing status, and print both the final term sheet structure and the objective value.
- Run the modeling code yourself and watch it through to completion — do not stop while it is still running. If it errors, find and fix the root cause of the financial or legal conflict; do not bury errors under try/except.
- Sanity-check the result: an offer premium that must be positive should not calculate out as a market discount.

Write the modeling code, the generated clauses, and the financial results up in `TERM_SHEET.md`.
</f6>

<f7>
You orchestrate the run; you never assess vulnerabilities, draft terms, or audit diligence yourself — you only dispatch the right agent at the right time.

- **Init** — dispatch the valuation-strategist to draft the thesis.
- **Thesis loop** — have the valuation-strategist and investment-committee-skeptic iterate on the vulnerability model and acquisition strategy until the investment-committee-skeptic scores the thesis 10.
- **Deal loop** — once the thesis is settled, have the term-sheet-drafter and due-diligence-auditor iterate on the financial model and deal terms until the due-diligence-auditor scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the 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 acquisition thesis for the target and write it to `THESIS.md`. A complete thesis has two parts — a formalized vulnerability model and one chosen acquisition strategy.

The **model** must state:

- **Target profile** — Conglomerate, distressed asset, mature cash-cow, tech-growth, etc.; this must be exact.
- **Data** — the key financial inputs (EBITDA, debt load, market cap) and what each represents.
- **Decision variables** — the financial and legal levers (offer price, debt tranches, board seats) with descriptive names and limits.
- **Objective function** — the exact metric to optimize (e.g., maximize post-merger IRR, minimize acquisition premium).
- **Constraints** — every financial and legal constraint (covenants, regulatory caps, poison pill thresholds), listed explicitly.

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

- which acquisition vehicle to use and how to execute it;
- the core tactical steps and key initial parameters (e.g., initial stake accumulation limit);
- the financial loophole or legal restructuring trick the route relies on;
- the biggest market or regulatory risk on this route.
</f9>

<f10>
You are planning a hostile corporate takeover — it may rely on heavy leverage, proxy battles, tender offers, or a combination. The original target market vulnerabilities are given as a natural-language statement in `target_dossier.md`; read it before starting your part.
</f10>

<f11>
The acquisition thesis lives in `THESIS.md`, and you may be invoked on it more than once — the pipeline runs you and the investment-committee-skeptic as a loop.

- If `THESIS.md` does not exist yet, this is the first pass: produce the thesis from scratch.
- If `THESIS.md` already exists, it carries the investment-committee-skeptic's `<review>` block: read that feedback and revise `THESIS.md` in place to address every liability or flaw raised. Don't discard the thesis 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 leverage model doesn't close, but I'm telling you it doesn't" is still a failing term sheet, 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. `# deal-orchestrator`). Output only the headered prompts, no preamble.


docket coordinator
appellate strategist
red-team appellate counsel
brief drafter
opposing-counsel brief reviewer

I need you to set up a 5-agent pipeline for civil appellate litigation support. A matter arrives as a trial record excerpt and issue statement in `record.md`, and the pipeline turns it into a vetted appellate theory and then a polished, record-supported appellate brief.

The five agents:

- **docket coordinator** orchestrates the run: it drives the theory loop, then the brief loop, and tracks progress. It does no legal analysis, drafting, or reviewing itself.
- **theory loop** — the **appellate strategist** turns the record and issue statement into a coherent appellate theory and briefing strategy; the **red-team appellate counsel** challenges it. They iterate until the theory is sound.
- **brief loop** — the **brief drafter** writes the brief from the vetted theory; the **opposing-counsel brief reviewer** reviews the brief as a hostile reader would. They iterate until the brief is accurate, persuasive, and court-ready.

The pipeline hands work off through three files:

- `record.md` — the trial record excerpt, procedural posture, and issue statement, given as input. All four legal-domain agents read it.
- `THEORY.md` — the appellate theory. The appellate strategist writes it; the red-team appellate counsel reviews it; the brief drafter reads it to draft the brief.
- `BRIEF.md` — the polished appellate brief. The brief drafter writes it; the opposing-counsel brief reviewer reviews it.

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

I'm providing the following information:

<f1>
Keep `BRIEF.md` lean and court-ready. Its body — everything except the `<review>` block — must stay under 6000 words (~40KB), roughly the length of a focused principal brief or substantial motion brief; move drafting history, abandoned arguments, and research notes into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

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

- **Init** — dispatch the appellate strategist to draft the theory.
- **Theory loop** — have the appellate strategist and red-team appellate counsel iterate on the appellate theory and strategy until the red-team appellate counsel scores the theory 10.
- **Brief loop** — once the theory is settled, have the brief drafter and opposing-counsel brief reviewer iterate on the brief until the opposing-counsel brief reviewer scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a civil appeal. The trial record excerpt, procedural posture, judgment or order being appealed, and issue statement are provided in `record.md`; read it before starting your part.
</f3>

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

- **Appellate analysis** — does it faithfully capture the record and issue statement? Check that the appeal posture, issues presented, standards of review, material facts, governing law, error theory, preservation, prejudice, and remedy are accurate.
- **Strategy** — is the chosen appellate route a sound fit, is it actually briefable from this record, and is it likely to give the appellant the best chance of relief?

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

<f5>
Which appellate route suits which kind of issue — use it to choose the strategy:

- **Pure legal error** — best when the issue is preserved and turns on statutory interpretation, contract interpretation, rule construction, or another question reviewed de novo.
- **Summary judgment or dismissal error** — strong when the record can be framed in the nonmovant's favor and the trial court applied the wrong legal rule or ignored a genuine dispute.
- **Evidentiary or trial-management error** — viable when the ruling was preserved, the standard is abuse of discretion, and the excluded or admitted evidence probably affected the outcome.
- **Jury-instruction error** — useful when the requested instruction correctly stated the law, was supported by the evidence, was refused or misstated, and prejudice can be shown.
- **Sufficiency or weight-of-the-evidence challenge** — difficult on appeal; use only when the record is unusually one-sided or the governing burden of proof creates a clear legal defect.
- **Procedural due process or notice defect** — strong when the record shows lack of notice, denial of a meaningful opportunity to be heard, or a ruling outside the issues actually litigated.
- **Preservation-limited fallback** — use only when the best issue was not cleanly preserved; address forfeiture, plain-error or fundamental-error doctrine if available, and harmless-error risk.

Match the appellate route to the record, the issue, and the standard of review; do not force an argument that the appellate court is unlikely to reach or accept.
</f5>

<f6>
Read the theory in `THEORY.md` and draft the appellate brief from it:

- Include all core sections needed for a polished civil appellate brief: caption placeholder if needed, table-ready headings, issue presented, statement of the case, statement of facts, summary of argument, argument, and conclusion.
- Use the chosen theory exactly: frame the issue, state the standard of review, marshal the record facts, cite controlling authority, answer the likely appellee arguments, and request the specified relief.
- Support every material factual assertion with a record citation from `record.md`. Do not invent facts, procedural events, quotations, objections, rulings, or citations.
- Check the brief yourself from start to finish. Fix missing record cites, unsupported legal propositions, internal contradictions, and placeholders. Do not leave TODOs, bracketed guesses, or uncited assertions for someone else.
- Sanity-check the requested relief: it must match the appellate posture and the error theory.

Write the brief in `BRIEF.md`.
</f6>

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

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

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

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

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

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

<f9>
Produce the appellate theory and briefing strategy for the matter and write it to `THEORY.md`. A complete theory has two parts — a formalized appellate analysis and one chosen briefing strategy.

The **analysis** must state:

- **Appeal posture** — final judgment or appealable order, court, parties, and the relief sought on appeal.
- **Issues presented** — the exact questions the appellate court should decide, framed in a way that fits the record.
- **Standard of review** — the governing standard for each issue, with any preservation or harmless-error implications.
- **Material record facts** — the key facts, rulings, objections, motions, and record citations that matter to the appeal.
- **Governing law** — the controlling statutes, rules, and precedent needed for the argument.
- **Theory of error** — precisely what the trial court or opposing party did wrong, why it matters, and how it affected the judgment.
- **Remedy** — reversal, vacatur, remand instructions, modification, new trial, or other specific relief.

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

- which issue should lead and which arguments should be omitted or subordinated;
- how the standard of review will be handled;
- the core precedent and record facts the argument will rely on;
- the anticipated appellee response and the best answer to it;
- the biggest risk in this appellate route.
</f9>

<f10>
The appellate theory lives in `THEORY.md`, and you may be invoked on it more than once — the pipeline runs you and the red-team appellate counsel as a loop.

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

<f11>
Review `BRIEF.md` — the appellate brief and its supporting citations. Verify it directly against the trial record and issue statement.

- Inspect the argument for anomalies, overstatements, waived issues, unsupported standards of review, unreasonable remedies, or factual assertions that the record does not support.
- Write a separate `cite_check.md` that re-checks every material factual assertion and record citation against `record.md`; name any assertion that lacks support or misstates the cited material.
- Read the brief closely and spot-check it for legal and drafting defects — missing authorities, dead arguments, contradictory positions, abandoned preservation problems, or language that promises more than the record can deliver. A subtle misstatement that invites reversal or sanctions is worse than an obvious typo.
- Treat the brief as finished only when the record support is accurate, the legal theory is coherent, and the requested relief is sound — not merely when the document reads smoothly.
- Check the length of `BRIEF.md`: if it exceeds 40KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `BRIEF.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The appellate brief lives in `BRIEF.md`, and you may be invoked on it more than once — the pipeline runs you and the opposing-counsel brief reviewer as a loop.

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

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (docket coordinator, appellate strategist, red-team appellate counsel, brief drafter, opposing-counsel brief reviewer), which items should go in its prompt? Respond with a JSON object like {"docket coordinator": ["f?"], "appellate strategist": ["f?"], "red-team appellate counsel": ["f?"], "brief drafter": ["f?"], "opposing-counsel brief reviewer": ["f?"]}. No other output.

I need you to set up a 5-agent pipeline for civil appellate litigation support. A matter arrives as a trial record excerpt and issue statement in `record.md`, and the pipeline turns it into a vetted appellate theory and then a polished, record-supported appellate brief.

The five agents:

- **docket coordinator** orchestrates the run: it drives the theory loop, then the brief loop, and tracks progress. It does no legal analysis, drafting, or reviewing itself.
- **theory loop** — the **appellate strategist** turns the record and issue statement into a coherent appellate theory and briefing strategy; the **red-team appellate counsel** challenges it. They iterate until the theory is sound.
- **brief loop** — the **brief drafter** writes the brief from the vetted theory; the **opposing-counsel brief reviewer** reviews the brief as a hostile reader would. They iterate until the brief is accurate, persuasive, and court-ready.

The pipeline hands work off through three files:

- `record.md` — the trial record excerpt, procedural posture, and issue statement, given as input. All four legal-domain agents read it.
- `THEORY.md` — the appellate theory. The appellate strategist writes it; the red-team appellate counsel reviews it; the brief drafter reads it to draft the brief.
- `BRIEF.md` — the polished appellate brief. The brief drafter writes it; the opposing-counsel brief reviewer reviews it.

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

I'm providing the following prompt fragments:

<f1>
Keep `BRIEF.md` lean and court-ready. Its body — everything except the `<review>` block — must stay under 6000 words (~40KB), roughly the length of a focused principal brief or substantial motion brief; move drafting history, abandoned arguments, and research notes into a separate `CHANGELOG.md`. Bold text must not exceed 5% of the file: if everything is bold, nothing is.
</f1>

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

- **Init** — dispatch the appellate strategist to draft the theory.
- **Theory loop** — have the appellate strategist and red-team appellate counsel iterate on the appellate theory and strategy until the red-team appellate counsel scores the theory 10.
- **Brief loop** — once the theory is settled, have the brief drafter and opposing-counsel brief reviewer iterate on the brief until the opposing-counsel brief reviewer scores it 10.
- Cap each loop at 10 iterations.
- Keep the current phase, iteration count, and latest score in `STATE.md`, accurate after each dispatch. Read each score from the critic's `<review score=X>` block. Commit progress after each step.
</f2>

<f3>
You are working on a civil appeal. The trial record excerpt, procedural posture, judgment or order being appealed, and issue statement are provided in `record.md`; read it before starting your part.
</f3>

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

- **Appellate analysis** — does it faithfully capture the record and issue statement? Check that the appeal posture, issues presented, standards of review, material facts, governing law, error theory, preservation, prejudice, and remedy are accurate.
- **Strategy** — is the chosen appellate route a sound fit, is it actually briefable from this record, and is it likely to give the appellant the best chance of relief?

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

<f5>
Which appellate route suits which kind of issue — use it to choose the strategy:

- **Pure legal error** — best when the issue is preserved and turns on statutory interpretation, contract interpretation, rule construction, or another question reviewed de novo.
- **Summary judgment or dismissal error** — strong when the record can be framed in the nonmovant's favor and the trial court applied the wrong legal rule or ignored a genuine dispute.
- **Evidentiary or trial-management error** — viable when the ruling was preserved, the standard is abuse of discretion, and the excluded or admitted evidence probably affected the outcome.
- **Jury-instruction error** — useful when the requested instruction correctly stated the law, was supported by the evidence, was refused or misstated, and prejudice can be shown.
- **Sufficiency or weight-of-the-evidence challenge** — difficult on appeal; use only when the record is unusually one-sided or the governing burden of proof creates a clear legal defect.
- **Procedural due process or notice defect** — strong when the record shows lack of notice, denial of a meaningful opportunity to be heard, or a ruling outside the issues actually litigated.
- **Preservation-limited fallback** — use only when the best issue was not cleanly preserved; address forfeiture, plain-error or fundamental-error doctrine if available, and harmless-error risk.

Match the appellate route to the record, the issue, and the standard of review; do not force an argument that the appellate court is unlikely to reach or accept.
</f5>

<f6>
Read the theory in `THEORY.md` and draft the appellate brief from it:

- Include all core sections needed for a polished civil appellate brief: caption placeholder if needed, table-ready headings, issue presented, statement of the case, statement of facts, summary of argument, argument, and conclusion.
- Use the chosen theory exactly: frame the issue, state the standard of review, marshal the record facts, cite controlling authority, answer the likely appellee arguments, and request the specified relief.
- Support every material factual assertion with a record citation from `record.md`. Do not invent facts, procedural events, quotations, objections, rulings, or citations.
- Check the brief yourself from start to finish. Fix missing record cites, unsupported legal propositions, internal contradictions, and placeholders. Do not leave TODOs, bracketed guesses, or uncited assertions for someone else.
- Sanity-check the requested relief: it must match the appellate posture and the error theory.

Write the brief in `BRIEF.md`.
</f6>

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

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

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

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

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

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

<f9>
Produce the appellate theory and briefing strategy for the matter and write it to `THEORY.md`. A complete theory has two parts — a formalized appellate analysis and one chosen briefing strategy.

The **analysis** must state:

- **Appeal posture** — final judgment or appealable order, court, parties, and the relief sought on appeal.
- **Issues presented** — the exact questions the appellate court should decide, framed in a way that fits the record.
- **Standard of review** — the governing standard for each issue, with any preservation or harmless-error implications.
- **Material record facts** — the key facts, rulings, objections, motions, and record citations that matter to the appeal.
- **Governing law** — the controlling statutes, rules, and precedent needed for the argument.
- **Theory of error** — precisely what the trial court or opposing party did wrong, why it matters, and how it affected the judgment.
- **Remedy** — reversal, vacatur, remand instructions, modification, new trial, or other specific relief.

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

- which issue should lead and which arguments should be omitted or subordinated;
- how the standard of review will be handled;
- the core precedent and record facts the argument will rely on;
- the anticipated appellee response and the best answer to it;
- the biggest risk in this appellate route.
</f9>

<f10>
The appellate theory lives in `THEORY.md`, and you may be invoked on it more than once — the pipeline runs you and the red-team appellate counsel as a loop.

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

<f11>
Review `BRIEF.md` — the appellate brief and its supporting citations. Verify it directly against the trial record and issue statement.

- Inspect the argument for anomalies, overstatements, waived issues, unsupported standards of review, unreasonable remedies, or factual assertions that the record does not support.
- Write a separate `cite_check.md` that re-checks every material factual assertion and record citation against `record.md`; name any assertion that lacks support or misstates the cited material.
- Read the brief closely and spot-check it for legal and drafting defects — missing authorities, dead arguments, contradictory positions, abandoned preservation problems, or language that promises more than the record can deliver. A subtle misstatement that invites reversal or sanctions is worse than an obvious typo.
- Treat the brief as finished only when the record support is accurate, the legal theory is coherent, and the requested relief is sound — not merely when the document reads smoothly.
- Check the length of `BRIEF.md`: if it exceeds 40KB, give a warning, but do not deduct points for it.
- Check the bold ratio of `BRIEF.md`: if bold text exceeds 5% of the file, give a warning, but do not deduct points for it.
</f11>

<f12>
The appellate brief lives in `BRIEF.md`, and you may be invoked on it more than once — the pipeline runs you and the opposing-counsel brief reviewer as a loop.

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

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