[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H122TVG2ES2QYRQ9VR5B7D":3,"skill-same:01M6H122TVG2ES2QYRQ9VR5B7D":113},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6H122TVG2ES2QYRQ9VR5B7D","docker-compose-patterns",null,"Use this skill when creating, modifying, or debugging Docker Compose configurations, even if the user just says they need to wire services together, add a database to their stack, or set up a local development environment with multiple containers. Covers service definitions, health checks, dependency ordering, volumes, networks, environment variables, and development overrides.","rokkay\u002Fdotfiles-macos","rokkay","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F47890402?v=4","01M6H11NRT7DCM9GA6N3522S20","José Carlos Raya","01M6H11NX2A5BWX1YEVPHEMS6Q",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-compose-patterns\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"docker","docker compose patterns","patterns","compose","docker compose","development","database","SET","networks","health","just","environment","use","up","debugging","local","development environment","local development","Variables","containers","2026-11-10 10:12:30",false,"---\nname: docker-compose-patterns\ndescription: Use this skill when creating, modifying, or debugging Docker Compose configurations, even if the user just says they need to wire services together, add a database to their stack, or set up a local development environment with multiple containers. Covers service definitions, health checks, dependency ordering, volumes, networks, environment variables, and development overrides.\nlicense: Apache-2.0\ncompatibility: Requires Docker Compose v2 (compose.yaml format).\n---\n\n# Docker Compose Patterns\n\n## Overview\n\nThis skill provides rules for creating, reviewing, and debugging Docker Compose configurations. Use it when the main artifact is `compose.yaml` or `compose.override.yaml` and the task is about service wiring rather than image-build internals.\n\n## When to use this skill\n\nActivate this skill when:\n\n- Creating a new `compose.yaml` for a project\n- Adding or modifying services in an existing Compose file\n- Setting up development overrides with `compose.override.yaml`\n- Debugging service startup ordering or connectivity issues\n\n## Do not use this skill when\n\nDo not use this skill when:\n\n- The project has no Docker setup yet and the main need is an initial scaffold\n- The main task is writing or optimizing a `Dockerfile`\n- The main task is improving build caching, image size, or runtime user configuration\n\n## Core guidance\n\n### File naming\n\nUse `compose.yaml` as the canonical filename. Do not use `docker-compose.yml` or `docker-compose.yaml` — those are legacy names.\n\n### Service definitions\n\n- Give services clear, lowercase names that reflect their role: `web`, `db`, `cache`, `worker`.\n- Always pin image tags to a specific version. Never use `latest` or omit the tag.\n- Set `restart: unless-stopped` for long-running infrastructure services and non-development deployments.\n- Add `container_name` only when external tools need a predictable name. Otherwise, let Compose generate names.\n\n### Dependency modeling\n\n- Use `depends_on` with `condition: service_healthy` for services that must be ready before dependents start.\n- Every service listed in `depends_on` with a health condition must have a `healthcheck` defined.\n- Do not rely on `depends_on` without conditions — it only guarantees container start, not readiness.\n\n### Health checks\n\n- Always add a `healthcheck` to database services (Postgres, MySQL, Redis, MongoDB).\n- Use the service's native client tool for health checks when available (e.g., `pg_isready`, `redis-cli ping`, `mysqladmin ping`).\n- Set reasonable `interval`, `timeout`, `retries`, and `start_period` values. Start with: `interval: 5s`, `timeout: 3s`, `retries: 3`, `start_period: 10s`.\n\n#### Health checks for distroless or scratch images\n\nDistroless, scratch-based, and hardened images contain no shell, curl, or wget. Do not bake tools into these images — that defeats their purpose. Instead, use a **healthcheck sidecar** that shares the application's network namespace:\n\n```yaml\nservices:\n  api:\n    build:\n      context: .\n      target: runtime          # distroless \u002F hardened image\n    ports:\n      - \"8080:8080\"\n    # No healthcheck here — the image has no tools to run one\n\n  api-health:\n    image: curlimages\u002Fcurl:8.22.0\n    network_mode: \"service:api\"   # shares api's localhost\n    entrypoint: [\"sleep\", \"infinity\"]  # keep sidecar alive for healthcheck\n    healthcheck:\n      test: [\"CMD\", \"curl\", \"-f\", \"http:\u002F\u002Flocalhost:8080\u002Fhealth\"]\n      interval: 30s\n      timeout: 5s\n      retries: 3\n      start_period: 45s\n    deploy:\n      resources:\n        limits:\n          memory: 32M\n```\n\nKey points:\n- The sidecar must stay alive with `entrypoint: [\"sleep\", \"infinity\"]` so Compose can execute the healthcheck inside it.\n- `network_mode: \"service:api\"` makes `localhost` inside the sidecar resolve to the api container's loopback — no extra networking needed.\n- Keep the sidecar lightweight with a resource limit (32MB is sufficient for curl).\n- Services that depend on `api` being ready should reference the **sidecar**, not the api directly:\n\n```yaml\n  worker:\n    depends_on:\n      api-health:\n        condition: service_healthy\n```\n\n### Volumes\n\n- Use named volumes for data that must persist across container recreations (database data, uploaded files).\n- Use bind mounts only for development-time source code syncing.\n- Define all named volumes in the top-level `volumes:` key.\n- Do not mount the Docker socket unless the service genuinely requires it.\n\n### Networks\n\n- For single-application stacks, the default network is sufficient. Do not create custom networks unless you need isolation between service groups.\n- When creating custom networks, prefer bridge driver and give networks descriptive names.\n- Use the top-level `networks:` key to define all custom networks.\n\n### Environment variables\n\n- Use `environment:` for non-sensitive values that are few in number.\n- Use `env_file:` pointing to a `.env` file for longer lists of variables.\n- Never hardcode secrets (passwords, API keys) directly in `compose.yaml`. Use `env_file:` or Docker secrets.\n- When defaults are needed in the `environment:` block for local development, use variable substitution with fallbacks: `${DB_PASSWORD:-postgres}`. Never write bare plaintext values for password fields.\n- Add `.env` to `.gitignore`.\n\n### Development overrides\n\n- Use `compose.override.yaml` for development-only settings. Compose loads it automatically alongside `compose.yaml`.\n- Put bind mounts for source code, debug ports, and development environment variables in the override file.\n- Use `develop.watch` for file-syncing and auto-rebuild in development when supported.\n- Keep production-oriented settings in the base `compose.yaml` and override only what changes for development.\n\n### Compose Watch\n\n- Prefer `develop.watch` over manual bind mounts for development workflows.\n- Use `action: sync` for files that should be copied into the container on change (source code).\n- Use `action: rebuild` for files that require a full image rebuild (dependency files like `package.json`, `requirements.txt`).\n- Use `action: sync+restart` for configuration files that need a process restart.\n\n### Destructive commands\n\nSome Compose commands delete data irreversibly. Before running any of the following, state exactly which data will be deleted and get explicit confirmation from the user — do not run them as a side effect of debugging, restarting, or \"cleaning up\" a stack:\n\n- `docker compose down -v` \u002F `docker compose down --volumes` — deletes named volumes, including database data.\n- `docker volume rm` \u002F `docker volume prune` run against a Compose project's volumes — deletes volumes directly. For the standalone case (no Compose project in play), see `docker-destructive-guardrails` instead. A volume referenced via `external: true` isn't managed by the Compose project either (`down -v` won't touch it) — treat it as the standalone case too: run `docker volume rm` without `-f` first, and get explicit confirmation before deleting it.\n- `docker compose rm -v` — deletes anonymous volumes attached to removed containers.\n\nIf the goal is only to restart services or reclaim containers\u002Fnetworks, use `docker compose down` (no `-v`) or `docker compose restart` instead — these leave named volumes intact.\n\n## Related skills\n\n- For first-time Docker project scaffolding and baseline file creation, use `docker-project-foundations`.\n- For Dockerfile internals, build caching, multi-stage builds, and `.dockerignore`, use `docker-build-strategies`.\n- For destructive Docker CLI commands outside Compose (`docker system prune`, `docker rm -f`, image\u002Fnetwork\u002Fbuilder pruning, standalone volume deletion) and a cross-product index of destructive-command guardrails, use `docker-destructive-guardrails`.\n\n## References\n\n- `references\u002Fservice-dependencies.md` — Detailed guidance on `depends_on`, health check patterns for common databases, and startup ordering strategies.\n- `references\u002Fvolumes-and-networks.md` — Patterns for volume mounts, named volumes, bind mounts, and network configuration.\n\n## Assets\n\n- `assets\u002Fcompose-web-app.yaml` — Complete multi-service web app (app + Postgres + Redis) with health checks, dependencies, and named volumes.\n- `assets\u002Fcompose-dev-override.yaml` — Development override showing bind mounts, debug ports, and Compose Watch configuration.\n- `assets\u002Fbad-vs-good.md` — Before\u002Fafter comparisons of common Compose mistakes and their fixes.\n\n## Scripts\n\n- **`scripts\u002Fverify-compose.sh`** — Validates the Compose project in the current directory with `docker compose config --quiet`, without printing resolved configuration. Run it from the project root (the directory that contains `compose.yaml`), with the script path resolved under this skill's directory:\n  ```bash\n  bash \"\u003Cskill-dir>\u002Fscripts\u002Fverify-compose.sh\" [--help]\n  ```\n  Replace `\u003Cskill-dir>` with the absolute path of the folder that contains this `SKILL.md`; the `scripts\u002F` path is relative to that folder, not to the project. Do not change into the skill directory first: the script validates whatever Compose project is in the current directory. If the skill directory cannot be resolved, run `docker compose config --quiet` directly. Exit status is `0` when the Compose configuration is valid or help is requested, the non-zero status from `docker compose config --quiet` when validation fails, and `2` for invalid arguments. Plain `docker compose config` can expose interpolated and `env_file` credentials in tool output or logs; use quiet validation by default. Compose warnings and errors are still emitted and may contain sensitive details.\n\n## Checks\n\n- `checks\u002Fverification.md` — Detailed verification runbook for manual review.\n","# Docker Compose Patterns\n\n## Overview\n\nThis skill provides rules for creating, reviewing, and debugging Docker Compose configurations. Use it when the main artifact is `compose.yaml` or `compose.override.yaml` and the task is about service wiring rather than image-build internals.\n\n## When to use this skill\n\nActivate this skill when:\n\n- Creating a new `compose.yaml` for a project\n- Adding or modifying services in an existing Compose file\n- Setting up development overrides with `compose.override.yaml`\n- Debugging service startup ordering or connectivity issues\n\n## Do not use this skill when\n\nDo not use this skill when:\n\n- The project has no Docker setup yet and the main need is an initial scaffold\n- The main task is writing or optimizing a `Dockerfile`\n- The main task is improving build caching, image size, or runtime user configuration\n\n## Core guidance\n\n### File naming\n\nUse `compose.yaml` as the canonical filename. Do not use `docker-compose.yml` or `docker-compose.yaml` — those are legacy names.\n\n### Service definitions\n\n- Give services clear, lowercase names that reflect their role: `web`, `db`, `cache`, `worker`.\n- Always pin image tags to a specific version. Never use `latest` or omit the tag.\n- Set `restart: unless-stopped` for long-running infrastructure services and non-development deployments.\n- Add `container_name` only when external tools need a predictable name. Otherwise, let Compose generate names.\n\n### Dependency modeling\n\n- Use `depends_on` with `condition: service_healthy` for services that must be ready before dependents start.\n- Every service listed in `depends_on` with a health condition must have a `healthcheck` defined.\n- Do not rely on `depends_on` without conditions — it only guarantees container start, not readiness.\n\n### Health checks\n\n- Always add a `healthcheck` to database services (Postgres, MySQL, Redis, MongoDB).\n- Use the service's native client tool for health checks when available (e.g., `pg_isready`, `redis-cli ping`, `mysqladmin ping`).\n- Set reasonable `interval`, `timeout`, `retries`, and `start_period` values. Start with: `interval: 5s`, `timeout: 3s`, `retries: 3`, `start_period: 10s`.\n\n#### Health checks for distroless or scratch images\n\nDistroless, scratch-based, and hardened images contain no shell, curl, or wget. Do not bake tools into these images — that defeats their purpose. Instead, use a **healthcheck sidecar** that shares the application's network namespace:\n\n```yaml\nservices:\n  api:\n    build:\n      context: .\n      target: runtime          # distroless \u002F hardened image\n    ports:\n      - \"8080:8080\"\n    # No healthcheck here — the image has no tools to run one\n\n  api-health:\n    image: curlimages\u002Fcurl:8.22.0\n    network_mode: \"service:api\"   # shares api's localhost\n    entrypoint: [\"sleep\", \"infinity\"]  # keep sidecar alive for healthcheck\n    healthcheck:\n      test: [\"CMD\", \"curl\", \"-f\", \"http:\u002F\u002Flocalhost:8080\u002Fhealth\"]\n      interval: 30s\n      timeout: 5s\n      retries: 3\n      start_period: 45s\n    deploy:\n      resources:\n        limits:\n          memory: 32M\n```\n\nKey points:\n- The sidecar must stay alive with `entrypoint: [\"sleep\", \"infinity\"]` so Compose can execute the healthcheck inside it.\n- `network_mode: \"service:api\"` makes `localhost` inside the sidecar resolve to the api container's loopback — no extra networking needed.\n- Keep the sidecar lightweight with a resource limit (32MB is sufficient for curl).\n- Services that depend on `api` being ready should reference the **sidecar**, not the api directly:\n\n```yaml\n  worker:\n    depends_on:\n      api-health:\n        condition: service_healthy\n```\n\n### Volumes\n\n- Use named volumes for data that must persist across container recreations (database data, uploaded files).\n- Use bind mounts only for development-time source code syncing.\n- Define all named volumes in the top-level `volumes:` key.\n- Do not mount the Docker socket unless the service genuinely requires it.\n\n### Networks\n\n- For single-application stacks, the default network is sufficient. Do not create custom networks unless you need isolation between service groups.\n- When creating custom networks, prefer bridge driver and give networks descriptive names.\n- Use the top-level `networks:` key to define all custom networks.\n\n### Environment variables\n\n- Use `environment:` for non-sensitive values that are few in number.\n- Use `env_file:` pointing to a `.env` file for longer lists of variables.\n- Never hardcode secrets (passwords, API keys) directly in `compose.yaml`. Use `env_file:` or Docker secrets.\n- When defaults are needed in the `environment:` block for local development, use variable substitution with fallbacks: `${DB_PASSWORD:-postgres}`. Never write bare plaintext values for password fields.\n- Add `.env` to `.gitignore`.\n\n### Development overrides\n\n- Use `compose.override.yaml` for development-only settings. Compose loads it automatically alongside `compose.yaml`.\n- Put bind mounts for source code, debug ports, and development environment variables in the override file.\n- Use `develop.watch` for file-syncing and auto-rebuild in development when supported.\n- Keep production-oriented settings in the base `compose.yaml` and override only what changes for development.\n\n### Compose Watch\n\n- Prefer `develop.watch` over manual bind mounts for development workflows.\n- Use `action: sync` for files that should be copied into the container on change (source code).\n- Use `action: rebuild` for files that require a full image rebuild (dependency files like `package.json`, `requirements.txt`).\n- Use `action: sync+restart` for configuration files that need a process restart.\n\n### Destructive commands\n\nSome Compose commands delete data irreversibly. Before running any of the following, state exactly which data will be deleted and get explicit confirmation from the user — do not run them as a side effect of debugging, restarting, or \"cleaning up\" a stack:\n\n- `docker compose down -v` \u002F `docker compose down --volumes` — deletes named volumes, including database data.\n- `docker volume rm` \u002F `docker volume prune` run against a Compose project's volumes — deletes volumes directly. For the standalone case (no Compose project in play), see `docker-destructive-guardrails` instead. A volume referenced via `external: true` isn't managed by the Compose project either (`down -v` won't touch it) — treat it as the standalone case too: run `docker volume rm` without `-f` first, and get explicit confirmation before deleting it.\n- `docker compose rm -v` — deletes anonymous volumes attached to removed containers.\n\nIf the goal is only to restart services or reclaim containers\u002Fnetworks, use `docker compose down` (no `-v`) or `docker compose restart` instead — these leave named volumes intact.\n\n## Related skills\n\n- For first-time Docker project scaffolding and baseline file creation, use `docker-project-foundations`.\n- For Dockerfile internals, build caching, multi-stage builds, and `.dockerignore`, use `docker-build-strategies`.\n- For destructive Docker CLI commands outside Compose (`docker system prune`, `docker rm -f`, image\u002Fnetwork\u002Fbuilder pruning, standalone volume deletion) and a cross-product index of destructive-command guardrails, use `docker-destructive-guardrails`.\n\n## References\n\n- `references\u002Fservice-dependencies.md` — Detailed guidance on `depends_on`, health check patterns for common databases, and startup ordering strategies.\n- `references\u002Fvolumes-and-networks.md` — Patterns for volume mounts, named volumes, bind mounts, and network configuration.\n\n## Assets\n\n- `assets\u002Fcompose-web-app.yaml` — Complete multi-service web app (app + Postgres + Redis) with health checks, dependencies, and named volumes.\n- `assets\u002Fcompose-dev-override.yaml` — Development override showing bind mounts, debug ports, and Compose Watch configuration.\n- `assets\u002Fbad-vs-good.md` — Before\u002Fafter comparisons of common Compose mistakes and their fixes.\n\n## Scripts\n\n- **`scripts\u002Fverify-compose.sh`** — Validates the Compose project in the current directory with `docker compose config --quiet`, without printing resolved configuration. Run it from the project root (the directory that contains `compose.yaml`), with the script path resolved under this skill's directory:\n  ```bash\n  bash \"\u003Cskill-dir>\u002Fscripts\u002Fverify-compose.sh\" [--help]\n  ```\n  Replace `\u003Cskill-dir>` with the absolute path of the folder that contains this `SKILL.md`; the `scripts\u002F` path is relative to that folder, not to the project. Do not change into the skill directory first: the script validates whatever Compose project is in the current directory. If the skill directory cannot be resolved, run `docker compose config --quiet` directly. Exit status is `0` when the Compose configuration is valid or help is requested, the non-zero status from `docker compose config --quiet` when validation fails, and `2` for invalid arguments. Plain `docker compose config` can expose interpolated and `env_file` credentials in tool output or logs; use quiet validation by default. Compose warnings and errors are still emitted and may contain sensitive details.\n\n## Checks\n\n- `checks\u002Fverification.md` — Detailed verification runbook for manual review.\n",{"name":5,"license":15,"description":7,"compatibility":49},"Requires Docker Compose v2 (compose.yaml format).","main","bb10a31719754024b2c1a5cf7deac4f926f74e78","config\u002Fclaude\u002Fskills\u002Fdocker-compose-patterns","https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos","https:\u002F\u002Fgithub.com\u002Frokkay","https:\u002F\u002Fwww.rayaleonjosecarlos.com\u002F","2026-10-28 21:20:44",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add rokkay\u002Fdotfiles-macos --skill docker-compose-patterns",{"tool":63,"command":64},"bunx","bunx skills add rokkay\u002Fdotfiles-macos --skill docker-compose-patterns",{"tool":66,"command":67},"pnpm","pnpm dlx skills add rokkay\u002Fdotfiles-macos --skill docker-compose-patterns","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-compose-patterns\u002FSKILL.md",true,[71,77,83,87,91,95,99,103,109],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"agents\u002Fopenai.yaml","REFERENCE","参考文档",261,"https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-compose-patterns\u002Fagents\u002Fopenai.yaml",{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"assets\u002Fbad-vs-good.md","ASSET","资产文件",2841,"https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-compose-patterns\u002Fassets\u002Fbad-vs-good.md",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"assets\u002Fcompose-dev-override.yaml",858,"https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-compose-patterns\u002Fassets\u002Fcompose-dev-override.yaml",{"path":88,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":89,"sourceHtmlUrl":90},"assets\u002Fcompose-web-app.yaml",1127,"https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-compose-patterns\u002Fassets\u002Fcompose-web-app.yaml",{"path":92,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":93,"sourceHtmlUrl":94},"checks\u002Fverification.md",3830,"https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-compose-patterns\u002Fchecks\u002Fverification.md",{"path":96,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Fservice-dependencies.md",2829,"https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-compose-patterns\u002Freferences\u002Fservice-dependencies.md",{"path":100,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fvolumes-and-networks.md",3522,"https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-compose-patterns\u002Freferences\u002Fvolumes-and-networks.md",{"path":104,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":107,"sourceHtmlUrl":108},"scripts\u002Fverify-compose.sh","SCRIPT","脚本",672,"https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-compose-patterns\u002Fscripts\u002Fverify-compose.sh",{"path":110,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":111,"sourceHtmlUrl":112},"skill.yaml",848,"https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-compose-patterns\u002Fskill.yaml",[114,145,177,194],{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":118,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":124,"publishedAt":44},"01M6H160V7EKZC4FQQRC7T7A2W","vercel-react-best-practices","React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React\u002FNext.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.","MIT","https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fvercel-react-best-practices\u002FSKILL.md",[121],{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144],"react","vercel react best practices","best practices","react best practices","vercel","writing","performance","components","react components","guidelines","tasks","code","Optimization","data","Next.js","refactoring","performance optimization","next","pages","triggers",{"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":118,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":162,"publishedAt":44},"01M6H13D6YMMCM5A4CQXXH7KV4","spatie-guidelines","Spatie's PHP, Laravel, JavaScript and Vue coding guidelines and conventions. Use when writing or reviewing PHP, Laravel, JavaScript, or Vue code for Spatie projects or packages. Covers code style, type declarations, docblocks, control flow, naming, routing, controllers, Blade, validation, comments, testing (Pest), package structure, service providers, and Git workflow. Triggers include \"follow Spatie guidelines\", \"Spatie style\", \"Spatie package\", or any code review for Spatie packages and projects.","https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fspatie-guidelines\u002FSKILL.md",[151,154,157],{"categoryNo":152,"categoryName":153,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":155,"categoryName":156,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":158,"categoryName":159,"taxonomyType":160,"taxonomyTypeDesc":161},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[163,134,164,144,165,166,167,36,168,169,170,171,127,136,172,173,174,130,175,176],"spatie guidelines","comments","type","standards","git workflow","coding guidelines","laravel","projects","package","code review","for","review","testing","workflow",{"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":184,"publishedAt":44},"01M6H128NTSYQPRAQ30GHER0BB","docker-project-foundations","Use this skill when setting up, initializing, or Dockerizing a project, even if the user doesn't explicitly mention Docker but describes a need for containerized local development, adding a database or cache dependency, or running services without host-level installs. Covers Dockerfile, compose.yaml, and .dockerignore creation with Docker best practices.","https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-project-foundations\u002FSKILL.md",[183],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[24,185,186,187,188,28,29,189,173,190,191,41,192,39,27,37,36,193,30,127],"foundations","project","docker project foundations","dockerfile","host","containerized","with","creation","cache",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":204,"publishedAt":44},"01M6H11X7E42Z91MHWMEYWK839","docker-build-strategies","Use this skill when writing, reviewing, or optimizing Dockerfiles, even if the user just says their image is too large, their build is slow, or they need to harden a container for production. Covers multi-stage builds, layer caching, .dockerignore, non-root users, and image size optimization.","https:\u002F\u002Fgithub.com\u002Frokkay\u002Fdotfiles-macos\u002Fblob\u002Fmain\u002Fconfig\u002Fclaude\u002Fskills\u002Fdocker-build-strategies\u002FSKILL.md",[200,201],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":202,"categoryName":203,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[205,206,207,24,208,173,209,210,211,212,213,214,36,215,34,216,31,137,217,130],"docker build strategies","strategies","build","default","size","multi","users","stage","caching","container","before building","dockerfiles","image"]