Finance

Investment Banking

Name: Investment Banking
Author: OpenAI

OpenAI v0.1.29

Publisher description

From the marketplace listing

Investment banking workflows for M&A, coverage, sponsors, ECM/DCM, LevFin, restructuring, capital advisory, valuation, buyer and investor targeting, diligence, pitch materials, and process execution.

Language: English · Automatically detected from descriptions.

ChatGPT marketplace listing ↗Website ↗Privacy policy ↗Terms ↗Repository ↗

Files & skills

File archives

Plugin package563 files · 1.2 MBBrowse files →

Skill instructions

buyer-investor-list14.9 KB

View saved version →

---
name: buyer-investor-list
description: build prioritized buyer, investor, lender, or sponsor universes for ib processes. use when the user asks for target lists, outreach waves, rationale, or tracker-ready parties. do not use to run the live process; use deal-process-tracker.
---

# Buyer Investor List

## Skill Configuration

### Common Skill Instructions

MANDATORY: Before searching connectors, retrieving evidence, or drafting output, read and apply the shared runtime contract in `../investment-banking/SKILL.md## Cross-Skill Runtime Contract`. Then check the router skill map and `../../references/plugin-routing-playbook.md` for adjacent skills that should be sequenced with this workflow. Do not run user-context setup or inspection during ordinary workflow work; route only explicit saved-context, source-setup, onboarding, or automation-setup requests to `../user-context/SKILL.md`.

### Source Resolution

Load `../../references/workflow-source-resolution.md`. Resolve only the categories needed for this workflow: `deal_materials`, `relationship_counterparty_context`, `market_data_public_sources`, and `models_workbooks_templates`. Use the shared runtime contract to map each attempted category to an available app, connector, file, export, or user-provided input.

## Relevant Dependency Categories

These are the source categories most likely to matter for this workflow. Use the router contract to resolve only the categories the task actually needs, prefer user-named sources first, and state any material source limitation.

- `Relationship & Counterparty Context`
- `Market Data & Public Sources`
- `Process Updates`

## Deliverable Intake

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. The hero deliverable must be a polished standalone HTML buyer-universe report, workbook, native deck/document, generated folder first-read file, or justified chat-only answer. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing standalone HTML report, workbook, native deck/document, or clear first-read package.

## Trigger Boundary

Use for prioritized buyer, sponsor, lender, financing source, or investor universes where the user needs who to contact, why they care, whether they can transact, what risk they introduce, who should approach them, and when they belong in the process.

Role: produce a senior banker process strategy artifact, not a directory export. Optimize for price, certainty, speed, confidentiality, strategic fit, financing capacity, cultural fit, restructuring feasibility, or competitive tension based on the user's objective.

Non-role: do not run the live process, mark outreach complete, send materials, grant access, or replace the process tracker. Use `deal-process-tracker` once the universe becomes active outreach.

## Fast Workflow

1. Classify the mandate: sell-side M&A, sponsor targeting, lender/financing source, growth/minority/private placement, restructuring/distressed capital, or public-market investor targeting.
2. Adapt to context: with no context, build a starter framework and assumptions; with partial context, produce a preliminary universe; with full materials or an existing list, preserve existing rows/notes and add proposed columns plus a change log.
3. Establish transaction objective, constraints, target profile, confidentiality limits, client preferences, do-not-contact parties, and success metric.
4. Define archetypes before names, then build the universe from user materials, connected sources, structured data, public sources, and banker judgment.
5. Normalize entities, apply hard screens, score/tier parties, write specific rationale, map relationship path, sequence outreach waves, and run MD-style QA.
6. Use only the references needed for the request; do not load every playbook by default.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: strategic buyers, sponsors, lenders/financing sources, exclusions/conflicts, and outreach-wave strategy. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Artifact Contract

Default deliverable: `extended_analysis` with executive summary, ranked table, top-call notes, hold/exclusion list, process strategy, source/evidence posture, confidentiality flags, tracker handoff readiness, and data gaps/validation asks.

Use starter or preliminary depth only when source context is genuinely thin, the user explicitly asks for a quick target list, or the response is a narrow update to an existing full universe. Read `../../references/output-depth-policy.md` before shortening.

For an HTML-selected pitch, prioritization, or top-call request, the hero artifact is a polished standalone HTML buyer-universe report. For a user-supplied universe that requires scoring, deduping, tracking, or operational row management, prefer a workbook as the hero artifact and use HTML only when requested as an additional reader-facing report.

Hero report ranked-table core fields: party, type, tier/wave, specific thesis, ability-to-transact evidence or validation need, confidentiality/regulatory handling, next action, and source/confidence. Keep raw score, penalty, and final-score columns in the working workbook or a secondary analytical schedule unless the user specifically wants numerical scoring in the first-read report.

For spreadsheet-like outputs, preserve existing user columns, add new fields to the right, and use proposed-change columns instead of destructive edits.

Tracker handoff: when the universe becomes active outreach, export the canonical `buyer_investor_list_to_deal_process_tracker` contract in `../../references/handoff-contracts.md`. Validate automation payloads against `../../schemas/buyer_investor_list_to_deal_process_tracker.schema.json`; keep `holds_and_exclusions` separate and preserve confidentiality, conflict, and client-approval flags.

## Standalone HTML Path

When HTML is requested or selected, produce a polished standalone HTML buyer-universe report following `../../references/html-artifact-standard.md`. This skill owns its report hierarchy, writing, and presentation. Do not route an ordinary buyer-universe HTML report through `dashboard-builder`, create a dashboard render contract, or force the analysis into fixed dashboard modules.

For an initial sell-side pitch or outreach-sequencing request, use this first-read hierarchy:

1. Process recommendation: objective, recommended process posture, conditional first-wave names, high-value holds, and decisions required from the client or MD.
2. Outreach sequencing: one compact wave-and-gates table combining disclosure approach, required approvals, and validation steps.
3. Prioritized buyer universe: the decision-useful ranked table, with unverified capacity, ownership, relationship, or conflicts visibly marked as validation needs.
4. Sensitive parties and holds: one register for confidentiality, regulatory, commercial, conflict, and do-not-contact handling.
5. Pre-outreach decisions: one consolidated action table for missing approvals, relationship checks, capacity validation, legal/compliance protocol, and material diligence gaps.
6. Evidence and limitations: readable source notes and the preliminary or decision-ready posture.

Keep the report table-first where comparison is central, but do not repeat the same conclusion in a hero callout, separate call sheet, separate open-diligence register, and multiple near-duplicate tables. In a pitch-stage HTML report, keep the prioritized buyer universe focused on actionable and conditionally actionable parties. Present held or excluded sensitive parties in the dedicated hold register instead of duplicating full rows in both sections, unless side-by-side comparison is central to the recommendation. A candidate with unverified ownership, capacity, conflict status, or outreach authorization may be recommended for validation or `Conditional Wave 1`, but must not be presented as cleared for outreach.

Do not add generic dashboard navigation, reader-action bars, related-file panels, internal renderer contracts, or visible generation machinery merely because the output is HTML. Include a companion workbook when the user needs operational scoring or tracker-style row management; keep it distinct from the first-read report.

## Source And Evidence Posture

Use user-provided deal materials and explicit instructions first, then connected/internal sources, licensed/company data where available, public primary/credible secondary sources, and clearly labeled inference. Compose with `financial-source-of-truth` when source hierarchy, citations, stale-data checks, conflicts, or fact/assumption labels matter.

Do not fabricate factual claims, relationship history, mandate fit, capacity, contacts, or do-not-contact status. Mark each row's source quality/confidence and preserve source dates.

## Validated Handoffs

Producer contracts:
- `buyer_investor_list_to_deal_process_tracker` -> `deal-process-tracker`. Schema: `../../schemas/buyer_investor_list_to_deal_process_tracker.schema.json`. Validate with `../../scripts/validate_handoff_payload.py buyer_investor_list_to_deal_process_tracker handoffs/buyer_investor_list_to_deal_process_tracker.json` before another skill imports it.

Use `../../references/handoff-contracts.md` for canonical field names and shared evidence semantics. Add `--strict` before any model, deck, committee, lender, board, or client-circulation use so placeholders, empty arrays, and empty objects fail instead of becoming assumptions.

Handoff payloads belong under `handoffs/` and must be listed in `manifest.json` as support or agent artifacts with `handoff_contract_name`, `schema_path`, `validator_status`, `validated_at`, and `consumer_skill`. They are never the hero deliverable unless the user explicitly asks for machine-readable output.

## Script Map

If the user provides a csv-style universe and asks for scoring, deduping, or tiering, you may use `scripts/score_buyer_universe.py`. The script preserves all original columns and appends framework-aligned score, risk penalty, tier, wave, recommended action, confidence, source quality, MD judgment note, score-basis, and QA fields. Use `--objective` when the process objective is clear (`maximize_valuation`, `maximize_certainty`, `preserve_confidentiality`, `founder_friendly_recap`, `lender_process`, or `distressed_restructuring`). Do not use the script as a substitute for judgment; review and revise the output before presenting it.

- For tracker handoff validation, use `../../scripts/validate_handoff_payload.py buyer_investor_list_to_deal_process_tracker <payload.json>`.

## HTML Evidence Readiness

For senior, client, committee, board, lender, or external postures, every material number, estimate, date-sensitive fact, sourced claim, assumption, and recommendation must have readable point-of-use citation support. Unknown citation IDs, missing source registers, uncited material numeric claims, unsupported buyer-capacity claims, unsupported interest or relationship claims, and uncleared confidentiality or regulatory implications are blocking readiness gaps: fix them, downgrade the posture to draft or preliminary pitch-screen status, or surface them explicitly.

For an HTML buyer-universe report:

- Keep sources readable: cite complete claims or table rows where possible rather than attaching repeated citation chips to every cell.
- Separate confirmed facts from banker hypotheses, inferred buyer logic, relationship-validation needs, and legal/compliance gates.
- Keep numeric scoring from implying buyer interest, transaction capacity, approval, or legal conclusions.
- Keep support artifacts and generation mechanics out of the visible report body unless requested.
- Render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: standalone HTML buyer-universe report, XLSX workbook, native deck/document, generated folder, or justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map

Load only the reference needed for the current task.

- `../../references/html-artifact-standard.md`: shared HTML design, evidence, and visual-inspection standard.
- `references/workflow.md`: full execution flow, mandate modes, context handling, archetype-first build logic, and process strategy.
- `references/scoring-framework.md`: tier definitions, score treatment, override rules, wave logic, and risk-adjusted scoring nuance.
- `references/output-templates.md`: standalone HTML report, ranked table, hold register, outreach sequence, and tracker-ready export templates.
- `references/data-source-playbook.md`: source hierarchy, entity resolution, data gathering, and evidence handling.
- `references/industry-nuance.md`: sector, buyer-type, sponsor/fund, cross-border, lender, and distressed-capital nuance.
- `references/compliance-confidentiality.md`: confidentiality, antitrust, MNPI, conflicts, clean-team, sanctions, and escalation flags.
- `references/qa-checklist.md`: final MD review, HTML presentation review, and tracker handoff readiness.
- `../../references/handoff-contracts.md`: canonical downstream handoff fields.
- `../../references/evidence-label-taxonomy.md`: shared evidence/source-label taxonomy.
- `../../references/output-depth-policy.md`: analysis-depth policy; default to `extended_analysis` unless an explicit shortening condition applies.

Referenced files: 9

capital-markets-issuance23.2 KB

View saved version →

---
name: capital-markets-issuance
description: frame issuer financing and capital-markets execution options. use when the user asks about ecm, dcm, private placements, market window, investor targeting, or use of proceeds. do not use for borrower credit approval.
---

# Capital Markets Issuance

## Skill Configuration

### Common Skill Instructions

### Source Resolution

Load `../../references/workflow-source-resolution.md`. Resolve only the categories needed for this workflow: `deal_materials`, `market_data_public_sources`, and `models_workbooks_templates`. Use the shared runtime contract to map each attempted category to an available app, connector, file, export, or user-provided input.

## Relevant Dependency Categories

- `Market Data & Public Sources`
- `Models, Workbooks & Templates`
- `Relationship & Counterparty Context`
- `Deal Materials`

## Deliverable Intake

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. The hero deliverable must be a polished standalone HTML financing report, workbook, native deck/document, generated folder first-read file, or justified chat-only answer. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing workbook, standalone HTML financing report, native deck/document, or clear first-read package.

## Purpose
Act like a senior investment-banking capital markets partner advising an issuer, sponsor, board, treasurer, or cfo on whether and how to raise capital. Produce decision-grade issuance views, not generic market summaries. Every output should answer: **what should the issuer do, why now, what instrument and size, at what likely terms, with what risks, and what next steps?** Address investor strategy when it is material to execution and supported by available evidence.

## Routing contract

Default lead role: **issuer-side capital markets advisor**.

Own:
- financing strategy, instrument choice, market window, launch timing, sizing, pricing ranges, investor targeting, use of proceeds, comparable issuance, execution plan, and fallback alternatives;
- private credit as one potential issuer financing alternative when comparing syndicated debt, bonds, loans, converts, equity, and private placements;
- high-level covenant, ratings, leverage, liquidity, and documentation constraints only insofar as they affect whether and how the issuer should raise capital.

Hand off:
- borrower-level lender decisioning, risk rating, credit committee memo, downside loss view, and conditions precedent to `private-credit-underwriting`;
- document-first covenant definitions, baskets, leakage, restricted payments, EBITDA definitions, and legal-document headroom mechanics to `covenant-package-analyzer`;
- deep operating-model, LBO, merger-model, or recovery mechanics to the relevant model-builder skill.

Explicit invocation override: if the user specifically asks to use `capital-markets-issuance`, keep this skill as the lead even when the prompt includes credit or covenant topics. In that case, answer from an issuer financing perspective, clearly state when credit/covenant items are inputs or caveats, and recommend handoffs rather than silently switching ownership.

## Output Modes

Choose the narrowest mode that satisfies the transaction decision and requested depth:

- `issuance_recommendation`: full issuer-side recommendation on whether, when, how much, and through which security to raise, with alternatives, pro forma impact, launch triggers, and fallback.
- `market_window_update`: focused proceed / prepare / defer / switch-instrument view with issuer-specific launch conditions, no-go triggers, and immediate workplan.
- `structured_handoff`: validated JSON for a downstream credit, covenant, model, or memo workflow; it is support material unless explicitly requested as the deliverable.

Default to `extended_analysis` under `../../references/output-depth-policy.md` for a substantive standalone recommendation while keeping optional sections proportionate to the actual decision.

## Non-negotiable operating rules
- Preserve user-provided files, sheets, models, tabs, and data. Never delete, overwrite, reorder, or hide data unless the user explicitly asks. When editing artifacts, create additive outputs or clearly marked new tabs/sections by default.
- Prefer callable connected routes, user-provided exports, uploaded files, internal context, and cited materials before public web search. Use web search only as a fallback or for current public market/company information when higher-priority sources are unavailable or insufficient.
- Label each material item as **source-backed**, **user-provided**, **assumption**, or **needs verification**. Time-stamp market data and flag stale data.
- Do not invent investor demand, book feedback, ratings views, covenant capacity, legal eligibility, or transaction terms. If unavailable, provide a required diligence item or assumption range.
- Treat securities-law, disclosure, mnpi, wall-crossing, rating-agency, and covenant matters as requiring banker/counsel verification. Do not provide legal advice.
- Challenge the prompt when needed: if the requested instrument is not likely the best answer, explain the superior path while still answering the user's request.

## Adaptive intake
Work even when context is thin.

1. **No issuer or instrument given**: ask up to five essentials only, then provide a reusable issuance workplan/template if immediate analysis is impossible. Essentials: issuer, public/private status, target amount or need, use of proceeds, instrument focus or open-ended alternatives, and timing constraint.
2. **Partial context given**: proceed using explicit assumptions. Fill gaps with connected sources if available; otherwise use market-standard ranges and clearly mark them.
3. **Rich context or files given**: use provided materials as the source of truth, reconcile conflicts, and cite/label sources. Preserve all source data.
4. **Live-market request**: obtain current market data when possible; include data timestamp, source hierarchy, and recency caveats.
5. **Artifact request**: if producing a deck, memo, spreadsheet, tracker, or model, follow the relevant artifact skill/workflow and keep this skill as the issuance judgment layer.

## Route by task type
Use this decision tree before drafting.

- **full issuance recommendation / board memo / client memo** -> follow `references/workflow.md` and default to the full output in `references/output-templates.md`.
- **ecm, ipo, follow-on, block, atm, pipe, rights offering** -> use `references/ecm.md`.
- **ig bonds, high-yield, leveraged loans, private credit, bank debt, private placements, abs** -> use `references/dcm.md`.
- **convertible, mandatory convertible, preferred, hybrid** -> use `references/convertibles-hybrids.md`.
- **market window or launch timing** -> use `references/market-window.md`.
- **investor targeting / anchor strategy / allocation plan** -> use `references/investor-targeting.md`.
- **comparable offerings / pricing benchmarks** -> use `references/comparable-deals.md`.
- **process timeline or live execution checklist** -> use `references/execution-checklists.md`.
- **sector-specific issuer** -> consult `references/sector-nuances.md`.
- **source hierarchy / data gaps / citations / staleness** -> consult `references/data-sources.md`.
- **final review** -> run the quality gates in `references/quality-review.md`.
- **mnpi, wall-crossing, offering communications, legal/rating/covenant constraints** -> consult `references/compliance-guardrails.md`.

## Core workflow
For a full recommendation, execute these steps in order:

1. **Frame the mandate**: identify the real capital need, audience, timing constraint, issuer health, and decision required.
2. **Build issuer snapshot**: business, financials, trading/credit profile, capital structure, ownership, catalysts, constraints, and readiness.
3. **Define use of proceeds**: test whether the rationale is specific, credible, value-enhancing, and aligned with prior messaging.
4. **Quantify pro forma impact**: dilution, proceeds, leverage, liquidity, interest cost, ratings/covenant pressure, ownership, maturity ladder, or conversion dilution as applicable.
5. **Compare instruments**: common equity, ipo/follow-on/block/atm/pipe, converts/hybrids, ig/hy bonds, loans, bank debt, private credit, private placements, abs, and fallback alternatives.
6. **Assess market window**: instrument-specific openness, sector sentiment, volatility, rates/spreads, fund flows, recent issuance, competing calendar, catalysts, and go/no-go triggers.
7. **Build comps when decision-useful**: when supported precedent issuance changes likely sizing, pricing, timing, or instrument choice, select relevant deals, adjust for market regime and issuer quality, and state the implication.
8. **Target investors when execution-relevant**: when supported investor evidence or a live preparation mandate requires it, identify buyer types or accounts, objections, outreach sequence, wall-crossing considerations, and book-quality implications.
9. **Recommend structure and execution plan**: size range, terms range, launch window, syndicate/process, approvals, workstreams, decision gates, contingencies.
10. **Review risks and mitigants**: market, issuer, investor, pricing, execution, disclosure, ratings, covenant, regulatory, reputational, and aftermarket risks.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: market window, comparable issuance, investor targeting, pro forma math, and execution/compliance. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Default Deliverable Standard

Lead with the financing decision, not background. For `issuance_recommendation`, use this first-read hierarchy unless the user requests another format:

1. **recommendation and decision requested**: proceed / prepare / defer / switch instrument / dual-track / no issuance; include timing, size or contingent size, conditions, and fallback.
2. **why raise or not raise now**: capital need, funding sufficiency, use of proceeds, signaling, and what would change the recommendation.
3. **instrument comparison**: the decision-useful alternatives, including the recommended instrument and rejected paths.
4. **recommended size, timing, and pro forma impact**: minimum viable, base, and maximum advisable size where relevant; net proceeds, dilution, leverage, liquidity, cost, or conversion impact.
5. **market-window triggers and fallback**: go/no-go criteria, preparation steps, approvals, disclosure/compliance dependencies, and contingency path.
6. **risks, verification items, and sources**: decision-critical gaps and source posture in readable banker language.

Add investor targeting, comparable issuance, detailed execution timetables, or broader market commentary only when available evidence supports the section and it changes the financing recommendation or execution path.

## MD-level judgment requirements
- Always distinguish **market access** from **market receptivity**. A deal that can price may still be strategically unattractive.
- Treat the market window as issuer- and instrument-specific: open for whom, in what size, at what terms, before/after which catalyst, and with which investor base.
- Explain why other instruments are inferior, not just why the recommendation is acceptable.
- Size the deal around capital need, market capacity, dilution/leverage tolerance, liquidity, investor appetite, ratings/covenants, and future flexibility.
- When the decision is to wait, prepare, or launch only after a catalyst, state the preferred contingent financing path rather than implying that a future issuance is certain.
- When executable market inputs such as current price, ADV, volatility, recent issuance evidence, or investor feedback are missing or stale, present size and terms as an illustrative planning case or readiness range, not a recommended base transaction.
- Translate math into judgment: what the transaction solves, what it risks, and what would change the recommendation.
- Build investor targeting from buyer psychology: why the investor buys, what mandate bucket fits, expected objections, and whether the investor is an anchor or price-sensitive filler.
- Include a fallback plan. Serious capital markets advice always has a plan if markets move or investor feedback is weak.

## Calculators
Use `scripts/issuance_math.py` for deterministic math when inputs are available. It supports `equity`, `debt`, and `convertible` modes. Prefer scripts for tie-out math, then interpret the result in banker language. Do not use the script when model definitions, covenants, or accounting treatment are uncertain without labeling assumptions.

When a reader-facing report displays calculator-driven proceeds, dilution, leverage, interest, conversion, or liquidity figures, retain the calculation inputs and the calculation results as support artifacts and list them in `manifest.json`. If multiple scenarios are displayed, preserve a consolidated results artifact or separately named scenario results rather than retaining only the input files.

Example:
```bash
python scripts/issuance_math.py --mode equity --input inputs.json
```

## Coordination with adjacent finance skills
- Use source hierarchy and citation discipline consistent with `financial-source-of-truth`.
- Use `financials-normalizer` or `excel-data-cleaner` before analysis when raw financials are messy.
- Use `model-audit-tieout` and `scenario-sensitivity-generator` when relying on a model.
- Use `memo-builder`, `pitch-deck-builder`, `ib-deck-qc`, and `style-guide-adapter` for final artifact polish.
- Use `buyer-investor-list` for broader buyer/lender/investor list logic, but add issuance-specific security fit, pricing, anchor strategy, and wall-crossing considerations here.
- Use `private-credit-underwriting` for lender-side credit approval, borrower risk recommendation, and committee-grade downside loss analysis. If handing off, use `capital_markets_issuance_to_private_credit_underwriting` in `../../references/handoff-contracts.md`.
- Use `covenant-package-analyzer` for document-first covenant definitions, basket/leakage analysis, and agreement-specific headroom mechanics. If handing off, use `capital_markets_issuance_to_covenant_package_analyzer` in `../../references/handoff-contracts.md`.
- Use `lbo-model-build` and `scenario-sensitivity-generator` for deep debt-capacity and returns analysis, and `distressed-recovery-waterfall` when value breaks, coercive exchanges, or restructuring alternatives become central.

Capital markets views on market clearing, sizing, or likely terms are not lender approval or legal covenant capacity. Preserve `source_log`, `source_as_of_dates`, `evidence_register`, legal/covenant caveats, and open items in any handoff.

## Final self-check
Before answering, verify:
- the recommendation is clear and commercially realistic;
- facts, assumptions, and stale-data risks are labeled;
- math ties out or assumptions are stated;
- any included comps are relevant and adjusted, not blindly averaged;
- any included investor targets are supported by rationale and objections;
- execution steps include approvals, diligence, legal/compliance, rating/covenant, and fallback paths;
- the output could survive senior banker, client, board, investor, and counsel review.
## Validated Handoffs

Producer contracts:
- `capital_markets_issuance_to_private_credit_underwriting` -> `private-credit-underwriting`. Schema: `../../schemas/capital_markets_issuance_to_private_credit_underwriting.schema.json`. Validate with `../../scripts/validate_handoff_payload.py capital_markets_issuance_to_private_credit_underwriting handoffs/capital_markets_issuance_to_private_credit_underwriting.json` before another skill imports it.
- `capital_markets_issuance_to_covenant_package_analyzer` -> `covenant-package-analyzer`. Schema: `../../schemas/capital_markets_issuance_to_covenant_package_analyzer.schema.json`. Validate with `../../scripts/validate_handoff_payload.py capital_markets_issuance_to_covenant_package_analyzer handoffs/capital_markets_issuance_to_covenant_package_analyzer.json` before another skill imports it.

## Standalone HTML Path

When HTML is requested or selected, produce a polished standalone HTML financing report following `../../references/html-artifact-standard.md`. This skill owns the financing judgment, report hierarchy, writing, and presentation. Do not route an ordinary issuance recommendation through `dashboard-builder`, create a dashboard render contract, or force financing analysis into fixed dashboard modules.

Let the transaction decision determine the first-read structure:

- New-money equity, convertible, or hybrid choice: recommendation, funded need and use of proceeds, security comparison, contingent size and terms, pro forma impact, market triggers, and fallback.
- Market-window update: current posture, issuer-specific evidence, go/no-go triggers, alternative instrument or delay path, and immediate readiness actions.
- Debt or private-capital alternative: liquidity or refinancing need, debt-capacity and covenant/rating caveats, structure comparison, execution conditions, and required handoffs.

Do not add generic dashboard navigation, reader-action bars, related-file panels, repeated export controls, or visible internal support machinery merely because the deliverable is HTML. Include a compact print or export feature only if it materially helps the financing workflow.

## HTML Evidence Readiness

For senior, client, committee, board, lender, or external postures, every material number, estimate, date-sensitive fact, sourced claim, assumption, and recommendation must have readable point-of-use citation support. Unknown citation IDs, missing source registers, uncited material numeric claims, or stale market-window inputs are blocking readiness gaps: fix them, downgrade the posture to draft/screen-grade, or surface them explicitly.

For an HTML financing recommendation:

- Display timestamps for market-sensitive inputs such as share price, trading performance, rates, spreads, volatility, borrow, and recent issuance data.
- Identify whether terms are source-backed, market-informed, analyst-calculated, or illustrative assumptions; do not imply price talk or investor feedback when none exists.
- For a wait or prepare recommendation, phrase the headline and decision request as conditional, state the launch or reconsideration triggers, and provide a credible fallback.
- When current execution inputs are missing or stale, call any displayed transaction size a planning case or readiness range rather than an executable recommended base size.
- Do not elevate a simplified burn, coverage, or runway proxy to the headline metric row for a pre-commercial, development-stage, or materially milestone-dependent issuer unless the limitations are decision-critical and unmistakable; prefer reported liquidity, guided spending, or direct cash-use figures in the first read.
- For a convertible recommendation, address existing equity-linked exposure, potential dilution, hedge/borrow mechanics where material, and investor-base implications.
- When displayed figures rely on deterministic calculations, include retained calculation outputs in support artifacts in addition to input assumptions.
- Keep support artifacts and generation mechanics out of the visible report body unless requested.
- Render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: XLSX workbook, polished standalone HTML financing report, native deck/document, generated folder, or justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map

- `../../references/html-artifact-standard.md`: shared standalone HTML design, evidence, and visual-inspection standard.
- `references/workflow.md`: full issuance recommendation workflow.
- `references/output-templates.md`: report-mode and financing-decision output guidance.
- `references/ecm.md`, `references/dcm.md`, and `references/convertibles-hybrids.md`: instrument-specific judgment.
- `references/market-window.md`: launch, wait, and fallback logic.
- `references/data-sources.md` and `references/quality-review.md`: evidence and final review gates.

Referenced files: 15

cim-builder20.5 KB

View saved version →

---
name: cim-builder
description: Draft or refresh buyer-facing CIMs, teasers, CIM storyboards, lender presentations, and management presentations. Do not use for independent CIM diligence; use cim-teardown.
---

# CIM Builder

## Skill Configuration

### Common Skill Instructions

### Source Resolution

Load `../../references/workflow-source-resolution.md`. Resolve only the categories needed for this workflow: `deal_materials`, `process_updates`, `market_data_public_sources`, and `models_workbooks_templates`. Use the shared runtime contract to map each attempted category to an available app, connector, file, export, or user-provided input.

## Relevant Dependency Categories

- `Deal Materials`
- `Process Updates`
- `Relationship & Counterparty Context`
- `Market Data & Public Sources`

## Deliverable Intake

When this skill owns a new substantive user-facing artifact, before source gathering, analysis, modeling, or rendering load `../../references/deliverable-intake-policy.md` and perform its adaptive `request_user_input` preflight for materially unresolved preferences. For a CIM, teaser, or CIM storyboard with an unresolved surface, offer `Polished HTML CIM / storyboard (Recommended)`, `Word document (.docx)`, and `PowerPoint storyboard or deck (.pptx)`. A request for a CIM or page-flow storyboard does not by itself imply slides: select polished standalone HTML by default when intake is not required or when a non-interactive run must apply a default. Select PPTX without a format question when the user explicitly requests slides, a deck, a management presentation, a lender presentation, or `.pptx`. When invoked as a downstream support step within an already scoped workflow, inherit resolved preferences and do not re-prompt.
## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the standalone HTML CIM/storyboard, banker-facing workbook, requested native deck/document, or clear first-read package.

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. The normal hero deliverable for a CIM, teaser, or CIM storyboard is a polished standalone HTML document. Use a native deck/document when requested or selected, a workbook for source/control work, a generated folder first-read file where justified, or chat only for narrow answers. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable and companion deliverables; mention support artifacts only when useful for the user's next action or requested, and do not link to manifests or handoff payloads in an ordinary delivery response.

## Core posture

Act like a senior sell-side investment banker / managing director building materials that must survive client review, buyer diligence, firm compliance, and process execution. Do not behave like a generic deck writer. Optimize for a credible transaction narrative, buyer psychology, evidence discipline, diligence resilience, and refreshability.

A strong CIM output must answer: what should the market believe about this business, why should the right buyers care now, what evidence supports the story, where will diligence push back, and how should the deal team frame the asset without overstating or hiding material issues.

## First classify the assignment

Before drafting, classify the task and proceed with the matching mode. Do not wait for perfect information if a useful partial output can be created with placeholders and open questions.

1. **new build**: create CIM architecture, equity story, page plan, draft language, source log, and diligence asks from available company materials.
2. **refresh**: update an existing CIM for new monthly financials, KPIs, market data, diligence findings, or process positioning.
3. **upgrade / MD review**: improve a rough CIM or analyst draft for story, buyer lens, source quality, risk framing, and banker-grade page logic.
4. **teaser / summary conversion**: create blind or named teaser, executive summary, or buyer outreach material from CIM inputs.
5. **management presentation conversion**: turn CIM materials into buyer meeting narrative, page flow, and Q&A prep.
6. **source / diligence pack**: create source log, tie-out checklist, data room asks, management follow-ups, and red-flag matrix.

## Deliverable Modes

After classifying the assignment, choose the delivery mode independently:

- `cim_document`: draft or refresh a written buyer-facing CIM or teaser; default hero deliverable is polished standalone HTML.
- `storyboard`: develop investment story, proposed page flow, key exhibits, source support, and management asks before circulation; default hero deliverable is polished standalone HTML, with the page-plan workbook as an appropriate companion.
- `presentation`: create slides only when the user requests a deck, slides, `.pptx`, a management presentation, or a lender presentation; the native PPTX is the hero deliverable.
- `source_pack`: create a workbook or structured support package when the requested job is evidence control rather than reader-facing drafting.

A `storyboard` is an internal planning document unless the user explicitly requests a slide storyboard. Do not silently turn it into a presentation.

## Adapt to input completeness

- **No context**: produce a CIM build plan, intake checklist, default outline, interview guide, data request list, source log template, and decision points. Do not invent company facts.
- **Partial context**: draft only sections supported by evidence; mark missing data, assumptions, and low-confidence claims. Include a section-level confidence table and management follow-up list.
- **Full context**: produce the requested materials plus page-by-page source mapping, financial/KPI tie-out, diligence issue log, and MD review checklist.
- **Existing CIM plus updates**: enter refresh mode. Preserve the original, create revised language or a change log, flag stale claims, compare old vs. new metrics, and never delete prior content unless the user explicitly asks.

## Source priority and evidence rules

Prefer sources in this order:

1. user-provided files, prompt context, and explicit instructions.
2. callable connected routes or user-provided exports, such as drive, email, slack, meetings, or file systems.
3. existing deal materials: prior CIM, teaser, management presentation, model, QoE, VDR index, Q&A log, legal/tax/commercial diligence.
4. source financials and operating data: audited financials, management accounts, monthly P&L, KPI exports, CRM, billing, customer, backlog, pipeline, HR, capex, and working capital data.
5. third-party and public research: filings, company websites, industry reports, government sources, market data providers, and web search.
6. clearly labeled assumptions or placeholders.

Use the companion `financial-source-of-truth` skill if available for source hierarchy, stale-data checks, citations, and fact/assumption labels. Use `financials-normalizer` or `excel-data-cleaner` if raw financials require cleaning before analysis. Use `model-audit-tieout` and `ib-deck-qc` before final external-ready circulation.

Never fabricate financial metrics, market share, customer names, management quotes, customer quotes, buyer interest, process status, certifications, awards, or legal conclusions. If a claim is not supported, label it as `needs confirmation` or replace it with a placeholder.

## Required workflow

Follow this sequence unless the user asks for a narrower output:

1. Define transaction context: sale, recap, capital raise, carve-out, debt raise, distressed sale, or other process; identify seller type, buyer universe, confidentiality constraints, process objective, and whether a signed transaction, exclusivity, go-shop, superior-proposal right, or other process-status constraint limits buyer-facing marketing. If a constraint exists, capture it in `manifest.json` as explicit `process_status` and `marketing_posture` metadata; a general transaction workflow label must not imply open buyer outreach.
2. Build the equity story spine: business definition, customer problem, why now, why this company wins, financial proof, growth runway, buyer-specific upside, key risks, and recommended framing.
3. Analyze buyer psychology: strategic, sponsor, lender, growth equity, infrastructure, family office, or other investor lens.
4. Build the fact base: company overview, market, customers, products, financials, KPIs, forecast, management, operations, risks, and evidence gaps.
5. Design the CIM architecture: section order, page-by-page message, exhibit plan, source needs, and open questions.
6. Draft or refresh content: use argument-led page titles, concise bullets, exhibits with a clear so-what, and source notes.
7. Tie out financials and KPIs: reconcile metrics, dates, units, add-backs, LTM periods, CAGRs, margins, chart data, and definitions.
8. Separate external-ready language from banker-internal notes, diligence risks, compliance flags, and management follow-ups.
9. Produce final package: CIM draft or page plan, source log, missing-data list, risk/disclosure matrix, buyer-tailoring notes, refresh log if applicable, and MD review checklist.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: story architecture, source support, financial/model inputs, page drafting, and QC handoff. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Load references as needed

- Use `references/cim_workflow.md` for the full end-to-end workflow and mode-specific behavior.
- Use `references/section_standards.md` when building or reviewing individual CIM sections.
- Use `references/sector_modules.md` when the company belongs to a specific sector or requires KPI-specific treatment.
- Use `references/transaction_modules.md` when tailoring to sale, recap, growth equity, carve-out, debt, or distressed contexts.
- Use `references/source_and_tieout.md` for source hierarchy, financial checks, KPI definitions, add-back discipline, and source log standards.
- Use `references/output_templates.md` for default response structures, page plans, equity story, refresh logs, and disclosure matrices.
- Use `references/review_checklists.md` before presenting external-ready or senior-review-ready outputs.
- Use `../../references/handoff-contracts.md` when exporting a QC package to `ib-deck-qc`; field names must match `cim_builder_to_ib_deck_qc`.
- Use `../../references/evidence-label-taxonomy.md` when mapping native evidence labels into `canonical_evidence_category` for downstream handoffs.

Use bundled assets only as templates; adapt them to the actual deal. Do not represent template language as final legal, compliance, or firm-approved disclosure.

## Output standards

Every substantial CIM build or refresh should include, unless not relevant:

- transaction context and input completeness assessment.
- MD-level equity story spine.
- buyer lens and likely diligence pressure points.
- recommended CIM architecture or updated page flow.
- page-by-page plan with key message, exhibit, required data, source, and open questions.
- draft language for requested sections.
- source log or source-log-ready table.
- financial and KPI tie-out notes.
- missing information request list.
- risk, disclosure, and confidentiality flags.
- internal banker notes separated from external-ready language.
- MD review checklist and next actions.

When the user asks for a finished CIM or deck and the environment supports document or slide creation, create a separate new output file rather than overwriting existing materials. If editing existing files, preserve originals and use a new version unless the user explicitly authorizes overwrite.

## Standalone HTML Path

When HTML is selected or defaulted for a CIM, teaser, or storyboard, produce a polished standalone HTML document following `../../references/html-artifact-standard.md`. This skill owns the document hierarchy, buyer-facing narrative, exhibits, citation placement, and internal-readiness labeling. Do not route ordinary CIM work through `dashboard-builder`, create a dashboard render contract, or add fixed dashboard controls.

For a substantive CIM/storyboard, a useful HTML structure is:

- title page and circulation posture;
- executive story and transaction context;
- investment highlights or proposed buyer narrative;
- proposed CIM architecture and page-by-page exhibit plan;
- supported financial, operating, transaction, or valuation evidence;
- diligence pressure points, disclosure considerations, and management support required;
- source register and readiness conclusion.

Separate buyer-facing draft language from banker-only readiness notes. In a public-source storyboard, visibly identify what can be stated from filed information and what requires management, counsel, or quality-control support before circulation.

## Presentation Path

When presentation mode is selected, produce an editable native deck and follow the same evidence, diligence, and circulation gates. A PPTX may be a useful optional companion to an HTML storyboard only when the user selects it or the workflow clearly requires slide-page design; do not create it by default merely because an HTML document includes a page plan.

## Export contract to `ib-deck-qc`

Any external-ready CIM, teaser, management presentation, lender presentation, or buyer-facing section must carry a QC handoff package before circulation review.

Use the canonical `cim_builder_to_ib_deck_qc` contract in `../../references/handoff-contracts.md`.

Required package fields:
- `artifact_type`, `artifact_version`, `circulation_posture`, `audience`, `transaction_context`, `last_updated`, `page_plan`, `source_log`, `key_numbers_to_tie`, `claim_register`, `chart_and_visual_register`, `financial_tie_outs`, `style_profile_package`, `style_change_log_package`, `confidentiality_and_disclosure_flags`, and `open_items`.

Populate nested records with the canonical component fields in the shared contract. Preserve native CIM fields, but add explicit canonical mappings such as `source_id`, `as_of_date`, `native_evidence_label`, `canonical_evidence_category`, `tie_out_status`, `blocks_circulation`, and `suggested_remediation`.

`ib-deck-qc` is the final banker/client circulation gate. `cim-builder` should not certify a deck as client-ready unless the QC handoff is either complete or the missing items are clearly labeled as blockers.

## Quality bar

Apply these tests before finalizing:

- Would a senior banker understand the buyer-facing story in the first two pages?
- Does each section answer a real buyer underwriting question?
- Are major claims tied to sources or labeled as assumptions?
- Do all financials, KPIs, units, dates, LTM periods, and charts tie across the model, source data, and text?
- Are risks framed credibly rather than hidden?
- Is sensitive information staged appropriately by process phase?
- Does the output create reusable artifacts for related skills: pitch-deck-builder, buyer-investor-list, comps-valuation, dcf-model-builder, lbo-model-build, private-credit-underwriting, covenant-package-analyzer, deal-process-tracker, cim-teardown, and ib-deck-qc?
## Validated Handoffs

Producer contracts:
- `cim_builder_to_ib_deck_qc` -> `ib-deck-qc`. Schema: `../../schemas/cim_builder_to_ib_deck_qc.schema.json`. Validate with `../../scripts/validate_handoff_payload.py cim_builder_to_ib_deck_qc handoffs/cim_builder_to_ib_deck_qc.json` before another skill imports it.

Intake validation:
- From `style-guide-adapter`: require `style_guide_adapter_style_profile` and run `../../scripts/validate_handoff_payload.py style_guide_adapter_style_profile handoffs/style_guide_adapter_style_profile.json` before importing fields into this skill.
- From `style-guide-adapter`: require `style_guide_adapter_change_log` and run `../../scripts/validate_handoff_payload.py style_guide_adapter_change_log handoffs/style_guide_adapter_change_log.json` before importing fields into this skill.

## HTML Evidence Readiness

For senior, client, committee, board, lender, or external postures, every material number, estimate, date-sensitive fact, sourced claim, assumption, and recommendation must have readable point-of-use citation support. Model-derived claims should cite workbook/sheet/cell or range where available. Unknown citation IDs, missing source registers, uncited material numeric claims, stale decision-critical facts, or unsupported process-status implications are blocking readiness gaps: fix them, downgrade the posture to working draft, or surface them as explicit gaps.

For a standalone HTML CIM or storyboard:

- keep the first-read hierarchy focused on buyer narrative, evidence, and circulation posture rather than implementation machinery;
- keep sources traceable near material claims and in a clean source register;
- avoid generic dashboard navigation, report-opening buttons, render-contract metadata, related-file panels, or “model file” modules unless requested and actually relevant;
- render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. For a CIM, teaser, or storyboard in document mode, the hero deliverable is the polished standalone HTML document. For presentation mode, it is the native deck. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then any meaningful companion deliverable. Mention internal support files only when requested or useful for an immediate next step; do not link to `manifest.json` or QC handoff payloads in ordinary delivery responses.

## Runtime Artifact Path

Default deterministic builder: `scripts/build_cim_package.py`. In document or storyboard mode, primary human deliverable is the standalone `cim_storyboard.html` and `cim_package_plan.xlsx` is the page-plan/source-log workpaper companion. Use the builder's explicit presentation path only when PPTX has been selected or requested; in that mode `cim_storyboard.pptx` becomes the primary artifact. When inputs identify signed-transaction or other marketing constraints, carry `process_status` and `marketing_posture` into the manifest. Do not generate a dashboard contract for ordinary CIM work. JSON page plans, source logs, manifests, and handoffs belong under support or handoff paths and must not be presented as the finished CIM. Client-ready status requires source-backed claims, diligence-resilient risk framing, buyer psychology review, visual inspection, and final `ib-deck-qc` before circulation.

Referenced files: 16

cim-teardown19.1 KB

View saved version →

---
name: cim-teardown
description: analyze seller materials into claims, diligence gaps, red flags, and model handoffs. use when the user asks to tear down a cim or banker deck. do not use to write the cim; use cim-builder.
---

# CIM-Teardown

## Skill Configuration

### Common Skill Instructions

### Source Resolution

## Relevant Dependency Categories

- `Deal Materials`
- `Models, Workbooks & Templates`
- `Process Updates`
- `Market Data & Public Sources`

## Deliverable Intake

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. The hero deliverable must be a polished standalone HTML diligence report, workbook, native deck/document, generated folder first-read file, or justified chat-only answer. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing standalone HTML diligence report, workbook, native deck/document, or clear first-read package.

## Trigger Boundary
Use this skill when the user wants to test seller materials, including:
- a CIM, teaser, or investor deck teardown
- a claims ledger from seller materials
- evidence requests, seller asks, or a data-room gap list
- ranked diligence questions or a diligence workplan
- a red-flag register
- quick underwriting implications from seller claims
- a decision-oriented diligence memo for PE, growth, CorpDev, or confirmatory diligence

Do not use this skill for:
- writing, polishing, or designing a CIM
- building a full DCF, LBO, merger model, or valuation workbook
- generic company summaries with no diligence or falsification ask
- pure legal opinions or legal advice
- casual article or deck summarization

## Role / Non-Role
Act as the diligence lead turning seller materials into a falsification-first, decision-grade pack that tells the team whether to keep spending time.

Default posture:
- the CIM is the claim source, not proof
- decision-grade top layer first, broad background later
- definitions before numbers
- gating items before narrative
- explicit kill criteria for each gating item
- first-wave seller asks before second-wave confirmatory diligence
- HTML teardown report first for substantial diligence; concise chat only for narrow follow-ups or explicit quick screens

Minimum input is one seller material artifact and an identifiable deal/company. If inputs are incomplete, still produce the teardown and mark gaps with `UNKNOWN`, `TBD`, `ASSUMPTION`, or `CITATION_TBD`.

Stop and ask for clarification only when document versions, deal perimeter, persona lens, or asset type conflict in a way that would change the answer.

## Fast Workflow
1. Triage deal stage, user-requested artifact, persona lens, available inputs, and connector/export availability.
2. Detect the primary asset type. Load the matching overlay reference before assigning owners or finalizing gates.
3. Build a citation map for files, pages, sections, exhibits, charts, footnotes, versions, and external sources.
4. Run the CIM credibility anomaly pass and promote material trust issues into the IC view.
5. Extract atomic claims, classify them, capture qualifiers, and flag missing definitions.
6. Run quick underwriting math when price plus earnings, cashflow, NOI, EBITDA, FCF, or equivalent metrics appear.
7. Draft first-wave gating items with linked `C-`, `E-`, `Q-`, and `RF-` IDs where available.
8. Create falsification-first questions and a `First-Wave Seller Data Request`.
9. Detect red flags, state `What resolves it`, and link each flag to claims and questions.
10. Produce the requested artifact with appendices, then run readability and audit QA.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: claims extraction, evidence/citation map, financial/KPI tie-out, red flags, and diligence questions. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Artifact Contract
Default output for substantial teardown work is an `extended_analysis` polished standalone HTML diligence report with three layers:
1. compact initial IC recommendation and gating decision
2. decision-useful first-wave diligence sections focused on the user's ask
3. appendices or structured exports for the full claims, evidence, questions, red flags, and tasks/workplan when useful

Default sections:
- `Initial IC Recommendation`, including posture, gating issues, and what changes the recommendation
- `Claims That Matter Most`, including proof status and required validation
- `Red Flags And Kill Tests`, including what resolves each gating issue
- `First-Wave Seller Data Request`, limited to evidence needed before deciding whether to proceed
- `Quick Underwriting Implications` when price and a cashflow/earnings metric exist
- external triangulation pack when connectors or primary exports are missing
- executable workplan when it adds decisions or ownership not already shown in the request table
- appendices: full claims ledger, evidence list, question list, red-flag register, and task/workplan list
- assumptions, missing evidence, and open questions

Use stable IDs across every artifact:
- `claim_id`: `C-0001`
- `evidence_id`: `E-0001`
- `question_id`: `Q-0001`
- `red_flag_id`: `RF-0001`
- `task_id`: `T-0001`

Create CSV, JSON, XLSX, or folder outputs only when the user asks for files or reusable structured output is clearly needed. Keep the same IDs and linkages across the HTML report, chat cover note, and support exports.

For an initial IC discussion, do not create a separate open-diligence section that merely repeats the gating issues, red flags, or first-wave seller request. Keep full linked diligence ledgers as appendices or support artifacts when they are decision-useful or needed by a downstream model or memo workflow.

For an initial IC screen, use one primary first-read gating/red-flag table that includes the relevant kill tests. Do not repeat the same risks in a separate main-body `Red Flags And Kill Tests` table; show only incremental risks there, or keep the full red-flag register in an appendix or support artifact.

For detailed schemas, templates, readability rules, and export contracts, read:
- [report-template.md](references/report-template.md)
- [output-schemas.md](references/output-schemas.md)
- [downstream-handoffs.md](references/downstream-handoffs.md)
- [handoff-contracts.md](../../references/handoff-contracts.md)

## Source / Evidence Posture
No hallucinated citations. Every material fact needs a resolvable pointer or `CITATION_TBD`.

Evidence order:
1. connectors and systems of record
2. user-provided exports, uploads, or data-room files
3. credible primary web sources
4. secondary aggregators, with lower confidence and corroboration when material

Web research can triangulate context but never overrides primary exports or systems of record. Label unsourced owners, deadlines, benchmark tolerances, acceptance thresholds, and kill thresholds as `sourced`, `calculated`, `screening default`, or `assumption`.

For detailed citation, proof, claim, metric, question, and red-flag rules, read:
- [citations.md](references/citations.md)
- [evidence-framework.md](references/evidence-framework.md)
- [claims-taxonomy.md](references/claims-taxonomy.md)
- [metric-definitions.md](references/metric-definitions.md)
- [question-engine.md](references/question-engine.md)
- [red-flag-catalog.md](references/red-flag-catalog.md)

## Validated Handoffs

Producer contracts:
- `cim_teardown_to_memo_builder` -> `memo-builder`. Schema: `../../schemas/cim_teardown_to_memo_builder.schema.json`. Validate with `../../scripts/validate_handoff_payload.py cim_teardown_to_memo_builder handoffs/cim_teardown_to_memo_builder.json` before another skill imports it.
- `cim_teardown_to_model_builder` -> `model builders`. Schema: `../../schemas/cim_teardown_to_model_builder.schema.json`. Validate with `../../scripts/validate_handoff_payload.py cim_teardown_to_model_builder handoffs/cim_teardown_to_model_builder.json` before another skill imports it.

## Script Map
Use scripts only when the user asks for file outputs or a structured teardown workspace.

- `scripts/validate_plan.py`: validates `plan.json` before scaffolding.
- `scripts/run_plan.py`: scaffolds `cim_teardown_report.html`, CSV ledgers, `deal_package.json`, and `manifest.json`; it does not parse the CIM.
- `scripts/validate_outputs.py`: validates output files, headers, IDs, cross-links, citation presence, and priority math.

When using scripts, read [output-schemas.md](references/output-schemas.md) for `plan.json`, file headers, and validation rules. Read [examples.md](references/examples.md) for the happy-path run sequence.

## Standalone HTML Path

When HTML is requested or selected, produce a polished standalone HTML diligence report following `../../references/html-artifact-standard.md`. This skill owns the diligence judgment, report hierarchy, writing, and presentation. Do not route an ordinary CIM teardown HTML report through `dashboard-builder`, create a dashboard render contract, or force linked diligence analysis into fixed dashboard modules.

For an initial IC screen, keep the first-read path tight: initial recommendation, gating claims, red flags and kill tests, first-wave seller data request, preliminary underwriting implications where possible, then evidence limitations and any useful appendix. Keep the main report focused on the decision to continue diligence, not on displaying every control ledger.

Stable `C-`, `E-`, `Q-`, `RF-`, and `T-` IDs remain part of this skill's analytical architecture. Use IDs where they help the IC reader connect an issue to proof or a seller request; preserve dense cross-links in appendices, CSV/JSON support files, or downstream handoffs instead of repeating them throughout the narrative.

Do not add generic dashboard navigation, repeated table export controls, reader-action bars, related-file panels, internal render contracts, or visible generation machinery merely because the deliverable is HTML. Include an exportable structured diligence pack only when requested or when a downstream workflow benefits from it.
Do not add a navigation bar or table-of-contents strip to an ordinary initial IC report unless material length or complexity makes navigation useful.

## HTML Evidence Readiness

For senior, client, committee, board, lender, or external postures, every material number, estimate, date-sensitive fact, sourced claim, assumption, and recommendation must have readable point-of-use citation support. Unknown citation IDs, missing source registers, uncited material numeric claims, unsupported normalization conclusions, or unresolved transaction-perimeter claims are blocking readiness gaps: fix them, downgrade the posture to draft or screen-grade, or surface them explicitly.

For an HTML CIM teardown report:

- Cite complete claims, table rows, or metric phrases where possible rather than repeating source chips across headings, individual cells, and section footers.
- Keep seller claims, analyst calculations, inferred diligence risks, and requested evidence visibly distinct.
- Make the proceed/pause/pass posture conditional when source support is limited to seller materials.
- Keep support artifacts and generation mechanics out of the visible report body unless requested.
- Render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: polished standalone HTML diligence report, XLSX workbook, native deck/document, generated folder, or justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

When the report is complete as an initial screen but material seller evidence is still needed for a proceed, reprice, or pass recommendation, set `blocked_or_partial_status.status` to `partial` and identify the unresolved inputs. Use `complete` only when the requested decision scope is resolved without material missing evidence.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map
Read only the references needed for the request.

Core operating references:
- [../../references/html-artifact-standard.md](../../references/html-artifact-standard.md): shared standalone HTML design, evidence, and visual-inspection standard.
- [analysis-playbook.md](references/analysis-playbook.md): detailed operating rules, anomaly pass, underwriting math, owner mapping, edge cases, and do-not-do rules.
- [report-template.md](references/report-template.md): default HTML report, IC view, seller ask block, readability QA, and templates.
- [citations.md](references/citations.md): detailed citation strings, web/CIM pointer rules, and citation failure modes.
- [evidence-framework.md](references/evidence-framework.md): proof hierarchy, retrieval ladder, source standards, seller tricks, and external triangulation.
- [claims-taxonomy.md](references/claims-taxonomy.md): claim extraction, taxonomy, qualifiers, and worked claim examples.
- [metric-definitions.md](references/metric-definitions.md): definitions and pitfalls for ARR, retention, gross margin, CAC, pipeline, EBITDA, cash conversion, and related metrics.
- [reconciliation-playbooks.md](references/reconciliation-playbooks.md): tie-outs for ARR, bookings, retention, gross margin, pipeline, working capital, and cash conversion.
- [question-engine.md](references/question-engine.md): falsification-first question design, priority scoring, owners, and branching follow-ups.
- [data-requests-library.md](references/data-requests-library.md): exact export wording and field lists for seller requests.
- [red-flag-catalog.md](references/red-flag-catalog.md): red-flag detection logic and severity calibration.
- [output-schemas.md](references/output-schemas.md): CSV/JSON schemas, plan schema, and validator expectations.
- [downstream-handoffs.md](references/downstream-handoffs.md): memo-builder and model-builder handoff fields, mapped to the shared `cim_teardown_to_memo_builder` and `cim_teardown_to_model_builder` contracts.
- [../../references/handoff-contracts.md](../../references/handoff-contracts.md): canonical cross-skill handoff field names.
- [persona-overlays.md](references/persona-overlays.md): PE, growth/VC, CorpDev, diligence lead, and mixed-lens emphasis.
- [security-legal-dd.md](references/security-legal-dd.md): security, compliance, and legal diligence checks when those workstreams are material.
- [examples.md](references/examples.md): trigger examples, edge cases, and a micro worked example.

Asset overlays:
- [overlay-saas.md](references/overlay-saas.md): software, SaaS, usage, or recurring-revenue businesses.
- [overlay-consumer-retail.md](references/overlay-consumer-retail.md): stores, ecommerce, brands, restaurants, and retail rollups.
- [overlay-local-field-services.md](references/overlay-local-field-services.md): route, dispatch, technician, local services, and field operations.
- [overlay-staffing-labor-services.md](references/overlay-staffing-labor-services.md): staffing, labor marketplaces, outsourced labor, and payroll-funding businesses.
- [overlay-fuel-convenience-site-retail.md](references/overlay-fuel-convenience-site-retail.md): fuel, convenience, car wash, QSR pad, and site-retail economics.
- [overlay-industrials.md](references/overlay-industrials.md): manufacturing, processing, distribution-with-production, and asset-heavy industrials.
- [overlay-healthcare.md](references/overlay-healthcare.md): providers, services, reimbursement, regulated healthcare, and patient-volume businesses.
- [overlay-financial-services.md](references/overlay-financial-services.md): asset management, insurance distribution, specialty finance, servicing, payments, and regulated financials.
- [overlay-real-assets.md](references/overlay-real-assets.md): site-driven real assets where throughput, permits, condition, and local demand drive cash flow.
- [overlay-real-estate-heavy.md](references/overlay-real-estate-heavy.md): leases, NOI, occupancy, rent, taxes, and property-heavy operating models.

Referenced files: 40

company-tearsheet14.4 KB

View saved version →

---
name: company-tearsheet
description: Create source-backed banker-facing company, target, borrower, issuer, or counterparty tearsheets. Use for baseline profiles, coverage screens, deal-screen inputs, and meeting context. Do not use for full memos, models, decks, or diligence reports.
---

# Company Tearsheet

## Skill Configuration

### Common Skill Instructions

### Source Resolution

Load `../../references/workflow-source-resolution.md`. Resolve only the catalogued source categories needed for the current tearsheet. Prefer a user-named source first, then one available app, connector, file, export, or pasted input that satisfies the category. Attempt the smallest useful native read only when the workflow needs that source. If a route needs auth, connection, or setup, state the practical limitation and continue from prompt context, active artifacts, pasted or exported material, and public sources when the tearsheet can still be useful. Do not inspect unrelated source categories, run broad source setup, write connector readiness, or create, read, migrate, or update `category-state.json`.

The runtime source categories below cover the catalogued Investment Banking sources. Use `references/source-and-evidence.md` for the broader evidence hierarchy and freshness rules.

### Workflow Sources

When this skill uses a source category, use it for the following information. These are semantic source categories, not fixed connector names.

- `deal_materials`: user-provided files, deal documents, VDR exports, management materials, and diligence sources needed for the company baseline.
- `process_updates`: trackers and internal updates only when active process status materially changes the tearsheet framing.
- `relationship_counterparty_context`: relationship, sponsor, buyer, lender, and counterparty context when it materially changes the coverage or transaction read.
- `market_data_public_sources`: filings, ratings, market data, provider exports, and transaction benchmarks needed for reported facts, valuation context, and freshness checks.
- `models_workbooks_templates`: models, workbook extracts, and approved templates only when they materially improve the baseline or downstream handoff.

## Relevant Dependency Categories

- `Market Data & Public Sources`
- `Relationship & Counterparty Context`
- `Deal Materials`

## Deliverable Intake

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. The hero deliverable must be a polished standalone HTML report, workbook, native deck/document, generated folder first-read file, or justified chat-only answer. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only for a factual baseline or explicitly requested coverage screen; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the owning workflow retains its intended banker-facing deliverable.

## Purpose And Boundary

Create a factual starting point for an Investment Banking workflow: a company or counterparty baseline, an initial coverage screen, a pitch input, a financing/credit snapshot, or a meeting brief input.

Use for source-backed profiles of a public or private company, borrower, issuer, sponsor-owned target, business unit, competitor, client, or relevant counterparty. Use a fund/manager profile only when it is directly part of a banker coverage or transaction context.

Do not turn the tearsheet into a complete investment memo, client pitch, valuation case, acquisition recommendation, lender approval, full diligence workplan, or model. Route expanded work to `memo-builder`, `pitch-deck-builder`, `cim-teardown`, `capital-markets-issuance`, `private-credit-underwriting`, `comps-valuation`, or the relevant model skill.

## Output Modes

Choose the narrowest mode that satisfies the request and requested depth:

- `baseline_tearsheet`: company identity, banker read, high-signal metrics, business/financial profile, mandate relevance, material gaps, sources, and next analytical route.
- `coverage_screen`: use when the prompt asks for initial coverage, pitch preparation, strategic alternatives, acquisition appetite, financing opportunity, or transaction dialogue. Add selected transaction/financing history, preliminary coverage angle, and one consolidated priority-questions table.
- `structured_handoff`: source-backed JSON for a downstream skill; it is support material unless explicitly requested as the deliverable.

Default to `extended_analysis` under `../../references/output-depth-policy.md` for a substantive standalone request, while keeping the selected mode disciplined. Full working depth in `baseline_tearsheet` does not justify expanding it into a pitch workplan; `coverage_screen` requires a mandate signal from the prompt or intake.

## Standalone HTML Path

When HTML is requested or selected, produce a polished standalone HTML banker tearsheet following `../../references/html-artifact-standard.md`. The skill owns its report hierarchy, writing, and presentation. Do not route an ordinary tearsheet through `dashboard-builder`, create a dashboard render contract, or force the content into fixed dashboard modules.

Let the profile type and mandate determine the first-read structure:

- M&A or coverage screen: coverage read, operating snapshot, transaction relevance, actionable validation questions.
- ECM/public issuer: equity story, operating/valuation context, capital-markets relevance, financing considerations.
- Borrower/financing issuer: credit profile, liquidity/leverage, financing need, maturities/covenants, underwriting gaps.
- Private target/sell-side: business profile, scale and KPIs, ownership/process context, diligence flags.
- Counterparty/meeting context: strategic relevance, relationship context when provided, developments, meeting implications.

Do not add generic dashboard navigation, reader-action bars, related-file panels, repeated diligence registers, or visible internal support machinery merely because the output is HTML. Include functionality only when it materially helps the stated banker workflow.

## Workflow

1. **Classify the profile and mode.** Identify the entity, banker use case, audience, `baseline_tearsheet` versus `coverage_screen`, and downstream workflow.
2. **Build a focused source inventory.** Track source identity, type, as-of date, retrieved-at date where relevant, period, freshness, and location.
3. **Extract only critical facts.** Use source-supported business, scale, operating driver, financial, capital structure, valuation, transaction, relationship, and evidence-gap fields relevant to the mandate.
4. **Label evidence and confidence.** Distinguish facts, company/management claims, company-defined metrics, calculations, estimates, assumptions, stale inputs, conflicts, and missing evidence.
5. **Compose the tearsheet.** Lead with why the entity matters for the mandate, then select four or five high-signal metrics and the minimum tables or narrative needed to establish the banker view.
6. **Control scope.** In `coverage_screen`, use one consolidated priority-questions/action table. Do not add a second open-diligence register that repeats it.
7. **Run QC.** Confirm identity, periods, units, currency, source support, freshness, readiness posture, citation readability, and HTML visual quality when applicable.

## Metric And Framing Discipline

- Headline metrics must serve the requested banker question, not merely fill a row of tiles.
- Do not feature stale market-derived valuation, trading levels, transaction values, or financing capacity in the headline view without a clear reason, visible as-of date, and explicit limitation. Prefer a current operating or mandate-relevant metric when valuation is not ready for decision use.
- Use `Valuation Context` or `Indicative Market Reference` for incomplete or derived valuation context; do not imply a valuation opinion, fairness conclusion, or client-ready pitch case.
- Keep management-defined metrics, synergy claims, prospective financing capacity, relationship intelligence, and internal objectives clearly identified as such.

## Source And Evidence Posture

Preserve all source materials, files, workbook tabs, user notes, and connected-app records unless the user explicitly requests a destructive change.

Use the strongest accessible source, starting with user-provided context/files and connected/internal sources, then primary sources, trusted providers, credible secondary sources, public web, and finally clearly labeled assumptions.

Never invent missing facts, metrics, ownership details, ratings, customer names, revenue, EBITDA, AUM, debt, valuation, relationship history, strategic appetite, or transaction objectives. Cite material claims and metrics; disclose stale, preliminary, unaudited, estimated, OCR-derived, low-confidence, and conflicting data.

In a reader-facing artifact, translate support labels into plain banking language such as `Reported`, `Company-defined`, `Derived`, `Management statement`, `Stale market reference`, or `Not yet sourced`; keep internal evidence codes in structured support data only unless explicitly requested.

## Deterministic Helpers And Handoffs

```bash
python scripts/validate_tearsheet_json.py path/to/tearsheet.json
python scripts/build_tearsheet_markdown.py path/to/tearsheet.json output.md
python scripts/map_tearsheet_to_memo_handoff.py path/to/tearsheet.json handoffs/company_tearsheet_to_memo_builder.json --strict
python ../../scripts/validate_handoff_payload.py company_tearsheet_to_memo_builder handoffs/company_tearsheet_to_memo_builder.json --strict
```

The JSON validator and memo mapper support structured handoffs. The Markdown converter is only for explicit Markdown requests or downstream legacy tooling; it does not produce the standalone HTML hero artifact. Raw JSON, Markdown, manifests, and handoff payloads are support artifacts unless the user specifically requests them.

Producer contract:

- `company_tearsheet_to_memo_builder` -> `memo-builder`. Schema: `../../schemas/company_tearsheet_to_memo_builder.schema.json`.

Use `../../references/handoff-contracts.md` for canonical fields and evidence semantics. Handoff payloads belong under `handoffs/`, must preserve source IDs and caveats, and must be listed in `manifest.json` as support or agent artifacts when generated. They are never the hero deliverable unless requested as machine-readable output.

## HTML Evidence Readiness

For senior, committee, board, client, lender, or external postures, every material number, estimate, date-sensitive fact, sourced claim, assumption, and recommendation must have readable point-of-use citation support. Unknown citation IDs, missing source registers, uncited material numerical claims, stale headline valuation inputs, or unsupported transaction implications are blocking readiness gaps: fix them, downgrade the posture to draft/screen-grade, or surface them explicitly.

For an HTML tearsheet:

- Keep the first-read sequence concise: banker read, four or five relevant metrics, operating/transaction or financing context, material gaps, source notes, and next route.
- Prefer one well-designed decision-useful table over several repeated panels.
- Cite complete figures and phrases; do not split fiscal periods, dates, transaction labels, or metric values into fragmented linked tokens.
- Keep support artifacts and generation mechanics out of the visible report body unless requested.
- Render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Do not create Markdown report files, JSON contracts, manifests, run logs, or handoff payloads as the default rich deliverable. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV. For an HTML-selected tearsheet, the hero artifact is the polished standalone HTML report.

## Reference Map

- `../../references/html-artifact-standard.md`: shared HTML design, evidence, and visual-inspection standard.
- `references/source-and-evidence.md`: source hierarchy, citation, freshness, conflict, and evidence-label rules.
- `references/profile-templates.md`: banker profile types and standalone HTML structures.
- `references/metric-library.md`: operating, valuation, financing, transaction, and profile-specific metrics.
- `references/quality-checks.md`: scope, evidence, valuation, and HTML presentation QC.
- `references/integration-guide.md`: downstream Investment Banking handoffs.
- `../../references/handoff-contracts.md`: exact payload fields for validated downstream imports.
- `../../references/evidence-label-taxonomy.md`: shared evidence semantics.
- `../../references/output-depth-policy.md`: analysis-depth policy; default to `extended_analysis` unless an explicit shortening condition applies.

Referenced files: 11

comps-valuation11.7 KB

View saved version →

---
name: comps-valuation
description: Produce source-backed trading-comps valuation for Investment Banking in report or workbook mode. Use for peer selection, trading multiples, implied valuation, Excel or Sheets comps models, EV bridges, refreshes, pressure tests, and workbook QA. Do not use for DCF, LBO, merger, three-statement, or non-banker investment decisions.
---

# Comps Valuation

## Skill Configuration

### Common Skill Instructions

### Source Resolution

Load `../../references/workflow-source-resolution.md`. Resolve only the categories needed for this workflow: `market_data_public_sources` and `models_workbooks_templates`. Use the shared runtime contract to map each attempted category to an available app, connector, file, export, or user-provided input.

## Relevant Dependency Categories

- `Market Data & Public Sources`
- `Models, Workbooks & Templates`

## Deliverable Intake

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md`. Preserve validated handoffs, source IDs, routing metadata, and the hero-deliverable hierarchy. Keep JSON, CSV, Markdown, logs, manifests, and handoff payloads secondary unless explicitly requested. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts when useful.

## Plugin Workflow Routing

For broad transaction workflows, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Keep `comps-valuation` as the comps owner in either mode while preserving routing metadata and the artifact hierarchy of any larger banker-facing package.

## Artifact Contract

Default to `extended_analysis` for a substantive comps request; read `../../references/output-depth-policy.md` before shortening. A report-mode hero is normally a polished standalone HTML valuation report with readable evidence support; a workbook-mode hero is an XLSX workbook with visible source, QA, and valuation support. Use chat-only output only when the user explicitly requests a quick or narrow answer.

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first and keep manifests, model-citation ledgers, handoff payloads, CSV imports, and run logs as support artifacts unless explicitly requested.

## Mode Selection

Select the mode from the prompt and available context; do not ask merely because both modes exist.

- `report` mode: peer-set rationale, trading comps read-through, implied valuation, concise peer review, valuation memo/table, or substantial standalone HTML report where no editable or refreshable workbook is requested.
- `workbook` mode: Excel, Google Sheets, XLSX, exported table, refreshable/model-ready comps, linked source tabs, EV bridge formulas, sensitivity tables, update/extend of an existing workbook, or formula/model pressure test.
- If an existing workbook is supplied and the requested result depends on changing or validating it, use `workbook` mode.
- Ask one targeted question only when report and workbook deliverables are both genuinely plausible and selecting the wrong one would cause material rework or prevent the requested use. When possible, state the inferred default and allow correction rather than blocking.

## Common Workflow

1. Identify target, transaction use, valuation date, currency, fiscal basis, sector/module, and required decision output.
2. Inspect supplied files and callable sources before asking for missing details.
3. Build or challenge the peer universe and label exclusions.
4. Validate dates, currency, period basis, EV bridge, denominators, adjustments, outliers, and source posture.
5. Select a valuation range only after peer and metric quality are explicit.
6. Apply the selected mode's output and QA contract.

## Report Mode

Read only as needed:

- `references/workflow-and-qa.md`
- `references/source-and-staleness-rules.md`
- `references/peer-selection.md`
- `references/module-rules.md`
- `references/valuation-readthrough.md`
- `references/output-templates.md`
- `references/investment-banking-integrations.md`

Use `scripts/build_comps_report.py` when deterministic report materialization from structured inputs is appropriate. Substantial analysis defaults to a polished standalone HTML valuation report following `../../references/html-artifact-standard.md`; chat is appropriate only for narrow checks or explicitly quick answers.

## Standalone HTML Path

When HTML is requested or selected for `report` mode, produce a polished standalone HTML comps valuation report following `../../references/html-artifact-standard.md`. This skill owns its report hierarchy, tables, valuation judgment, and evidence presentation. Do not route an ordinary trading-comps HTML report through `dashboard-builder`, create a dashboard render contract, or force the analysis into fixed dashboard modules.

For an initial strategic-alternatives pitch or implied-valuation request, use this first-read hierarchy:

1. Valuation conclusion and output posture: state the selected framework, implied value range, as-of date, and whether it is screening-only, usable-with-caveats, or decision-useful.
2. Selected peer framework: identify the target trading baseline, primary external comparable anchors, context peers, and excluded or outlier names separately.
3. Implied valuation range: show the selected multiple set, target denominator, enterprise-to-equity bridge, share basis, and premium or discount to the observed target price.
4. Premium and discount discussion: distinguish observable public trading support from strategic/control premium scenarios requiring transaction or buyer-specific support.
5. Comparability and normalization issues: explain accounting, lease, FX, period-basis, estimate-vintage, or business-mix limitations that affect the metric selection.
6. Diligence items and sources: state exactly what must be verified before client or external use and provide readable evidence support.

Keep calculation schedules, evidence ledgers, structured data imports, and manifests as support artifacts unless requested. Keep the first-read report table-forward where valuation comparison is central, but do not add generic dashboard navigation, reader-action bars, repeated export controls, visible render contracts, or source-popover machinery merely because the output is HTML.

## Valuation Framing Discipline

- A target company's current trading multiple is a market baseline or reference point, not external peer evidence. Label it separately from comparable-company anchors.
- When only one true external comparable influences the range, describe the selected range as judgmental, screening-oriented, or single-anchor-supported; do not present it as a statistically supported market range.
- When showing a midpoint interpolated between the target baseline and a single external anchor, label it `Illustrative Midpoint`, not `Screening Mid` or language that suggests an independently observed market point.
- In headline metrics, call the baseline-to-external-anchor percentage `Public Comps Uplift` or `Uplift To External Anchor`, not `Premium Range`; reserve premium terminology for a clearly separate strategic/control-premium scenario analysis.
- Keep secondary or mixed-model peers visible as context when helpful, but do not let them drive the selected multiple without an explicit reason.
- Present strategic or control premium scenarios separately from the public trading range unless transaction evidence supports including them in the selected valuation conclusion.
- When lease-accounting, definition, period, currency, or share-basis differences prevent clean comparison, surface the limitation before relying on the affected multiple.

## Workbook Mode

Read only as needed:

- `references/workbook/comps-framework.md`
- `references/workbook/data-sourcing-and-connectors.md`
- `references/workbook/model-workbook-spec.md`
- `references/workbook/qa-and-pressure-testing.md`
- `references/workbook/review-memo-template.md`
- `references/workbook/dashboard-map.md`

Use `scripts/create_comps_template.py` to create workbook scaffolding and `scripts/audit_comps_workbook.py` for mechanical QA support. Preserve functioning user workbook structure before rebuilding. Workbook mode owns build, extend, refresh, and pressure-test variants.

## Validated Handoffs

Before importing seller or management fields from `cim-teardown` into a workbook-mode comps model, require `cim_teardown_to_model_builder` and run `../../scripts/validate_handoff_payload.py cim_teardown_to_model_builder handoffs/cim_teardown_to_model_builder.json`. Use `../../references/handoff-contracts.md` for canonical field names and add `--strict` before model, deck, committee, lender, board, or client-circulation use.

Handoff payloads belong under `handoffs/` and must be listed in `manifest.json` as support or agent artifacts with validator status and consumer metadata. They are never the hero deliverable unless the user explicitly asks for machine-readable output.

## HTML Evidence Readiness

Unknown citation IDs, missing source registers, uncited material numeric claims, unsupported selected multiples, or unnormalized comparability issues are blocking readiness gaps. Fix them, downgrade the posture, or state the missing support; do not call the output senior/client/committee/board/external-ready while those gaps remain.

For a standalone HTML comps report, provide compact point-of-use citations in the opening valuation conclusion and any headline metric strip for the pricing date, baseline price or multiple, external anchor multiple, and derived implied-value range. Cite complete figures, periods, and metric statements rather than fragmenting linked text or adding repeated citation clutter. Verify that decision-critical public source links used for pricing, filings, and selected-anchor support resolve to the intended source before delivery; when a load-bearing link cannot be validated, identify it as unverified and downgrade the posture or request a replacement source. Keep internal support mechanics out of the visible report; and render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

## Boundaries

Use `financials-normalizer` for messy deal financials before reliance, `model-audit-tieout` when standalone model audit is the actual job, and `ib-deck-qc` for final client or committee circulation checks. Do not present legal, tax, fairness, solvency, or formal valuation opinions.

Referenced files: 19

covenant-package-analyzer18 KB

View saved version →

---
name: covenant-package-analyzer
description: Analyze credit documents for covenant definitions, baskets, leakage, headroom mechanics, amendments, and waivers. Use for finance-side covenant reviews, not legal advice.
---

# Covenant Package Analyzer

## Skill Configuration

### Common Skill Instructions

### Source Resolution

Load `../../references/workflow-source-resolution.md`. Resolve only the categories needed for this workflow: `deal_materials` and `models_workbooks_templates`. Use the shared runtime contract to map each attempted category to an available app, connector, file, export, or user-provided input.

## Relevant Dependency Categories

- `Deal Materials`
- `Market Data & Public Sources`
- `Process Updates`
- `Models, Workbooks & Templates`

## Deliverable Intake

When this skill owns a new substantive user-facing artifact, before source gathering, analysis, modeling, or rendering load `../../references/deliverable-intake-policy.md` and perform its adaptive `request_user_input` preflight for materially unresolved preferences. For a covenant package review, amendment analysis, or waiver memo with an unresolved surface, offer `Polished HTML covenant review memo (Recommended)`, `Excel covenant headroom workbook`, and `Word memo (.docx)`. Default to polished standalone HTML when intake is not required or a non-interactive run must apply a default. Select workbook-first output without a format question when the user requests calculations, covenant headroom, basket capacity, or scenarios requiring tabular inputs and formulas. When invoked as a downstream support step within an already scoped workflow, inherit resolved preferences and do not re-prompt.

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. The normal hero deliverable for a covenant review, amendment analysis, or waiver memo is a polished standalone HTML finance-side credit memo. Use a workbook as the hero deliverable for computed headroom, basket capacity, or scenario analysis, with a concise standalone HTML explanation as an appropriate companion. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable and any meaningful companion; do not link to render contracts, manifests, or handoff payloads in ordinary delivery responses.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the standalone HTML covenant memo, banker-facing headroom workbook, requested native document, or clear first-read package.

## Trigger Boundary

Use this skill for finance-side covenant analysis of credit agreements, indentures, note purchase agreements, term sheets, commitment papers, amendments, waivers, side letters, covenant certificates, and related debt documents.

Lead when the user asks what the borrower can do, what lenders can stop, how covenant ratios bind, how EBITDA and baskets create flexibility, what leakage exists, what negotiation asks matter, or what headroom can be computed from available documents and financials.

Do not present legal advice or final legal interpretation. Route contract drafting, enforceability, governing-law, or clause-language negotiation to legal or contract-review workflows, while framing this skill's output as finance-side analysis for counsel and the deal team.

## Role / Non-Role

Default lead role: document-first covenant and credit-agreement analyst.

Own document universe mapping, operative versions, definitions, baskets, leakage, restricted payments, investments, debt/lien capacity, covenant formulas, EBITDA definitions, collateral and guarantor gaps, amendment mechanics, waiver effects, source-backed headroom framing, and negotiation flags.

Hand off adjacent work:
- `financial-source-of-truth`: source hierarchy, stale-data checks, source conflicts, and fact / assumption / claim labels.
- `financials-normalizer`: reported EBITDA, adjusted EBITDA, normalized EBITDA, lender-after-haircut EBITDA, NWC, and add-back support.
- `private-credit-underwriting`: borrower-level proceed / decline recommendation, risk rating, downside loss view, collateral/recovery view, and credit committee memo.
- `capital-markets-issuance`: issuer-side financing strategy, instrument choice, market window, investor targeting, launch timing, and use-of-proceeds advice.
- `lbo-model-build` or `three-statement-model-builder`: covenant thresholds, liquidity, first-breach timing, debt paydown, and downside case modeling.
- `model-audit-tieout`: covenant calculators, compliance models, borrowing-base files, or uploaded workbook QA.
- `ib-deck-qc`: final committee materials, lender decks, board materials, or client reports.

If the user explicitly invokes `covenant-package-analyzer`, keep this skill as lead and label underwriting, capital markets, model, or legal implications as downstream read-through instead of silently switching ownership.

## Deliverable Modes

Choose the artifact mode independently from the analysis type:

- `covenant_memo`: document-first review of a credit agreement, amendment, waiver, covenant package, or reporting/default question; default hero deliverable is a polished standalone HTML memo.
- `headroom_workbook`: calculation-heavy ratio, basket, usage, or scenario work supported by inputs and governing definitions; default hero deliverable is an XLSX workbook, with an HTML summary when useful.
- `screening_note`: narrow initial screen from incomplete excerpts or public materials; use HTML or chat according to scope while clearly labeling missing reliance inputs.

An amendment or waiver review does not by itself call for a dashboard. Do not route an ordinary covenant review HTML memo through `dashboard-builder`.

For a substantive `covenant_memo`, a full inline Markdown review is not a completed deliverable unless the user explicitly requests chat, Markdown, or no file. When polished HTML is selected or defaulted, create the `.html` artifact, visually inspect it, and return a concise cover note with the HTML file as the hero deliverable.

## Fast Workflow

1. Use available context first: inspect prompt, attachments, prior context, and connectors before asking for documents.
2. Classify the request: term sheet screen, credit agreement teardown, amendment/waiver review, headroom analysis, EBITDA definition review, basket capacity review, or negotiation playbook.
3. Lock the document universe: borrower/issuer, guarantors, collateral agent, lenders, tranches, dates, amendments, and draft/executed status.
4. Create a source index with document type, date, source tier, operative status, missing schedules, and retrieval path.
5. Map capital structure and document stack: facilities, liens, guarantees, maturities, revolver, incremental facilities, intercreditor, collateral, and restricted/unrestricted subsidiaries.
6. Extract controlling definitions: EBITDA, CNI, debt, secured debt, net debt, fixed charges, pro forma basis, available amount, permitted acquisitions, collateral, and subsidiary definitions.
7. Analyze financial covenants, negative covenants, EBITDA add-backs, baskets, leakage paths, collateral/guarantor coverage, reporting, defaults, amendments, waivers, and voting controls.
8. Compute headroom only when definitions and financial inputs support it; otherwise state the exact missing metrics and affected conclusion.
9. Render decision-ready findings with fact/assumption/inference labels, severity, negotiation asks, open items, and downstream handoff.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: document universe, definitions, baskets/leakage, headroom math, and finance-side negotiation flags. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Artifact Contract

Default output sections:
- `Executive Summary`: recommendation, output posture, top risks, and required next step.
- `Source Base And Scope`: documents reviewed, dates, source tiers, and missing materials.
- `Covenant Package Snapshot`: parties, facilities, collateral, guarantees, financial covenants, reporting, and events of default.
- `Financial Covenant And Headroom`: covenant, threshold, actual, headroom, cushion, test date, and source.
- `EBITDA Definition And Add-Back Risk`: components, caps, pro forma terms, QoE/lender EBITDA gaps, and support needed.
- `Basket And Leakage Map`: debt, liens, RPs, investments, asset sales, junior debt prepayments, unrestricted subsidiaries, and leakage paths.
- `Negotiation Flags`: issue, severity, provision, economic impact, proposed ask, fallback, and owner.
- `Open Items And Data Requests`: exact missing file/value, why it matters, affected conclusion, and minimum substitute.
- `Downstream Handoff`: outputs for financial normalization, underwriting, LBO/forecast modeling, model audit, and deck QC.

For an amendment or waiver review, prefer the following document flow over forcing every generic covenant-package section:

1. executive conclusion and reliance posture;
2. two to four decision-gating questions that must be resolved before reliance;
3. document universe and operative amendment;
4. what the amendment or waiver covers;
5. what it does not waive or establish;
6. reporting deadlines and required deliverables;
7. covenant applicability and headroom gating analysis;
8. residual default, certificate, liquidity, and lender-action risks;
9. information request before reliance;
10. sources and posture conclusion.

Put the gating questions in a concise early callout or table before detailed deadline and headroom tables. For example: whether the reporting delivery occurred, whether required compliance certificates were delivered, whether the springing test applied, and whether the operative ratio calculation is supported. Keep later tables for evidence and mechanics rather than making the reader discover the decision gates there.

When consuming upstream structured context, use the canonical contracts in `../../references/handoff-contracts.md`:
- `capital_markets_issuance_to_covenant_package_analyzer`
- `private_credit_underwriting_to_covenant_package_analyzer`

Never treat proposed covenant capacity or proxy headroom as factual unless operative definitions, latest financials, debt schedule, basket usage, amendments, and prior usage are available or clearly caveated.

End with one posture label from the output reference: `decision-grade`, `diligence-grade`, `screening-only`, `not-supportable`, or `blocked`.

## Source And Evidence Posture

Prioritize user-provided and connected-source documents, then primary public filings and official sources, then trusted secondary sources, with general web search only as fallback. Ask for more only when a missing item changes the conclusion.

Use evidence labels from the source reference in analysis, structured support, and handoffs: `fact_primary`, `fact_secondary`, `management_claim`, `seller_claim`, `third_party_estimate`, `assumption`, `inference`, or `unsupported`. In a reader-facing memo, translate them into plain finance-side descriptions such as `Executed amendment`, `SEC filing`, `Company disclosure`, `Analyst inference`, or `Not yet supported`; do not display raw internal evidence codes as presentation labels unless the user requests them.

Never state that a borrower has covenant capacity unless the operative definition, latest financials, debt schedule, basket mechanics, and relevant prior usage are available or clearly caveated.

## Validated Handoffs

Intake validation:
- From `capital-markets-issuance`: require `capital_markets_issuance_to_covenant_package_analyzer` and run `../../scripts/validate_handoff_payload.py capital_markets_issuance_to_covenant_package_analyzer handoffs/capital_markets_issuance_to_covenant_package_analyzer.json` before importing fields into this skill.
- From `private-credit-underwriting`: require `private_credit_underwriting_to_covenant_package_analyzer` and run `../../scripts/validate_handoff_payload.py private_credit_underwriting_to_covenant_package_analyzer handoffs/private_credit_underwriting_to_covenant_package_analyzer.json` before importing fields into this skill.

## Script Map

- `scripts/scan_covenant_package.py`: first-pass scan of text, HTML, Markdown, JSON, CSV, and DOCX files for covenant terms, EBITDA terms, baskets, leakage terms, events of default, amendments, and issue candidates.
- `scripts/calculate_covenant_headroom.py`: compute headroom from a covenant test CSV when actual metrics and thresholds are available.

Treat scripts as triage aids. Always apply senior credit judgment and cite the governing document source before finalizing.

## HTML Evidence Readiness

For senior, client, committee, board, lender, or external postures, every material covenant threshold, deadline, defined term, waiver statement, compliance conclusion, estimate, assumption, and recommendation must have readable point-of-use citation support. Model-derived claims should cite workbook/sheet/cell or range where available. Unknown citation IDs, missing source registers, uncited material numeric claims, stale operative-document assumptions, or unsupported compliance/headroom conclusions are blocking readiness gaps: fix them, downgrade the posture, or surface them as explicit gaps.

For standalone HTML output, follow `../../references/html-artifact-standard.md` for shared professional styling, structure, accessibility, and local visual-QA requirements.

For a standalone HTML covenant memo:

- use a document-style hierarchy focused on the answer, operative provisions, residual risks, reliance gates, and evidence requests;
- foreground two to four decision-gating questions before detailed deadline or headroom tables in an amendment or waiver review;
- cite material terms and conclusions close to their use, but avoid repeating citation chips on every sentence or adding redundant section-source strips when the claim is already traceable;
- use reader-facing evidence language in visible tables and callouts, while retaining exact evidence codes only in support data or when explicitly requested;
- separate finance-side conclusions from legal questions requiring counsel;
- do not return the entire completed memo as inline Markdown when HTML is selected or defaulted; chat should point to the inspected HTML hero artifact and summarize the conclusion briefly;
- do not create dashboard render contracts, dashboard navigation, default copy/export controls, or related-file modules for ordinary covenant review work;
- render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. For covenant review, amendment analysis, or waiver memo work, the hero deliverable is normally the polished standalone HTML memo. For computed headroom, basket capacity, or scenario work, use the workbook as hero and a standalone HTML summary only when useful. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then any meaningful companion. Mention internal support files only when requested or useful for an immediate next step.

## Reference Map

- Read `references/source-and-evidence.md` when gathering documents, resolving source conflicts, applying evidence labels, checking stale documents, or making data requests.
- Read `references/covenant-analysis-playbook.md` when classifying request type or performing clause-by-clause covenant, definition, collateral, reporting, default, amendment, or waiver review.
- Read `references/baskets-leakage-taxonomy.md` when analyzing EBITDA definition risk, basket mechanics, leakage paths, priming risk, or negotiation asks.
- Read `references/output-templates.md` when formatting the memo, issue log, source base, headroom table, leakage map, data requests, severity, or output posture.
- Read `references/investment-banking-integrations.md` when handing findings to financial normalization, private credit underwriting, LBO/three-statement modeling, model audit, capital markets, or deck QC.

Referenced files: 12

dcf-model-builder11 KB

View saved version →

---
name: dcf-model-builder
description: Use when building code-backed DCF exports, WACC/terminal value work, EV-to-equity bridges, sensitivities, or price targets; not comps-only.
---

# DCF Model Builder

## Skill Configuration

### Common Skill Instructions

## Relevant Dependency Categories

- `Market Data & Public Sources`
- `Models, Workbooks & Templates`
- `Deal Materials`

## Deliverable Intake

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing workbook or an explicitly requested standalone HTML valuation summary, native deck/document, or clear first-read package.

Use for DCF, intrinsic value, FCFF/FCFE, WACC, terminal value, EV-to-equity, per-share value, and price-target work. Do not use for comps-only, audits, LBO, merger, memo, or deck-QC work.

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. For substantive DCF work, the normal hero deliverable is a polished banker-readable workbook with an insight-led first visible tab. Create a standalone HTML valuation summary only when the user explicitly requests HTML or a narrative companion; the workbook remains the model source of truth. CSV, JSON, Markdown, run logs, manifests, model-citation ledgers, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Workflow
1. Classify: template, partial-context screen, full-plan run, deterministic export, formula workbook, or handoff.
2. Read only needed references; usually `plan-schema.md`, `output-spec.md`, and integrations.
3. Create or locate `plan.json`; preserve user assumptions and source labels.
4. Validate, run the requested export, read the run log, and build the first-read workbook view around valuation range, market read-through, drivers, source posture, and open items.
5. Keep calculation integrity and decision readiness separate: formula/control tie-outs may be `OK` while source readiness remains `OPEN` or `screen-grade`.
6. Render and visually inspect the workbook summary, valuation, assumptions/sources, sensitivities, and checks tabs before reporting artifacts.
7. Hard failures mean `not-decision-ready`. Estimate- or placeholder-driven value means open with `Screen-grade only; forecast, WACC, and terminal assumptions require review.`

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: source support, historical normalization, forecast drivers, WACC/terminal value, sensitivities, and audit. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Artifacts
`deterministic_export`: write to the selected `--output-dir` (default `./output` from the caller's current working directory). The hero deliverable is `model.xlsx`, opening on a banker-readable `Cover`, `Executive Summary`, or `Dashboard` tab per `../../references/workbook-first-tab-standard.md`. Agent-facing support artifacts are `plan.json`, `run_log.json`, and `manifest.json`. Write legacy `report.md` only when explicitly requested with `--write-report-md`.

`banker_formula_workbook`: formula workbook plus separate run log and manifest; not arbitrary formula generation.

## Validated Handoffs

Intake validation:
- From `cim-teardown`: require `cim_teardown_to_model_builder` and run `../../scripts/validate_handoff_payload.py cim_teardown_to_model_builder handoffs/cim_teardown_to_model_builder.json` before importing fields into this skill.

## Script Map
- `scripts/validate_plan.py path/to/plan.json`
- `scripts/run_pipeline.py path/to/plan.json --output-dir output --print-report`
- `scripts/build_banker_formula_workbook.py path/to/plan.json --output-dir output`
- `scripts/*_runtime`: private engine internals; inspect only while debugging scripts.

## Workbook Evidence Readiness

The workbook is the analytical source of truth. For senior, client, committee, board, lender, or external postures, every material input and derived output must be traceable through readable source notes and `model_citations` / `model_citations_path` records down to workbook sheet/cell or range where available.

Unknown source IDs, missing model citations for headline valuation outputs, stale market or bridge inputs, unsupported terminal assumptions, or uncited material numeric claims are blocking readiness gaps. Fix them, cap the posture at `screen-grade`, or surface the gaps explicitly; do not call a workbook senior/client/committee/board/external-ready while they remain.

The first visible tab must display two explicitly labeled status fields in its first-read status block: `Calculation integrity` and `Decision readiness`. Do not summarize a workbook as `OK` merely because formula and tie-out checks pass when forecast, WACC, terminal value, equity bridge, or share-count evidence remains open.

For public-company strategic alternatives or market-reference work, make the current trading reference, premium or discount, terminal-value concentration, and unresolved bridge/share-count choices visible in the first-read view. When current trading materially diverges from base value, include a controlled numeric reverse-DCF output: hold the base valuation framework constant while solving for an operating assumption, or hold base operating assumptions constant while solving for WACC or terminal growth. Do not treat proximity to a composite downside or upside scenario as a substitute for that test.

For headline derived outputs such as enterprise value, equity value, per-share value, premium/discount, or a market-implied solved assumption, model-citation records must include the material upstream operating, WACC, terminal-value, EV-to-equity bridge, share-count, and market-reference dependencies used in the calculation. Record formula-error scan outcomes in the run log as an explicit result or match count; do not defer this evidence only to transient console output.

## Optional HTML Companion

When the user explicitly requests an HTML report or visual valuation summary, keep this skill as the analytical owner and produce a polished standalone HTML companion following `../../references/html-artifact-standard.md`. Do not route an ordinary DCF HTML summary through `dashboard-builder`, create a dashboard render contract, or force workbook-derived valuation findings into fixed dashboard modules.

In that HTML companion, cite workbook-derived valuation outputs to exact workbook cell/range records through `model_citations` or `model_citations_path` wherever available. Do not collapse DCF outputs to a generic `model-output` citation when the workbook location is known. Render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

Do not expose raw JSON, Markdown report files, model-citation ledgers, or run logs as the default final artifact.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: normally the XLSX valuation workbook; an explicitly requested standalone HTML valuation summary; native deck/document; generated folder; or justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, model-citation ledgers, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map
- `../../references/workbook-first-tab-standard.md`: required first-read workbook decision view.
- `../../references/html-artifact-standard.md`: optional standalone HTML companion and visual QA standard.
- `plan-schema.md`, `output-spec.md`, `banker-formula-workbook-contract.md`: contracts.
- `model-math.md`, `dcf-architecture.md`, `cash-flow-methods.md`, `wacc-terminal-value.md`: methods.
- `valuation-judgment.md`, `sensitivity-and-scenarios.md`, `integrity-controls.md`, `industry-playbooks.md`, `output-and-review.md`, `qa-checks.md`: review.

## Runtime Artifact Path

Default deterministic outputs are `model.xlsx`, `manifest.json`, `run_log.json`, and `model_citations.json`; formula mode emits `banker_formula_workbook.xlsx` with the same shared manifest and citation ledger. The workbook is the primary human deliverable and must open on `Cover`, `Executive Summary`, or `Dashboard`. Run logs, plans, and `model_citations.json` are support artifacts; dashboards and memos should cite model outputs through the ledger rather than generic model citations. Senior-ready status requires source-backed assumptions, workbook/cell provenance, checks, and no unresolved citation gaps.

Referenced files: 27

deal-process-tracker14.9 KB

View saved version →

---
name: deal-process-tracker
description: Build, update, or reconstruct IB deal-process trackers in a banker-facing workbook. Use for buyer progression, outreach, NDAs, access, diligence, bids, deadlines, process status, or proxy-disclosed sale-process chronology. Do not use to create buyer universes from scratch or write narrative HTML reports.
---

# Deal Process Tracker

## Skill Configuration

### Common Skill Instructions

### Source Resolution

Load `../../references/workflow-source-resolution.md`. Resolve only the categories needed for this workflow: `deal_materials`, `process_updates`, `relationship_counterparty_context`, and `models_workbooks_templates`. Use the shared runtime contract to map each attempted category to an available app, connector, file, export, or user-provided input.

## Relevant Dependency Categories

- `Process Updates`
- `Deal Materials`
- `Relationship & Counterparty Context`

## Deliverable Intake

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. For a substantive process build, update, or reconstruction, the hero deliverable is a polished XLSX tracker with an executive `Dashboard` first tab. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, which is the workbook here, then support artifacts in one short sentence if useful.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing workbook. Route a user request for a narrative HTML process report or board-style memo to `memo-builder`, using the tracker workbook or extracted process facts as source material; route a requested presentation to `pitch-deck-builder`.

## Trigger Boundary

Use for building, updating, or reconstructing IB deal-process trackers: buyer funnel, outreach, NDAs, materials access, diligence, process letters, IOIs/LOIs, bids, owners, dates, status, open issues, senior escalation, or public-filing chronology of a completed or signed sale process.

Role: maintain the process-execution spine or reconstruct disclosed process history, turning fragmented process facts into a workbook with source-backed status, MD judgment, risk, decision points, and change history where applicable.

Non-role: do not create the initial buyer universe from scratch, send outreach, grant materials access, provide legal advice, or silently overwrite historical tracker data. Use `buyer-investor-list` for universe creation and specialist skills for modeling, credit, covenant, deck, memo, and QC work.

## Fast Workflow

1. Choose workbook use case: live-process build, partial-context structuring, existing-tracker update, public-process reconstruction, executive/process update, or bid/round decision support.
2. Frame the process: transaction type, seller/client, asset, stage, buyer mix, confidentiality posture, public/private status, counsel/legal dependencies, deadlines, and decision point.
3. Gather and reconcile sources from prompt, uploaded files, existing tracker, callable connected routes, user-provided exports, deal docs, meeting notes, and public sources only when needed.
4. Normalize buyer names, stages, statuses, dates, owners, deadlines, risk levels, confidence labels, and tracker modules using `references/tracker-schema.md`.
5. Build or update the executive `Dashboard` tab, buyer master, contacts, outreach, NDA, document access, diligence, calendar, bids, issues/escalations, change log, sources, and definitions as needed.
6. Apply MD judgment to buyer credibility, process momentum, competitive tension, bid likelihood, confidentiality risk, stale items, and intervention needs.
7. Produce the right output view and run QA for missing owners, stale buyers, unsupported bid values, NDA/access conflicts, open diligence, and fact/inference labeling.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: party/status updates, materials and NDA status, diligence/bid milestones, owner actions, and process risks. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Artifact Contract

Default workbook content for a tracker build, refresh, or reconstruction:

1. Executive command view: process health, buyer funnel, priority buyers, upcoming deadlines, key risks, client decisions, and MD interventions.
2. Operating tracker: buyer master, outreach, NDA, document access, diligence, calendar, bids, issues, and change log.
3. Judgment layer: buyer credibility, bid likelihood, competitive tension, risk-adjusted bid quality, process risk, confidentiality risk, and escalation recommendations.

Default to `extended_analysis` even for chat answers: include the executive command view, operating tracker logic, judgment layer, source/caveat notes, change-log posture, and next actions that matter. Use compact markdown tables and bullets only when the user explicitly asks for a short update, the task is a narrow delta to an existing full tracker, or the response is a cover note for the workbook. Create or update a polished workbook with separate operating tabs and an executive `Dashboard` first tab. Read `../../references/output-depth-policy.md` before shortening.

This skill is workbook-owned. Do not create an automatic HTML companion, dashboard render contract, or dashboard-builder package for an ordinary tracker request. If the user primarily wants a narrative HTML executive summary, board process review, or reader-facing process memo, route to `memo-builder`; the tracker may provide source-backed schedules or a workbook companion when useful.

### Public-Process Reconstruction

When the source is a definitive proxy, merger filing, board disclosure, or similar public record rather than a live deal-team tracker, build a retrospective workbook that clearly states the disclosed scope. Include the executive conclusion, bidder progression, timeline, access or solicitation gates, bid and price progression, go-shop or no-shop mechanics where applicable, competitive-tension assessment, sources, and limitations. Distinguish filed facts from banker inference and counsel-review issues. Do not invent live owners, outreach tasks, or unresolved operating statuses merely to fill a tracker template.

Import from `buyer-investor-list`: consume `buyer_investor_list_to_deal_process_tracker` from `../../references/handoff-contracts.md`; validate automation payloads with `../../schemas/buyer_investor_list_to_deal_process_tracker.schema.json`. If `party_id`, `tier`, `recommended_wave`, or outreach eligibility is missing, create the row as `needs_review`; preserve `holds_and_exclusions` separately.

Import from `meeting-prep`: consume `meeting_prep_to_deal_process_tracker` from `../../references/handoff-contracts.md`; validate against `../../schemas/meeting_prep_to_deal_process_tracker.schema.json`. Translate only concrete process events into tracker deltas and preserve prior status, reason, date, and source.

## Source, Safety, And Evidence Posture

Use the user's prompt, existing tracker/workbook, deal artifacts, callable connected routes, user-provided exports, and uploaded documents first. Use web only as fallback for public/company/market facts. Cite sources when used.

Never delete or overwrite silently. Preserve rows, fields, notes, bid values, dates, and history unless explicitly requested; for updates, add a change log with prior value, new value, source, confidence, and review flag.

Separate confirmed facts, inferences, unverified items, conflicts, and recommendations. Respect NDA, clean-team, competitor, public-company, antitrust, employee, customer, pricing, MNPI, and legal-process sensitivities. Do not act on behalf of the deal team unless explicitly asked and supported by the environment.

## Validated Handoffs

Intake validation:
- From `buyer-investor-list`: require `buyer_investor_list_to_deal_process_tracker` and run `../../scripts/validate_handoff_payload.py buyer_investor_list_to_deal_process_tracker handoffs/buyer_investor_list_to_deal_process_tracker.json` before importing fields into this skill.
- From `meeting-prep`: require `meeting_prep_to_deal_process_tracker` and run `../../scripts/validate_handoff_payload.py meeting_prep_to_deal_process_tracker handoffs/meeting_prep_to_deal_process_tracker.json` before importing fields into this skill.

## Script Map

For deterministic tracker workbook materialization, use `scripts/build_process_tracker.py`. For import validation, use:

- `../../scripts/validate_handoff_payload.py buyer_investor_list_to_deal_process_tracker <payload.json>`
- `../../scripts/validate_handoff_payload.py meeting_prep_to_deal_process_tracker <payload.json>`

## Workbook Evidence Readiness

For senior, client, committee, board, lender, or external postures, every material number, date-sensitive fact, sourced claim, assumption, and recommendation in the workbook must be traceable at the point of use through a source ID, source column, source note, or clearly linked source register. For analysis derived from workbook calculations, retain readable inputs and formulas or calculation support.

Unknown source IDs, missing source registers, unsupported bid values or deadlines, unlabeled banker inferences, or unresolved legal/process-fairness conclusions are blocking readiness gaps. Fix them, downgrade the posture to draft or working-team use, or surface the missing support explicitly; do not call the workbook senior/client/committee/board/external-ready while those gaps remain.

Before delivering a substantive tracker workbook, inspect key ranges, scan for formula errors where formulas are present, and render and visually inspect the executive `Dashboard` and material operating tabs. Long operating tables should use frozen header rows and filters or structured tables where feasible; timelines, bid grids, and issue logs must remain legible at normal zoom.

## Presentation Boundary

This skill does not own a narrative HTML report mode. When the user explicitly requests an HTML report, board-style process narrative, or standalone presentation layer, preserve the tracker as the process source and route the reader-facing synthesis to `memo-builder` or `pitch-deck-builder` as appropriate. Do not route an ordinary process tracker through `dashboard-builder`.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. For a substantive request owned by this skill, identify the XLSX tracker workbook as the hero deliverable. Do not create Markdown or HTML reports as the default deliverable, and do not present JSON contracts, manifests, run logs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map

Load references only as needed:

- `references/tracker-schema.md`: read when creating/updating tracker modules, workbook tabs, fields, controlled values, and structured tables.
- `references/md-judgment.md`: read when ranking buyers, flagging risks, deciding escalation, comparing bids, or summarizing process health.
- `references/source-handling.md`: read when extracting from emails/docs/calendars, reconciling conflicts, preserving history, or updating an existing tracker.
- `references/output-templates.md`: read when designing workbook views for MD summaries, weekly client updates, board updates, buyer assessments, bid reviews, tracker build/update summaries, or public-process reconstructions.
- `references/quality-checks.md`: read before finalizing any tracker, update, recommendation, or import.
- `../../references/handoff-contracts.md`: read when importing from `buyer-investor-list` or `meeting-prep`, or when exact field-name parity matters.
- `../../references/evidence-label-taxonomy.md`: read when mapping process status, source notes, or confidence labels into shared evidence categories.
- `../../references/output-depth-policy.md`: read when deciding whether a compact process update is justified; default to `extended_analysis`.

## Runtime Artifact Path

Default deterministic builder: `scripts/build_process_tracker.py`. Primary human deliverable is `deal_process_tracker.xlsx` with an executive `Dashboard` first tab. Support artifacts live under `support/` and may include intake or source-ledger JSON; `manifest.json` is agent-facing and must identify the workbook as `first_read`. Senior-ready live trackers require current source dates, owner/status coverage for live process items, stale-date review, and open-items escalation; public-process reconstructions require disclosed-scope labeling, fact/inference separation, and explicit counsel-review flags where legal characterization matters.

Referenced files: 8

distressed-recovery-waterfall23.5 KB

View saved version →

---
name: distressed-recovery-waterfall
description: Analyze distressed capital structures and recovery waterfalls. Use when the user asks about claims, lien priority, fulcrum security, plan value, liquidation value, sale paths, or restructuring recoveries. Do not use for standard LBO modeling.
---

# Distressed Recovery Waterfall

## Skill Configuration

### Common Skill Instructions

### Source Resolution

## Relevant Dependency Categories

- `Deal Materials`
- `Market Data & Public Sources`
- `Models, Workbooks & Templates`
- `Process Updates`

## Deliverable Intake

When this skill owns a new substantive user-facing artifact, before source gathering, analysis, modeling, or rendering load `../../references/deliverable-intake-policy.md` and perform its adaptive `request_user_input` preflight for materially unresolved preferences. For a debtor-side sale-path, restructuring-alternatives, board-recommendation, or recovery-advice memo with an unresolved surface, offer `Polished HTML restructuring memo (Recommended)`, `Excel recovery waterfall workbook`, and `Word memo (.docx)`. Default to polished standalone HTML when intake is not required or a non-interactive narrative run must apply a default. Select workbook-first output without a format question when the request is principally to build, calculate, or sensitize recoveries, claims waterfalls, or value-break scenarios. When invoked as a downstream support step within an already scoped workflow, inherit resolved preferences and do not re-prompt.
## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the standalone HTML restructuring memo, banker-facing recovery workbook, requested native document, or clear first-read package.

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. The normal hero deliverable for debtor-side sale-path, restructuring-alternatives, or board-recommendation analysis is a polished standalone HTML restructuring memo. For model-heavy recovery waterfall, claims allocation, or value-break sensitivity work, use the workbook as the hero deliverable and a concise standalone HTML explanation only when useful. CSV, JSON, Markdown, run logs, manifests, model-citation ledgers, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable and meaningful companion deliverables; do not link to manifests, renderer contracts, audit payloads, or handoff files in ordinary delivery responses.

## Standard

Operate like a senior restructuring investment banker preparing MD/partner-level advice. Do not merely allocate value down a stack. Identify who is impaired, where value breaks, which constituency is fulcrum, who has leverage, which restructuring alternatives are executable, what diligence gaps matter, and what the client should do next.

Always separate:
- sourced facts, calculated outputs, user-provided assumptions, market-derived assumptions, and unsourced assumptions.
- strict legal-entitlement economics from negotiated plan economics.
- enterprise-value waterfalls from collateral/liquidation waterfalls.
- banker judgment from items requiring counsel, tax, valuation, or industry specialist review.

Do not provide definitive legal advice. Flag legal interpretation points for counsel review.

## Context routing

Start by inferring the working mode from the prompt and available materials:

1. No-context mode: if the user provides only a company name or broad request, do not fabricate the debt stack. Provide an intake checklist, model skeleton, and what can be done with public data.
2. Partial-context mode: if the user provides claims, debt, EBITDA, EV, or a model but not documents, build an illustrative waterfall and label all priority, lien, collateral, claim-size, and legal assumptions.
3. Full-data-room mode: if documents, models, VDR exports, or filings are available, extract the capital structure, claims, legal-entity map, collateral pools, valuation cases, and source tie-outs.
4. Existing-model mode: if the user provides an Excel workbook, preserve it. Do not overwrite tabs, formulas, names, or assumptions unless specifically requested. Create copies, output tabs, audit logs, and change notes.
5. Fast-turn mode: if the user explicitly needs quick meeting prep or time-boxed triage, produce a concise value-break read, three-case recovery table, diligence gaps, and senior questions; otherwise default to the full recovery analysis.
6. Advocacy mode: if the user represents a specific stakeholder, adapt the analysis to that constituency while still making economics and assumptions transparent.

If the user does not state the role, infer if possible from context. Otherwise state the assumed perspective, such as debtor-side, first-lien creditor, second-lien creditor, unsecured noteholder, sponsor, buyer, board, or internal banking team.

## Deliverable Modes

Choose the artifact mode independently from the analysis type:

- `restructuring_memo`: debtor-side sale path, board recommendation, stakeholder advice, or restructuring-alternatives analysis; default hero deliverable is a polished standalone HTML memo.
- `recovery_workbook`: calculation-heavy claims waterfall, recovery range, value-break, collateral pool, or sensitivity analysis; default hero deliverable is an XLSX workbook, with a standalone HTML companion only when it improves decision communication.
- `screening_note`: preliminary public-source or thin-context read without enough evidence for a board recommendation or supportable recovery model; use HTML or chat according to scope, with missing inputs made explicit.

A narrative restructuring memo is not a request for a dashboard. Do not route ordinary debtor-side recovery or sale-path HTML analysis through `dashboard-builder`. For a substantive `restructuring_memo`, do not return a completed inline Markdown memo when HTML is selected or defaulted; create and visually inspect the `.html` artifact and use chat as a concise cover note.

## Source hierarchy

Prefer sources in this order:

1. User-provided documents, workbooks, prompts, and uploaded data.
2. Callable connected routes or user-provided exports, such as drive, email, slack, internal document systems, financial-data connectors, market-data connectors, or deal-room exports.
3. Company filings, bankruptcy docket materials, court filings, indentures, credit agreements, prospectuses, press releases, investor presentations, and ratings reports.
4. Market data such as loan or bond prices, CDS, equity trading, comps, precedent transactions, DIP/exit financing terms, and recent restructuring precedents.
5. Web search as fallback for public, recent, or missing information.
6. User-confirmed assumptions when no reliable source is available.

Use `references/source-hierarchy.md` for source labels, stale-data checks, and citation discipline.

## Core workflow

Use this sequence unless the user explicitly asks for a narrower deliverable:

1. Frame mandate and client posture.
2. Build legal-entity, obligor, guarantor, and collateral map.
3. Build claims register, including funded debt and non-funded claims.
4. Normalize debt stack by true economic priority, not just labels.
5. Determine collateral coverage, structural subordination, and intercreditor constraints.
6. Build valuation framework: reorganization value, sale value, collateral value, and liquidation value.
7. Construct recovery waterfalls across low/base/high and restructuring alternatives.
8. Identify value break and fulcrum security by scenario.
9. Compare restructuring alternatives: amend-and-extend, exchange, LME, equitization, prepack, pre-arranged filing, freefall, 363 sale, credit bid, liquidation, or enforcement.
10. Analyze stakeholder leverage, plan feasibility, voting dynamics, and new-money needs.
11. Pressure-test assumptions and reconcile market prices to model recoveries.
12. Provide recommendation, negotiation posture, diligence gaps, and next-step workplan.

Load `references/workflow.md` for detailed procedural guidance.

## Output Depth

Default to `extended_analysis`: full capital structure, claims register, value bridge, recovery waterfall, fulcrum analysis, alternatives comparison, stakeholder leverage map, diligence gaps, and recommendation wherever the context supports it. Use quick-read or fast-turn formats only when the user explicitly asks for brevity, the task is live meeting prep, or source context is too thin for a full waterfall without false precision. Read `../../references/output-depth-policy.md` before shortening.

## Required analytical outputs

Every substantive response should include as many of these as the context supports:

- Executive conclusion: where value breaks, fulcrum class, recoveries, best path, and largest risks.
- Capital structure table: instrument, issuer/borrower, guarantors, collateral, lien, priority, claim amount, maturity, coupon, trading price, notes.
- Claims register: funded debt, DIP/admin, priority, trade, leases, litigation, pension, tax, professional fees, intercompany, contingent, disputed, and equity interests.
- Value bridge: enterprise value to distributable value, including cash, debt-like claims, fees, wind-down costs, new money, and required liquidity.
- Recovery waterfall: low/base/high and, when relevant, liquidation, sale, plan, and LME-adjusted cases.
- Fulcrum analysis: value-break class, sensitivity, trading-price comparison, practical control constituency, and possible fulcrum shifts.
- Alternatives comparison: economics, feasibility, timing, support needs, litigation risk, and recommendation.
- Stakeholder leverage map: economic, legal, voting, liquidity, operational, and process leverage.
- Diligence gaps: source documents required, counsel-review points, valuation issues, model gaps, and market checks.
- Recommendation: action-oriented view appropriate for a senior client conversation.

Use `references/output-templates.md` for quick-read, memo, model, board, and creditor formats.

For a debtor-side sale-path or board-recommendation memo, surface the decision gates early: what the stalking-horse transaction proves and does not prove, how DIP and administrative leakage changes distributable value, where value may break, and what information is required before the board can rely on a recommendation. If claims, collateral pools, payoff amounts, sale-process evidence, or current docket status are incomplete, frame recovery metrics as illustrative sensitivity rather than distributable recovery.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: claims/legal priority, valuation, collateral/liquidation, market checks, and restructuring alternatives. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Workbook and model behavior

When creating or editing spreadsheets:

- Preserve user work. Never delete, overwrite, or flatten data unless the user specifically asks.
- Make the first visible tab a banker-readable `Cover`, `Executive Summary`, or `Dashboard` tab following `../../references/workbook-first-tab-standard.md`, with liquidity, maturity wall, leverage/coverage, covenant headroom, recovery, fulcrum, path risk, and next steps.
- Add new tabs rather than changing original tabs when possible.
- Keep formulas intact and make calculation logic auditable.
- Use clear input/calculation/output/check sections.
- Add source notes and assumption labels.
- Include scenario and sensitivity support.
- Include QA checks that prove allocated value ties to distributable value.
- Make recoveries ranges when assumptions are uncertain.
- For complex spreadsheet creation or modification, also follow the spreadsheet/modeling skill available in the environment.

Use `references/model-architecture.md` for recommended workbook tabs and formula logic.

## Mechanical calculation helper

For a first-pass simple waterfall or QA cross-check, use `scripts/waterfall_engine.py` with a JSON input. This script only performs a mechanical priority waterfall and is not a substitute for legal, collateral, intercreditor, or plan analysis. See `references/script-waterfall-engine.md` before use.

Do not use the script when collateral pools, deficiency claims, guarantee limitations, or negotiated plan economics are material unless you explicitly adapt the input and explain limitations.

## Senior judgment rules

Always apply these MD-level rules:

- Treat the fulcrum as a negotiation and control question, not just a math output.
- Challenge management projections, valuation multiples, normalized EBITDA, capex, working capital, and exit financing capacity.
- Reconcile model recoveries to trading prices and explain why they differ.
- Separate liquidation floor from reorganization value.
- Show how value break moves under realistic downside cases.
- Identify whether out-of-money classes still have litigation, voting, or nuisance leverage.
- Identify whether money-good classes still have process leverage due to timing, cash interest, default interest, collateral, or consent rights.
- Include new-money dilution, backstop fees, MIP dilution, warrants, and exit financing where relevant.
- Flag absolute-priority, fair-and-equitable, secured-claim, make-whole, default-interest, and intercreditor issues for counsel review.
- Do not imply that a plan is executable just because the waterfall balances.
- Do not present gross purchase-price components, credit bids, or known-funded-debt-only recovery thresholds as distributable recovery without the required net-proceeds, priority-claims, collateral, and allowed-claims support.

## Coordination with other finance skills

Use or defer to related skills when their job is primary:

- `financial-source-of-truth`: source hierarchy, citations, stale-data checks, and assumption labels.
- `financials-normalizer`: normalize statements, filings, PDFs, VDR exports, and KPIs.
- `excel-data-cleaner`: clean raw spreadsheet inputs before modeling.
- `model-audit-tieout`: audit existing models, formulas, signs, links, and source tie-outs.
- `scenario-sensitivity-generator`: build sensitivities, breakevens, downside cases, and stress tests.
- `comps-valuation`, and `dcf-model-builder`: prepare comps, DCF, and valuation support.
- `private-credit-underwriting`, `covenant-package-analyzer`, `lbo-model-build`, and `capital-markets-issuance`: analyze refinancing capacity, leverage, coverage, covenant constraints, and market structure.
- `buyer-investor-list`: identify DIP lenders, rescue capital providers, stalking horse buyers, strategic buyers, or distressed investors.
- `memo-builder`, `pitch-deck-builder`, and `ib-deck-qc`: convert the analysis into circulation materials. Use the canonical `distressed_recovery_waterfall_to_memo_builder`, `distressed_recovery_waterfall_to_pitch_deck_builder`, and `distressed_recovery_waterfall_to_ib_deck_qc` contracts in `../../references/handoff-contracts.md`.

When consuming private-credit watchlist, amendment, default, or recovery context, use `private_credit_underwriting_to_distressed_recovery_waterfall` from `../../references/handoff-contracts.md`. Preserve legal-entitlement economics, negotiated plan economics, collateral/liquidation waterfalls, enterprise-value waterfalls, and counsel-review flags as separate fields.

## Reference map

- `references/source-hierarchy.md`: evidence rules, data-source priority, stale-data checks, and labels.
- `references/workflow.md`: step-by-step distressed recovery process and adaptive modes.
- `references/claims-priority-collateral.md`: claim taxonomy, priority, collateral, guarantor, lien, and intercreditor issues.
- `references/valuation-liquidation.md`: reorganization value, sale value, liquidation value, and sensitivity design.
- `references/restructuring-alternatives.md`: alternatives analysis and stakeholder leverage.
- `references/model-architecture.md`: workbook structure, model logic, outputs, and checks.
- `references/output-templates.md`: default response, memo, board, creditor, and quick-read templates when shortening is justified.
- `references/qa-checklist.md`: MD review checklist, red flags, and failure modes.
- `references/script-waterfall-engine.md`: mechanical script schema and limitations.
- `../../references/output-depth-policy.md`: read when deciding whether a quick-read waterfall is justified; default to `extended_analysis`.
## Validated Handoffs

Producer contracts:
- `distressed_recovery_waterfall_to_memo_builder` -> `memo-builder`. Schema: `../../schemas/distressed_recovery_waterfall_to_memo_builder.schema.json`. Validate with `../../scripts/validate_handoff_payload.py distressed_recovery_waterfall_to_memo_builder handoffs/distressed_recovery_waterfall_to_memo_builder.json` before another skill imports it.
- `distressed_recovery_waterfall_to_pitch_deck_builder` -> `pitch-deck-builder`. Schema: `../../schemas/distressed_recovery_waterfall_to_pitch_deck_builder.schema.json`. Validate with `../../scripts/validate_handoff_payload.py distressed_recovery_waterfall_to_pitch_deck_builder handoffs/distressed_recovery_waterfall_to_pitch_deck_builder.json` before another skill imports it.
- `distressed_recovery_waterfall_to_ib_deck_qc` -> `ib-deck-qc`. Schema: `../../schemas/distressed_recovery_waterfall_to_ib_deck_qc.schema.json`. Validate with `../../scripts/validate_handoff_payload.py distressed_recovery_waterfall_to_ib_deck_qc handoffs/distressed_recovery_waterfall_to_ib_deck_qc.json` before another skill imports it.

Intake validation:
- From `private-credit-underwriting`: require `private_credit_underwriting_to_distressed_recovery_waterfall` and run `../../scripts/validate_handoff_payload.py private_credit_underwriting_to_distressed_recovery_waterfall handoffs/private_credit_underwriting_to_distressed_recovery_waterfall.json` before importing fields into this skill.

## Standalone HTML Path

When HTML is selected or defaulted for a restructuring memo, produce a polished standalone HTML document following `../../references/html-artifact-standard.md`. This skill owns the restructuring judgment, memo hierarchy, citation placement, and board-readiness caveats. Do not create a dashboard render contract, generic dashboard navigation, reader-action bars, table-export controls, or related-files module for ordinary recovery or sale-path analysis.

For a debtor-side board or sale-path memo, a useful first-read hierarchy is:

1. recommendation and decision posture;
2. what the proposed sale path establishes and what remains unproven;
3. DIP, administrative, cure, and transaction-cost gates to recoveries;
4. value break and recovery sensitivity, clearly labeled as illustrative where evidence is incomplete;
5. process alternatives and stakeholder implications;
6. information required before a board recommendation;
7. sources, assumptions, counsel flags, and posture conclusion.

## HTML Evidence Readiness

For senior, client, committee, board, lender, or external postures, every material number, estimate, date-sensitive fact, sourced claim, assumption, and recommendation must have readable point-of-use citation support. Model-derived claims shown in the memo should identify the workbook sheet/cell or range where available. Unknown source identifiers, uncited material figures, missing source registers, or unsupported recovery/board-readiness conclusions are blocking gaps: fix them, downgrade the posture, or present them as explicit diligence requirements.

For reader-facing HTML:

- use plain restructuring language such as `Executed DIP agreement`, `Filed sale agreement`, `Analyst calculation`, `Illustrative sensitivity`, or `Not yet supported`, retaining internal evidence codes only in support data or when requested;
- avoid citation badges that dominate the conclusion or fragment dates and figures; make material claims traceable without turning the memo into an audit interface;
- label recovery percentages based only on known funded unsecured debt as upper-bound sensitivity before unquantified allowed-claim dilution;
- render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. For debtor-side sale-path, restructuring-alternatives, or board-recommendation analysis, the hero deliverable is normally the polished standalone HTML memo. For recovery modeling, waterfall computation, or value-break sensitivity work, use the workbook as hero and a standalone HTML summary only when useful. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, render contracts, model-citation ledgers, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then any meaningful companion. Mention support artifacts only when requested or useful for an immediate next step.

## Runtime Artifact Path

Default deterministic engine output is `recovery_waterfall.xlsx` with `Cover` first, plus `manifest.json` and `model_citations.json` as internal support. The engine does not generate a dashboard or render contract by default. Legacy Markdown, raw waterfall JSON/CSV, citation ledgers, manifests, and handoff payloads are support artifacts unless explicitly requested. Senior-ready status requires legal-entitlement separation, plan economics, collateral/liquidation support, counsel review flags, source-backed claims hierarchy, and workbook/cell provenance for recovery outputs.

Referenced files: 11

financials-normalizer19.9 KB

View saved version →

---
name: financials-normalizer
description: convert messy deal financials into model-ready statements, kpi schedules, source maps, and qa flags. use when an ib workflow needs spreading, normalization, or reconciliation. do not use for generic spreadsheet cleanup; use excel-data-cleaner.
---

# Financials Normalizer

## Skill Configuration

### Common Skill Instructions

### Source Resolution

## Relevant Dependency Categories

- `Models, Workbooks & Templates`
- `Deal Materials`
- `Market Data & Public Sources`

## Deliverable Intake

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing workbook or an explicitly requested standalone HTML normalization summary, native deck/document, or clear first-read package.

## Purpose
Turn messy source financials into auditable, model-ready normalized financial statements, KPI schedules, mappings, source citations, assumptions, conflicts, and QA flags for downstream finance skills.

This is a shared-core skill. Use it before valuation, LBO, transaction modeling, credit underwriting, memo, and deck workflows whenever the source financials are raw, fragmented, inconsistent, stale, or not tied out.

## Output Depth

Default to `extended_analysis`: produce or describe the full normalized package, source index, mapping logic, conflicts, assumptions, QA flags, source/evidence posture, and downstream readiness whenever financials will feed a model, memo, credit view, deck, or valuation. Use a shorter chat summary only when the user explicitly asks for it, the source context is too thin and the right answer is a source checklist/schema, or the main deliverable is already a workbook/package and chat is only a cover note. Read `../../references/output-depth-policy.md` before shortening.

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. For substantive normalization work, the normal hero deliverable is a polished banker-readable workbook with an insight-led first visible tab. Create a standalone HTML normalization summary only when the user explicitly requests HTML or a narrative companion; the workbook and supporting ledgers remain the normalized source of truth. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Non-negotiables
- Preserve source materials. Never delete, overwrite, hide, rename, or destructively transform raw tabs/files unless the user explicitly requests it.
- Prefer sources in this order: user-provided context/files, callable connected routes and internal-source exports, then public web sources for public-company or public-market data, then clearly labeled user/assistant assumptions.
- Never invent missing financials. Leave unavailable values blank or mark `missing_required_source`; explain what source is needed.
- Treat values as facts only when directly supported by evidence. Label derived values, standardized provider values, management adjustments, analyst adjustments, user assumptions, and inferred assumptions separately.
- Keep every normalized value traceable to `source_id`, `source_name`, `source_location`, `retrieved_at`, period, units, currency, and evidence label whenever available.
- If sources conflict, retain both values in `Conflict_Log`; do not silently choose one unless hierarchy and context make the decision clear.
- If freshness is uncertain, flag it. Clean stale data remains stale.
- If working in a workbook, write normalized outputs to new tabs or a new workbook and preserve raw/source tabs.

## Adaptive intake

### No context
1. Identify any target implied by the request: entity, ticker, borrower, portfolio company, business unit, period, statement type, or downstream use case.
2. Search callable connected routes or user-provided internal-source exports first when available.
3. For public companies, fall back to the latest primary filings, earnings releases, and company materials before secondary providers.
4. If the target or period is still unknown, ask for only the minimum blocking item. If the user wants a blank template, create the normalized schema and source checklist without values.

### Partial context
1. Use provided context as the working scope.
2. Fill non-blocking gaps from callable connected routes, user-provided exports, or public primary sources when appropriate.
3. Mark all filled values with source type, evidence label, confidence, and retrieval date.
4. Continue if missing information does not block normalization; otherwise ask only for the blocking source or assumption.

### Full context/files
1. Treat supplied files as the source package.
2. Build a source index before extraction.
3. Normalize into new outputs, never the raw materials.
4. Reconcile and QA before handing off to downstream skills.

## Workflow

### 1. Classify the normalization job
Classify the user’s context because the target schema and source hierarchy vary:
- **investment banking / private markets:** CIMs, VDR exports, QoE reports, management models, historical financials, revenue/KPI packs, debt, NWC, add-backs.
- **public markets:** filings, earnings releases, transcripts, investor decks, consensus, guidance, KPIs, segment data, share count, net debt.
- **private credit / lending:** borrower financials, collateral schedules, bank statements, EBITDA add-backs, covenant inputs, liquidity, debt schedule.
- **corporate finance / fp&a / accounting:** ERP/GL actuals, subledgers, planning exports, cost centers, departments, headcount, forecast versions, close status.

### 2. Build the source index
Create `Source_Index` before extracting values. Include: `source_id`, `source_name`, `source_type`, `owner_or_provider`, `period_covered`, `as_of_date`, `retrieved_at`, `file_tab_page_url_or_location`, `source_rank`, `freshness_status`, and `notes`.

Consult `references/source-protocol.md` for source hierarchy, stale-data thresholds, conflict handling, and citation format.

### 3. Extract to long-form staging
Extract values into `Normalized_Financials_Long` first, even if final statements are wide. Required columns:
`entity`, `source_id`, `statement`, `line_item_original`, `line_item_standard`, `line_item_id`, `period_end`, `period_label`, `period_type`, `currency`, `units`, `source_value`, `normalized_value`, `normalization_method`, `source_location`, `evidence_label`, `canonical_evidence_category`, `confidence`, `normalization_note`.

Consult `references/normalization-schema.md` and `references/line-item-taxonomy.md` for canonical statements, KPI schedules, sign conventions, and mapping rules.

### 4. Normalize periods, scale, currency, signs, and labels
- Periods: standardize to `YYYY-MM-DD` period-end dates and label annual, quarterly, monthly, LTM, YTD, forecast, budget, pro forma, or scenario.
- Units: preserve original units; normalize to the user’s requested unit or default to `$mm` for institutional finance outputs.
- Currency: preserve source currency unless conversion is requested or necessary; if converted, cite FX rate source and date.
- Signs: preserve `source_value`; use `normalized_value` and `normalization_method` to avoid losing source sign context.
- Labels: preserve exact source labels next to standardized labels.
- Adjustments: keep reported, adjusted, pro forma, management-adjusted, analyst-adjusted, provider-standardized, and estimated values separate.

### 5. Reconcile and QA
Run the QA rules in `references/qa-rules.md` before returning outputs. At minimum check:
- subtotal and roll-forward tie-outs
- balance sheet balance
- cash flow bridge where possible
- units/currency consistency
- duplicate periods and duplicate line items
- missing required sources
- stale or preliminary sources
- conflicting values across sources
- sign convention anomalies
- unsupported non-GAAP or KPI definitions

Use `scripts/normalize_extracted_financials.py` when extracted financial rows are available as CSV/JSON and deterministic unit, percent, bps, evidence, and companion-log handling would help. Use `scripts/validate_normalized_financials.py` when a normalized CSV exists and deterministic schema checks would help; add `--require-package` when validating the full output package. For workbook inputs, first extract the relevant tab/range with spreadsheet tools into a table or CSV; do not let scripts destructively modify workbooks.

### 6. Produce the normalized package
Default spreadsheet/workbook outputs:
1. `Executive_Summary` or `Cover` first-read tab
2. `Source_Index`
3. `Normalized_Financials_Long`
4. `Normalized_IS`
5. `Normalized_BS`
6. `Normalized_CF`
7. `KPI_Schedule`
8. `Adjustments_Log`
9. `Conflict_Log`
10. `Assumptions_Register`
11. `QA_Flags`
12. `Mapping_Dictionary`
13. `Checks`

For financing, leverage, or take-private use cases, also create readable decision-facing `EBITDA_Treatment_Matrix` and `Net_Debt_Treatment_Matrix` views, whether as named tabs or clearly bounded sections on the first-read/bridge tabs. These are review surfaces; `Normalized_Financials_Long`, source maps, and complete logs remain audit ledgers and need not function as presentation tabs.

The first visible tab must state the decision question, period and units, source posture, material normalized outputs, highest-priority open diligence items, and downstream readiness. In financing use cases, label a forecast denominator as `Management-Projected EBITDA` rather than accepted EBITDA, label committed financing as context only unless opening capitalization is established, and show separate `Reported statement integrity`, `EBITDA readiness`, `Net debt readiness`, and `Financing model handoff` statuses. Preserve those qualifiers in headline KPI strips and summary tables; use labels such as `Management-Projected FY2025E Adj. EBITDA` and `Committed Buyer Debt (Context Only)` rather than abbreviations that could imply accepted financing metrics or opening net debt.

Render and visually inspect the first-read tab, material treatment matrices or bridge tabs, normalized statements, and checks tab before delivery. Keep decision-facing tabs legible at normal zoom with wrapped text and bounded column widths. Detailed source, mapping, adjustment, conflict, and long-form staging ledgers may be compact audit tabs, but do not treat an unreadable full-sheet ledger render as reader-facing polish.

For chat-only tasks, still default to an extended normalization readout with the most material normalized tables, QA findings, conflict/assumption treatment, source posture, and downstream readiness. If evidence is insufficient, return a source request checklist, proposed schema, known context, missing-data table, and recommended next action.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: source extraction, line-item mapping, conflict resolution, reconciliation, and downstream-readiness QA. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Evidence labels
Use these exact native labels in `financials-normalizer` outputs. Preserve them exactly in `evidence_label` even when a downstream skill also needs a shared/canonical evidence category. For downstream handoffs, map them through `references/evidence-label-crosswalk.md` and the shared taxonomy at `../../references/evidence-label-taxonomy.md` when that shared file is available.
- `fact_source_reported`: directly sourced from a primary source or connected system.
- `fact_provider_standardized`: sourced from a trusted provider-standardized dataset.
- `derived_calculation`: calculated from sourced inputs.
- `management_adjusted`: company or management-defined adjusted metric.
- `analyst_adjusted`: user/assistant normalized or adjusted value.
- `assumption_user_provided`: assumption supplied by the user.
- `assumption_inferred`: inferred from context; disclose and use low confidence unless confirmed.
- `estimate_consensus`: consensus, Street estimate, or provider forecast.
- `missing_required_source`: required value unavailable.

When handing normalized data to another skill, include both:
- `evidence_label`: the exact native label above.
- `canonical_evidence_category`: the mapped shared-taxonomy category from `references/evidence-label-crosswalk.md`.

Do not overwrite native labels to fit another skill's accepted labels. If a downstream validator only accepts canonical categories, add a companion field or handoff note rather than mutating the normalizer output.

## Confidence labels
Use `high`, `medium`, or `low`:
- `high`: primary source or connected system; current period; clear label, units, and period.
- `medium`: credible secondary/provider source or clear source with minor mapping ambiguity.
- `low`: inferred mapping, stale/preliminary source, unclear period/units, OCR-heavy extraction, or source conflict.

## Downstream handoffs
- Use `financial-source-of-truth` when available for enterprise source routing, access controls, hierarchy, and citation discipline.
- Use `excel-data-cleaner` first when the spreadsheet layout itself blocks extraction: broken headers, merged cells, multi-table tabs, blank rows, malformed dates, or export artifacts.
- Use `model-audit-tieout` after normalized data is inserted into an existing or generated model.
- Use `scenario-sensitivity-generator` only after a clean base case exists.
- Hand off to `memo-builder`, `private-credit-underwriting`, `covenant-package-analyzer`, `comps-valuation`, `dcf-model-builder`, `lbo-model-build`, `merger-model-builder`, `three-statement-model-builder`, `pitch-deck-builder`, or `ib-deck-qc` only after material QA flags are disclosed.

Consult `references/integration-guide.md` for plugin-specific handoffs.

## Final response format
When returning results, use:
1. **What I normalized**: entity, sources, periods, units, currency, scope.
2. **Outputs created**: tables/tabs/files produced.
3. **Material QA findings**: tie-out breaks, stale data, missing values, conflicts, sign/unit issues.
4. **Fact vs assumption summary**: what is source-reported, derived, adjusted, estimated, or assumed.
5. **Recommended next step**: downstream skill or missing source needed.

Keep the response finance-grade and practical. Do not bury the user in generic accounting explanations.

## References
- `references/source-protocol.md`: evidence hierarchy, stale-data checks, citations, source conflicts, and assumption/fact labels.
- `references/normalization-schema.md`: canonical output schema, periods, signs, scales, and evidence labels.
- `references/evidence-label-crosswalk.md`: native-to-shared evidence taxonomy mapping and downstream handoff contract.
- `../../references/evidence-label-taxonomy.md`: shared evidence-label taxonomy when available; use it as the canonical target while preserving this skill's native labels.
- `references/line-item-taxonomy.md`: starter financial statement and KPI mapping rules.
- `references/qa-rules.md`: reconciliation tests, materiality thresholds, and red flags.
- `references/integration-guide.md`: how this skill composes with the other launch skills.
- `../../references/output-depth-policy.md`: read when deciding whether a concise normalization summary is justified; default to `extended_analysis`.
- `../../references/workbook-first-tab-standard.md`: required first-read workbook decision view.
- `../../references/html-artifact-standard.md`: optional standalone HTML companion and visual QA standard.

## Workbook Evidence Readiness

The workbook is the primary human deliverable and the normalized ledgers are its evidence layer. For senior, client, committee, board, lender, or external postures, every material reported amount, disclosed adjustment, derived metric, proposed EBITDA treatment, proposed net-debt treatment, and readiness conclusion must be traceable to readable source notes and the underlying ledger record or workbook cell/range where available.

Unknown source IDs, unlocated material values, unsupported add-back or debt-perimeter treatments, missing definition support, or unresolved blocker flags are blocking readiness gaps. Fix them, cap the posture at preliminary/partial, or surface them explicitly; do not call normalized outputs financing-model-ready, lender-ready, senior-ready, or external-ready while they remain.

For financing use cases, disclosed adjustments remain separate from accepted EBITDA treatment and debt-like/cash-like candidates remain separate from accepted net debt treatment until the required definition or diligence support is available. A reported statement tie-out may be `OK` while EBITDA readiness, net debt readiness, or financing model handoff remains `PARTIAL`, `OPEN`, or `BLOCKED`.

## Optional HTML Companion

When the user explicitly requests an HTML report or visual normalization summary, keep this skill as the analytical owner and produce a polished standalone HTML companion following `../../references/html-artifact-standard.md`. Do not route an ordinary normalization package through `dashboard-builder`, create a dashboard render contract, or substitute a visual wrapper for the model-ready workbook and audit ledgers.

In that HTML companion, keep reported facts, management-adjusted metrics, analyst treatment decisions, and readiness limitations visibly distinct. Render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery. Do not expose raw JSON, Markdown files, or full audit ledgers as the default final artifact.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: normally the XLSX normalization workbook; an explicitly requested standalone HTML normalization summary; native deck/document; generated folder; or justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, audit-ledger CSVs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

Referenced files: 12

ib-deck-qc19.5 KB

View saved version →

---
name: ib-deck-qc
description: quality-control investment-banking decks and reports before circulation. use when the user asks to check numbers, units, sources, charts, footnotes, formatting, or page takeaways. do not use to build the deck from scratch.
---

# IB Deck QC

## Skill Configuration

### Common Skill Instructions

## Relevant Dependency Categories

- `Deal Materials`
- `Models, Workbooks & Templates`
- `Market Data & Public Sources`
- `Process Updates`

## Deliverable Intake

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing workbook, HTML report/dashboard, native deck/document, or clear first-read package.

## Purpose

Use this skill as the banker/client-circulation gate for Investment Banking deliverables. The default job is to identify issues, prioritize fixes, and produce a polished standalone HTML QC report, annotated native deck workflow, or native-deck remediation path for pitch books, CIMs, teasers, valuation decks, financing decks, strategic alternatives materials, process materials, and committee readouts. Do not rewrite, rebuild, or redesign the deliverable unless the user explicitly asks for remediation.

This skill replaces the generic deck/report review dependency inside the Investment Banking plugin. Route final IB materials here, not to a generic deck/report review skill.

## Banker circulation ownership

This skill owns the final IB circulation decision:
- whether a deck, CIM, teaser, buyer list, financing pitch, valuation deck, or process material is ready for analyst fixes, VP/director review, MD review, client circulation, buyer/lender circulation, or is not circulable;
- whether numbers, units, dates, footnotes, sources, page titles, charts, and narrative claims tie across the deck, model, source files, and supporting materials;
- whether valuation, financing, leverage, covenant, returns, accretion/dilution, buyer rationale, process, and market pages carry the caveats needed for banker/client use;
- whether the page-level "so what" is clear enough for a banker to present without re-explaining the analysis.

Preserve the strongest generic QC controls: repeated-number tie-outs, source and footnote coverage, visual review, chart-to-narrative consistency, issue taxonomy, remediation sequence, posture labels, and explicit missing-support-file flags.

## Operating principles

1. Treat every number, unit, footnote, chart, and conclusion as something that must tie to an identified source or model output.
2. Separate deterministic findings from judgment calls. Mark uncertain items as `needs_review` rather than overclaiming.
3. Prioritize issues by decision impact. A mismatched EBITDA value, leverage multiple, covenant headroom, IRR, or valuation range is more important than minor formatting polish.
4. Preserve the original artifact. QC should create an issue log and suggested fixes first; edit only when asked.
5. Apply `financial-source-of-truth` standards for source hierarchy, stale-data checks, citation format, source conflicts, and fact/assumption labels.
6. Route model-level issues to `model-audit-tieout` and data-shaping issues to `excel-data-cleaner` instead of trying to solve them inside this skill.

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. For an ordinary circulation-gate review with no requested native markup workflow, the hero deliverable is a polished standalone HTML QC report. A workbook, native deck/document, generated folder first-read file, or justified chat-only answer may be the hero only when the user's requested workflow calls for it. CSV issue ledgers, JSON, Markdown, run logs, manifests, handoff payloads, and render inputs are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Workflow

### 1. Classify the deliverable

Identify the file type and purpose:
- IB pitch book, CIM, teaser, board deck, investor presentation, fairness/valuation deck, strategic alternatives deck, financing pitch, capital markets deck, process update, buyer/investor list, lender presentation, or committee readout
- model output deck or report linked to DCF, comps, LBO, merger model, QoE, three-statement, private credit, covenant analysis, capital markets issuance, restructuring, or recovery analysis
- mixed pack with PPTX/PDF/DOCX/XLSX support files

If the user provides multiple files, identify the controlling artifact and the source artifacts. Example: deck is controlling output; model, evidence ledger, transcript, and CIM are supporting materials.

### 2. Extract first-pass text, numbers, and sources

For PPTX, DOCX, XLSX, CSV, TXT, or markdown files, run the bundled script when available:

```bash
python scripts/inspect_deck_report.py <file1> <file2> --outdir qc_out
```

Use the script output as a first-pass map only. It is not a substitute for visual review, chart inspection, model tie-out, or PDF rendering.

For PDFs, screenshots, image-heavy slides, or scanned materials, use PDF/rendering tools to inspect pages visually before finalizing QC. If charts are embedded as images, state that the underlying chart data could not be extracted unless the model/source file is provided.

### 3. Build the QC map

Create or infer:
- page/slide/section list
- main title and thesis by page
- all repeated metrics and key claims
- source footnotes and citation coverage
- chart titles, axes, units, legends, and cited data source
- model-output tables and valuation/returns ranges
- section-level narrative conclusions

Consult `references/qc-playbook.md` for QC categories and `references/extraction-and-tieout.md` for extraction and tie-out guidance.

### 4. Run issue checks

Check at minimum:
- repeated numbers: same metric, company, period, and unit should match unless there is a disclosed reason
- units: millions/billions, dollars/local currency, percentages/bps, turns, multiples, per-share, nominal/real, annualized/LTM/NTM should be explicit and consistent
- source footnotes: each data-heavy page should identify source, as-of date, period, and whether data is company, market, broker, management, seller, model, or internal estimate
- charts: chart title, axis units, legends, series labels, chart numbers, and narrative takeaway should agree
- narrative consistency: executive summary, page titles, subtitles, bullets, charts, and conclusion should not contradict each other
- formatting: titles, subtitles, page numbers, fonts, alignment, table formatting, footnote style, decimal precision, capitalization, and repeated labels should be consistent
- caveats: preliminary, unaudited, management-provided, seller-provided, model-derived, and assumption-led items should be labeled
- compliance hygiene: do not add legal disclaimers unless requested, but flag missing caveats/disclosures where the analysis relies on uncertain or restricted inputs

Consult `references/issue-taxonomy.md` for severity and issue-type definitions.

## Import Contracts

Use `../../references/handoff-contracts.md` as the canonical shared handoff layer. If native field names differ, require the upstream artifact to map them to the canonical fields before QC.

Expected imports:
- `cim_builder_to_ib_deck_qc` for CIMs, teasers, management presentations, lender presentations, and buyer-facing CIM sections.
- `pitch_deck_builder_to_ib_deck_qc` for pitch books, client discussion decks, strategic alternatives decks, financing decks, and slide-blueprint handoffs.
- `style_guide_adapter_style_profile` and `style_guide_adapter_change_log` when a style profile or restyle pass was used.
- `distressed_recovery_waterfall_to_ib_deck_qc` when the material includes restructuring, claims, lien priority, recoveries, value-break, fulcrum, or waterfall analysis.

Use these packages to seed the QC map. Treat missing `source_log`, `key_numbers_to_tie`, `claim_register`, or required style/restructuring tie-outs as high-severity issues for any external, board, committee, lender, or client-facing deliverable. Preserve the distinction between external-ready language and internal banker notes; flag any internal note that appears in client-facing pages.

If style support is metadata-only or `visual_review_status` is `not_performed`, `metadata_only`, or `blocked`, do not assign `client-ready`; assign a lower posture and list rendered visual review as an open item.

### 5. Decide the review posture

Assign one of these postures:
- `client-ready`: only immaterial polish items remain
- `senior-review-ready`: mostly ready, with limited open questions or judgement calls
- `needs-targeted-fixes`: specific corrections are required before circulation
- `not-circulable`: material numerical, source, chart, or narrative issues remain
- `blocked`: necessary source/model files are missing

### 6. Produce the QC output

Default output for substantial QC work is an `extended_analysis` polished standalone HTML QC report, or an annotated/native deck workflow when the user asks for edits or slide-native review. Include:
1. Executive QC verdict
2. Circulation posture
3. Top issues by severity
4. Issue log table
5. Repeated metric / number tie-out table
6. Source and footnote coverage table
7. Chart and narrative tie-out findings
8. Formatting/presentation polish findings
9. Recommended remediation sequence
10. Open questions / missing support files

Use quick red-flag review only when the user explicitly asks for red flags, top issues only, a fast scan, or a narrow follow-up against an existing full QC pack. Read `../../references/output-depth-policy.md` before shortening. Use `references/output-templates.md` for default templates.

## Standalone HTML Path

For an ordinary HTML circulation-gate review, produce a polished standalone HTML QC report following `../../references/html-artifact-standard.md`. This skill owns the report hierarchy, issue prioritization, evidence presentation, and remediation sequence. Do not route an ordinary circulation QC HTML report through `dashboard-builder`, create a dashboard render contract, or force findings into generic dashboard modules.

Make the report read like a compact banker redline memo:
- open with the circulation posture, decision consequence, and three to five issues that block the requested circulation audience;
- place the remediation owner or required support next to each blocker;
- keep missing inputs and what remains unverifiable prominent but concise;
- put the detailed issue register, number/source checks, visual findings, and lower-priority polish beneath the first-read blockers;
- where a confirmed critical/high finding is visible in a supplied deck or PDF, include a compact page excerpt, page thumbnail, or precise page-reference callout when it makes remediation easier to confirm.

Keep evidence readable. Use compact point-of-use citations at the material issue, table-row, or paragraph level and a clean source register; do not repeat citation chips on every clause or table cell. Do not add generic dashboard navigation, persistent reader-action bars, repeated posture cards, broad export controls, or visible internal support machinery merely because the output is HTML.

If the user asks for an owner tracker, tracked remediation cycle, or slide-native markup, provide the appropriate workbook or annotated/native-deck companion workflow while keeping the circulation judgment and issue evidence consistent.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: number/model tie-out, source/footnote review, chart/narrative review, formatting/style QC, and issue severity. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Severity rules

Use these severities:
- `critical`: could change investment decision, valuation, financing terms, IC/credit recommendation, market read, or client trust
- `high`: material inconsistency or missing support that must be fixed before circulation
- `medium`: localized inconsistency, unclear caveat, formatting issue, or missing source detail that should be fixed
- `low`: polish item that does not affect substance
- `needs_review`: possible issue that requires visual, model, source, or user confirmation

Never hide uncertainty. If a number may be wrong but cannot be proven wrong from available files, label it `needs_review` and ask for the model/source support.

## Investment Banking skill routing

Use `references/investment-banking-integrations.md` when deciding whether an issue belongs in this skill or should be routed to another Investment Banking skill.

Common routes:
- source hierarchy, stale data, citation standard, source conflict, fact/assumption labeling -> `financial-source-of-truth`
- workbook formula, model logic, sensitivity, scenario, source tie-out -> `model-audit-tieout`
- messy tabular data, duplicated rows, bad date/number formats -> `excel-data-cleaner`
- valuation or transaction model construction or repair -> `dcf-model-builder`, `comps-valuation`, `lbo-model-build`, `merger-model-builder`, or `three-statement-model-builder`
- seller claim diligence and evidence asks -> `cim-teardown` or `financials-normalizer`
- buyer/investor rationale -> `buyer-investor-list`
- CIM or teaser build/refresh -> `cim-builder`
- issuance or financing market advice -> `capital-markets-issuance`
- restructuring and recovery waterfall logic -> `distressed-recovery-waterfall`
- final committee or client synthesis -> `memo-builder`

## Final checks before responding

Before final output, verify:
- every critical/high issue has location, evidence, why it matters, and suggested fix
- every repeated metric table distinguishes exact mismatch from possible period/unit mismatch
- source gaps are not presented as factual errors unless a controlling source proves the issue
- formatting findings are separated from investment-substance findings
- the final posture matches the severity of remaining issues
- the response does not imply the deck/report is fully verified if charts, screenshots, PDFs, or source models were not inspectable
- any shortened QC response was explicitly requested or justified by `../../references/output-depth-policy.md`
## Validated Handoffs

Intake validation:
- From `cim-builder`: require `cim_builder_to_ib_deck_qc` and run `../../scripts/validate_handoff_payload.py cim_builder_to_ib_deck_qc handoffs/cim_builder_to_ib_deck_qc.json` before importing fields into this skill.
- From `pitch-deck-builder`: require `pitch_deck_builder_to_ib_deck_qc` and run `../../scripts/validate_handoff_payload.py pitch_deck_builder_to_ib_deck_qc handoffs/pitch_deck_builder_to_ib_deck_qc.json` before importing fields into this skill.
- From `distressed-recovery-waterfall`: require `distressed_recovery_waterfall_to_ib_deck_qc` and run `../../scripts/validate_handoff_payload.py distressed_recovery_waterfall_to_ib_deck_qc handoffs/distressed_recovery_waterfall_to_ib_deck_qc.json` before importing fields into this skill.
- From `style-guide-adapter`: require `style_guide_adapter_style_profile` and run `../../scripts/validate_handoff_payload.py style_guide_adapter_style_profile handoffs/style_guide_adapter_style_profile.json` before importing fields into this skill.
- From `style-guide-adapter`: require `style_guide_adapter_change_log` and run `../../scripts/validate_handoff_payload.py style_guide_adapter_change_log handoffs/style_guide_adapter_change_log.json` before importing fields into this skill.

## HTML Evidence Readiness

For senior, client, committee, board, lender, or external circulation postures, every material number, estimate, date-sensitive fact, sourced claim, assumption, and recommendation in the standalone HTML QC report must have readable point-of-use citation support. Model-derived findings should cite the workbook/sheet/cell or range where available.

Unknown sources, missing source registers, or uncited material numeric findings are blocking readiness gaps. Fix them, downgrade the posture, or surface the missing support as an explicit source gap; do not call the reviewed deliverable ready for the requested circulation audience while those gaps remain.

For a standalone HTML QC report:
- cite each critical/high issue close to the stated evidence and remediation requirement without duplicating citation chips in every cell;
- distinguish confirmed deck defects from unsupported assertions, missing support, and judgment items requiring review;
- render and visually inspect the controlling deck/document where layout matters, plus the generated local HTML through local headless-browser screenshots rather than the in-app Browser plugin;
- check the opening viewport and issue-register sections for hierarchy, table legibility, clipped content, excessive chrome, and citation noise before delivery.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: standalone HTML QC report, XLSX remediation tracker, native deck/document, generated folder, or justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, render inputs, or handoff payloads as the main user-facing output. Keep CSV issue logs as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

Referenced files: 7

investment-banking15.9 KB

View saved version →

---
name: investment-banking
description: Route Investment Banking workflows for banker-owned transaction, capital markets, valuation, diligence, buyer/investor targeting, pitch, process, and restructuring work. Use when the user is preparing, reviewing, or executing M&A, financing, sponsor, issuer, lender, restructuring, coverage, or deal-advisory work, including CIMs, teasers, pitch materials, buyer lists, process trackers, merger models, capital markets analysis, and banker-facing valuation or diligence outputs. Do not use for public-equity investment decisions, personal financial advice, legal advice, FP&A, or generic writing tasks with no transaction or banker-workflow context.
---

# Investment Banking Router

## Skill Purpose

Route broad or focused Investment Banking intent to one or more explicit-only constituent skills. Treat explicit `@investment-banking`, `@Investment Banking`, or direct plugin invocation as strong intent to use this plugin, then apply the invocation gate below before substantive work. When the gate passes, choose the narrowest relevant lead skill from the map below, read each exact installed `skills/<skill-id>/SKILL.md` file before using it, and preserve any support-skill sequence from the routing playbook. Prefer a relevant Investment Banking sibling when the request overlaps generic finance, valuation, document, deck, model, diligence, or transaction-advisory work. Do not answer from the router alone when a focused owner exists.

## Plugin Purpose

Investment Banking provides banker-readable workflows for M&A, coverage, sponsor and strategic alternatives, ECM/DCM/LevFin, restructuring, valuation, CIM/VDR/Datasite diligence, buyer and investor targeting, process execution, pitch materials, model work, committee materials, and deal-team QC. It uses workflow-scoped source setup: connect or request only the source categories a selected banker workflow actually needs, while supporting pasted context, uploaded files, exports, public evidence, and existing models as fallback inputs.

## Bundled Path Resolution

Resolve router-owned bundled Markdown paths relative to the directory containing this `SKILL.md` before the first read; do not probe the caller's current working directory. From this router directory, shared references use `../../references/...`, sibling visible skills use `../...`, and bundled internal support uses `internal-support/...`.

Shell commands explicitly labeled plugin-root-relative are the exception: set the shell working directory to the plugin root (`../..` from this router directory) before running them.

## Invocation Gate

Read `../../references/invocation-policy.md` before choosing any specialist.
If the prompt has neither an explicit Investment Banking invocation nor banker-owned transaction, valuation, diligence, pitch, process, capital markets, restructuring, coverage, sponsor, issuer, lender, or deal-advisory context, do not route into this plugin.

# Skills

## cim-teardown

Use when controlling deal materials, CIMs, teasers, management presentations, VDR/Datasite exports, seller claims, diligence documents, or source packets need teardown before a banker relies on them.

## cim-builder

Use when the user needs a banker-readable CIM, teaser, buyer-facing narrative, management-presentation story, or source-aware marketing-material draft.

## buyer-investor-list

Use for buyer, sponsor, lender, strategic acquirer, investor, counterparty, or outreach-wave universe work that needs ranked targets and relationship/context rationale.

## deal-process-tracker

Use when the main artifact is a tracker for VDR access, NDA status, bidder status, process milestones, deadlines, bid logs, diligence requests, or next actions.

## capital-markets-issuance

Use for ECM, DCM, LevFin, private placement, hybrid, convert, refinancing, liquidity, market-window, proceeds, dilution, or financing alternatives advice.

## private-credit-underwriting

Use for lender-facing or borrower credit underwriting, private credit conditions, downside case, collateral, debt capacity, and credit committee readiness.

## covenant-package-analyzer

Use for covenant definitions, baskets, leakage, amendment capacity, document constraints, covenant headroom, and debt-document diligence.

## distressed-recovery-waterfall

Use for distressed capital structures, recovery waterfall, fulcrum security, restructuring alternatives, creditor dynamics, and recovery-range work.

## financials-normalizer

Use for spreading, cleaning, and normalizing source financials into model-ready schedules, source-to-cell maps, or model input packs.

## company-tearsheet

Use for issuer, target, acquirer, sponsor-owned company, or counterparty factual profiles that feed banker analysis without becoming the final transaction view.

## comps-valuation

Use for trading comps, precedent transaction comps, valuation ranges, peer selection, outlier handling, and comps support tables.

## dcf-model-builder

Use for DCF valuation workbooks, assumption structures, terminal value, WACC, sensitivity tables, and valuation support.

## lbo-model-build

Use for sponsor buy-side LBO workbooks, sources and uses, returns cases, debt sizing, operating model integration, and exit sensitivity.

## merger-model-builder

Use for accretion/dilution, pro forma merger math, purchase accounting, synergy cases, exchange ratio, and merger-model workbooks.

## three-statement-model-builder

Use for integrated three-statement operating models, forecast architecture, formula-first workbook construction, and model checks.

## scenario-sensitivity-generator

Use for downside/base/upside cases, scenario overlays, sensitivities, target backsolves, trigger metrics, and decision-impact matrices.

## model-audit-tieout

Use for model review, formula/source tie-out, workbook integrity checks, model audit reports, and remediation recommendations.

## memo-builder

Use for board, deal committee, fairness support, transaction recommendation, IC-style, or banker synthesis memos that import analysis from owning skills.

## pitch-deck-builder

Use for pitch decks, board decks, committee decks, page plans, storyboards, and slide-level source-aware narrative packages.

## ib-deck-qc

Use for final deck/report QC, circulation readiness, source tie-out, consistency checks, model support, and banker-facing issue logs.

## meeting-prep

Use for banker meeting briefs, transaction meeting prep, diligence-call prep, management-meeting questions, buyer/sponsor/lender meeting plans, and follow-up question lists.

## user-context

Use only for explicit Investment Banking saved preferences, source setup, onboarding, recall, inspect, update, export, reset, or automation setup. Do not use as an ordinary workflow pre-answer gate.

## test-investment-banking-workflows

Use only when the user explicitly asks to test, evaluate, regression-check, or review Investment Banking plugin workflows.

## Cross-Skill Runtime Contract

Use this shared contract as the plugin's Cross-Skill Best Practices for ordinary Investment Banking workflows, whether this router or a focused skill was invoked first.

### Audience And Language

Users expect banker-readable work product, not plugin setup narration. Explain source limits, assumptions, readiness, and next steps in deal-team language. Avoid exposing internal terms such as `source_category_plan`, `preflight`, `configured_route`, or `next_action` in user-facing output unless the user asks for implementation details.

### Dependency And Source Categories

The configured apps and their semantic categories live in this plugin's `.app.json`. Treat `.app.json` as the dependency-category registry, not as proof that any source is installed, authorized, or readable for the current user. An app can satisfy a category when its `category` or `categories` field matches the attempted category label below.

Use these category labels and legacy ids interchangeably inside this plugin:

- `Deal Materials` / `deal_materials`: CIMs, teasers, VDR or Datasite exports, diligence documents, source packets, management materials, and other controlling deal documents.
- `Process Updates` / `process_updates`: trackers, meeting notes, emails, internal messages, status updates, bids, deadlines, action logs, and process history.
- `Relationship & Counterparty Context` / `relationship_counterparty_context`: buyer, investor, lender, sponsor, issuer, advisor, relationship, and counterparty context.
- `Market Data & Public Sources` / `market_data_public_sources`: public filings, ratings context, trading data, estimates, market data, transaction benchmarks, and public-source support.
- `Models, Workbooks & Templates` / `models_workbooks_templates`: existing models, workbook extracts, spreadsheet inputs, templates, source-to-cell maps, and model-ready schedules.

When resolving a dependency, identify only the categories needed for the selected workflow, prefer user-named sources first, then choose one available app, connector, file, export, or pasted input that can satisfy the category. Prefer canonical finance plugins or provider-specific helper guidance over raw connectors when they add workflow support. Use additional sources only when they materially improve evidence, confidence, recency, or the artifact's next action.

Do not silently substitute a weaker category for a stronger required one. If the needed category is unavailable, unauthorized, too slow, or returns no useful context, state the practical limitation, continue from user-provided or public context when a limited answer is still useful, and label the output posture accordingly. Stop only when the missing source owns a required input that cannot be supplied or reliably inferred.

Attempt connector reads only when the active workflow needs that source. Before saying a source is ready, use the smallest safe native read-only check for that run. A successful read is run-specific evidence, not durable setup state. Do not use browser automation, UI observation, screenshots, or mirrored adjacent sources as readiness proof.

### Provider And Helper Routing

Provider-specific guidance stays internal in this pass; do not expose provider guides as selectable skills. When a selected workflow needs provider call shaping, first choose the semantic source category, then confirm the concrete route is callable, then load `internal-support/policy.md` and only the matching internal guide.

- Use `internal-support/daloopa-provider-guide/INTERNAL.md` only for callable Daloopa routes that supply source-backed public-company financials, KPIs, or model-ready schedules. Keep prices, consensus, news, and non-Daloopa values separately labeled.
- Use `internal-support/quartr-provider-guide/INTERNAL.md` only for callable Quartr routes that supply filings, reports, earnings releases, presentations, transcripts, events, management commentary, or standardized actual financials. Prefer Quartr over web fallback for those document-backed facts when it is callable.
- For FactSet, LSEG, S&P, Moody's, PitchBook, Third Bridge, Google Drive, Gmail, Slack, or other configured apps without a bundled provider guide, follow the live tool surface, preserve provider/source provenance, and do not invent a helper skill or imply access that was not verified in the current run.
- If the preferred provider is unavailable, unauthorized, or missing the needed field, state the provider gap, request a specific export or user-supplied source when useful, and use an alternate route only with clear source labeling.

### User Context And Setup

Do not run `skills/user-context/scripts/user_context_preflight.py` during ordinary Investment Banking workflows. Saved preferences and source setup are optional accelerators, not a pre-answer gate.

Route explicit remember, save, update, forget, inspect, export, reset, source-setup, onboarding, or automation-setup requests for Investment Banking context to `../user-context/SKILL.md` relative to this router directory, equivalently `skills/user-context/SKILL.md` from the plugin root. That skill owns durable `user-context.md`, `onboarding-state.json`, explicit source setup, and optional automations.

### User Input Modalities

Ask only for choices that materially change the lead owner, first-read artifact, evidence path, reliance standard, or user action. Use `request_user_input` when available for bounded choices with strong defaults: send all material unresolved questions together, put the recommended option first with `(Recommended)`, and set `autoResolutionMs` so an unanswered picker resolves to the recommended option. If `request_user_input` is unavailable or errors, ask all known material questions together in the next normal response, with recommended/default options first for bounded choices, and wait for the user's answer. Use `request_plugin_install` when a material missing source category can be solved by installing or connecting an available plugin, connector, or app. For open-ended facts, unknown deal context, or cases with no useful option set, group every known missing question in one concise plain-text response rather than asking one by one.

### Default Workflow

1. Resolve dependencies and clarify only material ambiguity.
2. Gather the smallest useful context from the category that owns the core source of truth, then broaden only when the first pass is empty, thin, conflicting, stale, or decision-relevant.
3. Produce the first useful banker-facing output in the workflow's preferred artifact form. Default to the skill's documented hero artifact when the user asks for substantive work, and chat only for narrow or explicitly quick answers.
4. End with a short useful next step tied to the artifact, such as refining the output, adding a companion workbook/deck/memo, running QC, refreshing sources, or setting up an explicit saved preference or source connection.

## Plugin Workflow Routing

After the gate passes, read `../../references/plugin-routing-playbook.md` and select one lead skill for the workflow. Preserve its artifact hierarchy and load supporting skills only for the workstreams the lead skill assigns.

## Internal Support

Read `internal-support/policy.md` when the lead workflow needs evidence control, generic data cleaning, HTML rendering, style application, or provider-specific call shaping after selecting a callable connector route. These supporting capabilities are bundled internal playbooks rather than selectable skills. Keep standalone normalization and model-audit requests with the visible `financials-normalizer` and `model-audit-tieout` workflows. For an explicitly requested internal support-only task admitted to this plugin, this router coordinates the task through the matching internal playbook.

## Deliverable Intake

For a new substantive hero artifact, the lead owner reads `../../references/deliverable-intake-policy.md` before source gathering or analysis and collects only unresolved preferences. Supporting skills and renderers inherit confirmed choices and do not re-prompt.

If the lead workflow, first-read artifact, transaction role, source/control packet, or circulation posture remains materially ambiguous after reading the playbook, use the Material Ambiguity Choice Sets in `../../references/deliverable-intake-policy.md`. Do not ask merely because multiple skills could help; ask only when the answer changes the lead owner, hero artifact, evidence path, or reliance standard.

## Artifact Discipline

Follow `../../references/artifact-manifest-standard.md` for routed work.
Read `../../references/output-depth-policy.md` and `../../references/deliverable-format-policy.md` for depth and presentation defaults. Default to full-depth analysis unless the user explicitly asks for a shorter answer, and keep Markdown reports or raw JSON/CSV as support artifacts rather than default reader-facing deliverables. For a producing skill migrated to `../../references/html-artifact-standard.md`, let that skill own its polished standalone HTML structure directly; use internal dashboard rendering only for an unmigrated workflow that explicitly retains that path.
Final responses should lead with the hero deliverable and keep support files secondary unless the user explicitly requests them.

Referenced files: 53

lbo-model-build11.8 KB

View saved version →

---
name: lbo-model-build
description: Build sponsor LBO models for sources and uses, debt, sweep, liquidity, returns, and downside underwriting. Use for take-privates, acquisition financing, or leverage screens; not DCF-only work.
---

# LBO Model Build

## Skill Configuration

### Common Skill Instructions

## Relevant Dependency Categories

- `Deal Materials`
- `Models, Workbooks & Templates`
- `Market Data & Public Sources`
- `Relationship & Counterparty Context`

## Deliverable Intake

When this skill owns a new substantive user-facing artifact, before source gathering, analysis, modeling, or rendering load `../../references/deliverable-intake-policy.md` and perform its adaptive `request_user_input` preflight for materially unresolved preferences. For an initial sponsor LBO model, take-private screen, or acquisition-financing model with an unresolved surface, offer `Excel sponsor LBO workbook (Recommended)`, `Polished HTML underwriting summary`, and `Inline screening view`. Default to the banker-readable workbook when intake is not required or a non-interactive model-build run must apply a default. When invoked as a downstream support step within an already scoped workflow, inherit resolved preferences and do not re-prompt.
## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing workbook, an explicitly requested standalone HTML underwriting summary, native deck/document, or clear first-read package.

Use for sponsor underwriting, acquisition financing, take-private screens, carve-outs, debt capacity, covenant headroom, liquidity survival, reverse stress, and XLSX exports. Do not use for DCF-only work, pure explainers, legal covenant interpretation, independent workbook audit, or final deck QC.

Rules: identify the decision lens; use available context before asking; keep EBITDA bases separate; do not present covenant EBITDA without the governing definition; label material inputs as `sourced_fact`, `management_assumption`, `seller_claim`, `sponsor_assumption`, `lender_case`, `analog_proxy`, `fallback_assumption`, or `unsupported`; default to `deterministic_export`. When final funded debt, commitment papers, or closing funds flow is unavailable, call the modeled financing an `illustrative financing case` or `public-source screening case`, cap posture at `screen-grade`, and make financing uncertainty visible in the first-read view.

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. For substantive LBO work, the normal hero deliverable is a polished banker-readable workbook with an insight-led first visible tab. Create a standalone HTML underwriting summary only when the user explicitly requests HTML or a narrative companion; the workbook remains the model source of truth. CSV, JSON, Markdown, run logs, manifests, model-citation ledgers, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Workflow Modes

- `screening_model`: public-source take-private or acquisition-financing screen where final funded debt, closing funds flow, covenant definitions, or validated sponsor operating assumptions are unavailable. Use a workbook hero, label assumed financing prominently, and do not exceed `screen-grade`.
- `underwriting_model`: source-supported sponsor model with financing structure, operating case, cash sweep, returns, sensitivities, downside and controls. Use a workbook hero and apply readiness gates before any senior or committee characterization.
- `html_companion`: explicitly requested narrative executive view of workbook outputs. Keep the workbook as the calculation source of truth and create standalone HTML only as a companion or selected first-read narrative surface.

For public-source screening cases, do not limit sensitivities to operating realization and exit multiple when financing terms are assumed. A completed banker-readable workbook must include: an operating/exit-value returns sensitivity; a financing uncertainty view that varies opening debt or leverage and interest pricing and reports returns plus liquidity impact; and a revolver-capacity or incremental-equity-cure view when a stress case draws or exhausts assumed liquidity. A single integrated downside case may support, but may not replace, these financing sensitivity views.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: operating case, sources and uses, debt/sweep/covenants, returns, downside, and audit. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

Run from the skill directory:

```bash
python3 scripts/validate_plan.py output/plan.json
python3 scripts/run_pipeline.py output/plan.json --output-dir output --print-report
```

`scripts/*.py` are short executable maps. Runtime source lives in `scripts/runtime/`; full support assets live under `assets/deep/`; `assets/plan_template.json` is a compact runnable example.

Outputs go to the selected `--output-dir` (default `./output` from the caller's current working directory). Treat `model.xlsx` as the hero human deliverable, opening on a banker-readable `Cover`, `Executive Summary`, or `Dashboard` tab per `../../references/workbook-first-tab-standard.md`; treat `plan.json`, `run_log.json`, `model_citations.json`, and `manifest.json` as agent-facing support artifacts. `model_citations.json` maps material output ids to exact workbook cells/ranges for evidence and any narrative companion. Write legacy `report.md` only when explicitly requested with `--write-report-md`. Verify hard failures, S&U, debt roll-forward, revolver/min cash, covenants, exit equity, reverse stress, value bridge, stated hold-period return timing, and periodicity/annualization. If deterministic output fails a QA check and another workbook path is used, disclose that fallback in the first-read tab and the user-facing cover note rather than silently presenting a substituted output. End with `decision-grade`, `senior-review-ready`, `screen-grade`, `not-decision-ready`, or `blocked`.
## Validated Handoffs

## Workbook Evidence Readiness

The workbook is the analytical source of truth. For senior, client, committee, board, lender, or external postures, every material input and derived output must be traceable through readable source/assumption notes and `model_citations` / `model_citations_path` records down to workbook sheet/cell or range where available.

Unknown source IDs, missing cell provenance for headline returns or leverage outputs, unsupported financing inputs, absent closing sources-and-uses support, unresolved covenant definitions, or unreported QA fallback paths are blocking readiness gaps. Fix them, cap posture at `screen-grade`, or surface them explicitly; do not call a workbook decision-grade or senior/committee-ready while they remain.

The first visible tab must clearly distinguish `Calculation integrity` from `Decision readiness`; do not leave that distinction only on a later checks sheet. A model may balance and pass formula checks while still being only a public-source screen because financing, covenant, cash-conversion, management-dilution, or closing-balance-sheet evidence is missing.

Before delivery, visually inspect the first visible tab, returns view, sensitivities view and checks/readiness view. Repair the workbook before returning it if the first tab lacks both readiness labels, the financing sensitivity views above are missing from a public-source screen, or a hold period renders as a multiple such as `5.0x` rather than as years.

## Optional HTML Companion

When the user explicitly requests an HTML report or visual underwriting summary, keep this skill as the analytical owner and produce a polished standalone HTML companion following `../../references/html-artifact-standard.md`. Do not route an ordinary LBO HTML summary through `dashboard-builder`, create a dashboard render contract, or force sponsor return findings into fixed dashboard modules.

In that HTML companion, cite workbook-derived outputs to exact workbook cell/range records through `model_citations` or `model_citations_path` wherever available. Render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

Do not expose raw JSON, Markdown report files, model-citation ledgers, or run logs as the default final artifact.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: normally the XLSX sponsor LBO workbook; an explicitly requested standalone HTML underwriting summary; native deck/document; generated folder; or justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, model-citation ledgers, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Runtime Artifact Path

Default deterministic outputs are `model.xlsx`, `manifest.json`, `run_log.json`, and `model_citations.json`. The workbook is the primary human deliverable; support artifacts include plan, run log, model citation ledger, and any optional legacy report requested explicitly. Sponsor/committee-ready status requires full sources and uses, source-supported financing terms, debt schedule, returns, covenants, operating case, sensitivities, checks, periodicity/annualization QA, and workbook/cell provenance for every material model number reused in a memo or deck.

Referenced files: 44

meeting-prep18.5 KB

View saved version →

---
name: meeting-prep
description: prepare ib meeting briefs, question lists, and debrief follow-ups. use when the user asks for call prep, buyer or lender meeting materials, diligence questions, or action tracking. do not use for full memo drafting.
---

# Meeting Prep

## Skill Configuration

### Common Skill Instructions

### Source Resolution

Load `../../references/workflow-source-resolution.md`. Resolve only the catalogued source categories needed for the current meeting. Prefer a user-named source first, then one available app, connector, file, export, or pasted input that satisfies the category. Attempt the smallest useful native read only when the workflow needs that source. If a route needs auth, connection, or setup, state the practical limitation and continue from prompt context, active artifacts, pasted or exported material, and public sources when the meeting brief can still be useful. Do not inspect unrelated source categories, run broad source setup, write connector readiness, or create, read, migrate, or update `category-state.json`.

The runtime source categories below cover the catalogued Investment Banking sources. Use `references/context-and-sources.md` for the broader evidence hierarchy, including optional meeting-logistics connectors.

### Workflow Sources

When this skill uses a source category, use it for the following information. These are semantic source categories, not fixed connector names.

- `deal_materials`: VDR exports, diligence documents, process letters, and source materials needed for an active transaction or diligence meeting.
- `process_updates`: trackers, meeting notes, and internal updates needed for status, action, or debrief context.
- `relationship_counterparty_context`: relationship, buyer, lender, sponsor, and counterparty context when it changes the meeting plan.
- `market_data_public_sources`: public filings, market data, ratings, and transaction benchmarks only when they materially change the coverage angle or meeting questions.
- `models_workbooks_templates`: models, workbooks, and templates only when they materially change the meeting baseline, analysis, or follow-up.

## Relevant Dependency Categories

- `Process Updates`
- `Deal Materials`
- `Relationship & Counterparty Context`
- `Market Data & Public Sources`

## Deliverable Intake

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. The hero deliverable must be a polished standalone HTML meeting brief, workbook, native deck/document, generated folder first-read file, or justified chat-only answer. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing standalone HTML brief, workbook, native deck/document, or clear first-read package.

## Trigger Boundary

Use for IB meeting briefs, call prep, diligence questions, live-meeting talk tracks, debriefs, and follow-up/action tracking from any starting point: no context, partial context, calendar invite, deck, model, memo, transcript, data room, or research packet.

Role: make the user ready for the meeting: what to know, what to ask, what not to say, what evidence to request, what decisions to drive, and what follow-ups to send.

Non-role: do not draft a full memo, build models/decks/trackers, certify circulation readiness, or overwrite source artifacts. Route full memo drafting to `memo-builder`; route process tracking to `deal-process-tracker`; route final IB material review to `ib-deck-qc`.

## Output Depth

Default to `extended_analysis`: a full prep bundle with decision frame, facts vs assumptions, source caveats, prioritized questions, diligence asks, likely pushbacks, avoid-saying items, follow-ups, and open gaps. Use a one-page, starter, or live-call brief only when the user explicitly asks for brevity, the meeting is imminent/time-boxed, or available context is too thin for a full prep without false precision. Read `../../references/output-depth-policy.md` when deciding whether to shorten.

## Output Modes

Choose the meeting mode that best matches the purpose rather than treating every meeting as diligence:

- `coverage_meeting`: introductory or relationship-development meeting with a public or private-company client. Lead with relationship objective, informed coverage angle, mandate triggers, three to five questions to land, no more than two or three conditional follow-up prompts, internal guardrails, and one preferred permissioned next step. Use limited alternative next steps only when distinct mandate triggers warrant different follow-up work. Do not turn an introductory call into an exhaustive diligence questionnaire or process tracker.
- `transaction_or_diligence_meeting`: active process, lender, buyer, sponsor, management diligence, or decision-gate meeting. Include detailed question/evidence matrices, issues, decisions, owners, and follow-ups as required.
- `debrief_or_follow_up`: completed meeting. Capture confirmed facts, changed assumptions, commitments, process implications, and owned actions; create a tracker handoff only for concrete process events.
- `live_call_brief`: imminent/time-boxed meeting or explicitly concise request. Produce a short, usable call sheet and identify what remains unverified.

## Fast Workflow

1. Determine mode: build from scratch, refresh prep, turn analysis into call prep, prepare for a specific meeting, prepare follow-ups, or review/upgrade an existing packet.
2. Infer meeting type, audience, circulation mode, objective, decision needed, and likely agenda. Ask only for details that materially change the output.
3. Build the context pack from the prompt, active artifacts, connected apps, trusted internal sources, source financials/models/materials, and public sources only when needed.
4. Handle sparse context without stalling: produce a starter brief with assumptions and data asks; for conflicts, mark "verify before meeting."
5. Compose with the narrowest relevant finance skill when specialized analysis is needed; do not duplicate model, valuation, credit, covenant, deck, source-of-truth, or process-tracker work.
6. Create the brief in the selected mode: decision frame, verified facts vs assumptions, top questions, targeted evidence asks, likely pushbacks or listening signals, avoid-saying items, and follow-ups. In `coverage_meeting`, consolidate questions rather than repeating the same themes in multiple topic tables.
7. For completed meetings, produce a debrief with decisions, new facts, changed assumptions, diligence requests, commitments, owners, due dates, dependencies, and draft follow-up language when useful.
8. Apply non-destructive artifact rules and run the quality bar before finalizing.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: source pack, counterparty context, diligence questions, banker talking points, and follow-up tracker. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Artifact Contract

Default prep bundle: meeting objective, likely agenda, must-know context, recommended stance, facts vs assumptions, questions ordered by decision impact, evidence asks, likely pushbacks or listening signals, action tracker, source log, and open gaps.

Questions must be specific, decision-linked, and ordered. For important questions, include why it matters, what answer would change the analysis, what evidence would verify it, likely evasive answer/follow-up, or owner/source to verify after the call.

For `coverage_meeting`, the first-read brief should answer: why this meeting matters now, what strategic/financing angle is worth testing, which few questions earn a second conversation, what mandate trigger to listen for, what not to presume, and what permissioned next step to request. Keep deeper issue trees and supporting diligence questions secondary rather than presenting three long overlapping priority-question tables as the core meeting script. Limit secondary prompts to two or three conditional follow-ups tied to management signals surfaced during the meeting. Present one recommended next step; include no more than two alternatives only where different observed triggers would lead to different work.

Memo handoff: export `meeting_prep_to_memo_builder` from `../../references/handoff-contracts.md` when prep or debrief should become a memo. Validate against `../../schemas/meeting_prep_to_memo_builder.schema.json`.

Tracker handoff: export `meeting_prep_to_deal_process_tracker` from `../../references/handoff-contracts.md` only when a meeting creates a concrete process event. Validate against `../../schemas/meeting_prep_to_deal_process_tracker.schema.json`. General impressions must be labeled `qualitative_signal` and source-noted.

## Standalone HTML Path

When HTML is requested or selected, produce a polished standalone HTML meeting brief following `../../references/html-artifact-standard.md`. This skill owns the brief hierarchy, writing, and presentation. Do not route an ordinary meeting-prep HTML brief through `dashboard-builder`, create a dashboard render contract, or force the preparation into fixed dashboard modules.

For an introductory coverage or management meeting, use this first-read hierarchy:

1. Meeting objective and recommended posture: what relationship or mandate outcome the banker should seek, without implying an existing mandate or financing need.
2. Must-know snapshot: a compact set of sourced operating, capital-allocation, liquidity, or strategic facts that change the conversation.
3. Coverage angles and mandate triggers: growth priorities, M&A/build-versus-buy, capital-markets relevance, and the concrete management signal that would justify follow-up work.
4. Questions to land: one compact prioritized table, normally three to five core questions plus no more than two or three conditional follow-up prompts tied to management signals; do not repeat the same topic across multiple long tables.
5. Talk track, guardrails, and next step: a credible opening/close, internal-only do-not-say items, missing relationship/logistics context, and one recommended permissioned next step with no more than two trigger-specific alternatives when needed.
6. Evidence and limitations: readable point-of-use citations and a concise source register.

Keep public-source analysis, inferred banking opportunities, internal strategy, and management-confirmed interest visibly distinct. Avoid generic dashboard navigation, persistent action bars, visible renderer plumbing, or broad diligence registers that make a first meeting feel like an active transaction process.

## Source, Safety, And Evidence Posture

Do not ask the user for context that can be retrieved from enabled connectors. Preserve source artifacts unless the user explicitly asks for edits; prefer new briefs, comments, speaker notes, copied sections, appended trackers, or change logs.

Separate facts, assumptions, recommendations, and meeting strategy. Do not fabricate attendees, decisions, financials, metrics, source provenance, or commitments.

## Validated Handoffs

Producer contracts:
- `meeting_prep_to_deal_process_tracker` -> `deal-process-tracker`. Schema: `../../schemas/meeting_prep_to_deal_process_tracker.schema.json`. Validate with `../../scripts/validate_handoff_payload.py meeting_prep_to_deal_process_tracker handoffs/meeting_prep_to_deal_process_tracker.json` before another skill imports it.
- `meeting_prep_to_memo_builder` -> `memo-builder`. Schema: `../../schemas/meeting_prep_to_memo_builder.schema.json`. Validate with `../../scripts/validate_handoff_payload.py meeting_prep_to_memo_builder handoffs/meeting_prep_to_memo_builder.json` before another skill imports it.

## Script Map

Deterministic standalone artifact scaffold:

- `scripts/build_meeting_prep_packet.py --input <intake.json> --output-dir <output-dir>`

For downstream handoff validation, use:

- `../../scripts/validate_handoff_payload.py meeting_prep_to_memo_builder <payload.json>`
- `../../scripts/validate_handoff_payload.py meeting_prep_to_deal_process_tracker <payload.json>`

## HTML Evidence Readiness

For senior, client, committee, board, lender, or external postures, every material number, estimate, date-sensitive fact, sourced claim, assumption, and recommendation must have readable point-of-use citation support. Unknown citation IDs, missing source registers, uncited material numerical claims, unsupported mandate implications, or unverified relationship claims are blocking readiness gaps: fix them, downgrade the posture to draft/internal working team, or surface the gaps explicitly.

For an HTML meeting brief:

- Cite complete facts and metric phrases close to where they inform the stance or question plan; do not rely only on a source appendix.
- State when attendees, prior relationship history, agenda, restricted-list/compliance posture, or bank-specific context were not provided; do not invent them.
- Distinguish a public-source inferred opportunity from management-confirmed interest, an active mandate, financing need, or M&A process.
- Use internal-only do-not-say guidance only in a clearly marked internal working brief, never in external-clean material.
- Render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: polished standalone HTML meeting brief, workbook, native deck/document, generated folder, or justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map

- `references/meeting-type-playbooks.md`: read when meeting type, persona, use case, or companion-skill routing matters.
- `references/context-and-sources.md`: read for context gathering, connector/source order, stale-data checks, citation behavior, source conflicts, and no-context handling.
- `references/output-templates.md`: read for detailed prep packets, debriefs, follow-up trackers, live talk tracks, and one-page/starter formats only when shortening is justified.
- `references/question-and-diligence-bank.md`: read when generating pointed diligence questions, evidence asks, pushback follow-ups, or avoid-asking topics.
- `references/follow-up-and-action-tracking.md`: read for post-meeting debrief mode, action tracker fields, status taxonomy, owners, due dates, and non-destructive tracker updates.
- `references/safety-and-integrations.md`: read for artifact safety, internal-vs-external circulation, sensitive topics, companion-skill routing, and final checks.
- `../../references/html-artifact-standard.md`: shared HTML design, evidence, and local visual-inspection standard.
- `../../references/handoff-contracts.md`: read when exporting exact fields to `memo-builder` or `deal-process-tracker`.
- `../../references/evidence-label-taxonomy.md`: read when mapping meeting facts, assumptions, judgments, and source notes to shared evidence labels.
- `../../references/output-depth-policy.md`: read when deciding whether a one-page or live-call format is justified; default to `extended_analysis`.

## Runtime Artifact Path

Default deterministic builder: `scripts/build_meeting_prep_packet.py`. Primary human deliverable is the standalone `meeting_prep_packet.html`; `meeting_prep_packet.docx` is the native document companion when generated. Support artifacts live under `support/` and include the intake JSON. The builder is a lightweight artifact scaffold; substantive briefs should apply the selected mode, full source work, and visual review. Senior-ready status requires attendee/source confidence, circulation-appropriate guardrails, open evidence asks, and no uncited material claims in the first-read brief.

Referenced files: 9

memo-builder19.2 KB

View saved version →

---
name: memo-builder
description: draft or review investment-banking memos from existing analysis. use when the user wants a client, committee, board, financing, process, or diligence note. do not use to build source models, decks, trackers, or tearsheets.
---

# Memo Builder

## Skill Configuration

### Common Skill Instructions

### Source Resolution

Load `../../references/workflow-source-resolution.md`. Resolve only the categories needed for this workflow: `deal_materials`, `process_updates`, `relationship_counterparty_context`, `market_data_public_sources`, and `models_workbooks_templates`. Use the shared runtime contract to map each attempted category to an available app, connector, file, export, or user-provided input.

## Relevant Dependency Categories

- `Deal Materials`
- `Process Updates`
- `Market Data & Public Sources`
- `Models, Workbooks & Templates`
- `Relationship & Counterparty Context`

## Deliverable Intake

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. For substantial memo work, the selected or high-confidence inferred surface controls the hero deliverable: formal banker, committee, board, client, or lender memos usually use a real Word document; source-heavy web-style reports usually use polished standalone HTML; quick narrow notes may stay inline. If the surface is semi-ambiguous, use `../../references/deliverable-intake-policy.md` before drafting and let the chosen or timeout-resolved option control the manifest primary. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing selected memo surface, workbook, native deck/document, or clear first-read package.

## Trigger Boundary

Use this skill when the user wants model outputs, CIM claims, diligence findings, buyer feedback, meeting notes, process status, or other Investment Banking analysis converted into a decision-ready memo for a client, MD, committee, board, lender, sponsor, issuer, or deal team.

Use it for client recommendations, committee approval notes, board or special committee notes, ECM/DCM/LevFin/private-placement framing, lender or credit committee support, transaction updates, process summaries, diligence synthesis, management-call readouts, one-page banking notes, and banker-readiness reviews of existing memos.

Do not use it when the primary request is to build a source model, CIM, teaser, pitch deck, buyer list, process tracker, company tearsheet, or final deck/report circulation QC. Route those requests to the appropriate upstream skill first, then return here for memo synthesis if needed.

Do not provide personal investment advice, trading advice, legal advice, tax advice, accounting advice, fairness opinions, or account-specific portfolio recommendations.

## Role / Non-Role

Role: act as the synthesis layer that turns existing banker analysis into a memo with explicit evidence, judgment, open items, and next steps.

Non-role: do not invent the analysis, build the model, create the CIM, run the buyer list, manage the process tracker, or certify final circulation readiness. If the memo may circulate externally, to a board, to a committee, or to lenders, mark `ib_deck_qc_required: yes` and route final-circulation candidates to `ib-deck-qc`.

Default output for substantial memo work: an `extended_analysis` memo in the selected or high-confidence inferred surface, with readable point-of-use citations and any model-derived claims tied to source IDs or workbook cells/ranges where available. For a new internal transaction memo, committee memo, board memo, client memo, or lender memo with no high-confidence surface, ask the format question and normally recommend `Word document (.docx)`. For a source-heavy web-style memo or explicit HTML request, use polished standalone HTML. Use concise chat only for narrow answers, quick follow-ups, or a cover note for a richer deliverable. Use one-page, transaction-update, or brief formats only when the user explicitly asks for that shorter form, the memo is a narrow delta against an existing full artifact, or the response is a cover note for a richer deliverable. Read `../../references/output-depth-policy.md` before shortening.

## Fast Workflow

1. Classify the memo mode, audience, circulation posture, decision or question, time sensitivity, and source scope.
2. Build the source packet from user-provided files, prior outputs, connected apps, models, decks, trackers, notes, and source-of-truth records before asking for more.
3. Read only the needed references:
- mode selection and the seven memo templates in [references/memo-modes-and-templates.md](references/memo-modes-and-templates.md)
- upstream skill handoffs and import payloads in [references/upstream-handoffs-and-imports.md](references/upstream-handoffs-and-imports.md)
- QA, readiness checks, and examples in [references/quality-checks-and-examples.md](references/quality-checks-and-examples.md)
- applicable sector overlays in [references/sector-overlays.md](references/sector-overlays.md)
4. Establish the memo plan using the artifact contract below.
5. Identify the decision hinge, the 3-5 load-bearing claims, and the evidence or model output behind each.
6. Draft in the selected mode, keeping background subordinate to decision usefulness.
7. Run memo QA for sources, numbers, scenario consistency, open items, caveats, audience fit, and downstream handoff.
8. Route final-circulation candidates to `ib-deck-qc`; use `style-guide-adapter` only for format, tone, and precedent alignment after content is correct.

## Standalone HTML Path

For an ordinary internal deal-team, client-draft, committee-draft, or board-draft memo delivered as HTML, produce a polished standalone HTML memo following `../../references/html-artifact-standard.md`. For a memo delivered as DOCX, create a real full Word memo with the same decision spine, evidence posture, risks, diligence asks, and source limitations; do not treat DOCX as a thin companion to an HTML-first artifact. This skill owns the memo hierarchy, recommendation, reliance posture, evidence presentation, risk framing, and diligence asks. Do not route an ordinary HTML memo through `dashboard-builder`, create a dashboard render contract, or force the memo into generic dashboard modules.

Make the first read feel like a banker decision memo:

- open with the recommendation, reliance posture, decision hinge, source scope, and the few transaction or financial facts needed to orient the reader;
- organize the body around transaction snapshot, supported rationale, projections or model implications, key risks, diligence required before reliance, and next actions;
- distinguish disclosed transaction projections, management or seller claims, banker calculations, model outputs, and banker judgment in reader-facing language;
- keep the memo plan, manifest, render inputs, JSON support records, and internal control plumbing outside the visible report unless the user asks for them;
- use compact tables only where they sharpen the decision; do not add generic reader-action bars, navigation shells, repeated copy/export controls, or related-files panels by default.

The memo may include HTML and DOCX companions when useful, but the selected or timeout-resolved surface remains the hero. If the user explicitly requests a dashboard, route that distinct presentation request separately without making it the ordinary memo path.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: model outputs, diligence findings, process status, evidence register, and final synthesis. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Artifact Contract

Every memo should carry this lightweight memo plan, even if it is only implicit in the chat output:

- `memo_type`
- `audience`
- `circulation`: internal draft, client draft, committee draft, board draft, lender draft, or final-circulation candidate
- `decision_or_question`
- `source_scope`
- `source_as_of_dates`
- `model_outputs_used`
- `key_numbers_to_tie`
- `style_profile_package`: optional, from `style_guide_adapter_style_profile`
- `style_change_log_package`: optional, from `style_guide_adapter_change_log`
- `open_items`
- `recommended_next_step`
- `ib_deck_qc_required`: yes for any external, board, committee, lender, or client-facing use

The memo plan is a control layer, not permission to make the memo thin. Preserve evidence labels, source dates, open items, key numbers to tie, and recommended next steps unless the user explicitly requests a shorter answer.

Use these posture labels:

- `final-circulation-candidate`: evidence-supported, internally consistent, and ready for `ib-deck-qc`.
- `senior-review-ready`: good draft, but needs MD/client-team review before circulation.
- `client-draft`: useful client-facing draft with open items disclosed.
- `screen-grade`: useful for early discussion but not ready for external or committee use.
- `blocked`: missing source/model/context prevents a defensible memo.

## Source And Evidence Posture

- Never invent facts, financials, buyer feedback, valuation ranges, debt terms, process status, board decisions, or diligence findings.
- Every material number needs a source, model output, or explicit assumption.
- If a model output is used, cite its model status, date, scenario, and any hard failures or material warnings.
- Separate reported facts, management claims, seller claims, model outputs, banker judgment, and assumptions.
- When relying only on transaction filings, characterize strategic rationale as `disclosed`, `stated`, or `board-considered`; do not say the filings support or validate the strategic logic unless independent evidence substantiates that conclusion.
- Use `financial-source-of-truth` when source hierarchy, conflicts, stale data, or fact/assumption labels matter.
- Use `financials-normalizer` before relying on messy financials, adjusted EBITDA, NWC, debt schedules, or KPI tables.
- If any upstream handoff is missing source dates, evidence labels, or circulation caveats, keep the memo at `screen-grade` or `senior-review-ready` and list the missing fields in `open_items`.

## Validated Handoffs

Intake validation:
- From `company-tearsheet`: require `company_tearsheet_to_memo_builder` and run `../../scripts/validate_handoff_payload.py company_tearsheet_to_memo_builder handoffs/company_tearsheet_to_memo_builder.json` before importing fields into this skill.
- From `meeting-prep`: require `meeting_prep_to_memo_builder` and run `../../scripts/validate_handoff_payload.py meeting_prep_to_memo_builder handoffs/meeting_prep_to_memo_builder.json` before importing fields into this skill.
- From `cim-teardown`: require `cim_teardown_to_memo_builder` and run `../../scripts/validate_handoff_payload.py cim_teardown_to_memo_builder handoffs/cim_teardown_to_memo_builder.json` before importing fields into this skill.
- From `distressed-recovery-waterfall`: require `distressed_recovery_waterfall_to_memo_builder` and run `../../scripts/validate_handoff_payload.py distressed_recovery_waterfall_to_memo_builder handoffs/distressed_recovery_waterfall_to_memo_builder.json` before importing fields into this skill.
- From `style-guide-adapter`: require `style_guide_adapter_style_profile` and run `../../scripts/validate_handoff_payload.py style_guide_adapter_style_profile handoffs/style_guide_adapter_style_profile.json` before importing fields into this skill.
- From `style-guide-adapter`: require `style_guide_adapter_change_log` and run `../../scripts/validate_handoff_payload.py style_guide_adapter_change_log handoffs/style_guide_adapter_change_log.json` before importing fields into this skill.

## Script Map

Use upstream Investment Banking and Financial Markets skills for deterministic model, diligence, valuation, process, and source-of-truth work, then use this skill to synthesize those outputs into memo form. When deterministic packaging from structured memo inputs is appropriate, use `scripts/build_memo_package.py --primary-format html` or `scripts/build_memo_package.py --primary-format docx` according to the selected memo surface.

For structured upstream packages, validate exact field names before relying on them as automation boundaries:

- `../../scripts/validate_handoff_payload.py company_tearsheet_to_memo_builder <payload.json>`
- `../../scripts/validate_handoff_payload.py meeting_prep_to_memo_builder <payload.json>`

## HTML Evidence Readiness

For senior, client, committee, board, lender, or external circulation postures, every material number, estimate, date-sensitive fact, sourced claim, assumption, and recommendation in the standalone HTML memo must have readable point-of-use citation support. Model-derived claims should cite the workbook, scenario, status, sheet, and cell or range where available.

Unknown sources, missing source registers, unsupported material numerical claims, or unlabeled projection/model assumptions are blocking readiness gaps. Fix them, downgrade the posture to draft or `screen-grade`, or surface the missing support as an explicit diligence gap; do not call the memo ready for the intended circulation audience while those gaps remain.

For a standalone HTML memo:

- label disclosed projections and synergy cases as disclosed or management/seller cases until diligence establishes an underwritten case;
- keep derived calculations and banker judgments visibly distinct from reported facts and quoted model outputs;
- render and visually inspect the local HTML through local headless-browser screenshots rather than the in-app Browser plugin, checking the opening viewport and the most decision-critical tables or diligence sections;
- check hierarchy, table legibility, clipping, density, citation noise, and whether the requested decision is clear before delivery.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: standalone HTML memo, XLSX workbook, native deck/document, generated folder, or justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, render inputs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map

- [references/memo-modes-and-templates.md](references/memo-modes-and-templates.md): read when choosing a memo mode, drafting from a mode-specific structure, or converting a user request into one of the seven standard memo templates.
- [references/upstream-handoffs-and-imports.md](references/upstream-handoffs-and-imports.md): read when consuming outputs from company tearsheets, CIM teardown, meeting prep, buyer/investor lists, process trackers, models, underwriting, covenant, capital markets, or restructuring workflows.
- [references/quality-checks-and-examples.md](references/quality-checks-and-examples.md): read before calling a memo senior-review-ready or final-circulation-candidate, when reviewing an existing memo, or when examples of memo-plan and evidence-label handling would help.
- [references/sector-overlays.md](references/sector-overlays.md): read only when the target clearly matches healthcare workflow/payments software, consumer internet/marketplace, or specialty materials/industrial carve-out.
- [../../references/html-artifact-standard.md](../../references/html-artifact-standard.md): shared standalone HTML design, evidence, and local visual-inspection standard.
- [../../references/handoff-contracts.md](../../references/handoff-contracts.md): read when exact upstream field names, shared package names, or cross-skill contract parity matters.
- [../../references/evidence-label-taxonomy.md](../../references/evidence-label-taxonomy.md): read when mapping upstream source labels, memo evidence labels, assumptions, and banker judgment into the shared taxonomy.
- [../../references/output-depth-policy.md](../../references/output-depth-policy.md): read when deciding whether one-page or transaction-update depth is justified; default to `extended_analysis`.

## Runtime Artifact Path

Default deterministic builder: `scripts/build_memo_package.py`. The selected or high-confidence inferred surface controls the primary human deliverable: `investment_memo.docx` for DOCX-selected formal memo circulation or `investment_memo.html` for HTML-selected web-style reports. The other surface may be generated as a companion. Support artifacts live under `support/` and include memo-plan or calculation-support JSON where needed; do not create a dashboard render contract for an ordinary memo. Committee/client-ready status requires source posture, model tie-outs, open issues, readable citation support, and downstream `ib-deck-qc` where required; unresolved material citations force draft posture.

Referenced files: 6

merger-model-builder14 KB

View saved version →

---
name: merger-model-builder
description: Build merger and accretion/dilution models for consideration, pro forma ownership, synergies, purchase accounting, financing mix, or EPS impact. Use for strategic M&A modeling; not standalone DCF or LBO work.
---

# Merger Model Builder

## Skill Configuration

### Common Skill Instructions

## Relevant Dependency Categories

- `Market Data & Public Sources`
- `Models, Workbooks & Templates`
- `Deal Materials`

## Deliverable Intake

When this skill owns a new substantive user-facing artifact, before source gathering, analysis, modeling, or rendering load `../../references/deliverable-intake-policy.md` and perform its adaptive `request_user_input` preflight for materially unresolved preferences. For a merger model, accretion/dilution screen, or pro forma ownership model with an unresolved surface, offer `Excel merger / accretion workbook (Recommended)`, `Polished HTML transaction summary`, and `Inline screening view`. Default to the banker-readable workbook when intake is not required or a non-interactive model-build run must apply a default. When invoked as a downstream support step within an already scoped workflow, inherit resolved preferences and do not re-prompt.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing workbook, an explicitly requested standalone HTML transaction summary, native deck/document, or clear first-read package.

Produce M&A model artifacts that answer whether the consideration structure, ownership transfer, synergies and accounting/financing effects support the deal rationale. For substantive merger-model work, the normal hero deliverable is a polished banker-readable workbook with an insight-led first visible tab. Use the full deterministic or formula engine when the input set supports its accounting scope; do not manufacture PPA or GAAP inputs merely to make a public-source adjusted-EPS screen fit a full-schema engine.

## Scope

Own sources/uses, consideration mix, PPA, financing, synergies, PF earnings, shares, ownership, EPS accretion/dilution, sensitivities, checks, and posture. Route sourcing, normalization, financing/covenant work, memo/deck polish, and independent workbook audit to the adjacent finance/IB skills.

## Rules

Use available prompt/files/connectors first; use placeholders only when the user wants a model despite gaps. Never overwrite user source files. Generated outputs go to a new or user-specified output directory.

Every material input needs a native evidence label from `references/plan-schema.md`. For partial context, the first user-facing output starts with:

> **SCREEN-GRADE: adjusted EPS analysis based on disclosed projections and modeled assumptions; GAAP accretion/dilution is not presented without complete PPA and post-close actualization support.**

Use this warning when ownership, disclosed projections, or synergy analysis can be completed but PPA, GAAP EPS, post-close share actualization, or refinancing effects cannot. List those items as readiness gates and keep the model `screen-grade`; do not describe disclosed source inputs as placeholders. Use explicit placeholder language only when an input included in the displayed metric is actually estimated or inserted to keep the model runnable.

## Workflow Modes

- `adjusted_eps_screen`: public-source merger model where transaction terms, ownership mechanics, disclosed projections, or synergy data support adjusted-EPS analysis but complete PPA, GAAP EPS, post-close denominator actualization, or financing economics do not. Use a workbook hero, omit unsupported GAAP conclusions, and do not exceed `screen-grade`.
- `gaap_accretion_model`: source-supported merger model with PPA, amortization, integration-cost treatment, financing effects and denominator support sufficient to show GAAP and adjusted EPS. Use a workbook hero and apply readiness gates before senior or committee characterization.
- `html_companion`: explicitly requested narrative executive view of workbook outputs. Keep the workbook as the calculation source of truth and create standalone HTML only as a companion or selected narrative surface.

For `adjusted_eps_screen`, classify each synergy measure by provenance: disclosed gross run-rate synergies; disclosed pretax net synergies when provided; disclosed costs to achieve when provided; or clearly labeled `implied cost-to-achieve` only when derived from disclosed gross and net synergy figures. Distinguish any model-derived after-tax benefit using a stated tax assumption. Do not call a disclosed pretax net synergy figure model-derived or an implied cost-to-achieve amount disclosed. Require sensitivity views for synergy realization and cost-to-achieve overrun or delayed capture, together with EPS breakeven against the selected pretax net synergy basis. In a fixed-ratio all-stock transaction, do not prioritize share-price sensitivity for ownership or EPS denominator mechanics unless the user asks for purchase-price or PPA-value analysis.

## Validated Handoffs

Intake validation:

- From `cim-teardown`: require `cim_teardown_to_model_builder` and run `../../scripts/validate_handoff_payload.py cim_teardown_to_model_builder handoffs/cim_teardown_to_model_builder.json` before importing fields into this skill.

## Script Map

Visible scripts are executable shims. Internals live in `scripts/runtime/` and should be opened only for debugging.

```bash
python3 scripts/validate_plan.py assets/plan_template.json
python3 scripts/run_pipeline.py assets/plan_template.json --output-dir output --print-report
python3 scripts/build_banker_formula_workbook.py assets/plan_template.json --output-dir output
```

`scripts/skill_core.py` imports the full-schema engine. `run_pipeline.py` writes `model.xlsx`, `plan.json`, `run_log.json`, `manifest.json`, and optional `report.md` only when explicitly requested. Formula mode materializes the bundled XLSX template and writes a separate formula log plus `manifest.json`. Treat `model.xlsx` as the hero human deliverable, opening on a banker-readable `Cover`, `Executive Summary`, or `Dashboard` tab per `../../references/workbook-first-tab-standard.md`; write legacy `report.md` only when explicitly requested. When a public-source `adjusted_eps_screen` intentionally omits PPA/GAAP fields that the bundled full-schema engine requires, build a formula-driven workbook limited to supported metrics rather than substituting placeholder purchase accounting. Treat logs, normalized plans, model-citation ledgers and manifests as support artifacts. Deep tests are archived outside the prompt-facing test wrappers; run them when changing internals.

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. For substantive merger-model work, the normal hero deliverable is a polished banker-readable workbook with an insight-led first visible tab. Create a standalone HTML transaction summary only when the user explicitly requests HTML or a narrative companion; the workbook remains the model source of truth. CSV, JSON, Markdown, run logs, manifests, model-citation ledgers, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Workflow

Triage the deal and select the workflow mode before modeling. Build or ingest `plan.json` where the selected engine supports the requested metrics; otherwise build the bounded `adjusted_eps_screen` workbook without unsupported PPA/GAAP calculations. Review hard failures, warnings, source posture, EPS with/without synergies, ownership, synergy provenance, PPA/GAAP readiness, financing effects and downside breaks. Deliver paths plus a banker conclusion and one posture label: `decision-grade`, `senior-review-ready`, `screen-grade`, `not-decision-ready`, or `blocked`.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: standalone inputs, transaction assumptions, financing/purchase accounting, synergies, accretion/dilution, and QA. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Workbook Evidence Readiness

The workbook is the analytical source of truth. For senior, client, committee, board, lender, or external postures, every material input and derived output must be traceable through readable source/assumption notes and `model_citations` / `model_citations_path` records down to workbook sheet/cell or range where available.

Unknown source IDs, missing model citations for headline ownership or EPS outputs, unsupported synergy classification, unavailable PPA or GAAP inputs, unresolved denominator actualization, or unreported model substitutions are blocking readiness gaps. Fix them, cap posture at `screen-grade`, or surface them explicitly; do not call a workbook senior/client/committee/board/external-ready while they remain.

The first visible tab must separately label `Calculation integrity` and `Decision readiness`. An adjusted-EPS model can calculate correctly while remaining only a screen because GAAP/PPA, post-close shares, financing economics, synergy execution or tax support remains incomplete.

Before delivery, visually inspect the first visible tab, ownership, EPS bridge, synergies, sensitivities and checks/readiness views. Repair the workbook before returning it if it calls a model-derived net benefit `disclosed`, displays GAAP accretion/dilution without complete supporting inputs, or leaves the readiness distinction only on a later checks sheet.

## Optional HTML Companion

When the user explicitly requests an HTML report or visual transaction summary, keep this skill as the analytical owner and produce a polished standalone HTML companion following `../../references/html-artifact-standard.md`. Do not route an ordinary merger-model HTML summary through `dashboard-builder`, create a dashboard render contract, or force workbook-derived ownership and accretion findings into fixed dashboard modules.

In that HTML companion, cite workbook-derived ownership, synergy, PPA, financing and accretion/dilution outputs to exact workbook cell/range records through `model_citations` or `model_citations_path` wherever available. Render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

Do not expose raw JSON, Markdown report files, model-citation ledgers, or run logs as the default final artifact.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: normally the XLSX merger/accretion workbook; an explicitly requested standalone HTML transaction summary; native deck/document; generated folder; or justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, model-citation ledgers, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map

- `plan-schema.md`: required keys, labels, source posture.
- `output-spec.md`: files, sheets, report/log shape.
- `workflow-and-mode-selection.md`: adjusted-EPS screen versus GAAP-capable model routing.
- `model-math.md`: core formulas and breakeven.
- `qa-checks.md`: failures, warnings, senior red flags.
- `banker-formula-workbook-contract.md`: formula template limits.
- `investment-banking-integrations.md`: handoffs.
- `evals.md`: smoke prompts and expected behavior.

## Runtime Artifact Path

Default deterministic outputs are `model.xlsx`, `manifest.json`, `run_log.json`, and `model_citations.json`; formula mode emits `banker_formula_workbook.xlsx` with the same shared manifest and citation ledger. The workbook is the primary human deliverable. Support artifacts include plans, run logs, and citation ledgers. Senior-ready status requires transaction assumptions, pro forma ownership, accretion/dilution, clearly classified synergy evidence, financing, PPA/GAAP support when presented, checks, and cell/range provenance for material model outputs.

Referenced files: 28

model-audit-tieout13.6 KB

View saved version →

---
name: model-audit-tieout
description: audit existing financial models and workbook outputs. use when the user asks to check formulas, sources, assumptions, sensitivities, links, or model readiness. do not use to build a new model from scratch.
---

# Model Audit Tie-out

## Skill Configuration

### Common Skill Instructions

## Relevant Dependency Categories

- `Models, Workbooks & Templates`
- `Deal Materials`
- `Market Data & Public Sources`

## Deliverable Intake

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. For a substantive review of an existing financial model, the normal hero deliverable is a polished banker-readable workbook audit pack. Use a standalone HTML audit summary only when the user explicitly requests HTML or the resolved format choice requires a narrative companion. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so a standalone model-review request results in a banker-facing audit workbook, while a committee memo or deck workflow can consume the audit findings without displacing its own hero deliverable.

## Trigger Boundary

Use this skill to audit an existing financial model, workbook, forecast, valuation file, sensitivity deck, or model-derived output. It is the quality-control layer for formula integrity, workbook structure, source support, assumptions, sensitivities, links, and decision readiness.

Use it when the user asks to check:
- formulas, hardcodes, broken links, circularity, hidden sheets, or workbook hygiene.
- whether model outputs tie to sources, decks, memos, assumptions, or cited documents.
- whether scenarios, downside cases, sensitivities, or model outputs are decision-useful.
- whether a model is ready for IC, credit committee, client delivery, board review, or diligence.

Do not use it to build a new model from scratch. Route new-build work to the relevant builder skill, and only edit or remediate a workbook when the user explicitly asks for changes.

## Role And Non-Role

Role: map the model, diagnose issues, trace outputs to sources, prioritize decision-impacting breaks, and produce an audit pack or fix list.

Non-role: replace DCF, LBO, comps, three-statement, underwriting, memo, deck, or data-cleaning skills. Use those skills after the audit if remediation or synthesis is requested.

## Fast Workflow

1. Define the audit mandate: model type, decision context, materiality threshold, files reviewed, and required output.
2. If a workbook is available, run the workbook audit script unless the task is purely conceptual; if no workbook is available, manually review the excerpts, screenshots, formulas, outputs, or assumptions provided.
3. Map the key outputs and decision drivers to workbook tabs, cells/ranges, formulas, source tabs, and source documents.
4. Apply formula and workbook controls for consistency, hardcodes, external links, hidden sheets, volatility, circularity, and schedule checks.
5. Tie material assumptions and outputs to evidence; use `financial-source-of-truth` standards when source hierarchy, staleness, conflicts, or evidence labels control the answer.
6. Review scenarios and sensitivities for coherent cases, relevant downside drivers, and false precision.
7. Where a clearly identified error affects a material output, create a formula-driven `audit-indicative` diagnostic bridge using stated or sourced inputs to quantify the effect; label it as a diagnostic rather than a remediated model.
8. Build a risk-ranked issue log with severity, category, location, finding, decision impact, recommended fix, and owner.
9. Deliver the requested audit artifact and stop before remediation unless the user asks you to make changes.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: formula controls, source tie-out, scenario review, output consistency, and issue severity. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Artifact Contract

Default to `extended_analysis` for model review. Use rapid-screen depth only when the user explicitly asks for a quick view, red flags, top issues only, meeting triage, or a narrow follow-up to an existing full audit:
- **Full audit pack:** polished workbook with executive summary, output bridge or material diagnostic where applicable, issue log, formula/workbook controls, source tie-out findings, assumption and scenario critique, remediation sequence, diligence asks, and scope appendix.
- **Rapid screen:** model health score, readiness posture, top issues, must-fix items, and missing files or questions.
- **Formula audit:** formula exception log plus workbook-control findings and recommended fixes.
- **Source tie-out:** source tie-out ledger with model location, model value, source value, tie status, evidence label, as-of date, decision impact, and action.
- **IC-ready audit pack:** executive summary, readiness posture, issue log, formula/workbook controls, source tie-out findings, assumption and scenario critique, remediation sequence, diligence asks, and scope appendix.

Use direct readiness language: `ready for decision`, `ready with caveats`, `not ready`, or `not assessable`.

For a full workbook audit pack, use an insight-led first visible sheet and organize the workbook around these tabs when applicable: `Executive Summary`, `Output Bridge`, `Issue Log`, `Source Tie-Out`, `Formula Controls`, `Model Map`, and `Scope / Evidence / Limitations`. Apply `../../references/workbook-first-tab-standard.md`.

Keep two readiness conclusions distinct: whether the audit pack is complete and usable for internal review, and whether the audited source model is reliable enough for the requested decision. A completed audit pack may properly conclude that the audited model is `not ready`.

Read `../../references/output-depth-policy.md` before shortening.

## Source And Evidence Posture

Material outputs and key assumptions must be traceable to a model tab, cell/range, source document, or explicit user assumption. A model can be mechanically clean but still not decision-ready if its core value, credit, liquidity, covenant, or return drivers are stale, unsupported, contradictory, or assumption-led.

Keep model mechanics separate from investment judgment. Formula errors, stale market data, unsupported add-backs, weak downside cases, and weak source support are different issue types and should be labeled separately.

Keep model-stated assumptions, primary-source facts, model-extracted values, and `audit-indicative` diagnostic calculations distinct. A diagnostic calculation may quantify an identified inconsistency using visible model or sourced inputs, but must not be described as a corrected transaction model, fully remediated output, or client/committee-ready conclusion. When the diagnostic incorporates only part of a disclosed or benchmark amount, separately label the adjustment incorporated and any residual unresolved gap in the executive summary and final response; do not present the residual gap as the diagnostic change.

## Script Map

- `scripts/audit_workbook.py`: static xlsx inspection for a cover-first mechanical-screen workbook, workbook map, formula inventory, issue log, and audit summary JSON. It supports, but does not replace, a judgmental source tie-out and diagnostic audit pack.
- `scripts/requirements.txt`: local script dependencies for workbook inspection.

Run the audit script from the skill directory or pass explicit paths:

```bash
python scripts/audit_workbook.py path/to/model.xlsx --out-dir audit_output
```

`scripts/audit_workbook.py --help` and argument parsing should work without `openpyxl`, but actual workbook inspection requires it. If dependencies cannot be installed or the script cannot run, state that clearly and use the manual audit workflow instead.

## Workbook Evidence Readiness

For internal transaction review, IC, client, committee, board, lender, or external postures, every material output, diagnostic adjustment, date-sensitive fact, sourced assumption, and readiness conclusion must be traceable at the point of use to a workbook tab and cell/range, source document location, or explicit assumption label. Include readable source IDs and as-of dates in the source tie-out ledger; use `model_citations` or an equivalent cell/range citation ledger when a workbook-derived output is used in another artifact.

Separate `Calculation integrity` from `Decision readiness`. A clean static scan, visible model PASS check, or formula tie-out is not evidence that material financing scope, synergy timing, purchase accounting, source support, or decision outputs are reliable. Unsupported material outputs, unexplained conflicts, diagnostic outputs presented as corrected results, or missing source/cell provenance are blocking readiness gaps.

For a workbook audit pack, render and visually inspect the executive summary and each material diagnostic, issue-log, source tie-out, and formula-control sheet before delivery. State explicitly when formulas and cached outputs were inspected without native Excel recalculation.

## Optional HTML Companion

When the user expressly requests HTML, produce a polished standalone audit summary following `../../references/html-artifact-standard.md`, grounded in workbook cell/range provenance and source tie-outs. Keep the workbook as the hero deliverable for model-heavy audit work unless the user explicitly selects a narrative-only surface. Do not route an ordinary model audit or HTML audit summary through `dashboard-builder`, create a dashboard render contract, or force the output into dashboard modules.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: for ordinary model review, a polished banker-readable XLSX audit pack; for expressly requested narrative explanation, an optional standalone HTML companion or selected narrative-only artifact; otherwise a justified alternate surface. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map

- `references/audit-playbook.md`: read when choosing audit mode, defining the mandate, mapping key outputs, applying model-specific focus areas, or setting readiness posture.
- `references/formula-and-workbook-controls.md`: read when checking formulas, hardcodes, hidden sheets, external links, circularity, schedule controls, or manual checks beyond the script.
- `references/tieout-and-source-checks.md`: read when tracing outputs or assumptions to sources, evidence labels, tie statuses, stale data, and source conflicts.
- `references/issue-taxonomy.md`: read when assigning severity, issue category, owner, escalation level, or rapid-screen health score.
- `references/output-templates.md`: read when producing a rapid screen, full audit memo, issue log, formula exception log, source tie-out ledger, or remediation plan.
- `references/investment-banking-integrations.md`: read when routing to or from other Investment Banking skills after the audit.
- `../../references/workbook-first-tab-standard.md`: required for substantive workbook audit packs.
- `../../references/html-artifact-standard.md`: read only when a standalone HTML audit companion is explicitly requested or selected.
- `../../references/output-depth-policy.md`: read when deciding whether rapid-screen depth is justified; default to `extended_analysis`.

Referenced files: 9

pitch-deck-builder16.1 KB

View saved version →

---
name: pitch-deck-builder
description: build investment-banking pitch deck outlines, page plans, and draft slide content. use when the user asks to create or refresh a banking pitch or client discussion deck. do not mark final client-ready; route final circulation qc to ib-deck-qc.
---

# Pitch Deck Builder

## Skill Configuration

### Common Skill Instructions

### Source Resolution

Load `../../references/workflow-source-resolution.md`. Resolve only the categories needed for this workflow: `deal_materials`, `process_updates`, `relationship_counterparty_context`, `market_data_public_sources`, and `models_workbooks_templates`. Use the shared runtime contract to map each attempted category to an available app, connector, file, export, or user-provided input.

## Relevant Dependency Categories

- `Deal Materials`
- `Market Data & Public Sources`
- `Relationship & Counterparty Context`
- `Process Updates`

## Deliverable Intake

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. The hero deliverable must be a workbook, HTML report/dashboard, native deck/document, generated folder first-read file, or justified chat-only answer. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing workbook, HTML report/dashboard, native deck/document, or clear first-read package.

## Trigger Boundary

Use for investment banking buyer pitches, sell-side and M&A pitches, financing pitches, strategic alternatives decks, company profile decks, market maps, sector updates, capital structure discussions, and board/client meeting decks.

Role: orchestrate the pitch storyline, page architecture, source posture, draft slide content, and structured handoffs.

Non-role: do not replace full valuation/modeling/diligence skills, do not make legal/tax/accounting/securities-law conclusions, and do not mark a deck final client-ready. Route circulation review to `ib-deck-qc`.

Success condition: produce a concise, decision-led banker deck in which each core page advances the audience's decision, supported facts and banker judgment are clearly distinguished, and visual QA is performed on the final exported artifact.

## Fast Workflow

1. Classify the deck type, audience, objective, source package, and whether the ask is a page plan, storyboard, native deck, or slide-construction handoff.
2. If the request is ambiguous, choose the most likely deck type from context; ask one targeted clarification only when the deck objective or target company is truly unclear.
3. If the entity/company facts are thin, route through `company-tearsheet`; if financials, valuation, credit, buyer lists, diligence, or models are specialized, use the appropriate dedicated skill instead of recreating it here.
4. Draft the MD-level storyline before page planning: what decision/action should the client take, why now, what supports it, and what objections must be handled.
5. Build the deck plan/page plan as the default planning control. Preserve user-provided materials and make missing sources, stale data, conflicts, assumptions, and senior-review issues visible.
6. For a deck deliverable, use the available `Presentations` capability to create a polished native editable `.pptx` when available. If native deck generation is unavailable or the user specifically requests HTML, create a polished standalone HTML storyboard/report following `../../references/html-artifact-standard.md`. Convert to slide blueprints only after the deck plan is stable.
7. Render and visually inspect the final exported `.pptx` slide previews and contact sheet, or the standalone HTML screenshots, before reporting QA. Then route final circulation/readiness review to `ib-deck-qc` when available.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: storyline, source support, financial/model inputs, slide drafting, and QC handoff. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Artifact Contract

Default reader-facing artifact: a polished native editable `.pptx` built through `Presentations` when that capability is available, or a polished standalone HTML storyboard/report when native deck generation is unavailable or HTML is expressly requested. The banker-readable deck plan remains the planning layer that explains the deck objective, MD storyline, proposed slide architecture, evidence status, source needs, open items, and downstream work.

Separate contract: a **slide blueprint** is a lower-level construction spec for slide-generation tools. Use it only after the deck plan is stable and do not substitute it for unresolved deck strategy or weak sourcing.

Do not route an ordinary deck or HTML storyboard through `dashboard-builder`. If a structured handoff is requested, use deck-plan JSON and validate it as a support artifact. If the downstream builder specifically needs construction instructions, create separate slide-blueprint JSON and validate that too.

## Export Contract To `ib-deck-qc`

When a deck plan, storyboard, native deck, or slide blueprint is ready for circulation review, export the canonical `pitch_deck_builder_to_ib_deck_qc` package from `../../references/handoff-contracts.md`.

Required package fields:
- `artifact_type`, `artifact_version`, `circulation_posture`, `audience`, `deck_metadata`, `md_storyline`, `page_plan`, `source_log`, `key_numbers_to_tie`, `claim_register`, `chart_and_visual_register`, `slide_blueprint`, `appendix`, `style_profile_package`, `style_change_log_package`, `qa_status`, and `open_items`.

The native deck or HTML storyboard/report is the user-facing strategy/page-plan artifact. The slide blueprint is only a construction spec after the deck plan is stable. Missing source support, unresolved storyline issues, or `qa_status.ready_for_ib_deck_qc = false` should block final circulation posture.

## Source And Evidence Posture

Preserve source materials, existing slides, sheets, rows, columns, files, workbook tabs, formulas, charts, deck structure, templates, masters, formatting systems, page numbers, footnote conventions, disclaimers, brand assets, and user data unless the user explicitly asks for changes.

Every material factual claim, metric, valuation output, market statistic, financing view, ownership claim, transaction reference, recent development, or buyer rationale needs a citation, source-register entry, or explicit `needs_source` / `assumption` / `placeholder` label.

Use pitch-deck-native labels such as `fact`, `source_derived_estimate`, `model_derived_estimate`, `banker_judgment`, `client_assumption`, `external_assumption`, `placeholder`, and `unknown`. For downstream Investment Banking handoffs, add `canonical_evidence_category` from `../../references/evidence-label-taxonomy.md` without overwriting native labels.

## Validated Handoffs

Producer contracts:
- `pitch_deck_builder_to_ib_deck_qc` -> `ib-deck-qc`. Schema: `../../schemas/pitch_deck_builder_to_ib_deck_qc.schema.json`. Validate with `../../scripts/validate_handoff_payload.py pitch_deck_builder_to_ib_deck_qc handoffs/pitch_deck_builder_to_ib_deck_qc.json` before another skill imports it.

Intake validation:
- From `distressed-recovery-waterfall`: require `distressed_recovery_waterfall_to_pitch_deck_builder` and run `../../scripts/validate_handoff_payload.py distressed_recovery_waterfall_to_pitch_deck_builder handoffs/distressed_recovery_waterfall_to_pitch_deck_builder.json` before importing fields into this skill.
- From `style-guide-adapter`: require `style_guide_adapter_style_profile` and run `../../scripts/validate_handoff_payload.py style_guide_adapter_style_profile handoffs/style_guide_adapter_style_profile.json` before importing fields into this skill.
- From `style-guide-adapter`: require `style_guide_adapter_change_log` and run `../../scripts/validate_handoff_payload.py style_guide_adapter_change_log handoffs/style_guide_adapter_change_log.json` before importing fields into this skill.

## Script Map

- `scripts/build_source_request_checklist.py <deck_type>`: print universal plus deck-type-specific source asks.
- `scripts/build_deck_blueprint.py --deck-type <type> [--entity ...] [--audience ...] [--objective ...] [--format json|markdown]`: create a starter slide-construction blueprint after planning context is stable.
- `scripts/validate_deck_plan_json.py <deck_plan.json>`: validate the user-facing deck/page-plan JSON contract.
- `scripts/build_deck_storyboard.py <deck_plan.json> <output.md>`: convert validated deck-plan JSON into a support storyboard when explicitly requested or needed for downstream tooling.
- `scripts/build_deck_storyboard_html.py --input <deck_plan.json> --output-dir <dir>`: create the standalone HTML storyboard fallback when native deck output is unavailable or HTML is requested.
- `scripts/validate_deck_blueprint.py <blueprint.json>`: validate lower-level slide-construction blueprint JSON.
- `scripts/make_slide_index.py <blueprint.json>`: create a compact slide index from blueprint JSON.

## Native Deck Evidence Readiness

For senior, client, committee, board, lender, or external postures, every material number, estimate, date-sensitive fact, sourced claim, assumption, and recommendation must have readable point-of-use citation support in the native deck or standalone HTML storyboard. Model-derived claims should cite model support down to workbook/sheet/cell or range where available.

Unknown source IDs, missing source registers, uncited material numeric claims, or unmarked banker judgment are blocking readiness gaps. Fix them, downgrade the posture to working draft, or surface the missing support explicitly; do not call the output senior/client/committee/board/external-ready while those gaps remain.

## Native Deck And HTML Fallback

When a native deck is requested or appropriate, keep this skill as the analytical owner and use `Presentations` for editable slide construction, rendering, contact-sheet review, and final exported `.pptx` visual QA. The normal hero artifact is the final `.pptx`; deck-plan JSON, source registers, QA records, and handoff payloads remain support artifacts.

If native slide tooling is unavailable or the user requests HTML, produce a polished standalone HTML storyboard following `../../references/html-artifact-standard.md`. Render and visually inspect the local HTML via local headless-browser screenshots; do not use the in-app Browser plugin for local-file inspection and do not route ordinary storyboard output through `dashboard-builder`.

For either path, report QA from the final exported artifact. If layout checks show warnings that are visually adjudicated as non-blocking, say so accurately rather than claiming `0` warnings.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: XLSX workbook, HTML report, HTML dashboard, native deck/document, generated folder, or justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map

- `references/deck-archetypes.md`: read when classifying the pitch type, required sections, typical slide order, archetype-specific outputs, or source asks.
- `references/storyline-framework.md`: read when shaping the MD storyline, proof pillars, client decision, page economy, or narrative escalation.
- `references/md-level-standards.md` and `references/banker-quality-standard.md`: read when drafting banker-grade action titles, commercial judgment, and senior-review framing.
- `references/source-and-evidence.md`: read when sources are missing, stale, conflicting, confidential, assumption-heavy, or need citation/evidence labels.
- `references/source-request-checklists.md`: read when context is thin or the deliverable should include source requests instead of fabricated values.
- `references/slide-library.md`: read when assembling common banking page patterns or choosing visuals.
- `references/output-schema.md`: read when producing the deck plan, HTML storyboard/report, support storyboard, or structured JSON handoff.
- `references/slide-blueprint-schema.md`: read only when a downstream slide builder needs construction-level instructions after the deck plan is stable.
- `references/integration-guide.md`: read when coordinating with `company-tearsheet`, valuation/modeling/credit/diligence skills, `style-guide-adapter`, or downstream deck builders.
- `references/quality-checklist.md` and `references/slide-quality-qc.md`: read before final delivery and before routing to `ib-deck-qc`.
- `references/prompt-examples.md`: read when testing trigger boundaries or example requests.
- `../../references/html-artifact-standard.md`: read when HTML storyboard/report output is requested or native slide tooling is unavailable.
- `../../references/handoff-contracts.md`: read when exporting the `pitch_deck_builder_to_ib_deck_qc` package or importing structured outputs from restructuring, style, model, credit, or diligence skills.

## Runtime Artifact Path

Primary human deliverable: a specifically named native `.pptx` created and rendered through `Presentations` when available. Deterministic standalone HTML fallback: `scripts/build_deck_storyboard_html.py`, producing `pitch_deck_storyboard.html` without a dashboard contract or placeholder native deck. Deck-plan JSON and QC handoffs are support/agent artifacts only. Final client-ready status is not granted here; route the generated deck or storyboard through `ib-deck-qc` with source/model citation coverage.

Referenced files: 22

private-credit-underwriting21.5 KB

View saved version →

---
name: private-credit-underwriting
description: Build borrower-level private credit underwriting views for lender cases, credit memos, debt sizing, downside, liquidity, collateral, recovery, and proceed/decline decisions. Use for lender-side credit decisions, not issuer financing strategy.
---

# Private Credit Underwriting

## Skill Configuration

### Common Skill Instructions

### Source Resolution

## Relevant Dependency Categories

- `Market Data & Public Sources`
- `Deal Materials`
- `Models, Workbooks & Templates`
- `Relationship & Counterparty Context`

## Deliverable Intake

When this skill owns a new substantive user-facing artifact, before source gathering, analysis, modeling, or rendering load `../../references/deliverable-intake-policy.md` and perform its adaptive `request_user_input` preflight for materially unresolved preferences. For a private-credit initial screen, lender underwriting memo, or acquisition-financing credit review with an unresolved surface, offer `Polished HTML lender underwriting memo (Recommended)`, `Excel debt-capacity / lender-case workbook`, and `Word credit memo (.docx)`. Default to polished standalone HTML when intake is not required or a non-interactive run must apply a default. Select workbook-first output without a format question when the user requests reusable debt sizing, liquidity, covenant, or downside calculations. When invoked as a downstream support step within an already scoped workflow, inherit resolved preferences and do not re-prompt.

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. The normal hero deliverable for an initial screen or lender underwriting memo is a polished standalone HTML lender memo. Use an XLSX workbook as the hero deliverable for reusable debt-capacity, lender-case, liquidity, covenant, or downside calculations, with a concise standalone HTML explanation as an appropriate companion. Native documents, generated folder first-read files, and justified chat-only answers remain available when requested or appropriate. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing workbook, standalone HTML lender memo, native deck/document, or clear first-read package.

## Trigger Boundary

Use this skill for borrower-level private credit decisioning: proceed / decline / proceed-with-conditions recommendations, lender cases, credit memos, debt sizing, downside, liquidity, collateral, recovery, sponsor support, monitoring plans, and credit committee synthesis.

Do not use this skill as the lead for issuer-side financing strategy, capital markets window advice, investor targeting, legal covenant interpretation, raw financial cleanup, or sponsor return modeling. Route those to the adjacent skills named below unless the user explicitly invokes `private-credit-underwriting`.

Explicit invocation override: if the user specifically asks to use this skill, keep it as the lead, produce the credit decision view, label adjacent capital markets or covenant-document topics as inputs/caveats, and recommend targeted handoffs.

## Role And Non-Role

Default lead role: **borrower-level private credit underwriter**.

Own:
- credit recommendation, lender case, risk rating, debt sizing, repayment capacity, downside, liquidity, collateral, recovery, sponsor support, monitoring plan, and committee memo synthesis.
- covenant and term-sheet analysis only as part of the credit decision and lender protection package.
- lender EBITDA, lender-after-haircut EBITDA, and covenant proxies when source support is clear or caveated.

Hand off:
- issuer-side financing strategy, ECM/DCM/private-placement market window, investor targeting, launch timing, and use-of-proceeds recommendation to `capital-markets-issuance`.
- document-first covenant definitions, baskets, restricted payments, investments, debt/lien capacity, leakage paths, EBITDA definition interpretation, amendments, and waiver mechanics to `covenant-package-analyzer` using `private_credit_underwriting_to_covenant_package_analyzer` when the output is structured.
- adjusted EBITDA, normalized EBITDA, lender EBITDA, run-rate adjustments, and NWC support to `financials-normalizer` when source-backed normalization is the main job.
- rebuilt operating forecasts and lender-case models to `three-statement-model-builder`.
- sponsor returns, sources and uses, equity value creation, and LBO mechanics to `lbo-model-build`.
- source hierarchy, stale-data checks, conflicts, citation format, and fact/assumption labels to `financial-source-of-truth`.
- distressed, amendment, default, or recovery waterfall analysis to `distressed-recovery-waterfall` using `private_credit_underwriting_to_distressed_recovery_waterfall` when value break, lien priority, or recoveries become central.
- model/formula/source QA to `model-audit-tieout`; final committee or lender-pack circulation checks to `ib-deck-qc`.

## Fast Workflow

1. Lock mandate and evidence posture: borrower, deal type, requested decision, audience, period, currency, units, source base, and whether the output is screening, diligence-grade, or committee-ready.
2. Classify the request: `initial_credit_screen`, `underwriting_memo`, `debt_capacity_workbook`, `terms_protections_review`, `covenant-liquidity`, `qa-review`, or `distressed-watch`.
3. Build the borrower snapshot: business model, revenue drivers, margin structure, cyclicality, concentration, competitive position, management, sponsor, and key risks.
4. Establish the earnings base: reported EBITDA, adjusted EBITDA, normalized EBITDA, lender-after-haircut EBITDA, and covenant EBITDA only when the governing definition is available.
5. Analyze cash conversion and repayment capacity: FCF, working capital, capex, cash taxes, interest, amortization, liquidity, and maturity runway.
6. Build lender and downside cases: stress the drivers that could actually break the credit and identify the first covenant, liquidity, cash-flow, borrowing-base, customer, margin, capex, or maturity breakpoint.
7. Assess structure, covenants, collateral, and recovery: facility terms, tranche priority, lien package, covenant headroom, sponsor support, EV cushion, liquidation value, and loss path.
8. Rate risk and recommend: for an initial screen, lead with a diligence-stage decision; for an underwritten credit view, use proceed / decline / proceed-with-conditions as appropriate. Include required conditions, monitoring package, and exact open items needed to upgrade confidence.

For detailed workflow, read [underwriting-playbook.md](references/underwriting-playbook.md). For risk taxonomy, read [risk-taxonomies.md](references/risk-taxonomies.md).

## Deliverable Modes

Choose the artifact mode from the decision question and calculation depth:

- `initial_credit_screen`: public-source or incomplete-information go / no-go / diligence view. The normal hero is a polished standalone HTML lender underwriting memo, and the maximum posture is `screening-only` or `not-committee-ready` when decision-gating facts are absent. Use a diligence-stage recommendation such as `proceed-to-diligence-only`, `pass-on-diligence`, or `decline`; do not use `proceed-with-conditions`, which implies a supportable credit structure.
- `underwriting_memo`: fuller lender decision memo with sufficient private diligence and source-backed lender cases. The normal hero is a polished standalone HTML lender underwriting memo, with a workbook companion when calculations need reuse.
- `debt_capacity_workbook`: calculation-heavy debt sizing, liquidity, covenant, or downside analysis supported by structured inputs. The normal hero is an XLSX workbook, with a concise standalone HTML companion when useful.
- `terms_protections_review`: structure, collateral, covenant, and lender-protection analysis. Use HTML for narrative decisioning or a workbook when calculated scenarios are central.

For acquisition financing where only target-company public information is available and the borrower perimeter includes an acquirer, sponsor vehicle, or combined company, state prominently: **No combined-borrower underwriting or hold-size conclusion is supportable without acquirer/parent financials, sources and uses, and committed debt terms.** Any displayed target-only debt figure must be labeled an `illustrative standalone cash-interest screening ceiling`, not supportable acquisition-financing capacity or a recommended lender hold.

Disclosed committed acquisition financing supports transaction-execution context or deal-certainty discussion only. Unless its terms and combined-borrower effects are available and underwritten, do not present it as a credit attraction, repayment support, lender protection, or basis for proceeding.

If a public-source screen displays an illustrative debt ceiling, include at least one cash-flow downside dimension as well as financing sensitivity, for example an unlevered FCF haircut alongside cash interest rate or minimum coverage threshold. A debt-level table at a single assumed rate and coverage threshold is not a sufficient downside case.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: borrower snapshot, earnings base, downside/liquidity, covenants/collateral, and committee synthesis. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Artifact Contract

Default output for `initial_credit_screen`, `underwriting_memo`, and narrative `terms_protections_review` work: `extended_analysis` in the form of a polished standalone HTML lender underwriting memo owned by this skill under `../../references/html-artifact-standard.md`. Do not route an ordinary lender underwriting HTML memo through `dashboard-builder`. Use workbook-first output for `debt_capacity_workbook` or when reusable calculations are central. Use concise chat only for explicit early go/no-go triage, a quick screen, or a narrow update to an existing credit package.

Request classification:

| Type | Default output |
|---|---|
| `initial_credit_screen` | standalone HTML credit screen with go / no-go / diligence asks unless the user explicitly requests a quick screen |
| `underwriting_memo` | standalone HTML full credit memo with recommendation and conditions |
| `debt_capacity_workbook` | workbook-first debt capacity, downside, and liquidity analysis |
| `terms_protections_review` | standalone HTML or workbook structure, pricing, covenants, collateral, and negotiation issues |
| `covenant-liquidity` | covenant bridge, liquidity runway, downside triggers |
| `qa-review` | issue log, missing support, broken logic, readiness verdict |
| `distressed-watch` | default / amendment / recovery readout and escalation plan |

Unless the user asks otherwise, include:

1. `Recommendation and posture`
2. `Borrower snapshot`
3. `Sources and evidence base`
4. `Transaction overview`
5. `Earnings base and QoE view`
6. `Credit metrics`
7. `Lender case and downside`
8. `Covenants, liquidity, and debt service`
9. `Collateral, recovery, and sponsor support`
10. `Key risks and mitigants`
11. `Required Before Credit Committee` as one prioritized gating table, plus monitoring only when the approval path is sufficiently developed
12. `Decision summary and source/evidence appendix`

Do not append a duplicate diligence-gaps module after the memo has already presented the committee gates.

End with one posture label: `screening-only`, `diligence-grade`, `committee-ready-with-caveats`, `not-committee-ready`, or `decline-recommended`. Read [output-templates.md](references/output-templates.md) for templates, monitoring formats, self-checks, and examples.

Read [../../references/output-depth-policy.md](../../references/output-depth-policy.md) before shortening; default to `extended_analysis`.

## Source And Evidence Posture

Do not begin with a broad data request. First inspect the prompt, attachments, prior outputs, callable connected routes, and user-provided exports. If the user references a VDR, model, drive folder, email thread, data room, internal memo, or workspace source, use a scoped runtime route when exposed; otherwise request an export before public web search.

Use the best available source tier:

1. user-provided materials and current conversation context
2. callable connected routes / institutional-source exports
3. transaction documents and diligence files
4. public primary or near-primary sources
5. reputable secondary sources for context only

Maintain material-claim classification using the shared evidence labels from `financial-source-of-truth`: `fact_primary`, `fact_secondary`, `management_claim`, `seller_claim`, `third_party_estimate`, `internal_estimate`, `assumption`, `inference`, `opinion`, and `unsupported`. In the reader-facing HTML memo, translate that taxonomy into natural language such as `SEC-reported`, `management forecast`, `illustrative assumption`, `analyst calculation`, or `not provided`; do not render raw internal taxonomy pills inline in the narrative or core tables. Preserve formal labels in the evidence appendix, manifest, or internal support artifacts where useful for auditability.

Ask the user for more only when a missing item materially changes the recommendation, covenant/liquidity conclusion, or downside loss view. Ask for the exact missing document or field, not a generic data dump. Read [source-and-evidence.md](references/source-and-evidence.md) for full hierarchy, freshness rules, conflict handling, and ask-for-more format.

## Validated Handoffs

Producer contracts:
- `private_credit_underwriting_to_covenant_package_analyzer` -> `covenant-package-analyzer`. Schema: `../../schemas/private_credit_underwriting_to_covenant_package_analyzer.schema.json`. Validate with `../../scripts/validate_handoff_payload.py private_credit_underwriting_to_covenant_package_analyzer handoffs/private_credit_underwriting_to_covenant_package_analyzer.json` before another skill imports it.
- `private_credit_underwriting_to_distressed_recovery_waterfall` -> `distressed-recovery-waterfall`. Schema: `../../schemas/private_credit_underwriting_to_distressed_recovery_waterfall.schema.json`. Validate with `../../scripts/validate_handoff_payload.py private_credit_underwriting_to_distressed_recovery_waterfall handoffs/private_credit_underwriting_to_distressed_recovery_waterfall.json` before another skill imports it.

Intake validation:
- From `capital-markets-issuance`: require `capital_markets_issuance_to_private_credit_underwriting` and run `../../scripts/validate_handoff_payload.py capital_markets_issuance_to_private_credit_underwriting handoffs/capital_markets_issuance_to_private_credit_underwriting.json` before importing fields into this skill.

## Script Map

Use `scripts/calculate_credit_metrics.py` when the user provides tabular financials and optional debt terms. It produces first-pass leverage, coverage, liquidity, covenant-headroom, warning, and report outputs.

Recommended command from this skill directory:

```bash
python3 scripts/calculate_credit_metrics.py \
--financials assets/borrower_financials_template.csv \
--terms assets/debt_terms_template.json \
--outdir /tmp/private_credit_metrics
```

Treat script output as a calculation aid, not a replacement for credit judgment. Read [credit-metrics.md](references/credit-metrics.md) before interpreting script output in a real memo.

## HTML Evidence Readiness

For any polished standalone HTML lender memo, follow `../../references/html-artifact-standard.md`. Give material facts, calculations, assumptions, and recommendations readable point-of-use citation support; keep repeated source badges subordinate to prose readability. Use reader-facing evidence language in the memo body rather than raw internal classification pills. When cited metrics come from a companion workbook, identify the workbook cell or range through `model_citations` / `model_citations_path` when available.

For committee, lender, senior, client, board, or external posture, unknown source IDs, unsupported material numbers, missing calculation basis, unmarked target-only capacity screens, or unresolved combined-borrower gaps are blocking readiness gaps. Fix them, cap the posture, or surface the missing support explicitly; do not call the output committee-ready while they remain.

Before delivery, render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin. Inspect the opening recommendation, lender case and downside, committee gates, and source appendix. Repair duplicated dashboard-style modules, clipped tables, or misleading capacity language before returning the artifact.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: normally a polished standalone HTML lender underwriting memo, an XLSX debt-capacity / lender-case workbook when reusable calculations are central, a requested native deck/document, a generated folder, or a justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map

Load references selectively:

| Reference | Read when |
|---|---|
| [source-and-evidence.md](references/source-and-evidence.md) | deciding source hierarchy, evidence labels, stale-data treatment, public-source fallback, source conflicts, or targeted data requests |
| [underwriting-playbook.md](references/underwriting-playbook.md) | producing a full credit memo, credit screen, committee readout, borrower snapshot, earnings base, lender case, or recommendation framework |
| [credit-metrics.md](references/credit-metrics.md) | calculating ratios, debt capacity, EBITDA bases, covenant headroom, downside cases, warning signs, or interpreting script output |
| [terms-covenants-collateral.md](references/terms-covenants-collateral.md) | reviewing term sheets, facility structure, covenants, collateral, lien priority, sponsor support, recovery, or distressed loss paths |
| [risk-taxonomies.md](references/risk-taxonomies.md) | building risk registers, severity labels, mitigants, risk ratings, watchlist triggers, or monitoring escalation logic |
| [output-templates.md](references/output-templates.md) | drafting full memos, quick screens, monitoring updates, data requests, QA reviews, self-checks, or reusable table formats |
| [examples.md](references/examples.md) | needing compact example language for screens, debt-sizing conclusions, covenant/liquidity summaries, distressed-watch updates, or decline recommendations |
| [investment-banking-integrations.md](references/investment-banking-integrations.md) | coordinating upstream/downstream handoffs with other Investment Banking skills |
| [../../references/handoff-contracts.md](../../references/handoff-contracts.md) | consuming `capital_markets_issuance_to_private_credit_underwriting` or exporting covenant/restructuring handoff packages with exact field names |
| [../../references/output-depth-policy.md](../../references/output-depth-policy.md) | deciding whether a quick screen or abbreviated update is justified; defaulting to `extended_analysis` |

Referenced files: 13

scenario-sensitivity-generator14.8 KB

View saved version →

---
name: scenario-sensitivity-generator
description: create scenario, sensitivity, stress-test, and breakeven frameworks for ib analyses. use when the user asks to pressure-test model drivers, cases, downside paths, or decision thresholds. do not build base models.
---

# Scenario & Sensitivity Generator

## Skill Configuration

### Common Skill Instructions

## Relevant Dependency Categories

- `Models, Workbooks & Templates`
- `Market Data & Public Sources`
- `Deal Materials`
- `Process Updates`

## Deliverable Intake

When this skill owns a new substantive user-facing artifact, before source gathering, analysis, modeling, or rendering load `../../references/deliverable-intake-policy.md` and perform its adaptive `request_user_input` preflight for materially unresolved preferences. For a scenario or sensitivity analysis with an unresolved surface, offer `Excel sensitivity workbook (Recommended)`, `Polished HTML sensitivity summary`, and `Inline screening view`. Default to the banker-readable workbook when intake is not required or a non-interactive analysis run must apply a default. When invoked as a downstream support step within an already scoped workflow, inherit resolved preferences and do not re-prompt.

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. For substantive sensitivity work, the normal hero deliverable is a polished banker-readable workbook with an insight-led first visible tab. Create a standalone HTML sensitivity summary only when the user explicitly requests HTML or a narrative companion; keep the workbook as the calculation source of truth when one exists. CSV, JSON, Markdown, run logs, manifests, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Plugin Workflow Routing

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing workbook, an explicitly requested standalone HTML sensitivity summary, native deck/document, or clear first-read package.

## Purpose

Turn an existing IB transaction model or analysis into a banker-ready sensitivity pack. Preserve the base model, change only explicit drivers, quantify what moved, identify what breaks first, and translate the output into deal actions.

This is not an FP&A scenario-planning skill. It is for transaction sensitivities: valuation, debt capacity, covenant headroom, financing terms, merger-model outputs, downside/breakage, sponsor returns, restructuring recoveries, and target backsolves.

## Use This Skill When

- The user has an existing DCF, comps, LBO, merger model, financing case, covenant model, credit case, or recovery waterfall and wants to stress outputs.
- The decision depends on price, valuation range, leverage, covenant cushion, liquidity, financing cost, dilution, accretion/dilution, IRR/MOIC, or recovery value.
- The user asks for base/upside/downside cases, a sensitivity table, a target backsolve, a break-even, a breakpoint, or a “what breaks first?” analysis.

Do not use this skill to build the underlying model. Route model construction to `dcf-model-builder`, `comps-valuation`, `lbo-model-build`, `merger-model-builder`, `three-statement-model-builder`, `covenant-package-analyzer`, `private-credit-underwriting`, `capital-markets-issuance`, or `distressed-recovery-waterfall` as appropriate.

## Fast Workflow

1. **Route the request.** Pick the transaction mode using `references/transaction-mode-router.md`: valuation, debt capacity, covenant headroom, financing terms, merger model, downside, returns, restructuring, or target backsolve.
2. **Classify the sensitivity basis.** Identify the baseline as `supplied model`, `corrected scenario-ready base`, `audit-indicative diagnostic overlay`, or `not suitable for sensitivity reliance`. Record embedded corrections or adjustments and unresolved items excluded from the analysis. If known material errors would contaminate the displayed base without an expressly labeled diagnostic or corrected overlay, stop and route to the relevant model or audit skill.
3. **Check model readiness and define the artifact.** Confirm the base has clear source dates, editable drivers, stable formulas, visible checks, and traceable output metrics. For substantive analysis, use a workbook sensitivity pack organized around the decision question: valuation range, debt/covenant stress, financing terms, merger-model sensitivity, LBO returns, downside/breakage, restructuring recovery, or target backsolve.
4. **Create the overlay.** List each changed driver by case using `references/scenario-overlay-contract.md`. Separate source facts, model-derived values, banker assumptions, market proxies, and placeholders.
5. **Materialize tables.** Use `scripts/materialize_sensitivity_pack.py` for deterministic starter tables across valuation, debt capacity, covenant headroom, financing terms, merger model, downside, and returns. See `references/deterministic-materializer.md`.
6. **Interpret results.** Explain what moved, why it moved, the key breakpoint, and the action the deal team should take.
7. **Verify and hand off cleanly.** Check that base sensitivity cells reconcile to the selected basis, render and visually inspect the workbook's first-read and material analysis tabs, and state the calculation-integrity and decision-readiness posture separately. Route an independent model audit to `model-audit-tieout` when requested or when material source/model reliability must be independently tested; route client decks or memos to `pitch-deck-builder`, `memo-builder`, and final `ib-deck-qc`.

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: base-model handoff, scenario design, sensitivity math, output grids, and QA. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Artifact Contract

Produce these sections unless the user asks for a different format:

Default reader-facing artifact: a polished banker-readable workbook with an insight-led first visible tab following `../../references/workbook-first-tab-standard.md`. Use chat only for narrow breakpoints, quick follow-ups, or a cover note for a richer artifact. Use a standalone HTML companion only when explicitly requested.

- **Executive summary:** headline conclusion, most sensitive drivers, first breakage point, recommended deal action.
- **Sensitivity basis and readiness:** classify the baseline as `supplied model`, `corrected scenario-ready base`, `audit-indicative diagnostic overlay`, or `not suitable for sensitivity reliance`; state embedded corrections, excluded unresolved issues, source/as-of dates, earnings basis, calculation integrity, and decision readiness.
- **Case summary:** base/upside/downside/stress outputs for the relevant transaction metrics.
- **Assumption overlay:** exact driver changes, timing, provenance, controllability, owner, and caveat.
- **Sensitivity tables:** compact one-way, two-way, or tornado-style outputs that directly answer the transaction question.
- **Breakpoints and triggers:** thresholds for price, leverage, covenant cushion, liquidity, rates/spreads, dilution, accretion/dilution, IRR/MOIC, or recoveries.
- **Driver-to-action table:** driver, impact, controllability, deal action, owner, timing, expected protection or upside.
- **Target backsolve:** target metric, locked constraints, allowed levers, required path, feasibility label, and what must be true.
- **Transaction implications memo:** what the client, sponsor, lender, committee, or deal team should do next.

## Deterministic Resources

Use these local assets when the user needs structured outputs or when another skill/model should consume the scenario work:

- `scripts/materialize_sensitivity_pack.py`: creates a deterministic workbook-first sensitivity scaffold with backing CSV/JSON support files.
- `assets/sensitivity_pack_modes.json`: canonical mode definitions for `valuation`, `debt_capacity`, `covenant_headroom`, `financing_terms`, `merger_model`, `downside`, and `returns`.
- `assets/scenario_overlay_template.csv`: overlay schema for driver changes.
- `assets/sensitivity_matrix_template.csv`: generic sensitivity table schema.
- `assets/target_backsolve_template.csv`: target-backsolve schema.
- `assets/trigger_metrics_template.csv`: trigger and contingency schema.
- `assets/deal_action_register_template.csv`: action register schema.

Recommended command:

```bash
python3 scripts/materialize_sensitivity_pack.py \
--mode all \
--entity ExampleCo \
--transaction-version "Base model v1" \
--output-dir /tmp/exampleco_sensitivity_pack
```

## Quality Rules

- Keep scenarios decision-useful: change a few meaningful drivers, not dozens of cosmetic assumptions.
- Show absolute outputs, not only deltas.
- Label EBITDA, earnings, covenant EBITDA, cash, debt, share count, FX, and market-data bases clearly.
- Do not mix as-of dates without flagging the mismatch.
- Do not present covenant headroom without covenant definitions or a clearly labeled proxy.
- Do not call illustrative outputs decision-grade.
- Do not hide formula changes inside scenario cases.
- Do not describe a corrected scenario-ready base or audit-indicative overlay as the unmodified source model.
- Show embedded base corrections and material excluded items prominently on the first-read tab and in the final response.
- Always name the first breakpoint and the action it triggers when downside, financing, covenant, merger, returns, or restructuring risk matters.

## Workbook Evidence Readiness

The workbook is the analytical source of truth for substantive sensitivity work. For internal transaction review, client, committee, board, lender, or external postures, every material input, modeled output, breakpoint, scenario adjustment, backsolve, and action recommendation must be traceable to a workbook cell/range, source document location, or explicit assumption label. Use readable source IDs and as-of dates in the source/assumption ledger; use `model_citations` or an equivalent cell/range citation ledger when workbook-derived outputs feed another artifact.

Keep `Calculation integrity` distinct from `Decision readiness`. A sensitivity grid can calculate correctly while the analysis remains only an internal screen because the base model, financing terms, synergy support, covenant definitions, forecast support, share count, purchase accounting, or integration-cost treatment is incomplete.

For a merger or accretion/dilution sensitivity pack, require a formula-driven tie-out of the base sensitivity cell to the selected EPS bridge, breakeven synergy and financing-cost backsolves when relevant, and prominent disclosure of whether the financing and synergy inputs are sourced, assumed, or corrected for scenario use. Do not leave the sensitivity-basis classification only on a later detail or checks tab.

Before delivery, render and visually inspect the first visible tab and each material sensitivity, scenario-overlay, trigger/action, checks, and source/assumption view. State explicitly when formulas and cached outputs were inspected without native Excel recalculation.

## Optional HTML Companion

When the user explicitly requests HTML, keep this skill as the analytical owner and produce a polished standalone sensitivity summary following `../../references/html-artifact-standard.md`, grounded in workbook cell/range provenance and source/assumption tie-outs. Keep the workbook as the hero deliverable for model-heavy sensitivity work unless the user explicitly selects a narrative-only surface. Do not route an ordinary sensitivity pack or HTML sensitivity summary through `dashboard-builder`, create a dashboard render contract, or force the analysis into fixed dashboard modules.

In an HTML companion, cite workbook-derived scenario outputs, target-backsolve cells, sensitivities, or bridge values to exact cell/range records wherever available. Render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery. Do not expose raw JSON, Markdown report files, model-citation ledgers, or run logs as the default final artifact.

## Deliverable Format Standard

Follow `../../references/deliverable-format-policy.md` before creating files. Always identify the hero deliverable first: ordinarily the XLSX sensitivity workbook; an explicitly requested standalone HTML sensitivity summary; native deck/document; generated folder; or justified chat-only answer. Do not create Markdown report files as the default rich deliverable. Do not present JSON contracts, manifests, run logs, or handoff payloads as the main user-facing output. Keep CSV files as backing ledgers/import layers unless the user explicitly asks for CSV, and explain whether each CSV contains new analysis or only support data.

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map

- `references/sensitivity-taxonomy.md`: detailed IB driver taxonomy, standard tables, breakpoints, and failure modes.
- `references/transaction-mode-router.md`: mode selection and routing rules.
- `references/deterministic-materializer.md`: how to use and extend the deterministic materializer.
- `references/scenario-overlay-contract.md`: overlay schema for workbook and skill handoffs.
- `references/target-backsolve-rubric.md`: feasibility labels and execution-realism checks.
- `references/output-templates.md`: trigger metrics, action register, QA checklist, and handoff outputs.
- `references/ib-integration.md`: ownership matrix and adjacent-skill boundaries.
- `../../references/workbook-first-tab-standard.md`: required for substantive workbook sensitivity packs.
- `../../references/html-artifact-standard.md`: read only when a standalone HTML sensitivity companion is explicitly requested or selected.

Referenced files: 15

three-statement-model-builder11.6 KB

View saved version →

---
name: three-statement-model-builder
description: Use when building integrated three-statement operating model exports with linked IS, BS, CF, drivers, checks, scenarios, or formula templates.
---

# Three Statement Model Builder

## Skill Configuration

### Common Skill Instructions

## Relevant Dependency Categories

- `Models, Workbooks & Templates`
- `Deal Materials`
- `Market Data & Public Sources`

## Deliverable Intake

For broad transaction workflow prompts, read `../../references/plugin-routing-playbook.md` before selecting or sequencing skills. Use this skill as lead only in the workflows named there; when acting as support, preserve validated handoff fields, source IDs, routing metadata, and the artifact hierarchy so the hero deliverable remains the banker-facing workbook, an explicitly requested standalone HTML companion, native deck/document, or clear first-read package.

Use for linked IS, BS, CF, working capital, PP&E/D&A, debt, cash sweep, liquidity, covenants, scenarios, sensitivities, and checks. Do not use for audit, LBO, DCF/comps/merger, memo, or deck work.

## Artifact Hierarchy

Follow `../../references/artifact-manifest-standard.md` before returning generated files. For substantive three-statement modeling work, the normal hero deliverable is a polished banker-readable workbook with an insight-led first visible tab. Create a standalone HTML operating-model summary only when the user explicitly requests HTML or a narrative companion; the workbook remains the model source of truth. CSV, JSON, Markdown, run logs, manifests, model-citation ledgers, and handoff payloads are support artifacts unless the user explicitly asks for them. Final responses should lead with the hero deliverable, then companion deliverables, then support artifacts in one short sentence if useful.

## Workflow
1. Classify: template, partial-context screen, full financial package, deterministic export, formula workbook, or handoff.
2. Read only needed references; usually `plan-schema.md`, `output-spec.md`, and integrations.
3. Create or locate `plan.json`; preserve raw files, formulas, assumptions, and labels.
4. Validate, run the requested export, read the run log, and build the first-read workbook view around operating drivers, cash conversion, liquidity, downside pressure, source posture, and open diligence.
5. Keep calculation integrity and decision readiness separate: balance-sheet, cash and formula checks may be `OK` while source readiness remains `OPEN` or `screen-grade`.
6. Render and visually inspect the workbook summary, driver/assumptions, scenario, statements, sources and checks tabs before reporting artifacts.
7. Hard failures mean `not-decision-ready`. Placeholder- or analyst-assumption-driven conclusions mean open with `Screen-grade only; operating, liquidity, or covenant assumptions require validation.`

## Sub-agent decomposition

For complex medium/large requests, use sub-agents where available; otherwise emulate the split as named workstreams. Suggested lanes: source support, historical normalization, operating drivers, balance sheet/cash flow, scenarios, and QA. Keep this skill as the lead: reconcile conflicts, source labels, assumptions, open items, final QA, and the user-facing answer.

## Artifacts
`deterministic_export`: write to the selected `--output-dir` (default `./output` from the caller's current working directory). The hero deliverable is `model.xlsx`, opening on a banker-readable `Cover`, `Executive Summary`, or `Dashboard` tab per `../../references/workbook-first-tab-standard.md`. Agent-facing support artifacts are `plan.json`, `run_log.json`, `model_citations.json`, and `manifest.json`. Write legacy `report.md` only when explicitly requested with `--write-report-md`.

`banker_formula_workbook`: formula workbook plus separate run log, `model_citations.json`, and manifest; not arbitrary formula generation. Any renamed, restyled, or otherwise substituted human-deliverable workbook must receive a citation ledger generated against that exact workbook; do not present a deterministic-control ledger as evidence for a different hero workbook.

## Validated Handoffs

## Workbook Evidence Readiness

The workbook is the analytical source of truth. For senior, client, committee, board, lender, or external postures, every material input and derived output must be traceable through readable source/assumption notes and `model_citations` / `model_citations_path` records down to the delivered workbook sheet/cell or range where available.

Unknown source IDs, missing hero-workbook cell provenance for headline revenue, EBITDA, FCF, liquidity or leverage outputs, unsupported financing or covenant inputs, unexplained working-capital or capex improvement, or citation records pointing to a different workbook than the delivered hero artifact are blocking readiness gaps. Fix them, cap posture at `screen-grade`, or surface them explicitly; do not call a workbook senior/client/committee/board/external-ready while they remain.

The first visible tab must clearly distinguish `Calculation integrity` from `Decision readiness`; do not leave that distinction only on a later checks sheet. A model may balance and pass formula checks while still being only an internal screen because operating assumptions, inventory/capex diligence, debt capacity, revolver availability, or covenant definitions are unresolved.

For public-source strategic alternatives work, make the operating driver bridge, cash conversion, leverage or liquidity trajectory, and linked downside pressure visible in the first-read view. If debt documents or covenant definitions are not provided, label any cash sweep, debt draw, headroom, or minimum-cash construct as illustrative and do not show an unqualified overall `OK`.

Before delivery, visually inspect the first visible tab, driver/control view, scenario view, statement schedules, sources/readiness view, and checks view. Search all visible status labels, including `Model status`, `Overall`, `QA posture`, `Calculation integrity`, and `Decision readiness`; no sheet may display an unqualified overall `OK` when decision readiness is `screen-grade`, `partial`, or `not-decision-ready`. Keep mechanical outcomes under `Calculation integrity` and make the reliance posture consistent with the first-read summary. Record formula-error scan outcomes as an explicit result or match count in the run log rather than referring only to transient console output.

## Optional HTML Companion

When the user explicitly requests an HTML report or visual operating-model summary, keep this skill as the analytical owner and produce a polished standalone HTML companion following `../../references/html-artifact-standard.md`. Do not route an ordinary three-statement-model HTML summary through `dashboard-builder`, create a dashboard render contract, or force workbook-derived operating and liquidity findings into fixed dashboard modules.

In that HTML companion, cite workbook-derived financial-statement, ratio, scenario, liquidity and forecast outputs to exact cells/ranges in the delivered workbook through `model_citations` or `model_citations_path` wherever available. Do not collapse model outputs to a generic `model-output` citation when the workbook location is known. Render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.

Do not expose raw JSON, Markdown report files, model-citation ledgers, or run logs as the default final artifact.

## Deliverable Format Standard

Final responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.

## Reference Map
- `../../references/workbook-first-tab-standard.md`: required first-read workbook decision view.
- `../../references/html-artifact-standard.md`: optional standalone HTML companion and visual QA standard.
- `plan-schema.md`, `output-spec.md`, `banker-formula-workbook-contract.md`: contracts.
- `model-math.md`, `model-architecture.md`, `forecast-judgment-guide.md`: mechanics.
- `integrity-controls.md`, `industry-playbooks.md`, `output-and-review.md`, `qa-checks.md`: review.

## Runtime Artifact Path

Default deterministic outputs are `model.xlsx`, `manifest.json`, `run_log.json`, and `model_citations.json`; formula mode emits `banker_formula_workbook.xlsx` with the same shared manifest and citation ledger. The workbook is the primary human deliverable and must open on `Cover`, `Executive Summary`, or `Dashboard`. Run logs, plans, and `model_citations.json` are support artifacts; any narrative companion must cite statement, ratio, scenario, forecast, liquidity and leverage outputs through records that point to the exact delivered workbook. Senior-ready status requires source-backed operating assumptions, workbook/cell provenance, checks, and no unresolved liquidity or covenant evidence gaps.

Referenced files: 25

user-context5.85 KB

View saved version →

---
name: user-context
description: Initialize, inspect, save, update, forget, export, or explicitly reset the Investment Banking plugin's local user context, source setup, or optional automation setup. Use only when the user explicitly asks to manage Investment Banking saved preferences, source pointers, context storage, or recurring automation.
---

# Investment Banking User Context

This skill owns the Investment Banking plugin's local user-context storage foundation and explicit-only onboarding contract. It is intentionally narrow: it can initialize, inspect, save, update, forget, export, or explicitly reset local context, interpret the next onboarding action, guide the four-step intro/defaults -> connectors/plugins -> automation -> hero-workflow flow, and configure user-approved automations. Ordinary Investment Banking workflows do not invoke this skill by default; saved context and source setup are optional accelerators, not a pre-answer gate.

## State Files

Store Investment Banking state under:

```text
$CODEX_HOME/state/plugins/openai-monorepo/investment-banking/
```

The storage foundation owns only:

```text
user-context.md
onboarding-state.json
```

Do not create `category-state.json`.

## Initialize

When the user explicitly asks to initialize Investment Banking user context, run `python3 skills/user-context/scripts/init_user_context_state.py` with the shell working directory set to this plugin's root. Set the working directory before the first attempt; do not probe alternate relative paths.

The initializer creates missing state files from bundled templates and preserves existing files unless the user explicitly requests overwrite behavior.

## Inspect

When the user explicitly asks to inspect saved Investment Banking context, run `python3 skills/user-context/scripts/user_context_preflight.py` with the shell working directory set to this plugin's root. Set the working directory before the first attempt; do not probe alternate relative paths.

Use the returned read-only JSON envelope to summarize initialization status, onboarding status, the deterministic `next_action`, the lightweight `onboarding_progress`, and empty memory categories. Treat `user-context.md` as user-editable durable context and `onboarding-state.json` as operational scaffolding.

## Save Update Or Forget

When the user explicitly asks to remember, save, update, forget, export, or apply durable Investment Banking preferences or source pointers, follow `skills/user-context/references/plugin-memory.md` from the plugin root. Store reusable user-approved context in `user-context.md`; keep live mandate details and operational connector state out. Initialize missing state only when a save needs persistence.

## Onboarding

When the user explicitly asks to set up, resume, defer, quiet, or complete Investment Banking onboarding, follow `skills/user-context/references/onboarding.md` from the plugin root. Use the inspection helper's `next_action` as the current step and render its `copy_ref` template substantially verbatim. Keep the visible flow to four steps: intro and lightweight defaults, connectors and plugins, one optional automation, then a three-option hero-workflow chooser. Capture broader durable preferences only when the user explicitly asks or supplies them naturally.

## Source Category Vocabulary

`skills/user-context/plugin-author-config/source-category-config.json` reserves static Investment Banking source category ids, labels, and preference hints for explicit setup/status work. The inspection helper exposes those categories as `source_category_plan` and echoes any setup-owned routes already saved under `onboarding-state.json` `connector_confirmation`. Ordinary workflow skills use the router's cross-skill runtime contract and `.app.json` categories instead of reading this helper first. Use `skills/user-context/references/source-category-runtime.md` from the plugin root for the source-setup boundary. Inspection does not prove source readiness, select routes, inspect connectors, or create `category-state.json`.

## Optional Automations

`skills/user-context/plugin-author-config/automation-config.md` defines the small author-owned automation menu. When the user explicitly asks for a recurring Investment Banking workflow or accepts the optional onboarding automation step, follow `skills/user-context/references/automation.md` from the plugin root. Do not create, update, pause, resume, or remove automations during ordinary workflow work.

## Reset

When the user explicitly asks to reset Investment Banking user context, run `python3 skills/user-context/scripts/reset_user_context_state.py` with the shell working directory set to this plugin's root. Set the working directory before the first attempt; do not probe alternate relative paths.

The reset helper moves active state files into a timestamped sibling backup directory before clearing them from the active state directory.

## Current Boundary

- The Investment Banking router and focused workflow skills do not run `scripts/user_context_preflight.py` during ordinary workflow work.
- Do not initialize state merely because another Investment Banking skill runs.
- Do not mutate state when running the read-only inspection helper.
- Do not inspect apps, connectors, plugins, `.app.json`, or source readiness during saved-context inspection.
- During user-approved explicit Source Setup, follow `skills/user-context/references/source-category-runtime.md` from the plugin root.
- During user-approved explicit automation setup or maintenance, follow `skills/user-context/references/automation.md` from the plugin root.
- Do not invoke onboarding unless the user explicitly asks for saved-context setup or management.
- Do not create or modify automations unless the user explicitly asks or accepts the optional automation setup step.
- Do not add, read, or migrate `category-state.json`. The reset helper may back up and clear an older copy during an explicit reset.

Referenced files: 14

Package details

Publisher declarations from the archived package. These are separate from our research and the live service's terms.

Package license: Proprietary
Package author: OpenAI
Keywords: investment-banking, factset, lseg, s&p global, pitchbook, moody's, third bridge, daloopa, quartr, m&a, valuation, pitch-deck, capital-markets, levfin, lbo, cim, teaser, vdr, datasite, data-room, buyer-universe, nda-tracker, process-tracker, debt-capacity, dashboard, html-dashboard, diligence-dashboard

Declared capabilities

Interactive
Read
Write

Package observed Oct 2, 2026.

.codex-plugin/plugin.json

Technical details

First seen: Sep 30, 2026 · 22:02 UTC
Last seen: Oct 2, 2026 · 06:00 UTC
Collection status: Collected

Plugin_68c39ea2b3888191827c933053f3a1d1

Download plugin data (JSON)