Choosing a Persona for a Task

Introduction

The selection question is not "which persona is best?" It is "which persona fits this task?" The right persona for a code review is wrong for a brainstorm. The right persona for onboarding is wrong for an incident. Selection is a small skill, but it is the difference between a useful agent and a frustrating one.

Key Concepts

• Task type: The category of work (review, implementation, brainstorm, learning, ops, writing).
• Reader: Who will consume the output. You? A teammate? An incident channel?
• Time pressure: Whether the task needs depth (teacher) or speed (concise).
• Surface area: How much output is acceptable for the task at hand.

Real World Context

A developer kicks off a week with five tasks: review a PR, implement a new endpoint, sketch a feature direction, write release notes, and run a flaky test investigation. Each task has a fitting persona. Trying to do all five with one persona means one task lands well and four feel off.

Deep Dive

A quick decision tree:

text
Is the task: brainstorming, exploring options?
    -> creative

Is the task: precise execution, code, ops?
    -> technical (peer) or concise (no chatter)

Is the task: teaching, onboarding, explaining?
    -> teacher

Is the task: writing for an audience (docs, release notes)?
    -> helpful (neutral) or teacher (deeper)

Is the task: incident response, time-pressured triage?
    -> concise

Is the task: a creative/fun project where mood is part of the point?
    -> any Expressive persona (creative, kawaii, pirate, ...)

A few selection heuristics worth internalizing.

Match the reader, not your mood. The persona shows up in the output, not in your terminal. If your output goes to a Slack channel where five teammates are reading, the persona is their experience, not yours. pirate is funny for the writer and noise for the readers.

Prefer Utility when in doubt. helpful is the safe default. It rarely impresses, but it rarely offends either. If you cannot decide, that is a sign the task does not need a stronger persona.

Switch when phase changes. The same hour of work might span brainstorm, implement, and document. Switch with /personality at the boundaries rather than picking one persona and gritting through.

Consider downstream consumption. Output that will land in a PR description, a docs page, or a release note will be read by people who do not know your persona settings. Use a Utility or Professional persona for that work, even if your in-session preference is more expressive.

Common Pitfalls

1. Sticking with the default forever: Most users never run /personality. They wonder why the agent feels generic. The answer is: they have not picked a persona for the work.
2. Persona-as-mood: Picking a persona because you feel like it rather than because the task needs it. The result is friction in the output for whoever reads it next.

Best Practices

1. State the persona in your inner monologue: "This is teaching, so teacher." Naming the choice catches mismatches.
2. Have a default per task type: Most developers settle on three to five personas they cycle between. The shortlist makes the choice faster.

Summary

• The selection question is "which persona fits this task?", not "which is best?".
• Match the reader and the time pressure, not your mood.
• Phase changes (brainstorm to implement to document) call for persona changes.
• A shortlist of three to five personas covers most real work.

# A typical day, phase by phase, with a fitting persona at each boundary.

/personality creative           # 9am: feature sketch
# ...brainstorm session...

/personality technical          # 10am: implementing the chosen approach
# ...coding session...

/personality concise            # 2pm: rapid bug-fix sprint
# ...one-liners and exact fixes...

/personality teacher            # 4pm: writing onboarding docs
# ...thorough explanations for new hires...