← KapaCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Kapa
Snapshot Oct 7, 2026 · 18:03 UTC · version 0.1.0
Collection source: downloaded plugin package.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Set up a Kapa Jira Service Management source so service desk requests are ingested. Use when the user wants Kapa to answer from their JSM request history.",
"included_files": [],
"name": "kapa-setup-jira-service-management",
"skill_md_contents": "---\nname: kapa-setup-jira-service-management\ndescription: Set up a Kapa Jira Service Management source so service desk requests are ingested. Use when the user wants Kapa to answer from their JSM request history.\n---\n\n# Set up Jira Service Management\n\n## 1. Have the user create an API token\n\nhttps://id.atlassian.com/manage-profile/security/api-tokens.\n\n## 2. Create the source\n\n`create_jira_service_management_source` with `project` and `name`. Keep the id.\n\n## 3. Check the credential and list the desks\n\n`validate_jira_service_management` with `base_url`, `username` and `api_token`\nanswers `{\"is_valid\": bool}`. Read the message back to the user on a failure:\na bad URL, a bad credential and a permissions problem all answer the same way.\n\nThen `list_jira_service_desks` shows the desks, and `list_jira_request_types`\nthe request types.\n\nThe request types cannot be scoped to one desk and carry no desk id, so names\nrepeat across desks. Show the whole list rather than matching on a name.\n\n## 4. Ask whether to ingest this at all\n\nService desk requests often carry customer names, email addresses and private\ninternal comments. Ask whether that content should be ingested at all before\nsetting this up on a 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 it\n\n`set_jira_service_management_config` with `source_jira_service_management`,\n`base_url`, `username` and `api_token`.\n\n- `base_url` is the site root, such as `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\n**Say what the age filter does before accepting it.** `request_age` limits how\nfar back requests are read, and the dashboard's own default is the last month\nonly. Tell the user the window you are setting and confirm it, rather than\nquietly ingesting four weeks of a multi-year desk.\n\nAsk which desks to read. `service_desk_ids_include` takes the ones the user\npicks, and leaving it out reads every desk on the site. Use\n`list_jira_service_desks` to show them the real names rather than asking for\nids.\n\nAsk which request types to read as well. `request_type_ids_include` and\n`request_type_ids_exclude` take ids from `list_jira_request_types`.\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: 21ef8cf9bccf43e526e307731b99fb2498f387296b2ac6bee55396cb210d6b3a