CI Pipeline Architect

A continuous integration pipeline is a product whose users are your own engineers, and its features are speed, signal, and trust. This skill designs or overhauls pipelines around the one metric that compounds: time from push to trustworthy verdict. It sequences stages by information value, spends caching where it pays, and treats flakiness as an outage in the trust budget rather than a fact of life.

When to use this skill

• Standing up a pipeline for a repository that has none
• A pipeline has grown slow ("forty minutes to red") or noisy enough that engineers merge past it
• Consolidating copy-pasted pipeline configs across services into one maintained pattern
• Adding a new class of check (integration tests, packaging, security scanning) without wrecking cycle time

Workflow

1. Measure before designing. For an existing pipeline: wall-clock by stage, failure rates by check, and where reruns concentrate — a rerun is an engineer voting that a check lies. For a new pipeline: list the failure classes worth catching, ranked by frequency times cost.
2. Order stages by information per second. Cheapest, highest-signal checks first: compile and type checks, lint, fast unit tests. Expensive suites run only after cheap ones pass — a type error should never wait on an integration environment to boot.
3. Split what can parallelize; share what repeats. Fan independent suites out across workers; pull repeated setup (dependency install, compilation) into a cached or prebuilt step. Cache keys derive from lockfiles and toolchain versions — a cache that can go stale silently is a future afternoon of debugging a ghost.
4. Define the merge gate explicitly. Which checks block merging and which merely report? Blocking checks must be deterministic, fast enough to respect, and owned by someone. Advisory checks post results without gating; promotion to blocking is an explicit decision made after they prove stable.
5. Build the flake protocol in from day one: automatic retry-once with every retry recorded as data, a quarantine list that removes a test from the gate while keeping it running and visible, and a standing rule that quarantined tests carry an owner and an expiry date.
6. Make failures debuggable from the failure page: logs grouped per step, artifacts (test reports, build outputs, screenshots) retained with sensible expiry, and the failing command printed so an engineer can reproduce it locally, verbatim.
7. Document the pipeline as an interface: what runs when, what blocks what, expected total time, and how to run each stage on a laptop. A pipeline nobody can reason about gets worked around, and a worked-around pipeline is decoration.

Output format

Deliver a stage map plus the decisions behind it:

Stage map: <stages, dependencies, parallelism, expected duration each>
Merge gate: <blocking checks> | Advisory: <reporting-only checks>
Caching: <what is cached, keyed on what, invalidated when>
Flake protocol: <retry policy, quarantine rules, ownership + expiry>
Local parity: <how each stage runs on a developer machine>

Guardrails

• Total time to verdict on the common path stays inside a stated budget — fifteen minutes is a defensible default. Any stage added must say what it displaces or why the budget moves.
• No check joins the merge gate without a measured stability period as advisory first.
• Secrets never appear in pipeline logs or in config committed to the repository; they arrive through the platform's secret mechanism, scoped to the stages that need them.
• Pipeline config is code: reviewed, versioned, and deduplicated through the platform's reuse mechanism rather than copy-pasted between repositories.
• A red default branch is the pipeline's highest-priority page. The design must make "who fixes red" unambiguous, or red becomes wallpaper within a month.