Update to OloLand DD

{
  "description": "Use when the user asks to run the OloLand ololand-dd-meeting-prep workflow. Prep for a diligence meeting — generate a one-page question list grounded in this deal's actual risks, evidence, and similar-deal patterns. Every question cites a source.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 450
    }
  ],
  "name": "ololand-dd-meeting-prep",
  "skill_md_contents": "---\nname: ololand-dd-meeting-prep\ndescription: \"Use when the user asks to run the OloLand ololand-dd-meeting-prep workflow.\\\n  \\ Prep for a diligence meeting \\u2014 generate a one-page question list grounded\\\n  \\ in this deal's actual risks, evidence, and similar-deal patterns. Every question\\\n  \\ cites a source.\"\n---\n\n\n# Workflow for ololand-dd-meeting-prep\n\nFollow the OloLand command instructions below when the user asks for `ololand-dd-meeting-prep` or the equivalent workflow.\n\n# Meeting Prep\n\nTurn a deal's existing analysis into a tailored question list for management presentations, expert calls, customer references, or advisor sessions. Questions are deal-specific, not generic — each one links back to a risk, a document, or a pattern from a similar deal.\n\n## Usage\n\n```\nololand-dd-meeting-prep <deal_id> <meeting_type> [focus]\n```\n\n## Arguments\n\n- `deal_id` (required) — The deal the meeting is about.\n- `meeting_type` (required) — One of: `management`, `expert`, `customer`, `advisor`.\n- `focus` (optional) — Narrow the prep to a workstream: `commercial`, `financial`, `operational`, `tech`. Default: full business.\n\n## Execution\n\n1. **Anchor the deal.** Call `get_deal`, `get_financial_snapshot`, and `get_deal_summary_tiles` to load company profile, current financial snapshot, and AI-generated executive summary / SWOT.\n2. **Pull the red flags.** Call `get_deal_risks(severity=\"high\")` and (if any returned) `get_deal_risks(severity=\"critical\")`. For each risk, call `get_evidence_links` to attach the exact document + page that triggered it. These become the \"must-ask, probe deeply\" questions.\n3. **Topic-specific document search.** Call `search_deal_documents` with queries matched to `meeting_type` and `focus`:\n   - **management** — `revenue concentration`, `customer churn`, `working capital seasonality`, `EBITDA bridge adjustments`, `org chart and key hires`\n   - **expert** — `competitive landscape`, `regulatory tailwinds`, `pricing power`, `substitution threats`\n   - **customer** — `contract terms`, `pricing history`, `support quality`, `competing vendors evaluated`\n   - **advisor** — `accounting policies`, `unusual treatments`, `restatement history`, `auditor changes`\n   Pull 2-3 results per query — anything surprising becomes a question.\n4. **Institutional pattern overlay.** Call `find_similar_deals`. For each similar deal, surface:\n   - Risks that were systematically under-scored (\"In 4/6 similar deals, customer concentration was flagged a tier too low\")\n   - Questions that caught real issues post-close\n   - Valuation ranges to reference live (median EV/EBITDA, revenue multiples)\n5. **Compose the one-page prep doc** in this exact structure:\n\n   1. **Meeting logistics** — meeting type, duration suggestion (60-90 min), focus area\n   2. **Top 3 objectives** — what you must learn, derived from the highest-severity risks + biggest unanswered question in the data room\n   3. **Question list** (15-20 max, prioritized) — grouped by topic, each question annotated with:\n      - `[★]` for must-asks (tied to Critical/High risks)\n      - `(source: <doc>:<page>)` for questions traceable to a specific document\n      - `(pattern: similar deal)` for questions surfaced by `find_similar_deals`\n   4. **Benchmarks to reference** — comp valuation ranges from `find_similar_deals`, financial snapshot deltas vs comps from `get_deal_summary_tiles`\n   5. **Red flags to probe** — bulleted list of risks with severity score and evidence citation\n   6. **Follow-up requests** — documents or data still missing from the data room (derived from `data_quality.missing_critical_data` if surfaced by tools)\n\n## Output Conventions\n\n- Keep the question list to **15-20 questions max** — you won't get through more in a 60-90 min session.\n- Lead with open-ended questions, then tighten with specifics (\"Walk us through revenue by customer\" before \"Why did customer X drop 12%?\").\n- Never invent a citation. If a question can't be tied back to a tool response, mark it `(general)` not `(source: ...)`.\n- Always close the question list with: *\"What haven't we asked about that we should?\"*\n\n## Output URL Conventions (STRICT)\n\nWhen linking back to OloLand views, the domain is **`app.ololand.ai`** — never `.com`. Use these canonical paths:\n\n- Risks (probe red flags here after the meeting): `https://app.ololand.ai/deals/{deal_id}/risks`\n- Data room (file follow-up requests here): `https://app.ololand.ai/deals/{deal_id}/dataroom`\n- Deal summary: `https://app.ololand.ai/deals/{deal_id}/summary`\n\nIf a tool response gives a `view_url`, render it verbatim. Don't construct URLs the tool didn't return.\n\n## Why This Matters\n\nGeneric prep templates produce generic questions. This command grounds every question in *this* deal's actual evidence and *your firm's* prior outcomes — the version of meeting prep an off-the-shelf LLM cannot produce because it has no access to your data room or your historical deal record.\n\n\n## OpenAI execution requirements\n\nUse the connected MCP server's current tool schemas. Do not invent tool arguments, job-status endpoints, inputs, or outputs. If a referenced tool is unavailable, explain the limitation and request the needed connection or data. Invoke writes only when the user has requested the corresponding action. Do not initiate purchases or payments. An unrun, unsupported, or unavailable procedure is a gap, never a passing result.\n\n\nOpenAI cannot execute local lifecycle hooks. Use the packaged explicit setup/review workflow when requested. Server-side MCP auditing remains authoritative; preserve evidence blockers and human-only approval gates.\n\nClaim-correction submission is unsupported in this OpenAI upload because the current handler records surface=cowork. Do not invoke submit_agent_claim_correction from OpenAI. Explain the limitation and retain proposed correction text for human review without claiming submission. See unsupported-workflows.json for the excluded canonical workflow.\n"
}