multi-stage-dockerfile by github

Decision brief

What it does—and where it fits

Create optimized multi-stage Dockerfiles for any language or framework

Best for

Not for

Tasks that require unconfirmed production actions or broad system permissions.
Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

Platform	Status	Evidence	What to check
Codex	Not declared	No explicit evidence	Portability before use
Claude Code	Not declared	No explicit evidence	Portability before use
Cursor	Not declared	No explicit evidence	Portability before use
Gemini CLI	Not declared	No explicit evidence	Portability before use

Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource

npx skills add https://github.com/github/awesome-copilot --skill "skills/multi-stage-dockerfile"

Safe inspection promptEditorial

Inspect the Agent Skill "multi-stage-dockerfile" from https://github.com/github/awesome-copilot/blob/9933dcad5be5caeb288cebcd370eeeb2fc2f1685/skills/multi-stage-dockerfile/SKILL.md at commit 9933dcad5be5caeb288cebcd370eeeb2fc2f1685. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

01
Multi-Stage Structure
Use a builder stage for compilation, dependency installation, and other build-time operations
Use a builder stage for compilation, dependency installation, and other build-time operationsUse a separate runtime stage that only includes what's needed to run the applicationCopy only the necessary artifacts from the builder stage to the runtime stage
02
Base Images
Start with official, minimal base images when possible
Start with official, minimal base images when possibleSpecify exact version tags to ensure reproducible builds (e.g., python:3.11-slim not just python)Consider distroless images for runtime stages where appropriate
03
Layer Optimization
Organize commands to maximize layer caching
Organize commands to maximize layer cachingPlace commands that change frequently (like code changes) after commands that change less frequently (like dependency installation)Use .dockerignore to prevent unnecessary files from being included in the build context
04
Security Practices
Avoid running containers as root - use USER instruction to specify a non-root user
Avoid running containers as root - use USER instruction to specify a non-root userRemove build tools and unnecessary packages from the final imageScan the final image for vulnerabilities

Permission review

Static risk signals and limitations

No configured static risk pattern was detected

This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial

Signal	Value	Evidence type	Meaning
Quality score	65/100	Computed	Documentation, specificity, maintenance, and trust rules
Repository stars	37,126	Source	Repository attention, not individual Skill quality
Compatibility	0 platforms	Source	Declared in the catalog source record
Usage guide	automated source guide	Editorial	Generated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository: github/awesome-copilot
Skill path: skills/multi-stage-dockerfile/SKILL.md
Commit: 9933dcad5be5caeb288cebcd370eeeb2fc2f1685
License: MIT
Collected: 2026-07-28
Default branch: main

View the original SKILL.md

Your goal is to help me create efficient multi-stage Dockerfiles that follow best practices, resulting in smaller, more secure container images.

Multi-Stage Structure

Use a builder stage for compilation, dependency installation, and other build-time operations
Use a separate runtime stage that only includes what's needed to run the application
Copy only the necessary artifacts from the builder stage to the runtime stage
Use meaningful stage names with the AS keyword (e.g., FROM node:18 AS builder)
Place stages in logical order: dependencies → build → test → runtime

Base Images

Start with official, minimal base images when possible
Specify exact version tags to ensure reproducible builds (e.g., python:3.11-slim not just python)
Consider distroless images for runtime stages where appropriate
Use Alpine-based images for smaller footprints when compatible with your application
Ensure the runtime image has the minimal necessary dependencies

Layer Optimization

Organize commands to maximize layer caching
Place commands that change frequently (like code changes) after commands that change less frequently (like dependency installation)
Use .dockerignore to prevent unnecessary files from being included in the build context
Combine related RUN commands with && to reduce layer count
Consider using COPY --chown to set permissions in one step

Security Practices

Avoid running containers as root - use USER instruction to specify a non-root user
Remove build tools and unnecessary packages from the final image
Scan the final image for vulnerabilities
Set restrictive file permissions
Use multi-stage builds to avoid including build secrets in the final image

Performance Considerations

Use build arguments for configuration that might change between environments
Leverage build cache efficiently by ordering layers from least to most frequently changing
Consider parallelization in build steps when possible
Set appropriate environment variables like NODE_ENV=production to optimize runtime behavior
Use appropriate healthchecks for the application type with the HEALTHCHECK instruction