[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WY3AXVNHYG69J2DR4C5FWE":3,"skill-same:01M6WY3AXVNHYG69J2DR4C5FWE":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},"01M6WY3AXVNHYG69J2DR4C5FWE","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\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.13.0\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,38],"review","dockerfile","dockerfile review","devops","when","v1","layer","size","orders","caching","build","images","writing","use","work","dockerfiles","Optimization","cache","best practices","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\u002Fv1\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":44,"description":50},{"processkit":45},{"id":46,"created":47,"version":48,"category":22,"apiVersion":49},"SKILL-dockerfile-review",1775433600000,"1.1.0","processkit.projectious.work\u002Fv1","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","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.13.0\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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add projectious-work\u002Fprocesskit --skill dockerfile-review",{"tool":64,"command":65},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill dockerfile-review",{"tool":67,"command":68},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill dockerfile-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.13.0\u002Fcontext\u002Fskills\u002Fdevops\u002Fdockerfile-review\u002FSKILL.md",true,[],[73,99,119,140,157,175],{"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","使用场景",[85,86,87,88,89,90,33,91,92,93,75,94,95,96,24,97,98],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":106,"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",[105],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[85,107,108,109,110,111,90,33,112,113,92,114,115,116,94,117,118],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"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",[],[85,126,127,87,88,128,90,33,129,130,131,132,94,133,134,135,136,137,138,139],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"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},"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",[],[85,93,147,87,90,148,149,112,150,129,92,151,152,94,153,154,134,155,24,156],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"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",[],[164,165,166,167,90,168,169,170,33,171,172,173,174],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"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",[],[85,182,183,87,88,128,90,148,33,91,129,184,92,131,94,154,134,135,185,98],"capability","capability management","queries","changes"]