04 / 10 · Agents

The four work-horse agents

An agent is a specialized "personality" of Claude — a system prompt plus tool list bundled into a markdown file. You spawn one when you want a particular kind of thinking.

Why agents change outcomes

Same model. Same code. Different outcome — because the frame is different.

Ask the default Claude to "look at this file and propose a refactor" and you get an okay answer. Ask the Senior Engineering Mentor agent to do the same thing and it does the job as a senior engineer would: looks for DRY violations, SRP violations, verbosity, dead code, convention drift; groups its findings into a table; presents the table before changing anything; waits for your approval; runs rubocop; re-runs the relevant specs.

The frame lives in the agent's system prompt. It says things like "your job is to find DRY violations" and "always present findings as a table before refactoring." Those instructions become the agent's worldview for the duration of its run.

This is why the slash commands route to specific agents. /cleanup runs the Senior Engineering Mentor. The cleanup is not "Claude scans the diff" — it is "the senior engineer scans the diff."

The four work-horses

Software Engineer

The default for /implement_jira. A planning-and-implementation persona, structurally biased to plan first. Pulls the ticket, renames the branch, drafts the plan, waits for your approval, executes in dependency order, runs specs.

Frame: "engineer + planner," not "code generator." Tilts behavior toward "first understand, then write."

Senior Engineering Mentor

The pre-PR cleanup agent. Reviews diffs for DRY violations, SRP violations, verbosity, convention drift. Presents findings as a markdown table before changing anything. Refactors on approval, runs rubocop, runs related specs.

Frame: "senior engineer mentoring a junior" — produces prioritized findings with rationale, not aggressive rewrites.

Documenter

Writes long-form, durable markdown about how a service / workflow / lifecycle / subsystem actually works. Built for the case where the code is correct but unreadable to anyone who didn't write it.

Frame: "researcher and writer." Reads code as a journalist reads sources — broadly, then deeply. Produces narratives, not file-by-file commentary.

Jirid

The Jira-heavy agent. Creating tickets, refining tickets, transitioning, linking, sprint operations. Knows custom field IDs, transition IDs, link type IDs, and the gotchas (e.g., customfield_10058 looks like Story Points but is screen-restricted; use 10023).

Frame: "ticket scribe with a clipboard." Validates field formats before acting.

Plus the built-ins you'll reach for

Explore — fast, read-only search across many files. Use when "where is X" or "find every place that uses Y" needs to span tens of files. Keeps results out of your main session context.

Plan — architectural-planning agent. Reads code; designs an implementation strategy; returns a plan. Does not write code. Useful when you want the plan as a deliverable separate from execution.

general-purpose — the catch-all. Multi-step research that doesn't fit the specialists.

When not to spawn one

Trust but verify. A sub-agent's summary describes what it intended to do, not necessarily what it did. After a spawn, check git diff or read the relevant files. The agent's text summary may not match what's on disk.