[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X4DXTATAN0GFC6BJE46JAS":3,"skill-same:01M6X4DXTATAN0GFC6BJE46JAS":72},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6X4DXTATAN0GFC6BJE46JAS","alerting-oncall",null,"Alert design and on-call practices — severity, runbooks, SLO burn-rate alerting, escalation. Use when designing alerts, writing runbooks, reducing alert fatigue, setting up escalation policies, implementing SLO-based alerting, or improving on-call processes.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Falerting-oncall\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"alerting","oncall","alerting oncall","up","when","implementing","v1","runbooks","fatigue","alerts","call","design","alert","burn-rate","slo","use","severity","escalation","observability","writing","2026-11-10 10:12:30",false,"---\nname: alerting-oncall\ndescription: |\n  Alert design and on-call practices — severity, runbooks, SLO burn-rate alerting, escalation. Use when designing alerts, writing runbooks, reducing alert fatigue, setting up escalation policies, implementing SLO-based alerting, or improving on-call processes.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-alerting-oncall\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: observability\n---\n\n# Alerting & On-Call\n\n## Intro\n\nGood alerting wakes humans only when humans need to act. Severity tiers,\nSLO burn-rate alerting, and runbooks turn noisy thresholds into a calm\non-call rotation. Alert fatigue is the number one quality problem — fix\nit by tracking page volume and deleting low-value alerts.\n\n## Overview\n\n### Severity levels\n\nDefine clear tiers so responders know how urgently to act:\n\n| Severity | Response Time | Action          | Example                                      |\n|----------|---------------|-----------------|----------------------------------------------|\n| **P1 \u002F Critical** | Immediate (\u003C 5 min) | Page on-call, wake people up | Total service outage, data loss, security breach |\n| **P2 \u002F High**     | Within 30 min        | Page during business hours   | Degraded service, error rate > SLO, partial outage |\n| **P3 \u002F Medium**   | Within 4 hours       | Ticket, fix today            | Elevated latency, disk 80% full, cert expiring in 7 days |\n| **P4 \u002F Low**      | Within 1 business day| Ticket, fix this sprint      | Deprecated API usage, non-critical background job failures |\n\nOnly P1 and P2 should page. P3 and P4 must create tickets and never\npage. Every alert has exactly one severity; if you cannot decide, it is\nP3.\n\n### Page vs ticket\n\nThe single most important decision in alert design is whether the alert\npages a human or files a ticket. Page when users are currently\nimpacted, data is at risk, or the situation will get worse without\nintervention. Ticket when the issue can wait hours or days, recovery is\nlikely automatic, or it is a warning about future risk. If the\nresponder's only action is \"acknowledge and wait\", it should be a\nticket. If you page more than twice a week for non-incidents, your\nalerts need tuning.\n\n### SLO-based (burn-rate) alerting\n\nThreshold alerts like \"error rate > 1%\" are noisy. SLO alerting fires\nonly when you are consuming your error budget too fast.\n\n1. Define the SLO (e.g. 99.9% availability over 30 days = 43 min budget)\n2. Compute `burn_rate = actual_error_rate \u002F (1 - SLO_target)`\n3. Use multi-window alerts to suppress false positives:\n   - **Page (P1)**: burn rate > 14.4 over both last 5 min AND last 1 hr\n   - **Page (P2)**: burn rate > 6 over both last 30 min AND last 6 hr\n   - **Ticket (P3)**: burn rate > 3 over both last 2 hr AND last 24 hr\n\nThis alerts early on severe burns and late on slow burns, matching\nhuman response capabilities.\n\n### Runbook minimum\n\nEvery alert that pages must have a runbook with: what the alert means\nin one sentence, likely causes ranked by frequency, diagnosis steps\nwith dashboard and command links, mitigation (quick fix plus\nescalation path), and the team and channel that owns it.\n\n### Alert fatigue prevention\n\nTrack pages per week per person; target less than two pages per\non-call shift. Review every alert weekly — if it fired and no action\nwas taken, delete or downgrade it. Merge per-instance alerts into\nper-service grouped alerts. Set thresholds from percentile baselines,\nnot guesses. Auto-resolve transient spikes within 5 minutes. Silence\nknown alerts proactively during deploys and planned maintenance.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Alerting on causes instead of symptoms.** An alert for \"CPU > 80%\" fires while users are perfectly happy (batch job running) and stays silent while users suffer (single slow database query consuming 0% CPU). Alert on what users experience: latency, error rate, and availability. Surface cause metrics on dashboards for diagnosis, not as alert conditions.\n- **Thresholds chosen by gut feel rather than baseline measurement.** A threshold of 1% error rate will fire constantly on a service that normally runs at 0.8% errors, or stay silent on a service whose normal is 0.1% and which just jumped to 0.9%. Set thresholds from two or more weeks of production baseline, not round numbers.\n- **Alerts without runbooks.** An alert that fires and leaves the on-call engineer to invent the response from scratch means every incident takes longer than it needs to and accumulates inconsistent notes. Every alert that pages must link to a runbook with: what it means, likely causes, diagnosis steps, and mitigation options.\n- **Informational pages — alerts where no action is required.** If the on-call engineer's only response is \"acknowledge and wait for it to auto-resolve\", the alert should not page. Page only when a human must act immediately. Move monitoring-only signals to dashboards or non-paging tickets.\n- **Per-instance alerts in a horizontally scaled fleet.** Alerting separately for each of N identical pods or instances produces N simultaneous pages for a single incident. Group by service or cluster and alert on the service-level SLO, not on individual instance metrics.\n- **Letting noisy alerts persist because \"we'll fix it later.\"** An alert that fires regularly and is routinely ignored trains the team to ignore all alerts. Track alert-to-action rate: if a team acknowledges an alert and takes no action at least 20% of the time, that alert is noise and must be tuned, downgraded, or deleted.\n- **Not pre-silencing alerts during planned maintenance or deploys.** An alert that fires during a known maintenance window generates noise that obscures real problems and burns on-call attention. Proactively silence or downgrade alerts for the duration of any planned operation that will trigger known threshold violations.\n\n## Full reference\n\n### Runbook template\n\n```\n# Alert: \u003Calert_name>\n## What it means\nOne sentence explaining the condition and its user impact.\n\n## Likely causes\n- Cause 1 (most common)\n- Cause 2\n- Cause 3\n\n## Diagnosis steps\n1. Check \u003Cdashboard_link> for the current state\n2. Run \u003Ccommand> to verify the symptom\n3. Check recent deploys: \u003Cdeploy_log_link>\n\n## Mitigation\n- Quick fix: \u003Crollback command or toggle>\n- If that doesn't work: \u003Cescalation path>\n\n## Escalation\n- Team: \u003Cteam_name> (#slack-channel)\n- Secondary: \u003Cperson or team>\n```\n\n### Escalation policy\n\n1. **Primary on-call** responds within the target time for severity\n2. **Auto-escalate** to secondary if not acknowledged within 10 min\n   (P1) or 30 min (P2)\n3. **Escalate to engineering lead** if not resolved within 1 hour (P1)\n   or 4 hours (P2)\n4. **Declare an incident** if multiple P1 alerts fire simultaneously\n   or the issue affects multiple services\n\n### On-call handoff\n\nHand off at a consistent time (e.g. Monday 10:00 local). The outgoing\non-call writes a summary covering active incidents, flaky alerts,\nknown issues, and anything to watch. The incoming on-call reviews and\nacknowledges. Shadow rotations pair new team members with experienced\non-call for 1-2 cycles before they take primary.\n\n### Incident communication\n\nDuring a P1\u002FP2 incident: open an incident channel immediately, post an\ninitial summary (what is broken, who is affected, current severity),\nupdate every 15-30 minutes even if the update is \"still investigating\",\npost to a public status page if external users are affected, and after\nresolution publish a timeline, root cause, and follow-up actions\nwithin 48 hours.\n\n### Anti-patterns\n\n- Alerting on causes instead of symptoms (CPU > 80% rather than\n  latency or error rate)\n- Static thresholds that ignore traffic patterns or seasonality\n- Alerts without runbooks — the responder has to invent the response\n  while paged\n- \"Informational\" pages — if no action is taken, the alert should not\n  page\n- Per-instance alerts in a fleet of N — group them\n- Letting noisy alerts persist because \"we'll fix it later\"\n","# Alerting & On-Call\n\n## Intro\n\nGood alerting wakes humans only when humans need to act. Severity tiers,\nSLO burn-rate alerting, and runbooks turn noisy thresholds into a calm\non-call rotation. Alert fatigue is the number one quality problem — fix\nit by tracking page volume and deleting low-value alerts.\n\n## Overview\n\n### Severity levels\n\nDefine clear tiers so responders know how urgently to act:\n\n| Severity | Response Time | Action          | Example                                      |\n|----------|---------------|-----------------|----------------------------------------------|\n| **P1 \u002F Critical** | Immediate (\u003C 5 min) | Page on-call, wake people up | Total service outage, data loss, security breach |\n| **P2 \u002F High**     | Within 30 min        | Page during business hours   | Degraded service, error rate > SLO, partial outage |\n| **P3 \u002F Medium**   | Within 4 hours       | Ticket, fix today            | Elevated latency, disk 80% full, cert expiring in 7 days |\n| **P4 \u002F Low**      | Within 1 business day| Ticket, fix this sprint      | Deprecated API usage, non-critical background job failures |\n\nOnly P1 and P2 should page. P3 and P4 must create tickets and never\npage. Every alert has exactly one severity; if you cannot decide, it is\nP3.\n\n### Page vs ticket\n\nThe single most important decision in alert design is whether the alert\npages a human or files a ticket. Page when users are currently\nimpacted, data is at risk, or the situation will get worse without\nintervention. Ticket when the issue can wait hours or days, recovery is\nlikely automatic, or it is a warning about future risk. If the\nresponder's only action is \"acknowledge and wait\", it should be a\nticket. If you page more than twice a week for non-incidents, your\nalerts need tuning.\n\n### SLO-based (burn-rate) alerting\n\nThreshold alerts like \"error rate > 1%\" are noisy. SLO alerting fires\nonly when you are consuming your error budget too fast.\n\n1. Define the SLO (e.g. 99.9% availability over 30 days = 43 min budget)\n2. Compute `burn_rate = actual_error_rate \u002F (1 - SLO_target)`\n3. Use multi-window alerts to suppress false positives:\n   - **Page (P1)**: burn rate > 14.4 over both last 5 min AND last 1 hr\n   - **Page (P2)**: burn rate > 6 over both last 30 min AND last 6 hr\n   - **Ticket (P3)**: burn rate > 3 over both last 2 hr AND last 24 hr\n\nThis alerts early on severe burns and late on slow burns, matching\nhuman response capabilities.\n\n### Runbook minimum\n\nEvery alert that pages must have a runbook with: what the alert means\nin one sentence, likely causes ranked by frequency, diagnosis steps\nwith dashboard and command links, mitigation (quick fix plus\nescalation path), and the team and channel that owns it.\n\n### Alert fatigue prevention\n\nTrack pages per week per person; target less than two pages per\non-call shift. Review every alert weekly — if it fired and no action\nwas taken, delete or downgrade it. Merge per-instance alerts into\nper-service grouped alerts. Set thresholds from percentile baselines,\nnot guesses. Auto-resolve transient spikes within 5 minutes. Silence\nknown alerts proactively during deploys and planned maintenance.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Alerting on causes instead of symptoms.** An alert for \"CPU > 80%\" fires while users are perfectly happy (batch job running) and stays silent while users suffer (single slow database query consuming 0% CPU). Alert on what users experience: latency, error rate, and availability. Surface cause metrics on dashboards for diagnosis, not as alert conditions.\n- **Thresholds chosen by gut feel rather than baseline measurement.** A threshold of 1% error rate will fire constantly on a service that normally runs at 0.8% errors, or stay silent on a service whose normal is 0.1% and which just jumped to 0.9%. Set thresholds from two or more weeks of production baseline, not round numbers.\n- **Alerts without runbooks.** An alert that fires and leaves the on-call engineer to invent the response from scratch means every incident takes longer than it needs to and accumulates inconsistent notes. Every alert that pages must link to a runbook with: what it means, likely causes, diagnosis steps, and mitigation options.\n- **Informational pages — alerts where no action is required.** If the on-call engineer's only response is \"acknowledge and wait for it to auto-resolve\", the alert should not page. Page only when a human must act immediately. Move monitoring-only signals to dashboards or non-paging tickets.\n- **Per-instance alerts in a horizontally scaled fleet.** Alerting separately for each of N identical pods or instances produces N simultaneous pages for a single incident. Group by service or cluster and alert on the service-level SLO, not on individual instance metrics.\n- **Letting noisy alerts persist because \"we'll fix it later.\"** An alert that fires regularly and is routinely ignored trains the team to ignore all alerts. Track alert-to-action rate: if a team acknowledges an alert and takes no action at least 20% of the time, that alert is noise and must be tuned, downgraded, or deleted.\n- **Not pre-silencing alerts during planned maintenance or deploys.** An alert that fires during a known maintenance window generates noise that obscures real problems and burns on-call attention. Proactively silence or downgrade alerts for the duration of any planned operation that will trigger known threshold violations.\n\n## Full reference\n\n### Runbook template\n\n```\n# Alert: \u003Calert_name>\n## What it means\nOne sentence explaining the condition and its user impact.\n\n## Likely causes\n- Cause 1 (most common)\n- Cause 2\n- Cause 3\n\n## Diagnosis steps\n1. Check \u003Cdashboard_link> for the current state\n2. Run \u003Ccommand> to verify the symptom\n3. Check recent deploys: \u003Cdeploy_log_link>\n\n## Mitigation\n- Quick fix: \u003Crollback command or toggle>\n- If that doesn't work: \u003Cescalation path>\n\n## Escalation\n- Team: \u003Cteam_name> (#slack-channel)\n- Secondary: \u003Cperson or team>\n```\n\n### Escalation policy\n\n1. **Primary on-call** responds within the target time for severity\n2. **Auto-escalate** to secondary if not acknowledged within 10 min\n   (P1) or 30 min (P2)\n3. **Escalate to engineering lead** if not resolved within 1 hour (P1)\n   or 4 hours (P2)\n4. **Declare an incident** if multiple P1 alerts fire simultaneously\n   or the issue affects multiple services\n\n### On-call handoff\n\nHand off at a consistent time (e.g. Monday 10:00 local). The outgoing\non-call writes a summary covering active incidents, flaky alerts,\nknown issues, and anything to watch. The incoming on-call reviews and\nacknowledges. Shadow rotations pair new team members with experienced\non-call for 1-2 cycles before they take primary.\n\n### Incident communication\n\nDuring a P1\u002FP2 incident: open an incident channel immediately, post an\ninitial summary (what is broken, who is affected, current severity),\nupdate every 15-30 minutes even if the update is \"still investigating\",\npost to a public status page if external users are affected, and after\nresolution publish a timeline, root cause, and follow-up actions\nwithin 48 hours.\n\n### Anti-patterns\n\n- Alerting on causes instead of symptoms (CPU > 80% rather than\n  latency or error rate)\n- Static thresholds that ignore traffic patterns or seasonality\n- Alerts without runbooks — the responder has to invent the response\n  while paged\n- \"Informational\" pages — if no action is taken, the alert should not\n  page\n- Per-instance alerts in a fleet of N — group them\n- Letting noisy alerts persist because \"we'll fix it later\"\n",{"name":5,"metadata":44,"description":50},{"processkit":45},{"id":46,"created":47,"version":48,"category":37,"apiVersion":49},"SKILL-alerting-oncall",1775433600000,"1.1.0","processkit.projectious.work\u002Fv1","Alert design and on-call practices — severity, runbooks, SLO burn-rate alerting, escalation. Use when designing alerts, writing runbooks, reducing alert fatigue, setting up escalation policies, implementing SLO-based alerting, or improving on-call processes.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Falerting-oncall","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add projectious-work\u002Fprocesskit --skill alerting-oncall",{"tool":64,"command":65},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill alerting-oncall",{"tool":67,"command":68},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill alerting-oncall","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Falerting-oncall\u002FSKILL.md",true,[],[73,100,120,141,158,176],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":84,"publishedAt":39},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[85,86,87,88,89,90,91,92,93,94,75,95,96,97,25,98,99],"management","skill management","create","update","package","alpha","work","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":107,"publishedAt":39},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[106],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[85,108,109,110,111,112,90,91,113,114,93,115,116,117,95,118,119],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":39},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[85,127,128,87,88,129,90,91,130,131,132,133,95,134,135,136,137,138,139,140],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":39},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[85,94,148,87,90,149,150,113,151,130,93,152,153,95,154,155,135,156,25,157],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":39},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[165,166,167,168,90,169,170,171,91,172,173,174,175],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":39},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[85,183,184,87,88,129,90,149,91,92,130,185,93,132,95,155,135,136,186,99],"capability","capability management","queries","changes"]