Update to OloLand DD

{
  "description": "Use when the user asks to run the OloLand ololand-dd-risk-report workflow. Generate a structured risk report for a deal — 67-category taxonomy (311 tracked risk factors) with severity scoring, evidence links, and institutional patterns from similar deals.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 449
    }
  ],
  "name": "ololand-dd-risk-report",
  "skill_md_contents": "---\nname: ololand-dd-risk-report\ndescription: \"Use when the user asks to run the OloLand ololand-dd-risk-report workflow.\\\n  \\ Generate a structured risk report for a deal \\u2014 67-category taxonomy (311\\\n  \\ tracked risk factors) with severity scoring, evidence links, and institutional\\\n  \\ patterns from similar deals.\"\n---\n\n\n# Workflow for ololand-dd-risk-report\n\nFollow the OloLand command instructions below when the user asks for `ololand-dd-risk-report` or the equivalent workflow.\n\n# Risk Report\n\nGenerate a comprehensive risk assessment using OloLand's institutional risk taxonomy — 311 risk factors across 67 categories.\n\n## Usage\n\n```\nololand-dd-risk-report <deal_id> [category]\n```\n\n## Arguments\n\n- `deal_id` (required) — The deal ID to assess.\n- `category` (optional) — Focus on a specific risk dimension: `commercial`, `financial`, `legal`, `hr`, `tech`. Default: all.\n\n## Execution\n\n1. Fetch existing risks with `get_deal_risks` from the MCP server.\n2. For each risk, retrieve evidence with `get_evidence_links`.\n3. Call `find_similar_deals` for institutional patterns from past deals. If it returns `status: \"no_usable_corpus\"`, omit the historical-patterns section entirely — do not fabricate one.\n4. Build the report:\n   - **Risk heatmap**: Probability vs. impact matrix for top 10 risks\n   - **Category breakdown**: Risks grouped by dimension (Commercial, Financial, Legal, HR, Tech)\n   - **Evidence citations**: Source documents for each risk\n   - **Historical patterns** (only if usable cohort exists): \"In 8 similar deals, this risk category was accurate 82% of the time\"\n   - **Deal-killer flags**: Risks where system severity <= 2 but analysts historically corrected to >= 4\n\n## Probability rendering (STRICT)\n\n`get_deal_risks` now returns three probability metadata fields per risk: `probability_source`, `probability_confidence`, and `probability_rendering`. Honor `probability_rendering`:\n\n- `numeric` — render `probability_percent` as a percentage (e.g. \"65%\"). The probability is source-supported.\n- `qualitative` — render as Low / Medium / High. The probability is a severity proxy, NOT a source-supported number. Do NOT show a percentage in this case.\n\nMixing severity-derived probabilities with source-supported ones in the same percentage column is a false-precision bug; the rendering field exists specifically to prevent that.\n\n## Report Format\n\nPresent as structured markdown with:\n- Summary table (risk name, severity 1-5, probability per the rendering rule above, dollar impact, evidence source)\n- Color-coded severity indicators\n- Institutional memory section (patterns from similar deals; omit if no usable cohort)\n- Recommended mitigants for Critical/High risks\n\n## Adding a risk the AI missed\n\nWhen the analyst identifies a risk that AI extraction didn't catch, call\n`add_manual_risk(deal_id, section_name, category,\nrisk_description, severity)`. `section_name` is one of `financial` /\n`commercial` / `legal` / `hr` / `tech`; `severity` defaults to `high` since a\nmanual entry implies analyst conviction (the LLM may reassess it on\nenhancement). This creates a manual `KnowledgeInsight` and queues AI\nenhancement (severity score, impact, mitigation, citations) that completes in\n30-90 seconds — tell the user the risk is immediately visible in the deal's\nrisk panels but full analysis is still filling in. A `status:\n\"already_registered\"` response is a success shape (idempotent dedup on\ndeal+category+description), not an error.\n\n## Recording a firm-wide risk policy\n\nIf the analyst states a **standing rule** rather than a judgment about one\nfinding — \"we don't care about customer concentration under 20% in this\nsector, stop flagging it\", \"always escalate key-person risk\" — this is a\nfirm-governance write, not a per-finding correction. Call\n`set_firm_risk_policy(risk_category, policy, rationale,\nscope_conditions, active)` with `policy` one of `waive` / `downweight` /\n`escalate`. `rationale` is required — an unexplained waiver defeats the point\nof recording it. This writes one `firm_risk_policies` row scoped to the\ncaller's own company (there is no `company_id` argument to spoof another\ntenant). Active policies surface as firm context to future analysis; they do\n**not** silently suppress detection — extraction and severity scoring are\nunchanged, so a waived risk is still found and still visible, just labeled\nwith how the firm has decided to treat it. Confirm this distinction to the\nuser before recording a `waive` policy so they don't expect the risk to stop\nappearing. A single one-off disagreement about one finding is\n`submit_risk_correction`, not this tool.\n\n## Output URL Conventions (STRICT)\n\nWhen linking to OloLand web app pages in your output, the domain is **`app.ololand.ai`** — never `.com`. Use these canonical paths:\n\n- Risks view: `https://app.ololand.ai/deals/{deal_id}/risks`\n- Data room: `https://app.ololand.ai/deals/{deal_id}/dataroom`\n- Deal summary: `https://app.ololand.ai/deals/{deal_id}/summary`\n\nNever construct URLs the MCP tool didn't return — if a tool response includes a `view_url` or `link` field, render it verbatim. Otherwise use the templates above.\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"
}