agentleFS
KhaledSaeed18KhaledSaeed18/node-express-boilerplate/.agents/skills/multi-stage-dockerfile/SKILL.md

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
  1. Distinctive:

    Use a builder stage for compilation, dependency installation, and other build-time operations

    line 10
  2. Distinctive:

    Use a separate runtime stage that only includes what's needed to run the application

    line 11
  3. Very specific:

    Use meaningful stage names with the AS keyword (e.g., FROM node:18 AS builder)

    line 13
  4. Distinctive:

    Place stages in logical order: dependencies → build → test → runtime

    line 14
  5. Distinctive:

    Start with official, minimal base images when possible

    line 18
  6. Distinctive:

    Consider distroless images for runtime stages where appropriate

    line 20
  7. Distinctive:

    Use Alpine-based images for smaller footprints when compatible with your application

    line 21
  8. Distinctive:

    Ensure the runtime image has the minimal necessary dependencies

    line 22
  9. Distinctive:

    Place commands that change frequently (like code changes) after commands that change less frequently (like dependency installation)

    line 27
  10. Very specific:

    Use .dockerignore to prevent unnecessary files from being included in the build context

    line 28
  11. Very specific:

    Consider using COPY --chown to set permissions in one step

    line 30
  12. Very specific:

    Avoid running containers as root - use USER instruction to specify a non-root user

    line 34
  13. Distinctive:

    Remove build tools and unnecessary packages from the final image

    line 35
  14. Distinctive:

    Use multi-stage builds to avoid including build secrets in the final image

    line 38
  15. Distinctive:

    Use build arguments for configuration that might change between environments

    line 42
  16. Distinctive:

    Consider parallelization in build steps when possible

    line 44
  17. Distinctive:

    Use appropriate healthchecks for the application type with the HEALTHCHECK instruction

    line 46

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
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

Download now (ZIP)

Trending

Surging: 1 new project took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Aug 30: 0 new projectsWeek of Sep 6: 0 new projectsWeek of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 1 new projectWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projects
Aug 2026Sep 2026Oct 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 1 in all, so this is a hint, not a trend.
  • Other versions11 projects use a version of this.

    Word for word · 7

    1. github/awesome-copilot★ 41k100% same
    2. idexal/idexal-skills★ 2100% same
    3. ElyzeSolutions/skills★ 1100% same
    4. ragna-ai/ragna-studio★ 1100% same
    5. Streamlinity/claude-skills-deploy★ 1100% same
    6. ZeroTokenClaw/agents-skills★ 1100% same
    7. ReaperOAK/ForgeOS★ 0100% same

    Edited · 1

    1. iCesofT/awesome-ai★ 173% same

    Wrote their own version · 3

    1. kimtth/agent-skill-100-lines-or-less★ 2same name
    2. ldaume/agentic-engineering-harness★ 2same name
    3. 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-devSkill

      playwright-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

    • JetBrainsSkill

      pnpm

      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

    • VercelSkill

      web-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

    • GoogleSkill

      improve-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.

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.