# CI CD And Automation > 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. - Skill: `tomevault-io/ci-cd-and-automation-9` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/ci-cd-and-automation-9` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/ci-cd-and-automation-9/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/ci-cd-and-automation-9 --- # 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: 1. Lint and format check 2. Type check 3. Unit tests with coverage 4. Build 5. Integration tests 6. Security scan 7. Deploy to staging 8. Smoke tests 9. 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 - [ ] Pipeline runs on every push and PR - [ ] Fastest checks run first - [ ] Each stage has clear pass/fail criteria - [ ] Deployment is fully automated - [ ] Rollback takes under 1 minute ## 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 1. Resolve the PR for the current branch. 2. Inspect current PR checks before waiting. 3. If checks already failed, diagnose those failures first. 4. If checks are pending, watch with `gh pr checks --watch --fail-fast`. 5. After each push, re-check the full PR check set and repeat until green. ## Commands ```bash # 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 --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 1. Resolve the active PR and inspect `gh pr checks --json name,bucket,state,workflow,link`. 2. 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. 3. Apply the smallest safe fix. 4. 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](https://github.com/v1truv1us/ai-eng-system) — distributed by [TomeVault](https://tomevault.io).