Update to Unify

{
  "description": "Run Unify agent tasks with the core run_agent → poll_agent → answer_question → read_agent_results loop. Use before starting any Unify run - covers writing effective task briefs, polling cadence, relaying clarification questions, reading results, and error recovery.",
  "included_files": [],
  "name": "agent-runs",
  "skill_md_contents": "---\nname: agent-runs\ndescription: Run Unify agent tasks with the core run_agent → poll_agent → answer_question → read_agent_results loop. Use before starting any Unify run - covers writing effective task briefs, polling cadence, relaying clarification questions, reading results, and error recovery.\n---\n\n# Running the Unify agent\n\nEvery Unify task is one lifecycle: start, poll, (maybe) answer questions, read.\n\n## 1. Start: `run_agent({ prompt })`\n\nReturns `{ runId, threadId, threadLink }` immediately. Write the prompt as a\nbrief to a skilled GTM operator who cannot see your conversation. Include:\n\n- **Entity type and deliverable**: companies or people; inline answer or a DataTable (\"return the results as a DataTable\" for anything more than a couple of records).\n- **Hard filters vs. intent**: exact constraints (industry, headcount, geography, funding stage, titles) separately from fuzzy persona intent (\"technical buyers of data-infrastructure tooling\"). Geography defaults to US, so say otherwise explicitly.\n- **Scale**: target count (\"20 companies\", \"2–3 contacts per company\").\n- **Budget**: if spend matters: \"prefer free sources (Universal Data, CRM)\" or \"cap credit spend at N\".\n- **Approval semantics** for outreach: whether to stop at previews or the user has approved enrolling/sending. Never authorize sending unless your user explicitly did.\n\nPre-answer the obvious clarification dimensions above; the agent pauses to ask\nwhen scope is ambiguous or expensive.\n\n**Show `threadLink` as soon as the run starts.** The run happens in the\nbackground on Unify's side, so the link is what lets the user watch it live —\nintermediate steps, tool calls, and partial results stream into that thread while\nyou poll. Send one short message right after `run_agent` returns that says the\nrun is underway and includes the **bare URL** on its own line (most terminals and\nplain-text clients auto-linkify a raw URL; Markdown link syntax only renders\nwhere Markdown is supported). This is the one user-facing message to send before\na terminal status — everything else about polling stays internal.\n\n`threadId` identifies the thread the agent ran in. Pass it back as\n`run_agent({ prompt, threadId })` for a follow-up task that should build on the\nsame context (same thread, same link) instead of starting cold.\n\n## 2. Poll: `poll_agent({ runId })`\n\nStatuses: `PENDING` (keep polling), `CLARIFICATION_NEEDED`, `READY`, `ERROR`,\n`NOT_FOUND`. Runs commonly take one to several minutes; poll every ~10 seconds\ninitially and back off toward ~30 seconds for long runs. Don't give up; complex\nlist-building runs can run 10+ minutes.\nTreat polling as internal tool work. Do not send user-facing messages that\nmerely announce polling attempts, waits, cadence changes, or unchanged `PENDING`\nstatuses. Beyond the initial \"run started, here's the link\" message, only message\nthe user when input is required, the run reaches a terminal state, or an\nactionable blocker occurs.\n\n## 3. Clarifications: `answer_question({ runId, answers })`\n\nOn `CLARIFICATION_NEEDED`, `poll_agent` returns `questions` (up to 4, each with\n2–4 options). Rules:\n\n- Answer every question in one call, in the same order, with `question` copied\n  **exactly** as returned; the server rejects mismatches.\n- `answer` may be an option label or free text.\n- If your conversation already contains the answer, answer directly; otherwise\n  present the questions and options to your user verbatim and relay their choices.\n- Response is `{ runId, alreadyResuming }`; keep polling either way. If the call\n  fails with a retryable message, retry with the same answers.\n\n## 4. Read: `read_agent_results({ runId })`\n\nOnly for `READY` or `ERROR` runs. Returns\n`{ status, finalAnswer, content, errorMessage, threadLink }`.\n`finalAnswer` is plain text. The result's **structured content** (`content`)\ncarries typed resource references with the exact IDs the loader tools require. A\nDataTable reference includes `tableId` + `versionId` (both needed by\n`load_datatable`), a List reference includes its `listId` (for `load_list`), and\nso on. Take IDs from there rather than parsing them out of the prose.\n\n`threadLink` is the same clickable thread URL `run_agent` returned, and comes\nback for both `READY` and `ERROR` runs. Present it again after relaying results\nso the user can inspect the full thread, intermediate steps, and any generated\nresources in the UI.\n\n**The result is the response; the link is only supporting context.** Never send\nonly the thread link or make the user open it to learn the outcome. Lead with\nthe substantive `finalAnswer` (or a faithful summary when it is long), include\nthe useful records or resource details you loaded, and state errors plainly.\nPut the link last in a short, visually de-emphasized footer such as:\n\n> Run details: <threadLink>\n\nKeep the bare URL visible so terminals and plain-text clients can auto-link it.\nIn clients known to support inline HTML, `<sub>Run details: <threadLink></sub>`\nis also acceptable, but do not rely on font sizing or hide the URL behind\nMarkdown link text.\n\n## Errors\n\n- \"workspace does not have chat funding available\" → billing gate; surface to the user.\n- Rate-limit errors → wait and retry `run_agent` once; don't hammer.\n- `ERROR` status → read `errorMessage`, report it plainly; a fresh, more specific brief often succeeds where a vague one failed.\n- Runs are visible only to the user who created them; don't ask about runIds from other sessions or users.\n"
}