Personas & categories

Reusable identities for the agents doing your work, and categories to group them in their libraries.

A persona is a reusable identity for a step's agent: a name, an icon and colour, and above all a system prompt. Attach one to a step and the transcript shows who is working — the same reviewer, spec writer, or security auditor serving every workflow in the project.

Defining one

Personas live in the Personas library — the editor, the dashboard, the Mac app, or a phone:

# persona/security-reviewer.yaml
id: security-reviewer
name: Security Reviewer
icon: shield
color: red
description: Reviews changes for security implications.
prompt: |
  You are a security reviewer. Focus on authentication, authorization,
  injection, and secrets handling. Prefer the smallest safe change.

name and prompt are required; the icon defaults to a person and the colour to grey. The editor has an AI "improve prompt" helper, and the setup wizard offers a starter roster — Engineer, Spec Writer, QA Engineer, Security Reviewer, Technical Writer, and friends — that you can adopt and edit.

Using one

- type: prompt
  prompt: Review the diff for security issues and fix what you find.
  personas: [security-reviewer]

The persona's prompt becomes part of the step's system prompt. The full layering, outermost first: your organization's agent instructions, the project system prompt, the workflow's base prompt, then the step's personas. The transcript shows all of them, each openable on its own.

A persona is deliberately not a model choice — pick models per step or per workflow in Agents & models.

More than one

A step can wear several personas, and often should. A step is regularly a frontend engineer and the house reviewer, and writing a third persona that repeats both is how a library stops being reusable.

- type: prompt
  prompt: Build the settings screen, then review your own diff.
  personas: [frontend-engineer, security-reviewer]

They layer in the order you list them, and the run badges the step with each of them. The older singular persona: still works and means a stack of one.

Categories

Workflows, personas, and triggers can each be grouped into categories. They are optional and invisible until you create one — no headers, no "Uncategorized" bucket, nothing to configure in a fresh project.

• Create, rename, delete from the library's header. Deleting a category leaves its members in place, just unfiled.
• Filing is drag and drop — drop a row on a group header to file it, drag past the last group to unfile. On a phone, use the row's "Move to category…" menu.
• Pickers follow along. Anywhere you choose a workflow or persona, categories render as submenus, with unfiled items last.
• Searching flattens the list. A category's name matches all its members. An item belongs to at most one category.

Categories are per library and per scope, so your organization's shared library and a project's own library each have their own.