[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X3QWDM31AFXY1T4FBSFBDV":3,"skill-same:01M6X3QWDM31AFXY1T4FBSFBDV":135},{"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":84,"commitSha":85,"skillDirectory":86,"forksCount":14,"repositoryHtmlUrl":87,"repositoryHomepageUrl":88,"ownerHtmlUrl":89,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":90,"install":91,"resources":104},"01M6X3QWDM31AFXY1T4FBSFBDV","decision-record",null,"Record decisions with rationale, alternatives, and consequences — the ADR pattern as a primitive. Use when a consequential choice is made — architecture, tooling, process, scope, trade-off. Capture WHY, not just WHAT.","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.7.0\u002Fskills\u002Fdecision-record\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"decision record","decision","record","when","architecture","audit trail","title","supersede","filter","scope","fresh","query","log","work","choice","why","sqlite","ids","audit","product","2026-11-10 10:12:30",false,"---\nname: decision-record\ndescription: |\n  Record decisions with rationale, alternatives, and consequences — the ADR pattern as a primitive. Use when a consequential choice is made — architecture, tooling, process, scope, trade-off. Capture WHY, not just WHAT.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-decision-record\n    version: \"1.0.0\"\n    created: 2026-04-06T00:00:00Z\n    category: process\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: [DecisionRecord]\n      mcp_tools: [record_decision, query_decisions, link_decision, supersede_decision]\n      templates: [decisionrecord]\n    commands:\n      - name: decision-record-write\n        args: \"decision-title\"\n        description: \"Record a new architectural or product decision with the given title\"\n      - name: decision-record-query\n        args: \"filter\"\n        description: \"Query existing decisions by keyword, status, or topic\"\n---\n\n# Decision Record\n\n## Intro\n\nA DecisionRecord captures a single consequential choice: what was decided,\nwhy, what alternatives were rejected, and what consequences are expected.\nThis is the classic **Architecture Decision Record (ADR)** pattern, promoted\nto a first-class primitive in processkit.\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 record a decision\n\nRecord a decision when the choice:\n\n- Has consequences someone will ask about in six months (\"why are we using X?\").\n- Rules out real alternatives that took thought to reject.\n- Affects more than one file, component, or person.\n- Is the kind of thing that \"we decided in a meeting\" but nobody wrote down.\n\nDon't record: trivial choices made inside a single function, preference calls\nwith no downside, decisions already documented somewhere authoritative.\n\n### Shape\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: DecisionRecord\nmetadata:\n  id: DEC-steady-river\n  created: 2026-04-06T00:00:00Z\nspec:\n  title: \"Use official Python MCP SDK with uv PEP 723 inline dependencies\"\n  state: accepted\n  context: \"Skill MCP servers need a runtime. Options vary from zero-dep stdlib to full SDK.\"\n  decision: \"Use the official mcp Python SDK, distributed as standalone scripts with PEP 723 inline deps, launched via uv.\"\n  rationale: |\n    - The SDK is the standard; rolling our own JSON-RPC means maintaining protocol code.\n    - PEP 723 + uv eliminates per-skill env setup; uv caching amortizes first-run cost.\n    - Container already has Python ≥3.10 and uv — no base image change.\n  alternatives:\n    - option: \"Raw JSON-RPC with zero dependencies\"\n      rejected_because: \"Reimplements the protocol, fragile for complex servers.\"\n    - option: \"Pydantic-only minimal server\"\n      rejected_because: \"Kept as escape hatch if container size becomes critical; not default.\"\n  consequences: |\n    - +300-400 MB image size per skill with MCP server.\n    - First-run 5-10s for uv resolution; cached thereafter.\n    - Escape hatch documented if size becomes an issue.\n  deciders: [ACTOR-owner, ACTOR-claude]\n  decided_at: 2026-04-05T00:00:00Z\n---\n\nOptional body: longer narrative, links to the discussion, related research.\n```\n\n### Workflow\n\n1. Pick an ID: `DEC-\u003Cgenerated-id>`.\n2. Write a declarative `title` — state the decision itself, not a question.\n3. Fill in `context` (what prompted this), `decision` (the chosen option),\n   `rationale` (why).\n4. List `alternatives` with explicit `rejected_because` — this is the part\n   future-you will thank present-you for.\n5. Write `consequences` — what follows from this decision, positive and\n   negative.\n6. Set `state: proposed` if still under discussion, `accepted` if finalized.\n7. Save to `context\u002Fdecisions\u002F`.\n8. Log `decision.proposed` or `decision.accepted`.\n\n### Superseding\n\nWhen a decision is replaced by a later one:\n\n1. In the **new** DecisionRecord, set `spec.supersedes: DEC-\u003Cold-id>`.\n2. In the **old** DecisionRecord, set `spec.state: superseded` and\n   `spec.superseded_by: DEC-\u003Cnew-id>`.\n3. Log `decision.superseded` referencing both IDs.\n\n**Never delete or edit the old record.** Its existence is why we can trace\nthe evolution of the decision.\n\nThis skill also provides the `\u002Fdecision-record-write` slash command for direct invocation — see `commands\u002Fdecision-record-write.md`. This skill also provides the `\u002Fdecision-record-query` slash command for direct invocation — see `commands\u002Fdecision-record-query.md`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Recording a decision before it has actually been made.** A\n  proposal in a discussion is not a DecisionRecord. Open a Discussion\n  if reasoning is still in flight; only record when the choice is\n  settled. Recording too early creates a fictional history.\n- **Capturing WHAT but not WHY.** A DecisionRecord without rationale\n  is just a workitem in the wrong directory. The whole value of the\n  ADR pattern is the reasoning trail — what was considered, why this\n  was picked, what was rejected.\n- **Omitting the rejected alternatives.** \"We decided X\" is half a\n  decision; \"We picked X over Y and Z because …\" is a decision.\n  Future-you needs the alternatives to know whether the call still\n  holds when context changes.\n- **Editing an old DecisionRecord instead of superseding it.**\n  Decisions are immutable history. If the call needs to change, write\n  a NEW DecisionRecord with `supersedes:` pointing at the old one\n  and set the old one's state to `superseded`. Never overwrite — the\n  old reasoning is part of the audit trail.\n- **Recording trivial choices as DecisionRecords.** A DecisionRecord\n  is overhead; reserve it for choices a future agent or human will\n  ask about in six months. Variable naming inside one function is\n  not a DecisionRecord.\n- **Putting the rationale in the Discussion body instead of the\n  DecisionRecord.** Discussions are pre-decisional reasoning;\n  DecisionRecords are post-decisional summary. The rationale must\n  be copied (not linked) into the DecisionRecord so the latter is\n  self-contained when read in isolation.\n- **Hallucinating decision history when the user asks \"what did we\n  decide about X\".** Run `query_decisions` and `search_entities`\n  against the actual store before answering. Do not synthesize an\n  answer from memory; it will be wrong.\n\n## Full reference\n\n### State machine\n\nSee `src\u002Fprimitives\u002Fstate-machines\u002Fdecisionrecord.yaml`:\n\n```\nproposed → accepted → superseded (terminal)\n    ↓\n  rejected (terminal)\n```\n\n`rejected` is for decisions considered and declined — kept for history.\n`superseded` is for decisions replaced by a later one.\n\n### Full field list\n\nSee `src\u002Fprimitives\u002Fschemas\u002Fdecisionrecord.yaml`. Notable fields:\n\n- `deciders`: list of Actor IDs. Who agreed.\n- `supersedes` \u002F `superseded_by`: DEC IDs. Replacement chain.\n- `related_workitems`: BACK IDs. Work that prompted or implements the decision.\n- `decided_at`: when the decision was finalized. Distinct from\n  `metadata.created` (when the file was written).\n\n### Distinguishing decisions from discussions\n\nA **Discussion** (separate primitive) is a multi-turn conversation exploring\na question. A **DecisionRecord** is the crisp outcome. Workflow:\n\n1. Open a Discussion when a question arises.\n2. Explore, debate, research.\n3. When the group converges on an answer, write a DecisionRecord.\n4. Link the Discussion via `spec.related_discussions` (cross-reference).\n\nNot every discussion produces a decision; not every decision is preceded by\na discussion.\n\n### Writing good titles\n\nGood titles are declarative, active, and concrete:\n\n- ✓ \"Use official Python MCP SDK with uv PEP 723 inline dependencies\"\n- ✓ \"Two-repo split: aibox + processkit\"\n- ✗ \"Which MCP library to use?\" (question, not decision)\n- ✗ \"Tooling update\" (too vague)\n- ✗ \"Alice's proposal\" (credits the person, not the decision)\n\n### Consequences that are honest\n\nFuture readers trust the decision record more when you write the real\nconsequences, including the uncomfortable ones. \"Costs 300-400 MB image\nsize\" builds more credibility than \"some increase in container size.\"\n\n### Linking to workitems\n\nWhen a decision prompts work to happen, link via `spec.related_workitems`:\n\n```yaml\nspec:\n  related_workitems: [BACK-calm-fox, BACK-swift-oak]\n```\n\nThis lets queries find \"all work that implements DEC-foo\" and \"all\ndecisions that motivated BACK-bar.\"\n","# Decision Record\n\n## Intro\n\nA DecisionRecord captures a single consequential choice: what was decided,\nwhy, what alternatives were rejected, and what consequences are expected.\nThis is the classic **Architecture Decision Record (ADR)** pattern, promoted\nto a first-class primitive in processkit.\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 record a decision\n\nRecord a decision when the choice:\n\n- Has consequences someone will ask about in six months (\"why are we using X?\").\n- Rules out real alternatives that took thought to reject.\n- Affects more than one file, component, or person.\n- Is the kind of thing that \"we decided in a meeting\" but nobody wrote down.\n\nDon't record: trivial choices made inside a single function, preference calls\nwith no downside, decisions already documented somewhere authoritative.\n\n### Shape\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: DecisionRecord\nmetadata:\n  id: DEC-steady-river\n  created: 2026-04-06T00:00:00Z\nspec:\n  title: \"Use official Python MCP SDK with uv PEP 723 inline dependencies\"\n  state: accepted\n  context: \"Skill MCP servers need a runtime. Options vary from zero-dep stdlib to full SDK.\"\n  decision: \"Use the official mcp Python SDK, distributed as standalone scripts with PEP 723 inline deps, launched via uv.\"\n  rationale: |\n    - The SDK is the standard; rolling our own JSON-RPC means maintaining protocol code.\n    - PEP 723 + uv eliminates per-skill env setup; uv caching amortizes first-run cost.\n    - Container already has Python ≥3.10 and uv — no base image change.\n  alternatives:\n    - option: \"Raw JSON-RPC with zero dependencies\"\n      rejected_because: \"Reimplements the protocol, fragile for complex servers.\"\n    - option: \"Pydantic-only minimal server\"\n      rejected_because: \"Kept as escape hatch if container size becomes critical; not default.\"\n  consequences: |\n    - +300-400 MB image size per skill with MCP server.\n    - First-run 5-10s for uv resolution; cached thereafter.\n    - Escape hatch documented if size becomes an issue.\n  deciders: [ACTOR-owner, ACTOR-claude]\n  decided_at: 2026-04-05T00:00:00Z\n---\n\nOptional body: longer narrative, links to the discussion, related research.\n```\n\n### Workflow\n\n1. Pick an ID: `DEC-\u003Cgenerated-id>`.\n2. Write a declarative `title` — state the decision itself, not a question.\n3. Fill in `context` (what prompted this), `decision` (the chosen option),\n   `rationale` (why).\n4. List `alternatives` with explicit `rejected_because` — this is the part\n   future-you will thank present-you for.\n5. Write `consequences` — what follows from this decision, positive and\n   negative.\n6. Set `state: proposed` if still under discussion, `accepted` if finalized.\n7. Save to `context\u002Fdecisions\u002F`.\n8. Log `decision.proposed` or `decision.accepted`.\n\n### Superseding\n\nWhen a decision is replaced by a later one:\n\n1. In the **new** DecisionRecord, set `spec.supersedes: DEC-\u003Cold-id>`.\n2. In the **old** DecisionRecord, set `spec.state: superseded` and\n   `spec.superseded_by: DEC-\u003Cnew-id>`.\n3. Log `decision.superseded` referencing both IDs.\n\n**Never delete or edit the old record.** Its existence is why we can trace\nthe evolution of the decision.\n\nThis skill also provides the `\u002Fdecision-record-write` slash command for direct invocation — see `commands\u002Fdecision-record-write.md`. This skill also provides the `\u002Fdecision-record-query` slash command for direct invocation — see `commands\u002Fdecision-record-query.md`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Recording a decision before it has actually been made.** A\n  proposal in a discussion is not a DecisionRecord. Open a Discussion\n  if reasoning is still in flight; only record when the choice is\n  settled. Recording too early creates a fictional history.\n- **Capturing WHAT but not WHY.** A DecisionRecord without rationale\n  is just a workitem in the wrong directory. The whole value of the\n  ADR pattern is the reasoning trail — what was considered, why this\n  was picked, what was rejected.\n- **Omitting the rejected alternatives.** \"We decided X\" is half a\n  decision; \"We picked X over Y and Z because …\" is a decision.\n  Future-you needs the alternatives to know whether the call still\n  holds when context changes.\n- **Editing an old DecisionRecord instead of superseding it.**\n  Decisions are immutable history. If the call needs to change, write\n  a NEW DecisionRecord with `supersedes:` pointing at the old one\n  and set the old one's state to `superseded`. Never overwrite — the\n  old reasoning is part of the audit trail.\n- **Recording trivial choices as DecisionRecords.** A DecisionRecord\n  is overhead; reserve it for choices a future agent or human will\n  ask about in six months. Variable naming inside one function is\n  not a DecisionRecord.\n- **Putting the rationale in the Discussion body instead of the\n  DecisionRecord.** Discussions are pre-decisional reasoning;\n  DecisionRecords are post-decisional summary. The rationale must\n  be copied (not linked) into the DecisionRecord so the latter is\n  self-contained when read in isolation.\n- **Hallucinating decision history when the user asks \"what did we\n  decide about X\".** Run `query_decisions` and `search_entities`\n  against the actual store before answering. Do not synthesize an\n  answer from memory; it will be wrong.\n\n## Full reference\n\n### State machine\n\nSee `src\u002Fprimitives\u002Fstate-machines\u002Fdecisionrecord.yaml`:\n\n```\nproposed → accepted → superseded (terminal)\n    ↓\n  rejected (terminal)\n```\n\n`rejected` is for decisions considered and declined — kept for history.\n`superseded` is for decisions replaced by a later one.\n\n### Full field list\n\nSee `src\u002Fprimitives\u002Fschemas\u002Fdecisionrecord.yaml`. Notable fields:\n\n- `deciders`: list of Actor IDs. Who agreed.\n- `supersedes` \u002F `superseded_by`: DEC IDs. Replacement chain.\n- `related_workitems`: BACK IDs. Work that prompted or implements the decision.\n- `decided_at`: when the decision was finalized. Distinct from\n  `metadata.created` (when the file was written).\n\n### Distinguishing decisions from discussions\n\nA **Discussion** (separate primitive) is a multi-turn conversation exploring\na question. A **DecisionRecord** is the crisp outcome. Workflow:\n\n1. Open a Discussion when a question arises.\n2. Explore, debate, research.\n3. When the group converges on an answer, write a DecisionRecord.\n4. Link the Discussion via `spec.related_discussions` (cross-reference).\n\nNot every discussion produces a decision; not every decision is preceded by\na discussion.\n\n### Writing good titles\n\nGood titles are declarative, active, and concrete:\n\n- ✓ \"Use official Python MCP SDK with uv PEP 723 inline dependencies\"\n- ✓ \"Two-repo split: aibox + processkit\"\n- ✗ \"Which MCP library to use?\" (question, not decision)\n- ✗ \"Tooling update\" (too vague)\n- ✗ \"Alice's proposal\" (credits the person, not the decision)\n\n### Consequences that are honest\n\nFuture readers trust the decision record more when you write the real\nconsequences, including the uncomfortable ones. \"Costs 300-400 MB image\nsize\" builds more credibility than \"some increase in container size.\"\n\n### Linking to workitems\n\nWhen a decision prompts work to happen, link via `spec.related_workitems`:\n\n```yaml\nspec:\n  related_workitems: [BACK-calm-fox, BACK-swift-oak]\n```\n\nThis lets queries find \"all work that implements DEC-foo\" and \"all\ndecisions that motivated BACK-bar.\"\n",{"name":5,"metadata":44,"description":83},{"processkit":45},{"id":46,"uses":47,"layer":60,"created":61,"version":62,"category":63,"commands":64,"provides":72,"apiVersion":82},"SKILL-decision-record",[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","process",[65,69],{"args":66,"name":67,"description":68},"decision-title","decision-record-write","Record a new architectural or product decision with the given title",{"args":27,"name":70,"description":71},"decision-record-query","Query existing decisions by keyword, status, or topic",{"mcp_tools":73,"templates":78,"primitives":80},[74,75,76,77],"record_decision","query_decisions","link_decision","supersede_decision",[79],"decisionrecord",[81],"DecisionRecord","processkit.projectious.work\u002Fv1","Record decisions with rationale, alternatives, and consequences — the ADR pattern as a primitive. Use when a consequential choice is made — architecture, tooling, process, scope, trade-off. Capture WHY, not just WHAT.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fdecision-record","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":92,"prompt":102,"zipAvailable":103},[93,96,99],{"tool":94,"command":95},"npx","npx skills add projectious-work\u002Fprocesskit --skill decision-record",{"tool":97,"command":98},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill decision-record",{"tool":100,"command":101},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill decision-record","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fdecision-record\u002FSKILL.md",true,[105,111,117,121,125,129],{"path":106,"resourceType":107,"resourceTypeDesc":108,"sizeBytes":109,"sourceHtmlUrl":110},"assets\u002Fdecisionrecord.yaml","ASSET","资产文件",587,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fdecision-record\u002Fassets\u002Fdecisionrecord.yaml",{"path":112,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":115,"sourceHtmlUrl":116},"commands\u002Fdecision-record-query.md","REFERENCE","参考文档",128,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fdecision-record\u002Fcommands\u002Fdecision-record-query.md",{"path":118,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":119,"sourceHtmlUrl":120},"commands\u002Fdecision-record-write.md",131,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fdecision-record\u002Fcommands\u002Fdecision-record-write.md",{"path":122,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":123,"sourceHtmlUrl":124},"mcp\u002Fmcp-config.json",202,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fdecision-record\u002Fmcp\u002Fmcp-config.json",{"path":126,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":127,"sourceHtmlUrl":128},"mcp\u002FSERVER.md",2354,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fdecision-record\u002Fmcp\u002FSERVER.md",{"path":130,"resourceType":131,"resourceTypeDesc":132,"sizeBytes":133,"sourceHtmlUrl":134},"mcp\u002Fserver.py","SCRIPT","脚本",8716,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fdecision-record\u002Fmcp\u002Fserver.py",[136,163,183,201,218,236],{"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":147,"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",[142],{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[148,149,150,151,152,153,32,154,155,156,138,157,158,159,160,161,162],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":170,"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",[169],{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},[148,171,172,173,174,175,153,32,176,177,155,178,179,180,157,181,182],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"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},"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",[],[148,190,191,150,151,192,153,32,31,193,21,30,157,194,195,196,197,198,199,200],"proposition","proposition management","index","world","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":207,"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",[],[148,156,208,150,153,209,210,176,211,31,155,212,213,157,214,215,195,216,160,217],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"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},"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",[],[225,226,227,228,153,229,230,231,32,232,233,234,235],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":237,"name":238,"nameZh":6,"description":239,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":240,"categories":241,"keywords":242,"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",[],[148,243,244,150,151,192,153,209,32,154,31,245,155,21,157,215,195,196,246,162],"capability","capability management","queries","changes"]