/dockerfile-generator

name: dockerfile-generator
description: Create, generate, or write Dockerfiles and multi-stage Docker images. Containerize apps.

Dockerfile Generator

Overview

This skill provides a comprehensive workflow for generating production-ready Dockerfiles with security, optimization, and best practices built-in. Generates multi-stage builds, security-hardened configurations, and optimized layer structures with automatic validation and iterative error fixing.

**Key Features:**

• Multi-stage builds for optimal image size (50-85% reduction)
• Security hardening (non-root users, minimal base images, no secrets)
• Layer caching optimization for faster builds
• Language-specific templates (Node.js, Python, Go, Java)
• Automatic .dockerignore generation
• Integration with `dockerfile-validator` for validation
• Iterative validation and error fixing (minimum 1 iteration if errors found)
• Local references plus docs lookup fallback chain for framework-specific patterns

When to Use This Skill

Invoke this skill when:

• Creating new Dockerfiles from scratch
• Containerizing applications (Node.js, Python, Go, Java, or other languages)
• Implementing multi-stage builds for size optimization
• Converting existing Dockerfiles to best practices
• Generating production-ready container configurations
• Optimizing Docker builds for security and performance
• The user asks to "create", "generate", "build", or "write" a Dockerfile
• Implementing containerization for microservices
• Setting up CI/CD pipeline container builds

Trigger Phrases

Use this skill immediately when the request contains phrasing like:

• "Generate a production Dockerfile for my app"
• "Create a multi-stage Dockerfile for <language/framework>"
• "Containerize this service with security best practices"
• "Optimize this Dockerfile for size and build speed"
• "Write Dockerfile and .dockerignore for deployment"

Do NOT Use This Skill For

• Validating existing Dockerfiles (use `dockerfile-validator` instead)
• Building or running containers (use docker build/run commands)
• Debugging running containers (use docker logs, docker exec)
• Managing Docker images or registries

Deterministic Execution Model

Run these stages in order, and do not skip a stage unless the skip reason is reported in the final output.

1. Gather requirements (language, runtime version, entrypoint, exposed port, package manager, health endpoint). 2. Load references (local reference files first; external docs only when local references are insufficient). 3. Generate Dockerfile and `.dockerignore`. 4. Validate with `dockerfile-validator` or fallback local tools. 5. Iterate fixes until stop condition is met. 6. Publish final artifacts plus validation/audit report.

Stop conditions for stage 5:

• Stop when there are zero validation errors and no unapproved warnings.
• Stop after 3 iterations maximum, then emit an intentional-deviation report for unresolved findings.

Reference Path Map

Consult these files directly by path as needed:

• `references/security_best_practices.md` for non-root users, secret handling, base image hardening, vulnerability scanning.
• `references/optimization_patterns.md` for multi-stage strategy, cache optimization, layer reduction, BuildKit cache mounts.
• `references/language_specific_guides.md` for language/framework runtime and package-manager patterns.
• `references/multistage_builds.md` for advanced stage-splitting and artifact-copy patterns.

Dockerfile Generation Workflow

Follow this workflow when generating Dockerfiles. Adapt based on user needs:

Stage 1: Gather Requirements

**Objective:** Understand what needs to be containerized and gather all necessary information.

**Information to Collect:**

1. **Application Details:**

• Programming language and version (Node.js 18/20, Python 3.11/3.12, Go 1.21+, Java 17/21, etc.)
• Application type (web server, API, CLI tool, batch job, etc.)
• Framework (Express, FastAPI, Spring Boot, etc.)
• Entry point (main file, command to run)

2. **Dependencies:**

• Package manager (npm/yarn/pnpm, pip/poetry, go mod, maven/gradle)
• System dependencies (build tools, libraries, etc.)
• Build-time vs runtime dependencies

3. **Application Configuration:**

• Port(s) to expose
• Environment variables needed
• Configuration files
• Health check endpoint (for web services)
• Volume mounts (if any)

4. **Build Requirements:**

• Build commands
• Test commands (optional)
• Compilation needs (for compiled languages)
• Static asset generation

5. **Production Requirements:**

• Expected image size constraints
• Security requirements
• Scaling needs
• Resource constraints (CPU, memory)

**Use AskUserQuestion if information is missing or unclear.**

**Example Questions:**

- What programming language and version is your application using?
- What is the main entry point to run your application?
- Does your application expose any ports? If so, which ones?
- Do you need any system dependencies beyond the base language runtime?
- Does your application need a health check endpoint?

Stage 2: Framework/Library Documentation Lookup (if needed)

**Objective:** Research framework-specific containerization patterns and best practices.

**When to Perform This Stage:**

• User mentions a specific framework (Next.js, Django, FastAPI, Spring Boot, etc.)
• Application has complex build requirements
• Need guidance on framework-specific optimization

**Research Process (strict fallback chain):**

1. **Read local references first (required):**

• `references/security_best_practices.md`
• `references/optimization_patterns.md`
• `references/language_specific_guides.md`

2. **Use Context7 docs lookup when local references are insufficient (preferred external source):**

   Use mcp__context7__resolve-library-id with the framework name
   Then use mcp__context7__query-docs with query:
   "docker deployment production build"