Doing More with Agents
View as markdownShelbi ships six agents: the orchestrator, developer, and review
roles that run the core loop, plus three reviewer presets (qa,
security, and adversarial). None of them is privileged machinery. An
agent is just a role: a system prompt plus an
optional skill set. Nothing stops you from authoring your own and dropping
it onto a workflow status, exactly the way the built-ins are wired.
This guide builds one worth having and shows where it goes.
The Adversarial Review agent already ships
The worked example below builds an adversarial reviewer from scratch,
because doing it once teaches the whole author-and-wire mechanism. If you
only want the reviewer, you already have it: the shipped adversarial
preset (alongside qa and security) is the same role, materialized and
ready. Skip to Add it to a
workflow and name
agent: adversarial on a status to wire the shipped one in one line.
The worked example: an Adversarial Review agent
The core loop is optimistic. The developer implements a task and marks it
review-ready; the review agent serves the finished branch to a human.
Nothing in that path is trying to prove the change is wrong (that's the
job of the shipped adversarial, qa, and security reviewers, which is
why they exist).
An Adversarial Review agent is that missing skeptic. Its job is not to
approve a change. It's to try to break it: find the bug, the injection,
the unhandled error, the edge case the tests quietly skip. It reads the
diff on the task's branch, writes up what it finds with severity and
file:line references, and only signs off when "no issues found" has
actually been earned.
Slotted between "in progress" and human review, it becomes an automated adversarial pass that every task walks through before a person spends attention on it. The developer's optimism gets a counterweight, and the human reviewer arrives to findings already on the table instead of a blank diff.
This is the same "a reviewer is a role you can drop on a status" idea the Agents concept describes: a task is the work, a workspace is the capacity, and the agent is the role that decides how the work gets done. Here we author a new role and give it a status to own.
Other agents you could build
The Adversarial Review agent is a gate: it reviews work and can send it back. That's one of two shapes a custom agent tends to take, and the distinction is worth keeping in mind as you design your own.
- Gate agents review a task and can bounce it back to an earlier status when they find problems. They rely on send-back, which the reviewer here uses to return work to the developer.
- Producer agents do work and hand off forward when they're done, the
way the
developermarks a branch review-ready.
A few worth having (the first two ship as presets already, the rest are yours to author):
- Security reviewer (gate) — audits a branch's diff for injection,
broken authorization, leaked secrets, and risky dependency bumps. Ships as
the
securitypreset; wire it onto a status to use it. - QA (producer + gate) — exercises a change against its acceptance
criteria and reports pass or fail with repro steps. Ships as the
qapreset. - Docs writer (producer) — keeps docs, READMEs, and the changelog in sync with a code change, then hands off forward.
- Performance reviewer (gate) — flags regressions, N+1 queries, and hot-path allocations a diff introduces.
Each slots onto a workflow status the same way the Adversarial Review agent
does. A gate agent owns an active status between the work and the human
and needs a bounce edge declared in the workflow's transitions. A
producer agent owns a status where its output is the deliverable, then hands
off forward.
Where to go next
The guide is two parts. Author the agent, then wire it in:
- Create the agent →
— scaffold
adversarial-reviewwithshelbi agent new, understand theinstructions.md/ preamble / skills model, and drop in a concrete, usable skeptic prompt. - Add it to a workflow →
— declare an
adversarial-reviewstatus, point it at the new agent, and rewire the transitions so a branch flows through the automated review on its way to a human.
See also
- Agents — the role/task/workspace model, the six shipped agents, and how a custom one slots in.
- Understanding Workflows — the branching models a workflow can implement, if you want to place this review gate inside a larger shape.