Workflow — review it, then prove it
Two built in, and you can write your own. Code review hands a change to the AI CLIs you have and consolidates what they find, marking anything two of them independently agree on. The release audit judges a whole project before you tag it, grading every finding by whether it was actually verified.
How to do it
- Open Workflow and point it at a repository.
- Pick a workflow — code review for a change, release audit for the whole project before a tag.
- Run it. Each gate reports what it ran and what happened.
- The exit gate is the answer: it clears every gate, or it is blocked and says which.
What a gate actually runs
Correctness runs `make test` if your Makefile has it, `npm test` if package.json does, `pytest` otherwise. Maintainability runs your linter. Security runs npm audit, pip-audit or gitleaks. Your commands, not ours.
More than one reviewer, when you have more than one
LLMLinq uses whichever AI CLIs are on your machine. With one, you get its review. With two or more they read at the same time and never see each other's notes, and anything they independently land on is marked as agreed — the strongest signal a review of this shape can give you. Nothing is hidden either way: a finding only one reviewer raised is still shown.
Your own review, if you want one
Make a workflow of your own: pick which CLIs do the work, and paste the prompt you already trust. Keep the JSON contract at the end and the findings are still charted by file and severity; drop it and the reply is shown as written instead. A review flow may carry any prompt — text is inert — while a gate flow may only choose from gates that already exist, because a gate carries a command.
Why the gates are deterministic
A check the model cannot argue with is the whole point. An agent asked whether its own work is good will say yes. A test suite will not. Every command a gate can run is fixed in LLMLinq — nothing asks an LLM what to execute, because an agent that could choose the command could choose one that passes.
Your project decides what the gate means
If your Makefile defines `lint`, that is what runs. You have already said which files, which rules and which exclusions; guessing at a generic command instead would report failures you deliberately excluded. Where you have declared nothing, LLMLinq falls back to the standard tool for your stack.
Skipped is not passed
A gate with no tooling behind it reports skipped and says so before the run, not after. Calling that a pass would mean the strongest green tick came from the weakest evidence. A skipped gate does not block shipping — refusing over a tool you do not use would only teach you to ignore the result.
Back-pressure
The one gate aimed at the agent rather than the code. A change too large for one person to review is refused, because three thousand lines is not more work delivered — it is work nobody will read, which is how unreviewed code ships.
Review is labelled as review
One gate asks a CLI whether a reader could tell what the change does and why. It is marked as judgement, not a check, so an agent saying "looks fine" is never rendered the same as a green test suite.
Your own workflows
Tick the gates you want and save them as a named workflow. A workflow chooses gates; it cannot introduce a command, so a workflow file is never a way to run something on your machine.