[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WXZ08QZM2D2C39Z41DM2ZE":3,"skill-same:01M6WXZ08QZM2D2C39Z41DM2ZE":146},{"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":87,"commitSha":88,"skillDirectory":89,"forksCount":14,"repositoryHtmlUrl":90,"repositoryHomepageUrl":91,"ownerHtmlUrl":92,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":93,"install":94,"resources":107},"01M6WXZ08QZM2D2C39Z41DM2ZE","workitem-management",null,"Create, transition, query, and link WorkItems — tasks, stories, bugs, epics. Use when the user asks to add, update, query, or link work items — backlog items, tasks, bugs, user stories, or epics.","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.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fworkitem-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],"workitem management","management","workitem","log","when","audit trail","transition","title","fresh","critical","query","bug","write","work","sqlite","ids","audit","update","create","tasks","2026-11-10 10:12:30",false,"---\nname: workitem-management\ndescription: |\n  Create, transition, query, and link WorkItems — tasks, stories, bugs, epics. Use when the user asks to add, update, query, or link work items — backlog items, tasks, bugs, user stories, or epics.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-workitem-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: [WorkItem]\n      mcp_tools: [create_workitem, transition_workitem, query_workitems, link_workitems]\n      templates: [workitem, workitem-bug, workitem-story]\n    commands:\n      - name: workitem-management-create\n        args: \"title [--type task|story|bug|epic] [--priority critical|high|medium|low]\"\n        description: \"Create a new work item in the backlog with the given title\"\n---\n\n# WorkItem Management\n\n## Intro\n\nWorkItems are the fundamental tracked unit of work in processkit — tasks,\nstories, bugs, spikes, epics, tickets. This skill creates them, transitions\nthem through their state machine, links them to other entities, and queries\nthem.\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 WorkItem\n\nWhenever the user (or you) identifies a distinct unit of work that should be\ntracked. Don't create work items for every tiny thing — a WorkItem is worth\ncreating when it has:\n\n- A clear title (\"Add aibox lint command\")\n- A distinct state lifecycle (it starts somewhere, ends somewhere)\n- Someone who should own it (even if not yet assigned)\n\nIf it's just a one-liner you're about to do in the next 30 seconds, don't\nbother.\n\n### WorkItem types\n\n`spec.type` distinguishes subtypes:\n\n| type    | When to use                                   |\n|---------|-----------------------------------------------|\n| `task`  | Default — generic unit of work                |\n| `story` | User-facing feature framed as a user story    |\n| `bug`   | Something that isn't working as intended      |\n| `epic`  | Large body of work, parent of other WorkItems |\n| `spike` | Time-boxed investigation with no committed deliverable |\n| `chore` | Maintenance, cleanup, refactoring             |\n\n### Creating\n\n1. Pick the `type`.\n2. Write a short, imperative `title`.\n3. Set `state` to the initial state (`backlog` by default).\n4. Set `priority` if known (`critical`\u002F`high`\u002F`medium`\u002F`low`).\n5. Assign to an Actor (optional at creation).\n6. Write the file to `context\u002Fworkitems\u002FBACK-\u003Cid>.md`.\n7. Log `workitem.created`.\n\n### Transitioning\n\nThe default state machine is:\n\n```\nbacklog → in-progress → review → done\n            ↓      ↑\n          blocked ↑\n            ↓      ↑\n          backlog ←\n(any state) → cancelled (terminal)\n```\n\nTo transition:\n1. Check the current state allows the transition (see `primitives\u002Fstate-machines\u002Fworkitem.yaml`).\n2. Update `spec.state`.\n3. Update `metadata.updated`.\n4. Set `spec.started_at` on first entry to `in-progress` (if unset).\n5. Set `spec.completed_at` when entering a terminal state.\n6. Log `workitem.transitioned` with `from_state` and `to_state` in `details`.\n\n### Linking\n\nFour types of links, all expressed in frontmatter:\n\n| Field                | Meaning                                                |\n|----------------------|--------------------------------------------------------|\n| `parent`             | This WorkItem is a child of a larger one (epic)        |\n| `children`           | This WorkItem has sub-items                            |\n| `blocks`             | This WorkItem blocks others until done                 |\n| `blocked_by`         | This WorkItem cannot proceed until others are done     |\n| `related_decisions`  | DecisionRecord IDs that motivated or constrain this    |\n\nFor scoped\u002Ftemporal relationships (e.g. \"Alice is assigned to this for sprint 42\nonly\"), use a Binding instead of `spec.assignee`.\n\n### Querying\n\nCommon queries the index MCP server will expose in Phase 3:\n\n- All WorkItems in a given state\n- All WorkItems assigned to an actor\n- All WorkItems blocked (or blocking something)\n- All WorkItems in a scope\n- Full-text search across title + body\n\nBefore Phase 3, query via filesystem glob + grep of `context\u002Fworkitems\u002F`.\n\nThis skill also provides the `\u002Fworkitem-management-create` slash command for direct invocation — see `commands\u002Fworkitem-management-create.md`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Creating a WorkItem when the user hasn't asked to track work yet.**\n  Sometimes the user is just thinking out loud. Don't translate every\n  mention of \"we should X\" into a backlog entry. Ask: did the user\n  explicitly say to track it, or did you decide to? If you decided, ask\n  first. The Note primitive (when available) is the right home for\n  half-formed ideas; WorkItem is for committed work.\n- **Transitioning state without checking the state machine.** State\n  changes that aren't allowed by `state-machines\u002Fworkitem.yaml` will be\n  rejected by the index, but a hand-edit can create an invalid state\n  on disk. Always go through `transition_workitem` (the MCP tool),\n  never edit `spec.state` directly. If the MCP server says no, the\n  state machine is the source of truth — escalate to the user about\n  the rule, don't bypass it.\n- **Forgetting to log the transition event.** If you transition outside\n  the MCP server (hand-editing for some reason), you must also write\n  the corresponding LogEntry via `event-log`. The audit trail relies\n  on this. Skipping it makes the index drift and breaks every later\n  \"what changed\" query.\n- **Creating duplicate workitems because you didn't query first.**\n  Before `create_workitem`, run `query_workitems` against title and\n  tags. The cost of one query is much smaller than the cost of an\n  orphaned duplicate the user has to merge later.\n- **Setting `priority: critical` on every bug.** \"Critical\" means\n  drop-everything urgency. If everything is critical, nothing is.\n  Default to `medium` and let the user upgrade.\n- **Linking with `blocks` \u002F `blocked_by` and forgetting the inverse.**\n  These are bidirectional. If A blocks B, B is blocked_by A. The MCP\n  server `link_workitems` enforces both sides — hand-edits often miss\n  the inverse, leaving the index inconsistent.\n- **Setting `assignee` on a WorkItem when the assignment is temporal.**\n  \"Alice owns this for sprint 42 only\" is a Binding, not an assignee.\n  Use a Binding entity for any time-bounded or scope-bounded\n  assignment. Assignee is for \"this is fundamentally Alice's\n  responsibility, indefinitely\".\n\n(See also \"Anti-patterns\" in Full reference and the parent\nstate-machine documentation for the canonical transition rules.)\n\n## Full reference\n\n### Full field list\n\nSee `src\u002Fprimitives\u002Fschemas\u002Fworkitem.yaml` for the authoritative schema.\nEvery field there is valid in a WorkItem `spec`.\n\n### State machine override\n\nTo customize the state machine, put a project-specific file at\n`context\u002Fstate-machines\u002Fworkitem.yaml`. The index MCP server will prefer the\nproject file over the processkit default. Transitions not listed in the\ncustom machine are rejected.\n\n### Estimates\n\n`spec.estimate` is intentionally freeform:\n\n```yaml\nestimate:\n  unit: points\n  value: 5\n```\n\nor\n\n```yaml\nestimate:\n  unit: hours\n  value: 4\n  confidence: rough\n```\n\nprocesskit does not mandate a unit. Projects pick one and stick with it.\n\n### Epics and hierarchy\n\nAn epic is just a WorkItem with `spec.type: epic` and many `children`.\nChildren link back via `parent`. There is no hard limit on nesting, but\nflat → one level of epic → tasks is the common shape.\n\n### Relationship to Discussions\n\nWhen a WorkItem emerges from a discussion, link the discussion via\n`spec.related_decisions` (if a decision was recorded) or mention it in the\nbody. The Discussion primitive (shipped later) captures multi-turn\nconversations — a WorkItem is the action that comes out of one.\n\n### Creating via MCP\n\nIn Phase 3, the `workitem-management` MCP server provides:\n\n```\ncreate_workitem(title, type, priority=None, assignee=None, parent=None, scope=None)\n  -> {id, path, state}\n\ntransition_workitem(id, to_state, note=None)\n  -> {ok, from_state, to_state}\n\nquery_workitems(state=None, assignee=None, type=None, scope=None, limit=50)\n  -> [{id, title, state, assignee, priority}, ...]\n\nlink_workitems(from_id, to_id, relation)  # relation ∈ blocks|parent|related\n  -> {ok}\n```\n\nUntil then, agents perform the same operations by editing files directly\nfollowing this SKILL.md.\n\n### File naming\n\nDefault: `context\u002Fworkitems\u002FBACK-\u003Cid>.md`. With shards:\n\n```toml\n[context.sharding.WorkItem]\nscheme = \"state\"\npattern = \"context\u002Fworkitems\u002F{state}\u002F\"\n```\n\nThis moves files as they transition. Turned off by default — most projects\nprefer flat.\n","# WorkItem Management\n\n## Intro\n\nWorkItems are the fundamental tracked unit of work in processkit — tasks,\nstories, bugs, spikes, epics, tickets. This skill creates them, transitions\nthem through their state machine, links them to other entities, and queries\nthem.\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 WorkItem\n\nWhenever the user (or you) identifies a distinct unit of work that should be\ntracked. Don't create work items for every tiny thing — a WorkItem is worth\ncreating when it has:\n\n- A clear title (\"Add aibox lint command\")\n- A distinct state lifecycle (it starts somewhere, ends somewhere)\n- Someone who should own it (even if not yet assigned)\n\nIf it's just a one-liner you're about to do in the next 30 seconds, don't\nbother.\n\n### WorkItem types\n\n`spec.type` distinguishes subtypes:\n\n| type    | When to use                                   |\n|---------|-----------------------------------------------|\n| `task`  | Default — generic unit of work                |\n| `story` | User-facing feature framed as a user story    |\n| `bug`   | Something that isn't working as intended      |\n| `epic`  | Large body of work, parent of other WorkItems |\n| `spike` | Time-boxed investigation with no committed deliverable |\n| `chore` | Maintenance, cleanup, refactoring             |\n\n### Creating\n\n1. Pick the `type`.\n2. Write a short, imperative `title`.\n3. Set `state` to the initial state (`backlog` by default).\n4. Set `priority` if known (`critical`\u002F`high`\u002F`medium`\u002F`low`).\n5. Assign to an Actor (optional at creation).\n6. Write the file to `context\u002Fworkitems\u002FBACK-\u003Cid>.md`.\n7. Log `workitem.created`.\n\n### Transitioning\n\nThe default state machine is:\n\n```\nbacklog → in-progress → review → done\n            ↓      ↑\n          blocked ↑\n            ↓      ↑\n          backlog ←\n(any state) → cancelled (terminal)\n```\n\nTo transition:\n1. Check the current state allows the transition (see `primitives\u002Fstate-machines\u002Fworkitem.yaml`).\n2. Update `spec.state`.\n3. Update `metadata.updated`.\n4. Set `spec.started_at` on first entry to `in-progress` (if unset).\n5. Set `spec.completed_at` when entering a terminal state.\n6. Log `workitem.transitioned` with `from_state` and `to_state` in `details`.\n\n### Linking\n\nFour types of links, all expressed in frontmatter:\n\n| Field                | Meaning                                                |\n|----------------------|--------------------------------------------------------|\n| `parent`             | This WorkItem is a child of a larger one (epic)        |\n| `children`           | This WorkItem has sub-items                            |\n| `blocks`             | This WorkItem blocks others until done                 |\n| `blocked_by`         | This WorkItem cannot proceed until others are done     |\n| `related_decisions`  | DecisionRecord IDs that motivated or constrain this    |\n\nFor scoped\u002Ftemporal relationships (e.g. \"Alice is assigned to this for sprint 42\nonly\"), use a Binding instead of `spec.assignee`.\n\n### Querying\n\nCommon queries the index MCP server will expose in Phase 3:\n\n- All WorkItems in a given state\n- All WorkItems assigned to an actor\n- All WorkItems blocked (or blocking something)\n- All WorkItems in a scope\n- Full-text search across title + body\n\nBefore Phase 3, query via filesystem glob + grep of `context\u002Fworkitems\u002F`.\n\nThis skill also provides the `\u002Fworkitem-management-create` slash command for direct invocation — see `commands\u002Fworkitem-management-create.md`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Creating a WorkItem when the user hasn't asked to track work yet.**\n  Sometimes the user is just thinking out loud. Don't translate every\n  mention of \"we should X\" into a backlog entry. Ask: did the user\n  explicitly say to track it, or did you decide to? If you decided, ask\n  first. The Note primitive (when available) is the right home for\n  half-formed ideas; WorkItem is for committed work.\n- **Transitioning state without checking the state machine.** State\n  changes that aren't allowed by `state-machines\u002Fworkitem.yaml` will be\n  rejected by the index, but a hand-edit can create an invalid state\n  on disk. Always go through `transition_workitem` (the MCP tool),\n  never edit `spec.state` directly. If the MCP server says no, the\n  state machine is the source of truth — escalate to the user about\n  the rule, don't bypass it.\n- **Forgetting to log the transition event.** If you transition outside\n  the MCP server (hand-editing for some reason), you must also write\n  the corresponding LogEntry via `event-log`. The audit trail relies\n  on this. Skipping it makes the index drift and breaks every later\n  \"what changed\" query.\n- **Creating duplicate workitems because you didn't query first.**\n  Before `create_workitem`, run `query_workitems` against title and\n  tags. The cost of one query is much smaller than the cost of an\n  orphaned duplicate the user has to merge later.\n- **Setting `priority: critical` on every bug.** \"Critical\" means\n  drop-everything urgency. If everything is critical, nothing is.\n  Default to `medium` and let the user upgrade.\n- **Linking with `blocks` \u002F `blocked_by` and forgetting the inverse.**\n  These are bidirectional. If A blocks B, B is blocked_by A. The MCP\n  server `link_workitems` enforces both sides — hand-edits often miss\n  the inverse, leaving the index inconsistent.\n- **Setting `assignee` on a WorkItem when the assignment is temporal.**\n  \"Alice owns this for sprint 42 only\" is a Binding, not an assignee.\n  Use a Binding entity for any time-bounded or scope-bounded\n  assignment. Assignee is for \"this is fundamentally Alice's\n  responsibility, indefinitely\".\n\n(See also \"Anti-patterns\" in Full reference and the parent\nstate-machine documentation for the canonical transition rules.)\n\n## Full reference\n\n### Full field list\n\nSee `src\u002Fprimitives\u002Fschemas\u002Fworkitem.yaml` for the authoritative schema.\nEvery field there is valid in a WorkItem `spec`.\n\n### State machine override\n\nTo customize the state machine, put a project-specific file at\n`context\u002Fstate-machines\u002Fworkitem.yaml`. The index MCP server will prefer the\nproject file over the processkit default. Transitions not listed in the\ncustom machine are rejected.\n\n### Estimates\n\n`spec.estimate` is intentionally freeform:\n\n```yaml\nestimate:\n  unit: points\n  value: 5\n```\n\nor\n\n```yaml\nestimate:\n  unit: hours\n  value: 4\n  confidence: rough\n```\n\nprocesskit does not mandate a unit. Projects pick one and stick with it.\n\n### Epics and hierarchy\n\nAn epic is just a WorkItem with `spec.type: epic` and many `children`.\nChildren link back via `parent`. There is no hard limit on nesting, but\nflat → one level of epic → tasks is the common shape.\n\n### Relationship to Discussions\n\nWhen a WorkItem emerges from a discussion, link the discussion via\n`spec.related_decisions` (if a decision was recorded) or mention it in the\nbody. The Discussion primitive (shipped later) captures multi-turn\nconversations — a WorkItem is the action that comes out of one.\n\n### Creating via MCP\n\nIn Phase 3, the `workitem-management` MCP server provides:\n\n```\ncreate_workitem(title, type, priority=None, assignee=None, parent=None, scope=None)\n  -> {id, path, state}\n\ntransition_workitem(id, to_state, note=None)\n  -> {ok, from_state, to_state}\n\nquery_workitems(state=None, assignee=None, type=None, scope=None, limit=50)\n  -> [{id, title, state, assignee, priority}, ...]\n\nlink_workitems(from_id, to_id, relation)  # relation ∈ blocks|parent|related\n  -> {ok}\n```\n\nUntil then, agents perform the same operations by editing files directly\nfollowing this SKILL.md.\n\n### File naming\n\nDefault: `context\u002Fworkitems\u002FBACK-\u003Cid>.md`. With shards:\n\n```toml\n[context.sharding.WorkItem]\nscheme = \"state\"\npattern = \"context\u002Fworkitems\u002F{state}\u002F\"\n```\n\nThis moves files as they transition. Turned off by default — most projects\nprefer flat.\n",{"name":5,"metadata":49,"description":86},{"processkit":50},{"id":51,"uses":52,"layer":65,"created":66,"version":67,"category":68,"commands":69,"provides":74,"apiVersion":85},"SKILL-workitem-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},"actor-profile","Resolve and validate Actor IDs referenced by this skill's entities.",{"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.",2,1775433600000,"1.0.0","processkit",[70],{"args":71,"name":72,"description":73},"title [--type task|story|bug|epic] [--priority critical|high|medium|low]","workitem-management-create","Create a new work item in the backlog with the given title",{"mcp_tools":75,"templates":80,"primitives":83},[76,77,78,79],"create_workitem","transition_workitem","query_workitems","link_workitems",[26,81,82],"workitem-bug","workitem-story",[84],"WorkItem","processkit.projectious.work\u002Fv1","Create, transition, query, and link WorkItems — tasks, stories, bugs, epics. Use when the user asks to add, update, query, or link work items — backlog items, tasks, bugs, user stories, or epics.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fworkitem-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":95,"prompt":105,"zipAvailable":106},[96,99,102],{"tool":97,"command":98},"npx","npx skills add projectious-work\u002Fprocesskit --skill workitem-management",{"tool":100,"command":101},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill workitem-management",{"tool":103,"command":104},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill workitem-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fworkitem-management\u002FSKILL.md",true,[108,114,118,122,128,132,136,140],{"path":109,"resourceType":110,"resourceTypeDesc":111,"sizeBytes":112,"sourceHtmlUrl":113},"assets\u002Fworkitem-bug.yaml","ASSET","资产文件",390,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fworkitem-management\u002Fassets\u002Fworkitem-bug.yaml",{"path":115,"resourceType":110,"resourceTypeDesc":111,"sizeBytes":116,"sourceHtmlUrl":117},"assets\u002Fworkitem-story.yaml",312,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fworkitem-management\u002Fassets\u002Fworkitem-story.yaml",{"path":119,"resourceType":110,"resourceTypeDesc":111,"sizeBytes":120,"sourceHtmlUrl":121},"assets\u002Fworkitem.yaml",262,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fworkitem-management\u002Fassets\u002Fworkitem.yaml",{"path":123,"resourceType":124,"resourceTypeDesc":125,"sizeBytes":126,"sourceHtmlUrl":127},"commands\u002Fworkitem-management-create.md","REFERENCE","参考文档",190,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fworkitem-management\u002Fcommands\u002Fworkitem-management-create.md",{"path":129,"resourceType":124,"resourceTypeDesc":125,"sizeBytes":130,"sourceHtmlUrl":131},"examples\u002Fcreate-feature.md",2665,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fworkitem-management\u002Fexamples\u002Fcreate-feature.md",{"path":133,"resourceType":124,"resourceTypeDesc":125,"sizeBytes":134,"sourceHtmlUrl":135},"mcp\u002Fmcp-config.json",210,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fworkitem-management\u002Fmcp\u002Fmcp-config.json",{"path":137,"resourceType":124,"resourceTypeDesc":125,"sizeBytes":138,"sourceHtmlUrl":139},"mcp\u002FSERVER.md",2351,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fworkitem-management\u002Fmcp\u002FSERVER.md",{"path":141,"resourceType":142,"resourceTypeDesc":143,"sizeBytes":144,"sourceHtmlUrl":145},"mcp\u002Fserver.py","SCRIPT","脚本",9908,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fworkitem-management\u002Fmcp\u002Fserver.py",[147,166,186,205,222,240],{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":154,"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",[153],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[25,155,42,41,156,157,37,158,159,160,149,161,162,163,164,165,30],"skill management","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package",{"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":173,"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",[172],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[25,174,175,176,177,178,157,37,179,180,159,181,182,183,161,184,185],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"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,193,194,42,41,195,157,37,27,196,197,34,161,198,199,200,201,202,203,204],"proposition","proposition management","index","world","record","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":211,"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,160,212,42,157,213,214,179,215,27,159,216,217,161,218,219,199,220,164,221],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":223,"name":224,"nameZh":6,"description":225,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":226,"categories":227,"keywords":228,"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",[],[229,230,231,232,157,233,234,235,37,236,237,238,239],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":241,"name":242,"nameZh":6,"description":243,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":244,"categories":245,"keywords":246,"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,247,248,42,41,195,157,213,37,158,27,249,159,197,161,219,199,200,250,30],"capability","capability management","queries","changes"]