# Doing More with Agents An agent is just a role, a system prompt plus a skill set, so nothing stops you authoring your own and slotting it into a workflow's statuses. This guide builds an Adversarial Review agent, an automated skeptic that tries to break a change before a human sees it, and wires it into a workflow. Shelbi already ships that reviewer as a preset; the guide is the mechanism behind it. Shelbi 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](/docs/concepts/agents) 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 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](/docs/guides/doing-more-with-agents/add-to-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](/docs/concepts/agents) concept describes: a task is the work, a [workspace](/docs/concepts/workspaces) 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](/docs/guides/doing-more-with-agents/adversarial-review-agent#how-send-back-works), 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 `developer` marks 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 `security` preset; 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 `qa` preset. - **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: 1. **[Create the agent →](/docs/guides/doing-more-with-agents/adversarial-review-agent)** — scaffold `adversarial-review` with `shelbi agent new`, understand the `instructions.md` / preamble / skills model, and drop in a concrete, usable skeptic prompt. 2. **[Add it to a workflow →](/docs/guides/doing-more-with-agents/add-to-workflow)** — declare an `adversarial-review` status, 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](/docs/concepts/agents) — the role/task/workspace model, the six shipped agents, and how a custom one slots in. - [Understanding Workflows](/docs/guides/understanding-workflows) — the branching models a workflow can implement, if you want to place this review gate inside a larger shape.