---
name: verification-loop-runner
description: "Sets a loop for working on code: after each change run the matching tests and checks, record the evidence, and only then move to the next change. Use when a multi-step code task needs each change followed by its tests and checks, with evidence recorded before the next change starts. Do not use for writing the tests themselves or planning the architecture of a feature. Related topics: coding, productivity."
---

# Verification Loop Runner

Sets a loop for working on code: after each change run the matching tests and checks, record the evidence, and only then move to the next change.

## When to use

Use this skill when a multi-step code task needs each change followed by its tests and checks, with evidence recorded before the next change starts. Do not use it for writing the tests themselves or planning the architecture of a feature.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Split the task into the smallest changes that can each be checked on their own.
3. Before each edit, state the check that will prove the change, such as a failing test or an observable behaviour.
4. Make the change, run the chosen scope of checks, and record the exact command and result.
5. Fix any failure before starting the next change, so work never stacks on a red result.
6. Run the full set of checks once at the end and report done or not done against the definition of done.

## Inputs

- **The task** (longer free text)
- **Repository checks available** (longer free text)
- **Test scope per change** (choose one: Only affected tests, Affected plus integration, Full suite)
- **Where to record evidence** (choose one: Reply in chat, A progress file, Commit messages)
- **Stop on first failure** (choose one: Yes, No)
- **Definition of done** (longer free text)

## Output

A table with one row per change showing the check run, result, and evidence, followed by a plain done or not done statement and any check that could not run.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Verification Loop Runner

Work through this task one verified change at a time.

- The task: {{The task}}
- Repository checks available: {{Repository checks available}}
- Test scope per change: {{Test scope per change}}
- Where to record evidence: {{Where to record evidence}}
- Stop on first failure: {{Stop on first failure}}
- Definition of done: {{Definition of done}}

Split the task into the smallest changes that can each be checked alone. For each one, write down the check that will prove it before editing: a test that fails now, a command output, or a behaviour to observe. Make the change, run the chosen scope of checks, and record the exact command and its result as evidence. If anything fails, fix that before touching the next change; never stack new work on a red result. After the last change, run the full set of checks once, compare against the definition of done, and list any check you could not run and why.

Report as a table with one row per change: change, check run, result, evidence. Finish with a clear statement of done or not done.

## Pitfalls

- Running only the new test and missing a regression elsewhere that the broader scope would catch.
- Recording that checks passed without the command output, which leaves nothing to verify later.
- Batching several edits before running anything, so a failure cannot be traced to one change.