scaffold-docker
Generate production-grade Docker configuration with multi-stage builds and health check module
Best use case
scaffold-docker is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Generate production-grade Docker configuration with multi-stage builds and health check module
Teams using scaffold-docker should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/scaffold-docker/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How scaffold-docker Compares
| Feature / Agent | scaffold-docker | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Generate production-grade Docker configuration with multi-stage builds and health check module
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Scaffold Docker & Health Checks
You are setting up production-grade containerization for a mission-critical TypeScript project. This skill generates a hardened Dockerfile, health check module, and Docker Compose configuration.
## Available Components
| Key | Component | Description |
|-----|-----------|-------------|
| `dockerfile` | Dockerfile + .dockerignore | Multi-stage build with security hardening |
| `health-checks` | Health Check Module | `src/health/` module with liveness, readiness, and startup probes |
| `compose` | Docker Compose | Development and production compose files |
## Instructions
### 1. Determine components
If `$ARGUMENTS` is provided, parse it as a comma-separated list. Otherwise, ask the user which components to set up. Default: `all`.
### 2. Load context
- Read `package.json` for project name, main entry point, scripts
- Read `tsconfig.json` for `outDir` (default: `dist/`)
- Check if `src/index.ts` or `src/main.ts` exists (application entry point)
- Check for existing `Dockerfile`, `docker-compose.yml`, `src/health/`
---
## Component: `dockerfile` — Dockerfile + .dockerignore
Ask the user which base image they prefer for the production stage:
- **`node:22-slim`** (recommended for most cases) — smaller than full image, includes shell for debugging
- **`gcr.io/distroless/nodejs22-debian12`** — no shell, no package manager, minimal attack surface (best for production)
### Generate `Dockerfile`:
```dockerfile
# =============================================================================
# Build Stage
# =============================================================================
FROM node:22-slim AS builder
WORKDIR /app
# Copy dependency files first for layer caching
COPY package.json package-lock.json ./
# Use npm ci for reproducible installs (Rule 3.4)
RUN npm ci
# Copy source and build
COPY tsconfig.json ./
COPY src/ ./src/
RUN npm run build
# Prune dev dependencies
RUN npm ci --omit=dev
# =============================================================================
# Production Stage
# =============================================================================
FROM <chosen-base-image> AS production
# Security: run as non-root user
USER node
WORKDIR /app
# Copy only production artifacts
COPY --from=builder --chown=node:node /app/dist ./dist
COPY --from=builder --chown=node:node /app/node_modules ./node_modules
COPY --from=builder --chown=node:node /app/package.json ./
# Environment
ENV NODE_ENV=production
# Health check (adjust port and path as needed)
HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
CMD ["node", "-e", "fetch('http://localhost:3000/healthz').then(r => process.exit(r.ok ? 0 : 1)).catch(() => process.exit(1))"]
EXPOSE 3000
# Use node directly (not npm start) for proper signal handling
CMD ["node", "dist/index.js"]
```
If the user chose distroless:
- Remove `HEALTHCHECK` (no shell available; rely on Kubernetes probes)
- `CMD` uses JSON array format only
- No `USER` directive needed (distroless defaults to non-root)
If the user chose slim:
- Add `dumb-init` for PID 1 signal handling:
```dockerfile
RUN apt-get update && apt-get install -y --no-install-recommends dumb-init && rm -rf /var/lib/apt/lists/*
ENTRYPOINT ["dumb-init", "--"]
```
### Generate `.dockerignore`:
```
# Source and tests (built artifacts are in dist/)
src/
tests/
**/*.test.ts
**/*.spec.ts
# Documentation
docs/
*.md
!README.md
# Development
.git/
.github/
.claude/
.vscode/
.idea/
coverage/
.stryker-tmp/
reports/
# Environment and secrets
.env
.env.*
*.pem
*.key
# Build tools
stryker.config.*
vitest.config.*
tsconfig.json
.eslintrc*
eslint.config.*
commitlint.config.*
.husky/
# OS files
.DS_Store
Thumbs.db
# Dependencies (rebuilt in Docker)
node_modules/
```
### Add npm scripts:
```json
{
"docker:build": "docker build -t <project-name> .",
"docker:run": "docker run -p 3000:3000 <project-name>"
}
```
### Suggest Trivy scanning:
```bash
# Scan the built image for vulnerabilities
trivy image --severity HIGH,CRITICAL --exit-code 1 <project-name>
```
---
## Component: `health-checks` — Health Check Module
Generate a health check module under `src/health/` following the project's coding standard (Result pattern, Zod schemas, branded types, readonly, TSDoc).
### `src/health/schema.ts`:
- Zod schema for health check responses
- Status type using `as const` object (not enum — Rule 3.5):
```typescript
const HealthStatus = {
HEALTHY: 'HEALTHY',
DEGRADED: 'DEGRADED',
UNHEALTHY: 'UNHEALTHY',
} as const;
type HealthStatusValue = typeof HealthStatus[keyof typeof HealthStatus];
```
- Response types for liveness, readiness (with per-component status), and startup
- All properties `readonly` (Rule 7.1)
- Exhaustive switch with `assertUnreachable` (Rule 8.3)
### `src/health/health.ts`:
- **`checkLiveness()`**: Returns `Result<LivenessResponse>`. Checks:
- Process is running
- Event loop is responsive (measure event loop lag)
- Does NOT check downstream dependencies (liveness should not trigger restarts due to external failures)
- **`checkReadiness(options)`**: Returns `Promise<Result<ReadinessResponse>>`. Checks each dependency:
- Accept a `ReadonlyArray<HealthDependency>` (dependency name + check function)
- Each check has an individual timeout using `AbortController` + `Promise.race` (Rule 4.2)
- Default timeout: 5 seconds per dependency
- Returns per-component status with overall status
- Bounded parallelism: check dependencies concurrently but with a limit (Rule 4.3)
- **`checkStartup()`**: Returns `Result<StartupResponse>`. Validates initialization prerequisites.
- All functions <= 40 lines (Rule 8.4), use Result pattern (Rule 6.2), have TSDoc (Rule 10.1)
### `src/health/health.test.ts`:
- Unit tests for all three health check functions
- Tests for: all healthy, one degraded, one unhealthy, timeout scenario, all down
- Property-based test with fast-check for dependency check arrays
- No `any` in tests
### `src/health/index.ts`:
- Barrel export of public types and functions
### Kubernetes probe configuration:
Generate a `docs/kubernetes-probes.yaml` reference:
```yaml
livenessProbe:
httpGet:
path: /livez
port: 3000
initialDelaySeconds: 30
periodSeconds: 15
failureThreshold: 3
timeoutSeconds: 5
readinessProbe:
httpGet:
path: /readyz
port: 3000
initialDelaySeconds: 10
periodSeconds: 10
failureThreshold: 3
timeoutSeconds: 5
startupProbe:
httpGet:
path: /healthz
port: 3000
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 30
timeoutSeconds: 5
```
### Integration guidance:
Show how to wire the health module into common frameworks:
- Plain `http.createServer`: route handler example
- Express: `app.get('/healthz', ...)` example
- Fastify: route example
---
## Component: `compose` — Docker Compose
### Generate `docker-compose.yml` for development:
```yaml
services:
app:
build:
context: .
target: builder # Use build stage for development
ports:
- "3000:3000"
- "9229:9229" # Node.js debugger
volumes:
- ./src:/app/src
- ./dist:/app/dist
environment:
- NODE_ENV=development
- LOG_LEVEL=debug
command: npm run dev
# Add dependencies as needed:
# depends_on:
# - postgres
# - redis
```
### If the user has databases or caches:
Ask which services to include and add them:
- PostgreSQL: with health check, volume for persistence
- Redis: with health check, memory limits
- MongoDB: with health check, volume
### Generate `docker-compose.prod.yml` (production overrides):
```yaml
services:
app:
build:
context: .
target: production
restart: unless-stopped
environment:
- NODE_ENV=production
deploy:
resources:
limits:
memory: 512M
```
---
## Summary
After generating all selected components:
1. List all created files
2. Note the Kubernetes probe configuration if health checks were generated
3. Remind the user to:
- Run `docker build` to verify the Dockerfile works
- Run Trivy scan on the built image
- Wire health check endpoints into their HTTP server
- Add `src/health/` to the parent barrel export if applicableRelated Skills
sovereign-docker-wizard
Docker optimization expert. Analyzes Dockerfiles for security and performance, generates multi-stage builds, optimizes image size, creates docker-compose configs, and identifies container misconfigurations.
project-scaffolding
Project type detection matrix, template recommendations per project type, post-scaffolding checklist, Harness integration patterns, and testing recommendations
production-dockerfile
Generate production-ready Dockerfiles with multi-stage builds, security best practices, and optimization. Use when containerizing Python applications for production deployment.
ln-731-docker-generator
Generates Docker and docker-compose configuration for multi-container development
helm-chart-scaffolding
Design, organize, and manage Helm charts for templating and packaging Kubernetes applications with reusable configurations. Use when creating Helm charts, packaging Kubernetes applications, or implementing templated deployments.
featbit-deployment-docker
Expert guidance for deploying FeatBit with Docker Compose across three tiers - Standalone (PostgreSQL only), Standard (PostgreSQL/MongoDB + Redis), and Professional (+ ClickHouse + Kafka). Use when user mentions "docker-compose", "deploy with Docker", "standalone vs standard vs pro", works with docker-compose.yml files, or asks about container configuration, environment variables, or production Docker setup.
dockerfile-optimization
Optimize Dockerfiles for smaller images, faster builds, better caching, and security. Use this skill when writing, reviewing, or debugging Dockerfiles.
Docker Hub Automation
Automate Docker Hub tasks via Rube MCP (Composio): repositories, images, tags, and container registry management. Always search tools first for current schemas.
docker
Docker y Compose. Proyecto usa este skill; contenido canónico en .ai-system.
docker-workflow
Comprehensive Docker containerization workflow covering multi-stage builds, docker-compose orchestration, image optimization, debugging, and production best practices. Use when containerizing applications, setting up development environments, or deploying with Docker.
docker-vigil-orchestration
Docker Compose orchestration for Vigil Guard v2.0.0 microservices (11 services). Use when deploying services, managing containers, troubleshooting Docker network issues, working with vigil-net, configuring docker-compose.yml, handling service dependencies, or working with 3-branch detection services (heuristics, semantic, prompt-guard).
docker-to-k8s-manifests
Automatically generate optimized Kubernetes deployment manifests from Dockerfile and docker-compose configurations with proper resource limits and health checks.