Update to OloLand DD

{
  "description": "Use when the user asks to run the OloLand ololand-dd-firm-playbook workflow. Read the firm's standing institutional playbook attached to this deal — WACC ranges, EV/Revenue and EV/EBITDA ceilings, target IRR, min MOIC, approval thresholds, preferred frameworks, custom rules. Use at the start of any deal turn that produces a number under the firm's name.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 451
    }
  ],
  "name": "ololand-dd-firm-playbook",
  "skill_md_contents": "---\nname: ololand-dd-firm-playbook\ndescription: \"Use when the user asks to run the OloLand ololand-dd-firm-playbook workflow.\\\n  \\ Read the firm's standing institutional playbook attached to this deal \\u2014 WACC\\\n  \\ ranges, EV/Revenue and EV/EBITDA ceilings, target IRR, min MOIC, approval thresholds,\\\n  \\ preferred frameworks, custom rules. Use at the start of any deal turn that produces\\\n  \\ a number under the firm's name.\"\n---\n\n\n# Workflow for ololand-dd-firm-playbook\n\nFollow the OloLand command instructions below when the user asks for `ololand-dd-firm-playbook` or the equivalent workflow.\n\n# ololand-dd-firm-playbook\n\nYou are reading THIS firm's standing investment configuration for the deal's tenant. The playbook encodes institutional preferences the firm has codified — they are more authoritative than market-default heuristics. When a playbook value constrains a number you're about to commit to (WACC, exit multiple, target IRR), honor it OR explicitly call out the deviation.\n\nThis is distinct from `ololand-dd-playbook-recall`, which surfaces patterns from past similar deals (cross-deal learning). `ololand-dd-firm-playbook` returns the firm's STANDING CONFIG.\n\n## Required inputs\n\n1. **deal_id** — the OloLand deal whose tenant's playbook to recall.\n\n## Action\n\nCall `recall_firm_playbook` with the `deal_id`. Render the response in this format:\n\n```\nFirm playbook for <deal_id> (resolution: <deal_pin | tenant_default>)\n\nTarget criteria:\n  Industries: <list>\n  Geographies: <list>\n  Revenue range: $<min> – $<max>\n  Min EBITDA margin: <pct>\n  Min growth rate: <pct>\n\nValuation thresholds:\n  Max EV / Revenue: <x>\n  Max EV / EBITDA: <x>\n  Target IRR: <pct>\n  Min MOIC: <x>\n\nApproval thresholds:\n  Partner: $<value>\n  IC: $<value>\n  Board: $<value>\n\nStandard timelines:\n  Initial review: <days>\n  LOI → close: <days>\n  DD period: <days>\n  IC review: <days>\n\nPreferred frameworks: <list>\n\nCustom rules:\n  - <name>: <condition>  [severity: <high | medium | low>]\n```\n\n## Empty-playbook handling\n\nIf the response is `playbook: null` (no active playbook configured for this tenant), say so explicitly and recommend the user configure one via the dashboard. **Do NOT fabricate a default playbook.** Fall back to OloLand's market-default methodology for the deal in question.\n\n## Deviation discipline\n\nIf the user is about to commit to a number that conflicts with the playbook (e.g. WACC outside the firm's range, exit multiple above the firm's ceiling), surface the conflict before answering. Either:\n- Adjust the number to fit the playbook range, OR\n- Quote the playbook value and explain the deviation rationale\n\nSilent substitution of OloLand defaults when a playbook is present is a discipline failure.\n\n## Example\n\n```\nololand-dd-firm-playbook deal_acme_2026\n```\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"
}