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".
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
O comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.
Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.
Explorador de arquivos
29 arquivos
Exibindo SKILL.md
SKILL.md
Instruções da origem · Visualização somente leitura
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 , , or ; the existing four-phase Deep Analysis → Generate → Build & Fix → Runtime Validation workflow remains the domain extension below.
success
stopped
error
Progressive Disclosure
Load modules/analyze.md, modules/generate.md, and modules/build-fix.md one level deep when their phase is reached. Load knowledge/templates only from those owned branches and retain the existing error-pattern routing.
Output, Stop, and Error States
success: source/provenance, named packaging files, successful image/build identity, migration/database proof, HTTP/health response, quiet runtime logs, verification evidence, and redaction result.
stopped: unresolved analysis, missing precondition, replacement or installation decision, or unavailable runtime input with observed evidence, redaction result, and safe next action; no partial acceptance claim.
error: failed build, migration, HTTP, health, or log step with its artifact, sanitized diagnostic, redaction result, and recovery action.
Handoffs
Send the complete typed handoff below for direct packaging requests. Deploy must preserve its own eligibility and Runtime Truth gates.
Use the runtime validation commands in this entry, node --check for changed helpers, and baseline cases dockerfile-positive-build-runtime and dockerfile-violating-build-only. Verify actual container behavior, migrations, HTTP, logs, file scope, and redaction.
Packaging Result Contract
Keep the result request-scoped and repository-relative. A build artifact does not
become a successful handoff until the runtime result is accepted.
success requires the Dockerfile and build result plus the applicable migration,
HTTP/health, and runtime-log checks. The result never contains passwords, tokens,
environment values, database URLs, or complete connection strings.
Overview
This skill generates production-ready Dockerfiles through a 4-phase process:
Deep Analysis - Understand project structure, workspace, migrations, and build complexity
Generate - Create Dockerfile with migration handling and build optimization
Build & Fix - Validate through actual build, fix errors iteratively
1. Database migrations not running - MOST CRITICAL
Symptom: relation "users" does not exist at runtime
Cause: Migrations detected but never executed
Prevention: Analysis phase Step 12 detects migrations and configures execution
Fix:
For Standalone + ORM: Install ORM deps separately
Add runtime migration to entrypoint script
Verify with psql -c "\dt" after container starts
2. Out of Memory during build
Symptom: Exit code 137, Killed, heap out of memory
Cause: Build script includes lint/type-check for 39+ workspace packages
Prevention: Analysis phase Step 13 detects heavy operations
Fix: Skip CI tasks in Docker build, increase NODE_OPTIONS to 8192MB
3. Workspace files not found
Symptom: ENOENT: no such file or directory, open '/app/e2e/package.json'Cause: .dockerignore excludes workspace package.json files
Fix: Use e2e/* instead of e2e, then !e2e/package.json
4. lockfile=false projects
Symptom: Cannot generate lockfile because lockfile is set to falseCause: Project has lockfile=false in .npmrc
Fix: Use pnpm install instead of pnpm install --frozen-lockfile
5. Build-time env vars missing
Symptom: KEY_VAULTS_SECRET is not setCause: Next.js SSG needs env vars at build time
Fix: Add ARG/ENV placeholders in build stage
6. Node binary path
Symptom: spawn /bin/node ENOENTCause: Scripts hardcode /bin/node but node:slim has it at /usr/local/bin/nodeFix: Add RUN ln -sf /usr/local/bin/node /bin/node
7. ORM not found in Standalone mode
Symptom: Cannot find module 'drizzle-orm' at runtime
Cause: Next.js standalone doesn't include all node_modules
Prevention: Analysis phase detects standalone + ORM combination
Fix: Install ORM separately in /deps and copy to final image
8. Wrong build command for monorepo with custom CLI
Symptom: Build succeeds but output files missing (e.g., assets-manifest.json not found)
Cause: Using yarn workspace @scope/pkg build instead of detected custom CLI syntax
Prevention: Analysis phase Step 14 detects custom CLI
Fix: Use detected CLI syntax for all build commands
9. Git hash required but .git not in Docker context
Symptom: Failed to open git repo or nodegit errors
Cause: Build tool requires git commit hash for versioning
Prevention: Analysis phase Step 14 detects git hash dependency
Fix: Set ENV GITHUB_SHA=docker-build to bypass git requirement
Symptom: ENOENT: no such file or directory, open '/app/static/assets-manifest.json'Cause: Frontend builds to different path than backend expects
Prevention: Analysis phase Step 14 detects static asset path mapping
Fix: Copy frontend outputs to backend's expected path in Dockerfile
Success Criteria
A successful Dockerfile must:
Build Phase:
Build without errors (docker buildx build exits 0)
Image size reasonable (< 2GB for most apps)
Follow production best practices (multi-stage, non-root, fixed versions)
Include all necessary supporting files (.dockerignore, docker-compose.yml, etc.)
Handle all workspace/monorepo requirements
Runtime Phase - CRITICAL:
6. Container starts successfully (no crashes)
7. Database migrations execute successfully (if migrations detected)
8. Database tables created (verify with psql)
9. Application responds with valid HTTP codes (200/302/401, not 500)
10. No runtime errors in logs (no "relation does not exist", etc.)
DO NOT declare success if:
Build passes but runtime fails
Migrations detected but tables missing
App returns 500 errors
Logs show database relation errors
Post-Build Validation COMPREHENSIVE
After successful build, perform FULL validation:
# 1. Start services
docker-compose up -d
sleep 30 # Wait for startup# 2. Check container status
docker-compose ps
# Expected: All containers UP and HEALTHY# 3. Verify database migrationsif [ migrations_detected ]; then# List tables
docker-compose exec postgres psql -U <user> -d <db> -c "\dt"# Expected: List of tables (users, sessions, etc.)# If "Did not find any relations" → FAIL# Count migrations
MIGRATION_COUNT=$(docker-compose exec postgres psql -U <user> -d <db> -t -c "SELECT COUNT(*) FROM <migration_table>;")
# Expected: Matches analysis count (e.g., 76)fi# 4. Test application health
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:3210)
# Expected: 200, 302, or 401# Unacceptable: 500, 502, 503if [ "$HTTP_CODE" = "500" ]; thenecho"FAILURE: App returning 500 error"
docker-compose logs app
exit 1
fi# 5. Check for errors in logs
docker-compose logs app | grep -i "error" | tail -20
# Should NOT contain:# - "relation does not exist"# - "table not found"# - "Cannot find module"# 6. Check image size
docker images <image-name>
# 7. Cleanup (if needed)
docker-compose down
