← KapaCONTENT HISTORY

Update to Kapa

Snapshot Oct 7, 2026 · 18:03 UTC · version 0.1.0

Collection source: downloaded plugin package.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Set up a Kapa Jira source so Jira issues are ingested. Use when the user wants Kapa to answer from their Jira issue history.",
  "included_files": [],
  "name": "kapa-setup-jira",
  "skill_md_contents": "---\nname: kapa-setup-jira\ndescription: Set up a Kapa Jira source so Jira issues are ingested. Use when the user wants Kapa to answer from their Jira issue history.\n---\n\n# Set up Jira\n\nJira Cloud only. Jira Server and Data Center are not supported.\n\n## 1. Have the user create an API token\n\nhttps://id.atlassian.com/manage-profile/security/api-tokens. The token carries\nthat account's own access.\n\n## 2. Create the source\n\n`create_jira_source` with `project` and `name`. Keep the returned id.\n\n## 3. Check the credential and list the projects\n\n`validate_jira` with `base_url`, `username` and `api_token`. It answers three\nways, not two: `true`, `\"Unauthorized\"` (the credential is wrong) or\n`\"Not Found\"` (the URL is wrong). Tell the user which of the two they need to\nfix.\n\nThen `list_jira_projects`, `list_jira_statuses`, `list_jira_resolutions` and\n`list_jira_issue_types` show the real options to choose from.\n\nThose four answer with an empty list when something goes wrong, which looks\nidentical to a site with nothing in it. Trust `validate_jira` for credential\nhealth, not an empty list.\n\n## 4. Configure it\n\n`set_jira_config` with `source_jira`, `base_url`, `username` and `api_token`.\n\n- `base_url` is the site root **without `/wiki`**, such as\n  `https://acme.atlassian.net`.\n- `username` is the Atlassian account email the token belongs to.\n- `api_token` is their secret. Ask for it, never invent one.\n\nAsk the user how to narrow it, rather than choosing yourself:\n\n- `ticket_age`: how far back to read by creation date, in months (`1m` to\n  `36m`) or `all`. Left out, this reads every issue ever filed, which on a\n  large site is a lot of content.\n- `projects_include`: which project keys (such as `ENG`) to read, or all.\n- `status_include`, `resolution_include` and `issuetype_include`: the names\n  from the matching list tool, to read only resolved bugs, for example.\n  Left out, each reads every value.\n\n## What it holds\n\nJira issues are problem histories, so they answer \"has this come up before\"\nrather than \"how does this work\". Tell the user that if they are choosing\nbetween sources.\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"
}

SHA-256 of public snapshot: b07b292e1e7d2a80c46f157ae504f947f3d934b1f9197296d779286681a89081