Files
hermes-agent/website/docs/reference/profile-commands.md
T
Teknium 1345dda0cf feat(kanban): orchestrator-driven auto-decomposition on triage (#27572)
* feat(kanban): orchestrator-driven auto-decomposition on triage

Closes the core gap in the kanban system: dropping a one-liner into Triage
now decomposes it into a graph of child tasks routed to specialist
profiles by description, matching teknium's original vision ("main
orchestrator splits/creates actual tasks, doles them out to each agent").

The build
---------
- hermes_cli/profiles.py: new `description` + `description_auto` fields
  on ProfileInfo, persisted in <profile_dir>/profile.yaml. Helpers
  read_profile_meta / write_profile_meta. `create_profile` accepts
  optional description.
- hermes_cli/profile_describer.py: new module — auto-generate a 1-2
  sentence description from a profile's skills + model + name via the
  auxiliary LLM (`auxiliary.profile_describer`).
- hermes_cli/main.py: new `hermes profile create --description ...`
  flag; new `hermes profile describe [name] [--text ... | --auto |
  --all --auto]` subcommand.
- hermes_cli/kanban_db.py: new `decompose_triage_task` atomic helper —
  creates N child tasks, links the root as a child of every leaf
  (root waits for the whole graph), flips root `triage -> todo` with
  orchestrator assignee, records an audit comment + `decomposed` event
  in a single write_txn.
- hermes_cli/kanban_decompose.py: new module — calls the auxiliary LLM
  (`auxiliary.kanban_decomposer`) with the profile roster + descriptions
  to produce a JSON task graph, then invokes the DB helper. Rewrites
  unknown assignees to the configured `kanban.default_assignee` (or
  the active default profile) so a task NEVER lands with assignee=None.
  Falls back to specify-style single-task promotion when the LLM
  returns `fanout: false`.
- hermes_cli/kanban.py: new `hermes kanban decompose [task_id | --all]`
  CLI verb.
- hermes_cli/config.py: new DEFAULT_CONFIG keys —
  kanban.orchestrator_profile, kanban.default_assignee,
  kanban.auto_decompose (default True), kanban.auto_decompose_per_tick
  (default 3), auxiliary.kanban_decomposer, auxiliary.profile_describer.
- gateway/run.py: kanban dispatcher watcher now runs auto-decompose
  before each `_tick_once`, capped by `auto_decompose_per_tick` so a
  bulk-load of triage tasks doesn't burst-spend the aux LLM.
- plugins/kanban/dashboard/plugin_api.py: new endpoints —
  GET /profiles (list roster + descriptions),
  PATCH /profiles/<name> (set description, user-authored),
  POST /profiles/<name>/describe-auto (LLM-generate),
  POST /tasks/<id>/decompose (run decomposer),
  GET/PUT /orchestration (orchestrator/default-assignee/auto-decompose
  pickers, with resolved fallbacks echoed back).
- plugins/kanban/dashboard/dist/index.js: new OrchestrationPanel
  collapsible — dropdowns for orchestrator profile and default
  assignee, auto-decompose toggle, per-profile description editor with
  Save and Auto-generate buttons. New ⚗ Decompose button next to
   Specify on triage-column task drawers.

Behavior
--------
- A task in Triage gets fanned out into a small DAG of child tasks.
  Children with no internal parents flip to `ready` immediately
  (parallel dispatch). Children with sibling parents wait. The root
  stays alive as a parent of every child — when the whole graph
  finishes, it promotes to `ready` and the orchestrator profile wakes
  back up to judge completion (the "adds more tasks until done" part
  of the original vision).
- `kanban.orchestrator_profile` unset -> falls back to the default
  profile (whichever `hermes` launches with no -p flag).
- `kanban.default_assignee` unset -> same fallback. Tasks NEVER end
  up unassigned.
- `kanban.auto_decompose=true` (default) runs the decomposer
  automatically on dispatcher ticks; manual `hermes kanban decompose`
  is always available.

Tests
-----
- tests/hermes_cli/test_kanban_decompose_db.py — 7 tests for the
  atomic DB helper (status transitions, dep graph, audit trail,
  validation errors).
- tests/hermes_cli/test_kanban_decompose.py — 6 tests for the
  decomposer module (fanout, no-fanout fallback, unknown-assignee
  rewrite, malformed-JSON resilience, no-aux-client path).
- tests/hermes_cli/test_profile_describer.py — 10 tests for
  profile.yaml r/w + the LLM auto-describer (yaml corrupt tolerance,
  user-vs-auto description protection, --overwrite, fallback parsing).

E2E
---
- CLI end-to-end: created profiles with descriptions, dropped a triage
  task, mocked the aux LLM with a 3-task graph -> verified all three
  children were created with the right assignees, the dependency
  edges matched the LLM's graph, root flipped to todo gated by every
  child, audit comment + `decomposed` event recorded.
- Dashboard end-to-end: started the dashboard against an isolated
  HERMES_HOME, verified all four new endpoints via curl (profile
  listing, PATCH for description, PUT for orchestration settings,
  POST for decompose). Opened the UI in the browser, confirmed the
  OrchestrationPanel renders with all three pickers + the per-profile
  description editor, typed a description, clicked Save, verified
  ~/.hermes/profile.yaml was written. Clicked Decompose on the triage
  card and confirmed the inline error message surfaced as designed
  ("no auxiliary client configured").

* feat(kanban): surface decompose mode (Auto/Manual) as a one-click pill

The auto/manual toggle already existed as kanban.auto_decompose (default
true), but it was buried inside the collapsed Orchestration settings
panel — users couldn't tell at a glance which mode they were in. This
hoists it to a pill at the top of the kanban page so the state is always
visible and one click flips it.

UX
- New "⚗ Decompose: AUTO|MANUAL" pill in the kanban header. Emerald
  styling when Auto is on (the default), muted/gray when Manual.
- Pill is visible both in the collapsed AND expanded Orchestration
  settings views so context is preserved when the user opens the panel.
- Tooltip explains both states + what clicking does.
- Renamed the in-panel "Auto-decompose on triage / Enabled" checkbox
  to "Decompose mode / Auto (default) | Manual" for language parity
  with the pill.

Behavior preserved
- Default remains Auto (kanban.auto_decompose=true).
- Manual mode restores pre-PR behavior: triage tasks stay in triage
  until the user clicks ⚗ Decompose on each card (or runs
  `hermes kanban decompose <id>`).

Implementation
- plugins/kanban/dashboard/dist/index.js: load /orchestration on mount
  (not just on expand) so the collapsed pill reflects real state.
  Render mode pill in both collapsed and expanded headers. Reuses the
  existing PUT /api/plugins/kanban/orchestration endpoint — no new
  backend, no new tests required.

E2E verified
- Pill renders as "⚗ Decompose: AUTO" on page load (default).
- One click flips to "⚗ Decompose: MANUAL" with muted styling.
- config.yaml on disk shows auto_decompose: false after the flip.
- Second click round-trips back to Auto; config.yaml flips to true.

* feat(kanban): rename mode pill to "Orchestration: Auto/Manual"

Per Teknium feedback — "Decompose" was too implementation-specific.
"Orchestration" is the user-facing concept (the whole pitch is the
orchestrator profile routing work), and the pill is the front door to it.

- Pill text: "Orchestration: Auto" / "Orchestration: Manual" (title case,
  no ⚗ prefix, no SHOUTY-CAPS for the mode value)
- In-panel checkbox label: "Orchestration mode" (was "Decompose mode")
- Tooltips updated to match
- No behavior change

* docs(kanban): document decompose, profile descriptions, orchestration mode

Brings the docs site up to parity with the PR. English build verified
locally (npx docusaurus build --locale en) — clean, no new broken links
or anchors. Pre-existing broken-link warnings (rl-training, llms.txt,
step-by-step-checklist, fallback-model) untouched.

- website/docs/reference/cli-commands.md
    + `hermes kanban decompose` action row in the action table, with
      pointer to the Auto vs Manual orchestration section.

- website/docs/reference/profile-commands.md
    + `--description "<text>"` flag on `hermes profile create`.
    + Full `hermes profile describe` section: read, --text, --auto,
      --overwrite, --all flags with examples.

- website/docs/user-guide/features/kanban.md (the big one)
    + Triage column intro rewritten around the Auto-decompose default
      behavior, with pointer to the new Auto vs Manual section.
    + Status action row updated to mention both ⚗ Decompose and
       Specify on triage cards.
    + New "Auto vs Manual orchestration" section explaining the two
      modes, how to flip them (pill, config), how routing-by-description
      works, the no-None-assignee guarantee, plus a config knob table
      (auto_decompose, auto_decompose_per_tick, orchestrator_profile,
      default_assignee) and the two new auxiliary slots
      (kanban_decomposer, profile_describer).
    + REST surface table gains 6 new endpoint rows: /tasks/:id/decompose,
      /profiles (GET), /profiles/:name (PATCH), /profiles/:name/describe-auto,
      /orchestration (GET + PUT).

- website/docs/user-guide/features/kanban-tutorial.md
    + Triage column blurb updated for Auto by default + Manual via the
      pill, with cross-link to the Auto vs Manual orchestration section.

- website/docs/user-guide/profiles.md
    + Blank-profile flow now mentions --description and points to the
      kanban routing model for context.

- website/docs/user-guide/configuration.md
    + `kanban_decomposer` and `profile_describer` added to the
      `hermes model -> Configure auxiliary models` menu listing.
2026-05-17 13:54:12 -07:00

15 KiB

sidebar_position
sidebar_position
7

Profile Commands Reference

This page covers all commands related to Hermes profiles. For general CLI commands, see CLI Commands Reference.

hermes profile

hermes profile <subcommand>

Top-level command for managing profiles. Running hermes profile without a subcommand shows help.

Subcommand Description
list List all profiles.
use Set the active (default) profile.
create Create a new profile.
delete Delete a profile.
show Show details about a profile.
alias Regenerate the shell alias for a profile.
rename Rename a profile.
export Export a profile to a tar.gz archive.
import Import a profile from a tar.gz archive.
install Install a profile distribution from a git URL or local directory. See Profile Distributions.
update Re-pull a distribution-managed profile and re-apply its bundle.
info Show distribution metadata for a profile (origin URL, commit, last update).

hermes profile list

hermes profile list

Lists all profiles. The currently active profile is marked with *.

Example:

$ hermes profile list
  default
* work
  dev
  personal

No options.

hermes profile use

hermes profile use <name>

Sets <name> as the active profile. All subsequent hermes commands (without -p) will use this profile.

Argument Description
<name> Profile name to activate. Use default to return to the base profile.

Example:

hermes profile use work
hermes profile use default

hermes profile create

hermes profile create <name> [options]

Creates a new profile.

Argument / Option Description
<name> Name for the new profile. Must be a valid directory name (alphanumeric, hyphens, underscores).
--clone Copy config.yaml, .env, and SOUL.md from the current profile.
--clone-all Copy everything (config, memories, skills, sessions, state) from the current profile.
--clone-from <profile> Clone from a specific profile instead of the current one. Used with --clone or --clone-all.
--no-alias Skip wrapper script creation.
--description "<text>" One- or two-sentence description of what this profile is good at. Used by the kanban orchestrator to route tasks based on role instead of profile name alone. Skip and add later via hermes profile describe. Persisted in <profile_dir>/profile.yaml.

Creating a profile does not make that profile directory the default project/workspace directory for terminal commands. If you want a profile to start in a specific project, set terminal.cwd in that profile's config.yaml.

Examples:

# Blank profile — needs full setup
hermes profile create mybot

# Clone config only from current profile
hermes profile create work --clone

# Clone everything from current profile
hermes profile create backup --clone-all

# Clone config from a specific profile
hermes profile create work2 --clone --clone-from work

hermes profile describe

hermes profile describe [<name>] [options]

Read or set a profile's description. The description is consumed by the kanban orchestrator to route tasks based on what each profile is good at, rather than guessing from the profile name alone. Persisted in <profile_dir>/profile.yaml so it survives reboots and is shared with the gateway.

With no flags, prints the current description (or (no description set for '<name>') if empty).

Argument / Option Description
<name> Profile to describe. Required unless --all --auto is used.
--text "<text>" Set the description to this exact text (user-authored). Overwrites any existing description.
--auto Auto-generate a 1-2 sentence description via the auxiliary LLM, based on the profile's installed skills, configured model, and name. Configure the model under auxiliary.profile_describer in config.yaml. Auto-generated descriptions are marked description_auto: true so the dashboard can flag them for review.
--overwrite With --auto, replace user-authored descriptions too (default: skip profiles whose description was set explicitly).
--all With --auto, sweep every profile missing a description.

Examples:

# Read the current description
hermes profile describe researcher

# Set it explicitly
hermes profile describe researcher --text "Reads source code and writes findings."

# Let the LLM generate one
hermes profile describe researcher --auto

# Fill in descriptions for every profile that doesn't have one
hermes profile describe --all --auto

hermes profile delete

hermes profile delete <name> [options]

Deletes a profile and removes its shell alias.

Argument / Option Description
<name> Profile to delete.
--yes, -y Skip confirmation prompt.

Example:

hermes profile delete mybot
hermes profile delete mybot --yes

:::warning This permanently deletes the profile's entire directory including all config, memories, sessions, and skills. Cannot delete the currently active profile. :::

hermes profile show

hermes profile show <name>

Displays details about a profile including its home directory, configured model, gateway status, skills count, and configuration file status.

This shows the profile's Hermes home directory, not the terminal working directory. Terminal commands start from terminal.cwd (or the launch directory on the local backend when cwd: ".").

Argument Description
<name> Profile to inspect.

Example:

$ hermes profile show work
Profile: work
Path:    ~/.hermes/profiles/work
Model:   anthropic/claude-sonnet-4 (anthropic)
Gateway: stopped
Skills:  12
.env:    exists
SOUL.md: exists
Alias:   ~/.local/bin/work

hermes profile alias

hermes profile alias <name> [options]

Regenerates the shell alias script at ~/.local/bin/<name>. Useful if the alias was accidentally deleted or if you need to update it after moving your Hermes installation.

Argument / Option Description
<name> Profile to create/update the alias for.
--remove Remove the wrapper script instead of creating it.
--name <alias> Custom alias name (default: profile name).

Example:

hermes profile alias work
# Creates/updates ~/.local/bin/work

hermes profile alias work --name mywork
# Creates ~/.local/bin/mywork

hermes profile alias work --remove
# Removes the wrapper script

hermes profile rename

hermes profile rename <old-name> <new-name>

Renames a profile. Updates the directory and shell alias.

Argument Description
<old-name> Current profile name.
<new-name> New profile name.

Example:

hermes profile rename mybot assistant
# ~/.hermes/profiles/mybot → ~/.hermes/profiles/assistant
# ~/.local/bin/mybot → ~/.local/bin/assistant

hermes profile export

hermes profile export <name> [options]

Exports a profile as a compressed tar.gz archive.

Argument / Option Description
<name> Profile to export.
-o, --output <path> Output file path (default: <name>.tar.gz).

Example:

hermes profile export work
# Creates work.tar.gz in the current directory

hermes profile export work -o ./work-2026-03-29.tar.gz

hermes profile import

hermes profile import <archive> [options]

Imports a profile from a tar.gz archive.

Argument / Option Description
<archive> Path to the tar.gz archive to import.
--name <name> Name for the imported profile (default: inferred from archive).

Example:

hermes profile import ./work-2026-03-29.tar.gz
# Infers profile name from the archive

hermes profile import ./work-2026-03-29.tar.gz --name work-restored

Distribution commands

:::tip New to distributions? Start with the Profile Distributions user guide — it covers the why, when, and how with full examples. The sections below are a dry CLI reference for when you know what you want. :::

Distributions turn a profile into a shareable, versioned artifact published as a git repository. A recipient installs the distribution with a single command and can update it in place later without touching their local memories, sessions, or credentials.

auth.json and .env are never part of a distribution — they stay on the installing user's machine.

The recipient's user data (memories, sessions, auth, their own edits to .env) is always preserved across the initial install and subsequent updates.

:::info hermes profile export / import are still the right commands for local backup and restore of a profile on your own machine. Distribution (install / update / info) is a separate concept: ship a profile via git so someone else can install it. :::

hermes profile install

hermes profile install <source> [--name <name>] [--alias] [--force] [--yes]

Installs a profile distribution from a git URL or a local directory.

Option Description
<source> Git URL (github.com/user/repo, https://..., git@..., ssh://, git://) or a local directory containing distribution.yaml at its root.
--name NAME Override the profile name from the manifest.
--alias Also create a shell wrapper (e.g. telemetryhermes -p telemetry).
--force Overwrite an existing profile of the same name. User data is still preserved.
-y, --yes Skip the manifest-preview confirmation prompt.

The installer shows the manifest, lists required env vars, and warns about cron jobs before asking for confirmation. Required env vars go into a .env.EXAMPLE file you copy to .env and fill in.

Examples:

# Install from a GitHub repo (shorthand)
hermes profile install github.com/kyle/telemetry-distribution --alias

# Install from a full HTTPS git URL
hermes profile install https://github.com/kyle/telemetry-distribution.git

# Install from SSH
hermes profile install git@github.com:kyle/telemetry-distribution.git

# Install from a local directory during development
hermes profile install ./telemetry/

hermes profile update

hermes profile update <name> [--force-config] [--yes]

Re-clones the distribution from its recorded source and applies updates. Distribution-owned files (SOUL.md, skills/, cron/, mcp.json) are overwritten; user data (memories, sessions, auth, .env) is never touched.

config.yaml is preserved by default to keep your local overrides. Pass --force-config to reset it to the distribution's shipped config.

hermes profile info

hermes profile info <name>

Prints the profile's distribution manifest — name, version, required Hermes version, author, env var requirements, the source URL/path, and the Installed: timestamp recorded when the distribution was last install-ed or update-d. Useful for checking what a shared profile needs before installing it, and for spotting "this profile was installed 6 months ago and hasn't been updated."

hermes profile list also shows the distribution name and version in a Distribution column, and hermes profile show <name> / delete <name> surface the source URL so you can tell at a glance which profiles came from a git repo vs. were created locally.

Private distributions

A private git repository works as a distribution source with no extra configuration — the install shells out to your normal git binary, so whatever authentication your shell is already set up for (SSH key, git credential helper, GitHub CLI's stored HTTPS credentials) applies transparently.

# Uses your SSH key, the same as any other `git clone`
hermes profile install git@github.com:your-org/internal-assistant.git

# Uses your git credential helper
hermes profile install https://github.com/your-org/internal-assistant.git

If a clone prompts for credentials interactively in your terminal during install, that prompt flows through. Set up your auth the way you'd normally use git clone against the same repo first, then install.

Distribution manifest (distribution.yaml)

Every distribution has a distribution.yaml at the root of its repository:

name: telemetry
version: 0.1.0
description: "Compliance monitoring harness"
hermes_requires: ">=0.12.0"
author: "Your Name"
license: "MIT"
env_requires:
  - name: OPENAI_API_KEY
    description: "OpenAI API key"
    required: true
  - name: GRAPHITI_MCP_URL
    description: "Memory graph URL"
    required: false
    default: "http://127.0.0.1:8000/sse"
distribution_owned:   # optional; defaults to SOUL.md, config.yaml,
                      #   mcp.json, skills/, cron/, distribution.yaml
  - SOUL.md
  - skills/compliance/
  - cron/

hermes_requires supports >=, <=, ==, !=, >, <, or a bare version (treated as >=). Install fails with a clear error if the current Hermes version doesn't satisfy the spec.

distribution_owned is optional. If set, only those paths are replaced on update; anything else in the profile stays user-owned. If omitted, the defaults above apply.

Publishing a distribution

Authoring a distribution is just a git push:

  1. In your profile directory, create distribution.yaml with at least name and version.
  2. Initialize a git repo (or use an existing one) and push to GitHub / GitLab / any host Hermes can clone from.
  3. Tell recipients to run hermes profile install <your-repo-url>.

Use git tags for versioned releases — recipients who clone HEAD get your latest state, and you can always bump version: in the manifest.

hermes -p / hermes --profile

hermes -p <name> <command> [options]
hermes --profile <name> <command> [options]

Global flag to run any Hermes command under a specific profile without changing the sticky default. This overrides the active profile for the duration of the command.

Option Description
-p <name>, --profile <name> Profile to use for this command.

Examples:

hermes -p work chat -q "Check the server status"
hermes --profile dev gateway start
hermes -p personal skills list
hermes -p work config edit

hermes completion

hermes completion <shell>

Generates shell completion scripts. Includes completions for profile names and profile subcommands.

Argument Description
<shell> Shell to generate completions for: bash, zsh, or fish.

Examples:

# Install completions
hermes completion bash >> ~/.bashrc
hermes completion zsh >> ~/.zshrc
hermes completion fish > ~/.config/fish/completions/hermes.fish

# Reload shell
source ~/.bashrc

After installation, tab completion works for:

  • hermes profile <TAB> — subcommands (list, use, create, etc.)
  • hermes profile use <TAB> — profile names
  • hermes -p <TAB> — profile names

See also