[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NPMQ76GGXGFA4M9C7CS7D4":3,"skill-same:01M6NPMQ76GGXGFA4M9C7CS7D4":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":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6NPMQ76GGXGFA4M9C7CS7D4","dockerfile-review",null,"Dockerfile best practices — layer optimization, caching, security, image size. Use when writing, reviewing, or optimizing Dockerfiles, investigating bloated images, or fixing cache-busting build orders.","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\u002Fdevops\u002Fdockerfile-review\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"dockerfile review","review","dockerfile","work","layer","size","orders","caching","build","images","devops","use","writing","dockerfiles","Optimization","cache","best practices","security","image","2026-11-10 10:12:30",false,"---\nname: dockerfile-review\ndescription: |\n  Dockerfile best practices — layer optimization, caching, security, image size. Use when writing, reviewing, or optimizing Dockerfiles, investigating bloated images, or fixing cache-busting build orders.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv2\n    id: SKILL-dockerfile-review\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: devops\n---\n\n# Dockerfile Review\n\n## Intro\n\nA good Dockerfile is small, cache-friendly, reproducible, and does not\nrun as root. Most problems come from three mistakes: ordering layers\nwrong (busting the cache), forgetting to clean up package manager\nstate, and using `ADD` when `COPY` is what you meant.\n\n## Overview\n\n### Layer optimization\n\nEvery instruction creates a layer; layers are cached in order. Order\ninstructions from least to most frequently changing so the cache stays\nwarm. Combine related `RUN` commands with `&&` to collapse layers.\nKeep a `.dockerignore` file so build context does not balloon with\n`node_modules`, `.git`, and local caches.\n\n### Caching dependencies\n\nCopy dependency manifests and install **before** copying source code.\nIf the manifests haven't changed, the install layer is reused:\n\n```dockerfile\nCOPY requirements.txt .\nRUN pip install -r requirements.txt\nCOPY . .\n```\n\nPin dependency versions so builds are reproducible. Unpinned\ndependencies produce \"works in CI, fails in prod\" surprises.\n\n### Security\n\n- Don't run as root. Create a non-root user and `USER` into it after\n  setup.\n- Never `COPY` secrets into an image. Use BuildKit build secrets or\n  inject via runtime environment variables.\n- Pin base images by digest for supply-chain integrity:\n  `FROM python:3.12-slim@sha256:...`.\n- Remove package manager caches after installing\n  (`rm -rf \u002Fvar\u002Flib\u002Fapt\u002Flists\u002F*`).\n\n### Size reduction\n\n- Start from slim or alpine base images where the ecosystem supports\n  it.\n- Use multi-stage builds for compiled languages — the final stage\n  should not contain the compiler.\n- Remove build tools after compilation.\n- Use `--no-install-recommends` with `apt-get`.\n\n### Correctness\n\n- Prefer `COPY` over `ADD` — `ADD` has magic behavior (URL fetch,\n  auto-extraction) that usually surprises you.\n- Set `WORKDIR` instead of `cd` in `RUN` commands.\n- Use the exec form of `CMD` and `ENTRYPOINT`:\n  `[\"executable\", \"arg\"]`, not the shell form.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **`COPY . .` before installing dependencies.** Copying the full source tree before the dependency install step means any source file change invalidates the install cache, forcing a full reinstall on every build. Copy dependency manifests first (`COPY requirements.txt .`), install, then copy source — this way the install layer is reused unless the manifest changes.\n- **Running the final image as root.** A container running as root inside a compromised container has host-level privileges if the container runtime is misconfigured or if a vulnerability allows container escape. Always create a dedicated non-root user and `USER` into it before `CMD`\u002F`ENTRYPOINT`. This is a single `RUN useradd` and `USER` instruction.\n- **Using `ADD` with a local path instead of `COPY`.** `ADD` with a local file path behaves like `COPY` but also auto-extracts tarballs and fetches URLs — surprising behavior that causes non-obvious build results. Use `COPY` for all local file copies; `ADD` is only appropriate for URL fetching or deliberate tarball extraction.\n- **Unpinned base image tags (`FROM python:latest`).** `latest` resolves to a different image every time the build runs on a new host or after an upstream push, producing non-reproducible builds. Pin to a specific version tag (`python:3.12-slim`) and ideally to a digest (`@sha256:...`) for full supply-chain integrity.\n- **Shell-form `CMD` or `ENTRYPOINT`.** `CMD python app.py` (shell form) runs the command inside `\u002Fbin\u002Fsh -c`, which means signals from the container runtime (`SIGTERM` on `docker stop`) are sent to the shell, not to the Python process. The process does not shut down gracefully. Use exec form: `CMD [\"python\", \"app.py\"]`.\n- **`apt-get install` and `rm -rf \u002Fvar\u002Flib\u002Fapt\u002Flists\u002F*` in separate `RUN` instructions.** Docker layers are immutable snapshots. Removing the apt cache in a later `RUN` does not reclaim the space from the earlier layer — the files exist in the earlier layer's snapshot permanently. Combine `apt-get update`, `apt-get install`, and the cleanup into a single `RUN` command.\n- **Secrets passed via `ARG` or `ENV`.** Build arguments and environment variables are stored in the image's layer history and visible with `docker history` or `docker inspect`. Never pass API keys, passwords, or tokens via `ARG` or `ENV` at build time — use BuildKit's `--mount=type=secret` for build-time secrets, and runtime environment variables for run-time secrets.\n\n## Full reference\n\n### Canonical Python Dockerfile\n\n```dockerfile\n# syntax=docker\u002Fdockerfile:1.7\nFROM python:3.12-slim@sha256:... AS builder\nWORKDIR \u002Fapp\nCOPY requirements.txt .\nRUN pip install --no-cache-dir --prefix=\u002Finstall -r requirements.txt\n\nFROM python:3.12-slim@sha256:...\nRUN useradd --create-home --uid 1000 app\nWORKDIR \u002Fapp\nCOPY --from=builder \u002Finstall \u002Fusr\u002Flocal\nCOPY --chown=app:app . .\nUSER app\nENV PYTHONUNBUFFERED=1 PYTHONDONTWRITEBYTECODE=1\nENTRYPOINT [\"python\", \"-m\", \"myapp\"]\n```\n\nNotable choices: multi-stage build so pip's build deps are not in the\nfinal image, explicit non-root user, `COPY --chown` so we don't need\na later `chown`, exec-form entrypoint, environment variables set via\n`ENV` rather than inside the command.\n\n### Canonical apt cleanup\n\n```dockerfile\nRUN apt-get update \\\n && apt-get install -y --no-install-recommends \\\n        ca-certificates \\\n        curl \\\n && rm -rf \u002Fvar\u002Flib\u002Fapt\u002Flists\u002F*\n```\n\nAlways combine `update`, `install`, and cleanup into one `RUN`. A\nseparate `RUN rm -rf \u002Fvar\u002Flib\u002Fapt\u002Flists\u002F*` does nothing for image size\nbecause the previous layer already committed those files.\n\n### Multi-stage build for Go\n\n```dockerfile\nFROM golang:1.22-alpine AS builder\nWORKDIR \u002Fsrc\nCOPY go.mod go.sum .\u002F\nRUN go mod download\nCOPY . .\nRUN CGO_ENABLED=0 go build -o \u002Fout\u002Fapp .\u002Fcmd\u002Fapp\n\nFROM gcr.io\u002Fdistroless\u002Fstatic-debian12\nCOPY --from=builder \u002Fout\u002Fapp \u002Fapp\nUSER nonroot:nonroot\nENTRYPOINT [\"\u002Fapp\"]\n```\n\n### Anti-patterns\n\n- **`COPY . .` before installing dependencies** — every source change\n  busts the install cache\n- **Running as root in production** — add a user and `USER` into it\n- **`ADD` with a local path** — use `COPY`; reserve `ADD` for URL\n  fetches and tar auto-extraction\n- **`latest` base image tags** — pin to a specific version, ideally by\n  digest\n- **Shell-form `CMD` \u002F `ENTRYPOINT`** — breaks signal handling; use\n  the exec form\n- **`apt-get install` without `--no-install-recommends`** — pulls in\n  tons of suggested packages\n- **Secrets via `ARG` or `ENV`** — they persist in image history; use\n  BuildKit secrets (`--mount=type=secret`) instead\n- **Missing `.dockerignore`** — sends `.git`, `node_modules`, and\n  everything else to the daemon as build context\n\n### Review checklist\n\n- Is the base image pinned (ideally by digest)?\n- Are dependencies installed before source is copied?\n- Is `.dockerignore` present and sensible?\n- Does the final stage run as non-root?\n- Are package manager caches removed in the same `RUN`?\n- Is `ENTRYPOINT` \u002F `CMD` in exec form?\n- Are compile-time deps excluded from the final stage?\n- Is there any `latest`, any bare `ADD`, any secret in `ARG`\u002F`ENV`?\n","# Dockerfile Review\n\n## Intro\n\nA good Dockerfile is small, cache-friendly, reproducible, and does not\nrun as root. Most problems come from three mistakes: ordering layers\nwrong (busting the cache), forgetting to clean up package manager\nstate, and using `ADD` when `COPY` is what you meant.\n\n## Overview\n\n### Layer optimization\n\nEvery instruction creates a layer; layers are cached in order. Order\ninstructions from least to most frequently changing so the cache stays\nwarm. Combine related `RUN` commands with `&&` to collapse layers.\nKeep a `.dockerignore` file so build context does not balloon with\n`node_modules`, `.git`, and local caches.\n\n### Caching dependencies\n\nCopy dependency manifests and install **before** copying source code.\nIf the manifests haven't changed, the install layer is reused:\n\n```dockerfile\nCOPY requirements.txt .\nRUN pip install -r requirements.txt\nCOPY . .\n```\n\nPin dependency versions so builds are reproducible. Unpinned\ndependencies produce \"works in CI, fails in prod\" surprises.\n\n### Security\n\n- Don't run as root. Create a non-root user and `USER` into it after\n  setup.\n- Never `COPY` secrets into an image. Use BuildKit build secrets or\n  inject via runtime environment variables.\n- Pin base images by digest for supply-chain integrity:\n  `FROM python:3.12-slim@sha256:...`.\n- Remove package manager caches after installing\n  (`rm -rf \u002Fvar\u002Flib\u002Fapt\u002Flists\u002F*`).\n\n### Size reduction\n\n- Start from slim or alpine base images where the ecosystem supports\n  it.\n- Use multi-stage builds for compiled languages — the final stage\n  should not contain the compiler.\n- Remove build tools after compilation.\n- Use `--no-install-recommends` with `apt-get`.\n\n### Correctness\n\n- Prefer `COPY` over `ADD` — `ADD` has magic behavior (URL fetch,\n  auto-extraction) that usually surprises you.\n- Set `WORKDIR` instead of `cd` in `RUN` commands.\n- Use the exec form of `CMD` and `ENTRYPOINT`:\n  `[\"executable\", \"arg\"]`, not the shell form.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **`COPY . .` before installing dependencies.** Copying the full source tree before the dependency install step means any source file change invalidates the install cache, forcing a full reinstall on every build. Copy dependency manifests first (`COPY requirements.txt .`), install, then copy source — this way the install layer is reused unless the manifest changes.\n- **Running the final image as root.** A container running as root inside a compromised container has host-level privileges if the container runtime is misconfigured or if a vulnerability allows container escape. Always create a dedicated non-root user and `USER` into it before `CMD`\u002F`ENTRYPOINT`. This is a single `RUN useradd` and `USER` instruction.\n- **Using `ADD` with a local path instead of `COPY`.** `ADD` with a local file path behaves like `COPY` but also auto-extracts tarballs and fetches URLs — surprising behavior that causes non-obvious build results. Use `COPY` for all local file copies; `ADD` is only appropriate for URL fetching or deliberate tarball extraction.\n- **Unpinned base image tags (`FROM python:latest`).** `latest` resolves to a different image every time the build runs on a new host or after an upstream push, producing non-reproducible builds. Pin to a specific version tag (`python:3.12-slim`) and ideally to a digest (`@sha256:...`) for full supply-chain integrity.\n- **Shell-form `CMD` or `ENTRYPOINT`.** `CMD python app.py` (shell form) runs the command inside `\u002Fbin\u002Fsh -c`, which means signals from the container runtime (`SIGTERM` on `docker stop`) are sent to the shell, not to the Python process. The process does not shut down gracefully. Use exec form: `CMD [\"python\", \"app.py\"]`.\n- **`apt-get install` and `rm -rf \u002Fvar\u002Flib\u002Fapt\u002Flists\u002F*` in separate `RUN` instructions.** Docker layers are immutable snapshots. Removing the apt cache in a later `RUN` does not reclaim the space from the earlier layer — the files exist in the earlier layer's snapshot permanently. Combine `apt-get update`, `apt-get install`, and the cleanup into a single `RUN` command.\n- **Secrets passed via `ARG` or `ENV`.** Build arguments and environment variables are stored in the image's layer history and visible with `docker history` or `docker inspect`. Never pass API keys, passwords, or tokens via `ARG` or `ENV` at build time — use BuildKit's `--mount=type=secret` for build-time secrets, and runtime environment variables for run-time secrets.\n\n## Full reference\n\n### Canonical Python Dockerfile\n\n```dockerfile\n# syntax=docker\u002Fdockerfile:1.7\nFROM python:3.12-slim@sha256:... AS builder\nWORKDIR \u002Fapp\nCOPY requirements.txt .\nRUN pip install --no-cache-dir --prefix=\u002Finstall -r requirements.txt\n\nFROM python:3.12-slim@sha256:...\nRUN useradd --create-home --uid 1000 app\nWORKDIR \u002Fapp\nCOPY --from=builder \u002Finstall \u002Fusr\u002Flocal\nCOPY --chown=app:app . .\nUSER app\nENV PYTHONUNBUFFERED=1 PYTHONDONTWRITEBYTECODE=1\nENTRYPOINT [\"python\", \"-m\", \"myapp\"]\n```\n\nNotable choices: multi-stage build so pip's build deps are not in the\nfinal image, explicit non-root user, `COPY --chown` so we don't need\na later `chown`, exec-form entrypoint, environment variables set via\n`ENV` rather than inside the command.\n\n### Canonical apt cleanup\n\n```dockerfile\nRUN apt-get update \\\n && apt-get install -y --no-install-recommends \\\n        ca-certificates \\\n        curl \\\n && rm -rf \u002Fvar\u002Flib\u002Fapt\u002Flists\u002F*\n```\n\nAlways combine `update`, `install`, and cleanup into one `RUN`. A\nseparate `RUN rm -rf \u002Fvar\u002Flib\u002Fapt\u002Flists\u002F*` does nothing for image size\nbecause the previous layer already committed those files.\n\n### Multi-stage build for Go\n\n```dockerfile\nFROM golang:1.22-alpine AS builder\nWORKDIR \u002Fsrc\nCOPY go.mod go.sum .\u002F\nRUN go mod download\nCOPY . .\nRUN CGO_ENABLED=0 go build -o \u002Fout\u002Fapp .\u002Fcmd\u002Fapp\n\nFROM gcr.io\u002Fdistroless\u002Fstatic-debian12\nCOPY --from=builder \u002Fout\u002Fapp \u002Fapp\nUSER nonroot:nonroot\nENTRYPOINT [\"\u002Fapp\"]\n```\n\n### Anti-patterns\n\n- **`COPY . .` before installing dependencies** — every source change\n  busts the install cache\n- **Running as root in production** — add a user and `USER` into it\n- **`ADD` with a local path** — use `COPY`; reserve `ADD` for URL\n  fetches and tar auto-extraction\n- **`latest` base image tags** — pin to a specific version, ideally by\n  digest\n- **Shell-form `CMD` \u002F `ENTRYPOINT`** — breaks signal handling; use\n  the exec form\n- **`apt-get install` without `--no-install-recommends`** — pulls in\n  tons of suggested packages\n- **Secrets via `ARG` or `ENV`** — they persist in image history; use\n  BuildKit secrets (`--mount=type=secret`) instead\n- **Missing `.dockerignore`** — sends `.git`, `node_modules`, and\n  everything else to the daemon as build context\n\n### Review checklist\n\n- Is the base image pinned (ideally by digest)?\n- Are dependencies installed before source is copied?\n- Is `.dockerignore` present and sensible?\n- Does the final stage run as non-root?\n- Are package manager caches removed in the same `RUN`?\n- Is `ENTRYPOINT` \u002F `CMD` in exec form?\n- Are compile-time deps excluded from the final stage?\n- Is there any `latest`, any bare `ADD`, any secret in `ARG`\u002F`ENV`?\n",{"name":5,"metadata":43,"description":49},{"processkit":44},{"id":45,"created":46,"version":47,"category":29,"apiVersion":48},"SKILL-dockerfile-review",1775433600000,"1.1.0","processkit.projectious.work\u002Fv2","Dockerfile best practices — layer optimization, caching, security, image size. Use when writing, reviewing, or optimizing Dockerfiles, investigating bloated images, or fixing cache-busting build orders.\n","main","7231f100e266e30d2c1699ecde5c00602471dc3c","src\u002Fcontext\u002Fskills\u002Fdevops\u002Fdockerfile-review","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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add projectious-work\u002Fprocesskit --skill dockerfile-review",{"tool":63,"command":64},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill dockerfile-review",{"tool":66,"command":67},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill dockerfile-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fdevops\u002Fdockerfile-review\u002FSKILL.md",true,[71],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":14,"sourceHtmlUrl":75},"scripts\u002F.gitkeep","SCRIPT","脚本","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fdevops\u002Fdockerfile-review\u002Fscripts\u002F.gitkeep",[77,104,124,145,162,180],{"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,92,93,94,22,95,96,97,79,98,99,100,101,102,103],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":111,"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",[110],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},[89,112,113,114,115,116,94,22,117,118,96,119,120,121,98,122,123],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"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,131,132,91,92,133,94,22,134,135,136,137,98,138,139,140,141,142,143,144],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"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,97,152,91,94,153,154,117,155,134,96,156,157,98,158,159,139,160,101,161],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"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",[],[169,170,171,172,94,173,174,175,22,176,177,178,179],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"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,187,188,91,92,133,94,153,22,95,134,189,96,136,98,159,139,140,190,103],"capability","capability management","queries","changes"]