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.