Update to Kapa

{
  "description": "Set up a Kapa Zendesk tickets source so support tickets are ingested. Use when the user wants Kapa to answer from their Zendesk support history.",
  "included_files": [],
  "name": "kapa-setup-zendesk-tickets",
  "skill_md_contents": "---\nname: kapa-setup-zendesk-tickets\ndescription: Set up a Kapa Zendesk tickets source so support tickets are ingested. Use when the user wants Kapa to answer from their Zendesk support history.\n---\n\n# Set up Zendesk tickets\n\nConnects through OAuth, so the user approves it in their browser.\n\n## 1. Create the source\n\n`create_zendesk_tickets_source` with `project` and `name`. Keep the id.\n\n## 2. Start the connection\n\n`connect_zendesk_tickets` with the source `id` and the user's `subdomain`, the\nfirst label of their zendesk.com host. For `https://acme.zendesk.com` that is\n`acme`.\n\nIt returns an `auth_url`. **Open it in the user's browser** and ask them to\napprove it there.\n\n## 3. Wait for the user, then check once\n\nThe approval happens in the browser, so there is nothing to poll. Ask the user\nto tell you when they are done, then call `check_zendesk_tickets_connection`\n**once**.\n\n## 4. Ask whether to ingest this at all\n\nSupport tickets routinely contain customer names, email addresses and account\ndetails. Ask whether that should be ingested at all before setting this up on\na project that serves external users.\n\n## 5. Set PII masking\n\nThis source carries customer names, email addresses and account details, so\nset masking up front. Setting it later works, since `update_source` queues the\nalready-ingested items to be reprocessed under the new rules, but that spends\nquota re-reading everything. Doing it first avoids the second pass.\n\nCall `update_source` with `markdown_pii_config` first, for example\n`{\"entities\": [\"EMAIL_ADDRESS\", \"PERSON\", \"PHONE_NUMBER\"]}`. The available\nentities are PHONE_NUMBER, EMAIL_ADDRESS, PERSON, CREDIT_CARD and IBAN_CODE.\nUse `allow_list` for strings that look like PII but should stay, such as a\nsupport alias.\n\nAsk the user what should be redacted. Do not assume, and do not skip this\nbecause they did not raise it.\n\n## 6. Configure what it ingests\n\n`configure_zendesk_tickets` with `auth_method` set to `oauth` and the same\n`subdomain`. Without the auth method the grant is never attached.\n\nShow these options and ask which the user wants. Support tickets are usually\nthe largest source a team has, so say what each filter would leave out rather\nthan applying one silently.\n\n- `ticket_age`: how far back to read, or all history.\n- `statuses` and `priorities`: which tickets to read, or all of them.\n- `tags`: only tickets carrying these tags. `tags_exclude` drops tickets\n  instead.\n\n## Notes\n\nThe grant belongs to whoever approves it, so only that person can configure the\nsource afterwards.\n\n## Finish the job\n\nSaving the configuration starts ingestion. There is no separate publish step.\n\nThen call `list_sources` with `project_id` to confirm what the project holds.\n\n## Shared Kapa workflow rules\n\nTools act as the connected user with that user's project permissions. Resolve the intended project and use only authorized data. Do not invent credentials, source IDs, filters, or tool results. Check the available tool schema before passing arguments.\n\nExplain and obtain approval for ingestion and its quota cost before saving a configuration that starts ingestion or calling `start_crawl`; existing explicit approval for that exact action is sufficient. Ask the user to choose source scope and filters. Validate credentials and discover accessible content before saving. Keep credentials out of visible results, logs, and exported artifacts. Use a secure credential input if the host provides one.\n\nFor a web source, preview the exact configuration and inspect the extracted article content before ingestion. Report queued, running, failed, and completed states accurately. If uncertain about Kapa behavior, use `search_kapa_docs` when available.\n"
}