{"id":15831,"plugin_id":"Plugin_68c39ea2b3888191827c933053f3a1d1","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:12:09.702Z","digest":"c2bea261bc65c0027b7d4878aa0af2f92e6fea9ec33394adbd3515e4fd5238e9","against":null,"payload":{"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.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":317},{"relative_path":"assets/cim_intake_checklist.md","size_in_bytes":1305},{"relative_path":"assets/cim_page_plan_template.md","size_in_bytes":264},{"relative_path":"assets/diligence_issue_log_template.csv","size_in_bytes":102},{"relative_path":"assets/management_interview_guide.md","size_in_bytes":2252},{"relative_path":"assets/refresh_change_log_template.csv","size_in_bytes":106},{"relative_path":"assets/source_log_template.csv","size_in_bytes":151},{"relative_path":"references/cim_workflow.md","size_in_bytes":10534},{"relative_path":"references/output_templates.md","size_in_bytes":6826},{"relative_path":"references/review_checklists.md","size_in_bytes":5177},{"relative_path":"references/section_standards.md","size_in_bytes":8351},{"relative_path":"references/sector_modules.md","size_in_bytes":7431},{"relative_path":"references/source_and_tieout.md","size_in_bytes":6459},{"relative_path":"references/transaction_modules.md","size_in_bytes":5854},{"relative_path":"scripts/build_cim_package.py","size_in_bytes":14184},{"relative_path":"scripts/check_source_log.py","size_in_bytes":2646}],"name":"cim-builder","skill_md_contents":"---\nname: cim-builder\ndescription: Draft or refresh buyer-facing CIMs, teasers, CIM storyboards, lender presentations, and management presentations. Do not use for independent CIM diligence; use cim-teardown.\n---\n\n# CIM Builder\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`, `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.\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- `Process Updates`\n- `Relationship & Counterparty Context`\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. 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.\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 standalone HTML CIM/storyboard, banker-facing workbook, requested native deck/document, or clear first-read package.\n\n## Artifact Hierarchy\n\nFollow `../../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.\n\n## Core posture\n\nAct 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.\n\nA 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.\n\n## First classify the assignment\n\nBefore 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.\n\n1. **new build**: create CIM architecture, equity story, page plan, draft language, source log, and diligence asks from available company materials.\n2. **refresh**: update an existing CIM for new monthly financials, KPIs, market data, diligence findings, or process positioning.\n3. **upgrade / MD review**: improve a rough CIM or analyst draft for story, buyer lens, source quality, risk framing, and banker-grade page logic.\n4. **teaser / summary conversion**: create blind or named teaser, executive summary, or buyer outreach material from CIM inputs.\n5. **management presentation conversion**: turn CIM materials into buyer meeting narrative, page flow, and Q&A prep.\n6. **source / diligence pack**: create source log, tie-out checklist, data room asks, management follow-ups, and red-flag matrix.\n\n## Deliverable Modes\n\nAfter classifying the assignment, choose the delivery mode independently:\n\n- `cim_document`: draft or refresh a written buyer-facing CIM or teaser; default hero deliverable is polished standalone HTML.\n- `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.\n- `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.\n- `source_pack`: create a workbook or structured support package when the requested job is evidence control rather than reader-facing drafting.\n\nA `storyboard` is an internal planning document unless the user explicitly requests a slide storyboard. Do not silently turn it into a presentation.\n\n## Adapt to input completeness\n\n- **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.\n- **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.\n- **Full context**: produce the requested materials plus page-by-page source mapping, financial/KPI tie-out, diligence issue log, and MD review checklist.\n- **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.\n\n## Source priority and evidence rules\n\nPrefer sources in this order:\n\n1. user-provided files, prompt context, and explicit instructions.\n2. callable connected routes or user-provided exports, such as drive, email, slack, meetings, or file systems.\n3. existing deal materials: prior CIM, teaser, management presentation, model, QoE, VDR index, Q&A log, legal/tax/commercial diligence.\n4. 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.\n5. third-party and public research: filings, company websites, industry reports, government sources, market data providers, and web search.\n6. clearly labeled assumptions or placeholders.\n\nUse 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.\n\nNever 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.\n\n## Required workflow\n\nFollow this sequence unless the user asks for a narrower output:\n\n1. 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.\n2. 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.\n3. Analyze buyer psychology: strategic, sponsor, lender, growth equity, infrastructure, family office, or other investor lens.\n4. Build the fact base: company overview, market, customers, products, financials, KPIs, forecast, management, operations, risks, and evidence gaps.\n5. Design the CIM architecture: section order, page-by-page message, exhibit plan, source needs, and open questions.\n6. Draft or refresh content: use argument-led page titles, concise bullets, exhibits with a clear so-what, and source notes.\n7. Tie out financials and KPIs: reconcile metrics, dates, units, add-backs, LTM periods, CAGRs, margins, chart data, and definitions.\n8. Separate external-ready language from banker-internal notes, diligence risks, compliance flags, and management follow-ups.\n9. 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.\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: 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.\n\n\n## Load references as needed\n\n- Use `references/cim_workflow.md` for the full end-to-end workflow and mode-specific behavior.\n- Use `references/section_standards.md` when building or reviewing individual CIM sections.\n- Use `references/sector_modules.md` when the company belongs to a specific sector or requires KPI-specific treatment.\n- Use `references/transaction_modules.md` when tailoring to sale, recap, growth equity, carve-out, debt, or distressed contexts.\n- Use `references/source_and_tieout.md` for source hierarchy, financial checks, KPI definitions, add-back discipline, and source log standards.\n- Use `references/output_templates.md` for default response structures, page plans, equity story, refresh logs, and disclosure matrices.\n- Use `references/review_checklists.md` before presenting external-ready or senior-review-ready outputs.\n- Use `../../references/handoff-contracts.md` when exporting a QC package to `ib-deck-qc`; field names must match `cim_builder_to_ib_deck_qc`.\n- Use `../../references/evidence-label-taxonomy.md` when mapping native evidence labels into `canonical_evidence_category` for downstream handoffs.\n\nUse bundled assets only as templates; adapt them to the actual deal. Do not represent template language as final legal, compliance, or firm-approved disclosure.\n\n## Output standards\n\nEvery substantial CIM build or refresh should include, unless not relevant:\n\n- transaction context and input completeness assessment.\n- MD-level equity story spine.\n- buyer lens and likely diligence pressure points.\n- recommended CIM architecture or updated page flow.\n- page-by-page plan with key message, exhibit, required data, source, and open questions.\n- draft language for requested sections.\n- source log or source-log-ready table.\n- financial and KPI tie-out notes.\n- missing information request list.\n- risk, disclosure, and confidentiality flags.\n- internal banker notes separated from external-ready language.\n- MD review checklist and next actions.\n\nWhen 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.\n\n## Standalone HTML Path\n\nWhen 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.\n\nFor a substantive CIM/storyboard, a useful HTML structure is:\n\n- title page and circulation posture;\n- executive story and transaction context;\n- investment highlights or proposed buyer narrative;\n- proposed CIM architecture and page-by-page exhibit plan;\n- supported financial, operating, transaction, or valuation evidence;\n- diligence pressure points, disclosure considerations, and management support required;\n- source register and readiness conclusion.\n\nSeparate 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.\n\n## Presentation Path\n\nWhen 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.\n\n## Export contract to `ib-deck-qc`\n\nAny external-ready CIM, teaser, management presentation, lender presentation, or buyer-facing section must carry a QC handoff package before circulation review.\n\nUse the canonical `cim_builder_to_ib_deck_qc` contract in `../../references/handoff-contracts.md`.\n\nRequired package fields:\n- `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`.\n\nPopulate 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`.\n\n`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.\n\n## Quality bar\n\nApply these tests before finalizing:\n\n- Would a senior banker understand the buyer-facing story in the first two pages?\n- Does each section answer a real buyer underwriting question?\n- Are major claims tied to sources or labeled as assumptions?\n- Do all financials, KPIs, units, dates, LTM periods, and charts tie across the model, source data, and text?\n- Are risks framed credibly rather than hidden?\n- Is sensitive information staged appropriately by process phase?\n- 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?\n## Validated Handoffs\n\n<!-- GENERATED: validated-handoffs START -->\n\nProducer contracts:\n- `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.\n\nIntake validation:\n- 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.\n- 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.\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## 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. 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.\n\nFor a standalone HTML CIM or storyboard:\n\n- keep the first-read hierarchy focused on buyer narrative, evidence, and circulation posture rather than implementation machinery;\n- keep sources traceable near material claims and in a clean source register;\n- avoid generic dashboard navigation, report-opening buttons, render-contract metadata, related-file panels, or “model file” modules unless requested and actually relevant;\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. 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.\n\nFinal 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.\n\n## Runtime Artifact Path\n\nDefault 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.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}