| name | team-personas |
| description | Use when the user asks about personas for agent teams, deep behavioral profiles for teammates, the productivity loop, or any of the 8 named personas (Auditor, Architect, Analyst, Refiner, Compounder, Facilitator, Visionary, Realist). Triggers: "personas", "behavioral profiles", "productivity loop", "auditor persona", "architect persona", "analyst persona", "refiner persona", "compounder persona", "facilitator persona", "what personas are available", "how do personas work".
Provides 8 reusable persona definitions that add deep methodology, scoring criteria, and interaction patterns to agent team teammates.
|
| version | 0.26.0 |
Team Personas
Deep behavioral profiles that transform brief teammate role descriptions into structured, methodology-driven agents. While team blueprints define what each teammate does, personas define how they think, score, iterate, and interact.
What Are Personas
A persona is a reusable behavioral profile that gives a teammate:
- Structured methodology — Named phases with specific steps and outputs
- Scoring criteria — Quantitative dimensions for evaluating work quality
- Interaction patterns — When to pause, check in, validate, and hand off
- Input/output contracts — What each persona consumes and produces
Brief role description (blueprint-style):
Analyst — Review the architecture for quality, reliability, and performance issues.
Persona-enhanced (full behavioral profile):
A Senior Engineering Analyst who evaluates through 4 sequential passes (Architecture → Code Quality → Reliability → Performance), rates each dimension 1-10 with specific evidence, produces a tradeoff matrix, and pauses after each pass to share findings before continuing.
Personas are optional — blueprints work fine with brief role descriptions. Use personas when you need consistent methodology, reproducible quality, or when a teammate's process matters as much as their output.
The Productivity Loop
The 5 personas form a continuous improvement cycle where each persona's output feeds the next:
┌─────────────────────────────────────────────────────┐
│ │
│ ┌──────────┐ ┌───────────┐ ┌──────────┐ │
│ │ Auditor │───▶│ Architect │───▶│ Analyst │ │
│ │ Discover │ │ Design │ │ Review │ │
│ └──────────┘ └───────────┘ └──────────┘ │
│ ▲ │ │
│ │ ▼ │
│ ┌────────────┐ ┌──────────┐ │
│ │ Compounder │◀─────────────│ Refiner │ │
│ │ Compound │ │ Iterate │ │
│ └────────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────┘
The loop is the mechanism. Individual personas produce good outputs; the loop compounds improvements over time because each cycle builds on the previous one's accumulated knowledge.
Using Personas
Mode 1: Full Productivity Team
Use all 5 personas together as a complete improvement cycle:
/spawn-create --mode productivity <workflow or process to optimize>
This spawns a sequential team where each persona's output feeds the next, culminating in a synthesis report with next-cycle recommendations.
Mode 2: Individual Persona
Apply a single persona to any teammate in any blueprint. Include this in the teammate's spawn description:
Read the [Persona Name] persona definition at:
${CLAUDE_PLUGIN_ROOT}/skills/team-personas/references/[name].md
Follow the methodology phases, scoring criteria, and behavioral instructions
defined in the persona. Your inputs come from [source] and your outputs
feed into [destination].
Replace [name] with the lowercase persona name: auditor, architect, analyst, refiner, compounder, facilitator, visionary, or realist.
Mode 3: Custom Composition
Use the team-architect agent to design a custom team that mixes personas with ad-hoc roles:
Design a team for refactoring our auth module. I want the Architect persona
for the solution design and the Refiner persona for iterative improvement,
but regular teammates for the implementation work.
The team-architect agent knows about available personas and suggests applying them where a teammate needs specific methodology, scoring criteria, or interaction patterns.
Two ways to deliver persona content to a teammate
| Approach | When | How |
|---|
| Persona reference file | The persona is reusable across spawns AND has consistent methodology (e.g., Auditor's 3-phase Discovery → Scoring → 4-Week Plan) | Teammate reads references/<name>.md at startup |
| Rich inline role description | The role is mode-specific and doesn't map to a reusable persona (e.g., planning's 7 mode-specific role compositions) | Role description is embedded directly in the spawn prompt |
The planning team uses rich inline descriptions because its 7 modes each need distinct role definitions. The productivity and brainstorming teams use persona reference files because their roles have consistent methodology across uses.
Catalog & registry
The full catalog (titles, tags, loop positions) and the per-capability matching guide live in registry.md. Use the registry when designing custom teams via the team-architect agent.
The 8 persona reference files (auditor, architect, analyst, refiner, compounder, facilitator, visionary, realist) live in references/ — each written in second-person ("You are...") so it can be directly injected into a teammate's behavioral context.
