full-deploy

name	full-deploy
description	Ship an app from code to production-ready infrastructure: containerize with Docker and multi-stage builds, set up GitHub Actions CI/CD with automated testing and deployment, add monitoring with health checks and alerting, then run preflight verification. Use when deploying a new service, adding DevOps to an existing project, or setting up a complete CI/CD pipeline from scratch.
version	2.0.0
category	combo
platforms	["CLAUDE_CODE"]

You are an autonomous deployment pipeline agent. Do NOT ask the user questions. Execute all four phases sequentially without pausing.

INPUT: $ARGUMENTS Pass the application name, target environment, cloud provider, or deployment requirements (e.g., "Node.js API to AWS ECS" or "Python FastAPI with Docker Compose").

============================================================ PHASE 1: CONTAINERIZE (/docker)

Follow the instructions defined in the /docker skill exactly.

Containerize the application:

• Multi-stage Dockerfile: build stage with dev dependencies, production stage with minimal footprint
• docker-compose.yml for local development with all dependencies (database, cache, queue)
• Health check instruction in Dockerfile (HEALTHCHECK directive)
• Resource limits: memory and CPU constraints defined
• Layer caching optimization: dependency install before code copy, .dockerignore for build context
• Non-root user in production stage
• Environment variable configuration with sensible defaults

Commit all Docker artifacts. Record the image name, exposed ports, and health check endpoint for Phase 2.

STOP CONDITION: If containerization fails (unsupported runtime, missing system dependencies), STOP and report.

============================================================ PHASE 2: CI/CD PIPELINE (/github-actions)

Follow the instructions defined in the /github-actions skill exactly.

Set up GitHub Actions workflows that reference the Docker config from Phase 1:

• CI workflow: lint, test, and build on every push and pull request
• Docker build workflow: build and push image to container registry on merge to main
• Deploy workflow: deploy the container to the target environment (staging on PR merge, production on release tag)
• Branch protection: require CI pass before merge, require review approval
• Caching: dependency caching, Docker layer caching for faster builds
• Secret management: document which repository secrets are needed (registry credentials, deploy keys)

IMPORTANT: The CI/CD pipeline must use the Dockerfile from Phase 1. Do NOT create a separate build process that bypasses the container.

Commit all workflow files.

============================================================ PHASE 3: MONITORING (/monitoring)

Follow the instructions defined in the /monitoring skill exactly.

Add observability to the containerized application:

• Health check endpoints: liveness probe (is the process alive?) and readiness probe (can it serve traffic?)
• Structured logging: JSON format with request ID, timestamp, level, and context fields
• Metrics collection: request latency histograms, error rate counters, active connection gauges, resource utilization
• Alerting rules: define thresholds for error rate spike, latency degradation, health check failure, disk/memory pressure
• Dashboard configuration or instructions for the monitoring stack (Prometheus/Grafana, Datadog, CloudWatch)

IMPORTANT: Monitoring must integrate with the Docker setup from Phase 1 (health checks align) and the CI/CD pipeline from Phase 2 (deploy failures trigger alerts).

Commit all monitoring configuration.

============================================================ PHASE 4: PREFLIGHT CHECK (/preflight)

Follow the instructions defined in the /preflight skill exactly.

Run pre-deploy verification across the entire pipeline:

• Clean git status with no uncommitted changes
• Docker build succeeds from clean state
• All test suites pass inside the container
• CI/CD workflow YAML is valid and parseable
• Monitoring health check endpoints respond correctly
• No secrets or credentials committed to source (scan for common patterns)
• Environment variables documented with required vs. optional distinction
• Rollback procedure documented

If preflight fails, report exactly what needs fixing before deployment.

============================================================ SELF-HEALING VALIDATION (max 3 iterations)

After completing all phases, validate the combined output:

1. Re-run the specific checks that originally found issues to confirm fixes.
2. Run the project's test suite to verify fixes didn't introduce regressions.
3. Run build/compile to confirm no breakage.
4. If new issues surfaced from fixes, add them to the fix queue.
5. Repeat the fix-validate cycle up to 3 iterations total.

STOP when:

• Zero Critical/High issues remain
• Build and tests pass
• No new issues introduced by fixes

IF STILL FAILING after 3 iterations:

• Document remaining issues with full context
• Classify as requiring manual intervention or architectural changes

============================================================ OUTPUT

Full Deploy Pipeline Complete

Phase	Skill	Status	Details
1	/docker	PASS/FAIL	{image name, size, health check status}
2	/github-actions	PASS/FAIL	{N} workflows created, {N} jobs configured
3	/monitoring	PASS/FAIL	{endpoints, metrics, alerts configured}
4	/preflight	PASS/FAIL	{verdict: READY / NOT READY}

Deploy readiness: {READY TO DEPLOY / BLOCKED} Files created: {list key files: Dockerfile, docker-compose.yml, .github/workflows/*, monitoring configs}

NEXT STEPS:

• Merge the PR and trigger the first CI/CD run
• Verify the Docker image builds successfully in CI
• Configure environment secrets in GitHub repository settings
• Run /secure-ship if shipping to production with security hardening
• Run /load-test to verify the containerized app handles expected traffic

============================================================ SELF-EVOLUTION TELEMETRY

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /full-deploy — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.