[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NQBECSDFW08C65X0DT5QXG":3,"skill-same:01M6NQBECSDFW08C65X0DT5QXG":138},{"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},"01M6NQBECSDFW08C65X0DT5QXG","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\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\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","log","title","supersede","filter","scope","fresh","pattern","query","architecture","write","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\u002Fv2\n    id: SKILL-decision-record\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: [DecisionRecord]\n      mcp_tools: [record_decision, query_decisions, link_decision, supersede_decision]\n      templates: [decisionrecord]\n    commands:\n      - name: pk-dec\n        args: \"decision-title\"\n        description: \"Record a new architectural or product decision with the given title\"\n      - name: pk-dec-find\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\u002Fv2\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.created`; later state changes use\n   `decision.transitioned`.\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 `\u002Fpk-dec` and `\u002Fpk-dec-find` commands for\ndirect invocation — see `commands\u002Fpk-dec.md` and\n`commands\u002Fpk-dec-find.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\u002Fv2\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.created`; later state changes use\n   `decision.transitioned`.\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 `\u002Fpk-dec` and `\u002Fpk-dec-find` commands for\ndirect invocation — see `commands\u002Fpk-dec.md` and\n`commands\u002Fpk-dec-find.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","processkit",[65,69],{"args":66,"name":67,"description":68},"decision-title","pk-dec","Record a new architectural or product decision with the given title",{"args":25,"name":70,"description":71},"pk-dec-find","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\u002Fv2","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","7231f100e266e30d2c1699ecde5c00602471dc3c","src\u002Fcontext\u002Fskills\u002Fprocesskit\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\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fdecision-record\u002FSKILL.md",true,[105,111,117,121,125,129,135],{"path":106,"resourceType":107,"resourceTypeDesc":108,"sizeBytes":109,"sourceHtmlUrl":110},"assets\u002Fdecisionrecord.yaml","ASSET","资产文件",341,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fdecision-record\u002Fassets\u002Fdecisionrecord.yaml",{"path":112,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":115,"sourceHtmlUrl":116},"commands\u002Fpk-dec-find.md","REFERENCE","参考文档",130,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fdecision-record\u002Fcommands\u002Fpk-dec-find.md",{"path":118,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":119,"sourceHtmlUrl":120},"commands\u002Fpk-dec.md",133,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fdecision-record\u002Fcommands\u002Fpk-dec.md",{"path":122,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":123,"sourceHtmlUrl":124},"mcp\u002Fmcp-config.json",213,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fdecision-record\u002Fmcp\u002Fmcp-config.json",{"path":126,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":127,"sourceHtmlUrl":128},"mcp\u002FSERVER.md",2757,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fdecision-record\u002Fmcp\u002FSERVER.md",{"path":130,"resourceType":131,"resourceTypeDesc":132,"sizeBytes":133,"sourceHtmlUrl":134},"mcp\u002Fserver.py","SCRIPT","脚本",11663,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fdecision-record\u002Fmcp\u002Fserver.py",{"path":136,"resourceType":131,"resourceTypeDesc":132,"sizeBytes":14,"sourceHtmlUrl":137},"scripts\u002F.gitkeep","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fdecision-record\u002Fscripts\u002F.gitkeep",[139,166,186,204,221,239],{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":150,"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",[145],{"categoryNo":146,"categoryName":147,"taxonomyType":148,"taxonomyTypeDesc":149},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[151,152,153,154,155,156,32,157,158,159,141,160,161,162,163,164,165],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"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":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",[172],{"categoryNo":146,"categoryName":147,"taxonomyType":148,"taxonomyTypeDesc":149},[151,174,175,176,177,178,156,32,179,180,158,181,182,183,160,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":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",[],[151,193,194,153,154,195,156,32,22,196,21,29,160,197,198,199,200,201,202,203],"proposition","proposition management","index","world","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":210,"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",[],[151,159,211,153,156,212,213,179,214,22,158,215,216,160,217,218,198,219,163,220],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":222,"name":223,"nameZh":6,"description":224,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":225,"categories":226,"keywords":227,"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",[],[228,229,230,231,156,232,233,234,32,235,236,237,238],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":240,"name":241,"nameZh":6,"description":242,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":243,"categories":244,"keywords":245,"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",[],[151,246,247,153,154,195,156,212,32,157,22,248,158,21,160,218,198,199,249,165],"capability","capability management","queries","changes"]