Code-test-review

Code-test-review takes one task, usually from a spec, and doesn't stop until it's built, tested, reviewed and checked against what was asked for.

Starting it

Point it at what to build:

"Implement task 12.b from specifications/12-refunds/ using the code-test-review workflow."

"Build the sign-up endpoint described in PAY-412, test it and review it."

It needs something to build against: a spec, a ticket, or a clear written description. It also needs a feature branch. If you're on main, Slo creates one first, named after the ticket when there is one.

What happens

Step 1: Code and test, in small pieces

Slo writes a small piece of the change, tests it, gets it green, and only then writes the next piece. It doesn't write a thousand lines and hope.

For each piece it finds every decision point (each if, early return, try/except and branch) and writes a test for each path. Tests are named after the behaviour they check. The step ends when the whole suite passes.

Your conventions apply throughout: named arguments, type hints, docstrings, and whatever your own skills and SLO.md add.

Step 2: Review

Slo reviews the change against the spec. It isn't a style pass. It looks for:

  • Requirements that are missing or only half done.
  • Behaviour that's wrong, or edge cases that aren't handled.
  • Security problems, such as injection, secrets in code or missing auth checks.
  • Convention breaks, including names that don't match the rest of the codebase.
  • Decision points without a test.

Anything serious goes back to step 1 to be fixed.

Step 3: Completion check

With fresh eyes, Slo scans the code against the spec's full list of deliverables, layer by layer, and marks each one done, partial or not started. You get a completion percentage and, for anything unfinished, exactly what to build and where.

If it's under 100%, the workflow loops back to step 1. It finishes when the tests are green, the review has nothing serious left, and the check reaches 100%, or when you say the remainder can wait.

Controlling the pace

By default Slo pauses after each step and waits for you. Say "continue" to move on, or give a correction. To run straight through, ask for it: "run it to completion".

Shipping

Code-test-review stops at reviewed code. Committing and opening the merge request is a separate step, so you can check the work first:

"Commit this with a message that says what changed and why, push it, and open a merge request."

See From spec to merged PR for the whole path.

Just the part you need

Each step also works on its own:

  • "Review my current changes against the spec."
  • "Is task 12.b complete? List what's missing."
  • "Write tests for every decision point in services/refunds.py."