[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X4KP7ZPX219WXTJJSCE7CR":3,"skill-same:01M6X4KP7ZPX219WXTJJSCE7CR":125},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":82,"commitSha":83,"skillDirectory":84,"forksCount":14,"repositoryHtmlUrl":85,"repositoryHomepageUrl":86,"ownerHtmlUrl":87,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":88,"install":89,"resources":102},"01M6X4KP7ZPX219WXTJJSCE7CR","discussion-management",null,"Manage Discussion entities — structured, multi-turn conversations that explore questions and produce decisions. Use when a question or design choice needs multi-turn exploration before a decision is reached — RFCs, design debates, trade-off analyses.","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\u002Fdiscussion-management\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"discussion management","management","log","when","audit trail","transition","conversations","fresh","get","query","exploration","design","question","work","choice","decision","explore","open","sqlite","workflow","2026-11-10 10:12:30",false,"---\nname: discussion-management\ndescription: |\n  Manage Discussion entities — structured, multi-turn conversations that explore questions and produce decisions. Use when a question or design choice needs multi-turn exploration before a decision is reached — RFCs, design debates, trade-off analyses.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-discussion-management\n    version: \"1.0.0\"\n    created: 2026-04-06T00:00:00Z\n    category: process\n    layer: 4\n    uses:\n      - skill: event-log\n        purpose: Log events to keep the audit trail accurate after every write.\n      - skill: decision-record\n        purpose: Record consequential decisions made during this skill's workflow.\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: [Discussion]\n      mcp_tools:\n        - open_discussion\n        - get_discussion\n        - transition_discussion\n        - add_outcome\n        - list_discussions\n      templates: [discussion]\n---\n\n# Discussion Management\n\n## Intro\n\nA Discussion is a structured, multi-turn conversation exploring a question.\nIt captures the back-and-forth of research, proposals, objections, and\nconvergence — producing (or failing to produce) a DecisionRecord as its\noutcome. Think of it as the audit trail behind a decision.\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\u002Fv1\nkind: Discussion\nmetadata:\n  id: DISC-002\n  title: \"aibox Refocus — Core Principles and Scope\"\n  created: 2026-04-05\n  participants: [owner, claude]\nspec:\n  state: active          # active | resolved | archived\n  question: \"What is aibox's core scope? What belongs in processkit? What is out of scope entirely?\"\n  related: [DISC-001]\n---\n\n# Discussion body\n\n## 1. Problem statement\n...\n\n## 2. What aibox IS\n...\n\n## Decisions (DEC-NNN records)\n- DEC-017: Scope refocus\n- DEC-018: Two-repo split\n...\n```\n\n### Workflow\n\n1. Start a Discussion when a non-trivial question arises.\n2. Write the `question` as one crisp sentence.\n3. Use numbered sections in the body: problem statement, options considered,\n   analysis, decisions.\n4. As decisions crystallize, write DecisionRecords and list them at the bottom\n   of the Discussion.\n5. When converged, set `state: resolved`. Log `discussion.resolved`.\n\n### Discussions vs DecisionRecords\n\n| Discussion                     | DecisionRecord                          |\n|--------------------------------|-----------------------------------------|\n| Multi-turn, exploratory        | Single outcome, crisp                   |\n| Captures reasoning journey     | Captures the destination                |\n| May produce 0–many DEC records | Produced by at most one Discussion      |\n| Often long-form                | Tightly structured                      |\n\nUse a Discussion when you don't yet know the answer. Use a DecisionRecord\nwhen you do.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Opening a Discussion when the choice is already obvious.** If\n  the user already knows what they want, write a DecisionRecord\n  directly. Discussions are for genuinely open questions where the\n  reasoning trail matters; using one for a settled call wastes\n  ceremony.\n- **Letting Discussions go stale.** A Discussion with no activity\n  for weeks should either resolve (with an outcome) or close\n  (state: archived). Open-forever discussions clutter the index\n  and signal pretend-thinking.\n- **Not recording the outcome as a DecisionRecord on convergence.**\n  When a Discussion reaches an answer, the answer must become a\n  DecisionRecord referenced in the discussion's `outcomes` field.\n  Without that promotion, the value of the discussion evaporates\n  the next time someone asks \"what did we decide\".\n- **Putting decisive content in the body but leaving `outcomes`\n  empty.** The `outcomes` field is what downstream queries read.\n  If the body says \"we decided X\" but `outcomes: []`, the index\n  doesn't know a decision was made and can't link the discussion\n  to the DecisionRecord.\n- **Confusing Discussion (pre-decisional) with DecisionRecord\n  (post-decisional).** Discussions capture reasoning in flight;\n  DecisionRecords capture settled choices. Don't write reasoning\n  into a DecisionRecord, and don't write conclusions into a\n  Discussion body without also creating the DecisionRecord.\n- **Forgetting to add participants.** The `participants` field is\n  how queries like \"what is Alice currently thinking about\" work.\n  An unattributed Discussion is invisible to participant queries.\n- **Treating one user message as a \"discussion\".** A Discussion is\n  multi-turn by definition. If there's only one back-and-forth, it\n  doesn't need the structure — answer directly or write a\n  DecisionRecord.\n\n## Full reference\n\n### Fields\n\n| Field          | Type           | Notes                                          |\n|----------------|----------------|------------------------------------------------|\n| `state`        | enum           | `active` \u002F `resolved` \u002F `archived`             |\n| `question`     | string         | The driving question                           |\n| `participants` | list[string]   | Actor IDs                                      |\n| `related`      | list[string]   | Other discussion IDs                           |\n| `outcomes`     | list[string]   | DEC IDs produced                               |\n| `opened_at`    | datetime       | When the discussion started                    |\n| `closed_at`    | datetime       | When it was marked resolved                    |\n\n### Long-running discussions\n\nSome discussions span weeks or months. Keep them in one file — use section\ndividers with dates rather than creating multiple files. The index MCP\nserver can show discussion activity over time by reading LogEntries that\nreference it.\n\n### Archiving\n\nWhen a discussion is old and no longer actively referenced, move it to\n`context\u002Farchive\u002Fdiscussions\u002F` and set `state: archived`. Do not delete —\nthe reasoning is often the most valuable context for future work.\n\n### Example: DISC-002\n\nThe DISC-002 document in the aibox repo is a full example of a processkit\nDiscussion — multi-section, multiple open questions resolved over time,\nproducing DEC-017..DEC-024. It predates this skill (was written in plain\nMarkdown) and can be retroactively brought into the format by adding the\nfrontmatter block.\n","# Discussion Management\n\n## Intro\n\nA Discussion is a structured, multi-turn conversation exploring a question.\nIt captures the back-and-forth of research, proposals, objections, and\nconvergence — producing (or failing to produce) a DecisionRecord as its\noutcome. Think of it as the audit trail behind a decision.\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\u002Fv1\nkind: Discussion\nmetadata:\n  id: DISC-002\n  title: \"aibox Refocus — Core Principles and Scope\"\n  created: 2026-04-05\n  participants: [owner, claude]\nspec:\n  state: active          # active | resolved | archived\n  question: \"What is aibox's core scope? What belongs in processkit? What is out of scope entirely?\"\n  related: [DISC-001]\n---\n\n# Discussion body\n\n## 1. Problem statement\n...\n\n## 2. What aibox IS\n...\n\n## Decisions (DEC-NNN records)\n- DEC-017: Scope refocus\n- DEC-018: Two-repo split\n...\n```\n\n### Workflow\n\n1. Start a Discussion when a non-trivial question arises.\n2. Write the `question` as one crisp sentence.\n3. Use numbered sections in the body: problem statement, options considered,\n   analysis, decisions.\n4. As decisions crystallize, write DecisionRecords and list them at the bottom\n   of the Discussion.\n5. When converged, set `state: resolved`. Log `discussion.resolved`.\n\n### Discussions vs DecisionRecords\n\n| Discussion                     | DecisionRecord                          |\n|--------------------------------|-----------------------------------------|\n| Multi-turn, exploratory        | Single outcome, crisp                   |\n| Captures reasoning journey     | Captures the destination                |\n| May produce 0–many DEC records | Produced by at most one Discussion      |\n| Often long-form                | Tightly structured                      |\n\nUse a Discussion when you don't yet know the answer. Use a DecisionRecord\nwhen you do.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Opening a Discussion when the choice is already obvious.** If\n  the user already knows what they want, write a DecisionRecord\n  directly. Discussions are for genuinely open questions where the\n  reasoning trail matters; using one for a settled call wastes\n  ceremony.\n- **Letting Discussions go stale.** A Discussion with no activity\n  for weeks should either resolve (with an outcome) or close\n  (state: archived). Open-forever discussions clutter the index\n  and signal pretend-thinking.\n- **Not recording the outcome as a DecisionRecord on convergence.**\n  When a Discussion reaches an answer, the answer must become a\n  DecisionRecord referenced in the discussion's `outcomes` field.\n  Without that promotion, the value of the discussion evaporates\n  the next time someone asks \"what did we decide\".\n- **Putting decisive content in the body but leaving `outcomes`\n  empty.** The `outcomes` field is what downstream queries read.\n  If the body says \"we decided X\" but `outcomes: []`, the index\n  doesn't know a decision was made and can't link the discussion\n  to the DecisionRecord.\n- **Confusing Discussion (pre-decisional) with DecisionRecord\n  (post-decisional).** Discussions capture reasoning in flight;\n  DecisionRecords capture settled choices. Don't write reasoning\n  into a DecisionRecord, and don't write conclusions into a\n  Discussion body without also creating the DecisionRecord.\n- **Forgetting to add participants.** The `participants` field is\n  how queries like \"what is Alice currently thinking about\" work.\n  An unattributed Discussion is invisible to participant queries.\n- **Treating one user message as a \"discussion\".** A Discussion is\n  multi-turn by definition. If there's only one back-and-forth, it\n  doesn't need the structure — answer directly or write a\n  DecisionRecord.\n\n## Full reference\n\n### Fields\n\n| Field          | Type           | Notes                                          |\n|----------------|----------------|------------------------------------------------|\n| `state`        | enum           | `active` \u002F `resolved` \u002F `archived`             |\n| `question`     | string         | The driving question                           |\n| `participants` | list[string]   | Actor IDs                                      |\n| `related`      | list[string]   | Other discussion IDs                           |\n| `outcomes`     | list[string]   | DEC IDs produced                               |\n| `opened_at`    | datetime       | When the discussion started                    |\n| `closed_at`    | datetime       | When it was marked resolved                    |\n\n### Long-running discussions\n\nSome discussions span weeks or months. Keep them in one file — use section\ndividers with dates rather than creating multiple files. The index MCP\nserver can show discussion activity over time by reading LogEntries that\nreference it.\n\n### Archiving\n\nWhen a discussion is old and no longer actively referenced, move it to\n`context\u002Farchive\u002Fdiscussions\u002F` and set `state: archived`. Do not delete —\nthe reasoning is often the most valuable context for future work.\n\n### Example: DISC-002\n\nThe DISC-002 document in the aibox repo is a full example of a processkit\nDiscussion — multi-section, multiple open questions resolved over time,\nproducing DEC-017..DEC-024. It predates this skill (was written in plain\nMarkdown) and can be retroactively brought into the format by adding the\nfrontmatter block.\n",{"name":5,"metadata":49,"description":81},{"processkit":50},{"id":51,"uses":52,"layer":65,"created":66,"version":67,"category":68,"provides":69,"apiVersion":80},"SKILL-discussion-management",[53,56,59,62],{"skill":54,"purpose":55},"event-log","Log events to keep the audit trail accurate after every write.",{"skill":57,"purpose":58},"decision-record","Record consequential decisions made during this skill's workflow.",{"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.",4,1775433600000,"1.0.0","process",{"mcp_tools":70,"templates":76,"primitives":78},[71,72,73,74,75],"open_discussion","get_discussion","transition_discussion","add_outcome","list_discussions",[77],"discussion",[79],"Discussion","processkit.projectious.work\u002Fv1","Manage Discussion entities — structured, multi-turn conversations that explore questions and produce decisions. Use when a question or design choice needs multi-turn exploration before a decision is reached — RFCs, design debates, trade-off analyses.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fdiscussion-management","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-09 00:53:29",{"source":8,"skillName":5,"commands":90,"prompt":100,"zipAvailable":101},[91,94,97],{"tool":92,"command":93},"npx","npx skills add projectious-work\u002Fprocesskit --skill discussion-management",{"tool":95,"command":96},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill discussion-management",{"tool":98,"command":99},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill discussion-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fdiscussion-management\u002FSKILL.md",true,[103,109,115,119],{"path":104,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":107,"sourceHtmlUrl":108},"assets\u002Fdiscussion.yaml","ASSET","资产文件",434,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fdiscussion-management\u002Fassets\u002Fdiscussion.yaml",{"path":110,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":113,"sourceHtmlUrl":114},"mcp\u002Fmcp-config.json","REFERENCE","参考文档",214,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fdiscussion-management\u002Fmcp\u002Fmcp-config.json",{"path":116,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":117,"sourceHtmlUrl":118},"mcp\u002FSERVER.md",1489,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fdiscussion-management\u002Fmcp\u002FSERVER.md",{"path":120,"resourceType":121,"resourceTypeDesc":122,"sizeBytes":123,"sourceHtmlUrl":124},"mcp\u002Fserver.py","SCRIPT","脚本",8406,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fdiscussion-management\u002Fmcp\u002Fserver.py",[126,146,166,185,202,219],{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":133,"publishedAt":44},"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",[132],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[25,134,135,136,137,138,37,139,140,141,128,32,142,143,144,145,29],"skill management","create","update","package","alpha","list","manage","ontology","as","manifests","v1","skill package",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":153,"publishedAt":44},"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",[152],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[25,154,155,156,157,158,138,37,159,160,140,161,162,163,32,164,165],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":44},"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",[],[25,173,174,135,136,175,138,37,26,176,177,33,32,178,179,180,181,182,183,184],"proposition","proposition management","index","world","record","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":191,"publishedAt":44},"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",[],[25,141,192,135,138,193,194,159,195,26,140,196,197,32,198,199,179,200,144,201],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":208,"publishedAt":44},"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",[],[209,210,211,212,138,41,213,214,37,215,216,217,218],"okf","compatibility","okf compatibility","validate","knowledge","format","export","bundles","bundle","import",{"skillNo":220,"name":221,"nameZh":6,"description":222,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":223,"categories":224,"keywords":225,"publishedAt":44},"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",[],[25,226,227,135,136,175,138,193,37,139,26,228,140,177,32,199,179,180,229,29],"capability","capability management","queries","changes"]