agentsclimarketplace

Dockerize

Skill HM-IT-CODE/forge-skills/skills/devops/dockerize

Battle-tested Claude Code skills for full-stack & systems engineers

Install
npx -y skills add HM-IT-CODE/forge-skills --skill dockerize

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generates a production-grade, multi-stage Dockerfile and docker-compose for a project. Use when the user says "dockerize", "containerize this", "write a Dockerfile", "add Docker", or wants to package a service for deployment. Detects the stack and applies small-image, non-root, layer-caching best practices.

SKILL.md

3.1 KB, as published. Nobody here has run it

Dockerize

Produce a Dockerfile a platform team would approve: small, secure, reproducible, and fast to rebuild. Never a single fat FROM language with the whole repo copied in.

Step 1 — Detect the stack

Inspect the repo to determine language, build tool, and run command:

  • Node/TS: package.json (scripts, engines), lockfile (pnpm-lock.yaml / package-lock.json / yarn.lock).
  • Python: pyproject.toml / requirements.txt, entry module.
  • Rust: Cargo.toml, binary name from [[bin]] or package name.
  • Go: go.mod, main package path.

Confirm the detected build and start commands. If ambiguous, ask.

Step 2 — Write a multi-stage Dockerfile

Always use multi-stage builds: a builder stage with the toolchain, and a minimal runtime stage that copies only the artifact.

Apply these rules in every Dockerfile:

  • Pin the base image to a specific minor + variant (e.g. node:22-slim, python:3.12-slim, rust:1.79, golang:1.22). Avoid latest.
  • Order layers for cache: copy dependency manifests and install deps before copying source, so code changes don't bust the dependency layer.
  • Minimal runtime base: distroless, alpine, -slim, or scratch (Go/Rust static binaries).
  • Run as non-root: create and switch to an unprivileged user.
  • No secrets in layers. Use build args / runtime env, never bake credentials.
  • Add a HEALTHCHECK when the service exposes a port.
  • Set EXPOSE, a sensible WORKDIR, and an explicit CMD (exec form, JSON array).

Reference shape (Rust static binary)

# ---- builder ----
FROM rust:1.79-slim AS builder
WORKDIR /app
COPY Cargo.toml Cargo.lock ./
RUN mkdir src && echo "fn main() {}" > src/main.rs && cargo build --release && rm -rf src
COPY . .
RUN cargo build --release

# ---- runtime ----
FROM gcr.io/distroless/cc-debian12
COPY --from=builder /app/target/release/<binary> /usr/local/bin/app
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/usr/local/bin/app"]

Adapt the same two-stage pattern to whatever stack you detected.

Step 3 — Add .dockerignore

Generate a .dockerignore that excludes build artifacts and local junk so the build context stays small:

.git
target/
node_modules/
dist/
**/*.log
.env*

Step 4 — docker-compose (if it helps)

If the service needs a database or other dependency, generate a docker-compose.yml wiring the app to its dependencies with named volumes, a healthcheck-gated depends_on, and env passed via environment / .env. Keep it self-hostable with one docker compose up.

Step 5 — Verify

Show the user the docker build command and, where possible, note the expected final image size order of magnitude. Point out anything stack-specific they should tune (e.g. multi-arch builds, build secrets). Do not run pushes to any registry.

Gives 2 of the 12 instructions most containers cloud skills give

Counted across 607 of the 657 authors here whose files we hold, read 2026-08-06

  • run containers as a non-root userin 69 of 607, across 49 files
  • use multi-stage buildshere, and in 52 of 607, across 41 files
  • use Promise.all for independent operationsin 47 of 607, across 13 files
  • import directly instead of barrel filesin 46 of 607, across 12 files
  • use ternary instead of AND for conditionalsin 45 of 607, across 12 files
  • use Set or Map for O(1) lookupsin 42 of 607, across 10 files
  • create a .dockerignore filehere, and in 41 of 607, across 31 files
  • Read individual rule files for detailsin 39 of 607, across 9 files
  • authenticate server actions like API routesin 35 of 607, across 7 files
  • use next/dynamic for heavy componentsin 34 of 607, across 9 files
  • use React.cache for per-request deduplicationin 34 of 607, across 10 files
  • copy dependency files before source codein 34 of 607, across 21 files

Said here and by no other author read

  • inspect the repo to detect the stack
  • confirm detected build and start commands
  • ask if detected commands are ambiguous
  • pin the base image to a specific minor and variant
  • use build args or runtime env for secrets
  • add a healthcheck when the service exposes a port

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.