[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X010D1WTMCQS2AKFDCD2QS":3,"skill-same:01M6X010D1WTMCQS2AKFDCD2QS":93},{"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},"01M6X010D1WTMCQS2AKFDCD2QS","release-semver",null,"Semantic versioning releases — version bumps, changelogs, tags, publishing. Use when preparing a new release: deciding the version bump, drafting the changelog, tagging the commit, and publishing to the project's distribution channel.","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\u002Fdevops\u002Frelease-semver\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"release","semver","release semver","bump","when","phase","v1","tags","type","distribution","project","draft","commit","patch","publishing","auto","version","use","publish","create","2026-11-10 10:12:30",false,"---\nname: release-semver\ndescription: |\n  Semantic versioning releases — version bumps, changelogs, tags, publishing. Use when preparing a new release: deciding the version bump, drafting the changelog, tagging the commit, and publishing to the project's distribution channel.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-release-semver\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: devops\n    layer: 3\n    commands:\n      - name: release-semver-prepare\n        args: \"bump-type\"\n        description: \"Prepare a release: bump version, draft changelog, create tag (bump-type: major, minor, patch, or auto)\"\n      - name: release-semver-publish\n        args: \"\"\n        description: \"Execute the publish phase of the prepared release\"\n---\n\n# Semantic Versioning Release Process\n\n## Intro\n\nReleases are routine, not heroic. Decide the version bump from the\nnature of the changes, draft a changelog, update version files in\none commit, tag with `vX.Y.Z`, and publish. The goal is a release\nanyone on the team can perform from the same checklist.\n\n## Overview\n\n### Determine the version bump\n\nSemantic versioning has three numbers: MAJOR.MINOR.PATCH.\n\n- **Patch** (0.1.0 → 0.1.1): bug fixes only, no API changes.\n- **Minor** (0.1.0 → 0.2.0): new features, backward-compatible.\n- **Major** (0.1.0 → 1.0.0): breaking changes.\n\nPre-1.0 projects bend the rules: minor bumps are allowed to break\ncompatibility, and patch bumps cover both features and fixes. Once\nyou ship 1.0, the rules become strict.\n\n### Pre-release checklist\n\n- All tests pass on the main branch.\n- No uncommitted changes in the working tree.\n- Dependencies reviewed and up to date where appropriate.\n- CHANGELOG or release notes drafted.\n\n### Draft the changelog\n\nGroup entries under **Added**, **Changed**, **Fixed**, and\n**Removed**. Reference issue and PR numbers. Note breaking changes\nprominently — call them out in their own section if a major bump\nis involved.\n\n### Bump, commit, tag, publish\n\nUpdate the version in every relevant file (`Cargo.toml`,\n`pyproject.toml`, `package.json`, lockfiles). Commit with a message\nlike `chore: bump version to vX.Y.Z`. Tag the commit `vX.Y.Z`.\nPublish according to the project's distribution channel\n(crates.io, PyPI, npm, GitHub Releases, container registry, etc.).\n\n### Example\n\nUser says: \"Let's release — we fixed two bugs and added a feature.\"\nThe agent recommends a minor bump (because of the new feature),\ndrafts changelog entries grouped Added\u002FFixed, updates version\nfiles, creates the bump commit, and tags it.\n\nThis skill also provides the `\u002Frelease-semver-prepare` slash command for direct invocation — see `commands\u002Frelease-semver-prepare.md`. This skill also provides the `\u002Frelease-semver-publish` slash command for direct invocation — see `commands\u002Frelease-semver-publish.md`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Bundling a breaking change into a patch or minor release.** Consumers rely on semver guarantees to control when they take breaking changes. A breaking change in a patch release violates the contract and causes silent runtime failures in consumer code.\n- **Skipping the changelog because \"git log has it\".** Git log is not a changelog. It lacks context, grouping, and the human judgment that makes a changelog useful. Every release needs a curated changelog with Added\u002FChanged\u002FFixed\u002FRemoved sections.\n- **Bumping all version files in separate commits.** A brief window where `Cargo.toml` says `1.2.0` but `pyproject.toml` still says `1.1.0` is a broken state. Update all version files in a single atomic commit.\n- **Tagging before CI passes.** A tag should point to a commit that has been fully built and tested. Tagging a commit that later fails CI means the published artifact may not match what was verified.\n- **Publishing from a developer machine without a clean checkout.** Uncommitted local changes — WIP files, debug flags, `console.log` statements — may sneak into the artifact. Publish from CI with a clean checkout or from a fresh clone.\n- **Re-tagging a published version to fix a mistake.** Package registries (crates.io, PyPI, npm) prohibit or block re-publishing to an existing version. Cut a new patch version (e.g. `1.2.1`) to fix a mistake in `1.2.0`; never overwrite a tag.\n- **Pre-1.0 projects that promise stability they cannot keep.** If the API is still moving, stay below 1.0 and say so. Cutting `1.0.0` too early creates a compatibility obligation that slows future improvements.\n\n## Full reference\n\n### When pre-1.0 ends\n\nCut 1.0 when the public API is something you are willing to\nsupport without breaking. Until then, keep the version below 1.0\nhonestly — there is no shame in 0.17.0, and it signals to users\nthat the surface may still move.\n\n### Version bumps for special changes\n\n| Change | Bump |\n|---|---|\n| Bug fix that does not change behavior contract | patch |\n| Performance improvement, no API change | patch |\n| New feature behind a feature flag | minor |\n| New optional parameter with a default | minor |\n| Removing or renaming a public symbol | major |\n| Changing default behavior of an existing API | major |\n| Tightening input validation that rejects previously valid input | major |\n| Dependency bump that surfaces in your public API | major |\n\n### Anti-patterns\n\n- Bundling breaking changes into a patch release\n- Skipping the changelog \"because git log has it\"\n- Tagging a commit that was not built and tested\n- Publishing from a developer machine without a clean checkout\n- Re-tagging a published version to fix a mistake (cut a new\n  patch instead)\n- Pre-1.0 projects that promise stability they cannot keep\n","# Semantic Versioning Release Process\n\n## Intro\n\nReleases are routine, not heroic. Decide the version bump from the\nnature of the changes, draft a changelog, update version files in\none commit, tag with `vX.Y.Z`, and publish. The goal is a release\nanyone on the team can perform from the same checklist.\n\n## Overview\n\n### Determine the version bump\n\nSemantic versioning has three numbers: MAJOR.MINOR.PATCH.\n\n- **Patch** (0.1.0 → 0.1.1): bug fixes only, no API changes.\n- **Minor** (0.1.0 → 0.2.0): new features, backward-compatible.\n- **Major** (0.1.0 → 1.0.0): breaking changes.\n\nPre-1.0 projects bend the rules: minor bumps are allowed to break\ncompatibility, and patch bumps cover both features and fixes. Once\nyou ship 1.0, the rules become strict.\n\n### Pre-release checklist\n\n- All tests pass on the main branch.\n- No uncommitted changes in the working tree.\n- Dependencies reviewed and up to date where appropriate.\n- CHANGELOG or release notes drafted.\n\n### Draft the changelog\n\nGroup entries under **Added**, **Changed**, **Fixed**, and\n**Removed**. Reference issue and PR numbers. Note breaking changes\nprominently — call them out in their own section if a major bump\nis involved.\n\n### Bump, commit, tag, publish\n\nUpdate the version in every relevant file (`Cargo.toml`,\n`pyproject.toml`, `package.json`, lockfiles). Commit with a message\nlike `chore: bump version to vX.Y.Z`. Tag the commit `vX.Y.Z`.\nPublish according to the project's distribution channel\n(crates.io, PyPI, npm, GitHub Releases, container registry, etc.).\n\n### Example\n\nUser says: \"Let's release — we fixed two bugs and added a feature.\"\nThe agent recommends a minor bump (because of the new feature),\ndrafts changelog entries grouped Added\u002FFixed, updates version\nfiles, creates the bump commit, and tags it.\n\nThis skill also provides the `\u002Frelease-semver-prepare` slash command for direct invocation — see `commands\u002Frelease-semver-prepare.md`. This skill also provides the `\u002Frelease-semver-publish` slash command for direct invocation — see `commands\u002Frelease-semver-publish.md`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Bundling a breaking change into a patch or minor release.** Consumers rely on semver guarantees to control when they take breaking changes. A breaking change in a patch release violates the contract and causes silent runtime failures in consumer code.\n- **Skipping the changelog because \"git log has it\".** Git log is not a changelog. It lacks context, grouping, and the human judgment that makes a changelog useful. Every release needs a curated changelog with Added\u002FChanged\u002FFixed\u002FRemoved sections.\n- **Bumping all version files in separate commits.** A brief window where `Cargo.toml` says `1.2.0` but `pyproject.toml` still says `1.1.0` is a broken state. Update all version files in a single atomic commit.\n- **Tagging before CI passes.** A tag should point to a commit that has been fully built and tested. Tagging a commit that later fails CI means the published artifact may not match what was verified.\n- **Publishing from a developer machine without a clean checkout.** Uncommitted local changes — WIP files, debug flags, `console.log` statements — may sneak into the artifact. Publish from CI with a clean checkout or from a fresh clone.\n- **Re-tagging a published version to fix a mistake.** Package registries (crates.io, PyPI, npm) prohibit or block re-publishing to an existing version. Cut a new patch version (e.g. `1.2.1`) to fix a mistake in `1.2.0`; never overwrite a tag.\n- **Pre-1.0 projects that promise stability they cannot keep.** If the API is still moving, stay below 1.0 and say so. Cutting `1.0.0` too early creates a compatibility obligation that slows future improvements.\n\n## Full reference\n\n### When pre-1.0 ends\n\nCut 1.0 when the public API is something you are willing to\nsupport without breaking. Until then, keep the version below 1.0\nhonestly — there is no shame in 0.17.0, and it signals to users\nthat the surface may still move.\n\n### Version bumps for special changes\n\n| Change | Bump |\n|---|---|\n| Bug fix that does not change behavior contract | patch |\n| Performance improvement, no API change | patch |\n| New feature behind a feature flag | minor |\n| New optional parameter with a default | minor |\n| Removing or renaming a public symbol | major |\n| Changing default behavior of an existing API | major |\n| Tightening input validation that rejects previously valid input | major |\n| Dependency bump that surfaces in your public API | major |\n\n### Anti-patterns\n\n- Bundling breaking changes into a patch release\n- Skipping the changelog \"because git log has it\"\n- Tagging a commit that was not built and tested\n- Publishing from a developer machine without a clean checkout\n- Re-tagging a published version to fix a mistake (cut a new\n  patch instead)\n- Pre-1.0 projects that promise stability they cannot keep\n",{"name":5,"metadata":44,"description":61},{"processkit":45},{"id":46,"layer":47,"created":48,"version":49,"category":50,"commands":51,"apiVersion":60},"SKILL-release-semver",3,1775433600000,"1.1.0","devops",[52,56],{"args":53,"name":54,"description":55},"bump-type","release-semver-prepare","Prepare a release: bump version, draft changelog, create tag (bump-type: major, minor, patch, or auto)",{"args":57,"name":58,"description":59},"","release-semver-publish","Execute the publish phase of the prepared release","processkit.projectious.work\u002Fv1","Semantic versioning releases — version bumps, changelogs, tags, publishing. Use when preparing a new release: deciding the version bump, drafting the changelog, tagging the commit, and publishing to the project's distribution channel.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fdevops\u002Frelease-semver","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":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add projectious-work\u002Fprocesskit --skill release-semver",{"tool":75,"command":76},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill release-semver",{"tool":78,"command":79},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill release-semver","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fdevops\u002Frelease-semver\u002FSKILL.md",true,[83,89],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"commands\u002Fpk-publish.md","REFERENCE","参考文档",128,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fdevops\u002Frelease-semver\u002Fcommands\u002Fpk-publish.md",{"path":90,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":91,"sourceHtmlUrl":92},"commands\u002Fpk-release.md",200,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fdevops\u002Frelease-semver\u002Fcommands\u002Fpk-release.md",[94,120,140,161,178,196],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":105,"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",[100],{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[106,107,38,108,109,110,111,112,113,114,96,115,116,117,25,118,119],"management","skill management","update","package","alpha","work","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":127,"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",[126],{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},[106,128,129,130,131,132,110,111,133,134,113,135,136,137,115,138,139],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"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",[],[106,147,148,38,108,149,110,111,150,151,152,153,115,154,155,156,157,158,159,160],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"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",[],[106,114,168,38,110,169,170,133,171,150,113,172,173,115,174,175,155,176,25,177],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"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",[],[185,186,187,188,110,189,190,191,111,192,193,194,195],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":202,"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",[],[106,203,204,38,108,149,110,169,111,112,150,205,113,152,115,175,155,156,206,119],"capability","capability management","queries","changes"]