Update to OloLand DD

{
  "description": "Use when the user asks to run the OloLand ololand-dd-financing workflow. Prepare acquisition financing for a deal — deterministic financing analysis, capital-provider sourcing prep, rule-governed capital-programme eligibility signals, and internal lender pre-read packages.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 447
    }
  ],
  "name": "ololand-dd-financing",
  "skill_md_contents": "---\nname: ololand-dd-financing\ndescription: \"Use when the user asks to run the OloLand ololand-dd-financing workflow.\\\n  \\ Prepare acquisition financing for a deal \\u2014 deterministic financing analysis,\\\n  \\ capital-provider sourcing prep, rule-governed capital-programme eligibility signals,\\\n  \\ and internal lender pre-read packages.\"\n---\n\n\n# Workflow for ololand-dd-financing\n\nFollow the OloLand command instructions below when the user asks for `ololand-dd-financing` or the equivalent workflow.\n\n# Financing\n\nUse this command when the user asks \"how do I finance this acquisition?\", \"what leverage can this deal support?\", \"which lenders fit this deal?\", \"does this deal qualify for any government/SBA-style capital programme?\", or wants a lender pre-read package prepared.\n\n## Usage\n\n```\nololand-dd-financing <deal_id>                    # status of the deal's financing workflow\nololand-dd-financing <deal_id> analyze [scenario] [lbo_run_id]   # deterministic financing analysis (base|upside|downside)\nololand-dd-financing <deal_id> sourcing [amount] [provider_types] # provider sourcing from the latest (or a named) analysis\nololand-dd-financing <deal_id> lender-package [provider_match_ids] # internal lender pre-read package\nololand-dd-financing <deal_id> programs [jurisdiction] [rails]     # list active rule-governed capital programmes\nololand-dd-financing <deal_id> capital-plan [jurisdiction] [rails] [amount] [financing_run_id]  # build a capital plan (signals only)\nololand-dd-financing <deal_id> eligibility <program_key> [program_version]  # one programme's eligibility signals\n```\n\n## Execution\n\n1. **status** (default) — call `get_financing_workflow_status(deal_id)`. Reports the latest financing analysis, sourcing run, and where the deal sits in the financing workflow.\n2. **analyze** — call `run_financing_analysis(deal_id, scenario)`. This is a deterministic engine run (debt capacity, structure candidates, coverage ratios), optionally seeded from an existing LBO run via `lbo_run_id`. Default scenario is `base`.\n3. **sourcing** — call `prepare_financing_sourcing(deal_id)`, optionally with `requested_financing_amount`, `target_provider_types`, or a specific `financing_run_id`. Returns matched provider types and draft outreach copy for human review.\n4. **lender-package** — call `prepare_financing_lender_package(deal_id)`, optionally scoped to `provider_match_ids` from a sourcing run. Returns an internal pre-read with an application checklist.\n5. **programs** — call `list_capital_programs(deal_id, jurisdiction, rails)`. Read-only; returns programme identity, authority, source reference, and version — never an eligibility determination. `jurisdiction` defaults to `US`. Only an OMITTED `rails` argument defaults to debt-only — if the user wants every rail, pass an explicit empty list, not `None`.\n6. **capital-plan** — call `prepare_capital_plan(deal_id, jurisdiction, rails, financing_run_id, amount)`. Persists a `CapitalPlanRun` (lineage only) reporting programme eligibility **signals and gaps only** — never state that the deal qualifies for or is approved for a programme. Spends no Apollo credits, submits nothing, and does not perform discretionary provider matching (that's `sourcing`, step 3).\n7. **eligibility** — call `evaluate_capital_eligibility(deal_id, program_key, program_version)` for one programme's per-predicate eligibility signals, with rule and evidence citations. Read-only, does not persist a plan run, and is never a verdict.\n8. Pair conclusions with evidence: cite the financing analysis figures the tools return; do not restate them from memory.\n\n## Output\n\n- **Status**: workflow stage, latest analysis id/scenario, sourcing-run summary.\n- **Analysis**: supportable debt, structure candidates, key coverage/leverage ratios, assumptions used.\n- **Sourcing prep**: provider matches (type, fit rationale), draft outreach for review — clearly labeled DRAFT.\n- **Lender package**: pre-read contents and the application checklist, with the in-app `view_url` when returned.\n- **Programs**: programme name, authority, jurisdiction/rail, source reference, version.\n- **Capital plan**: per-programme signals and gaps table — explicitly labeled \"signals only, not a qualification determination.\"\n- **Eligibility**: per-predicate pass/fail/unknown signals with rule and evidence citations, plus counts — never render this as a yes/no verdict.\n\n## Guardrails\n\n- **Prepare-only over this rail.** These tools analyze, match, and draft. Provider enrollment, sending outreach or emails, sharing anything with a lender, and submitting applications are human-approved actions that happen in the OloLand app's Financing flow — never claim to have contacted or applied to anyone.\n- **Never state a deal qualifies for, is eligible for, or is approved for a capital programme.** `capital-plan` and `eligibility` report signals and gaps only; the determination is not this rail's to make.\n- Outreach copy returned by sourcing prep is a draft for human review; present it as such.\n- Financing figures come from the deterministic engine output. Do not blend in your own leverage estimates without labeling them as unverified commentary.\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"
}