Why a command does not do everything itself
A command is what you type. An agent is who it hands a piece of the work to, with a narrow job and instructions of its own. The split is deliberate: the one who decides what the work is does not also decide it has been done, and the one who writes the code is not the one who signs it off.
You never call an agent directly. Commands do that, and the report tells you which ones ran. Every agent's full instructions are readable in the panel under AI instructions in the side menu, in your account's language; one not translated yet is shown in English, with a notice saying so.
The eight agents
| Agent | What it is responsible for |
|---|---|
analyst |
Finds what is ambiguous before anything is built, and returns the gaps. Handed a document to check, it also reads each claim the document makes about how your system behaves today against the code, and marks each one verified or contradicted. It does not write code, and it does not decide what to do with either list — the command that called it does. |
developer |
Implements what the requirements settled, following the patterns already in your codebase, and nothing beyond them. |
frontend |
Everything a person sees: templates, component markup, and the files under your resources folder. It reads the styling standard every time rather than from memory, and does not touch backend logic. |
ux-designer |
Looks at the implemented interface as a user would: is the action findable, is the empty state explained, is the destructive button clearly different from the safe one. In a product with its own design layer it also checks that screens follow the catalogue and the identity manual with the fewest components. It proposes; it does not implement. |
code-reviewer |
Reviews code against the standards. It is the stand-in gate for when the analyzer cannot be reached, and a manual reviewer when you ask for one by name. |
tech-lead |
The architecture opinion: is the logic in the right layer, is something repeated that should be shared, would a developer meeting this code understand it quickly. Called when you ask for it, and also by /review when a finding keeps failing after repeated fixes or when the analyzer does not answer. |
documenter |
Writes the developer documentation for what was built, and keeps it in the project's own documentation folder rather than scattered through the code. When the command that called it asks, and the change is one a user would notice, it also writes what a user reads: the feature item, the guide when the flow needs steps, and — when /finish asks for it — the changelog entry. |
workflow-reviewer |
Reviews changes to the commands, agents and standards themselves — not your code. It catches a rule that is unclear, in the wrong place, or written as a narrow reaction to one bad run. |
The two pairs worth knowing about
frontend and ux-designer work in a cycle. After the interface is implemented, the designer reviews it and says what a user would trip over. Its proposals are proposals: they are shown to you and wait for your yes before anything is changed. The one exception is the design review /next runs on a plan /design-catalog wrote: you already confirmed that plan, so a correction that brings the build back to it goes to the queue without asking you again.
code-reviewer stands in, and says so. The analyzer is the authority on the standards. When the connection to it is down, the reviewer reads the code instead — and the result is reported as an internal review, never as an analyzer pass. Those are different things and you are always told which one you got. What the analyzer can and cannot settle is in What the analyzer cannot check.
When the toolkit itself changes
Changing a command, an agent or a standard is reviewed by workflow-reviewer before it counts as correct, and the review is run twice over the same wording — the same text handed to a reviewer twice does not always come back the same way.
That loop has a ceiling on purpose. When repeated rounds stop converging, or after ten rounds, the change ships as it stands and every finding left open is reported to you instead. Polishing wording forever costs more than it is worth, and the decision is put in front of you rather than absorbed silently.
Next
- What each command does — which command calls which of these.
- How a task travels — where in the run each one is used.