CI Pipeline from Scratch
Build a continuous-integration pipeline that installs, lints, tests, and builds on every push/PR — fast, cached, and gating merges on green. Scopes the pipeline contract FIRST — triggers, the job/stage graph, the matrix, caching strategy, and the gates — then writes the CI workflow YAML, then a reviewer validates the syntax, stage ordering, caching, and that it actually fails on a broken build. Covers CI triggers, job/stage dependencies, dependency caching, build matrices, status checks, fail-fast gating, and a valid workflow file.
Steps
Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.
- Scope the pipelineplannerentry
lock triggers, stages, matrix, caching, gates
Show working prompt
Scope the CI pipeline before writing YAML. Step 1: Decide the triggers (push to which branches, pull requests, manual). Step 2: Lay out the job/stage graph: install → lint → test → build, including which stages can run in parallel and which depend on others. Step 3: Decide the matrix (e.g. OS/runtime versions) and the caching strategy (cache the dependency store keyed on the lockfile) to keep runs fast. Step 4: Define the gates: which stages must pass to mark the check green and block a merge, and fail-fast behavior. Step 5: Write a numbered acceptance-criteria checklist of 5-9 items (e.g. 'the workflow triggers on push and PR', 'dependencies are cached', 'a failing test fails the pipeline and blocks merge', 'lint/test/build run in a sensible order'). `write_task_note` the scope + checklist and write the same to the produces path.
- Write the workflowdeveloper
implement the CI workflow YAML
Show working prompt
Author the CI workflow file to the scope. Step 1: Set the triggers and the matrix exactly as scoped. Step 2: Define the jobs/stages with their dependency edges (test depends on install, etc.) and a checkout + runtime-setup step. Step 3: Add dependency caching keyed on the lockfile so repeat runs are fast. Step 4: Run lint, test, and build as gating steps so any non-zero exit fails the job. Step 5: Ensure the file is valid YAML for the target CI system and that the failing-test case would actually fail the run. Write the workflow to the produces path. On a loop-back, fix only the named gaps. `write_task_note` the file path and which criteria now pass.
- Verify the workflowreviewer
confirm syntax, ordering, caching, gating
Show working prompt
Verify the CI workflow. Step 1: Confirm the file parses as valid YAML and conforms to the target CI system's schema (lint it if a linter is available). Step 2: Confirm the triggers, matrix, and stage-dependency ordering match the scope. Step 3: Confirm caching is wired to the lockfile and the cache key is sensible. Step 4: Trace the gating logic and confirm a failing lint/test/build step would fail the run and block a merge (no `continue-on-error` masking failures). Write a verification note with the YAML-validity result and the gating trace to the produces path.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Validate the workflow file. For EACH acceptance criterion: confirm it is valid YAML for the target CI system, confirm triggers/matrix/stage-ordering match the scope, confirm dependency caching is wired correctly, and confirm a failing test would fail the pipeline and block merge (nothing masks failures). Write PASS/FAIL per criterion. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "build" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- set up ci
- create a ci pipeline
- github actions workflow
- build a ci/cd pipeline
- add automated testing on push
Source
View this craftbook on GitHub · MIT license