[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X0D9BHX46FZY708VRT71VG":3,"skill-same:01M6X0D9BHX46FZY708VRT71VG":102},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":75,"commitSha":76,"skillDirectory":77,"forksCount":14,"repositoryHtmlUrl":78,"repositoryHomepageUrl":79,"ownerHtmlUrl":80,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":81,"install":82,"resources":95},"01M6X0D9BHX46FZY708VRT71VG","process-management",null,"Manage Process entities — declarative sequences of steps with roles, gates, and a definition of done. Use when defining a reusable workflow — code review, release, incident response, onboarding — that the project wants to run consistently.","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\u002Fprocess-management\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"process management","process","management","when","code review","audit trail","definition","project","incident","done","log","work","ids","audit","code","run","workflow","definition of done","incident response","review","2026-11-10 10:12:30",false,"---\nname: process-management\ndescription: |\n  Manage Process entities — declarative sequences of steps with roles, gates, and a definition of done. Use when defining a reusable workflow — code review, release, incident response, onboarding — that the project wants to run consistently.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-process-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      - skill: role-management\n        purpose: Resolve Role IDs when entities need role-based assignment.\n      - skill: gate-management\n        purpose: Evaluate gate conditions before allowing transitions.\n    provides:\n      primitives: [Process]\n      templates: [process]\n---\n\n# Process Management\n\n## Intro\n\nA Process is a declarative definition of a workflow: a sequence of steps,\nthe roles involved, the gates that must pass, and the definition of done.\nprocesskit does NOT execute processes — agents and humans do. processkit\njust defines them.\n\n## Overview\n\n### Shape\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: Process\nmetadata:\n  id: PROC-code-review\n  created: 2026-04-06T00:00:00Z\nspec:\n  name: code-review\n  description: \"Review a pull request before merge.\"\n  triggers: [pr.opened, pr.review-requested]\n  roles: [developer, reviewer]\n  steps:\n    - name: author-self-check\n      role: developer\n      uses_skill: code-review\n      description: \"Author runs the self-review checklist.\"\n    - name: peer-review\n      role: reviewer\n      uses_skill: code-review\n      description: \"A different actor reviews the diff and leaves comments.\"\n      gates: [GATE-no-blocking-comments]\n    - name: approval\n      role: reviewer\n      description: \"Reviewer approves the PR.\"\n      gates: [GATE-code-review-passed]\n    - name: merge\n      role: developer\n      description: \"Author merges after approval and CI pass.\"\n      gates: [GATE-ci-passed, GATE-code-review-passed]\n  definition_of_done: \"PR merged with at least one approval, all CI gates passed.\"\n---\n```\n\n### Workflow\n\n1. Pick `PROC-\u003Cname>`.\n2. List `triggers` — events that kick off the process.\n3. List required `roles`.\n4. Define `steps` in order. Each step names the actor role, optional skill,\n   description, and gates.\n5. Write a clear `definition_of_done`.\n6. Save to `context\u002Fprocesses\u002F`.\n\n### Running a process\n\nAn agent running a process:\n1. Detects the trigger.\n2. Walks the steps in order.\n3. For each step, performs the action (often guided by `uses_skill`).\n4. Validates gates at each step — logs `gate.passed` \u002F `gate.failed`.\n5. Logs `process.step.started` \u002F `process.step.completed`.\n6. Exits when the last step completes or a blocking gate fails.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Defining a Process without ownership.** Every Process needs an\n  owner Actor — the person or role responsible for keeping it\n  current. Unowned Processes drift and become \"the way we used to\n  do things\".\n- **Process with no termination criteria.** A Process must answer\n  \"how do I know this is done\". Open-ended processes that never\n  terminate become noise; the agent has no signal to stop\n  participating.\n- **Hand-waving \"automated steps\" that aren't actually wired.** If\n  a Process step says \"CI runs automatically\", verify the CI hook\n  exists. A Process that lies about its automation is worse than\n  one that admits everything is manual.\n- **Forgetting to version Process changes.** When a Process\n  definition changes, bump the version. Existing in-flight runs\n  should reference the version they started under, not silently\n  inherit the new rules mid-flight.\n- **Mixing Process steps with WorkItems.** A Process step\n  (\"review the PR\") is reusable across many runs; a WorkItem\n  (\"review BACK-1234\") is one specific instance. Don't put\n  workitem-specific data in the Process definition.\n- **Process documentation without examples.** A Process that says\n  \"follow the release checklist\" without linking to a worked\n  example of a past release is incomplete. Examples are the\n  difference between followable and theoretical.\n- **Authoring a Process for a one-off operation.** If you only run\n  it once, it's a runbook entry or a project log, not a Process.\n  Processes earn their cost through repetition.\n\n## Full reference\n\n### Fields\n\n| Field                | Type          | Notes                                              |\n|----------------------|---------------|----------------------------------------------------|\n| `name`               | string        | kebab-case identifier                              |\n| `description`        | string        | One sentence                                       |\n| `triggers`           | list[string]  | Event types that start the process                 |\n| `roles`              | list[string]  | Role names involved                                |\n| `steps`              | list[object]  | Ordered list; see below                            |\n| `definition_of_done` | string        | The acceptance criterion for the whole process     |\n| `parallel`           | bool          | Default false; true = steps run in parallel        |\n| `retryable`          | bool          | Can the process be re-run if it fails?             |\n\n### Step object\n\n```yaml\n- name: \u003Cstep-name>\n  role: \u003Crole-name>         # who performs this step\n  description: \u003Cone-sentence>\n  uses_skill: \u003Cskill-name>  # optional — skill that guides execution\n  inputs: [\u003Centity-ref>]    # optional — what this step needs\n  outputs: [\u003Centity-ref>]   # optional — what this step produces\n  gates: [\u003Cgate-id>]        # optional — gates that must pass\n  on_failure: \u003Caction>      # halt | retry | skip | escalate\n```\n\n### Parallel vs sequential\n\nDefault is sequential. Set `parallel: true` to run steps concurrently when\nthey are independent. For conditional branching, write multiple processes\nand trigger them conditionally rather than embedding complex logic.\n\n### Scoping a process\n\nUse a Binding (`type: process-scope`) to apply a process to a specific\nproject or team:\n\n```yaml\nkind: Binding\nspec:\n  type: process-scope\n  subject: PROC-code-review\n  target: SCOPE-project-x\n```\n\n### No workflow engine\n\nprocesskit does not ship an engine that executes processes. The Process\ndefinition is a contract between the definition and whoever runs it. Agents\nare the default runners; automation can take over specific steps.\n","# Process Management\n\n## Intro\n\nA Process is a declarative definition of a workflow: a sequence of steps,\nthe roles involved, the gates that must pass, and the definition of done.\nprocesskit does NOT execute processes — agents and humans do. processkit\njust defines them.\n\n## Overview\n\n### Shape\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: Process\nmetadata:\n  id: PROC-code-review\n  created: 2026-04-06T00:00:00Z\nspec:\n  name: code-review\n  description: \"Review a pull request before merge.\"\n  triggers: [pr.opened, pr.review-requested]\n  roles: [developer, reviewer]\n  steps:\n    - name: author-self-check\n      role: developer\n      uses_skill: code-review\n      description: \"Author runs the self-review checklist.\"\n    - name: peer-review\n      role: reviewer\n      uses_skill: code-review\n      description: \"A different actor reviews the diff and leaves comments.\"\n      gates: [GATE-no-blocking-comments]\n    - name: approval\n      role: reviewer\n      description: \"Reviewer approves the PR.\"\n      gates: [GATE-code-review-passed]\n    - name: merge\n      role: developer\n      description: \"Author merges after approval and CI pass.\"\n      gates: [GATE-ci-passed, GATE-code-review-passed]\n  definition_of_done: \"PR merged with at least one approval, all CI gates passed.\"\n---\n```\n\n### Workflow\n\n1. Pick `PROC-\u003Cname>`.\n2. List `triggers` — events that kick off the process.\n3. List required `roles`.\n4. Define `steps` in order. Each step names the actor role, optional skill,\n   description, and gates.\n5. Write a clear `definition_of_done`.\n6. Save to `context\u002Fprocesses\u002F`.\n\n### Running a process\n\nAn agent running a process:\n1. Detects the trigger.\n2. Walks the steps in order.\n3. For each step, performs the action (often guided by `uses_skill`).\n4. Validates gates at each step — logs `gate.passed` \u002F `gate.failed`.\n5. Logs `process.step.started` \u002F `process.step.completed`.\n6. Exits when the last step completes or a blocking gate fails.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Defining a Process without ownership.** Every Process needs an\n  owner Actor — the person or role responsible for keeping it\n  current. Unowned Processes drift and become \"the way we used to\n  do things\".\n- **Process with no termination criteria.** A Process must answer\n  \"how do I know this is done\". Open-ended processes that never\n  terminate become noise; the agent has no signal to stop\n  participating.\n- **Hand-waving \"automated steps\" that aren't actually wired.** If\n  a Process step says \"CI runs automatically\", verify the CI hook\n  exists. A Process that lies about its automation is worse than\n  one that admits everything is manual.\n- **Forgetting to version Process changes.** When a Process\n  definition changes, bump the version. Existing in-flight runs\n  should reference the version they started under, not silently\n  inherit the new rules mid-flight.\n- **Mixing Process steps with WorkItems.** A Process step\n  (\"review the PR\") is reusable across many runs; a WorkItem\n  (\"review BACK-1234\") is one specific instance. Don't put\n  workitem-specific data in the Process definition.\n- **Process documentation without examples.** A Process that says\n  \"follow the release checklist\" without linking to a worked\n  example of a past release is incomplete. Examples are the\n  difference between followable and theoretical.\n- **Authoring a Process for a one-off operation.** If you only run\n  it once, it's a runbook entry or a project log, not a Process.\n  Processes earn their cost through repetition.\n\n## Full reference\n\n### Fields\n\n| Field                | Type          | Notes                                              |\n|----------------------|---------------|----------------------------------------------------|\n| `name`               | string        | kebab-case identifier                              |\n| `description`        | string        | One sentence                                       |\n| `triggers`           | list[string]  | Event types that start the process                 |\n| `roles`              | list[string]  | Role names involved                                |\n| `steps`              | list[object]  | Ordered list; see below                            |\n| `definition_of_done` | string        | The acceptance criterion for the whole process     |\n| `parallel`           | bool          | Default false; true = steps run in parallel        |\n| `retryable`          | bool          | Can the process be re-run if it fails?             |\n\n### Step object\n\n```yaml\n- name: \u003Cstep-name>\n  role: \u003Crole-name>         # who performs this step\n  description: \u003Cone-sentence>\n  uses_skill: \u003Cskill-name>  # optional — skill that guides execution\n  inputs: [\u003Centity-ref>]    # optional — what this step needs\n  outputs: [\u003Centity-ref>]   # optional — what this step produces\n  gates: [\u003Cgate-id>]        # optional — gates that must pass\n  on_failure: \u003Caction>      # halt | retry | skip | escalate\n```\n\n### Parallel vs sequential\n\nDefault is sequential. Set `parallel: true` to run steps concurrently when\nthey are independent. For conditional branching, write multiple processes\nand trigger them conditionally rather than embedding complex logic.\n\n### Scoping a process\n\nUse a Binding (`type: process-scope`) to apply a process to a specific\nproject or team:\n\n```yaml\nkind: Binding\nspec:\n  type: process-scope\n  subject: PROC-code-review\n  target: SCOPE-project-x\n```\n\n### No workflow engine\n\nprocesskit does not ship an engine that executes processes. The Process\ndefinition is a contract between the definition and whoever runs it. Agents\nare the default runners; automation can take over specific steps.\n",{"name":5,"metadata":52,"description":74},{"processkit":53},{"id":54,"uses":55,"layer":65,"created":66,"version":67,"category":68,"provides":69,"apiVersion":73},"SKILL-process-management",[56,59,62],{"skill":57,"purpose":58},"event-log","Log events to keep the audit trail accurate after every write.",{"skill":60,"purpose":61},"role-management","Resolve Role IDs when entities need role-based assignment.",{"skill":63,"purpose":64},"gate-management","Evaluate gate conditions before allowing transitions.",3,1775433600000,"1.0.0","processkit",{"templates":70,"primitives":71},[28],[72],"Process","processkit.projectious.work\u002Fv1","Manage Process entities — declarative sequences of steps with roles, gates, and a definition of done. Use when defining a reusable workflow — code review, release, incident response, onboarding — that the project wants to run consistently.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fprocess-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":83,"prompt":93,"zipAvailable":94},[84,87,90],{"tool":85,"command":86},"npx","npx skills add projectious-work\u002Fprocesskit --skill process-management",{"tool":88,"command":89},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill process-management",{"tool":91,"command":92},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill process-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fprocess-management\u002FSKILL.md",true,[96],{"path":97,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"assets\u002Fprocess.yaml","ASSET","资产文件",342,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fprocess-management\u002Fassets\u002Fprocess.yaml",[103,125,145,165,182,200],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":110,"publishedAt":47},"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",[109],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[29,111,112,113,114,115,38,116,117,118,105,119,120,121,122,123,124],"skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"publishedAt":47},"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",[131],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[29,133,134,135,136,137,115,38,138,139,117,140,141,142,119,143,144],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":47},"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",[],[29,152,153,112,113,154,115,38,37,155,156,157,119,158,159,160,161,162,163,164],"proposition","proposition management","index","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":47},"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",[],[29,118,172,112,115,173,174,138,175,37,117,176,177,119,178,179,159,180,122,181],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":47},"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",[],[189,190,191,192,115,193,194,195,38,196,197,198,199],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"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":47},"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",[],[29,207,208,112,113,154,115,173,38,116,37,209,117,156,119,179,159,160,210,124],"capability","capability management","queries","changes"]