A Hermes profile is an isolation boundary, not merely a role label. Each profile has its own configuration, sessions, memory, Skills, and credentials. A specialist team works when those boundaries match real responsibilities and the orchestrator can route work from clear descriptions.
- Give every specialist a distinct profile home.
- Describe outcomes and limits, not a vague persona.
- Assign only the Skills and tool groups the role needs.
- Clone state deliberately;
--clone-allis broader than most team setups require.
1. Start with responsibilities
The fixture defines six roles: researcher, code verifier, Korean writer, English writer, reviewer, and orchestrator. The split follows handoffs in the final project. Research produces supported claims; verification produces observed outputs; writers work from those inputs; review checks parity; orchestration routes the work.
A profile description matters because Hermes Kanban can use it when choosing a worker. “Helpful writer” says little. “Localizes English technical articles without changing facts” gives the router and reviewer a useful boundary.
2. Inspect the specification
team.json records the role name, logical home, description, Skills, and tool groups. Run the read-only checker before creating anything:
python3 examples/chapter-06-specialist-profiles/check_profiles.py
python3 -m unittest discover -s examples/chapter-06-specialist-profiles/tests -vThe checker requires all six roles in canonical order and a unique home for each one. Mutation tests remove a role, reuse a home, and add a secret-like field.
PASS: 6 specialist profiles have unique homes and explicit responsibilities3. Create one profile first
Test the smallest slice before creating the whole team:
hermes profile create researcher --description "Finds primary sources and records supported claims."
hermes profile show researcher
hermes profile listprofile show lets you inspect the new boundary. If it is correct, repeat the create command with the other descriptions from team.json. Profile names use lowercase alphanumeric identifiers; the fixture also permits hyphens.
4. Choose cloning scope deliberately
A plain create gives the new role an independent starting point. --clone copies selected configuration, secrets, SOUL.md, and Skills from a source profile. --clone-all copies substantially more state. Broad cloning can defeat the reason for separating a reviewer from a writer.
Model choice may be shared while tools and Skills remain different. Configure each role from its own profile context, and never copy a credential simply because a role might need it later.
5. Verify isolation and routing data
Run hermes profile show <name> for each profile and compare the result with the approved specification. Check the description, active home, enabled Skills, and tools. A file-level specification cannot prove the live Hermes state matches it, so this readback is required after creation.
The fixture intentionally stops before live creation. It proves that the team design is complete, uniquely scoped, and free of credential fields. It does not claim that six profiles exist on the reader’s machine.
Leave a Reply