ci-pipeline-design

Designs CI pipelines with stage ordering, caching, sharding, and trigger routing for fast feedback.

1|Updated Jul 3, 2026
One-click install
npx skills add https://github.com/Nandansai08/skillz --skill ci-pipeline-design-nandansai08
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ci-pipeline-design
Source: https://github.com/Nandansai08/skillz/tree/main/skills/devops-cicd/ci-pipeline-design
Command: npx skills add https://github.com/Nandansai08/skillz --skill ci-pipeline-design-nandansai08

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Slow CI pipelines push developers toward batched commits, context switching, and admin-merge bypasses. This Skill provides a measured workflow for designing or overhauling a CI pipeline so pull request feedback stays under ten minutes. ## Core Features & Use Cases - Fail-fast stage ordering: Sequence lint, typecheck, unit tests, build, integration, and e2e smoke so cheap checks report first. - Caching and parallelism: Key dependency caches on lockfile hashes, shard tests by historical timing, and verify cache hit rates. - Trigger routing: Define what runs on PRs, merges to main, nightly jobs, and path-filtered monorepo changes, while keeping secrets away from fork PRs. - Use Case: A monorepo with a 28-minute serial pipeline gets redesigned with lockfile-keyed caching, four timing-balanced unit test shards, a PR smoke set, and Turborepo path filtering, bringing PR p95 feedback to about 7 minutes. ## Quick Start Ask the agent to analyze your current CI job timings and redesign the pipeline so PR feedback fits within ten minutes.

Frequently Asked Questions about ci-pipeline-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I speed up a slow CI pipeline?▼

Measure per-job timings first, then order stages cheapest-first, cache dependencies keyed on lockfile hashes, and shard tests by historical timing. Route heavy suites like full e2e to post-merge or nightly runs instead of every PR.

What should run on every pull request in CI?▼

PR checks should include lint, typecheck, unit tests, integration tests, and a small e2e smoke set, all fitting a ten-minute budget. Full e2e suites, artifact publishing, and benchmarks belong on merge-to-main or nightly triggers.

How do I cache dependencies in CI correctly?▼

Key the dependency cache on the lockfile hash, such as hashFiles('**/package-lock.json'), not on branch names or static keys. After setup, verify the cache hit rate, since a mis-keyed cache can report success while downloading everything.

How do I parallelize tests in a CI pipeline?▼

Split tests into shards balanced by historical timing rather than file count, using tools like pytest-split, Jest --shard, Playwright sharding, or a CI matrix. Aim for a few even shards, since too many small shards mostly pay startup overhead.

When should I not use this CI design skill?▼

Use github-actions-authoring for writing the actual workflow syntax, and e2e-test-triage for shrinking or stabilizing the e2e suite itself. This skill covers pipeline architecture and routing decisions, not syntax mechanics.

Why do fork pull requests pose a CI security risk?▼

Fork PRs can reach jobs that hold secrets or deploy credentials if triggers are not restricted. Deploy stages and secret-bearing jobs must run only from protected branches, making pipeline routing a security boundary.