$npx -y skills add hatch3r/hatch3r --skill hatch3r-ci-pipelineDesigns and optimizes CI/CD pipelines. Covers stage design, test parallelization, artifact management, and pipeline performance.
| 1 | # CI Pipeline Workflow |
| 2 | |
| 3 | ## Quick Start |
| 4 | |
| 5 | ``` |
| 6 | Task Progress: |
| 7 | - [ ] Step 0: Detect ambiguity (P8 B1) |
| 8 | - [ ] Step 1: Audit existing pipeline |
| 9 | - [ ] Step 2: Design stage structure |
| 10 | - [ ] Step 3: Optimize test parallelization |
| 11 | - [ ] Step 4: Configure artifact management |
| 12 | - [ ] Step 5: Implement and validate |
| 13 | ``` |
| 14 | |
| 15 | ## Step 0 — Detect Ambiguity (P8 B1) |
| 16 | |
| 17 | Before any work, scan the invocation for unresolved questions in scope, intent, acceptance criteria, target environment, or irreversibility. If any are found, ask the user via the platform-native question tool per `agents/shared/user-question-protocol.md`. Do not proceed under silent assumption. Default path, not an exception. Triggers for THIS skill: CI platform (GitHub Actions vs GitLab vs CircleCI vs Azure Pipelines), pipeline duration target, runner sizing budget, deploy gate (auto vs manual approval for prod), and artifact retention policy. |
| 18 | |
| 19 | ## Fan-out Discipline (P8 B2) |
| 20 | |
| 21 | Fan-out scales with task size; token cost never justifies serializing independent work (`rules/hatch3r-fan-out-discipline.md` P8 B2; `agents/shared/efficiency-patterns.md`). Emit `sub_agents_spawned: { count, rationale, task_structure }` in your output. |
| 22 | |
| 23 | ## Step 1: Audit Existing Pipeline |
| 24 | |
| 25 | - Map the current pipeline stages, their dependencies, and execution times. |
| 26 | - Identify bottlenecks: which stages take the longest? Which block others unnecessarily? |
| 27 | - Check for flaky tests that cause unnecessary reruns. |
| 28 | - Review resource usage: are runners appropriately sized? Are caches effective? |
| 29 | - Measure total pipeline duration from push to deployable artifact. |
| 30 | |
| 31 | ## Step 2: Design Stage Structure |
| 32 | |
| 33 | - Organize into logical stages: install, lint, typecheck, unit test, integration test, build, deploy. |
| 34 | - Maximize parallelism: lint, typecheck, and unit tests can run in parallel after install. |
| 35 | - Use fail-fast: if lint fails, skip tests. If unit tests fail, skip integration tests. |
| 36 | - Gate deployments behind all quality checks. |
| 37 | - Separate environment-specific deployment stages (staging, production) with manual approval gates for production. |
| 38 | |
| 39 | ## Step 3: Optimize Test Parallelization |
| 40 | |
| 41 | - Split test suites across multiple runners using test file sharding or test duration-based splitting. |
| 42 | - Use test timing data from previous runs to balance shard workloads. |
| 43 | - Run unit tests and integration tests on separate runners in parallel. |
| 44 | - For monorepos: only run tests for changed packages and their dependents. |
| 45 | - Cache test results for unchanged code paths where the test framework supports it. |
| 46 | |
| 47 | ## Step 4: Configure Artifact Management |
| 48 | |
| 49 | - Build artifacts once, deploy the same artifact to all environments. |
| 50 | - Tag artifacts with commit SHA and build number for traceability. |
| 51 | - Set retention policies: keep production artifacts longer, clean up PR artifacts after merge. |
| 52 | - Store build metadata (git SHA, branch, build time, test results) alongside artifacts. |
| 53 | - Use content-addressable storage or artifact registries appropriate to the project (npm, Docker, S3). |
| 54 | |
| 55 | ## Step 5: Implement and Validate |
| 56 | |
| 57 | - Implement pipeline changes incrementally — test each stage change in a feature branch. |
| 58 | - Verify caching works: first run populates cache, second run uses it (confirmed by cache hit log output). |
| 59 | - Confirm parallel stages don't have hidden dependencies causing race conditions. |
| 60 | - Measure pipeline duration improvement against the baseline from Step 1. |
| 61 | - Document the pipeline architecture for the team. |
| 62 | |
| 63 | ## Supply-Chain Floor |
| 64 | |
| 65 | A CI/CD pipeline is the supply-chain attack surface — design the floor in, do not bolt it on. The glob-scoped floor rules attach when you edit a workflow or Dockerfile; this callout surfaces them at pipeline-design time so the controls are planned, not discovered. Apply both rules as authored — this section cross-references, it does not restate: |
| 66 | |
| 67 | - `rules/hatch3r-dependency-management.md` — SHA-pin every GitHub Action to a 40-char commit SHA (not a tag); `npm ci` / lockfile-only installs; CVE scan gate before merge; npm Trusted Publishing via GitHub OIDC with `--provenance` (no long-lived publish token), attestations signed by Sigstore. |
| 68 | - `rules/hatch3r-container-hardening.md` — pin base images by `@sha256:` digest; generate an SBOM (CycloneDX or SPDX) in the build stage; cosign-sign images and verify by digest at deploy; distroless / Wolfi runtime, non-root user. |
| 69 | |
| 70 | Gate releases on these the same way Step 2 gates deploys on quality checks: a release stage that publishes without provenance + SBOM, or pulls an unpinned action / untagged base image, fails the gate. |
| 71 | |
| 72 | ## Pipeline Performance Targets |
| 73 | |
| 74 | | Metric | Target | |
| 75 | |--------|--------| |
| 76 | | Lint + typecheck | < 2 minutes | |
| 77 | | Unit tests | < |