Menu
Generate production-ready, secure, multi-stage Dockerfile and .dockerignore for any project
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Create changelog fragment for release notes. Invoke during /prd-done workflow during the first push to the PR.
Create a release tag based on accumulated changelog fragments, then prune merged worktrees and branches. Run when ready to cut a release.
Build and publish the mock-server Docker image to GitHub Container Registry. Use when mock server fixtures or code have changed and need to be published.
Analyze the blast radius of a proposed Kubernetes operation. Accepts free-text input: kubectl commands (e.g., "kubectl delete pvc data-postgres-0 -n production"), YAML manifests, or plain-English descriptions (e.g., "what happens if I delete the postgres database?"). Returns whether the operation is safe and a detailed dependency analysis with confidence levels.
Close a PRD that is already implemented or no longer needed
Create documentation-first PRDs that guide development through user-facing content
| name | dot-ai-generate-dockerfile |
| description | Generate production-ready, secure, multi-stage Dockerfile and .dockerignore for any project |
| user-invocable | true |
Generate an optimized, secure, multi-stage Dockerfile and .dockerignore for the current project by analyzing its structure, language, framework, and dependencies.
You are helping a developer containerize their application for production deployment. Your task is to analyze the project structure and generate two files:
These are non-negotiable rules that override all other guidance.
ABSOLUTE RULE: Before adding ANY instruction, configuration, or feature to the Dockerfile, verify it by examining the actual codebase.
Required Process:
Never assume. Always verify. Ask when uncertain. Evidence-based Dockerfiles only.
Thoroughness over speed: Shallow analysis leads to broken Dockerfiles. Before generating anything:
A correct Dockerfile that took longer to generate is far better than a fast but broken one. Spend the time upfront.
REQUIREMENT: Ensure all Dockerfile instructions support multiple architectures (amd64, arm64, etc.).
Apply to:
The Dockerfile must build successfully on different CPU architectures without modification.
ABSOLUTE PROHIBITION: DO NOT add HEALTHCHECK instruction under ANY circumstances.
Why:
If you add HEALTHCHECK, you are violating the "verify everything" principle.
These are best practices to consider when generating the Dockerfile. Apply them when relevant to the project - not every practice applies to every situation:
Use this section as guidance during generation and a reference for validation.
| Practice | Description |
|---|---|
| Non-root user | Create and run as a dedicated user (UID 10001+), never run as root |
| Pin image versions | Use specific tags like node:20-alpine, never :latest |
| Official images | Prefer Docker Official Images or Verified Publishers from trusted sources |
| No secrets in image | Never embed credentials, API keys, or passwords in Dockerfile or ENV instructions |
| No sudo | Don't use sudo in containers; switch USER explicitly when root access is needed |
| Minimal packages | Only install packages that are actually required for the application |
| --no-install-recommends | Use this flag with apt-get to prevent installing optional packages |
| COPY over ADD | Always use COPY unless you specifically need ADD's tar extraction; never use ADD with URLs |
| No debugging tools | Avoid installing curl, wget, vim, netcat in production images unless required by the application |
| Clean in same layer | Remove package manager caches in the same RUN command as installation |
| Executables owned by root | Application binaries should be owned by root but executed by non-root user |
| Practice | Description |
|---|---|
| Minimal base images | Prefer alpine, slim, distroless, or scratch over full distribution images |
| Multi-stage builds | Always separate build dependencies from runtime; build stage → runtime stage |
| Match language needs | Compiled languages → distroless/scratch; Interpreted → slim/alpine with runtime |
| Derive version from project | Get language version from project files (package.json engines, go.mod, etc.) |
| Practice | Description |
|---|---|
| Layer caching | Copy dependency manifests (package.json, go.mod) before source code |
| Combine RUN commands | Chain related commands with && to reduce layers and enable cleanup |
| Explicit COPY | Never use COPY . .; explicitly copy only required files and directories |
| Order by change frequency | Place stable instructions first (base image, deps) and volatile ones last (source code) |
| Production dependencies only | Install only production dependencies, not devDependencies |
| Practice | Description |
|---|---|
| Sort arguments | Alphabetize multi-line package lists for easier maintenance and review |
| Use WORKDIR | Always use WORKDIR to change directories, never RUN cd |
| Exec form for CMD | Use JSON array format: CMD ["executable", "arg1"] for proper signal handling |
| Comment non-obvious decisions | Explain why certain choices were made, not what the command does |
| OCI labels (optional) | Add metadata labels for image management (org.opencontainers.image.*) |
Before generating anything, check if the project already has a Dockerfile.
Dockerfile in the project root (also check for variants like Dockerfile.prod).dockerignore and read it if presentThis determines whether Step 2 will generate new files or improve existing ones.
Identify the project characteristics through exploration, not pattern matching.
These are analysis goals, not lookup tables. The examples below are illustrative - apply the same analytical approach to ANY language, framework, or toolchain you encounter.
Language Detection: Explore the project to identify its programming language(s).
package.json, go.mod, requirements.txt, Cargo.toml, Gemfile, composer.json, mix.exs, build.sbt, etc.)Version Detection: Find the required language/runtime version.
.node-version, .python-version, .ruby-version, .tool-versions)Framework Detection: Identify frameworks from dependencies and project structure.
Application Type: Determine what kind of application this is by examining entry points and configuration.
Port Detection: Search for port configuration in source code and configuration files.
PORT, HTTP_PORT)Build Requirements: Identify how the project is built.
System Dependencies: Critical step - missing runtime binaries cause silent failures.
Environment Variable Detection: Critical step - missing env vars cause runtime failures.
.env.example, .env.sample, or similar files that document required variablesIf no existing Dockerfile → Generate a new multi-stage Dockerfile using the patterns below.
If existing Dockerfile found → Analyze it against the best practices and checklists below, then improve:
Use the patterns and checklists below for both generation and validation.
The examples below show structural patterns, not copy-paste templates. Adapt the pattern to whatever language, package manager, and build tool the project uses.
# Build stage - use an image with build tools for this language
FROM <language-image>:<version>-<variant> AS builder
WORKDIR /app
# PATTERN: Copy dependency manifests FIRST for layer caching
# Examples: package.json, go.mod, requirements.txt, Gemfile, Cargo.toml, pom.xml
COPY <dependency-manifest-files> ./
# PATTERN: Install dependencies, clean cache in same layer
# Use whatever package manager the project uses
RUN <install-dependencies-command> && \
<clean-cache-command>
# PATTERN: Copy only the source files needed for build
# Never use "COPY . ." - be explicit about what's needed
COPY <source-directories> ./
COPY <config-files-needed-for-build> ./
# PATTERN: Run the project's build command
RUN <build-command>
Builder stage checklist:
AS builder)COPY . .)# Runtime stage - use minimal image appropriate for the language
# Compiled languages: consider distroless, scratch, or alpine
# Interpreted languages: use slim or alpine variant with runtime only
FROM <minimal-runtime-image>:<version>
WORKDIR /app
# PATTERN: Create non-root user (syntax varies by base image)
# Alpine uses addgroup/adduser, Debian uses groupadd/useradd
RUN <create-group-command> && \
<create-user-command>
# PATTERN: Copy ONLY runtime artifacts from builder
# What you copy depends on the language:
# - Compiled: just the binary
# - Interpreted: built output + runtime dependencies + minimal config
COPY --from=builder <build-outputs> ./
COPY --from=builder <runtime-dependencies> ./
# PATTERN: Set ownership to non-root user
RUN chown -R <user>:<group> /app
# Switch to non-root user BEFORE exposing ports or setting CMD
USER <non-root-user>
# Only if port was verified during analysis
EXPOSE <port>
# PATTERN: Use exec form for proper signal handling
# The command depends on how this application runs
CMD ["<executable>", "<args>"]
Runtime stage checklist:
When system packages are required, use the package manager appropriate for your base image. The principle is always the same: install only what's needed and clean the cache in the same layer.
Common examples (adapt to your base image's package manager):
# apt-get (Debian, Ubuntu)
RUN apt-get update && \
apt-get install -y --no-install-recommends \
package1 \
package2 && \
rm -rf /var/lib/apt/lists/*
# apk (Alpine)
RUN apk add --no-cache \
package1 \
package2
# yum/dnf (RHEL, Fedora, CentOS)
RUN yum install -y \
package1 \
package2 && \
yum clean all && \
rm -rf /var/cache/yum
Package installation checklist:
If no existing .dockerignore → Generate a minimal one based on the Dockerfile.
If existing .dockerignore found → Review it against the Dockerfile's COPY commands:
Generate a MINIMAL .dockerignore file based on the Dockerfile.
Since the Dockerfile uses explicit COPY commands (not COPY . .), .dockerignore serves a limited purpose:
DO NOT exclude directories that aren't copied by your Dockerfile!
If your Dockerfile doesn't copy a directory, excluding it in .dockerignore is pointless redundancy.
~10-15 lines maximum. If your .dockerignore exceeds 20 lines, you're likely adding unnecessary exclusions.
Purpose: Verify the Dockerfile works before presenting to user. A Dockerfile isn't done until it's validated.
Build the image to verify the Dockerfile syntax and instructions are correct:
docker build -t [project-name]-validation .
Start a container to verify the application runs:
docker run -d --name [project-name]-test [project-name]-validation
sleep 5 # Allow startup time
Check container state:
docker inspect --format='{{.State.Status}}' [project-name]-test
docker inspect --format='{{.State.ExitCode}}' [project-name]-test
Expected behavior depends on application type (determined in Step 1):
If container crashed or exited unexpectedly → proceed to log analysis to understand why.
Capture and analyze container logs:
docker logs [project-name]-test 2>&1
Analyze logs using your knowledge of the project from Step 1. You know:
Use this context to determine if the logs indicate:
If logs indicate a problem → identify root cause, fix Dockerfile or .dockerignore, retry.
If hadolint is installed, run it to catch Dockerfile best practice issues:
hadolint Dockerfile
If trivy is installed, scan the built image for vulnerabilities:
trivy image --severity HIGH,CRITICAL [project-name]-validation
If any validation step fails:
Maximum 5 iterations. If still failing after 5 attempts:
Always clean up after validation, whether successful or not:
docker stop [project-name]-test 2>/dev/null || true
docker rm [project-name]-test 2>/dev/null || true
docker rmi [project-name]-validation 2>/dev/null || true
Only proceed to present the Dockerfile to user after:
Present both files to the user:
After generating, provide:
docker build -t [project-name] .docker run -p [port]:[port] [project-name]Present the improved files with a summary of changes:
Recommended next steps (the Dockerfile has already been validated):
:latest)COPY . .)&&--no-install-recommends (if apt-get used)["executable", "arg"])Do not present Dockerfile to user until all validation checks pass.
<manifest-file>. Reading it to understand the ecosystem."<language> project using <framework/tool>. The manifest indicates version <X>."<file>. Following imports to understand runtime needs."<build-tools>, runtime stage needs only <runtime-artifacts>."<binary>. This needs to be in the runtime image."Key mindset: Investigate the actual project rather than matching against templates. Every project is unique. Don't present until validated.