ci-cd
CI/CD
Automate everything between code commit and production deployment. Manual steps are bugs waiting to happen.
Context
CI/CD is the backbone of reliable delivery. Continuous Integration ensures every code change is validated automatically. Continuous Delivery ensures validated code can be deployed to production at any time. Together, they reduce the risk of releases from "big scary event" to "routine operation."
In a lifecycle-aware system, CI/CD must preserve upstream quality and rollout constraints. It should not flatten unresolved brownfield risks into a generic "deploy after tests pass" pipeline.
Inputs
- source-code -- produced by the preceding skill in the lifecycle
- test-strategy-doc -- produced by the preceding skill in the lifecycle
- architecture-doc -- produced by the preceding skill in the lifecycle
- task-list -- produced by the preceding skill in the lifecycle
Process
Step 1: Design Pipeline Stages
A typical pipeline:
Commit -> Lint -> Build -> Unit Test -> Integration Test -> Security Scan -> Deploy Staging -> Deploy Production
Each stage should:
- Fail fast (cheapest checks first)
- Run in isolation (no shared state between stages)
- Produce artifacts usable by downstream stages
For brownfield or compatibility-sensitive delivery, include explicit gates for:
- contract/integration behavior that protects release boundaries
- coexistence or rollback verification
- staged rollout readiness rather than a single blind production hop
Step 2: Configure Build Environment
- Use containerized builds for reproducibility (same result locally and in CI)
- Pin dependency versions (lockfile committed)
- Cache dependencies between runs for speed
- Matrix builds for multi-platform support
Step 3: Automate Testing
- Unit tests run on every commit (< 5 min)
- Integration tests run on every PR (< 15 min)
- E2E tests run before deployment (< 30 min)
- Parallelize test suites where possible
Match stages to the reviewed test strategy rather than assuming a generic default. Unsupported-flow or coexistence tests should run where they can actually stop an unsafe deploy.
Step 4: Automate Deployment
- Staging: auto-deploy on merge to main
- Production: one-click (or auto) deploy with approval gate
- Use infrastructure-as-code for environment consistency
- Implement rollback automation
If release boundaries or sync semantics remain constrained, use staging and gated rollout steps that fail closed rather than pipelines that assume instant full production rollout.
Step 5: Configure Notifications
- Notify on failure (but not on success -- reduce noise)
- Link to logs and artifacts for quick debugging
- Alert on deployment completion
Outputs
- ci-cd-pipeline -- produced by this skill
- build-artifacts -- produced by this skill
Quality Gate
- Pipeline runs on every PR and merge to main
- Build time < 15 minutes for fast feedback
- All test types automated (unit, integration, security scan)
- Staging deployment automated
- Rollback mechanism tested
- Brownfield coexistence or release-boundary checks are enforced where applicable
Anti-Patterns
- "It works on my machine" -- Containerize builds. Environment differences are bugs.
- Slow pipelines -- If CI takes 30+ minutes, developers skip it. Optimize relentlessly.
- Flaky tests in CI -- Quarantine or fix immediately. A flaky pipeline is a useless pipeline.
- Manual deployment steps -- "SSH into the server and run this script" is not CI/CD.
- No rollback plan -- Every deployment must have a tested rollback path.
- Pipeline that ignores release boundaries -- Shipping a generic pipeline that never verifies unsupported-flow behavior, coexistence, or rollback readiness for the current slice.
Related Skills
- testing-strategy -- defines what tests to run in the pipeline
- deployment-strategy -- defines deployment patterns (blue-green, canary)
- release-management -- coordinates release process
- monitoring-observability -- post-deployment validation
Distribution
- Public install surface:
skills/.curated - Canonical authoring source:
skills/06-delivery/ci-cd/SKILL.md - This package is exported for
npx skills add/updatecompatibility. - Packaging stability:
beta - Capability readiness:
beta
More from yknothing/prodcraft
system-design
Use when reviewed requirements or specifications are ready and the team must decide high-level architecture, component boundaries, integration seams, or brownfield coexistence strategy before API design, technology selection, or task planning.
6intake
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
6feature-development
Use when a reviewed task slice has tests or acceptance targets and the team must turn it into a small, mergeable implementation increment without expanding scope, breaking contracts, or hiding release-boundary risk.
6monitoring-observability
Use when a live service or newly delivered release needs actionable telemetry, dashboards, and alerts that expose real user-impactful boundaries, especially when brownfield coexistence rules, unsupported-flow safety, rollback health, or queue/backfill behavior must be visible before incidents escalate.
6incident-response
Use when a live production issue needs coordinated containment, severity triage, stakeholder communication, and evidence capture, especially when a recent release, brownfield coexistence rules, rollback decisions, or unresolved contract boundaries must be handled before root-cause work.
6requirements-engineering
Use when the work is still at the \u201Cwhat should we build\u201D stage and approved discovery inputs or entry-stack outputs must become prioritized requirements and scope boundaries before specification, architecture, planning, or coding. Not for acceptance criteria, spec review, or implementation.
6