Dockerfile & Container Reviewer

Reviews Dockerfiles and docker-compose files for security, size, build, and best practice issues, providing a detailed severity-rated report with fixes.

Security Scan

The skill is internally consistent with its stated purpose (reviewing Dockerfiles and docker-compose files) and asks for no extra credentials or installs; the only minor mismatch is an undocumented expectation of persistent state for its 'self-improvement' feature.

Purpose & Capability

Name/description match the runtime instructions: the SKILL.md describes checks and outputs that align with a Dockerfile/docker-compose reviewer. No unrelated binaries, env vars, or config paths are requested.

Instruction Scope

Instructions stay within scope (request the Dockerfile/docker-compose content and produce a structured report). However, the 'Self-improvement instructions' ask the agent to track counts across multiple reviews (after 20 reviews surface top mistakes), which implies persistent state or logging that is not specified—this is a scope extension worth clarifying.

Install Mechanism

No install spec and no code files—instruction-only skill with nothing written to disk or fetched at install time.

Credentials

No environment variables, credentials, or config path requirements are declared or referenced. The skill does request user-provided Dockerfile/compose content (which may contain secrets); the SKILL.md does call out checking for secrets but does not request any sensitive environment access.

Persistence & Privilege

always is false and autonomous invocation is allowed (platform default). The only concern is the self-improvement instruction that implies accumulating data across runs; the skill does not declare how or where that data should be stored or whether it will persist between sessions.

Assessment

This skill appears coherent for reviewing Dockerfiles and docker-compose files. Before enabling it, consider: (1) It asks you to paste Dockerfiles/compose files — don't paste secrets, private keys, or credentials into the review input. (2) The SKILL.md requests that the agent accumulate review counts and surface aggregated 'Top 3' mistakes after 20 reviews, but it doesn't declare any storage mechanism or retention policy — ask the skill author or platform how/where that summary data will be stored, who can access it, and how long it is retained. (3) Because the skill is instruction-only, it does no hidden network installs, but confirm your agent's default behavior for persisted memory/logging if you care about exposure of the reviewed contents.

dockerfile-reviewer

Description

Review Dockerfiles and docker-compose files for security vulnerabilities, oversized images, build inefficiencies, and missing best practices. Returns a structured report with severity ratings and corrected examples.

Use when

• "review my Dockerfile"
• "is this container secure"
• "optimize my docker build"
• "why is my image so large"
• "check my docker-compose"
• Any Dockerfile, docker-compose.yml, or .dockerignore

Input

Paste the Dockerfile and/or docker-compose.yml. Optionally specify:

• Target environment (production, CI, local dev)
• Base image constraints (must use specific distro, etc.)
• Whether the app runs as a service or a one-shot job

Output format

## Dockerfile Review

### Critical (fix before production)
- [Finding] — [security or correctness risk]
  ✗ Before: [problematic line(s)]
  ✓ After:  [corrected line(s)]

### Warnings (should fix)
- [Finding] — [size or reliability impact]

### Suggestions (nice to have)
- [Finding] — [explanation]

### What's correct
- [Specific patterns done right]

### Summary
[2–3 sentences: biggest risk, estimated image size savings if any, top fix]

Review checklist

Security

• Running as root (no USER directive) — container escape risk
• Secret or credential in ENV, ARG, or RUN layer — visible in image history
• Base image not pinned (FROM ubuntu:latest instead of ubuntu:22.04) — supply chain risk
• Using curl | bash to install software — arbitrary code execution
• Unnecessary packages installed (attack surface)
• No HEALTHCHECK — orchestrator can't detect unhealthy containers
• Writable filesystem where read-only would suffice

Image size

• Large base image when alpine or distroless would work
• Installing dev tools in production image (compilers, debuggers, test frameworks)
• Multiple RUN commands that should be chained with && (each RUN = a layer)
• COPY . . before dependency install (cache busting on every code change)
• Not using .dockerignore — copying node_modules, .git, build artifacts
• Leftover apt/apk cache not cleaned in same RUN layer

Build correctness

• Wrong WORKDIR — files land in unexpected paths
• EXPOSE port doesn't match what the app actually listens on
• CMD vs ENTRYPOINT confusion — CMD should be overridable args, ENTRYPOINT the executable
• Using ADD when COPY is sufficient (ADD has implicit tar extraction and URL fetch)
• Build args used as secrets (visible in docker history)

docker-compose specific

• No restart policy — containers don't recover from crashes
• Hardcoded secrets in environment: block — use .env or secrets
• Named volumes not defined in volumes: section
• Port binding to 0.0.0.0 when 127.0.0.1 would suffice
• No resource limits (mem_limit, cpus) — one container can starve others
• Depends_on without condition: service_healthy — race conditions on startup

Multi-stage build

• Single-stage build for compiled language — ships compiler in production image
• Build artifacts not properly copied from builder stage
• Redundant stages that could be merged

Severity definitions

• Critical: Security vulnerability or correctness bug that affects production
• Warning: Image bloat, reliability issue, or hard-to-debug behavior
• Suggestion: Style, caching efficiency, or future-proofing improvement

Self-improvement instructions

After each review, note the most impactful finding. After 20 reviews, surface "Top 3 Dockerfile mistakes" at the start of the response.