CI CD And Automation
Addy OsmaniCommunityCreated by Addy Osmani
- Skill
- Tool integration
- Software development
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a structured approach to implementing CI/CD pipelines that enforce quality through automated gates including linting, type checking, testing, and security audits. It emphasizes the 'shift left' philosophy to catch issues early, provides templates for GitHub Actions, and outlines best practices for environment management, feature flags, and rollback procedures to ensure reliable software delivery.
What it does
- Defines a multi-stage quality gate pipeline for automated code verification.
- Provides GitHub Actions configuration templates for CI, integration tests, and E2E testing.
- Outlines strategies for preview deployments and staged rollouts to production.
- Details best practices for secret management and environment configuration.
- Offers techniques for optimizing CI pipeline performance and reducing build times.
- Establishes patterns for integrating AI agents into the CI feedback loop.
When to use it
- When initializing a new project's CI/CD infrastructure.
- When adding or modifying automated quality checks in an existing pipeline.
- When configuring deployment strategies like canary releases or preview environments.
- When debugging persistent CI failures or optimizing slow build times.
- When establishing branch protection and merge requirements.
Advantages
- Reduces production risk through consistent, automated verification.
- Accelerates development cycles by catching bugs early in the pipeline.
- Provides clear, repeatable procedures for deployments and rollbacks.
- Promotes a culture of accountability with defined roles like the Build Cop.
- Ensures security and stability through mandatory quality gates.
Usage examples
- “Set up a basic GitHub Actions CI pipeline for my Node.js project.”
- The agent generates a .github/workflows/ci.yml file including linting, type checking, unit testing, building, and security auditing steps.
- “My CI pipeline is taking over 15 minutes to run. How can I optimize it?”
- The agent suggests strategies such as caching dependencies, parallelizing independent jobs, using path filters, or sharding test suites.
- “How should I handle database integration tests in my CI pipeline?”
- The agent provides a configuration example using service containers for PostgreSQL and explains how to use GitHub Secrets for database credentials.
- “The CI pipeline failed with a type error. How do I fix this?”
- The agent analyzes the provided error output, suggests the specific code fix, and advises on how to verify the fix locally before pushing.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/addyosmani/ci-cd-and-automation/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip ci-cd-and-automation.zip -d .agents/skills
Documentation by Addy Osmani
CI/CD and Automation
Overview
Automate quality gates so that no change reaches production without passing tests, lint, type checking, and build. CI/CD is the enforcement mechanism for every other skill — it catches what humans and agents miss, and it does so consistently on every single change.
Shift Left: Catch problems as early in the pipeline as possible. A bug caught in linting costs minutes; the same bug caught in production costs hours. Move checks upstream — static analysis before tests, tests before staging, staging before production.
Faster is Safer: Smaller batches and more frequent releases reduce risk, not increase it. A deployment with 3 changes is easier to debug than one with 30. Frequent releases build confidence in the release process itself.
When to Use
Setting up a new project's CI pipeline
Adding or modifying automated checks
Configuring deployment pipelines
When a change should trigger automated verification
Debugging CI failures
The Quality Gate Pipeline
Every change goes through these gates before merge:
Pull Request Opened
│
▼
┌─────────────────┐
│ LINT CHECK │ eslint, prettier
│ ↓ pass │
│ TYPE CHECK │ tsc --noEmit
│ ↓ pass │
│ UNIT TESTS │ jest/vitest
│ ↓ pass │
│ BUILD │ npm run build
│ ↓ pass │
│ INTEGRATION │ API/DB tests
│ ↓ pass │
│ E2E (optional) │ Playwright/Cypress
│ ↓ pass │
│ SECURITY AUDIT │ npm audit
│ ↓ pass │
│ BUNDLE SIZE │ bundlesize check
└─────────────────┘
│
▼
Ready for reviewNo gate can be skipped. If lint fails, fix lint — don't disable the rule. If a test fails, fix the code — don't skip the test.
GitHub Actions Configuration
Basic CI Pipeline
# .github/workflows/ci.yml
name: CI
on:
pull_request:
branches: [main]
push:
branches: [main]
jobs:
quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Lint
run: npm run lint
- name: Type check
run: npx tsc --noEmit
- name: Test
run: npm test -- --coverage
- name: Build
run: npm run build
- name: Security audit
run: npm audit --audit-level=highWith Database Integration Tests
integration:
runs-on: ubuntu-latest
services:
postgres:
image: postgres:16
env:
POSTGRES_DB: testdb
POSTGRES_USER: ci_user
POSTGRES_PASSWORD: ${{ secrets.CI_DB_PASSWORD }}
ports:
- 5432:5432
options: >-
--health-cmd pg_isready
--health-interval 10s
--health-timeout 5s
--health-retries 5
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- name: Run migrations
run: npx prisma migrate deploy
env:
DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
- name: Integration tests
run: npm run test:integration
env:
DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdbNote: Even for CI-only test databases, use GitHub Secrets for credentials rather than hardcoding values. This builds good habits and prevents accidental reuse of test credentials in other contexts.
E2E Tests
e2e:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- name: Install Playwright
run: npx playwright install --with-deps chromium
- name: Build
run: npm run build
- name: Run E2E tests
run: npx playwright test
- uses: actions/upload-artifact@v4
if: failure()
with:
name: playwright-report
path: playwright-report/Feeding CI Failures Back to Agents
The power of CI with AI agents is the feedback loop. When CI fails:
CI fails
│
▼
Copy the failure output
│
▼
Feed it to the agent:
"The CI pipeline failed with this error:
[paste specific error]
Fix the issue and verify locally before pushing again."
│
▼
Agent fixes → pushes → CI runs againKey patterns:
Lint failure → Agent runs `npm run lint -- --fix` and commits
Type error → Agent reads the error location and fixes the type
Test failure → Agent follows debugging-and-error-recovery skill
Build error → Agent checks config and dependenciesDeployment Strategies
Preview Deployments
Every PR gets a preview deployment for manual testing:
# Deploy preview on PR (Vercel/Netlify/etc.)
deploy-preview:
runs-on: ubuntu-latest
if: github.event_name == 'pull_request'
steps:
- uses: actions/checkout@v4
- name: Deploy preview
run: npx vercel --token=${{ secrets.VERCEL_TOKEN }}Feature Flags
Feature flags decouple deployment from release. Deploy incomplete or risky features behind flags so you can:
Ship code without enabling it. Merge to main early, enable when ready.
Roll back without redeploying. Disable the flag instead of reverting code.
Canary new features. Enable for 1% of users, then 10%, then 100%.
Run A/B tests. Compare behavior with and without the feature.
// Simple feature flag pattern
if (featureFlags.isEnabled('new-checkout-flow', { userId })) {
return renderNewCheckout();
}
return renderLegacyCheckout();Flag lifecycle: Create → Enable for testing → Canary → Full rollout → Remove the flag and dead code. Flags that live forever become technical debt — set a cleanup date when you create them.
Staged Rollouts
PR merged to main
│
▼
Staging deployment (auto)
│ Manual verification
▼
Production deployment (manual trigger or auto after staging)
│
▼
Monitor for errors (15-minute window)
│
├── Errors detected → Rollback
└── Clean → DoneRollback Plan
Every deployment should be reversible:
# Manual rollback workflow
name: Rollback
on:
workflow_dispatch:
inputs:
version:
description: 'Version to rollback to'
required: true
jobs:
rollback:
runs-on: ubuntu-latest
steps:
- name: Rollback deployment
env:
VERSION: ${{ inputs.version }}
run: |
# Deploy the specified previous version. Pass the input through env,
# never interpolate it into the script (shell injection).
npx vercel rollback "$VERSION"Environment Management
.env.example → Committed (template for developers)
.env → NOT committed (local development)
.env.test → Committed (test environment, no real secrets)
CI secrets → Stored in GitHub Secrets / vault
Production secrets → Stored in deployment platform / vaultCI should never have production secrets. Use separate secrets for CI testing.
Automation Beyond CI
Dependabot / Renovate
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: npm
directory: /
schedule:
interval: weekly
open-pull-requests-limit: 5Build Cop Role
Designate someone responsible for keeping CI green. When the build breaks, the Build Cop's job is to fix or revert — not the person whose change caused the break. This prevents broken builds from accumulating while everyone assumes someone else will fix it.
PR Checks
Required reviews: At least 1 approval before merge
Required status checks: CI must pass before merge
Branch protection: No force-pushes to main
Auto-merge: If all checks pass and approved, merge automatically
CI Optimization
When the pipeline exceeds 10 minutes, apply these strategies in order of impact:
Slow CI pipeline?
├── Cache dependencies
│ └── Use the setup-node cache option (or actions/cache) for the package manager cache, not node_modules
├── Run jobs in parallel
│ └── Split lint, typecheck, test, build into separate parallel jobs
├── Only run what changed
│ └── Use path filters to skip unrelated jobs (e.g., skip e2e for docs-only PRs)
├── Use matrix builds
│ └── Shard test suites across multiple runners
├── Optimize the test suite
│ └── Remove slow tests from the critical path, run them on a schedule instead
└── Use larger runners
└── GitHub-hosted larger runners or self-hosted for CPU-heavy buildsExample: caching and parallelism
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22', cache: 'npm' }
- run: npm ci
- run: npm run lint
typecheck:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22', cache: 'npm' }
- run: npm ci
- run: npx tsc --noEmit
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22', cache: 'npm' }
- run: npm ci
- run: npm test -- --coverageCommon Rationalizations
| Rationalization | Reality |
|---|---|
| "CI is too slow" | Optimize the pipeline (see CI Optimization below), don't skip it. A 5-minute pipeline prevents hours of debugging. |
| "This change is trivial, skip CI" | Trivial changes break builds. CI is fast for trivial changes anyway. |
| "The test is flaky, just re-run" | Flaky tests mask real bugs and waste everyone's time. Fix the flakiness. |
| "We'll add CI later" | Projects without CI accumulate broken states. Set it up on day one. |
| "Manual testing is enough" | Manual testing doesn't scale and isn't repeatable. Automate what you can. |
Red Flags
No CI pipeline in the project
CI failures ignored or silenced
Tests disabled in CI to make the pipeline pass
Production deploys without staging verification
No rollback mechanism
Secrets stored in code or CI config files (not secrets manager)
Long CI times with no optimization effort
Verification
After setting up or modifying CI:
[ ] All quality gates are present (lint, types, tests, build, audit)
[ ] Pipeline runs on every PR and push to main
[ ] Failures block merge (branch protection configured)
[ ] CI results feed back into the development loop
[ ] Secrets are stored in the secrets manager, not in code
[ ] Deployment has a rollback mechanism
[ ] Pipeline runs in under 10 minutes for the test suite
Files
- ATTRIBUTION.mdAdded by AutoGineer881 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md11.2 KiB
SKILL.md
CI/CD and Automation
Overview
Automate quality gates so that no change reaches production without passing tests, lint, type checking, and build. CI/CD is the enforcement mechanism for every other skill — it catches what humans and agents miss, and it does so consistently on every single change.
Shift Left: Catch problems as early in the pipeline as possible. A bug caught in linting costs minutes; the same bug caught in production costs hours. Move checks upstream — static analysis before tests, tests before staging, staging before production.
Faster is Safer: Smaller batches and more frequent releases reduce risk, not increase it. A deployment with 3 changes is easier to debug than one with 30. Frequent releases build confidence in the release process itself.
When to Use
Setting up a new project's CI pipeline
Adding or modifying automated checks
Configuring deployment pipelines
When a change should trigger automated verification
Debugging CI failures
The Quality Gate Pipeline
Every change goes through these gates before merge:
Pull Request Opened
│
▼
┌─────────────────┐
│ LINT CHECK │ eslint, prettier
│ ↓ pass │
│ TYPE CHECK │ tsc --noEmit
│ ↓ pass │
│ UNIT TESTS │ jest/vitest
│ ↓ pass │
│ BUILD │ npm run build
│ ↓ pass │
│ INTEGRATION │ API/DB tests
│ ↓ pass │
│ E2E (optional) │ Playwright/Cypress
│ ↓ pass │
│ SECURITY AUDIT │ npm audit
│ ↓ pass │
│ BUNDLE SIZE │ bundlesize check
└─────────────────┘
│
▼
Ready for reviewNo gate can be skipped. If lint fails, fix lint — don't disable the rule. If a test fails, fix the code — don't skip the test.
GitHub Actions Configuration
Basic CI Pipeline
# .github/workflows/ci.yml
name: CI
on:
pull_request:
branches: [main]
push:
branches: [main]
jobs:
quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Lint
run: npm run lint
- name: Type check
run: npx tsc --noEmit
- name: Test
run: npm test -- --coverage
- name: Build
run: npm run build
- name: Security audit
run: npm audit --audit-level=highWith Database Integration Tests
integration:
runs-on: ubuntu-latest
services:
postgres:
image: postgres:16
env:
POSTGRES_DB: testdb
POSTGRES_USER: ci_user
POSTGRES_PASSWORD: ${{ secrets.CI_DB_PASSWORD }}
ports:
- 5432:5432
options: >-
--health-cmd pg_isready
--health-interval 10s
--health-timeout 5s
--health-retries 5
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- name: Run migrations
run: npx prisma migrate deploy
env:
DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
- name: Integration tests
run: npm run test:integration
env:
DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdbNote: Even for CI-only test databases, use GitHub Secrets for credentials rather than hardcoding values. This builds good habits and prevents accidental reuse of test credentials in other contexts.
E2E Tests
e2e:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- name: Install Playwright
run: npx playwright install --with-deps chromium
- name: Build
run: npm run build
- name: Run E2E tests
run: npx playwright test
- uses: actions/upload-artifact@v4
if: failure()
with:
name: playwright-report
path: playwright-report/Feeding CI Failures Back to Agents
The power of CI with AI agents is the feedback loop. When CI fails:
CI fails
│
▼
Copy the failure output
│
▼
Feed it to the agent:
"The CI pipeline failed with this error:
[paste specific error]
Fix the issue and verify locally before pushing again."
│
▼
Agent fixes → pushes → CI runs againKey patterns:
Lint failure → Agent runs `npm run lint -- --fix` and commits
Type error → Agent reads the error location and fixes the type
Test failure → Agent follows debugging-and-error-recovery skill
Build error → Agent checks config and dependenciesDeployment Strategies
Preview Deployments
Every PR gets a preview deployment for manual testing:
# Deploy preview on PR (Vercel/Netlify/etc.)
deploy-preview:
runs-on: ubuntu-latest
if: github.event_name == 'pull_request'
steps:
- uses: actions/checkout@v4
- name: Deploy preview
run: npx vercel --token=${{ secrets.VERCEL_TOKEN }}Feature Flags
Feature flags decouple deployment from release. Deploy incomplete or risky features behind flags so you can:
Ship code without enabling it. Merge to main early, enable when ready.
Roll back without redeploying. Disable the flag instead of reverting code.
Canary new features. Enable for 1% of users, then 10%, then 100%.
Run A/B tests. Compare behavior with and without the feature.
// Simple feature flag pattern
if (featureFlags.isEnabled('new-checkout-flow', { userId })) {
return renderNewCheckout();
}
return renderLegacyCheckout();Flag lifecycle: Create → Enable for testing → Canary → Full rollout → Remove the flag and dead code. Flags that live forever become technical debt — set a cleanup date when you create them.
Staged Rollouts
PR merged to main
│
▼
Staging deployment (auto)
│ Manual verification
▼
Production deployment (manual trigger or auto after staging)
│
▼
Monitor for errors (15-minute window)
│
├── Errors detected → Rollback
└── Clean → DoneRollback Plan
Every deployment should be reversible:
# Manual rollback workflow
name: Rollback
on:
workflow_dispatch:
inputs:
version:
description: 'Version to rollback to'
required: true
jobs:
rollback:
runs-on: ubuntu-latest
steps:
- name: Rollback deployment
env:
VERSION: ${{ inputs.version }}
run: |
# Deploy the specified previous version. Pass the input through env,
# never interpolate it into the script (shell injection).
npx vercel rollback "$VERSION"Environment Management
.env.example → Committed (template for developers)
.env → NOT committed (local development)
.env.test → Committed (test environment, no real secrets)
CI secrets → Stored in GitHub Secrets / vault
Production secrets → Stored in deployment platform / vaultCI should never have production secrets. Use separate secrets for CI testing.
Automation Beyond CI
Dependabot / Renovate
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: npm
directory: /
schedule:
interval: weekly
open-pull-requests-limit: 5Build Cop Role
Designate someone responsible for keeping CI green. When the build breaks, the Build Cop's job is to fix or revert — not the person whose change caused the break. This prevents broken builds from accumulating while everyone assumes someone else will fix it.
PR Checks
Required reviews: At least 1 approval before merge
Required status checks: CI must pass before merge
Branch protection: No force-pushes to main
Auto-merge: If all checks pass and approved, merge automatically
CI Optimization
When the pipeline exceeds 10 minutes, apply these strategies in order of impact:
Slow CI pipeline?
├── Cache dependencies
│ └── Use the setup-node cache option (or actions/cache) for the package manager cache, not node_modules
├── Run jobs in parallel
│ └── Split lint, typecheck, test, build into separate parallel jobs
├── Only run what changed
│ └── Use path filters to skip unrelated jobs (e.g., skip e2e for docs-only PRs)
├── Use matrix builds
│ └── Shard test suites across multiple runners
├── Optimize the test suite
│ └── Remove slow tests from the critical path, run them on a schedule instead
└── Use larger runners
└── GitHub-hosted larger runners or self-hosted for CPU-heavy buildsExample: caching and parallelism
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22', cache: 'npm' }
- run: npm ci
- run: npm run lint
typecheck:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22', cache: 'npm' }
- run: npm ci
- run: npx tsc --noEmit
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22', cache: 'npm' }
- run: npm ci
- run: npm test -- --coverageCommon Rationalizations
| Rationalization | Reality |
|---|---|
| "CI is too slow" | Optimize the pipeline (see CI Optimization below), don't skip it. A 5-minute pipeline prevents hours of debugging. |
| "This change is trivial, skip CI" | Trivial changes break builds. CI is fast for trivial changes anyway. |
| "The test is flaky, just re-run" | Flaky tests mask real bugs and waste everyone's time. Fix the flakiness. |
| "We'll add CI later" | Projects without CI accumulate broken states. Set it up on day one. |
| "Manual testing is enough" | Manual testing doesn't scale and isn't repeatable. Automate what you can. |
Red Flags
No CI pipeline in the project
CI failures ignored or silenced
Tests disabled in CI to make the pipeline pass
Production deploys without staging verification
No rollback mechanism
Secrets stored in code or CI config files (not secrets manager)
Long CI times with no optimization effort
Verification
After setting up or modifying CI:
[ ] All quality gates are present (lint, types, tests, build, audit)
[ ] Pipeline runs on every PR and push to main
[ ] Failures block merge (branch protection configured)
[ ] CI results feed back into the development loop
[ ] Secrets are stored in the secrets manager, not in code
[ ] Deployment has a rollback mechanism
[ ] Pipeline runs in under 10 minutes for the test suite
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs Node.js
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- Addy Osmani
- Publisher
- Addy Osmani (Community)
- Source
- addyosmani/agent-skills · skills/ci-cd-and-automation · commit 301b02b
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Addy Osmani or Addy Osmani.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download ci-cd-and-automation.zip