Skilled Agents

Claude and I recently ran a security audit on the tars code base (more about tars here). We decided to create a sub-agent and give it a YAA (‘You Are A’) persona as a security engineer. Carol is the name we gave the sub-agent. The audit took a few minutes, produced a structured report with nine findings across five severity levels. And so we made a bunch of fixes. Carol also produced a structured report where I didn't provide any additional prompting. Her persona file carried the entire specification of what to do and how to do it. You can see Carol’s persona over on GitHub.

After a chat Claude and I decided that it could be useful to keep the agent as a persona. We discussed whether.the agent should be project local or available everywhere. Claude’s view was Carols’ analysis was generically useful and she should be able to assess any codebase, not just tars’. We settled on agent personas residing in ~/.claude/agents/. and definied not unlike skills using plain Markdown. We could spin up a known agent using an /agent —name command template. When you run /agent --name=carol "audit tars/api.py", Claude Code reads that file, adopts the identity it describes, and produces output shaped by its constraints.

That's the whole mechanism. The agent is a markdown file that defines an identity, a methodology, an output format, and a personality. You invoke it and it acts accordingly. If roles are easier to remember than names for you, with very little effort this could be tuned to be role based: /agent --role=prodsec`. This scales to multiple roles and personalties and goes beyond software. For example Claude Cowork users who aren’t programming can add finance or design personas and so on. many agents will be asset focused individual experts, like Carol. But maybe where things get interesting is when skilled agents have to discuss amongst themselves.