Doing More with Agents

View as markdown

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 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 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 → — 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 → — 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 — 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.