Update to Investment Banking

{
  "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.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 298
    },
    {
      "relative_path": "assets/examples/micro_example_claims_ledger.csv",
      "size_in_bytes": 1466
    },
    {
      "relative_path": "assets/examples/micro_example_diligence_questions.csv",
      "size_in_bytes": 2065
    },
    {
      "relative_path": "assets/examples/micro_example_evidence_checklist.csv",
      "size_in_bytes": 922
    },
    {
      "relative_path": "assets/examples/micro_example_red_flag_register.csv",
      "size_in_bytes": 979
    },
    {
      "relative_path": "assets/examples/micro_example_workplan.csv",
      "size_in_bytes": 775
    },
    {
      "relative_path": "assets/templates/claims_ledger.template.csv",
      "size_in_bytes": 322
    },
    {
      "relative_path": "assets/templates/diligence_questions.template.csv",
      "size_in_bytes": 348
    },
    {
      "relative_path": "assets/templates/evidence_checklist.template.csv",
      "size_in_bytes": 299
    },
    {
      "relative_path": "assets/templates/plan.example.json",
      "size_in_bytes": 1011
    },
    {
      "relative_path": "assets/templates/red_flag_register.template.csv",
      "size_in_bytes": 197
    },
    {
      "relative_path": "assets/templates/workplan.template.csv",
      "size_in_bytes": 192
    },
    {
      "relative_path": "references/analysis-playbook.md",
      "size_in_bytes": 13477
    },
    {
      "relative_path": "references/citations.md",
      "size_in_bytes": 5149
    },
    {
      "relative_path": "references/claims-taxonomy.md",
      "size_in_bytes": 7697
    },
    {
      "relative_path": "references/data-requests-library.md",
      "size_in_bytes": 5791
    },
    {
      "relative_path": "references/downstream-handoffs.md",
      "size_in_bytes": 3728
    },
    {
      "relative_path": "references/evidence-framework.md",
      "size_in_bytes": 6266
    },
    {
      "relative_path": "references/examples.md",
      "size_in_bytes": 3455
    },
    {
      "relative_path": "references/metric-definitions.md",
      "size_in_bytes": 8469
    },
    {
      "relative_path": "references/output-schemas.md",
      "size_in_bytes": 11003
    },
    {
      "relative_path": "references/overlay-consumer-retail.md",
      "size_in_bytes": 3040
    },
    {
      "relative_path": "references/overlay-financial-services.md",
      "size_in_bytes": 2994
    },
    {
      "relative_path": "references/overlay-fuel-convenience-site-retail.md",
      "size_in_bytes": 4941
    },
    {
      "relative_path": "references/overlay-healthcare.md",
      "size_in_bytes": 2884
    },
    {
      "relative_path": "references/overlay-industrials.md",
      "size_in_bytes": 2933
    },
    {
      "relative_path": "references/overlay-local-field-services.md",
      "size_in_bytes": 4370
    },
    {
      "relative_path": "references/overlay-real-assets.md",
      "size_in_bytes": 3939
    },
    {
      "relative_path": "references/overlay-real-estate-heavy.md",
      "size_in_bytes": 2870
    },
    {
      "relative_path": "references/overlay-saas.md",
      "size_in_bytes": 2805
    },
    {
      "relative_path": "references/overlay-staffing-labor-services.md",
      "size_in_bytes": 4665
    },
    {
      "relative_path": "references/persona-overlays.md",
      "size_in_bytes": 10611
    },
    {
      "relative_path": "references/question-engine.md",
      "size_in_bytes": 5738
    },
    {
      "relative_path": "references/reconciliation-playbooks.md",
      "size_in_bytes": 4247
    },
    {
      "relative_path": "references/red-flag-catalog.md",
      "size_in_bytes": 13847
    },
    {
      "relative_path": "references/report-template.md",
      "size_in_bytes": 9033
    },
    {
      "relative_path": "references/security-legal-dd.md",
      "size_in_bytes": 1908
    },
    {
      "relative_path": "scripts/run_plan.py",
      "size_in_bytes": 15189
    },
    {
      "relative_path": "scripts/validate_outputs.py",
      "size_in_bytes": 11568
    },
    {
      "relative_path": "scripts/validate_plan.py",
      "size_in_bytes": 5193
    }
  ],
  "skill_md_contents": "---\nname: cim-teardown\ndescription: 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.\n---\n\n# CIM-Teardown\n\n## Skill Configuration\n\n### Common Skill Instructions\n\nMANDATORY: 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`.\n\n### Source Resolution\n\nLoad `../../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.\n\n## Relevant Dependency Categories\n\nThese 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.\n\n- `Deal Materials`\n- `Models, Workbooks & Templates`\n- `Process Updates`\n- `Market Data & Public Sources`\n\n## Deliverable Intake\n\nWhen 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. When invoked as a downstream support step within an already scoped workflow, inherit resolved preferences and do not re-prompt.\n\n## Artifact Hierarchy\n\nFollow `../../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.\n\n## Plugin Workflow Routing\n\nFor 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.\n\n## Trigger Boundary\nUse this skill when the user wants to test seller materials, including:\n- a CIM, teaser, or investor deck teardown\n- a claims ledger from seller materials\n- evidence requests, seller asks, or a data-room gap list\n- ranked diligence questions or a diligence workplan\n- a red-flag register\n- quick underwriting implications from seller claims\n- a decision-oriented diligence memo for PE, growth, CorpDev, or confirmatory diligence\n\nDo not use this skill for:\n- writing, polishing, or designing a CIM\n- building a full DCF, LBO, merger model, or valuation workbook\n- generic company summaries with no diligence or falsification ask\n- pure legal opinions or legal advice\n- casual article or deck summarization\n\n## Role / Non-Role\nAct as the diligence lead turning seller materials into a falsification-first, decision-grade pack that tells the team whether to keep spending time.\n\nDefault posture:\n- the CIM is the claim source, not proof\n- decision-grade top layer first, broad background later\n- definitions before numbers\n- gating items before narrative\n- explicit kill criteria for each gating item\n- first-wave seller asks before second-wave confirmatory diligence\n- HTML teardown report first for substantial diligence; concise chat only for narrow follow-ups or explicit quick screens\n\nMinimum 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`.\n\nStop and ask for clarification only when document versions, deal perimeter, persona lens, or asset type conflict in a way that would change the answer.\n\n## Fast Workflow\n1. Triage deal stage, user-requested artifact, persona lens, available inputs, and connector/export availability.\n2. Detect the primary asset type. Load the matching overlay reference before assigning owners or finalizing gates.\n3. Build a citation map for files, pages, sections, exhibits, charts, footnotes, versions, and external sources.\n4. Run the CIM credibility anomaly pass and promote material trust issues into the IC view.\n5. Extract atomic claims, classify them, capture qualifiers, and flag missing definitions.\n6. Run quick underwriting math when price plus earnings, cashflow, NOI, EBITDA, FCF, or equivalent metrics appear.\n7. Draft first-wave gating items with linked `C-`, `E-`, `Q-`, and `RF-` IDs where available.\n8. Create falsification-first questions and a `First-Wave Seller Data Request`.\n9. Detect red flags, state `What resolves it`, and link each flag to claims and questions.\n10. Produce the requested artifact with appendices, then run readability and audit QA.\n\n## Sub-agent decomposition\n\nFor 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.\n\n\n## Artifact Contract\nDefault output for substantial teardown work is an `extended_analysis` polished standalone HTML diligence report with three layers:\n1. compact initial IC recommendation and gating decision\n2. decision-useful first-wave diligence sections focused on the user's ask\n3. appendices or structured exports for the full claims, evidence, questions, red flags, and tasks/workplan when useful\n\nDefault sections:\n- `Initial IC Recommendation`, including posture, gating issues, and what changes the recommendation\n- `Claims That Matter Most`, including proof status and required validation\n- `Red Flags And Kill Tests`, including what resolves each gating issue\n- `First-Wave Seller Data Request`, limited to evidence needed before deciding whether to proceed\n- `Quick Underwriting Implications` when price and a cashflow/earnings metric exist\n- external triangulation pack when connectors or primary exports are missing\n- executable workplan when it adds decisions or ownership not already shown in the request table\n- appendices: full claims ledger, evidence list, question list, red-flag register, and task/workplan list\n- assumptions, missing evidence, and open questions\n\nUse stable IDs across every artifact:\n- `claim_id`: `C-0001`\n- `evidence_id`: `E-0001`\n- `question_id`: `Q-0001`\n- `red_flag_id`: `RF-0001`\n- `task_id`: `T-0001`\n\nCreate 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.\n\nFor 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.\n\nFor 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.\n\nFor detailed schemas, templates, readability rules, and export contracts, read:\n- [report-template.md](references/report-template.md)\n- [output-schemas.md](references/output-schemas.md)\n- [downstream-handoffs.md](references/downstream-handoffs.md)\n- [handoff-contracts.md](../../references/handoff-contracts.md)\n\n## Source / Evidence Posture\nNo hallucinated citations. Every material fact needs a resolvable pointer or `CITATION_TBD`.\n\nCanonical pointer families:\n- `CIM <file> | p.<page> | <section_path> | <exhibit_id> | <object> | <span>`\n- `WEB | <source_name> | <url> | <title> | <date_accessed> | <span/lines>`\n- `CITATION_TBD`\n\nEvidence order:\n1. connectors and systems of record\n2. user-provided exports, uploads, or data-room files\n3. credible primary web sources\n4. secondary aggregators, with lower confidence and corroboration when material\n\nWeb 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`.\n\nFor detailed citation, proof, claim, metric, question, and red-flag rules, read:\n- [citations.md](references/citations.md)\n- [evidence-framework.md](references/evidence-framework.md)\n- [claims-taxonomy.md](references/claims-taxonomy.md)\n- [metric-definitions.md](references/metric-definitions.md)\n- [question-engine.md](references/question-engine.md)\n- [red-flag-catalog.md](references/red-flag-catalog.md)\n\n## Validated Handoffs\n\n<!-- GENERATED: validated-handoffs START -->\n\nProducer contracts:\n- `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.\n- `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.\n\nUse `../../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.\n\nHandoff 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.\n\n<!-- GENERATED: validated-handoffs END -->\n## Script Map\nUse scripts only when the user asks for file outputs or a structured teardown workspace.\n\n- `scripts/validate_plan.py`: validates `plan.json` before scaffolding.\n- `scripts/run_plan.py`: scaffolds `cim_teardown_report.html`, CSV ledgers, `deal_package.json`, and `manifest.json`; it does not parse the CIM.\n- `scripts/validate_outputs.py`: validates output files, headers, IDs, cross-links, citation presence, and priority math.\n\nWhen 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.\n\n## Standalone HTML Path\n\nWhen 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.\n\nFor 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.\n\nStable `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.\n\nDo 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.\nDo not add a navigation bar or table-of-contents strip to an ordinary initial IC report unless material length or complexity makes navigation useful.\n\n## HTML Evidence Readiness\n\nFor 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.\n\nFor an HTML CIM teardown report:\n\n- Cite complete claims, table rows, or metric phrases where possible rather than repeating source chips across headings, individual cells, and section footers.\n- Keep seller claims, analyst calculations, inferred diligence risks, and requested evidence visibly distinct.\n- Make the proceed/pause/pass posture conditional when source support is limited to seller materials.\n- Keep support artifacts and generation mechanics out of the visible report body unless requested.\n- Render and visually inspect local HTML with local headless-browser screenshots, not the in-app Browser plugin, before delivery.\n\n## Deliverable Format Standard\n\nFollow `../../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.\n\nWhen 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.\n\nFinal responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.\n\n## Reference Map\nRead only the references needed for the request.\n\nCore operating references:\n- [../../references/html-artifact-standard.md](../../references/html-artifact-standard.md): shared standalone HTML design, evidence, and visual-inspection standard.\n- [analysis-playbook.md](references/analysis-playbook.md): detailed operating rules, anomaly pass, underwriting math, owner mapping, edge cases, and do-not-do rules.\n- [report-template.md](references/report-template.md): default HTML report, IC view, seller ask block, readability QA, and templates.\n- [citations.md](references/citations.md): detailed citation strings, web/CIM pointer rules, and citation failure modes.\n- [evidence-framework.md](references/evidence-framework.md): proof hierarchy, retrieval ladder, source standards, seller tricks, and external triangulation.\n- [claims-taxonomy.md](references/claims-taxonomy.md): claim extraction, taxonomy, qualifiers, and worked claim examples.\n- [metric-definitions.md](references/metric-definitions.md): definitions and pitfalls for ARR, retention, gross margin, CAC, pipeline, EBITDA, cash conversion, and related metrics.\n- [reconciliation-playbooks.md](references/reconciliation-playbooks.md): tie-outs for ARR, bookings, retention, gross margin, pipeline, working capital, and cash conversion.\n- [question-engine.md](references/question-engine.md): falsification-first question design, priority scoring, owners, and branching follow-ups.\n- [data-requests-library.md](references/data-requests-library.md): exact export wording and field lists for seller requests.\n- [red-flag-catalog.md](references/red-flag-catalog.md): red-flag detection logic and severity calibration.\n- [output-schemas.md](references/output-schemas.md): CSV/JSON schemas, plan schema, and validator expectations.\n- [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.\n- [../../references/handoff-contracts.md](../../references/handoff-contracts.md): canonical cross-skill handoff field names.\n- [persona-overlays.md](references/persona-overlays.md): PE, growth/VC, CorpDev, diligence lead, and mixed-lens emphasis.\n- [security-legal-dd.md](references/security-legal-dd.md): security, compliance, and legal diligence checks when those workstreams are material.\n- [examples.md](references/examples.md): trigger examples, edge cases, and a micro worked example.\n\nAsset overlays:\n- [overlay-saas.md](references/overlay-saas.md): software, SaaS, usage, or recurring-revenue businesses.\n- [overlay-consumer-retail.md](references/overlay-consumer-retail.md): stores, ecommerce, brands, restaurants, and retail rollups.\n- [overlay-local-field-services.md](references/overlay-local-field-services.md): route, dispatch, technician, local services, and field operations.\n- [overlay-staffing-labor-services.md](references/overlay-staffing-labor-services.md): staffing, labor marketplaces, outsourced labor, and payroll-funding businesses.\n- [overlay-fuel-convenience-site-retail.md](references/overlay-fuel-convenience-site-retail.md): fuel, convenience, car wash, QSR pad, and site-retail economics.\n- [overlay-industrials.md](references/overlay-industrials.md): manufacturing, processing, distribution-with-production, and asset-heavy industrials.\n- [overlay-healthcare.md](references/overlay-healthcare.md): providers, services, reimbursement, regulated healthcare, and patient-volume businesses.\n- [overlay-financial-services.md](references/overlay-financial-services.md): asset management, insurance distribution, specialty finance, servicing, payments, and regulated financials.\n- [overlay-real-assets.md](references/overlay-real-assets.md): site-driven real assets where throughput, permits, condition, and local demand drive cash flow.\n- [overlay-real-estate-heavy.md](references/overlay-real-estate-heavy.md): leases, NOI, occupancy, rent, taxes, and property-heavy operating models.\n"
}