Common Code Reviewer
Apply structured Dockerfile review rules with BLOCKER, MAJOR, and NIT severities before images reach production.
Overview
Common Code Reviewer is an agent skill most often used in Ship (also Build integrations) that applies Dockerfile hygiene and multi-stage rules with BLOCKER, MAJOR, and NIT severities.
Install
npx skills add https://github.com/william-yeh/common-code-reviewer --skill common-code-reviewerWhat is this skill?
- Enforces pinned digests and flags floating tags and FROM latest as BLOCKER
- Requires non-root USER and minimal final-stage bases to reduce attack surface
- Multi-stage rules: separate build/runtime, named stages, narrow COPY --from artifacts
- Severity buckets: BLOCKER, MAJOR, and NIT aligned to production container risk
- Applies to Dockerfile, Dockerfile.*, and *.dockerfile files in the common review framework
- Three severity buckets: BLOCKER, MAJOR, and NIT
- Targets Dockerfile, Dockerfile.*, and *.dockerfile paths
Adoption & trust: 1 installs on skills.sh; 1 GitHub stars; 2/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
Your agent reviews application code but Dockerfiles still slip through with latest tags, root users, and fat runtime images.
Who is it for?
Indie teams containerizing Node, Python, or polyglot services who want opinionated Docker review inside the agent.
Skip if: Projects with no containers, or teams that already enforce identical policy solely via centralized OPA or enterprise image scanners without agent review.
When should I use this skill?
Reviewing Dockerfiles in PRs or when hardening container images before production release.
What do I get? / Deliverables
Review output lists prioritized Dockerfile violations so you harden images before build pipelines or production deploy.
- Structured review comments with BLOCKER, MAJOR, and NIT severities
- Dockerfile-specific remediation guidance
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Container hygiene gates belong on the Ship shelf because they protect release artifacts, while teams also invoke them during Build when authoring Dockerfiles. Review subphase is the canonical home for automated code review supplements targeting Dockerfile and *.dockerfile paths.
Where it fits
First Dockerfile for a new API service gets reviewed for multi-stage separation before CI exists.
Pre-merge agent pass flags FROM latest and missing USER on production-bound images.
Release candidate images are checked for distroless preference and narrow COPY --from scopes.
Base image refresh PRs are reviewed for digest pinning instead of mutable tags.
How it compares
Checker-style review rules for Dockerfiles—not a Dockerfile generator or a CI build skill.
Common Questions / FAQ
Who is common-code-reviewer for?
Solo builders and small teams using AI agents for PR review who need Dockerfile-specific BLOCKER and MAJOR guidance.
When should I use common-code-reviewer?
In Ship review before merging container changes, in Build integrations when adding a new Dockerfile, or during Operate infra refreshes that retag base images.
Is common-code-reviewer safe to install?
Treat it like any review skill: consult Prism Security Audits on this page; it should not execute containers but may read repo Dockerfiles during review.
SKILL.md
READMESKILL.md - Common Code Reviewer
# Dockerfile Review Rules These rules supplement the common review framework. Apply them to `Dockerfile`, `Dockerfile.*`, and `*.dockerfile` files. ## Base Image Hygiene - **Pin base images to a digest**: `FROM node:20-alpine` is mutable — the tag can be overwritten. Prefer `FROM node:20-alpine@sha256:<digest>` for reproducible builds. Flag floating tags on production images as MAJOR. - **Use minimal base images**: Prefer distroless, Alpine, or scratch for final stages. Flag `ubuntu`, `debian`, or `centos` as final-stage bases unless justified — they carry significant unnecessary attack surface (MAJOR). - **Flag `FROM latest`**: Always a BLOCKER. `latest` is unpinned and will silently break on upstream updates. - **Avoid using root as the default**: The final stage must set `USER <non-root>`. Missing `USER` instruction is MAJOR — containers default to root, which is a container escape risk. ## Multi-Stage Builds - **Separate build and runtime stages**: Flag single-stage builds that install compilers, build tools, or SDKs in the same layer that runs the app. Build deps must not reach the final image (MAJOR). - **Name stages**: Use `FROM ... AS builder` for readability and to allow targeted builds (`docker build --target builder`). Unnamed stages in multi-stage files are a NIT. - **Copy only necessary artifacts**: `COPY --from=builder / /` copies the entire build filesystem. Flag overly broad `COPY --from` that brings in build tools or test artifacts (MAJOR). ## Layer and Cache Optimization - **Order instructions by change frequency** (ascending): `FROM` → system deps → app deps → app source → config. Placing `COPY . .` before `RUN npm install` busts the dependency cache on every source change — flag as MINOR. - **Combine related `RUN` commands**: Multiple `RUN apt-get install` calls create unnecessary layers. Combine with `&&` and clean up in the same layer (`rm -rf /var/lib/apt/lists/*`). Flag as MINOR. - **Clean package manager caches in the same `RUN` layer**: `apt-get install` followed by a separate `RUN rm -rf /var/lib/apt/lists/*` does not save space — the data is already committed to the layer below. Must be the same `RUN` instruction (MAJOR). - **Avoid `ADD` when `COPY` suffices**: `ADD` has implicit tar-extraction and URL-fetching behavior. Use `COPY` for local files. Flag `ADD` for local file copy as MINOR. ## Security - **Never bake secrets into image layers**: `ENV SECRET=...`, `ARG SECRET=...` used as runtime secrets, or credentials in `RUN curl -H "Authorization: Bearer ..."` are BLOCKERs. Secrets persist in layer history even after deletion. Use `--secret` (BuildKit) or inject at runtime via environment. - **Flag `--no-check-certificate` / `curl -k`**: Disabling TLS verification in `RUN` instructions is a BLOCKER — supply chain attack vector. - **Verify downloaded artifacts**: `RUN wget ... && tar xz ...` without checksum verification is MAJOR. Always verify with `sha256sum` or GPG signatures. - **Drop capabilities and set read-only root filesystem**: Not enforceable in the Dockerfile itself, but flag if the image is being built for Kubernetes and no `securityContext` equivalent is visible. Raise as an advisory NIT. - **`HEALTHCHECK` presence**: Production images should declare a `HEALTHCHECK`. Missing healthcheck is MINOR — orchestrators can't determine container readiness without it. ## Environment and Configuration - **Prefer `COPY` over `ADD` for config files**: Explicit is better than implicit. - **Use `ENV` for runtime configuration, `ARG` for build-time configuration**: Swapping these means secrets or build metadata leak into the runtime environment (or vice versa). Flag `ARG` used for values that need to persist at runtime as MINOR. - **Set `WORKDIR` explicitly**: Relying on implicit `/` as working directory makes paths fragile. Flag missing `WORKDIR` in any non-trivial Dockerfile as MINOR. - **Expose only necessary ports**: `EXPOSE` is documentation, not enforcement, but flag `EXPOSE 0-65535`