Update to OloLand DD

{
  "description": "Use when the user asks to run the OloLand ololand-dd-playbook-recall workflow. Pull your firm's playbook for deals like this — what worked, what didn't, what got missed in similar past deals. Wraps cross-deal learning + per-deal outcome metadata.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 453
    }
  ],
  "name": "ololand-dd-playbook-recall",
  "skill_md_contents": "---\nname: ololand-dd-playbook-recall\ndescription: \"Use when the user asks to run the OloLand ololand-dd-playbook-recall\\\n  \\ workflow. Pull your firm's playbook for deals like this \\u2014 what worked, what\\\n  \\ didn't, what got missed in similar past deals. Wraps cross-deal learning + per-deal\\\n  \\ outcome metadata.\"\n---\n\n\n# Workflow for ololand-dd-playbook-recall\n\nFollow the OloLand command instructions below when the user asks for `ololand-dd-playbook-recall` or the equivalent workflow.\n\n# Playbook Recall\n\nSurfaces your firm's institutional memory on deals like this one. For each similar past deal, returns the playbook moves that worked, the moves that didn't, the risks that were correctly flagged, and (most usefully) the risks that were missed and materialized post-close.\n\n## Usage\n\n```\nololand-dd-playbook-recall <deal_id>\n```\n\n## Arguments\n\n- `deal_id` (required) — The current deal to recall playbooks for. Similarity is computed against industry (35%), size (25%), deal type (20%), and margin profile (20%).\n\n## Execution\n\n1. Call `find_similar_deals` from the MCP server with the `deal_id`. Returns up to 8 most similar past deals.\n2. **If the response is `status: \"no_usable_corpus\"`** — stop here. Tell the user explicitly that institutional memory cannot support this deal yet (strict deal-type / sector-family / size-ratio filters couldn't form a usable cohort). Do NOT fabricate a cohort from looser matching.\n3. For each similar deal in a usable cohort, walk the `outcome` / `learning_insights` blocks that `find_similar_deals` returns directly:\n   - The risk categories that were flagged during DD vs. the risks that materialized post-close\n   - The accuracy patterns (where projections were systematically optimistic / pessimistic)\n   - The valuation ranges that closed vs. the underwritten range\n4. For deeper context on specific past deals, use `get_deal`, `get_deal_risks`, and `get_evidence_links` on the historical deal IDs returned in step 1.\n5. Synthesize into a structured playbook recall:\n\n   - **What worked** — moves that recurred across multiple similar deals with positive outcomes\n   - **What didn't** — moves attempted but with poor outcomes; treat as anti-patterns\n   - **What was missed** — risks that *weren't* flagged during DD but materialized post-close. This is the most valuable section: it surfaces the systematic blind spots in your firm's prior reads of this deal type.\n   - **Calibration** — for each metric the current deal is presenting (revenue growth, EBITDA margin, leverage), the historical accuracy of similar deals' projections vs. realizations.\n\n## Why this matters\n\nThis is the institutional-memory wedge. A general-purpose AI doesn't have access to your firm's deal history; it can only tell you industry averages. This command tells you what *your firm* learned the last 14 times you saw a deal shaped like this one — including the patterns that consistently get missed in DD and bite later.\n\n## Example\n\n```\nololand-dd-playbook-recall deal_acme_2026\n```\n\nReturns: \"Across 6 similar industrial-services rollups your firm closed in 2022-2024: revenue projections were overestimated by avg 15%, customer concentration was flagged in 5/6 deals and materialized in 3, integration cost overruns averaged 1.4x management's estimate. Recommended DD pivots: deeper customer interviews, integration cost stress test at 1.5x management base case.\"\n\n## Related commands\n\n- `ololand-dd-similar-deals` — raw similarity output without playbook synthesis\n- `ololand-dd-calibrate-vs-history` — applies historical accuracy patterns to adjust the current deal's projections\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"
}