← ClaudeAtlas

ci-designlisted

Vocabulary and principles for well-designed CI. Use when the user wants to design, review, or audit CI, says CI is noisy, slow, or expensive, or is designing a workflow yml.
ConnorGriffin/skills · ★ 20 · Web & Frontend · score 66
Install: claude install-skill ConnorGriffin/skills
# CI Design Design CI so cost tracks the surface area actually touched, not the number of pushes. Use this language wherever CI is being designed, reviewed, or audited. ## Priorities Fix in this order — each tier assumes the ones above it are already sound: 1. **Minutes and billing waste.** Runner tier, caching, unconditional jobs. Money leaks here even when every run is green. 2. **PR feedback latency.** How long a contributor waits to learn a push is good or bad. Concurrency and trigger surface live here. 3. **Run and notification volume.** Duplicate or invisible checks, noisy scheduling. Annoying, but cheaper than the first two. Baseline failure noise (a flaky test, a known-red job) matters less than any of these — it's visible and locally fixable. Structural waste isn't; it compounds silently across every run. ## Vocabulary Use these terms exactly. **Trigger surface** — the product of events, branches, and paths that fire a workflow (`on: push/pull_request` × branch filters × path filters). The trigger surface is the first lever: a workflow that fires on every push to every branch has a trigger surface many times larger than the work it actually needs to validate. **Path filtering** — restricting a job to run only when files it cares about changed. The required-checks-safe pattern: never put `paths:` at the workflow level on a job that's a required status check — GitHub can leave a required check permanently pending if its workflow never triggers. Instea