Update to Investment Banking

{
  "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.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 275
    },
    {
      "relative_path": "references/compliance-confidentiality.md",
      "size_in_bytes": 3596
    },
    {
      "relative_path": "references/data-source-playbook.md",
      "size_in_bytes": 5115
    },
    {
      "relative_path": "references/industry-nuance.md",
      "size_in_bytes": 6031
    },
    {
      "relative_path": "references/output-templates.md",
      "size_in_bytes": 8087
    },
    {
      "relative_path": "references/qa-checklist.md",
      "size_in_bytes": 3618
    },
    {
      "relative_path": "references/scoring-framework.md",
      "size_in_bytes": 6673
    },
    {
      "relative_path": "references/workflow.md",
      "size_in_bytes": 9043
    },
    {
      "relative_path": "scripts/score_buyer_universe.py",
      "size_in_bytes": 29948
    }
  ],
  "skill_md_contents": "---\nname: buyer-investor-list\ndescription: 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.\n---\n\n# Buyer Investor List\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`, `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.\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- `Relationship & Counterparty Context`\n- `Market Data & Public Sources`\n- `Process Updates`\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 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.\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 report, workbook, native deck/document, or clear first-read package.\n\n## Trigger Boundary\n\nUse 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.\n\nRole: 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.\n\nNon-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.\n\n## Fast Workflow\n\n1. Classify the mandate: sell-side M&A, sponsor targeting, lender/financing source, growth/minority/private placement, restructuring/distressed capital, or public-market investor targeting.\n2. 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.\n3. Establish transaction objective, constraints, target profile, confidentiality limits, client preferences, do-not-contact parties, and success metric.\n4. Define archetypes before names, then build the universe from user materials, connected sources, structured data, public sources, and banker judgment.\n5. Normalize entities, apply hard screens, score/tier parties, write specific rationale, map relationship path, sequence outreach waves, and run MD-style QA.\n6. Use only the references needed for the request; do not load every playbook by default.\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: 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.\n\n\n## Artifact Contract\n\nDefault 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.\n\nUse 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.\n\nFor 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.\n\nHero 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.\n\nFor spreadsheet-like outputs, preserve existing user columns, add new fields to the right, and use proposed-change columns instead of destructive edits.\n\nTracker 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.\n\n## Standalone HTML Path\n\nWhen 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.\n\nFor an initial sell-side pitch or outreach-sequencing request, use this first-read hierarchy:\n\n1. Process recommendation: objective, recommended process posture, conditional first-wave names, high-value holds, and decisions required from the client or MD.\n2. Outreach sequencing: one compact wave-and-gates table combining disclosure approach, required approvals, and validation steps.\n3. Prioritized buyer universe: the decision-useful ranked table, with unverified capacity, ownership, relationship, or conflicts visibly marked as validation needs.\n4. Sensitive parties and holds: one register for confidentiality, regulatory, commercial, conflict, and do-not-contact handling.\n5. Pre-outreach decisions: one consolidated action table for missing approvals, relationship checks, capacity validation, legal/compliance protocol, and material diligence gaps.\n6. Evidence and limitations: readable source notes and the preliminary or decision-ready posture.\n\nKeep 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.\n\nDo 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.\n\n## Source And Evidence Posture\n\nUse 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.\n\nDo 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.\n\n## Validated Handoffs\n\n<!-- GENERATED: validated-handoffs START -->\n\nProducer contracts:\n- `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.\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\n\nIf 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.\n\n- For tracker handoff validation, use `../../scripts/validate_handoff_payload.py buyer_investor_list_to_deal_process_tracker <payload.json>`.\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 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.\n\nFor an HTML buyer-universe report:\n\n- Keep sources readable: cite complete claims or table rows where possible rather than attaching repeated citation chips to every cell.\n- Separate confirmed facts from banker hypotheses, inferred buyer logic, relationship-validation needs, and legal/compliance gates.\n- Keep numeric scoring from implying buyer interest, transaction capacity, approval, or legal conclusions.\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: 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.\n\nFinal responses should point the user to the hero deliverable first and then briefly explain any supporting artifacts.\n\n## Reference Map\n\nLoad only the reference needed for the current task.\n\n- `../../references/html-artifact-standard.md`: shared HTML design, evidence, and visual-inspection standard.\n- `references/workflow.md`: full execution flow, mandate modes, context handling, archetype-first build logic, and process strategy.\n- `references/scoring-framework.md`: tier definitions, score treatment, override rules, wave logic, and risk-adjusted scoring nuance.\n- `references/output-templates.md`: standalone HTML report, ranked table, hold register, outreach sequence, and tracker-ready export templates.\n- `references/data-source-playbook.md`: source hierarchy, entity resolution, data gathering, and evidence handling.\n- `references/industry-nuance.md`: sector, buyer-type, sponsor/fund, cross-border, lender, and distressed-capital nuance.\n- `references/compliance-confidentiality.md`: confidentiality, antitrust, MNPI, conflicts, clean-team, sanctions, and escalation flags.\n- `references/qa-checklist.md`: final MD review, HTML presentation review, and tracker handoff readiness.\n- `../../references/handoff-contracts.md`: canonical downstream handoff fields.\n- `../../references/evidence-label-taxonomy.md`: shared evidence/source-label taxonomy.\n- `../../references/output-depth-policy.md`: analysis-depth policy; default to `extended_analysis` unless an explicit shortening condition applies.\n"
}