When I ask Bob to review code, I want it to look for bugs, explain what it found, and leave the files alone while I decide what to change. I also want to use the same checklist next time, without writing the whole review prompt again. That's where the idea of an agent persona starts to make sense to me.

A persona gives an agent a particular role: what to pay attention to, how to report its findings, and which boundaries to follow. “You are a senior developer” is a start. A checklist and a clear description of the expected result give Bob much more to go on.

In Bob Shell 2.0.5, you can put that role into a named subagent. That's the mechanism behind the example here. “Persona” describes the instructions we're giving it, rather than a separate feature you need to enable.

A reviewer with a clear brief

A subagent is a helper Bob starts for a focused task. It has its own conversation context and returns its findings to the main conversation. That lets it read through code without filling the main conversation with every search and file it opens. Bob's subagent documentation explains the mechanics.

For a review I expect to repeat, I can give that helper a name and keep its instructions in the project. Create .bob/agents/code-reviewer.md with this content:

---
name: code-reviewer
description: Reviews Java code for correctness and error handling.
groups:
  - read
---

You are a code reviewer on a Java team.

Review the files named in the task. Read related code when needed
to understand their behavior.

Focus on:
1. Logic errors, null handling, and missing input validation.
2. Error handling that hides failures or loses important information.
3. Names or structure that make the code difficult to understand.

Return a table with severity, file and line, finding, and reason.
Put correctness problems first. Distinguish confirmed problems
from questions that need more context.
If you find no issues, say so. Do not invent findings.
Do not edit files.

The name lets me ask for this reviewer again. The body holds the review instructions, and groups limits the helper to the parent's available read tools. That tool setting keeps editing and command execution out of this review.

Keep groups on multiple lines exactly as shown. In Shell 2.0.5, the shorthand groups: [read] isn't parsed as a list and falls back to broader tool groups.

Save the file, then start a new task in Agent mode in a trusted project, with subagents enabled. The new task loads the definition. Ask Bob:

Spawn a subagent named code-reviewer.
Review src/main/java/com/example/OrderService.java.
Delegate the review to that subagent and return its findings.
Do not change any files.

Replace the path with a file in your project. Approve the subagent when Bob prompts you. Naming code-reviewer explicitly tells Bob which definition to use.

What I get from keeping the role in a file

The next review starts with the same instructions. If the checklist needs a project convention, I can add it to the file. Committing it with the repository also lets a teammate use the same reviewer and suggest improvements to its brief. In Shell 2.0.5, keep the definition in each project's .bob/agents/ directory; a copy in your home directory isn't loaded.

For a one-off task, you can put the role directly into the request to Bob's built-in read-only explore subagent. A saved definition earns its place when you expect to ask for that role again.

The checklist won't make every finding correct, so I still need to read the result and decide what to act on. What it gives me is a review brief I can inspect, improve, and share. I'd start with one recurring task and a short set of instructions. For me, code review is a good place to begin.

If you want to read more tips and tricks about Bob and agentic coding, make sure to also visit my Bob topic page on The Main Thread!