Ci cd

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

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.From its SKILL.md

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.

SKILL.md

4.6 KB, ~1.0k tokens by cl100k_base, 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

What ships with it: 5 files

7.0 KB alongside SKILL.md

references/

Gives 1 of the 12 instructions most ci cd skills give in ~1.0k tokens

Counted across 343 of the 355 authors here whose files we hold, read 2026-09-06

Pin third-party actions to full commit SHAin 34 of 343, across 29 files
Set timeout-minutes on every jobin 23 of 343, across 17 files
Deploy to staging before productionin 18 of 343
Use OIDC instead of stored cloud credentialsin 18 of 343, across 12 files
Pin action versionsin 14 of 343, across 13 files
Cache dependencies keyed on the lockfile hashin 14 of 343, across 13 files
Declare least-privilege permissions at workflow and job levelin 13 of 343, across 7 files
Pass untrusted values through env variablesin 13 of 343, across 9 files
Create efficient GitHub Actions workflowsin 11 of 343, across 5 files
Cache dependencies via setup actions or actions/cachein 11 of 343, across 5 files
Cache dependencies to speed up buildsin 11 of 343
Store secrets in secret managershere, and in 11 of 343, across 10 files

Said here and by no other author read

Keep the same gate order across languages
Feed CI failures back to the development loop

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.