Ci cd

Skill OutlineDriven/odin-claude-plugin/skills/ci-cd

Outline-Driven Development for Claude Code - 46 agents, 25+ skills, diagram-first methodology, AST-based editing, atomic commits.

Install

npx -y skills add OutlineDriven/odin-claude-plugin --skill ci-cd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Set up or modify CI/CD pipelines and deployment automation. Use when setting up build pipelines, automating quality gates, configuring test runners in CI, or establishing deployment strategies.

SKILL.md

4.6 KB, as published. Nobody here has run it

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.

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 review

No gate can be skipped. If lint fails, fix lint. Do not disable the rule. If a test fails, fix the code. Do not skip the test.

Note: The gates are language-general; only the commands change per ecosystem. The Node commands in the gates above map directly to other stacks. For example, Python (ruff check, mypy, pytest, pip-audit) or Rust (cargo build, cargo clippy, cargo test, cargo audit). Keep the same gate order regardless of language.

Feeding CI Failures Back to Agents

Read references/ci-failure-feedback-loop.md when a CI run has already failed and the failure needs to be routed back to an agent for a fix. Skip it when setting up a new pipeline or adding a gate for the first time — that branch has no failure yet to feed back.

Reference materials

The gate order above is fixed. These supply the commands and config that realize it.

references/github-actions.md: workflow YAML for the quality pipeline, Postgres-backed integration tests, and Playwright E2E.
references/deployment-strategies.md: preview deploys, feature-flag lifecycle, staged rollouts, and the rollback workflow.
references/automation-and-environments.md: where env vars and secrets live across .env* and CI, plus Dependabot and branch protection.
references/ci-optimization.md: the slow-pipeline decision tree, caching, and job parallelism.
references/ci-failure-feedback-loop.md: the copy-error-to-agent feedback loop; read only once a CI run has failed.

Common Rationalizations

Rationalization	Reality
"CI is too slow"	Optimize the pipeline (see `references/ci-optimization.md`), 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

Production deploys without staging verification
No rollback mechanism
Secrets stored in code or CI config files (not secrets manager)

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