[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WX8YDFSWJH0E1KPM3FT0KB":3,"skill-same:01M6WX8YDFSWJH0E1KPM3FT0KB":89},{"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":62,"commitSha":63,"skillDirectory":64,"forksCount":14,"repositoryHtmlUrl":65,"repositoryHomepageUrl":66,"ownerHtmlUrl":67,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":68,"install":69,"resources":82},"01M6WX8YDFSWJH0E1KPM3FT0KB","state-machine-management",null,"Define and customize StateMachine entities — the state\u002Ftransition graphs used by WorkItems, DecisionRecords, and other primitives with lifecycle. Use when a project needs to customize the default state machine for a primitive (add states, change transitions) or define a state machine for a custom entity type.","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.10.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fstate-machine-management\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"state","management","state machine management","state machine","machine","when","customize","custom","for","v1","states","event","keep","define","project","state-machine","default","log","use","lifecycle","2026-11-10 10:12:30",false,"---\nname: state-machine-management\ndescription: |\n  Define and customize StateMachine entities — the state\u002Ftransition graphs used by WorkItems, DecisionRecords, and other primitives with lifecycle. Use when a project needs to customize the default state machine for a primitive (add states, change transitions) or define a state machine for a custom entity type.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-state-machine-management\n    version: \"1.0.0\"\n    created: 2026-04-06T00:00:00Z\n    category: processkit\n    layer: 3\n    uses:\n      - skill: event-log\n        purpose: Log events to keep the audit trail accurate after every write.\n    provides:\n      primitives: [StateMachine]\n      templates: [statemachine]\n---\n\n# State Machine Management\n\n## Intro\n\nA StateMachine defines the valid states of a primitive and the allowed\ntransitions between them. processkit ships default state machines for\nWorkItem and DecisionRecord; projects override these or define new ones\nfor custom entities.\n\n## Overview\n\n### Shape\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: StateMachine\nmetadata:\n  id: SM-workitem\n  name: workitem\n  created: 2026-04-06T00:00:00Z\nspec:\n  description: \"WorkItem lifecycle with a formal review state.\"\n  initial: backlog\n  terminal: [done, cancelled]\n  states:\n    backlog:\n      description: \"Not started.\"\n      transitions:\n        - to: in-progress\n        - to: cancelled\n    in-progress:\n      description: \"Being actively worked on.\"\n      transitions:\n        - to: review\n        - to: blocked\n        - to: cancelled\n    blocked:\n      description: \"Cannot proceed until a blocker is resolved.\"\n      transitions:\n        - to: in-progress\n        - to: cancelled\n    review:\n      description: \"Awaiting review.\"\n      transitions:\n        - to: done\n        - to: in-progress\n    done:\n      description: \"Complete.\"\n      transitions: []\n    cancelled:\n      description: \"Abandoned.\"\n      transitions: []\n---\n```\n\n### Overriding the default\n\nTo customize the workitem state machine for a specific project, put an\noverride at `context\u002Fstate-machines\u002Fworkitem.yaml`. The index MCP server\nand any other validator prefer the project file over the processkit default.\n\nOverrides must:\n- Keep the same `initial` state (or migrate existing data).\n- Not remove states that existing entities are currently in.\n- Add new transitions only from states that already exist.\n\n### Workflow\n\n1. Copy the default from `src\u002Fprimitives\u002Fstate-machines\u002F\u003Cname>.yaml`.\n2. Edit states, transitions, and guards.\n3. Save to `context\u002Fstate-machines\u002F\u003Cname>.yaml`.\n4. Run `aibox lint` (once it validates state machines) — or audit manually\n   to ensure no existing entity is stranded in a state the new machine\n   doesn't know about.\n5. Log `state-machine.updated`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Cycles in the state graph without explicit handling.** A cycle\n  (e.g., `in-review → in-progress → in-review`) is fine if it's\n  intentional, but every cycle should be marked and have an exit\n  criterion. Unmarked cycles cause infinite loops in process\n  execution.\n- **Terminal states with outgoing transitions.** A \"terminal\"\n  state by definition has no outgoing edges. If `cancelled` has a\n  transition to `re-opened`, then `cancelled` isn't terminal —\n  rename it. Mislabeled terminals confuse downstream queries\n  filtering by lifecycle stage.\n- **Missing initial state declaration.** Every state machine\n  needs an explicit `initial` state. Without it, new entities\n  have no lawful starting point and the validator can't reject\n  malformed creations.\n- **Hand-editing state machine YAML instead of using the MCP\n  tools.** Direct edits skip validation. The state-machine\n  primitive enforces \"no orphan states\" and \"all transitions\n  reference declared states\" at write time; bypassing it lets\n  invalid graphs land on disk.\n- **State machine that doesn't match the entity's actual\n  lifecycle.** If the schema says a workitem can be cancelled but\n  the state machine has no `cancelled` state, the two are out of\n  sync and queries break. Schema and state-machine must agree —\n  treat them as one unit when changing either.\n- **Forgetting to update consumers when transitions change.**\n  When you remove a transition (e.g., dropping `in-progress →\n  done` direct), every workitem currently in `in-progress` is\n  stranded. Audit current entities before removing transitions\n  and write a Migration if any are affected.\n- **Adding states without removing dead ones.** State machines\n  accumulate cruft over time. When you introduce a new state\n  that supersedes an old one, remove or deprecate the old one.\n  Otherwise the graph becomes a dictionary of every state anyone\n  ever proposed.\n- **Project-level state machines that diverge silently from\n  defaults.** If a project overrides a default state machine\n  (e.g., `context\u002Fstate-machines\u002Fworkitem.yaml`), record the\n  override as a DecisionRecord. Future maintainers need to know\n  why the project's workitem flow differs from processkit's\n  default.\n\n## Full reference\n\n### Fields\n\n| Field         | Type         | Notes                                                |\n|---------------|--------------|------------------------------------------------------|\n| `description` | string       | What this machine is for                             |\n| `initial`     | string       | Starting state for new entities                     |\n| `terminal`    | list[string] | States with no outgoing transitions                  |\n| `states`      | map          | `state_name → {description, transitions}`           |\n\n### Transition object\n\n```yaml\ntransitions:\n  - to: \u003Cstate-name>\n    guard: \"optional human-readable precondition\"\n    on_enter: \u003Cevent-type>        # LogEntry event to emit\n    required_role: \u003Crole-name>    # who is allowed to make the transition\n```\n\nGuards are advisory unless enforced by an MCP server that knows about them.\n\n### Validation\n\n- No cycles from terminal states.\n- Every non-terminal state has at least one outgoing transition.\n- Every state referenced in `transitions` must exist in `states`.\n- `initial` must exist in `states`.\n\n### Machine history\n\nChanges to a state machine are themselves LogEntries\n(`event_type: state-machine.updated`) rather than git commits alone — this\nlets queries reason about \"what did the valid states look like on date X?\".\n\n### Multiple machines for one kind\n\nYou can ship multiple state machines for the same primitive kind by using\ndistinct `name`s. Entities opt into a specific machine via\n`spec.state_machine: \u003Cname>`. Useful when the same kind has fundamentally\ndifferent lifecycles (e.g. `WorkItem` with `bug-lifecycle` vs `story-lifecycle`).\n","# State Machine Management\n\n## Intro\n\nA StateMachine defines the valid states of a primitive and the allowed\ntransitions between them. processkit ships default state machines for\nWorkItem and DecisionRecord; projects override these or define new ones\nfor custom entities.\n\n## Overview\n\n### Shape\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: StateMachine\nmetadata:\n  id: SM-workitem\n  name: workitem\n  created: 2026-04-06T00:00:00Z\nspec:\n  description: \"WorkItem lifecycle with a formal review state.\"\n  initial: backlog\n  terminal: [done, cancelled]\n  states:\n    backlog:\n      description: \"Not started.\"\n      transitions:\n        - to: in-progress\n        - to: cancelled\n    in-progress:\n      description: \"Being actively worked on.\"\n      transitions:\n        - to: review\n        - to: blocked\n        - to: cancelled\n    blocked:\n      description: \"Cannot proceed until a blocker is resolved.\"\n      transitions:\n        - to: in-progress\n        - to: cancelled\n    review:\n      description: \"Awaiting review.\"\n      transitions:\n        - to: done\n        - to: in-progress\n    done:\n      description: \"Complete.\"\n      transitions: []\n    cancelled:\n      description: \"Abandoned.\"\n      transitions: []\n---\n```\n\n### Overriding the default\n\nTo customize the workitem state machine for a specific project, put an\noverride at `context\u002Fstate-machines\u002Fworkitem.yaml`. The index MCP server\nand any other validator prefer the project file over the processkit default.\n\nOverrides must:\n- Keep the same `initial` state (or migrate existing data).\n- Not remove states that existing entities are currently in.\n- Add new transitions only from states that already exist.\n\n### Workflow\n\n1. Copy the default from `src\u002Fprimitives\u002Fstate-machines\u002F\u003Cname>.yaml`.\n2. Edit states, transitions, and guards.\n3. Save to `context\u002Fstate-machines\u002F\u003Cname>.yaml`.\n4. Run `aibox lint` (once it validates state machines) — or audit manually\n   to ensure no existing entity is stranded in a state the new machine\n   doesn't know about.\n5. Log `state-machine.updated`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Cycles in the state graph without explicit handling.** A cycle\n  (e.g., `in-review → in-progress → in-review`) is fine if it's\n  intentional, but every cycle should be marked and have an exit\n  criterion. Unmarked cycles cause infinite loops in process\n  execution.\n- **Terminal states with outgoing transitions.** A \"terminal\"\n  state by definition has no outgoing edges. If `cancelled` has a\n  transition to `re-opened`, then `cancelled` isn't terminal —\n  rename it. Mislabeled terminals confuse downstream queries\n  filtering by lifecycle stage.\n- **Missing initial state declaration.** Every state machine\n  needs an explicit `initial` state. Without it, new entities\n  have no lawful starting point and the validator can't reject\n  malformed creations.\n- **Hand-editing state machine YAML instead of using the MCP\n  tools.** Direct edits skip validation. The state-machine\n  primitive enforces \"no orphan states\" and \"all transitions\n  reference declared states\" at write time; bypassing it lets\n  invalid graphs land on disk.\n- **State machine that doesn't match the entity's actual\n  lifecycle.** If the schema says a workitem can be cancelled but\n  the state machine has no `cancelled` state, the two are out of\n  sync and queries break. Schema and state-machine must agree —\n  treat them as one unit when changing either.\n- **Forgetting to update consumers when transitions change.**\n  When you remove a transition (e.g., dropping `in-progress →\n  done` direct), every workitem currently in `in-progress` is\n  stranded. Audit current entities before removing transitions\n  and write a Migration if any are affected.\n- **Adding states without removing dead ones.** State machines\n  accumulate cruft over time. When you introduce a new state\n  that supersedes an old one, remove or deprecate the old one.\n  Otherwise the graph becomes a dictionary of every state anyone\n  ever proposed.\n- **Project-level state machines that diverge silently from\n  defaults.** If a project overrides a default state machine\n  (e.g., `context\u002Fstate-machines\u002Fworkitem.yaml`), record the\n  override as a DecisionRecord. Future maintainers need to know\n  why the project's workitem flow differs from processkit's\n  default.\n\n## Full reference\n\n### Fields\n\n| Field         | Type         | Notes                                                |\n|---------------|--------------|------------------------------------------------------|\n| `description` | string       | What this machine is for                             |\n| `initial`     | string       | Starting state for new entities                     |\n| `terminal`    | list[string] | States with no outgoing transitions                  |\n| `states`      | map          | `state_name → {description, transitions}`           |\n\n### Transition object\n\n```yaml\ntransitions:\n  - to: \u003Cstate-name>\n    guard: \"optional human-readable precondition\"\n    on_enter: \u003Cevent-type>        # LogEntry event to emit\n    required_role: \u003Crole-name>    # who is allowed to make the transition\n```\n\nGuards are advisory unless enforced by an MCP server that knows about them.\n\n### Validation\n\n- No cycles from terminal states.\n- Every non-terminal state has at least one outgoing transition.\n- Every state referenced in `transitions` must exist in `states`.\n- `initial` must exist in `states`.\n\n### Machine history\n\nChanges to a state machine are themselves LogEntries\n(`event_type: state-machine.updated`) rather than git commits alone — this\nlets queries reason about \"what did the valid states look like on date X?\".\n\n### Multiple machines for one kind\n\nYou can ship multiple state machines for the same primitive kind by using\ndistinct `name`s. Entities opt into a specific machine via\n`spec.state_machine: \u003Cname>`. Useful when the same kind has fundamentally\ndifferent lifecycles (e.g. `WorkItem` with `bug-lifecycle` vs `story-lifecycle`).\n",{"name":5,"metadata":44,"description":61},{"processkit":45},{"id":46,"uses":47,"layer":51,"created":52,"version":53,"category":54,"provides":55,"apiVersion":60},"SKILL-state-machine-management",[48],{"skill":49,"purpose":50},"event-log","Log events to keep the audit trail accurate after every write.",3,1775433600000,"1.0.0","processkit",{"templates":56,"primitives":58},[57],"statemachine",[59],"StateMachine","processkit.projectious.work\u002Fv1","Define and customize StateMachine entities — the state\u002Ftransition graphs used by WorkItems, DecisionRecords, and other primitives with lifecycle. Use when a project needs to customize the default state machine for a primitive (add states, change transitions) or define a state machine for a custom entity type.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.10.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fstate-machine-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":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add projectious-work\u002Fprocesskit --skill state-machine-management",{"tool":75,"command":76},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill state-machine-management",{"tool":78,"command":79},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill state-machine-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.10.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fstate-machine-management\u002FSKILL.md",true,[83],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"assets\u002Fstatemachine.yaml","ASSET","资产文件",262,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.10.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fstate-machine-management\u002Fassets\u002Fstatemachine.yaml",[90,116,136,155,170,188],{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":101,"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",[96],{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[20,102,103,104,105,106,107,108,109,110,92,111,112,113,28,114,115],"skill management","create","update","package","alpha","work","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":123,"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",[122],{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},[20,124,125,126,127,128,106,107,129,130,109,131,132,133,111,134,135],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"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,143,144,103,104,145,106,107,36,146,147,148,111,149,30,150,151,152,153,154],"proposition","proposition management","index","world","record","query","creation","interface","updates","facts","claims","WSJF",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"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,110,162,103,106,38,163,129,164,36,109,165,166,111,167,31,30,168,28,169],"ontology management","archive","roadmap","do","domain","iteration","measurement","generic",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":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",[],[177,178,179,180,106,181,182,183,107,184,185,186,187],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":194,"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,195,196,103,104,145,106,38,107,108,36,197,109,147,111,31,30,150,198,115],"capability","capability management","queries","changes"]