/ci-cd-pipeline

name: memstack-deployment-ci-cd-pipeline
description: "Use this skill when the user says 'CI/CD', 'GitHub Actions', 'pipeline', 'continuous integration', 'continuous deployment', 'ci-cd-pipeline', 'automate deploys', or needs to set up automated build, test, and deployment pipelines. Do NOT use for one-time manual deployments."
version: 1.0.0
license: "Proprietary, MemStack™ Pro by CW Affiliate Investments LLC. See LICENSE.txt"

🔄 CI/CD Pipeline: Continuous Integration & Deployment

*Detect project type and generate a complete CI/CD pipeline with lint, test, build, deploy stages, rollback strategy, and environment management.*

Activation

When this skill activates, output:

`🔄 CI/CD Pipeline: Designing your pipeline...`

| Context | Status | |---------|--------| | **User says "CI/CD", "pipeline", "GitHub Actions"** | ACTIVE | | **User wants automated testing and deployment** | ACTIVE | | **User mentions branch strategy, deploy gates, or rollbacks** | ACTIVE | | **User wants Docker setup (CI/CD is secondary)** | DORMANT: see docker-setup | | **User wants server provisioning (not pipeline)** | DORMANT: see hetzner-setup | | **User wants to deploy to a specific platform only** | DORMANT, see railway-deploy or netlify-deploy |

Protocol

Step 1: Gather Inputs

Ask the user for:

• **Project type**: Node.js, Python, Go, Rust, monorepo?
• **Testing framework**: Jest, Vitest, Pytest, Go test?
• **Deployment target**: Vercel, Railway, Netlify, Hetzner VPS, AWS, Docker registry?
• **Current CI/CD**: Any existing pipeline, or starting from scratch?
• **Branch strategy**: Trunk-based, GitFlow, or custom?
• **Team size**: Solo dev, small team, or large team?

Step 2: Detect Project & Recommend Platform

Auto-detect from project files and recommend CI/CD platform:

| Project Signal | Platform Recommendation | Reason | |---------------|------------------------|--------| | `.github/` exists | GitHub Actions | Already on GitHub, native integration | | `vercel.json` or Next.js | Vercel (auto-deploy) + GitHub Actions (CI) | Vercel handles deploy, GHA handles testing | | `railway.json` | Railway (auto-deploy) + GitHub Actions (CI) | Railway handles deploy, GHA handles testing | | `netlify.toml` | Netlify (auto-deploy) + GitHub Actions (CI) | Netlify handles deploy, GHA handles testing | | Dockerfile present | GitHub Actions → Docker registry → deploy | Full control pipeline | | Monorepo (`packages/`) | GitHub Actions with matrix/path filters | Need per-package CI | | Self-hosted server | GitHub Actions → SSH deploy | Push-based deployment |

**Default recommendation: GitHub Actions**: free for public repos, 2,000 min/month for private.

Step 3: Design Pipeline Stages

Define the stage sequence:

┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐
│  LINT   │──→│  TEST   │──→│  BUILD  │──→│ DEPLOY  │──→│ VERIFY  │
│         │   │         │   │         │   │         │   │         │
│ ESLint  │   │ Unit    │   │ Compile │   │ Push to │   │ Health  │
│ Prettier│   │ Integ.  │   │ Bundle  │   │ target  │   │ Smoke   │
│ Types   │   │ E2E     │   │ Docker  │   │ env     │   │ Rollback│
└─────────┘   └─────────┘   └─────────┘   └─────────┘   └─────────┘
     │              │              │              │              │
  Fail fast    Gate: block     Artifacts      Env-specific    Auto-rollback
  < 1 min      if < 80%       cached         secrets         on failure

**Stage details:**

| Stage | Trigger | Failure Action | Duration Target | |-------|---------|---------------|-----------------| | **Lint** | Every push, every PR | Block merge | < 1 min | | **Test** | Every push, every PR | Block merge | < 5 min | | **Build** | PR merge to main/develop | Block deploy | < 3 min | | **Deploy** | Build passes on target branch | Alert + rollback | < 2 min | | **Verify** | After deploy completes | Auto-rollback | < 1 min |

Step 4: Branch Strategy

**Recommended: Simplified GitFlow**

main (production)
  ├── develop (staging)
  │     ├── feature/add-auth
  │     ├── feature/dashboard
  │     └── fix/login-bug
  └── hotfix/critical-fix (→ main + develop)

| Branch | Deploys To | CI Runs | Auto-Deploy? | |--------|-----------|---------|-------------| | `feature/*` | none | Lint + Test | No | | `develop` | Staging | Lint + Test + Build + Deploy | Yes | | `main` | Production | Lint + Test + Build + Deploy | Yes (or manual gate) | | `hotfix/*` | none | Lint + Test | No (merge to main to deploy) |

**Branch protection rules:**

main:
  - Require PR review (1+ approvals)
  - Require status checks (lint, test, build)
  - No force push
  - No direct push

develop:
  - Require status checks (lint, test)
  - Allow direct push (for solo devs)
  - No force push

Step 5: Environment Variable Management

── ENVIRONMENT VARIABLES ──────────────────

Three environments with escalating secrets:

LOCAL (.env.local, never committed):
  DATABASE_URL=postgresql://localhost:5432/app_dev
  API_KEY=dev_test_key
  NODE_ENV=development

STAGING (GitHub Secrets / platform env):
  DATABASE_URL=[staging DB connection string]
  API_KEY=[staging API key]
  NODE_ENV=staging

PRODUCTION (GitHub Secrets / platform env):
  DATABASE_URL=[production DB connection string]
  API_KEY=[production API key]
  NODE_ENV=production

**Secret management rules:**

• Never hardcode secrets in pipeline config
• Use GitHub Environments for per-branch secrets
• Use `GITHUB_TOKEN` for GitHub operations (auto-provided)
• Rotate secrets quarterly
• Audit secret access in GitHub Settings → Secrets → Audit log

**GitHub Environments setup:**

Repository → Settings → Environments:
  staging:
    Secrets: DATABASE_URL, API_KEY
    Deployment branches: develop

  production:
    Secrets: DATABASE_URL, API_KEY
    Deployment branches: main
    Required reviewers: [team member] (optional gate)

Step 6: Generate Pipeline Config

**GitHub Actions: Node.js project:**

name: CI/CD Pipelin