[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NQCE5AVX9D188TYRZ2GKG0":3,"skill-same:01M6NQCE5AVX9D188TYRZ2GKG0":130},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":80,"commitSha":81,"skillDirectory":82,"forksCount":14,"repositoryHtmlUrl":83,"repositoryHomepageUrl":84,"ownerHtmlUrl":85,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":86,"install":87,"resources":100},"01M6NQCE5AVX9D188TYRZ2GKG0","gate-management",null,"Manage Gate entities — validation checkpoints that WorkItems, scopes, or\npolicy applications must pass (code review, security scan, tests). Use\nwhen defining or updating a checkpoint for v2 workflow surfaces — code\nreview, tests green, security scan, stakeholder approval.","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\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fgate-management\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"gate management","gate","management","list","fresh","get","green","query","surfaces","log","code review","write","work","sqlite","audit","security scan","code","create","workflow","review","2026-11-10 10:12:30",false,"---\nname: gate-management\ndescription: |\n  Manage Gate entities — validation checkpoints that WorkItems, scopes, or\n  policy applications must pass (code review, security scan, tests). Use\n  when defining or updating a checkpoint for v2 workflow surfaces — code\n  review, tests green, security scan, stakeholder approval.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv2\n    id: SKILL-gate-management\n    version: \"1.0.0\"\n    created: 2026-04-06T00:00:00Z\n    category: processkit\n    layer: 3\n    uses:\n      - skill: event-log\n        purpose: Log events to keep the audit trail accurate after every write.\n      - skill: index-management\n        purpose: Query existing entities and keep the SQLite index fresh after writes.\n      - skill: id-management\n        purpose: Allocate unique entity identifiers via central ID generation.\n    provides:\n      primitives: [Gate]\n      mcp_tools:\n        - create_gate\n        - get_gate\n        - list_gates\n        - evaluate_gate\n      templates: [gate]\n---\n\n# Gate Management\n\n## Intro\n\nA Gate is a validation checkpoint — \"code review passed\", \"tests green\",\n\"security scan clean\", \"stakeholder signed off\". In v2, Bindings attach\ngates to concrete workflow surfaces such as WorkItems and Scopes.\n\n> **MCP server.** This skill ships a self-contained MCP server at\n> `mcp\u002Fserver.py` (PEP 723 script — requires `uv` and Python ≥ 3.10 on\n> PATH). Agent harnesses reach its tools by reading a single MCP config\n> file at startup, so the contents of `mcp\u002Fmcp-config.json` must be merged\n> into the harness's MCP config and placed at the harness-specific path\n> before this skill is usable. If processkit was installed by an installer,\n> that wiring is the installer's responsibility; if processkit was\n> installed manually, the project owner must do it by hand.\n\n## Overview\n\n### Shape\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv2\nkind: Gate\nmetadata:\n  id: GATE-code-review\n  created: 2026-04-06T00:00:00Z\nspec:\n  name: code-review\n  description: \"At least one reviewer has approved the change.\"\n  kind: manual           # manual | automated | hybrid\n  validator: \"A second actor reviews and approves.\"\n  required_roles: [reviewer]\n  blocking: true         # if false, gate is advisory only\n---\n```\n\n### Workflow\n\n1. Pick `GATE-\u003Cname>` where name is a short noun phrase.\n2. Set `kind`: `manual` (human does it), `automated` (check runs automatically),\n   or `hybrid` (both).\n3. Describe the `validator` — the concrete check. One or two sentences.\n4. List `required_roles` if specific actors must do the validation.\n5. Set `blocking: true` for hard gates (cannot proceed), `false` for advisory.\n\n### Gate outcomes\n\nGates emit LogEntries when they are evaluated:\n- `gate.passed` — validation succeeded\n- `gate.failed` — validation failed (include failure details)\n- `gate.waived` — validation was bypassed (include `details.waived_by` and reason)\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Defining a Gate without an evaluator.** A Gate that says \"code\n  review passed\" but doesn't say HOW that's checked is decoration,\n  not a checkpoint. Every Gate must have either an automated check\n  (script, MCP tool, CI job) or a clearly named manual approver.\n- **Auto-approving manual gates.** If a Gate is `kind: manual`, the\n  agent does NOT have authority to mark it passed. Surface the gate\n  to the user, ask for explicit approval, and only then call\n  `evaluate_gate` with the approver's ACTOR-ID.\n- **Missing the rollback path on failure.** Every Gate that can fail\n  must specify what happens when it does — block the process, page\n  oncall, escalate, defer to a different gate. A Gate that fails\n  silently is worse than no gate.\n- **Writing gates that are too coarse.** \"Tests pass\" is too vague —\n  which suite? Which subset? With what coverage threshold?\n  Granularity matters because the agent needs to know what\n  specifically is being checked when the gate is invoked.\n- **Forgetting to log `gate.passed` \u002F `gate.failed` \u002F `gate.waived`.**\n  These events are how the audit trail tracks process health. If\n  you evaluate a gate without logging the outcome, the index can't\n  answer \"how often does this gate fail\" or \"who waived it last\".\n- **Hand-waving \"automated\" gates that aren't actually wired.** If\n  `kind: automated`, the evaluator must exist and be runnable from\n  the agent's environment. Marking a gate automated when it\n  actually requires a human is a process failure dressed as a\n  technical one.\n- **Treating gate failures as warnings.** Gates are blockers by\n  design. If a Gate fails, the dependent process step does NOT\n  proceed, even under pressure. If the user wants to bypass, that's\n  a `gate.waived` event with the waiver's name and reason — never\n  an unrecorded continuation.\n\n## Full reference\n\n### Fields\n\n| Field             | Type          | Notes                                          |\n|-------------------|---------------|------------------------------------------------|\n| `name`            | string        | Short kebab-case identifier                    |\n| `description`     | string        | What this gate checks                          |\n| `kind`            | enum          | `manual` \u002F `automated` \u002F `hybrid`              |\n| `validator`       | string        | Prose description of the check                 |\n| `validator_command` | string      | Optional. CLI command that automates the check |\n| `required_roles`  | list[string]  | Roles that can sign off                        |\n| `blocking`        | bool          | `true` = cannot proceed if failed              |\n| `evidence_required` | bool        | Require a link\u002Fartifact in the pass event      |\n\n### Binding gates to v2 workflow surfaces\n\nUse `workitem-gate` for a concrete run or task, and `scope-gate` for a\ngate that applies across a Scope. Legacy `process-gate` Bindings are\nmigration-only.\n\n```yaml\nkind: Binding\nspec:\n  type: workitem-gate\n  subject: BACK-release-run\n  target: GATE-security-scan\n  scope: SCOPE-project-x\n```\n\nThis way the same Gate can apply to multiple runs or scopes, and the\nmapping changes without editing the Gate or governed entity.\n\n### Waiving a gate\n\nIf a blocking gate is bypassed, log `gate.waived` with `details.waived_by`\n(actor ID), `details.reason`, and `details.expires_at`. Do not edit the\nGate definition — the waiver is an event, not a property.\n","# Gate Management\n\n## Intro\n\nA Gate is a validation checkpoint — \"code review passed\", \"tests green\",\n\"security scan clean\", \"stakeholder signed off\". In v2, Bindings attach\ngates to concrete workflow surfaces such as WorkItems and Scopes.\n\n> **MCP server.** This skill ships a self-contained MCP server at\n> `mcp\u002Fserver.py` (PEP 723 script — requires `uv` and Python ≥ 3.10 on\n> PATH). Agent harnesses reach its tools by reading a single MCP config\n> file at startup, so the contents of `mcp\u002Fmcp-config.json` must be merged\n> into the harness's MCP config and placed at the harness-specific path\n> before this skill is usable. If processkit was installed by an installer,\n> that wiring is the installer's responsibility; if processkit was\n> installed manually, the project owner must do it by hand.\n\n## Overview\n\n### Shape\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv2\nkind: Gate\nmetadata:\n  id: GATE-code-review\n  created: 2026-04-06T00:00:00Z\nspec:\n  name: code-review\n  description: \"At least one reviewer has approved the change.\"\n  kind: manual           # manual | automated | hybrid\n  validator: \"A second actor reviews and approves.\"\n  required_roles: [reviewer]\n  blocking: true         # if false, gate is advisory only\n---\n```\n\n### Workflow\n\n1. Pick `GATE-\u003Cname>` where name is a short noun phrase.\n2. Set `kind`: `manual` (human does it), `automated` (check runs automatically),\n   or `hybrid` (both).\n3. Describe the `validator` — the concrete check. One or two sentences.\n4. List `required_roles` if specific actors must do the validation.\n5. Set `blocking: true` for hard gates (cannot proceed), `false` for advisory.\n\n### Gate outcomes\n\nGates emit LogEntries when they are evaluated:\n- `gate.passed` — validation succeeded\n- `gate.failed` — validation failed (include failure details)\n- `gate.waived` — validation was bypassed (include `details.waived_by` and reason)\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Defining a Gate without an evaluator.** A Gate that says \"code\n  review passed\" but doesn't say HOW that's checked is decoration,\n  not a checkpoint. Every Gate must have either an automated check\n  (script, MCP tool, CI job) or a clearly named manual approver.\n- **Auto-approving manual gates.** If a Gate is `kind: manual`, the\n  agent does NOT have authority to mark it passed. Surface the gate\n  to the user, ask for explicit approval, and only then call\n  `evaluate_gate` with the approver's ACTOR-ID.\n- **Missing the rollback path on failure.** Every Gate that can fail\n  must specify what happens when it does — block the process, page\n  oncall, escalate, defer to a different gate. A Gate that fails\n  silently is worse than no gate.\n- **Writing gates that are too coarse.** \"Tests pass\" is too vague —\n  which suite? Which subset? With what coverage threshold?\n  Granularity matters because the agent needs to know what\n  specifically is being checked when the gate is invoked.\n- **Forgetting to log `gate.passed` \u002F `gate.failed` \u002F `gate.waived`.**\n  These events are how the audit trail tracks process health. If\n  you evaluate a gate without logging the outcome, the index can't\n  answer \"how often does this gate fail\" or \"who waived it last\".\n- **Hand-waving \"automated\" gates that aren't actually wired.** If\n  `kind: automated`, the evaluator must exist and be runnable from\n  the agent's environment. Marking a gate automated when it\n  actually requires a human is a process failure dressed as a\n  technical one.\n- **Treating gate failures as warnings.** Gates are blockers by\n  design. If a Gate fails, the dependent process step does NOT\n  proceed, even under pressure. If the user wants to bypass, that's\n  a `gate.waived` event with the waiver's name and reason — never\n  an unrecorded continuation.\n\n## Full reference\n\n### Fields\n\n| Field             | Type          | Notes                                          |\n|-------------------|---------------|------------------------------------------------|\n| `name`            | string        | Short kebab-case identifier                    |\n| `description`     | string        | What this gate checks                          |\n| `kind`            | enum          | `manual` \u002F `automated` \u002F `hybrid`              |\n| `validator`       | string        | Prose description of the check                 |\n| `validator_command` | string      | Optional. CLI command that automates the check |\n| `required_roles`  | list[string]  | Roles that can sign off                        |\n| `blocking`        | bool          | `true` = cannot proceed if failed              |\n| `evidence_required` | bool        | Require a link\u002Fartifact in the pass event      |\n\n### Binding gates to v2 workflow surfaces\n\nUse `workitem-gate` for a concrete run or task, and `scope-gate` for a\ngate that applies across a Scope. Legacy `process-gate` Bindings are\nmigration-only.\n\n```yaml\nkind: Binding\nspec:\n  type: workitem-gate\n  subject: BACK-release-run\n  target: GATE-security-scan\n  scope: SCOPE-project-x\n```\n\nThis way the same Gate can apply to multiple runs or scopes, and the\nmapping changes without editing the Gate or governed entity.\n\n### Waiving a gate\n\nIf a blocking gate is bypassed, log `gate.waived` with `details.waived_by`\n(actor ID), `details.reason`, and `details.expires_at`. Do not edit the\nGate definition — the waiver is an event, not a property.\n",{"name":5,"metadata":52,"description":79},{"processkit":53},{"id":54,"uses":55,"layer":65,"created":66,"version":67,"category":68,"provides":69,"apiVersion":78},"SKILL-gate-management",[56,59,62],{"skill":57,"purpose":58},"event-log","Log events to keep the audit trail accurate after every write.",{"skill":60,"purpose":61},"index-management","Query existing entities and keep the SQLite index fresh after writes.",{"skill":63,"purpose":64},"id-management","Allocate unique entity identifiers via central ID generation.",3,1775433600000,"1.0.0","processkit",{"mcp_tools":70,"templates":75,"primitives":76},[71,72,73,74],"create_gate","get_gate","list_gates","evaluate_gate",[28],[77],"Gate","processkit.projectious.work\u002Fv2","Manage Gate entities — validation checkpoints that WorkItems, scopes, or\npolicy applications must pass (code review, security scan, tests). Use\nwhen defining or updating a checkpoint for v2 workflow surfaces — code\nreview, tests green, security scan, stakeholder approval.\n","main","7231f100e266e30d2c1699ecde5c00602471dc3c","src\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fgate-management","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":88,"prompt":98,"zipAvailable":99},[89,92,95],{"tool":90,"command":91},"npx","npx skills add projectious-work\u002Fprocesskit --skill gate-management",{"tool":93,"command":94},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill gate-management",{"tool":96,"command":97},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill gate-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fgate-management\u002FSKILL.md",true,[101,107,113,117,123,126],{"path":102,"resourceType":103,"resourceTypeDesc":104,"sizeBytes":105,"sourceHtmlUrl":106},"assets\u002Fgate.yaml","ASSET","资产文件",267,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fgate-management\u002Fassets\u002Fgate.yaml",{"path":108,"resourceType":109,"resourceTypeDesc":110,"sizeBytes":111,"sourceHtmlUrl":112},"mcp\u002Fmcp-config.json","REFERENCE","参考文档",213,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fgate-management\u002Fmcp\u002Fmcp-config.json",{"path":114,"resourceType":109,"resourceTypeDesc":110,"sizeBytes":115,"sourceHtmlUrl":116},"mcp\u002FSERVER.md",1613,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fgate-management\u002Fmcp\u002FSERVER.md",{"path":118,"resourceType":119,"resourceTypeDesc":120,"sizeBytes":121,"sourceHtmlUrl":122},"mcp\u002Fserver.py","SCRIPT","脚本",16122,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fgate-management\u002Fmcp\u002Fserver.py",{"path":124,"resourceType":119,"resourceTypeDesc":120,"sizeBytes":14,"sourceHtmlUrl":125},"scripts\u002F.gitkeep","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fgate-management\u002Fscripts\u002F.gitkeep",{"path":127,"resourceType":119,"resourceTypeDesc":120,"sizeBytes":128,"sourceHtmlUrl":129},"scripts\u002Ftest_gate_management.py",2839,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fgate-management\u002Fscripts\u002Ftest_gate_management.py",[131,150,170,189,206,224],{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":138,"publishedAt":47},"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",[137],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[29,139,44,140,141,142,39,30,143,144,133,32,145,146,147,148,149],"skill management","update","package","alpha","manage","ontology","as","manifests","v1","skill package","transition",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":157,"publishedAt":47},"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",[156],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[29,158,159,160,161,162,142,39,163,164,143,165,166,167,32,168,169],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":47},"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",[],[29,177,178,44,140,179,142,39,36,180,181,34,32,182,183,184,185,186,187,188],"proposition","proposition management","index","world","record","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":47},"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",[],[29,144,196,44,142,197,198,163,199,36,143,200,201,32,202,203,183,204,147,205],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":212,"publishedAt":47},"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",[],[213,214,215,216,142,217,218,219,39,220,221,222,223],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":225,"name":226,"nameZh":6,"description":227,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":228,"categories":229,"keywords":230,"publishedAt":47},"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",[],[29,231,232,44,140,179,142,197,39,30,36,233,143,181,32,203,183,184,234,149],"capability","capability management","queries","changes"]