multi-stage-dockerfile
Skill36 starsChanged 4 months agoMITView on GitHub
Create optimized multi-stage Dockerfiles for any language or framework
We split this skill into the rules it gives an agent
17 rules. 0 are common, 13 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
13
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Use a builder stage for compilation, dependency installation, and other build-time operations
- Distinctive: line 11
Use a separate runtime stage that only includes what's needed to run the application
- Very specific: line 13
Use meaningful stage names with the AS keyword (e.g., FROM node:18 AS builder)
- Distinctive: line 14
Place stages in logical order: dependencies → build → test → runtime
- Distinctive: line 18
Start with official, minimal base images when possible
- Distinctive: line 20
Consider distroless images for runtime stages where appropriate
- Distinctive: line 21
Use Alpine-based images for smaller footprints when compatible with your application
- Distinctive: line 22
Ensure the runtime image has the minimal necessary dependencies
- Distinctive: line 27
Place commands that change frequently (like code changes) after commands that change less frequently (like dependency installation)
- Very specific: line 28
Use .dockerignore to prevent unnecessary files from being included in the build context
- Very specific: line 30
Consider using COPY --chown to set permissions in one step
- Very specific: line 34
Avoid running containers as root - use USER instruction to specify a non-root user
- Distinctive: line 35
Remove build tools and unnecessary packages from the final image
- Distinctive: line 38
Use multi-stage builds to avoid including build secrets in the final image
- Distinctive: line 42
Use build arguments for configuration that might change between environments
- Distinctive: line 44
Consider parallelization in build steps when possible
- Distinctive: line 46
Use appropriate healthchecks for the application type with the HEALTHCHECK instruction
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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
ASkeyword (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-slimnot justpython) - 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
.dockerignoreto 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
USERinstruction 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
Trending
Surging: 1 new project took it in the last 4 weeks, none the 4 weeks before.thin data
Other versions11 projects use a version of this.
Word for word · 7
- github/awesome-copilot★ 41k100% same
- idexal/idexal-skills★ 2100% same
- ElyzeSolutions/skills★ 1100% same
- ragna-ai/ragna-studio★ 1100% same
- Streamlinity/claude-skills-deploy★ 1100% same
- ZeroTokenClaw/agents-skills★ 1100% same
- ReaperOAK/ForgeOS★ 0100% same
Edited · 1
- iCesofT/awesome-ai★ 173% same
Wrote their own version · 3
- kimtth/agent-skill-100-lines-or-less★ 2same name
- ldaume/agentic-engineering-harness★ 2same name
- jenreh/appkit-bpmn-server★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use playwright-best-practices, pnpm and 2 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
currents-devSkillplaywright-best-practices
Use when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, testing accessibility (axe-core), file uploads/downloads, date/time mocking, WebSockets, geolocation, permissions, multi-tab/popup flows, mobile/responsive layouts, touch gestures, GraphQL, error handling, offline mode, multi-user collaboration, third-party services (payments, email verification), console error monitoring, global setup/teardown, test annotations (skip, fixme, slow), test tags (@smoke, @fast, @critical, filtering with --grep), project dependencies, security testing (XSS, CSRF, auth), performance budgets (Web Vitals, Lighthouse), iframes, component testing, canvas/WebGL, service workers/PWA, test coverage, i18n/localization, Electron apps, or browser extension testing. Covers E2E, component, API, visual, accessibility, security, Electron, and extension testing.
Also in 3 projects that use this
JetBrainsSkillpnpm
Node.js package manager with strict dependency resolution. Use when running pnpm specific commands, configuring workspaces, or managing dependencies with catalogs, patches, or overrides.
Also in 3 projects that use this
VercelSkillweb-design-guidelines
Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
Also in 3 projects that use this
GoogleSkillimprove-codebase-architecture
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
Also in 3 projects that use this
In this repository18 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/architecture.mdcCursor rule
- .cursor/rules/conventions.mdcCursor rule
- add-middlewareSkill
- add-openapi-docsSkill
- add-testSkill
- api-design-principlesSkill
- find-skillsSkill
- improveSkill
- new-resourceSkill
- nodejs-best-practicesSkill
- prisma-client-apiSkill
- prisma-database-setupSkill
- prisma-postgresSkill
- security-auditSkill
- typescript-magicianSkill
- update-schemaSkill
- vitestSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

