Update to OloLand DD

{
  "description": "Use when the user asks to run the OloLand ololand-dd-new-deal workflow. Create a new deal from a company name or ticker — auto-fetches the latest canonical annual filing (10-K, 20-F, or 40-F, plus substantive exhibits) and reports backend fundamentals source and coverage for public companies (SEC when enabled); seeds private companies with web research and auto-ingests a public S-1 if the target has filed to go public.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 446
    }
  ],
  "name": "ololand-dd-new-deal",
  "skill_md_contents": "---\nname: ololand-dd-new-deal\ndescription: \"Use when the user asks to run the OloLand ololand-dd-new-deal workflow.\\\n  \\ Create a new deal from a company name or ticker \\u2014 auto-fetches the latest\\\n  \\ canonical annual filing (10-K, 20-F, or 40-F, plus substantive exhibits) and reports\\\n  \\ backend fundamentals source and coverage for public companies (SEC when enabled);\\\n  \\ seeds private companies with web research and auto-ingests a public S-1 if the\\\n  \\ target has filed to go public.\"\n---\n\n\n# Workflow for ololand-dd-new-deal\n\nFollow the OloLand command instructions below when the user asks for `ololand-dd-new-deal` or the equivalent workflow.\n\n# New Deal\n\nCreate an OloLand deal in seconds. Type a public ticker (e.g. `SNOW`) and the system auto-pulls the latest canonical annual filing (10-K, 20-F, or 40-F, with substantive exhibits) from the relevant filing source and reports the backend fundamentals source and coverage actually available for that issuer (SEC when enabled). Coverage may be partial or unavailable; a queued filing task is not evidence that a complete financial set exists. Type a private company name and it seeds the workspace from web research — and if that private target has filed a **public** S-1 / IPO-registration statement, the `s1_watcher` pipeline auto-fetches the S-1 into the data room so the analysis can cite it by S-1 page. A **confidential** DRS draft cannot be ingested — its body is sealed at the SEC until conversion to a public S-1, so the read stays press-based until then.\n\n## Usage\n\n```\nololand-dd-new-deal <company name or ticker>\n```\n\n## Arguments\n\n- `<company name or ticker>` (required) — Free text. Examples: `Snowflake`, `SNOW`, `MSFT`, `Stripe`, `stripe.com`.\n\n## Execution\n\nThe instruction below is for the model executing this command.\n\n> **Developer can create deals.** Developer is a bounded single-deal trial — `create_deal` runs on Developer (one active deal, metered against the monthly credit budget). Never pre-refuse deal creation; if the one-deal limit is reached, surface the tool's upgrade CTA.\n\n1. **Resolve the company first.** Call the `resolve_company` MCP tool with the user's query. If the user typed a clean ticker (`SNOW`, `MSFT`, `BRK.B`), pass `hint=\"public\"`. Otherwise leave `hint` unset.\n\n2. **Show the candidates.** If `resolve_company` returns multiple candidates above 0.7 confidence, list them concisely (top 3-5) with name, ticker (if any), exchange, and Public/Private classification. Ask which one the user means. If a single high-confidence match comes back, you can skip the confirmation.\n\n3. **Create the deal.** Call `create_deal` with:\n   - `query` — the user's original text (preserved for the audit trail).\n   - `ticker_override` — set to the picked candidate's ticker (uppercased) if the user disambiguated. This bypasses the resolver so we don't risk a different result the second time.\n   - `cik_override` — set to the picked candidate's CIK if available.\n   - `hint` — `\"public\"` or `\"private\"` if the user was explicit.\n   - `analysis_policy` — `\"screen\"` (default) or `\"full\"`. Prefer this canonical analysis-depth control. The legacy `deal_mode` (`\"screening\"` / `\"formal_dd\"`) is a compatibility alias; ask only if the user signals interest in formal DD.\n\n4. **Report what was kicked off.** From the `create_deal` response, tell the user:\n   - The `deal_id` and `classification` (public/private/unresolved).\n   - For public: that the latest canonical annual filing (10-K, 20-F, or 40-F, plus substantive exhibits) is downloading and backend fundamentals coverage is being collected. The `task_id` lets them poll progress; report the returned source and coverage status and do not promise a complete financial set from task dispatch or success alone.\n   - The `resource_uri` (e.g. `ololand://deals/deal_abc123`) — they can subscribe to it via `resources/read` to watch the deal hydrate, instead of repeatedly calling `get_deal`.\n   - A direct link to the deal in the web app: `https://app.ololand.ai/deals/{deal_id}/dataroom` (public) or `https://app.ololand.ai/deals/{deal_id}/summary` (private).\n   - For a private target that has filed an S-1: the S-1 is auto-ingested during creation. Confirm via `list_deal_documents(deal_id)` — an S-1 in the data room shows up as a normal document; a detected-but-not-yet-ingested filing shows up as a `kind=\"pending_filing\"` entry. If it's `pending_ingest`, call `ingest_s1(deal_id)` to fetch it; if it's `sealed`, the draft is confidential and nothing can be pulled yet. **Never tell the user OloLand can't ingest S-1s — it can, for public filings.**\n\n5. **Watch ingestion (optional).** If the user wants live progress, call `check_task_status(task_id)` every ~5 seconds until status is `success` or `failure`. Treat document completion and fundamentals completion as separate signals.\n\n## Disambiguation pattern\n\nOloLand's MCP server runs in stateless mode — there's no mid-tool elicitation. Disambiguation happens here in conversation. The flow is always:\n\n1. `resolve_company(query)` → see candidates.\n2. Pick one (with the user's confirmation when ambiguous).\n3. `create_deal(query, ticker_override=<picked ticker>, cik_override=<picked cik>)` → bypasses re-resolution.\n\nDon't call `create_deal` first when the query could match multiple companies — it will pick the top hit silently, which surprises users. Always resolve first when in doubt.\n\n## After Completion\n\nSuggested next steps to offer the user:\n- `ololand-dd-dd-analyze <deal_id>` — run bounded extraction, risk, and financial-snapshot processing once the annual filing (10-K, 20-F, or 40-F; or ingested S-1) finishes processing. Cross-document reconciliation is a separate explicit action.\n- `ololand-dd-valuation <deal_id> read all` — inspect governed DCF/LBO and source-backed Comps without starting a model run.\n- `ololand-dd-valuation <deal_id> run all` — explicitly create fresh DCF/LBO/Monte Carlo candidates when the user asks to execute new models.\n- `ololand-dd-risk-report <deal_id>` — risk taxonomy breakdown (67 categories / 311 risk factors).\n- `ololand-dd-talk-to-deal <deal_id> \"<question>\"` — voice-optimized Q&A on the deal.\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"
}