[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X0AENMENECNMERNJKSDPCE":3,"skill-same:01M6X0AENMENECNMERNJKSDPCE":117},{"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":32,"commitSha":75,"skillDirectory":76,"forksCount":14,"repositoryHtmlUrl":77,"repositoryHomepageUrl":78,"ownerHtmlUrl":79,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":80,"install":81,"resources":94},"01M6X0AENMENECNMERNJKSDPCE","binding-management",null,"Manage Binding entities — scoped, temporal, many-to-many relationships between any two primitives. Use when a relationship between two entities needs scope, time, or its own attributes — e.g. 'Alice is the tech lead for project X from Jan to June' or 'the security gate applies to the release process only on the main branch'.","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.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fbinding-management\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"binding management","management","binding","relationship","when","attributes","scope","fresh","end","project","time","create","query","main","log","security gate","only","branch","sqlite","ids","2026-11-10 10:12:30",false,"---\nname: binding-management\ndescription: |\n  Manage Binding entities — scoped, temporal, many-to-many relationships between any two primitives. Use when a relationship between two entities needs scope, time, or its own attributes — e.g. 'Alice is the tech lead for project X from Jan to June' or 'the security gate applies to the release process only on the main branch'.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-binding-management\n    version: \"1.0.0\"\n    created: 2026-04-06T00:00:00Z\n    category: processkit\n    layer: 2\n    uses:\n      - skill: event-log\n        purpose: Log events to keep the audit trail accurate after every write.\n      - skill: actor-profile\n        purpose: Resolve and validate Actor IDs referenced by this skill's entities.\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: [Binding]\n      mcp_tools: [create_binding, query_bindings, end_binding, resolve_bindings_for]\n      templates: [binding]\n---\n\n# Binding Management\n\n## Intro\n\nA Binding is an entity that connects two other entities with optional scope,\ntemporality, and conditions. It is the junction-table pattern promoted to\na primitive, and it is the right choice whenever a relationship is more than\na simple \"A references B\" — for example \"Alice is the tech lead on project X\nfor 2026,\" or \"the security gate applies to the release process only on the\nmain branch.\"\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 use a Binding vs a cross-reference\n\n**Rule:** if a relationship has **scope**, **time**, or **its own attributes**\n→ Binding. If it is just \"A relates to B\" → cross-reference in frontmatter.\n\n| Situation                                                 | Binding or cross-ref? |\n|-----------------------------------------------------------|-----------------------|\n| \"BACK-foo blocks BACK-bar\"                                | cross-ref             |\n| \"DEC-x is related to BACK-y\"                              | cross-ref             |\n| \"Alice is a developer\" (globally, permanently)            | cross-ref (in Actor)  |\n| \"Alice is tech lead on project X for 2026\"                | **Binding**           |\n| \"The security gate applies to the release process\"       | cross-ref (in Process)|\n| \"The security gate applies to release process *only on main branch*\" | **Binding** |\n| \"Sprint 42 runs from Apr 1 to Apr 14 and scopes these items\" | **Binding**        |\n\nIf in doubt, prefer the cross-reference. Promote to a Binding only when you\nactually need the extra dimensions.\n\n### Binding types\n\n`spec.type` is freeform; conventions emerge per project. Common ones:\n\n| type                  | subject kind | target kind |\n|-----------------------|--------------|-------------|\n| `role-assignment`     | Actor        | Role        |\n| `work-assignment`     | WorkItem     | Actor       |\n| `process-gate`        | Process      | Gate        |\n| `process-scope`       | Process      | Scope       |\n| `schedule-scope`      | Schedule     | Scope       |\n| `constraint-scope`    | Constraint   | Scope       |\n| `category-assignment` | any          | Category    |\n\n### Shape\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: Binding\nmetadata:\n  id: BIND-bright-falcon\n  created: 2026-04-06T00:00:00Z\nspec:\n  type: role-assignment\n  subject: ACTOR-alice\n  target: ROLE-tech-lead\n  scope: SCOPE-project-x\n  valid_from: 2026-01-01\n  valid_until: 2026-12-31\n  conditions:\n    approval_required: false\n  description: \"Alice fills the tech-lead role on project X for 2026.\"\n---\n\nOptional body: context for why this binding exists, related discussion, etc.\n```\n\n### Workflow\n\n1. Pick the `type` — match an existing convention if possible.\n2. Set `subject` (the entity \"receiving\" the relationship) and `target`\n   (the entity \"being bound to\").\n3. Set `scope` if the binding only applies within a particular scope.\n4. Set `valid_from` \u002F `valid_until` if the binding is time-bounded.\n5. Add `conditions` for arbitrary constraints.\n6. Save to `context\u002Fbindings\u002F`.\n7. Log `binding.created`.\n\n### Ending a binding\n\nTo end a binding:\n\n- **Preferred:** set `valid_until` to the current date, log `binding.ended`.\n- **Alternative:** delete the Binding file (only if it was created in error).\n\nDo NOT edit `subject` or `target` of an existing binding — write a new one\nand end the old one. The history is what makes Bindings useful.\n\n### Resolving \"who currently fills role X in scope Y?\"\n\n1. Find Bindings where `type: role-assignment` and `target: ROLE-x` and\n   (`scope: SCOPE-y` or `scope: null`).\n2. Filter to those active at the current time (`valid_from ≤ now ≤ valid_until`\n   or either unset).\n3. Return the `subject` IDs.\n\nThe Phase 3 MCP server provides `resolve_bindings_for(entity_id, type?, at_time?)`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Using a Binding when a simple cross-reference would do.** If the\n  relationship has no scope, no time bounds, and no attributes of its\n  own (\"this workitem relates to that decision\"), use a frontmatter\n  cross-reference, not a Binding. Bindings are overhead — reserve\n  them for relationships that genuinely need their own lifecycle.\n- **Using a cross-reference when scope or time matters.** The inverse\n  trap: \"Alice owns this for sprint 42 only\" or \"the security gate\n  applies on the main branch only\" must be a Binding, not an\n  assignee field. Cross-references can't carry temporal validity.\n- **Forgetting `valid_from` \u002F `valid_until` on temporal Bindings.**\n  A Binding without time bounds reads as \"forever\". If the\n  relationship is bounded (\"until end of quarter\"), set the bounds\n  at creation. Otherwise queries like \"who owns X right now\" return\n  stale results.\n- **Forgetting to end a Binding when the relationship ends.** Open\n  Bindings accumulate as orphans. When the underlying relationship\n  ends, call `end_binding` (or set `valid_until`) — don't just\n  delete the entity, since the historical record matters.\n- **Hallucinating subject or target IDs.** Always verify both the\n  subject and the target exist via `index-management.get_entity`\n  before creating a Binding. A Binding pointing at a non-existent\n  entity is structurally invalid and breaks every later resolve\n  query.\n- **Querying current bindings without a time filter.** When asking\n  \"who is the tech lead now\", filter by current time\n  (`valid_from ≤ now ≤ valid_until`). A naive query returns every\n  Binding ever, including expired ones.\n- **Treating Bindings as RBAC enforcement.** Bindings are\n  descriptive, not restrictive. They record who has which role,\n  not who is allowed to do what. Authorization is out of scope —\n  do not use Bindings as a permission check.\n\n## Full reference\n\n### Fields\n\n| Field         | Type           | Notes                                                            |\n|---------------|----------------|------------------------------------------------------------------|\n| `type`        | string         | Freeform — the binding type. Conventions per project.            |\n| `subject`     | string         | ID of the entity on the \"from\" side of the relationship.         |\n| `target`      | string         | ID of the entity on the \"to\" side of the relationship.           |\n| `scope`       | string         | Optional. Scope ID within which this binding applies.            |\n| `valid_from`  | date\u002Fdatetime  | Optional. When the binding starts being in effect.               |\n| `valid_until` | date\u002Fdatetime  | Optional. When the binding stops being in effect.                |\n| `conditions`  | map            | Optional. Freeform constraints.                                  |\n| `description` | string         | One-line human-readable summary.                                 |\n\n### Why Binding is generalized from RoleBinding\n\nDISC-001 introduced RoleBinding as the 18th primitive. DISC-002 §11 investigated\nwhether this should be generalized. The pattern of \"put a third thing between\ntwo things so either can change independently\" is fundamental in software\ndesign (GoF patterns, DI, junction tables) and appears in at least 7 relationship\ntypes in processkit. Generalizing keeps the primitive count at 18 while covering\nmore cases. See DEC-023.\n\n### No enforcement\n\nBindings are descriptive. processkit does not prevent actions based on\nbindings — e.g., a WorkItem doesn't refuse to transition if the actor isn't\nbound to the required role. Enforcement is a governance concern\n(DEC-017).\n\n### Indexing\n\nIn Phase 3, the index MCP server maintains a `bindings` table:\n\n```\nbindings(id, type, subject, subject_kind, target, target_kind,\n         scope, valid_from, valid_until, active)\n```\n\nwith `active` computed from `valid_from`\u002F`valid_until` vs current time.\nThis makes \"who currently holds role X\" a single SQL query.\n\n### Idempotency for \"current state\" bindings\n\nWhen the same effective state is re-asserted (e.g. \"Alice is still tech\nlead\"), prefer extending `valid_until` on the existing Binding rather than\ncreating a new one. This keeps history clean. If the underlying situation\n*changed* and just happened to end up in the same place, that's a new\nBinding.\n","# Binding Management\n\n## Intro\n\nA Binding is an entity that connects two other entities with optional scope,\ntemporality, and conditions. It is the junction-table pattern promoted to\na primitive, and it is the right choice whenever a relationship is more than\na simple \"A references B\" — for example \"Alice is the tech lead on project X\nfor 2026,\" or \"the security gate applies to the release process only on the\nmain branch.\"\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 use a Binding vs a cross-reference\n\n**Rule:** if a relationship has **scope**, **time**, or **its own attributes**\n→ Binding. If it is just \"A relates to B\" → cross-reference in frontmatter.\n\n| Situation                                                 | Binding or cross-ref? |\n|-----------------------------------------------------------|-----------------------|\n| \"BACK-foo blocks BACK-bar\"                                | cross-ref             |\n| \"DEC-x is related to BACK-y\"                              | cross-ref             |\n| \"Alice is a developer\" (globally, permanently)            | cross-ref (in Actor)  |\n| \"Alice is tech lead on project X for 2026\"                | **Binding**           |\n| \"The security gate applies to the release process\"       | cross-ref (in Process)|\n| \"The security gate applies to release process *only on main branch*\" | **Binding** |\n| \"Sprint 42 runs from Apr 1 to Apr 14 and scopes these items\" | **Binding**        |\n\nIf in doubt, prefer the cross-reference. Promote to a Binding only when you\nactually need the extra dimensions.\n\n### Binding types\n\n`spec.type` is freeform; conventions emerge per project. Common ones:\n\n| type                  | subject kind | target kind |\n|-----------------------|--------------|-------------|\n| `role-assignment`     | Actor        | Role        |\n| `work-assignment`     | WorkItem     | Actor       |\n| `process-gate`        | Process      | Gate        |\n| `process-scope`       | Process      | Scope       |\n| `schedule-scope`      | Schedule     | Scope       |\n| `constraint-scope`    | Constraint   | Scope       |\n| `category-assignment` | any          | Category    |\n\n### Shape\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: Binding\nmetadata:\n  id: BIND-bright-falcon\n  created: 2026-04-06T00:00:00Z\nspec:\n  type: role-assignment\n  subject: ACTOR-alice\n  target: ROLE-tech-lead\n  scope: SCOPE-project-x\n  valid_from: 2026-01-01\n  valid_until: 2026-12-31\n  conditions:\n    approval_required: false\n  description: \"Alice fills the tech-lead role on project X for 2026.\"\n---\n\nOptional body: context for why this binding exists, related discussion, etc.\n```\n\n### Workflow\n\n1. Pick the `type` — match an existing convention if possible.\n2. Set `subject` (the entity \"receiving\" the relationship) and `target`\n   (the entity \"being bound to\").\n3. Set `scope` if the binding only applies within a particular scope.\n4. Set `valid_from` \u002F `valid_until` if the binding is time-bounded.\n5. Add `conditions` for arbitrary constraints.\n6. Save to `context\u002Fbindings\u002F`.\n7. Log `binding.created`.\n\n### Ending a binding\n\nTo end a binding:\n\n- **Preferred:** set `valid_until` to the current date, log `binding.ended`.\n- **Alternative:** delete the Binding file (only if it was created in error).\n\nDo NOT edit `subject` or `target` of an existing binding — write a new one\nand end the old one. The history is what makes Bindings useful.\n\n### Resolving \"who currently fills role X in scope Y?\"\n\n1. Find Bindings where `type: role-assignment` and `target: ROLE-x` and\n   (`scope: SCOPE-y` or `scope: null`).\n2. Filter to those active at the current time (`valid_from ≤ now ≤ valid_until`\n   or either unset).\n3. Return the `subject` IDs.\n\nThe Phase 3 MCP server provides `resolve_bindings_for(entity_id, type?, at_time?)`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Using a Binding when a simple cross-reference would do.** If the\n  relationship has no scope, no time bounds, and no attributes of its\n  own (\"this workitem relates to that decision\"), use a frontmatter\n  cross-reference, not a Binding. Bindings are overhead — reserve\n  them for relationships that genuinely need their own lifecycle.\n- **Using a cross-reference when scope or time matters.** The inverse\n  trap: \"Alice owns this for sprint 42 only\" or \"the security gate\n  applies on the main branch only\" must be a Binding, not an\n  assignee field. Cross-references can't carry temporal validity.\n- **Forgetting `valid_from` \u002F `valid_until` on temporal Bindings.**\n  A Binding without time bounds reads as \"forever\". If the\n  relationship is bounded (\"until end of quarter\"), set the bounds\n  at creation. Otherwise queries like \"who owns X right now\" return\n  stale results.\n- **Forgetting to end a Binding when the relationship ends.** Open\n  Bindings accumulate as orphans. When the underlying relationship\n  ends, call `end_binding` (or set `valid_until`) — don't just\n  delete the entity, since the historical record matters.\n- **Hallucinating subject or target IDs.** Always verify both the\n  subject and the target exist via `index-management.get_entity`\n  before creating a Binding. A Binding pointing at a non-existent\n  entity is structurally invalid and breaks every later resolve\n  query.\n- **Querying current bindings without a time filter.** When asking\n  \"who is the tech lead now\", filter by current time\n  (`valid_from ≤ now ≤ valid_until`). A naive query returns every\n  Binding ever, including expired ones.\n- **Treating Bindings as RBAC enforcement.** Bindings are\n  descriptive, not restrictive. They record who has which role,\n  not who is allowed to do what. Authorization is out of scope —\n  do not use Bindings as a permission check.\n\n## Full reference\n\n### Fields\n\n| Field         | Type           | Notes                                                            |\n|---------------|----------------|------------------------------------------------------------------|\n| `type`        | string         | Freeform — the binding type. Conventions per project.            |\n| `subject`     | string         | ID of the entity on the \"from\" side of the relationship.         |\n| `target`      | string         | ID of the entity on the \"to\" side of the relationship.           |\n| `scope`       | string         | Optional. Scope ID within which this binding applies.            |\n| `valid_from`  | date\u002Fdatetime  | Optional. When the binding starts being in effect.               |\n| `valid_until` | date\u002Fdatetime  | Optional. When the binding stops being in effect.                |\n| `conditions`  | map            | Optional. Freeform constraints.                                  |\n| `description` | string         | One-line human-readable summary.                                 |\n\n### Why Binding is generalized from RoleBinding\n\nDISC-001 introduced RoleBinding as the 18th primitive. DISC-002 §11 investigated\nwhether this should be generalized. The pattern of \"put a third thing between\ntwo things so either can change independently\" is fundamental in software\ndesign (GoF patterns, DI, junction tables) and appears in at least 7 relationship\ntypes in processkit. Generalizing keeps the primitive count at 18 while covering\nmore cases. See DEC-023.\n\n### No enforcement\n\nBindings are descriptive. processkit does not prevent actions based on\nbindings — e.g., a WorkItem doesn't refuse to transition if the actor isn't\nbound to the required role. Enforcement is a governance concern\n(DEC-017).\n\n### Indexing\n\nIn Phase 3, the index MCP server maintains a `bindings` table:\n\n```\nbindings(id, type, subject, subject_kind, target, target_kind,\n         scope, valid_from, valid_until, active)\n```\n\nwith `active` computed from `valid_from`\u002F`valid_until` vs current time.\nThis makes \"who currently holds role X\" a single SQL query.\n\n### Idempotency for \"current state\" bindings\n\nWhen the same effective state is re-asserted (e.g. \"Alice is still tech\nlead\"), prefer extending `valid_until` on the existing Binding rather than\ncreating a new one. This keeps history clean. If the underlying situation\n*changed* and just happened to end up in the same place, that's a new\nBinding.\n",{"name":5,"metadata":44,"description":74},{"processkit":45},{"id":46,"uses":47,"layer":60,"created":61,"version":62,"category":63,"provides":64,"apiVersion":73},"SKILL-binding-management",[48,51,54,57],{"skill":49,"purpose":50},"event-log","Log events to keep the audit trail accurate after every write.",{"skill":52,"purpose":53},"actor-profile","Resolve and validate Actor IDs referenced by this skill's entities.",{"skill":55,"purpose":56},"index-management","Query existing entities and keep the SQLite index fresh after writes.",{"skill":58,"purpose":59},"id-management","Allocate unique entity identifiers via central ID generation.",2,1775433600000,"1.0.0","processkit",{"mcp_tools":65,"templates":70,"primitives":71},[66,67,68,69],"create_binding","query_bindings","end_binding","resolve_bindings_for",[21],[72],"Binding","processkit.projectious.work\u002Fv1","Manage Binding entities — scoped, temporal, many-to-many relationships between any two primitives. Use when a relationship between two entities needs scope, time, or its own attributes — e.g. 'Alice is the tech lead for project X from Jan to June' or 'the security gate applies to the release process only on the main branch'.\n","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fbinding-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":82,"prompt":92,"zipAvailable":93},[83,86,89],{"tool":84,"command":85},"npx","npx skills add projectious-work\u002Fprocesskit --skill binding-management",{"tool":87,"command":88},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill binding-management",{"tool":90,"command":91},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill binding-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fbinding-management\u002FSKILL.md",true,[95,101,107,111],{"path":96,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":99,"sourceHtmlUrl":100},"assets\u002Fbinding.yaml","ASSET","资产文件",511,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fbinding-management\u002Fassets\u002Fbinding.yaml",{"path":102,"resourceType":103,"resourceTypeDesc":104,"sizeBytes":105,"sourceHtmlUrl":106},"mcp\u002Fmcp-config.json","REFERENCE","参考文档",219,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fbinding-management\u002Fmcp\u002Fmcp-config.json",{"path":108,"resourceType":103,"resourceTypeDesc":104,"sizeBytes":109,"sourceHtmlUrl":110},"mcp\u002FSERVER.md",2081,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fbinding-management\u002Fmcp\u002FSERVER.md",{"path":112,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":115,"sourceHtmlUrl":116},"mcp\u002Fserver.py","SCRIPT","脚本",8657,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fbinding-management\u002Fmcp\u002Fserver.py",[118,144,164,183,200,218],{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":129,"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",[124],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[20,130,30,131,132,133,134,135,136,137,120,138,139,140,141,142,143],"skill management","update","package","alpha","work","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":151,"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",[150],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},[20,152,153,154,155,156,133,134,157,158,136,159,160,161,138,162,163],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"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",[],[20,171,172,30,131,173,133,134,33,174,175,31,138,176,177,178,179,180,181,182],"proposition","proposition management","index","world","record","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"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",[],[20,137,190,30,133,191,192,157,193,33,136,194,195,138,196,197,177,198,141,199],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":206,"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",[],[207,208,209,210,133,211,212,213,134,214,215,216,217],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":222,"categories":223,"keywords":224,"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",[],[20,225,226,30,131,173,133,191,134,135,33,227,136,175,138,197,177,178,228,143],"capability","capability management","queries","changes"]