Docker Image Builder Skill

You've now written Dockerfiles for the Task API through six lessons. Each time, you made similar decisions: base image selection, dependency strategy, layer optimization, security posture. What if you could encode this reasoning so AI can apply it consistently to ANY project?

That's what skills do. A skill captures domain expertise in a format that AI can apply reliably across contexts. Instead of re-explaining your Docker preferences every time, you encode them once. The AI then reasons through your principles for each new project, producing Dockerfiles that match your production standards.

This lesson teaches you to transform your Docker knowledge into a reusable skill. You'll learn the Persona + Questions + Principles pattern that makes skills effective, create a complete SKILL.md file, and test it against projects you haven't seen before.

---

What Makes a Pattern Worth Encoding

Not every workflow deserves a skill. Creating skills takes effort. You need to identify patterns that justify that investment.

Three criteria determine if a pattern is worth encoding:

Docker containerization meets all three. You containerize services repeatedly, each Dockerfile involves 8-10 decisions, and faster containerization accelerates deployment across all projects.

Patterns that DON'T justify skills:

• One-off configuration (single project setup)
• Simple commands (docker build, docker run)
• Trivial decisions (choosing between two obvious options)

Exercise: Before continuing, list three patterns from your own work that might justify skills. Apply the three criteria to each.

---

The Persona + Questions + Principles Pattern

Effective skills follow a consistent structure. Each component serves a specific purpose:

Persona: The Cognitive Stance

A persona establishes HOW the AI should think. It's not "you are an expert"—that's too vague. A good persona specifies the perspective and priorities that produce right thinking.

Weak persona:

Strong persona:

The strong persona tells the AI:

• Domain: DevOps engineering
• Target: Production Kubernetes
• Priorities: Size, speed, security, simplicity
• Tradeoff resolution: Favor runtime over build-time

Analysis Questions: Context-Specific Reasoning

Analysis questions force the AI to gather context before acting. Without them, AI produces generic solutions. With them, AI reasons about YOUR specific situation.

Generic approach (no questions):

Context-aware approach (with questions):

Each question targets a decision point. The answers shape the Dockerfile.

Principles: Non-Negotiable Decisions

Principles are rules that apply regardless of context. They encode your hard-won lessons about what works in production.

Docker containerization principles:

1. Multi-Stage Always: Separate build dependencies from runtime
2. UV for Speed: Use UV package manager (10-100x faster than pip)
3. Alpine Default: Start with alpine, fall back to slim if compatibility issues
4. Health Checks Mandatory: Every production container needs HEALTHCHECK
5. Non-Root Default: Run as non-root user unless explicitly required otherwise
6. Environment Configuration: All configuration via environment variables
7. No Secrets in Image: Never COPY .env or credentials into image

These aren't suggestions. They're non-negotiables that every Dockerfile should follow unless there's explicit justification to deviate.

---

Designing the Production Dockerfile Skill

Let's build the complete skill, component by component.

Skill Persona

Analysis Questions

Principles

Package Management

P4: UV for Python Always use UV package manager for Python. It's 10-100x faster than pip:

P5: Lock Files Required Use requirements.txt with pinned versions or uv.lock for reproducibility. Never install without version constraints in production.

Base Images

P6: Alpine Default Start with python:3.12-alpine (50MB). Fall back to slim (150MB) only if alpine causes compatibility issues with specific packages.

P7: Pin Versions Use python:3.12-alpine, not python:alpine. Explicit versions prevent surprise breakage when base images update.

Security

P8: Non-Root User Create and switch to non-root user:

P9: No Secrets in Image Never COPY .env, credentials, or API keys. Inject via environment at runtime. Use Docker secrets or Kubernetes secrets for sensitive data.

P10: Minimal Installed Packages Only install what runtime needs. Build tools stay in build stage.

Runtime Configuration

P11: Health Checks Mandatory Every production container needs HEALTHCHECK:

P12: Environment Variables for Configuration All configuration via ENV. No hardcoded values in Dockerfile.

Large Files

P13: Volume Mount, Don't COPY Files >100MB (models, datasets) should be volume-mounted at runtime:

Never embed large files in the image.

---```markdown

name: production-dockerfile description: Generate production-ready Dockerfiles with multi-stage builds, security best practices, and optimization. Use when containerizing Python applications for Kubernetes or Docker deployments. allowed-tools: Read, Write, Edit, Bash

Production Dockerfile Skill

Persona

Think like a DevOps engineer who optimizes container images for production Kubernetes deployments. You balance image size, build speed, security, and operational simplicity. When tradeoffs exist:

• Security trumps convenience
• Runtime size trumps build speed
• Operational clarity trumps clever optimization

Analysis Questions

Before generating a Dockerfile, analyze the project:

1. Deployment Target: Kubernetes, Docker Compose, or bare Docker?
2. Base Image Strategy: Security constraints? Required system libraries?
3. Dependency Installation: Python (UV)? Node (npm ci)? Mixed?
4. Large Files: Model files >100MB to volume-mount?
5. Security Requirements: Non-root user? Read-only filesystem?
6. Health Monitoring: Health endpoint? Startup time?
7. Build Context: What should .dockerignore exclude?

Principles

Build Structure

• Multi-Stage Always: Separate build and runtime stages
• Layer Order: Dependency files first, then source
• Combine RUN: Related operations in single RUN

Package Management

• UV for Python: 10-100x faster than pip
• Lock Files: Pinned versions for reproducibility

Base Images

• Alpine Default: Start with alpine, fall back to slim
• Pin Versions: Explicit tags, not :latest

Security

• Non-Root User: Always create and switch to appuser
• No Secrets: Environment injection at runtime only
• Minimal Packages: Only runtime dependencies

Runtime

• Health Checks: Every container needs HEALTHCHECK
• Environment Config: All settings via ENV

Large Files

• Volume Mount: Files >100MB via volumes, not COPY

Output Format

When generating Dockerfiles, produce:

1. Dockerfile with comments explaining each decision
2. .dockerignore excluding build artifacts and secrets
3. docker-compose.yaml (if multi-service or volume mounts needed)
4. Size estimate comparing to naive approach

Activation

Use this skill when:

• Containerizing a new Python service
• Optimizing an existing Dockerfile
• Reviewing containerization for security issues
• Setting up Docker-based CI/CD pipelines

Wrong: Only works for FastAPIname: fastapi-dockerfile

Right: Works for any Python servicename: production-dockerfile

Wrong: No guidance on prioritiesThink like a Docker expert.

Right: Clear priorities and tradeoffsThink like a DevOps engineer who prioritizes size over build speed...

Wrong: Rule without reasonAlways use alpine.

Right: Principle with justificationAlpine Default: Start with alpine (50MB) for minimal size.Fall back to slim only if compatibility issues arise.