CI/CD and Automation
Overview
Build and deployment pipelines should enforce quality automatically. Apply Shift Left principles (catch issues early), use feature flags for safe releases, and make the pipeline the authority on whether code is ready to ship.
When to Use
- Setting up CI/CD for a new project
- Modifying existing build or deploy pipelines
- Adding quality gates or automated checks
- Troubleshooting pipeline failures
Core Principles
Shift Left
Catch issues as early as possible:
- Lint and format on save or pre-commit
- Run type checks locally before push
- Run unit tests on every push
- Run integration tests on every PR
- Run security scans on merge to main
Faster is Safer
Small, frequent deployments are safer than large, infrequent ones:
- Automate the deployment process completely
- Make rollbacks trivial
- Deploy to staging automatically on merge
- Deploy to production with a single approval or automatically
Feature Flags
Use feature flags for:
- Incomplete features merged to main
- A/B testing and gradual rollouts
- Kill switches for new functionality
- Environment-specific behavior
Quality Gate Pipeline
Standard pipeline stages:
- Lint and format check
- Type check
- Unit tests with coverage
- Build
- Integration tests
- Security scan
- Deploy to staging
- Smoke tests
- Deploy to production
Process
Step 1: Define Pipeline Stages
- List all automated checks the project needs
- Order them fastest-failing-first
- Ensure each stage has clear pass/fail criteria
Step 2: Implement Fast Feedback
- Ensure lint and type checks run in under 30 seconds
- Ensure unit tests run in under 2 minutes
- Provide clear error output for each failure
Step 3: Add Deployment Automation
- Automated staging deployment on merge
- Automated production deployment with approval gate
- Rollback procedure that can execute in under 1 minute
Step 4: Monitor Pipeline Health
- Track build success rates
- Track mean time to recovery from failures
- Alert on pipeline failures that block merges
Common Rationalizations
| Rationalization |
Reality |
| "The pipeline can be fixed later" |
Broken pipelines encourage bypassing them, which defeats their purpose. |
| "Full automation is too much work" |
Manual deployment is slower, more error-prone, and harder to audit. |
| "Feature flags add complexity" |
Feature flags add controlled complexity that prevents uncontrolled deployment risk. |
Verification
Anti-Rationalization Table
| Excuse |
Counter |
| "The pipeline can be fixed later" |
Broken pipelines encourage bypassing them, which defeats their purpose. |
| "Full automation is too much work" |
Manual deployment is slower, more error-prone, and harder to audit. |
| "Feature flags add complexity" |
Feature flags add controlled complexity that prevents uncontrolled deployment risk. |
| "We don't need staging, just deploy to production" |
Staging catches environment-specific issues before they reach users. |
| "The pipeline is fast enough" |
Slow pipelines discourage frequent commits. Fast feedback enables trunk-based development. |
Imported from cursor-team-kit/loop-on-ci (MIT, cursor/plugins)
Loop on CI
Trigger
Need to watch a branch or pull request and iterate on CI failures until all required checks are green.
Use gh pr checks as the source of truth. It includes all PR-attached checks, while gh run list only covers GitHub Actions.
Workflow
- Resolve the PR for the current branch.
- Inspect current PR checks before waiting.
- If checks already failed, diagnose those failures first.
- If checks are pending, watch with
gh pr checks --watch --fail-fast.
- After each push, re-check the full PR check set and repeat until green.
Commands
# Resolve the active PR
gh pr view --json number,url,headRefName
# Inspect all attached checks
gh pr checks --json name,bucket,state,workflow,link
# Watch pending checks and fail fast
gh pr checks --watch --fail-fast
# GitHub Actions logs, when the failing check links to a GHA run
gh run view <run-id> --log-failed
Guardrails
- Keep each fix scoped to a single failure cause when possible.
- Do not bypass hooks (
--no-verify) to force progress.
- If the failure is clearly unrelated to the PR and appears fixed on main, merge latest main instead of bloating the PR with unrelated fixes.
- If failures are flaky, retry once and report flake evidence.
- Re-run
gh pr checks --json name,bucket,state,workflow,link after every push; the check set can change.
Output
- Current CI status
- Failure summary and fixes applied
- PR URL once checks are green
Imported from cursor-team-kit/fix-ci (MIT, cursor/plugins)
Fix CI
Trigger
Branch or PR CI is failing and needs a fast, iterative path to green checks.
Workflow
- Resolve the active PR and inspect
gh pr checks --json name,bucket,state,workflow,link.
- Inspect failed jobs and extract the first actionable error. Use GitHub Actions logs when available; otherwise use the check link to identify the failing command or service.
- Apply the smallest safe fix.
- Push, re-check the PR check set, and repeat until green.
Guardrails
- Fix one actionable failure at a time.
- Prefer minimal, low-risk changes before broader refactors.
- Keep
gh pr checks as the source of truth for overall PR CI state.
Output
- Primary failing job and root error
- Fixes applied in iteration order
- Current CI status and next action
Source: v1truv1us/ai-eng-system — distributed by TomeVault.
1---2name: ci-cd-and-automation-93description: Shift Left, Faster is Safer, feature flags, quality gate pipelines, failure feedback loops. Use when setting up or modifying build and deploy pipelines. Use when this capability is needed.4---56# CI/CD and Automation78## Overview910Build and deployment pipelines should enforce quality automatically. Apply Shift Left principles (catch issues early), use feature flags for safe releases, and make the pipeline the authority on whether code is ready to ship.1112## When to Use1314- Setting up CI/CD for a new project15- Modifying existing build or deploy pipelines16- Adding quality gates or automated checks17- Troubleshooting pipeline failures1819## Core Principles2021### Shift Left2223Catch issues as early as possible:24- Lint and format on save or pre-commit25- Run type checks locally before push26- Run unit tests on every push27- Run integration tests on every PR28- Run security scans on merge to main2930### Faster is Safer3132Small, frequent deployments are safer than large, infrequent ones:33- Automate the deployment process completely34- Make rollbacks trivial35- Deploy to staging automatically on merge36- Deploy to production with a single approval or automatically3738### Feature Flags3940Use feature flags for:41- Incomplete features merged to main42- A/B testing and gradual rollouts43- Kill switches for new functionality44- Environment-specific behavior4546### Quality Gate Pipeline4748Standard pipeline stages:491. Lint and format check502. Type check513. Unit tests with coverage524. Build535. Integration tests546. Security scan557. Deploy to staging568. Smoke tests579. Deploy to production5859## Process6061### Step 1: Define Pipeline Stages6263- List all automated checks the project needs64- Order them fastest-failing-first65- Ensure each stage has clear pass/fail criteria6667### Step 2: Implement Fast Feedback6869- Ensure lint and type checks run in under 30 seconds70- Ensure unit tests run in under 2 minutes71- Provide clear error output for each failure7273### Step 3: Add Deployment Automation7475- Automated staging deployment on merge76- Automated production deployment with approval gate77- Rollback procedure that can execute in under 1 minute7879### Step 4: Monitor Pipeline Health8081- Track build success rates82- Track mean time to recovery from failures83- Alert on pipeline failures that block merges8485## Common Rationalizations8687| Rationalization | Reality |88|---|---|89| "The pipeline can be fixed later" | Broken pipelines encourage bypassing them, which defeats their purpose. |90| "Full automation is too much work" | Manual deployment is slower, more error-prone, and harder to audit. |91| "Feature flags add complexity" | Feature flags add controlled complexity that prevents uncontrolled deployment risk. |9293## Verification9495- [ ] Pipeline runs on every push and PR96- [ ] Fastest checks run first97- [ ] Each stage has clear pass/fail criteria98- [ ] Deployment is fully automated99- [ ] Rollback takes under 1 minute100101## Anti-Rationalization Table102103| Excuse | Counter |104|--------|---------|105| "The pipeline can be fixed later" | Broken pipelines encourage bypassing them, which defeats their purpose. |106| "Full automation is too much work" | Manual deployment is slower, more error-prone, and harder to audit. |107| "Feature flags add complexity" | Feature flags add controlled complexity that prevents uncontrolled deployment risk. |108| "We don't need staging, just deploy to production" | Staging catches environment-specific issues before they reach users. |109| "The pipeline is fast enough" | Slow pipelines discourage frequent commits. Fast feedback enables trunk-based development. |110111## Imported from cursor-team-kit/loop-on-ci (MIT, cursor/plugins)112113# Loop on CI114115## Trigger116117Need to watch a branch or pull request and iterate on CI failures until all required checks are green.118119Use `gh pr checks` as the source of truth. It includes all PR-attached checks, while `gh run list` only covers GitHub Actions.120121## Workflow1221231. Resolve the PR for the current branch.1242. Inspect current PR checks before waiting.1253. If checks already failed, diagnose those failures first.1264. If checks are pending, watch with `gh pr checks --watch --fail-fast`.1275. After each push, re-check the full PR check set and repeat until green.128129## Commands130131```bash132# Resolve the active PR133gh pr view --json number,url,headRefName134135# Inspect all attached checks136gh pr checks --json name,bucket,state,workflow,link137138# Watch pending checks and fail fast139gh pr checks --watch --fail-fast140141# GitHub Actions logs, when the failing check links to a GHA run142gh run view <run-id> --log-failed143```144145## Guardrails146147- Keep each fix scoped to a single failure cause when possible.148- Do not bypass hooks (`--no-verify`) to force progress.149- If the failure is clearly unrelated to the PR and appears fixed on main, merge latest main instead of bloating the PR with unrelated fixes.150- If failures are flaky, retry once and report flake evidence.151- Re-run `gh pr checks --json name,bucket,state,workflow,link` after every push; the check set can change.152153## Output154155- Current CI status156- Failure summary and fixes applied157- PR URL once checks are green158159## Imported from cursor-team-kit/fix-ci (MIT, cursor/plugins)160161# Fix CI162163## Trigger164165Branch or PR CI is failing and needs a fast, iterative path to green checks.166167## Workflow1681691. Resolve the active PR and inspect `gh pr checks --json name,bucket,state,workflow,link`.1702. Inspect failed jobs and extract the first actionable error. Use GitHub Actions logs when available; otherwise use the check link to identify the failing command or service.1713. Apply the smallest safe fix.1724. Push, re-check the PR check set, and repeat until green.173174## Guardrails175176- Fix one actionable failure at a time.177- Prefer minimal, low-risk changes before broader refactors.178- Keep `gh pr checks` as the source of truth for overall PR CI state.179180## Output181182- Primary failing job and root error183- Fixes applied in iteration order184- Current CI status and next action185186---187> Source: [v1truv1us/ai-eng-system](https://github.com/v1truv1us/ai-eng-system) — distributed by [TomeVault](https://tomevault.io).188<!-- tomevault:4.0:skill_md:2026-06-15 -->