[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WZEGTK7BWH7F736V02NHQC":3,"skill-same:01M6WZEGTK7BWH7F736V02NHQC":72},{"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":51,"commitSha":52,"skillDirectory":53,"forksCount":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6WZEGTK7BWH7F736V02NHQC","dependency-management",null,"Cross-language dependency management — lockfiles, version pinning, automated updates, security, and licenses. Use when setting up or reviewing lockfile strategy, configuring automated dependency updates, auditing dependencies for security or license issues, handling monorepo dependencies, or deciding whether to vendor.","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.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fdependency-management\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"dependency","management","dependency management","vendor","when","for","v1","updates","dependencies","up","version","use","security","strategy","work","monorepo","lockfile","engineering","license","issues","2026-11-10 10:12:30",false,"---\nname: dependency-management\ndescription: |\n  Cross-language dependency management — lockfiles, version pinning, automated updates, security, and licenses. Use when setting up or reviewing lockfile strategy, configuring automated dependency updates, auditing dependencies for security or license issues, handling monorepo dependencies, or deciding whether to vendor.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-dependency-management\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# Dependency Management\n\n## Intro\n\nDependencies are the largest unmaintained surface in most projects.\nPin them, lock them, scan them, and update them on a schedule. The\ndefaults differ by language, but the principles are universal: commit\nthe lockfile, automate the updates, gate on CI, and review every\nchange.\n\n## Overview\n\n### Lockfiles\n\nLockfiles pin the exact resolved versions of all direct and\ntransitive dependencies. Always commit lockfiles for applications and\nservices. For libraries, commit the lockfile for CI reproducibility\nbut do not publish it. Never edit lockfiles by hand — regenerate them\nthrough the package manager.\n\n| Ecosystem | Manifest | Lockfile |\n|-----------|----------|----------|\n| Rust | `Cargo.toml` | `Cargo.lock` |\n| Python (uv\u002Fpip) | `pyproject.toml` | `uv.lock` \u002F `requirements.txt` |\n| Node.js (npm) | `package.json` | `package-lock.json` |\n| Node.js (pnpm) | `package.json` | `pnpm-lock.yaml` |\n| Go | `go.mod` | `go.sum` |\n\n### Version pinning\n\n- **Exact pins** (`==1.2.3`): maximum reproducibility. Use for\n  applications and Docker images.\n- **Compatible range** (`^1.2.3` or `~=1.2`): allow patch\u002Fminor\n  updates. Use for libraries to avoid conflicts with consumers.\n- **Minimum bound** (`>=1.2.0`): widest compatibility, but can lead\n  to untested combinations. Use sparingly.\n\nRule of thumb: pin tightly in applications, pin loosely in libraries.\n\n### Automated updates\n\n**Dependabot** is GitHub-native. Configure\n`.github\u002Fdependabot.yml` with ecosystems, schedule, and reviewers.\nSet `open-pull-requests-limit` (5–10) to avoid PR floods. Group\nminor\u002Fpatch updates to reduce noise.\n\n**Renovate** is more flexible: monorepos, package-pattern grouping,\nauto-merge for patch updates. Use `extends: [\"config:recommended\"]`\nin `renovate.json` as a baseline. Use `matchPackagePatterns` to\ngroup related packages (e.g. all `@aws-sdk\u002F*`).\n\nFor both: require CI to pass before merging. Auto-merge patch\nupdates for well-tested projects. Review major updates manually and\nread the changelog.\n\n### Monorepos\n\nUse the workspace features your toolchain provides — Cargo\nworkspaces, npm\u002Fpnpm workspaces, uv workspaces. Share common\ndependency versions at the workspace root. Pin shared tooling\n(linters, formatters) at the root. Let individual packages declare\ntheir own domain-specific deps. Update everything together with\n`cargo update --workspace` or the equivalent.\n\n### Security and licenses\n\nIntegrate vulnerability scanning into CI. Block merges on\ncritical\u002Fhigh vulnerabilities and track accepted risks with ignore\nrules and expiry dates. For licenses, maintain an SPDX-based\nallow-list and flag copyleft licenses (GPL, AGPL) in proprietary\nprojects for legal review.\n\n| Tool | Ecosystem |\n|---|---|\n| `cargo audit` \u002F `cargo-deny` | Rust |\n| `npm audit` \u002F `pnpm audit` | Node.js |\n| `pip-audit` \u002F `uv pip audit` | Python |\n| `govulncheck` | Go |\n| `license-checker` | Node.js |\n| `pip-licenses` | Python |\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Hand-editing lockfiles.** Lockfiles are generated artifacts — their format is designed for machines and manual edits are easily invalid. Regenerate them with the package manager; never edit by hand.\n- **Omitting lockfiles from version control for applications.** Without a committed lockfile, different developers (and CI) resolve different transitive versions. Commit lockfiles for all applications and services; the \"don't commit lockfile\" rule applies only to libraries.\n- **Auto-merging major version bumps.** Major bumps can contain breaking API changes. Auto-merge is appropriate for patches, not majors. Major updates require changelog review before merging.\n- **Ignoring Dependabot or Renovate PRs until they pile up.** A backlog of 40 dependency PRs becomes unreviewable. Each one also causes merge conflicts with the others. Review and merge promptly; set a weekly cadence.\n- **Pinning loosely in applications \"to stay current\".** Applications should use exact pins and a managed update workflow. Loose ranges in applications lead to unreproducible builds and silent version drift between environments.\n- **Adding a 200-package dependency for a 5-line utility.** Every dependency is a maintenance, security, and license liability. Audit the size and scope of the dependency before adding it; prefer stdlib or a smaller alternative.\n- **No SLA on security advisories.** \"We'll get to it\" means critical vulnerabilities sit in the codebase for months. Define explicit SLAs: critical\u002Fhigh → fix within 48 hours; medium → within the current sprint.\n\n## Full reference\n\n### Dependency review checklist\n\nFor every PR that changes dependencies:\n\n1. **What changed** — new dependency, version bump, removal?\n2. **Why** — feature, security fix, deprecation?\n3. **License** — does it fit the project's allow-list?\n4. **Size and scope** — proportional to the problem it solves?\n5. **Alternatives** — is there a lighter or stdlib-based option?\n6. **Security** — does the new version have known advisories?\n\n### Vendoring\n\nCopy dependencies into the repository for offline builds or\nsupply-chain control:\n\n- Rust: `cargo vendor` plus `.cargo\u002Fconfig.toml` with\n  `[source.vendored-sources]`\n- Go: `go mod vendor` plus `-mod=vendor` at build time\n- Node.js: rarely vendored; use `npm pack` plus a local tarball if\n  needed\n\nVendor when building in air-gapped environments, pinning against\nregistry outages, or needing a full audit of dependency source.\n\n### Dependabot example\n\n```yaml\n# .github\u002Fdependabot.yml\nversion: 2\nupdates:\n  - package-ecosystem: cargo\n    directory: \u002F\n    schedule:\n      interval: weekly\n      day: monday\n    open-pull-requests-limit: 10\n    reviewers:\n      - \"team-backend\"\n    groups:\n      minor-and-patch:\n        update-types: [\"minor\", \"patch\"]\n\n  - package-ecosystem: npm\n    directory: \u002Ffrontend\n    schedule:\n      interval: weekly\n    groups:\n      react:\n        patterns: [\"react*\", \"@types\u002Freact*\"]\n```\n\n### cargo-deny example\n\n```toml\n# deny.toml\n[advisories]\nvulnerability = \"deny\"\nunmaintained = \"warn\"\nyanked = \"deny\"\n\n[licenses]\nallow = [\"MIT\", \"Apache-2.0\", \"BSD-2-Clause\", \"BSD-3-Clause\", \"ISC\", \"Unicode-3.0\"]\ncopyleft = \"deny\"\n\n[[licenses.exceptions]]\nallow = [\"MPL-2.0\"]\ncrates = [\"webpki-roots\"]\n\n[bans]\nmultiple-versions = \"warn\"\ndeny = [\n    { crate = \"openssl\", use-instead = \"rustls\" },\n]\n```\n\n### Renovate auto-merge example\n\n```json\n{\n  \"$schema\": \"https:\u002F\u002Fdocs.renovatebot.com\u002Frenovate-schema.json\",\n  \"extends\": [\"config:recommended\"],\n  \"packageRules\": [\n    {\n      \"matchUpdateTypes\": [\"patch\"],\n      \"automerge\": true,\n      \"automergeType\": \"pr\",\n      \"requiredStatusChecks\": [\"ci\"]\n    },\n    {\n      \"matchPackagePatterns\": [\"^@aws-sdk\u002F\"],\n      \"groupName\": \"AWS SDK\",\n      \"schedule\": [\"before 8am on monday\"]\n    },\n    {\n      \"matchUpdateTypes\": [\"major\"],\n      \"labels\": [\"breaking-change\"],\n      \"automerge\": false\n    }\n  ]\n}\n```\n\n### Anti-patterns\n\n- Hand-editing lockfiles instead of regenerating them\n- Ignoring Dependabot PRs until they pile up into an unreviewable\n  backlog\n- Auto-merging major updates without reading the changelog\n- Pinning loosely in applications \"to stay current\" — that is what\n  the update workflow is for\n- Adding a 200-package dependency for a five-line utility\n- Treating a security advisory as \"we'll get to it\" — set an SLA\n","# Dependency Management\n\n## Intro\n\nDependencies are the largest unmaintained surface in most projects.\nPin them, lock them, scan them, and update them on a schedule. The\ndefaults differ by language, but the principles are universal: commit\nthe lockfile, automate the updates, gate on CI, and review every\nchange.\n\n## Overview\n\n### Lockfiles\n\nLockfiles pin the exact resolved versions of all direct and\ntransitive dependencies. Always commit lockfiles for applications and\nservices. For libraries, commit the lockfile for CI reproducibility\nbut do not publish it. Never edit lockfiles by hand — regenerate them\nthrough the package manager.\n\n| Ecosystem | Manifest | Lockfile |\n|-----------|----------|----------|\n| Rust | `Cargo.toml` | `Cargo.lock` |\n| Python (uv\u002Fpip) | `pyproject.toml` | `uv.lock` \u002F `requirements.txt` |\n| Node.js (npm) | `package.json` | `package-lock.json` |\n| Node.js (pnpm) | `package.json` | `pnpm-lock.yaml` |\n| Go | `go.mod` | `go.sum` |\n\n### Version pinning\n\n- **Exact pins** (`==1.2.3`): maximum reproducibility. Use for\n  applications and Docker images.\n- **Compatible range** (`^1.2.3` or `~=1.2`): allow patch\u002Fminor\n  updates. Use for libraries to avoid conflicts with consumers.\n- **Minimum bound** (`>=1.2.0`): widest compatibility, but can lead\n  to untested combinations. Use sparingly.\n\nRule of thumb: pin tightly in applications, pin loosely in libraries.\n\n### Automated updates\n\n**Dependabot** is GitHub-native. Configure\n`.github\u002Fdependabot.yml` with ecosystems, schedule, and reviewers.\nSet `open-pull-requests-limit` (5–10) to avoid PR floods. Group\nminor\u002Fpatch updates to reduce noise.\n\n**Renovate** is more flexible: monorepos, package-pattern grouping,\nauto-merge for patch updates. Use `extends: [\"config:recommended\"]`\nin `renovate.json` as a baseline. Use `matchPackagePatterns` to\ngroup related packages (e.g. all `@aws-sdk\u002F*`).\n\nFor both: require CI to pass before merging. Auto-merge patch\nupdates for well-tested projects. Review major updates manually and\nread the changelog.\n\n### Monorepos\n\nUse the workspace features your toolchain provides — Cargo\nworkspaces, npm\u002Fpnpm workspaces, uv workspaces. Share common\ndependency versions at the workspace root. Pin shared tooling\n(linters, formatters) at the root. Let individual packages declare\ntheir own domain-specific deps. Update everything together with\n`cargo update --workspace` or the equivalent.\n\n### Security and licenses\n\nIntegrate vulnerability scanning into CI. Block merges on\ncritical\u002Fhigh vulnerabilities and track accepted risks with ignore\nrules and expiry dates. For licenses, maintain an SPDX-based\nallow-list and flag copyleft licenses (GPL, AGPL) in proprietary\nprojects for legal review.\n\n| Tool | Ecosystem |\n|---|---|\n| `cargo audit` \u002F `cargo-deny` | Rust |\n| `npm audit` \u002F `pnpm audit` | Node.js |\n| `pip-audit` \u002F `uv pip audit` | Python |\n| `govulncheck` | Go |\n| `license-checker` | Node.js |\n| `pip-licenses` | Python |\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Hand-editing lockfiles.** Lockfiles are generated artifacts — their format is designed for machines and manual edits are easily invalid. Regenerate them with the package manager; never edit by hand.\n- **Omitting lockfiles from version control for applications.** Without a committed lockfile, different developers (and CI) resolve different transitive versions. Commit lockfiles for all applications and services; the \"don't commit lockfile\" rule applies only to libraries.\n- **Auto-merging major version bumps.** Major bumps can contain breaking API changes. Auto-merge is appropriate for patches, not majors. Major updates require changelog review before merging.\n- **Ignoring Dependabot or Renovate PRs until they pile up.** A backlog of 40 dependency PRs becomes unreviewable. Each one also causes merge conflicts with the others. Review and merge promptly; set a weekly cadence.\n- **Pinning loosely in applications \"to stay current\".** Applications should use exact pins and a managed update workflow. Loose ranges in applications lead to unreproducible builds and silent version drift between environments.\n- **Adding a 200-package dependency for a 5-line utility.** Every dependency is a maintenance, security, and license liability. Audit the size and scope of the dependency before adding it; prefer stdlib or a smaller alternative.\n- **No SLA on security advisories.** \"We'll get to it\" means critical vulnerabilities sit in the codebase for months. Define explicit SLAs: critical\u002Fhigh → fix within 48 hours; medium → within the current sprint.\n\n## Full reference\n\n### Dependency review checklist\n\nFor every PR that changes dependencies:\n\n1. **What changed** — new dependency, version bump, removal?\n2. **Why** — feature, security fix, deprecation?\n3. **License** — does it fit the project's allow-list?\n4. **Size and scope** — proportional to the problem it solves?\n5. **Alternatives** — is there a lighter or stdlib-based option?\n6. **Security** — does the new version have known advisories?\n\n### Vendoring\n\nCopy dependencies into the repository for offline builds or\nsupply-chain control:\n\n- Rust: `cargo vendor` plus `.cargo\u002Fconfig.toml` with\n  `[source.vendored-sources]`\n- Go: `go mod vendor` plus `-mod=vendor` at build time\n- Node.js: rarely vendored; use `npm pack` plus a local tarball if\n  needed\n\nVendor when building in air-gapped environments, pinning against\nregistry outages, or needing a full audit of dependency source.\n\n### Dependabot example\n\n```yaml\n# .github\u002Fdependabot.yml\nversion: 2\nupdates:\n  - package-ecosystem: cargo\n    directory: \u002F\n    schedule:\n      interval: weekly\n      day: monday\n    open-pull-requests-limit: 10\n    reviewers:\n      - \"team-backend\"\n    groups:\n      minor-and-patch:\n        update-types: [\"minor\", \"patch\"]\n\n  - package-ecosystem: npm\n    directory: \u002Ffrontend\n    schedule:\n      interval: weekly\n    groups:\n      react:\n        patterns: [\"react*\", \"@types\u002Freact*\"]\n```\n\n### cargo-deny example\n\n```toml\n# deny.toml\n[advisories]\nvulnerability = \"deny\"\nunmaintained = \"warn\"\nyanked = \"deny\"\n\n[licenses]\nallow = [\"MIT\", \"Apache-2.0\", \"BSD-2-Clause\", \"BSD-3-Clause\", \"ISC\", \"Unicode-3.0\"]\ncopyleft = \"deny\"\n\n[[licenses.exceptions]]\nallow = [\"MPL-2.0\"]\ncrates = [\"webpki-roots\"]\n\n[bans]\nmultiple-versions = \"warn\"\ndeny = [\n    { crate = \"openssl\", use-instead = \"rustls\" },\n]\n```\n\n### Renovate auto-merge example\n\n```json\n{\n  \"$schema\": \"https:\u002F\u002Fdocs.renovatebot.com\u002Frenovate-schema.json\",\n  \"extends\": [\"config:recommended\"],\n  \"packageRules\": [\n    {\n      \"matchUpdateTypes\": [\"patch\"],\n      \"automerge\": true,\n      \"automergeType\": \"pr\",\n      \"requiredStatusChecks\": [\"ci\"]\n    },\n    {\n      \"matchPackagePatterns\": [\"^@aws-sdk\u002F\"],\n      \"groupName\": \"AWS SDK\",\n      \"schedule\": [\"before 8am on monday\"]\n    },\n    {\n      \"matchUpdateTypes\": [\"major\"],\n      \"labels\": [\"breaking-change\"],\n      \"automerge\": false\n    }\n  ]\n}\n```\n\n### Anti-patterns\n\n- Hand-editing lockfiles instead of regenerating them\n- Ignoring Dependabot PRs until they pile up into an unreviewable\n  backlog\n- Auto-merging major updates without reading the changelog\n- Pinning loosely in applications \"to stay current\" — that is what\n  the update workflow is for\n- Adding a 200-package dependency for a five-line utility\n- Treating a security advisory as \"we'll get to it\" — set an SLA\n",{"name":5,"metadata":44,"description":50},{"processkit":45},{"id":46,"created":47,"version":48,"category":36,"apiVersion":49},"SKILL-dependency-management",1775433600000,"1.1.0","processkit.projectious.work\u002Fv1","Cross-language dependency management — lockfiles, version pinning, automated updates, security, and licenses. Use when setting up or reviewing lockfile strategy, configuring automated dependency updates, auditing dependencies for security or license issues, handling monorepo dependencies, or deciding whether to vendor.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fdependency-management","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add projectious-work\u002Fprocesskit --skill dependency-management",{"tool":64,"command":65},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill dependency-management",{"tool":67,"command":68},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill dependency-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fdependency-management\u002FSKILL.md",true,[],[73,98,118,138,155,173],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":84,"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",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[20,85,86,87,88,89,33,90,91,92,75,93,94,95,25,96,97],"skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":105,"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",[104],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[20,106,107,108,109,110,89,33,111,112,91,113,114,115,93,116,117],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"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",[],[20,125,126,86,87,127,89,33,128,129,130,131,93,132,133,134,26,135,136,137],"proposition","proposition management","index","log","world","record","query","creation","event","interface","facts","claims","WSJF",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"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",[],[20,92,145,86,89,146,147,111,148,128,91,149,150,93,151,152,133,153,25,154],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"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",[],[162,163,164,165,89,166,167,168,33,169,170,171,172],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"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",[],[20,180,181,86,87,127,89,146,33,90,128,182,91,130,93,152,133,134,183,97],"capability","capability management","queries","changes"]