Update to OloLand DD

{
  "description": "Use when the user asks to run the OloLand ololand-dd-assumption-controls workflow. Review underwriting assumption controls for a deal — open, blocking, and IC-readiness state. Walks the middle-office assumption ledger that gates IC approval.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 457
    }
  ],
  "name": "ololand-dd-assumption-controls",
  "skill_md_contents": "---\nname: ololand-dd-assumption-controls\ndescription: \"Use when the user asks to run the OloLand ololand-dd-assumption-controls\\\n  \\ workflow. Review underwriting assumption controls for a deal \\u2014 open, blocking,\\\n  \\ and IC-readiness state. Walks the middle-office assumption ledger that gates IC\\\n  \\ approval.\"\n---\n\n\n# Workflow for ololand-dd-assumption-controls\n\nFollow the OloLand command instructions below when the user asks for `ololand-dd-assumption-controls` or the equivalent workflow.\n\n# Assumption Controls\n\nUnderwriting assumptions are first-class controls in OloLand. An analyst owns each statement, with a status (unverified / verified / mitigated / invalidated / accepted) and priority (low / medium / high / critical). Open high/critical tracked assumptions block IC approval; resolving them clears the gate.\n\nThis command walks the assumption ledger for a deal and reports the IC-blocker state.\n\n## Usage\n\n```\nololand-dd-assumption-controls <deal_id> [filter]\n```\n\n## Arguments\n\n- `deal_id` (required) — The deal whose assumption controls to review.\n- `filter` (optional) — `open` | `blocking` | `resolved` | `all`. Default: `blocking` (the IC-relevant subset).\n\n## Execution\n\n1. Call `get_assumption_control_summary` with the `deal_id`. This returns `total`, `open_count`, `resolved_count`, `blocking_count`, `ic_blocked`, `by_status`, `by_category`, and the top-10 `blocking_assumptions`.\n2. If `ic_blocked` is true:\n   - List each blocking assumption with statement, category, priority, status, owner, and sensitivity_score.\n   - Group by category so the analyst can see where the gaps cluster.\n3. Call `get_assumption_evidence_pack` to retrieve the evidence ledger and `quality_flags`. For each blocking assumption, surface its `evidence_strength` (none / weak / partial / supported) and any `missing_links`.\n4. Call `list_deal_assumptions` with `priority=critical` and `priority=high` to verify nothing in the tracked-but-not-blocking state has been overlooked (e.g., suggested assumptions waiting to be promoted).\n5. Render the result as a structured review:\n\n   - **IC status**: Clear / Blocked (with count)\n   - **Blockers**: table of `id`, `statement`, `category`, `priority`, `status`, `evidence_strength`, `missing_links`\n   - **By category**: count of open assumptions per category (financial / commercial / operational / market / legal / regulatory / hr / technical / financing / growth / margin / capex / wacc / terminal / other)\n   - **Recommended next actions**: for each blocker, the most concrete next step (verify with X document; mitigate via Y; mark accepted with a risk-acknowledgment note; invalidate if the underlying premise no longer holds).\n\n## Status transitions\n\nWhen the analyst is ready to resolve an assumption, call `set_assumption_status` with the `assumption_id`, the target `status` (`verified` / `mitigated` / `invalidated` / `accepted` / `unverified` to reopen), and an optional `note`. Allowed transitions:\n\n| From | To |\n|---|---|\n| unverified | verified, mitigated, invalidated, accepted |\n| verified | accepted, invalidated, unverified (reopen) |\n| mitigated | accepted, invalidated, unverified (reopen) |\n| invalidated | unverified (reopen only) |\n| accepted | unverified (reopen only) |\n\nDo NOT attempt other transitions — the service returns a validation error.\n\n## Why this matters\n\nMost AI tools generate analysis. OloLand also enforces the middle-office controls that turn analysis into an approved IC decision. Surfacing assumption state in chat — and letting the analyst transition it without leaving your assistant — is the workflow loop that competing AI assistants don't ship.\n\n## Example\n\n```\nololand-dd-assumption-controls deal_acme_2026 blocking\n```\n\nReturns: \"IC BLOCKED — 3 open blockers (2 critical, 1 high). Critical: 'FY27 revenue growth of 22% requires entry into new geography' (status=unverified, evidence_strength=none, no commercial DD attached). Critical: 'Customer concentration <30% by closing' (status=unverified, evidence_strength=weak, conflicting source). High: 'Working-capital normalization $4M' (status=unverified, evidence_strength=partial). Recommended: schedule customer DD calls; pull most recent A/R aging; have CFO confirm WC bridge.\"\n\n## Related commands\n\n- `ololand-dd-ic-approve-readiness` — pre-flight check before attempting to approve an IC package\n- `ololand-dd-risk-report` — separate surface for risk taxonomy, not assumption controls\n\n## Output URL Conventions (STRICT)\n\nDomain is `app.ololand.ai`. Surface for assumption controls:\n- `https://app.ololand.ai/deals/{deal_id}/analysis/assumptions`\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"
}