Team Conventions for Personas

+15 Mana ✨
Custom Personas in Config(DOCUMENTATION)

Introduction

Personas stop being a personal preference and start being a team artifact the moment Hermes output lands in shared channels (Slack, PRs, docs, alerts). The team's reputation now depends on the persona choices of whoever is driving. Agreeing on a few conventions removes that surprise without removing individual flexibility.

Key Concepts

  • Shared channels: Slack, PR descriptions, docs, alerts, recorded sessions.
  • Professional defaults: The set of personas considered safe for shared output.
  • Custom team personas: Personas defined in a shared config that encode the team's voice.
  • Per-task overrides: Individual flexibility within team rules.

Real World Context

A team adopts Hermes. Within a month, a senior engineer pastes a pirate-flavored bug summary into the customer-facing changelog. Customers laugh, leadership does not. The team adds a single rule: "For PR descriptions, release notes, and customer-facing output, use helpful, concise, or technical." The rule takes thirty seconds to write and saves the team that conversation from happening twice.

Deep Dive

Three levels of team convention are worth considering, from light to heavy.

Level one: shortlist of professional defaults. The team agrees on three to four personas considered safe for shared output. Typically: helpful, concise, technical, teacher. Anything outside the shortlist requires conscious choice for shared contexts. This is the easiest convention to adopt and covers most failure modes.

Level two: per-context rules. The team specifies which persona to use for which shared context:

text
Incident channels      -> concise
PR descriptions        -> helpful
Release notes          -> teacher
Internal RFC drafts    -> technical
Customer changelogs    -> helpful

These rules live in the team handbook. They are not enforced by Hermes; they are social conventions. Most violations come from someone forgetting to switch, not from disagreement.

Level three: a shared custom persona. The team defines its own persona in a shared config.yaml (or in a shared SOUL.md template). The custom persona encodes the team's voice. New hires inherit it. Cross-team consistency improves. Example:

yaml
agent:
  personalities:
    acme-engineer: >
      You are a precise, calm Acme engineer. You explain trade-offs
      without hedging unnecessarily, admit uncertainty when present,
      and never use marketing language in technical contexts.

Users can then invoke /personality acme-engineer and get the team voice. Some teams ship this as part of their developer onboarding.

A few notes on adoption. Conventions only stick if they are easy to follow and visible at decision time. Documenting them in a wiki nobody reads does not help. Pinning the rules in the channel where the violations happen, or adding them to the onboarding checklist, does help.

And conventions should be narrow. A rule that says "always use professional personas" is too vague to enforce. A rule that says "PR descriptions use helpful; incidents use concise" is concrete enough to apply.

Common Pitfalls

  1. Implicit conventions: Everyone "knows" the rules but no one wrote them down. The new hire breaks them in week one.
  2. Over-restriction: A team rule that locks down every persona choice removes the individual flexibility that makes the tool useful. Convention should be a floor, not a ceiling.

Best Practices

  1. Write conventions where the work happens: In the PR template, in the incident runbook, in onboarding. Not in a separate wiki page.
  2. Ship a custom team persona only when it solves a real problem: Most teams do not need one. Three professional defaults and a per-context rule covers 90 percent of cases.

Summary

  • Shared output makes persona a team concern, not just a personal preference.
  • Three levels of convention: shortlist, per-context rules, shared custom persona.
  • Keep rules narrow and visible at the moment they apply.
  • A custom team persona is worth defining when team voice consistency matters across many developers.

Code Examples

yaml
# ~/.hermes/config.yaml - a shared team configuration
agent:
  personalities:
    acme-engineer: >
      You are a precise, calm Acme engineer. Use direct, technical
      language. Admit uncertainty. Never use marketing language in
      technical contexts. Confirm before destructive commands.

    acme-docs: >
      You are an Acme technical writer. Explain concepts patiently with
      clear examples. Define terms before using them. No internal
      jargon without an inline definition.
✓ Completed