Update to Kapa

{
  "description": "Set up a Kapa OpenAPI source so an API specification is ingested. Use when the user wants Kapa to answer questions about their API endpoints.",
  "included_files": [],
  "name": "kapa-setup-openapi",
  "skill_md_contents": "---\nname: kapa-setup-openapi\ndescription: Set up a Kapa OpenAPI source so an API specification is ingested. Use when the user wants Kapa to answer questions about their API endpoints.\n---\n\n# Set up OpenAPI\n\n## 1. Create the source\n\n`create_openapi_source` with `project` and `name`. Keep the returned id.\n\n## 2. Check the specification\n\n`validate_openapi_url` with `url` confirms the document parses.\n\nOn success it answers with the spec's title and version, and **there is no\n`valid` key**. A failure answers `{\"valid\": false}`. So treat the presence of a\ntitle as success, not the value of `valid`.\n\nReading the title back to the user is a cheap way to confirm the URL points at\nthe spec they meant.\n\n## 3. Configure it\n\n`set_openapi_config` with `source_openapi` and `url`.\n\n`url` must point at the **specification document itself**, the JSON or YAML,\nnot the documentation page that renders it. Swagger 2.0 and OpenAPI 3.x both\nwork.\n\nPass `linked_url` as well. It is the human-readable documentation page, and\nwithout it answers cite the raw specification, which is not useful to a reader.\n\n## Why this often beats crawling the same pages\n\nAPI reference pages usually render their request and response schemas in the\nbrowser, so a web crawl of them captures only a title and a line of\ndescription. The specification is structured, so it gives cleaner coverage of\nevery endpoint. If the user is crawling a documentation site that includes API\nreference pages, suggest excluding those paths from the crawl and adding this\nsource instead.\n\n## Finish the job\n\nSaving the configuration starts ingestion. There is no separate publish step,\nso once the config saves the source is live.\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"
}