Switching as a Workflow Move

+15 Mana ✨
Personality Runtime Switching(DOCUMENTATION)

Introduction

Most people treat the /personality command as a novelty. They run it once during onboarding, see that it works, and then never touch it again. That is a missed lever. Switching personas is a workflow move, not a one-time setup step. The teams that use Hermes most effectively are the ones that switch as often as they change context, which is several times an hour.

Key Concepts

  • Workflow move: A small deliberate action you take to align the tool to the phase of work, not a configuration choice you make once.
  • Phase of work: Brainstorm, implement, review, document, triage. Each has different demands.
  • Cost of switching: One slash command. Roughly the same cost as Cmd+S.
  • Cost of not switching: Subtle friction throughout the session: too much fluff, not enough explanation, wrong tone for the reader.

Real World Context

A senior engineer working on a feature for an afternoon does roughly the following: 15 minutes of brainstorming the API, 90 minutes of implementing, 15 minutes of writing the PR description, 10 minutes of reviewing a teammate's PR while waiting on CI. Four phases, four optimal personas. Most engineers stay on whatever persona was set in the morning. The cost is a constant low-level mismatch: a touch too verbose during implementation, a touch too terse during the PR description.

Deep Dive

The mindset shift is to treat persona selection as part of how you set up the next chunk of work, the way you might run cd ~/code/api before starting a feature. "What am I about to do?" answers "which persona?".

A helpful frame: think of personas as lenses the agent looks through. The lens does not change reality; it changes which parts of reality come into focus. A teacher lens brings prerequisites and analogies into focus. A concise lens brings the next-action into focus. A creative lens brings unexpected adjacent ideas into focus.

Frequency matters. The teams that get the most out of Hermes tend to switch:

  • Once at the start of a focused work block ("I am about to code for an hour: /personality concise").
  • When the phase changes within a session ("Now I am writing the release notes: /personality teacher").
  • When the audience changes ("This response will end up in the PR description: /personality helpful").
  • When you notice friction ("The agent is explaining too much: /personality concise").

The last trigger is worth emphasizing. The friction itself is the cue. If you find yourself reading past three paragraphs of preamble, that is a persona signal, not a model signal. Switch.

The inverse failure mode is over-switching: changing persona every two turns chasing a perfect fit. That is more friction than running with a slightly-off persona. A coarse model ("three to five personas, one per phase") beats a fine model ("twelve personas, one per task type") for most users.

Common Pitfalls

  1. Setting it once and forgetting: You picked helpful on your first day and never revisited. That is fine for the first day. By month three, you are leaving signal on the table.
  2. Over-switching mid-task: Flipping between concise and teacher inside a single thought. The agent's voice becomes incoherent and the conversation feels unstable.

Best Practices

  1. Switch at boundaries, not in the middle of a turn: Phase changes, audience changes, friction signals. Not every other response.
  2. Voice the switch in your head: "Implementation is starting, so concise." Naming the move makes it a habit.

Summary

  • Persona switching is a workflow move, applied every time the work changes shape.
  • Triggers to switch: phase change, audience change, friction signal, start of a focused block.
  • Switch at boundaries, not mid-turn. Over-switching is its own friction.
  • Most users settle on three to five personas they cycle between deliberately.

Code Examples

text
Friction signal: too much preamble during a tight fix

  /personality helpful
  > Quick: how do I revert this commit but keep the changes staged?
  < Great question! There are several ways to revert in git, depending on
    whether you have already pushed and what kind of revert you want...

  > /personality concise
  > Same question.
  < git reset --soft HEAD~1

The friction (long preamble) was the cue. Persona was the answer.
✓ Completed