AI Skills
dockerfile-skill

dockerfile-skill

Generate production-ready Dockerfile for any GitHub project. Supports monorepo, multi-stage builds, workspace detection, and iterative build-fix cycles. Use when user asks to create, generate, write, fix, or improve a Dockerfile, wants to containerize an application, mentions Docker build issues, needs a .dockerignore, or wants to package their app as a Docker image. Also triggers on \"/dockerfile\".

80stars
20forks
Updated 9/28/2026
Get SkillSource Code

Related Skills

chief-ai-officer-advisor27Kcmux-backend25Kcontext-mode20K
SKILL.md
read-only
name
dockerfile-skill
description

Generate production-ready Dockerfile for any GitHub project. Supports monorepo, multi-stage builds, workspace detection, and iterative build-fix cycles. Use when user asks to create, generate, write, fix, or improve a Dockerfile, wants to containerize an application, mentions Docker build issues, needs a .dockerignore, or wants to package their app as a Docker image. Also triggers on \"/dockerfile\".

Dockerfile Generator Skill

Identity and Discovery

  • Owner: dockerfile-skill (/dockerfile and Dockerfile, containerize, build-fix, or Docker build requests).

  • Class: local-artifact-mutation with a validated packaging handoff to sealos-deploy.

  • Canaries: DFS-RUNTIME-ACCEPT, DFS-OWNED-FILES, and DFS-REDACT.

Scope and Boundaries

Accept a local path or GitHub URL, optionally with a readiness report from cloud-native-readiness. Analyze and write only the named packaging artifacts (Dockerfile, .dockerignore, optional compose/entrypoint/docs and deploy-side build evidence); preserve pre-existing files and project values by default. A replacement requires an explicit request decision recorded before mutation. Build, migration, HTTP, and log validation remain required before a result is accepted.

Risk and Confirmation

Keep generated secrets, environment values, database URLs, and connection details out of reports. A required package or system-tool installation follows the current project confirmation boundary. Never treat a successful docker build as runtime acceptance; the DFS-RUNTIME-ACCEPT canary requires migration/table, HTTP, health, and log evidence.

Lifecycle Workflow

For each request, analyze the project, generate owned packaging, run the closed-loop build/fix phase, and run runtime validation. Emit request-scoped success, stopped, or error; the existing four-phase Deep Analysis → Generate → Build & Fix → Runtime Validation workflow remains the domain extension below.