Update to OloLand DD

{
  "description": "Use when the user asks to run the OloLand ololand-dd-dd-analyze workflow. Run the deal's bounded due-diligence extraction pipeline — financial snapshot, five-dimension risk extraction, and target-only commercial findings. Valuation, forensic QoE, conflict detection, war-game, and memo generation are separate explicit actions.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 448
    }
  ],
  "name": "ololand-dd-dd-analyze",
  "skill_md_contents": "---\nname: ololand-dd-dd-analyze\ndescription: \"Use when the user asks to run the OloLand ololand-dd-dd-analyze workflow.\\\n  \\ Run the deal's bounded due-diligence extraction pipeline \\u2014 financial snapshot,\\\n  \\ five-dimension risk extraction, and target-only commercial findings. Valuation,\\\n  \\ forensic QoE, conflict detection, war-game, and memo generation are separate explicit\\\n  \\ actions.\"\n---\n\n\n# Workflow for ololand-dd-dd-analyze\n\nFollow the OloLand command instructions below when the user asks for `ololand-dd-dd-analyze` or the equivalent workflow.\n\n# Due Diligence Analysis\n\nRun the bounded extraction and risk-analysis pipeline on a deal using OloLand's institutional control system. This command does not run DCF/LBO/Monte Carlo, war-game, forensic QoE, cross-document conflict detection, or memo generation.\n\n## Usage\n\n```\nololand-dd-dd-analyze <deal_id>\n```\n\n## Arguments\n\n- `deal_id` (required) — The deal ID to analyze. The backend tool does not accept a narrower scope parameter.\n\n## Execution\n\n1. Verify the deal exists using the `get_deal` MCP tool.\n2. **Status-only questions are a terminal read-only path and never start a run.** If the user is asking whether an earlier dispatch finished or what it produced, do not continue to step 3 and do not call `run_due_diligence`. Require the original `task_id` returned by an earlier `run_due_diligence` call and call `check_task_status(task_id)` only to report that task's launch state. If the caller does not have that task ID, report that this legacy dispatch's status is unavailable; do not substitute `get_analysis_run_status`, because it reads a different canonical `AnalysisRun` workflow. Stop after reporting status.\n3. Call `run_due_diligence(deal_id)` exactly once. The backend dispatches `master_data_extraction_task`, whose bounded contract is:\n   - Simplified financial statement extraction into the deal snapshot\n   - Risk extraction across the five dimensions: HR, Legal, Tech, Commercial, and Financial\n   - Target-only commercial opportunities, insights, and synergies extraction\n   - No DCF, LBO, Monte Carlo, war-game, forensic QoE, conflict detector, memo, or other valuation engine\n4. Poll the returned parent `task_id` with `check_task_status`, but treat `SUCCESS` only as **launch confirmed**. The current parent task dispatches five child jobs asynchronously and returns before they all finish; its terminal state is not an analysis-complete signal.\n5. After launch confirmation, read `get_financial_snapshot` and `get_deal_risks` separately:\n   - Record the request time before invoking `run_due_diligence`. Treat the financial leg as fresh only when the returned snapshot's `created_at` is at or after that request time. Otherwise report it as pending or stale.\n   - `get_deal_risks` exposes the latest available register but does not prove that this legacy dispatch refreshed it. Label those rows **latest available risks**, not “risks extracted by this run.”\n   - This MCP rail exposes no durable completion/read receipt for the three commercial child jobs. Report their completion as unverified; do not attribute existing commercial findings to this run.\n   - `get_deal_summary_tiles` may be read separately when useful, but do not claim this extraction run created or refreshed those tiles.\n6. Never call the parent task “complete” or infer all-child completion from its success. If the freshness checks above do not pass, return `launch confirmed; results pending/unverified` and the exact missing proof.\n\n## After Completion\n\nReport:\n- Parent dispatch status: `launch confirmed`, `launch failed`, or `unknown` — never `analysis complete`\n- Count and severity mix of the latest risk rows returned within `get_deal_risks`' tool limit, explicitly not a total-register count and not attributed to this run without a durable receipt\n- Top 5 latest available risks with evidence citations\n- Financial snapshot (revenue, EBITDA, margins) only when its `created_at` proves post-request freshness; otherwise state pending/stale\n- Commercial child completion: unverified on this legacy MCP rail\n- Any source or coverage gaps returned by the extraction tools\n- Explicitly note that conflict detection, forensic QoE, valuation, and memo generation were not run\n- Suggested next steps: `ololand-dd-valuation <deal_id> read all` to inspect governed models and source-backed market evidence, or `ololand-dd-valuation <deal_id> run all` only when the user explicitly asks to create fresh model candidates; `ololand-dd-risk-report <deal_id>` for deep risk analysis\n\n## Output URL Conventions (STRICT)\n\nWhen linking to OloLand web app pages in your output, use ONLY these canonical patterns. The domain is **`app.ololand.ai`** — never `.com`. Path segments are exact (e.g. `dataroom` not `data-room`; `due-diligence` with hyphen).\n\n- Risks view: `https://app.ololand.ai/deals/{deal_id}/risks`\n- Data room: `https://app.ololand.ai/deals/{deal_id}/dataroom`\n- Valuations: `https://app.ololand.ai/deals/{deal_id}/valuations`\n- Deal summary: `https://app.ololand.ai/deals/{deal_id}/summary`\n- Due diligence: `https://app.ololand.ai/deals/{deal_id}/due-diligence`\n\nIf a tool response gives you a `view_url`, render that verbatim. Never construct a URL the tool didn't return when the tool gave you one.\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"
}