CI gives the repository an independent place to run checks. Local hooks improve feedback time, but they do not replace a clean runner using the committed files.

Checkout → Install pinned dependencies → Build and test → Report failures
  1. 1Checkout
  2. 2Install pinned dependencies
  3. 3Build and test
  4. 4Report failures

Work through the example

Keep required checks reproducible and preserve nonzero exit codes through pipes. Run simulator jobs only where the runner supports them.

Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.

Implementation reference

The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.

1. Hook vs. CI vs. reviewer

Three enforcement layers. Use the cheapest one that can decide the question.

Layer Decides Cost Feedback speed
Hook Rules a script can evaluate ~free Immediate — model self-corrects mid-turn
CI Same, plus full build/test minutes After push
Reviewer subagent Judgment: is this correct, does it match intent tokens End of task

The ordering matters. Spending a reviewer subagent on "did you use DispatchQueue.main.async" is waste — a grep answers that for free, instantly, and cannot be argued with. Reserve model judgment for what rules cannot express.

Rule of thumb: if you can write the check as a grep or an exit code, it is a hook. If it needs to understand intent, it is a reviewer.

Acceptance and failure review

Checkpoint What to inspect If it does not match
Checkout Confirm the input and environment Preserve the failure and return to this step
Install pinned dependencies Inspect the intermediate artifact Preserve the failure and return to this step
Build and test Run the focused check Preserve the failure and return to this step
Report failures Record the observed result Preserve the failure and return to this step

Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.

Evidence and limits

A workflow file is not a successful run; inspect the actual job result.

This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.

Inspect the source used in this lesson.

What to do next

Next: Subagents for iOS: splitting review, build and design across agents