[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X18X4CKGHBSFTC70RAMXJV":3,"skill-same:01M6X18X4CKGHBSFTC70RAMXJV":116},{"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":73,"commitSha":74,"skillDirectory":75,"forksCount":14,"repositoryHtmlUrl":76,"repositoryHomepageUrl":77,"ownerHtmlUrl":78,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":79,"install":80,"resources":93},"01M6X18X4CKGHBSFTC70RAMXJV","role-management",null,"Create and maintain Role entities — named sets of responsibilities that actors can fill. Use when defining a new role in the project (developer, reviewer, tech-lead, release-manager) or updating an existing role's responsibilities.","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.22.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Frole-management\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"role management","role","management","log","when","audit trail","fresh","get","project","query","maintain","create","list","write","work","reviewer","sqlite","audit","release","update","2026-11-10 10:12:30",false,"---\nname: role-management\ndescription: |\n  Create and maintain Role entities — named sets of responsibilities that actors can fill. Use when defining a new role in the project (developer, reviewer, tech-lead, release-manager) or updating an existing role's responsibilities.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-role-management\n    version: \"1.0.0\"\n    created: 2026-04-06T00:00:00Z\n    category: processkit\n    layer: 1\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: [Role]\n      mcp_tools:\n        - create_role\n        - get_role\n        - update_role\n        - list_roles\n        - link_role_to_actor\n      templates: [role]\n---\n\n# Role Management\n\n## Intro\n\nA Role is a named set of responsibilities that an Actor can fill. Roles\ndescribe what — not who. \"Alice is a developer\" is a Binding between Actor\n`ACTOR-alice` and Role `ROLE-developer`; this skill manages the Role side of\nthat relationship.\n\n**Important:** Roles in processkit have no enforcement semantics. They are\ndescriptive, not restrictive. RBAC enforcement is out of scope\n(see DISC-002 \u002F DEC-017).\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### When to create a Role\n\nCreate a Role when:\n- A responsibility recurs across multiple work items or processes.\n- You need to refer to \"the person who X\" without naming a specific actor.\n- A process template references the role (\"the reviewer must …\").\n\n### Shape\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: Role\nmetadata:\n  id: ROLE-reviewer\n  created: 2026-04-06T00:00:00Z\nspec:\n  name: reviewer\n  description: \"Reviews code and documentation changes before merge.\"\n  responsibilities:\n    - \"Read PRs within 48 hours of request\"\n    - \"Approve or request changes with actionable feedback\"\n    - \"Block merges on security or correctness concerns\"\n  skills_required: [code-review, debugging]\n  default_scope: project      # project | sprint | permanent\n---\n\nOptional body: elaboration, examples, anti-patterns.\n```\n\n### Workflow\n\n1. Pick an ID: `ROLE-\u003Cname>` where name is kebab-case and unique.\n2. Write a one-sentence `description` — the role's purpose.\n3. List concrete `responsibilities` as imperative bullet points.\n4. Optionally list `skills_required` — links to skill IDs that describe the\n   capabilities this role depends on.\n5. Save to `context\u002Froles\u002F`.\n6. Log `role.created`.\n\n### Assigning actors to roles\n\n**Do not list actor IDs in the Role file.** Assignments go in Binding entities\nso they can be scoped, time-bounded, and changed without editing the Role.\n\n```yaml\nkind: Binding\nspec:\n  type: role-assignment\n  subject: ACTOR-alice\n  target: ROLE-reviewer\n  scope: SCOPE-project-x    # optional\n```\n\nSee `skills\u002Fbinding-management`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Confusing Role with Actor.** A Role is a named set of\n  responsibilities (\"tech-lead\", \"release-manager\"). An Actor is a\n  person or agent who can FILL a role. \"Alice is the tech lead\" is\n  a Binding from `ACTOR-alice` to `ROLE-tech-lead`, not an update\n  to either entity.\n- **Creating a Role for one specific person.** \"Alice's\n  responsibilities\" is not a Role; it's just Alice. Roles capture\n  responsibilities that can be transferred between people. If only\n  one person could ever fill it, it's a job title, not a Role.\n- **Treating Role membership as RBAC enforcement.** Roles are\n  descriptive, not restrictive. processkit does not check whether\n  an actor is \"allowed\" to do something based on their Role.\n  Authorization is out of scope — Roles document who SHOULD do\n  what, not who is permitted to.\n- **Renaming a Role instead of creating a new one.** Renaming\n  silently rewrites history — every old Binding now points at a\n  Role with a different meaning. If the responsibilities have\n  genuinely changed, create a new Role and end the old Bindings;\n  don't overwrite.\n- **Putting tasks in `responsibilities` instead of WorkItems.** The\n  `responsibilities` field describes ongoing duties (\"review PRs\",\n  \"approve releases\"), not specific to-dos. If you find yourself\n  writing \"implement feature X\" in responsibilities, that's a\n  WorkItem.\n- **Vague responsibility lists.** \"Ensures quality\" is not a\n  responsibility; \"Reviews every PR before merge to main\" is. Each\n  bullet should be concrete enough that you could ask a holder\n  \"did you do this last week\" and get a yes\u002Fno answer.\n- **Forgetting to log `role.created` \u002F `role.updated`.** The audit\n  trail tracks role evolution. Skipping the log makes \"when did we\n  add the security-reviewer role\" unanswerable.\n\n## Full reference\n\n### Fields\n\n| Field              | Type          | Notes                                                    |\n|--------------------|---------------|----------------------------------------------------------|\n| `name`             | string        | Kebab-case. Matches the suffix of `metadata.id`.         |\n| `description`      | string        | One sentence. Shown in role listings.                    |\n| `responsibilities` | list[string]  | Imperative bullet points. Concrete, not vague.           |\n| `skills_required`  | list[string]  | Skill IDs or names. Advisory, not enforced.              |\n| `default_scope`    | enum          | `project` \u002F `sprint` \u002F `permanent`. Default assumption for Bindings. |\n| `supersedes`       | string        | Role ID this one replaces (for role renames\u002Freorg).      |\n\n### Roles vs Categories vs Gates\n\nBeginners sometimes conflate three related concepts:\n\n- **Role** — who does a thing (reviewer, developer, release-manager).\n- **Category** — how a thing is classified (bug, feature, tech-debt).\n- **Gate** — a checkpoint that validates a thing (code-review-passed).\n\nA Role can be assigned via Binding; a Category is a label; a Gate is\nsomething a process has to pass. Don't model one as another.\n\n### No enforcement\n\nprocesskit does not check that an actor filling a role has the right\n`skills_required`, or that actions restricted to a role are only performed\nby bound actors. Roles are descriptive. If you need RBAC, that's a\ngovernance platform concern (DEC-017).\n\n### Well-known roles\n\nprocesskit does not ship a canonical list of roles — they vary too much per\nproject. But these are common enough to be mentioned here for naming\nconsistency: `developer`, `reviewer`, `tech-lead`, `release-manager`,\n`incident-commander`, `product-owner`, `designer`, `security-reviewer`.\nProjects are free to use these names or invent their own.\n","# Role Management\n\n## Intro\n\nA Role is a named set of responsibilities that an Actor can fill. Roles\ndescribe what — not who. \"Alice is a developer\" is a Binding between Actor\n`ACTOR-alice` and Role `ROLE-developer`; this skill manages the Role side of\nthat relationship.\n\n**Important:** Roles in processkit have no enforcement semantics. They are\ndescriptive, not restrictive. RBAC enforcement is out of scope\n(see DISC-002 \u002F DEC-017).\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### When to create a Role\n\nCreate a Role when:\n- A responsibility recurs across multiple work items or processes.\n- You need to refer to \"the person who X\" without naming a specific actor.\n- A process template references the role (\"the reviewer must …\").\n\n### Shape\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: Role\nmetadata:\n  id: ROLE-reviewer\n  created: 2026-04-06T00:00:00Z\nspec:\n  name: reviewer\n  description: \"Reviews code and documentation changes before merge.\"\n  responsibilities:\n    - \"Read PRs within 48 hours of request\"\n    - \"Approve or request changes with actionable feedback\"\n    - \"Block merges on security or correctness concerns\"\n  skills_required: [code-review, debugging]\n  default_scope: project      # project | sprint | permanent\n---\n\nOptional body: elaboration, examples, anti-patterns.\n```\n\n### Workflow\n\n1. Pick an ID: `ROLE-\u003Cname>` where name is kebab-case and unique.\n2. Write a one-sentence `description` — the role's purpose.\n3. List concrete `responsibilities` as imperative bullet points.\n4. Optionally list `skills_required` — links to skill IDs that describe the\n   capabilities this role depends on.\n5. Save to `context\u002Froles\u002F`.\n6. Log `role.created`.\n\n### Assigning actors to roles\n\n**Do not list actor IDs in the Role file.** Assignments go in Binding entities\nso they can be scoped, time-bounded, and changed without editing the Role.\n\n```yaml\nkind: Binding\nspec:\n  type: role-assignment\n  subject: ACTOR-alice\n  target: ROLE-reviewer\n  scope: SCOPE-project-x    # optional\n```\n\nSee `skills\u002Fbinding-management`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Confusing Role with Actor.** A Role is a named set of\n  responsibilities (\"tech-lead\", \"release-manager\"). An Actor is a\n  person or agent who can FILL a role. \"Alice is the tech lead\" is\n  a Binding from `ACTOR-alice` to `ROLE-tech-lead`, not an update\n  to either entity.\n- **Creating a Role for one specific person.** \"Alice's\n  responsibilities\" is not a Role; it's just Alice. Roles capture\n  responsibilities that can be transferred between people. If only\n  one person could ever fill it, it's a job title, not a Role.\n- **Treating Role membership as RBAC enforcement.** Roles are\n  descriptive, not restrictive. processkit does not check whether\n  an actor is \"allowed\" to do something based on their Role.\n  Authorization is out of scope — Roles document who SHOULD do\n  what, not who is permitted to.\n- **Renaming a Role instead of creating a new one.** Renaming\n  silently rewrites history — every old Binding now points at a\n  Role with a different meaning. If the responsibilities have\n  genuinely changed, create a new Role and end the old Bindings;\n  don't overwrite.\n- **Putting tasks in `responsibilities` instead of WorkItems.** The\n  `responsibilities` field describes ongoing duties (\"review PRs\",\n  \"approve releases\"), not specific to-dos. If you find yourself\n  writing \"implement feature X\" in responsibilities, that's a\n  WorkItem.\n- **Vague responsibility lists.** \"Ensures quality\" is not a\n  responsibility; \"Reviews every PR before merge to main\" is. Each\n  bullet should be concrete enough that you could ask a holder\n  \"did you do this last week\" and get a yes\u002Fno answer.\n- **Forgetting to log `role.created` \u002F `role.updated`.** The audit\n  trail tracks role evolution. Skipping the log makes \"when did we\n  add the security-reviewer role\" unanswerable.\n\n## Full reference\n\n### Fields\n\n| Field              | Type          | Notes                                                    |\n|--------------------|---------------|----------------------------------------------------------|\n| `name`             | string        | Kebab-case. Matches the suffix of `metadata.id`.         |\n| `description`      | string        | One sentence. Shown in role listings.                    |\n| `responsibilities` | list[string]  | Imperative bullet points. Concrete, not vague.           |\n| `skills_required`  | list[string]  | Skill IDs or names. Advisory, not enforced.              |\n| `default_scope`    | enum          | `project` \u002F `sprint` \u002F `permanent`. Default assumption for Bindings. |\n| `supersedes`       | string        | Role ID this one replaces (for role renames\u002Freorg).      |\n\n### Roles vs Categories vs Gates\n\nBeginners sometimes conflate three related concepts:\n\n- **Role** — who does a thing (reviewer, developer, release-manager).\n- **Category** — how a thing is classified (bug, feature, tech-debt).\n- **Gate** — a checkpoint that validates a thing (code-review-passed).\n\nA Role can be assigned via Binding; a Category is a label; a Gate is\nsomething a process has to pass. Don't model one as another.\n\n### No enforcement\n\nprocesskit does not check that an actor filling a role has the right\n`skills_required`, or that actions restricted to a role are only performed\nby bound actors. Roles are descriptive. If you need RBAC, that's a\ngovernance platform concern (DEC-017).\n\n### Well-known roles\n\nprocesskit does not ship a canonical list of roles — they vary too much per\nproject. But these are common enough to be mentioned here for naming\nconsistency: `developer`, `reviewer`, `tech-lead`, `release-manager`,\n`incident-commander`, `product-owner`, `designer`, `security-reviewer`.\nProjects are free to use these names or invent their own.\n",{"name":5,"metadata":44,"description":72},{"processkit":45},{"id":46,"uses":47,"layer":57,"created":58,"version":59,"category":60,"provides":61,"apiVersion":71},"SKILL-role-management",[48,51,54],{"skill":49,"purpose":50},"event-log","Log events to keep the audit trail accurate after every write.",{"skill":52,"purpose":53},"index-management","Query existing entities and keep the SQLite index fresh after writes.",{"skill":55,"purpose":56},"id-management","Allocate unique entity identifiers via central ID generation.",1,1775433600000,"1.0.0","processkit",{"mcp_tools":62,"templates":68,"primitives":69},[63,64,65,66,67],"create_role","get_role","update_role","list_roles","link_role_to_actor",[20],[70],"Role","processkit.projectious.work\u002Fv1","Create and maintain Role entities — named sets of responsibilities that actors can fill. Use when defining a new role in the project (developer, reviewer, tech-lead, release-manager) or updating an existing role's responsibilities.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.22.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Frole-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":81,"prompt":91,"zipAvailable":92},[82,85,88],{"tool":83,"command":84},"npx","npx skills add projectious-work\u002Fprocesskit --skill role-management",{"tool":86,"command":87},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill role-management",{"tool":89,"command":90},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill role-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.22.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Frole-management\u002FSKILL.md",true,[94,100,106,110],{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"assets\u002Frole.yaml","ASSET","资产文件",285,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.22.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Frole-management\u002Fassets\u002Frole.yaml",{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"mcp\u002Fmcp-config.json","REFERENCE","参考文档",213,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.22.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Frole-management\u002Fmcp\u002Fmcp-config.json",{"path":107,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":108,"sourceHtmlUrl":109},"mcp\u002FSERVER.md",1543,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.22.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Frole-management\u002Fmcp\u002FSERVER.md",{"path":111,"resourceType":112,"resourceTypeDesc":113,"sizeBytes":114,"sourceHtmlUrl":115},"mcp\u002Fserver.py","SCRIPT","脚本",11850,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.22.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Frole-management\u002Fmcp\u002Fserver.py",[117,139,159,178,195,213],{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":128,"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",[123],{"categoryNo":124,"categoryName":125,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[21,129,30,38,130,131,33,31,132,133,119,26,134,135,136,137,138],"skill management","package","alpha","manage","ontology","as","manifests","v1","skill package","transition",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":146,"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",[145],{"categoryNo":124,"categoryName":125,"taxonomyType":126,"taxonomyTypeDesc":127},[21,147,148,149,150,151,131,33,152,153,132,154,155,156,26,157,158],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"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",[],[21,166,167,30,38,168,131,33,22,169,170,28,26,171,172,173,174,175,176,177],"proposition","proposition management","index","world","record","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"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",[],[21,133,185,30,131,186,187,152,188,22,132,189,190,26,191,192,172,193,136,194],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"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",[],[202,203,204,205,131,206,207,208,33,209,210,211,212],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":217,"categories":218,"keywords":219,"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",[],[21,220,221,30,38,168,131,186,33,31,22,222,132,170,26,192,172,173,223,138],"capability","capability management","queries","changes"]