Update to OloLand DD

{
  "description": "Use when the user asks to run the OloLand ololand-dd-source workflow. Map private companies, review a sourced target brief, inspect data-source access, or prepare a deal-sourcing pipeline.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 419
    }
  ],
  "name": "ololand-dd-source",
  "skill_md_contents": "---\nname: ololand-dd-source\ndescription: Use when the user asks to run the OloLand ololand-dd-source workflow.\n  Map private companies, review a sourced target brief, inspect data-source access,\n  or prepare a deal-sourcing pipeline.\n---\n\n\n# Workflow for ololand-dd-source\n\nFollow the OloLand command instructions below when the user asks for `ololand-dd-source` or the equivalent workflow.\n\n# Deal Sourcing\n\nEnd-to-end sourcing pipeline that compounds: every selected company persists in\nthe tenant-owned sourcing ledger before contact enrichment or outreach begins.\n\n## Usage\n\n```\nololand-dd-source <criteria>\nololand-dd-source map private ecommerce seller software, trust and fulfillment tools\nololand-dd-source brief <watchlist_id> since 2026-09-21\nololand-dd-source connections\n```\n\nIf no criteria are provided, ask for capabilities or sector, geography, stage\nor size preferences, and exclusions. Early-stage capability searches need not\nhave revenue or EBITDA data; keep unavailable financials unknown.\n\n## Select the workflow\n\nRoute `connections`, `brief`, and `map` before thesis/default sourcing intent.\nRequests for a company landscape, database, or research-only shortlist use\n`map`; requests to review an existing pipeline or prepare its weekly brief use\n`brief`. These modes do not capture contacts, draft outreach, promote deals,\nor activate delivery. A recurring-delivery request is a separate scheduling\ntask, not satisfied by generating a brief.\n\nExecute exactly one branch and return its output. After `connections`, `brief`,\nor `map` completes, stop; never fall through to the default sourcing pipeline\nor its contact/outreach steps. Only a separate user request can start another\nbranch.\n\nIf a request combines mapping with creating/updating a standing thesis and\ndoes not choose which to do first, resolve that order before any write. Do not\nsilently discard one intent or chain the two write workflows.\n\n### Connections — establish what can actually be read\n\nInventory only tools available in this session. The plugin declares OloLand's\nMCP server; it does not install or authenticate Google Drive, Slack, Gmail,\nCalendar, Obsidian, or an internal forum connector.\n\nIf the host already exposes a source connector, use it for a small read of a\nuser-selected permitted source. Report the source reference, access outcome,\nand intended use. Do not infer working access from the presence of a tool.\nWhen no connector is available, report that gap and use a selected-file import\nor the client's connector setup flow. Never request tokens in chat.\n\nHost tools can contribute evidence to this conversation. Their credentials and\npermissions do not transfer to OloLand, and an interactive read does not create\na persistent OloLand source or authorize a scheduled job. Before passing\nprivate excerpts to OloLand, establish that this transfer is within the user's\nrequested scope and use only necessary content with source references. Never\ninclude private notes, strategy, or source excerpts in public-web queries.\n\nFor the OloLand application, direct the user to Settings → Connect data sources\n(`/integrations`; older versions label it Integrations). The current Google\nconnection supports Drive import and Home assistant reads. For deal analysis,\nimport selected documents into that deal's Data Room and verify they appear\nand are retrievable. Connecting alone does not sync a vault or import files.\nThe Gmail connection is send/metadata access, not inbox-content retrieval;\ndo not claim Calendar or Slack access from the Google connection. Connected\nApps lists agents authorized to access OloLand, not external data sources.\n\nReturn a table: source, access path, tested read, persistence, remaining step.\n\n### Map — persist a research universe without outreach\n\nLoad the `deal-sourcing` skill's research-only workflow. Run discovery and\ndurable mandate/candidate persistence (steps 1–3 below) and then stop before\ncontact capture. Call `list_watchlists` first to reuse a materially\nidentical mandate. Pass actual discovery results unchanged to persistence;\nnever fabricate discovery IDs or disguise hand-researched rows as returned\nobjects. If OloLand access is unavailable, provide a clearly labeled local\nresearch artifact and state that it has not been saved to the tenant ledger.\nThe preserved discovery snapshot can include contact fields already returned\nby discovery; research-only means no separate contact-graph import or outreach,\nnot a guarantee that the snapshot contains no contact data.\n\nInclude capability/category, stage and ownership evidence (or unknown),\nsource/date, fit hypothesis, uncertainty, actual saved stage, and next research\naction. Stage and private status require evidence; absence of a stock ticker\nis not proof. Keep evidence completeness separate from strategic fit.\n\n### Brief — read an existing sourcing ledger\n\n1. If the watchlist ID is missing, call `list_watchlists` and\n   resolve the intended mandate; do not create one as a side effect.\n2. Call `list_watchlist_matches` with that `watchlist_id`,\n   `include_dismissed: true`, `skip: 0`, and `limit: 100`. Page using `skip`\n   until `total` is covered, or state the exact reviewed subset if bounded.\n   Preserve passed/dismissed dispositions; they are not new recommendations.\n3. If a comparison date is supplied, classify new-to-ledger candidates using\n   `first_matched_at`. A newer `last_signal_at` or `updated_at` identifies a\n   record to inspect, not proof of a material business change. Use dated\n   evidence to explain an update. Without a prior brief/baseline, label the\n   result an initial snapshot; never invent week-over-week change.\n4. Review supporting `evidence_refs` and any permitted public sources. Select\n   up to 5–10 relevant, non-passed candidates; use fewer if evidence is weak.\n   Distinguish new discoveries, evidenced updates, unchanged watch items,\n   and research gaps. Report any reconsideration of a passed company\n   separately, with its original reason and new evidence; do not change it.\n5. For each item show the company/domain, mandate fit hypothesis, what changed\n   (or initial discovery), dated sources, uncertainty, and next action. Return\n   the actual `view_url` and covered period. Save/update/promote/contact/send\n   tools are out of scope for this read-only mode.\n\nA brief generated here is an on-demand draft. Search Monitor is the sourcing\nledger; existing in-app briefings and environment-controlled digest delivery\nhave their own cadence. Do not claim a Monday schedule, delivery, or background\nsource access without an actual configured schedule and execution evidence.\nThe unrelated marketing weekly briefing is not a tenant sourcing scheduler.\n\n## Default sourcing pipeline — `ololand-dd-source <criteria>` only\n\nThis section is not executed for `connections`, `brief`, or `map`. For remaining\nrequests, first classify the request. If it asks to create, list, update, deactivate, or\nreview matches for a standing thesis, route directly to the thesis operations\nbelow. Do not load `deal-sourcing` or run the one-off discovery, watchlist,\ncandidate-persistence, contact-import, or outreach pipeline for a thesis\nrequest. Otherwise, load the `deal-sourcing` skill and run this pipeline:\n\n1. **Discover targets** — call `search_company_discovery` with:\n   - `query`: the user's sector/product/market thesis\n   - `mode: \"discover\"`\n   - `company_scope: \"private\"` unless the user explicitly includes public targets\n   - `filters`: geography, industry/sector, ownership, size, and negative filters\n   - `limit: 25`\n   Use `natural_language_company_search` only when the criteria\n   cannot be represented as structured filters.\n2. **Create the mandate** — call `create_watchlist` with the\n   user's original criteria and a descriptive name. Reuse an existing watchlist\n   only when its criteria are materially identical.\n3. **Persist candidates immediately** — pass the selected discovery result\n   objects unchanged to `save_sourcing_candidates`, with\n   `watchlist_id` set to the ID returned or reused in step 2 and `candidates`\n   set to the selected result objects. This captures the source snapshot,\n   evidence references, match rationale, and candidate stage before any\n   third-party enrichment. Repeated calls are idempotent.\n4. **Capture supported contacts** — when a discovery result includes an\n   executive with a real email, phone number, or LinkedIn URL, select at most\n   one founder/CEO/CFO and pass that returned evidence to\n   `openclaw_import_contacts` with\n   `source_system: \"company_discovery\"`. OloLand performs tenant-scoped identity\n   dedupe and central do-not-contact checks. If discovery did not return usable\n   contact evidence, leave the candidate shortlisted and report the gap.\n5. **Link the relationship** — call\n   `update_sourcing_candidate` with the step-2 `watchlist_id`,\n   saved candidate `match_id`, resulting `outreach_contact_id`, and\n   `sourcing_stage: \"enriched\"`.\n6. **Find a hook** — prefer the candidate's returned `search_snippets`,\n   `signal_summary`, and `ma_signal_summary`. If those are insufficient, perform\n   a current public-web search for a funding round, hiring spike, leadership\n   change, product launch, or expansion. Do not call deal-scoped research tools\n   before a Deal exists.\n7. **Prepare outreach copy** — write a 60-90 word proposed email in the command\n   response using the specific hook. This is reviewable copy, not a Gmail or\n   OloLand outreach draft, and it is never sent. Keep the candidate at\n   `enriched` (or `shortlisted` when no contact was captured).\n\nThis plugin declares only the OloLand MCP server. Do not claim Apollo or Gmail\noperations, and do not fabricate contact or draft IDs.\n\n## Default sourcing output\n\nReport a table:\n\n| Company | Contact evidence | Hook | Candidate stage | Outreach copy |\n\nPlus a summary: N discovered, M saved, D deduped/updated, C contacts captured.\n\n## After default sourcing completion\n\n- Suggest `ololand-dd-dd-analyze <company>` for the most promising target.\n- Remind the user: the proposed copy was not saved or sent; move it to the\n  firm's approved outreach system only after review.\n\n## Standing sourcing mandates (thesis)\n\nA watchlist (steps 2-5 above) is a one-off discovery run's persistence layer.\nA **thesis** is a different, longer-lived object: a standing sourcing mandate\n(sectors, sub-sectors, geography, financial parameters, deal types,\nqualitative criteria) that the signal pipeline continuously matches against,\nsurfacing hits in the Search Monitor over time. These are sourcing mandates,\n**not strategy or SWOT frameworks** — do not describe them that way.\n\nUse this when the user wants to save standing acquisition criteria rather\nthan run a one-time discovery pass:\n\n- **Create** — call `create_thesis` with `thesis_name` and\n  whichever of `description`, `fund_name`, `sectors`, `sub_sectors`,\n  `geography`, `geography_exclusions`, `financial_parameters`, `deal_types`,\n  `qualitative_criteria`, `signal_config` the user specified.\n- **List** — call `list_theses`, optionally filtered by\n  `status` (`active` | `paused` | `closed`), before creating a new one — reuse\n  an existing mandate whose criteria materially overlap rather than\n  duplicating it.\n- **Update** — call `update_thesis` with `thesis_id` and only\n  the fields that changed; omitted fields are left alone.\n- **Deactivate** — call `deactivate_thesis` with `thesis_id`\n  (default `status=\"paused\"`, reversible — never a hard delete; pass\n  `status=\"closed\"` when the user means it's done for good). Reactivate with\n  `update_thesis(thesis_id, status=\"active\")`.\n- **Review matches** — call `list_thesis_matches(thesis_id)` for\n  the mandate's current non-dismissed signal matches, highest composite score\n  first. Promising matches still go through the discovery pipeline above\n  (persist as a sourcing candidate, capture supported contacts) before any\n  outreach copy is drafted.\n\nReport the `view_url` each call returns (the Search Monitor tab) rather than\nconstructing a link.\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"
}