Update to OloLand DD

{
  "description": "Use when the user asks to run the OloLand ololand-dd-plan workflow. Get a structured plan from OloLand's planner agent BEFORE firing the executor — review the proposed steps, open questions, and tool-call estimate so you can correct course without burning tool calls. The pre-execution gate for non-trivial deal questions.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 442
    }
  ],
  "name": "ololand-dd-plan",
  "skill_md_contents": "---\nname: ololand-dd-plan\ndescription: \"Use when the user asks to run the OloLand ololand-dd-plan workflow.\\\n  \\ Get a structured plan from OloLand's planner agent BEFORE firing the executor\\\n  \\ \\u2014 review the proposed steps, open questions, and tool-call estimate so you\\\n  \\ can correct course without burning tool calls. The pre-execution gate for non-trivial\\\n  \\ deal questions.\"\n---\n\n\n# Workflow for ololand-dd-plan\n\nFollow the OloLand command instructions below when the user asks for `ololand-dd-plan` or the equivalent workflow.\n\n# ololand-dd-plan\n\nYou are running OloLand's planner agent in plan-mode. The planner reads the user's question, the active deal context, and produces a structured `PlanResponse` (steps, open_questions, escalation_required, reasoning, estimated tool calls) — without running any tools, doing any document search, or escalating to templates. It's a single Flash-class call; cheap relative to the executor run that follows.\n\n## Required inputs\n\n1. **deal_id** — the deal the conversation is about.\n2. **session_id** — an active ADK conversation session. If the user doesn't have one, call `create_conversation_session(deal_id)` first and use the returned id.\n3. **message** — the user's question that the planner should plan for. Quote it verbatim — don't paraphrase.\n\n## Action\n\nCall `submit_plan_for_approval` with the three inputs.\n\n## Output\n\nRender the plan in this shape:\n\n```\nProposed plan for: \"<message>\"\n\nSteps\n  1. <step.title> — <step.description>\n     Tools: <step.tools (if any)>\n  2. ...\n\nOpen questions\n  - <q1>\n  - ...\n\nEstimated tool calls: <n>\nEscalation required: <true|false>\nReasoning: <reasoning>\n```\n\nThen ask the user:\n\n> Approve this plan? Reply \"yes\" to approve the handoff, \"no\" to adjust, or rewrite any step. A same-chat \"yes\" records intent only; it does not execute the plan. Execution requires continuing this same session in OloLand's first-party app or normal session endpoint with the returned plan payload supplied as `approved_plan`.\n\nOn approval, continue the **same session** through OloLand's first-party app or\nnormal SSE/message endpoint, attaching the returned plan payload in the\n`approved_plan` field of `SubmitMessageRequest`. This field supplies execution\ncontext; it is not currently a persisted or hash-validated approval identity,\nso do not describe the handoff as tamper-proof or cryptographically bound. The external MCP\n`ask_deal_agent` and `talk_to_deal` tools do not currently accept the normal\nendpoint's `approved_plan` field; do not call them for the planned execution, and\ndo not treat quoted plan prose or a conversational \"yes\" as a substitute for\nthat binding. If the current client cannot send `approved_plan` through the\nnormal session endpoint, stop and report that governed execution is\nunavailable on this rail.\n\nOn rejection, ask what should change and re-plan.\n\n## When to use\n\n- **Before any non-trivial deal question that will be answered by the conversational executor.** \"Write the IC memo\", \"What are the top three risks\", or \"Run the DCF and compare to comps\" should *always* be planned before an agent executor turn.\n- **When the user asked for something ambiguous.** The planner surfaces `open_questions` — let the user resolve those before tool calls fire.\n- **When the user is cost-conscious.** Plan mode is one cheap call; the executor that follows is many. Approving a tight plan beats an executor that escalates because the prompt was vague.\n- **Before any escalation to ic-memo, risk-chat, or forensic-chat templates.** The planner will signal `escalation_required: true` when appropriate.\n\n## When NOT to use\n\n- For lookup-style questions (\"what's the deal id?\", \"how many documents are uploaded?\"). These take one tool call regardless; planning is overhead.\n- For a fixed-purpose deterministic tool that the user explicitly invoked with bounded parameters. The user's explicit run request is the authority for that one named tool; it does not authorize a conversational executor or follow-on writes.\n- For corrections to a previous turn — use `unsupported OpenAI claim-correction workflow (see unsupported-workflows.json)` instead.\n- For methodology questions (\"how does the forensic QoE work?\"). Use `/load-skill` (or `load_skill`) directly.\n\n## Refusing to skip the plan\n\nIf a user repeatedly asks you to \"just answer it\" on a multi-step question, plan anyway and surface the plan in the response. The plan-mode discipline is what makes the executor's tool budget predictable. The agent runtime has a 12-iteration cap per turn; a planless 12-iteration spiral wastes the budget on backtracking.\n\nCompanion skill: `cmd-plan` (auto-loads).\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"
}