[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X3N5BMNAF74ZSWJSJBPYHZ":3,"skill-same:01M6X3N5BMNAF74ZSWJSJBPYHZ":76},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":14,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M6X3N5BMNAF74ZSWJSJBPYHZ","changelog",null,"Generates and maintains CHANGELOG.md files following Keep a Changelog conventions — from git history, commit messages, or a description of changes. Use when asked to write a changelog, update release notes, or document what changed in a version.","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\u002Fchangelog\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"use","when","changes","for","v1","number","keep","document","files","version","commit","process","work","history","correct","messages","update","release notes","notes","2026-11-10 10:12:30",false,"---\nname: changelog\ndescription: |\n  Generates and maintains CHANGELOG.md files following Keep a Changelog conventions — from git history, commit messages, or a description of changes. Use when asked to write a changelog, update release notes, or document what changed in a version.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-changelog\n    version: \"1.0.0\"\n    created: 2026-04-08T00:00:00Z\n    category: process\n    layer: 2\n    uses:\n      - skill: release-semver\n        purpose: Determine the correct version number for a release entry.\n---\n\n# Changelog\n\n## Intro\n\nFollow the [Keep a Changelog](https:\u002F\u002Fkeepachangelog.com) convention:\none `CHANGELOG.md` at the repo root, entries in reverse chronological\norder (newest first), each release tagged with a semantic version and\ndate, changes grouped under seven standard categories. Write for\nhumans, not machines — the reader is a developer evaluating whether\nto upgrade.\n\n## Overview\n\n### File structure\n\n```markdown\n# Changelog\n\nAll notable changes to this project will be documented in this file.\n\nThe format is based on [Keep a Changelog](https:\u002F\u002Fkeepachangelog.com\u002Fen\u002F1.1.0\u002F),\nand this project adheres to [Semantic Versioning](https:\u002F\u002Fsemver.org\u002Fspec\u002Fv2.0.0.html).\n\n## [Unreleased]\n\n## [1.2.0] — 2026-04-08\n\n### Added\n- ...\n\n### Changed\n- ...\n\n### Deprecated\n- ...\n\n### Removed\n- ...\n\n### Fixed\n- ...\n\n### Security\n- ...\n\n[Unreleased]: https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fcompare\u002Fv1.2.0...HEAD\n[1.2.0]: https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fcompare\u002Fv1.1.0...v1.2.0\n[1.1.0]: https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Freleases\u002Ftag\u002Fv1.1.0\n```\n\nThe `[Unreleased]` section accumulates changes since the last\nrelease. On release, it becomes the new version block.\n\n### The seven change categories\n\nUse exactly these headings — no others:\n\n| Category | What goes here |\n|---|---|\n| **Added** | New features, new endpoints, new configuration options |\n| **Changed** | Changes to existing behavior, updated defaults, refactors that change observable behavior |\n| **Deprecated** | Features that will be removed in a future version |\n| **Removed** | Features removed in this version |\n| **Fixed** | Bug fixes |\n| **Security** | Vulnerability fixes — always include CVE IDs where available |\n\nOmit sections that have no entries for a release. Do not use custom\ncategories (e.g. \"Performance\", \"Refactor\") — map to the nearest\nstandard one.\n\n### Extracting changes from git\n\nUse the git log to find changes since the last release:\n\n```bash\n# Changes since the last tag\ngit log v1.1.0..HEAD --oneline\n\n# Changes between two tags\ngit log v1.1.0..v1.2.0 --oneline\n\n# With full messages for detail\ngit log v1.1.0..HEAD --format=\"%h %s%n%b\" | head -100\n```\n\nThen group commits by type:\n- `feat:` or `add` → **Added**\n- `fix:` → **Fixed**\n- `chore:`, `refactor:`, `perf:` → **Changed** (if user-visible)\n- `BREAKING CHANGE:` → **Removed** or **Changed** (prominently)\n- `security:` or CVE mentions → **Security**\n\nDiscard: merge commits, version bumps, CI config changes, typo\nfixes in comments, and any change the end user will never notice.\n\n### Writing good changelog entries\n\nEach entry is a single sentence describing the user-visible change.\nFormat: verb phrase in past tense, describing the observable\nbehavior change, not the implementation detail.\n\n**Good:**\n- Added `--dry-run` flag to the `sync` command that previews changes without applying them\n- Fixed a race condition in the connection pool that caused intermittent 500 errors under high load\n- Removed support for Python 3.8, which reached end-of-life in October 2024\n\n**Bad:**\n- Refactored the database layer (not user-visible)\n- Updated dependencies (too vague — say which and why if it matters)\n- Fixed bug (say what bug, what symptom)\n\nLink to the relevant issue or PR for every entry where one exists:\n`Added dark mode support ([#142](https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fissues\u002F142))`\n\n### Releasing: promote [Unreleased] to a version\n\nWhen releasing version `1.2.0`:\n\n1. Replace `## [Unreleased]` with `## [1.2.0] — YYYY-MM-DD`\n2. Add a new empty `## [Unreleased]` section at the top\n3. Add the version link at the bottom:\n   `[1.2.0]: https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fcompare\u002Fv1.1.0...v1.2.0`\n4. Update the `[Unreleased]` link:\n   `[Unreleased]: https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fcompare\u002Fv1.2.0...HEAD`\n\n### Breaking changes\n\nBreaking changes deserve special treatment:\n\n1. Place them first in the **Changed** or **Removed** section\n2. Add a `> **Breaking change:**` blockquote before the entry\n3. Include migration steps or a link to the migration guide\n\n```markdown\n### Changed\n\n> **Breaking change:** The `auth` configuration key has been renamed\n> to `authentication`. Update your config files before upgrading.\n> See the [migration guide](docs\u002Fmigration\u002Fv2.md).\n\n- Renamed `config.auth` to `config.authentication` for clarity\n```\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Including implementation-only changes that users will never notice.** A changelog entry for \"refactored the database connection pool to use a factory pattern\" tells users nothing useful. Filter to changes with observable user-visible effects — if the user can't see it, benchmark it, or configure it, it doesn't belong in the changelog.\n- **Writing entries that describe what changed in the code instead of what changed for the user.** \"Updated the auth middleware to validate JWT expiry\" is an implementation detail; \"Fixed a bug where expired tokens were accepted without re-authentication\" is the user-facing fact. Write from the user's perspective, not the developer's.\n- **Using custom category names instead of the seven Keep a Changelog standard ones.** Adding \"Performance\", \"Internal\", or \"Refactoring\" sections breaks compatibility with tools that parse CHANGELOG.md (release generators, changelog aggregators) and confuses readers who expect the standard headings. Map every change to the nearest standard category.\n- **Forgetting to update the comparison links at the bottom.** CHANGELOG.md links at the bottom reference Git tags. After every release, two links change: the `[Unreleased]` link and the new version link. Leaving them pointing to old tags makes the diff links wrong for everyone who clicks them.\n- **Putting the [Unreleased] section below past releases instead of at the top.** The `[Unreleased]` section must always be the first entry, immediately after the file header. Entries below it are older releases in reverse chronological order. An [Unreleased] section buried below past versions is invisible to maintainers accumulating pre-release notes.\n- **Including every commit message verbatim.** Raw commit messages (\"wip\", \"fix test\", \"revert previous\", \"merge branch main\") are noise in a changelog. Synthesize: group related commits into one user-visible entry, discard implementation churn, and rewrite technical commit shorthand into plain language.\n- **Not marking breaking changes prominently.** A breaking change buried as the fifth bullet in \"Changed\" will be missed by users scanning the changelog before upgrading. Breaking changes must be clearly marked — use a blockquote, bold text, or a dedicated sub-heading — so they are impossible to miss.\n\n## Full reference\n\n### Conventional Commits mapping\n\nIf the project uses [Conventional Commits](https:\u002F\u002Fconventionalcommits.org):\n\n| Commit prefix | Changelog category |\n|---|---|\n| `feat:` | Added |\n| `fix:` | Fixed |\n| `perf:` | Changed |\n| `refactor:` (visible) | Changed |\n| `docs:` (user-facing) | Changed |\n| `BREAKING CHANGE:` footer | Changed or Removed (prominent) |\n| `security:` | Security |\n| `chore:`, `test:`, `ci:` | Omit |\n| `deprecate:` | Deprecated |\n\n### Automating changelog generation\n\nTools that parse Conventional Commits and generate a draft changelog:\n- `git-cliff` — highly configurable, supports custom templates\n- `conventional-changelog-cli` — Node.js, many preset styles\n- `release-please` (Google) — GitHub Actions workflow\n\nThese produce a draft; always human-review before publishing.\nThe agent's job when automation is available: **review and edit**\nthe generated draft, not generate from scratch.\n\n### GitHub release notes vs. CHANGELOG.md\n\nGitHub's \"Generate release notes\" button is not a substitute for\nCHANGELOG.md:\n- GitHub release notes are per-release and not accumulated\n- They are structured around PR titles, not user-visible changes\n- They are only accessible via GitHub, not in the repository\n\nCHANGELOG.md is the authoritative, cumulative, human-readable record.\nGitHub release notes can be generated from it, not the other way\naround.\n\n### Old changelog entries — when to leave them alone\n\nNever rewrite or delete old changelog entries, even when they are\nwrong about what a version contained. Old entries are part of the\nproject's permanent history. If a past entry was incorrect, add a\nnote in a later version's section that corrects the record.\n","# Changelog\n\n## Intro\n\nFollow the [Keep a Changelog](https:\u002F\u002Fkeepachangelog.com) convention:\none `CHANGELOG.md` at the repo root, entries in reverse chronological\norder (newest first), each release tagged with a semantic version and\ndate, changes grouped under seven standard categories. Write for\nhumans, not machines — the reader is a developer evaluating whether\nto upgrade.\n\n## Overview\n\n### File structure\n\n```markdown\n# Changelog\n\nAll notable changes to this project will be documented in this file.\n\nThe format is based on [Keep a Changelog](https:\u002F\u002Fkeepachangelog.com\u002Fen\u002F1.1.0\u002F),\nand this project adheres to [Semantic Versioning](https:\u002F\u002Fsemver.org\u002Fspec\u002Fv2.0.0.html).\n\n## [Unreleased]\n\n## [1.2.0] — 2026-04-08\n\n### Added\n- ...\n\n### Changed\n- ...\n\n### Deprecated\n- ...\n\n### Removed\n- ...\n\n### Fixed\n- ...\n\n### Security\n- ...\n\n[Unreleased]: https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fcompare\u002Fv1.2.0...HEAD\n[1.2.0]: https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fcompare\u002Fv1.1.0...v1.2.0\n[1.1.0]: https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Freleases\u002Ftag\u002Fv1.1.0\n```\n\nThe `[Unreleased]` section accumulates changes since the last\nrelease. On release, it becomes the new version block.\n\n### The seven change categories\n\nUse exactly these headings — no others:\n\n| Category | What goes here |\n|---|---|\n| **Added** | New features, new endpoints, new configuration options |\n| **Changed** | Changes to existing behavior, updated defaults, refactors that change observable behavior |\n| **Deprecated** | Features that will be removed in a future version |\n| **Removed** | Features removed in this version |\n| **Fixed** | Bug fixes |\n| **Security** | Vulnerability fixes — always include CVE IDs where available |\n\nOmit sections that have no entries for a release. Do not use custom\ncategories (e.g. \"Performance\", \"Refactor\") — map to the nearest\nstandard one.\n\n### Extracting changes from git\n\nUse the git log to find changes since the last release:\n\n```bash\n# Changes since the last tag\ngit log v1.1.0..HEAD --oneline\n\n# Changes between two tags\ngit log v1.1.0..v1.2.0 --oneline\n\n# With full messages for detail\ngit log v1.1.0..HEAD --format=\"%h %s%n%b\" | head -100\n```\n\nThen group commits by type:\n- `feat:` or `add` → **Added**\n- `fix:` → **Fixed**\n- `chore:`, `refactor:`, `perf:` → **Changed** (if user-visible)\n- `BREAKING CHANGE:` → **Removed** or **Changed** (prominently)\n- `security:` or CVE mentions → **Security**\n\nDiscard: merge commits, version bumps, CI config changes, typo\nfixes in comments, and any change the end user will never notice.\n\n### Writing good changelog entries\n\nEach entry is a single sentence describing the user-visible change.\nFormat: verb phrase in past tense, describing the observable\nbehavior change, not the implementation detail.\n\n**Good:**\n- Added `--dry-run` flag to the `sync` command that previews changes without applying them\n- Fixed a race condition in the connection pool that caused intermittent 500 errors under high load\n- Removed support for Python 3.8, which reached end-of-life in October 2024\n\n**Bad:**\n- Refactored the database layer (not user-visible)\n- Updated dependencies (too vague — say which and why if it matters)\n- Fixed bug (say what bug, what symptom)\n\nLink to the relevant issue or PR for every entry where one exists:\n`Added dark mode support ([#142](https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fissues\u002F142))`\n\n### Releasing: promote [Unreleased] to a version\n\nWhen releasing version `1.2.0`:\n\n1. Replace `## [Unreleased]` with `## [1.2.0] — YYYY-MM-DD`\n2. Add a new empty `## [Unreleased]` section at the top\n3. Add the version link at the bottom:\n   `[1.2.0]: https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fcompare\u002Fv1.1.0...v1.2.0`\n4. Update the `[Unreleased]` link:\n   `[Unreleased]: https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fcompare\u002Fv1.2.0...HEAD`\n\n### Breaking changes\n\nBreaking changes deserve special treatment:\n\n1. Place them first in the **Changed** or **Removed** section\n2. Add a `> **Breaking change:**` blockquote before the entry\n3. Include migration steps or a link to the migration guide\n\n```markdown\n### Changed\n\n> **Breaking change:** The `auth` configuration key has been renamed\n> to `authentication`. Update your config files before upgrading.\n> See the [migration guide](docs\u002Fmigration\u002Fv2.md).\n\n- Renamed `config.auth` to `config.authentication` for clarity\n```\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Including implementation-only changes that users will never notice.** A changelog entry for \"refactored the database connection pool to use a factory pattern\" tells users nothing useful. Filter to changes with observable user-visible effects — if the user can't see it, benchmark it, or configure it, it doesn't belong in the changelog.\n- **Writing entries that describe what changed in the code instead of what changed for the user.** \"Updated the auth middleware to validate JWT expiry\" is an implementation detail; \"Fixed a bug where expired tokens were accepted without re-authentication\" is the user-facing fact. Write from the user's perspective, not the developer's.\n- **Using custom category names instead of the seven Keep a Changelog standard ones.** Adding \"Performance\", \"Internal\", or \"Refactoring\" sections breaks compatibility with tools that parse CHANGELOG.md (release generators, changelog aggregators) and confuses readers who expect the standard headings. Map every change to the nearest standard category.\n- **Forgetting to update the comparison links at the bottom.** CHANGELOG.md links at the bottom reference Git tags. After every release, two links change: the `[Unreleased]` link and the new version link. Leaving them pointing to old tags makes the diff links wrong for everyone who clicks them.\n- **Putting the [Unreleased] section below past releases instead of at the top.** The `[Unreleased]` section must always be the first entry, immediately after the file header. Entries below it are older releases in reverse chronological order. An [Unreleased] section buried below past versions is invisible to maintainers accumulating pre-release notes.\n- **Including every commit message verbatim.** Raw commit messages (\"wip\", \"fix test\", \"revert previous\", \"merge branch main\") are noise in a changelog. Synthesize: group related commits into one user-visible entry, discard implementation churn, and rewrite technical commit shorthand into plain language.\n- **Not marking breaking changes prominently.** A breaking change buried as the fifth bullet in \"Changed\" will be missed by users scanning the changelog before upgrading. Breaking changes must be clearly marked — use a blockquote, bold text, or a dedicated sub-heading — so they are impossible to miss.\n\n## Full reference\n\n### Conventional Commits mapping\n\nIf the project uses [Conventional Commits](https:\u002F\u002Fconventionalcommits.org):\n\n| Commit prefix | Changelog category |\n|---|---|\n| `feat:` | Added |\n| `fix:` | Fixed |\n| `perf:` | Changed |\n| `refactor:` (visible) | Changed |\n| `docs:` (user-facing) | Changed |\n| `BREAKING CHANGE:` footer | Changed or Removed (prominent) |\n| `security:` | Security |\n| `chore:`, `test:`, `ci:` | Omit |\n| `deprecate:` | Deprecated |\n\n### Automating changelog generation\n\nTools that parse Conventional Commits and generate a draft changelog:\n- `git-cliff` — highly configurable, supports custom templates\n- `conventional-changelog-cli` — Node.js, many preset styles\n- `release-please` (Google) — GitHub Actions workflow\n\nThese produce a draft; always human-review before publishing.\nThe agent's job when automation is available: **review and edit**\nthe generated draft, not generate from scratch.\n\n### GitHub release notes vs. CHANGELOG.md\n\nGitHub's \"Generate release notes\" button is not a substitute for\nCHANGELOG.md:\n- GitHub release notes are per-release and not accumulated\n- They are structured around PR titles, not user-visible changes\n- They are only accessible via GitHub, not in the repository\n\nCHANGELOG.md is the authoritative, cumulative, human-readable record.\nGitHub release notes can be generated from it, not the other way\naround.\n\n### Old changelog entries — when to leave them alone\n\nNever rewrite or delete old changelog entries, even when they are\nwrong about what a version contained. Old entries are part of the\nproject's permanent history. If a past entry was incorrect, add a\nnote in a later version's section that corrects the record.\n",{"name":5,"metadata":43,"description":54},{"processkit":44},{"id":45,"uses":46,"layer":50,"created":51,"version":52,"category":30,"apiVersion":53},"SKILL-changelog",[47],{"skill":48,"purpose":49},"release-semver","Determine the correct version number for a release entry.",2,1775606400000,"1.0.0","processkit.projectious.work\u002Fv1","Generates and maintains CHANGELOG.md files following Keep a Changelog conventions — from git history, commit messages, or a description of changes. Use when asked to write a changelog, update release notes, or document what changed in a version.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fchangelog","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":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add projectious-work\u002Fprocesskit --skill changelog",{"tool":68,"command":69},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill changelog",{"tool":71,"command":72},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill changelog","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fchangelog\u002FSKILL.md",true,[],[77,102,122,143,159,177],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":88,"publishedAt":38},"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",[83],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[89,90,91,35,92,93,31,94,95,96,79,97,98,99,23,100,101],"management","skill management","create","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":38},"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",[108],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},[89,110,111,112,113,114,93,31,115,116,95,117,118,119,97,120,121],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":38},"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",[],[89,129,130,91,35,131,93,31,132,133,134,135,97,136,137,138,139,140,141,142],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":38},"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",[],[89,96,150,91,93,151,152,115,153,132,95,154,155,97,156,25,137,157,23,158],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","measurement","generic",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":38},"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",[],[166,167,168,169,93,170,171,172,31,173,174,175,176],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":38},"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",[],[89,184,185,91,35,131,93,151,31,94,132,186,95,134,97,25,137,138,21,101],"capability","capability management","queries"]