From mad-skills
Generate container-based release pipelines that build once and promote immutable artifacts through environments (dev → staging → prod). Detects your stack, interviews for infrastructure choices, then outputs deterministic CI/CD files (Dockerfile, workflows, deployment manifests) that run without an LLM. Use when setting up deployment pipelines, containerizing an app, creating release workflows, or connecting CI to container-friendly infrastructure (Azure Container Apps, AWS Fargate, Google Cloud Run, Kubernetes, Dokku, Coolify, CapRover, etc.).
npx claudepluginhub slamb2k/mad-skills --plugin mad-skillsThis skill is limited to using the following tools:
When this skill is invoked, IMMEDIATELY output the banner below before doing anything else.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
When this skill is invoked, IMMEDIATELY output the banner below before doing anything else. Pick ONE tagline at random — vary your choice each time. CRITICAL: Reproduce the banner EXACTLY character-for-character. The first line of the art has 4 leading spaces — you MUST preserve them.
{tagline}
⠀ ██╗██████╗ ██████╗ ██████╗██╗ ██╗
██╔╝██╔══██╗██╔═══██╗██╔════╝██║ ██╔╝
██╔╝ ██║ ██║██║ ██║██║ █████╔╝
██╔╝ ██║ ██║██║ ██║██║ ██╔═██╗
██╔╝ ██████╔╝╚██████╔╝╚██████╗██║ ██╗
╚═╝ ╚═════╝ ╚═════╝ ╚═════╝╚═╝ ╚═╝
Taglines:
Generate container-based release pipelines following the build-once, promote-everywhere philosophy. Every artifact is built exactly once, tested, tagged with git SHA + semver, pushed to a registry, and promoted through environments without rebuilding.
All generated files are deterministic — no LLM required at runtime.
Parse optional flags from the request:
--registry-only: Only generate Dockerfile, .dockerignore, and registry config (skip deployment)--skip-interview: Use detected defaults without interactive prompts--dry-run: Show what would be generated without writing filesAfter the banner, display parsed input:
┌─ Input ────────────────────────────────────────
│ {Field}: {value}
│ Flags: {parsed flags or "none"}
└────────────────────────────────────────────────
Pre-flight results:
── Pre-flight ───────────────────────────────────
✅ {dep} {version or "found"}
⚠️ {dep} not found → {fallback detail}
❌ {dep} missing → stopping
──────────────────────────────────────────────────
Stage/phase headers: ━━ {N} · {Name} ━━━━━━━━━━━━━━━━━━━━━━━━━
Status icons: ✅ done · ❌ failed · ⚠️ degraded · ⏳ working · ⏭️ skipped
Detect the hosting platform before pre-flight so dependency checks are platform-specific:
REMOTE_URL=$(git remote get-url origin 2>/dev/null)
if echo "$REMOTE_URL" | grep -qiE 'dev\.azure\.com|visualstudio\.com'; then
PLATFORM="azdo"
elif echo "$REMOTE_URL" | grep -qi 'github\.com'; then
PLATFORM="github"
else
PLATFORM="github" # default fallback
fi
Pass {PLATFORM} into all phase prompts. Each phase uses the appropriate
CLI tool and registry defaults based on the detected platform.
Before starting, check dependencies:
| Dependency | Type | Check | Required | Resolution | Detail |
|---|---|---|---|---|---|
| docker | cli | docker --version | no | ask | Needed for local build verification; skip verify phase if absent |
| git | cli | git --version | yes | stop | Install from https://git-scm.com |
| sync | skill | ls .claude/skills/sync/SKILL.md ~/.claude/skills/sync/SKILL.md ~/.claude/plugins/marketplaces/slamb2k/skills/sync/SKILL.md 2>/dev/null | no | fallback | Repo sync; falls back to manual git pull |
| az devops | cli | az devops -h 2>/dev/null | no | fallback | Falls back to REST API with PAT; see AzDO tooling below |
Platform-conditional rules:
az devops: Only checked when PLATFORM == azdo. Skip for GitHub repos.For each applicable row, in order:
{PLATFORM}When PLATFORM == azdo, follow the shared AzDO platform guide
(repo root: references/azdo-platform.md) for tooling detection (AZDO_MODE)
and configuration validation (AZDO_ORG, AZDO_PROJECT).
Pass these variables into all phase prompts alongside {PLATFORM}.
Invoke /sync to ensure the working tree is up to date with origin/main before
scanning. If /sync is unavailable, run git pull manually. This prevents
generating pipelines against stale code.
Launch an Explore subagent to scan the codebase and produce a DETECTION_REPORT.
Task(
subagent_type: "Explore",
description: "Detect stack and existing infrastructure",
prompt: <read from references/interview-guide.md#detection-prompt>
)
The detection prompt scans for:
Parse DETECTION_REPORT. This feeds into the interview phase.
Present the detection results to the user and fill in gaps through guided questions.
Read the full interview flow from references/interview-guide.md#interview-questions.
The interview covers these topics in order. Skip questions where detection already provided a confident answer (but confirm with the user).
Confirm detected language, framework, and entry point. Ask only if detection was ambiguous (e.g., monorepo with multiple stacks).
Detect from existing CI config or ask:
Ask how many deployment stages and the promotion model:
For each environment, ask the deployment target:
Different environments can use different targets (e.g., dev=Dokku, prod=Azure Container Apps).
For each environment promotion, ask what tests gate the promotion:
How environment-specific config is managed:
Optional — ask only if deploying to platforms that need this:
If --skip-interview flag: Use detected defaults + sensible platform-aware
defaults for everything else:
PLATFORM == github): ghcr.io, 3-stage, GitHub Secrets, simple rollbackPLATFORM == azdo): Azure Container Registry, 3-stage, Azure Key Vault, simple rollbackCompile all answers into a DOCK_CONFIG object for Phase 3.
Based on DETECTION_REPORT and DOCK_CONFIG, generate all pipeline files.
Use templates from references/ as starting points and customize for the
detected stack and chosen platforms.
Read references/dockerfile-templates.md for the detected stack.
Generate a multi-stage Dockerfile:
Generate .dockerignore excluding: .git, node_modules, __pycache__, .env*,
test fixtures, documentation, IDE config.
Generate a local development compose file that mirrors the production image with development overrides (volume mounts, hot reload, debug ports).
Detect CI system from Phase 1 (GitHub Actions / Azure Pipelines / GitLab CI).
Read the appropriate template from references/pipeline-templates.md.
Generate a workflow that implements:
On pull request:
pr-{number}-{sha:7}On merge to main (or default branch):
{sha:7} and latestOn release tag (vX.Y.Z):
{sha:7} image as vX.Y.Z — do NOT rebuildKey principle: the release workflow never rebuilds. It promotes the exact image that was tested on main.
Based on the chosen platforms per environment, read the appropriate section
from references/platform-deploy-guides.md and generate:
az containerapp commands in workflowgcloud run deploy commandsGenerate an environment matrix config file (deploy/environments.json or
deploy/environments.yml) defining per-environment settings:
environments:
dev:
target: <platform>
registry_tag_pattern: "{sha:7}"
auto_deploy: true
tests: [smoke]
staging:
target: <platform>
registry_tag_pattern: "v{version}"
auto_deploy: false # requires manual approval or tag
tests: [integration, e2e]
prod:
target: <platform>
registry_tag_pattern: "v{version}"
auto_deploy: false
tests: [smoke-post-deploy]
If the detected framework doesn't already have a health endpoint, add a comment
in the generated workflow noting that a /healthz or /health endpoint is
recommended for deployment readiness probes.
If Docker is available, run a verification step:
docker build --target production -t dock-verify:test .
If the build succeeds, report success. If it fails, diagnose and fix the Dockerfile. Skip this phase if Docker is not installed (noted in pre-flight).
Also validate generated workflow files:
Present the user with a summary of all generated files before writing.
If --dry-run flag: Show the file list and content previews without writing.
After all files are generated and verified, present:
┌─ Dock · Report ────────────────────────────────
│
│ ✅ Dock complete
│
│ 🔧 Stack: {language} / {framework}
│ 📦 Registry: {registry}
│ 🌍 Stages: {env1} → {env2} → {env3}
│
│ 📝 Generated files
│ • {file} — {brief description}
│ • {file} — {brief description}
│ • ...
│
│ 📊 Pipeline flow
│ PR → build + test
│ Merge → build + test → push → deploy dev → smoke
│ Tag → retag (no rebuild) → staging → e2e → prod
│
│ 🔗 Links
│ Dockerfile: {path}
│ Workflow: {path}
│ Compose: {path}
│
│ ⚡ Next steps
│ 1. Review generated files
│ 2. Configure secrets: {list}
│ 3. Push to trigger first pipeline run
│
└─────────────────────────────────────────────────
If /dock detects it has been run before (existing deploy/ directory, existing
deployment workflow), it should:
deploy/
artifacts and wire the CI workflow to trigger deployment on merge to main.