pre-deploy-checklist
This Claude Code skill validates deployment readiness by systematically checking Dockerfile validity, port configuration consistency, environment variables, build commands, dependency lockfiles, Docker ignore settings, health endpoints, and database migration setup. Use it before triggering any deployment to identify and report configuration issues that commonly cause build or runtime failures.
git clone --depth 1 https://github.com/nixopus/nixopus /tmp/pre-deploy-checklist && cp -r /tmp/pre-deploy-checklist/api/skills/pre-deploy-checklist ~/.claude/skills/pre-deploy-checklistSKILL.md
# Pre-Deploy Checklist Run through this checklist before triggering any deployment. Each check uses workspace tools. Report all findings, do not stop at the first failure. ## Checklist ### 1. Dockerfile exists and is valid - Use `read_file` on the Dockerfile path - Verify it has a `FROM` directive - Verify it has an `EXPOSE` directive matching the expected port - Verify it ends with a `CMD` or `ENTRYPOINT` - If using multi-stage, verify the final stage copies the built artifacts **If Dockerfile is missing**: Use the `dockerfile-generation` skill to generate one. ### 2. Port configuration matches - Compare: Dockerfile `EXPOSE` value, app's actual listen port, any `PORT` env var, and the port configured in the Nixopus application - All must agree. Mismatched ports are a top deployment failure cause. - If using docker-compose, also check the `ports:` mapping ### 3. Required env vars are set - Run env detection (use `env-detection` skill) to find all required vars - Cross-reference with what's configured in the Nixopus application - Flag any missing required vars - Flag any vars using placeholder values (`your-api-key-here`, `change-me`, `TODO`) ### 4. Build command works - Check `package.json` `scripts.build` (or equivalent) exists - If TypeScript, check `tsconfig.json` exists and `outDir` is set - Check that the build output directory referenced in the Dockerfile matches the actual build output ### 5. Dependencies are locked - Check for a lockfile (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, `Cargo.lock`, `poetry.lock`, `go.sum`) - Using `npm install` instead of `npm ci` in a Dockerfile without a lockfile leads to inconsistent builds ### 6. .dockerignore exists - Check for `.dockerignore` file - Must include at minimum: `node_modules`, `.git`, `dist`, `.env` - Missing `.dockerignore` causes bloated build contexts and potential secret leaks ### 7. Healthcheck endpoint - For API servers: check if there's a `/health` or `/healthz` or `/api/health` endpoint - If the Dockerfile or compose file includes a `HEALTHCHECK`, verify the endpoint exists in code - Not strictly required but recommended — flag as warning if missing ### 8. Database migrations - Check if the app has a migration system (`prisma`, `typeorm`, `knex`, `alembic`, `django migrate`, `goose`) - If yes, verify the migration command is included in the deployment flow (compose `command:`, Dockerfile `CMD`, or Nixopus pre-deploy hook) - Unmigrated databases after deploy cause runtime crashes ## Result format Report as a table: | Check | Status | Details | |-------|--------|---------| | Dockerfile | PASS/FAIL/WARN | What was found or missing | | Port match | PASS/FAIL | Expected vs actual | | Env vars | PASS/FAIL | Count of missing vars | | Build command | PASS/FAIL | The command found | | Lockfile | PASS/WARN | Which lockfile, or none | | .dockerignore | PASS/WARN | Present or missing | | Healthcheck | PASS/WARN | Endpoint found or none | | Migrations | PASS/WARN/N/A | Migration tool and command | Only block deployment (report FAIL) for checks 1-4. Checks 5-8 are warnings that should be reported but don't block. ## Summary Format Report the checklist table, then: **Ready**: what looks good **Warnings**: non-critical issues **Blockers**: must fix before deploy **Recommendations**: specific fixes with code blocks
Reference for all Nixopus API operations callable via nixopus_api(method, path, body)
Generate Caddyfile configurations for static sites and reverse proxies — SPA fallback routing, cache headers, compression, redirects, and error pages. Use when deploying a static site that needs custom Caddy configuration, or when the user needs SPA routing, caching, or redirect rules.
Generate docker-compose.yml for multi-service setups including databases, caches, and service dependencies. Use when the app needs a database, cache, message broker, or has multiple independently deployable services.
Size container memory and CPU limits, diagnose OOM kills and CPU throttling, and recommend resource adjustments by ecosystem. Use when containers are being OOM-killed, running slowly, or when setting initial resource limits for a deployment.
Build and deploy C/C++ applications — CMake, Meson, Ninja, and Dockerfile patterns. Use when deploying a C or C++ project, or when CMakeLists.txt or meson.build is detected.
Run database migrations safely during deployment — framework-specific commands, pre-deploy vs post-deploy timing, health gates, and rollback strategies. Use when the app has a database migration system and needs migrations run during deployment.
Build and deploy Deno applications — version detection, dependency caching, and Dockerfile patterns. Use when deploying a Deno project, or when deno.json or deno.jsonc is detected.
Sub-agent routing table — which agent handles diagnostics, machine health, infrastructure, GitHub, billing, and notifications. Load when the current task is not a direct deployment.