Skip to main content
A persona is the answer to “who is the agent in this repo?” — a versioned profile injected at session start that sets the agent’s stance before any work begins. Where plans say what to build and hooks enforce how commits land, the persona shapes how the agent behaves between those two.

​
What a persona contains

Each persona is a profile with two blocks:
  • a system block — bundled with tiny-brain, versioned, and updated with the plugin. It defines the stance: what to read before writing, which skills to reach for, what’s out of scope.
  • a user block — yours. Custom rules and details layered on top of the system stance, preserved across plugin updates.
tiny-brain ships with the developer persona. Its stance is a compact statement of the whole system: be pipeline-led (the review pipeline is the quality bar), be skill-first (/plan, /fix, /spike, /adr before improvising), let hooks own tracking state, use the repo’s own script commands, and read the repo’s context files before writing code. Just as important is what it rules out — inventing phase models, re-running reviews the pipeline will run anyway, hand-editing tracking files.

​
How it reaches the agent

The session-start hook injects the active persona’s context into the session; the same content is available directly: 
tiny-brain as developer
The default persona is set in the repo’s tiny-brain config (defaultPersona), so every session in the repo starts from the same identity — regardless of which AI tool opened it.

​
Why this exists

Without a persona, every session re-negotiates its working style from scratch, and two sessions in the same repo can behave like two different engineers. With one, the discipline is repo-level: the stance travels with the repository, survives across sessions and tools, and can be tuned by the team in the user block without forking the bundled rules.