§ Discovery
/personas
Establish who the design is for, not just what it should look like.
What it does
Most AI design workflows treat “the user” as an undifferentiated abstraction — a stand-in for whoever the model has seen most. /personas replaces the abstraction with named primary and secondary user types calibrated to the product, written into `.personas.md` so every downstream command (/design, /decide, /critique, /uxreview, /audit) can ground decisions in a specific person doing a specific thing rather than an average reader.
Three modes, surfaced before the work begins. Mode A drafts personas from `.spruce.md` when no research exists — every persona explicitly labelled as a structured assumption rather than a finding. Mode B structures user-supplied research into the artifact format. Mode C pressure-tests a finished `.personas.md` against context for character drift, missing dimensions, or unstated assumptions. The mode question protects the artifact’s truth value — context-derived personas don’t get presented as research-grounded.
Specimen
/personas · Stillpoint
Forward implications
What these personas mean for design work going forward
- Density direction: Maya’s intermediate expertise + Jordan’s first-time wariness both argue for spacious-leaning-balanced. Already calibrated in .spruce.md. /foundations and /design should hold this; deviations should surface as /decide calls.
- Voice register: Both personas are anti-performance + anti-wellness-cliché. /voice should treat the following as character violations: social-proof copy (“join thousands”), gamification language (“streaks,” “rewards,” “levels”), saccharine warmth (“you’ve got this!”), wellness-influencer cadence. /survey, /critique, /detect should flag these against either persona’s needs.
- Tradeoff resolution: Maya is primary. When Maya’s daily-use experience and Jordan’s first-impression conflict, surface as /decide rather than defaulting. When they align (which is most of the time), execute confidently.
- Engagement-pattern discipline: Both personas want the product to be opened-used-closed, not engagement-maximizing. No persistent notifications by default. No growth loops. No social sharing. /design and /decide should treat features that violate this as out-of-scope unless explicitly requested.
- Persona evolution: Most Jordan users become Maya users within weeks if the practice lands. The personas’ dynamic relationship means the product’s “new user” surfaces matter for both — Jordan today is Maya tomorrow.
/personas writes .personas.md — a primary + secondary user type calibrated to the product, with confidence labelled honestly so downstream commands can weight findings appropriately. Every Spruce command that should ground decisions in named users reads from this file.
When to use it
- Starting a project where downstream design decisions should be grounded in named users rather than an average reader.
- You have user research and want it structured into the artifact format Spruce reads from.
- An existing `.personas.md` exists but hasn’t been pressure-tested for assumptions or drift.
- Another command flagged that audience context was thin and suggested grounding work in named users first.
- Preparing to run /audit and want HCD artifacts in place to ground its findings.
How to use it
By default /personas asks which mode to run — drafting from context, structuring supplied research, or pressure-testing an existing file. Every persona names its confidence (research-grounded / context-derived / assumed) so downstream commands can weight findings appropriately. Output is `.personas.md` at the project root, alongside `.spruce.md`.
- /personas pressure-test
- /personas update
Anti-patterns it addresses
- Stock-template personas with names, photos, and demographics that read as marketing personas rather than design tools. Personas should serve specific design decisions, not populate a slide.
- Context-derived personas presented as research-grounded findings. Without the confidence label, downstream commands can’t weight the artifact correctly — and the team can’t tell what they actually know about their users.
- Personas that describe demographics (“34-year-old marketing manager in Austin”) without naming what jobs they’re doing or what they need from the design. Demographics aren’t a design constraint; jobs and needs are.
- Five-or-more personas that fragment design attention. The artifact is most useful with a primary + secondary; additional personas dilute focus without adding decision-grounding power.
- Personas that don’t inform any design decision. If a persona’s existence wouldn’t change a design call, it’s documentation rather than a design tool — cut it.