Engineering Loops

ACTION

Run [test suite] N times and collect every test whose result changes between runs. Fix the most frequent flake at its root cause (shared state, timing, ordering, or an external dependency), never with a blind sleep or retry.

CHECK

Re-run the fixed test N times, then the whole suite once, and confirm the flake is gone and nothing else regressed.

STOP

Stop when N consecutive full-suite runs pass clean, or progress stalls for two rounds.

ACTION

Upgrade [dependency] to [target version]. Read the changelog and migration guide first, then make the smallest set of changes needed, one package at a time.

CHECK

After each change run the full build, type-check, and tests, and confirm no new failures versus the baseline you recorded first.

STOP

Stop at a green build on the target version, or when a breaking change needs a product decision.

ACTION

Before any work starts, write a contract of what complete means and what evidence proves each requirement, then work the task and gather that evidence.

CHECK

Mark each requirement only when its required evidence exists, and do not claim done without the evidence.

STOP

Finish only when every requirement is proven by evidence; otherwise stop as blocked, stalled, or out of budget with a requirement-to-evidence table.

ACTION

Run two roles in a loop: a builder that implements the next item on the plan, and a checker that runs tests, typecheck, and lint and reports exactly what broke; feed every failure back as the next instruction.

CHECK

The checker, not the builder, must confirm tests, types, and lint are clean before an item counts as done.

STOP

Stop when the build is green and the checker has nothing left to report.

ACTION

Before doing any work, rewrite the request into a precise goal: the exact end state, how you will verify it, what you must not touch, and the stop condition; confirm that goal, then execute against it.

CHECK

Judge execution against the written goal verification criteria, not the original vague ask.

STOP

Stop when the goal end state is verified, or surface the goal for correction if it cannot be made precise.

ACTION

Refactor [module] for clarity without changing behavior; first confirm there is green test coverage (add characterization tests if missing), then make one small structural change at a time.

CHECK

Run the full test suite after every change and revert immediately if anything goes red; behavior must stay identical.

STOP

Stop when the target structure is reached with all tests still green, or when a change would alter behavior, in which case stop and ask.

ACTION

Write the tests for [feature] first from the expected behavior, run them, and confirm they fail for the right reason; commit the failing tests, then implement until they pass without modifying the tests.

CHECK

After each change run the full suite; a change only counts when the previously failing tests pass and nothing else regresses.

STOP

Stop when all target tests pass with the tests unmodified, or progress stalls and the spec needs clarifying.

ACTION

For [bug], first write a minimal failing test or script that reliably reproduces it, then form one hypothesis about the root cause and make the smallest change to test that hypothesis.

CHECK

Re-run the reproduction after each change; only accept a fix when the repro passes and the full suite stays green.

STOP

Stop when the bug is fixed and a regression test is added, or after several hypotheses fail and you need more information.

ACTION

Before writing code for [task], first explore by reading the relevant files and reporting what you find without editing; then write a plan; only after the plan is approved, implement it and write tests for the key parts.

CHECK

Verify the implementation against the plan and run the full test suite; every planned item must be done and all tests green before continuing.

STOP

Stop when the plan is fully implemented with passing tests and a descriptive commit or PR is ready, or when the plan needs a human decision.