Code review

A branch is ready for review. How to get an analysis that stays in the project and is linked to the tasks.

The situation

The branch is ready. You want an analysis — not "looks fine", but concrete findings. And you want it not to vanish into a chat: two weeks later, when the same problem resurfaces, it helps to see that it was already discussed.

What you do

Decide what to do with the findings. A review is an opinion, not a verdict. You will reject some of them, and that is fine.

Re-run after fixes. Each run adds an iteration rather than overwriting the previous one: what changed between passes stays visible.

What the agent does

in the agent session, on the branch with the finished code

/flownix-review AF-TASK-42

The slug is optional — without it the review covers the current diff and links to nothing. Naming the task costs one word and pays for itself in a fortnight.

What sits behind that:

get_node_by_slug(slug: "AF-TASK-42") — what was supposed to come out in the first place.
rag_query over the touched subsystem: a "we do not do it that way here" finding should rest on where that is written down.
Analysis of the git diff and the findings themselves.
create_review with the commit hash and the verdict text, set_review_nodes to link it to the tasks.

A rerun after fixes adds an iteration (add_review_iteration) instead of overwriting the previous one:

in the agent session, after the fixes

/flownix-review AF-TASK-42

What comes out

The review lives in the project's "Reviews" tab, linked to tasks, with a history of iterations. From a task you can see it was reviewed; from a review, which tasks it touches.

Repeat runs accumulate: the first iteration with findings, the second after fixes, a third if needed. The whole trail of corrections stays visible.

Limits

The agent does not replace a human reviewer where the decision is architectural. It is good at spotting divergence from recorded decisions and at catching carelessness; it is poor at deciding whether the thing should have been built that way at all.

The quality of findings depends on what the project records. On a project with no spec and no documents there is nothing to check against, and the agent falls back on generic style advice.