Update to OloLand DD

{
  "description": "Use when the user asks to run the OloLand ololand-dd-war-game workflow. Run a competitive strategy simulation using RL/PPO — models 16 quarters of competitive dynamics with market share shifts, pricing pressure, and investment decisions.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 446
    }
  ],
  "name": "ololand-dd-war-game",
  "skill_md_contents": "---\nname: ololand-dd-war-game\ndescription: \"Use when the user asks to run the OloLand ololand-dd-war-game workflow.\\\n  \\ Run a competitive strategy simulation using RL/PPO \\u2014 models 16 quarters of\\\n  \\ competitive dynamics with market share shifts, pricing pressure, and investment\\\n  \\ decisions.\"\n---\n\n\n# Workflow for ololand-dd-war-game\n\nFollow the OloLand command instructions below when the user asks for `ololand-dd-war-game` or the equivalent workflow.\n\n# War Game Simulation\n\nRun an RL-powered competitive strategy simulation for a deal.\n\n## Usage\n\n```\nololand-dd-war-game <deal_id> [scenarios]\n```\n\n## Arguments\n\n- `deal_id` (optional) — The deal to simulate. If omitted, resolve it from the prose (see below).\n- `scenarios` (optional) — Comma-separated: `base_case`, `expansion`, `macro_stress`, `regulated_stress`, or `all`. Default: `base_case`. When the user asks about **regulatory** response, include `regulated_stress`.\n\n## Natural-language invocation (no deal_id)\n\nUsers rarely pass a bare deal_id — they describe a company and a counterfactual, e.g.\n*\"/war-game on Robinhood, assume it built Exchange Funds in-house instead of acquiring Frec/Cache. Competitive and regulatory response?\"* Treat the counterfactual as a caller-supplied hypothetical. If the simulator or required deal evidence is unavailable, relay that result; do not present an empty or inferred result as a simulation.\n\n1. **Resolve the target to an existing deal.** Use `deal-search` / `list_deals` to find an existing deal for the named company. If none exists, say that a deal context is required; do not create one automatically.\n2. **Separate review from execution.** For an audit, review, or read-only request, follow `ololand-dd-plan`: create or reuse the deal conversation session, submit the user's verbatim counterfactual with `submit_plan_for_approval`, render the plan, and stop for approval. After approval, direct the user to continue the same session in the OloLand app or normal SSE/message endpoint with the returned plan payload supplied as `approved_plan` on `SubmitMessageRequest`. That field supplies execution context; it is not a persisted or hash-validated approval identity. Do not call the MCP `ask_deal_agent` or `talk_to_deal` tools for this planned execution because they cannot carry the field; quoted plan prose is not a substitute. If the client cannot use the normal endpoint, report the governed review as unavailable on this rail; do not run a simulation or infer an answer. For a request that explicitly asks to run the simulation, continue to Execution step 1; that is a bounded, fixed-purpose tool call rather than a conversational executor turn.\n3. **Pick scenarios from intent.** \"regulatory response\" → `regulated_stress`; \"across conditions\" / unspecified depth → `all`; otherwise `base_case`.\n4. If the user supplied a custom counterfactual or premise that would change the simulated business, buyer, capability, market, or competitive setup, **fail closed as unsupported on this MCP rail**. `run_war_game_simulation` accepts only `deal_id` and `scenarios`; do not discard the premise, invent an argument, substitute another tool, or run the default deal-context simulation as if it answered the custom question. State that the requested premise cannot be carried by this bounded tool. A plain scenario request with no custom premise may continue to Execution.\n5. Separate factual buyer premises from simulator predictions. Do not claim a buyer/acquirer identity, observed strategy, historical action, expected synergy, or any other real-world premise unless a tenant-authorized returned source supports it with an inline citation. Keep caller-provided buyer premises labeled hypothetical. A completed simulator's modeled strategy, likely action, competitor response, EV distribution, or robustness score may be relayed without a document citation only when it is clearly labeled **simulator prediction** and tied to the exact returned simulation identity and scenario; never restate that prediction as a sourced fact.\n\n## Execution\n\n1. Confirm that the user explicitly requested execution, then call `run_war_game_simulation` from the MCP server with the deal_id and scenarios.\n2. The simulation auto-populates from deal context:\n   - **Focal company**: Revenue, market share, EBITDA margin from financial snapshot\n   - **Competitors**: Extracted from commercial DD, classified by archetype (price leader, innovation leader, fast follower, niche defender, cash cow)\n   - **Market**: TAM, growth rate, switching costs from market intelligence\n3. A MaskablePPO agent runs 1000 episodes of 16-quarter simulations.\n4. Poll progress with `check_task_status` when a task id is returned, then fetch results with `get_war_game_results` when the simulation id or batch id is available.\n5. Relay an unavailable or error status as such. Do not infer scenario output, buyer behavior, or completion from a queued task or missing result. Present predictions only from a completed result that returns its `simulation_id` and `scenario_label`; a task id, batch id, or prose description alone is not prediction provenance.\n\n## Results\n\nFor each completed scenario, report the returned values under a heading such as `Simulator prediction — simulation <simulation_id>, scenario <scenario_label>`. These prediction fields do not need document citations because the simulation identity is their provenance; any factual input or buyer premise repeated alongside them still does. The simulation returns:\n- **Optimal strategy path**: Quarter-by-quarter moves (HOLD, PRICING, PRODUCT, EXPANSION, M&A, COST_CUTTING)\n- **EV distribution**: Mean, median, P5/P25/P75/P95, VaR, CVaR\n- **Critical decision points**: Top 3 non-trivial strategic moves and when to make them\n- **Competitor response patterns**: How competitors react (most active competitor, pricing pressure rate, dominant strategies)\n- **Robustness score**: 0-100 combining EV stability, path consistency, and tail resilience\n\n## Why This Matters\n\nThis is the only RL-based competitive strategy simulator in the M&A market. No competitor has this. It models actual competitive dynamics — market share shifts, moat erosion, R&D investment returns — not just static scenario tables.\n\n## Example\n\n```\nololand-dd-war-game deal123 all\n```\nRuns 4 scenarios (base, expansion, macro stress, regulated stress) and returns a comparison matrix showing how the optimal strategy changes under different market conditions.\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"
}