Common situations
Ten shapes of real work. Find the one that looks like yours, take the command, and read the part that says when not to bother.
The ten shapes
Five of the same job, and you do not want to sit through them Fan out · independent cards
Why the board handles this well Nothing depends on anything, so the dispatcher claims all of them as fast as your concurrency allows. Each runs in its own process. One failing does not touch the other four, and each keeps its own run history.
hermes kanban create "transcribe call 4" --assignee transcriber When to skip it If the five are really one job cut into five, write one card. Five cards rebuild the same context five times and you pay for it five times.
Each step needs the answer from the step before it Chain · parents and children
Why the board handles this well The child waits in Todo. When the parent completes, the dependency engine promotes it to Ready on its own, and the child worker is handed the parent summary before it starts. It does not re-derive a decision that was already made.
hermes kanban create "write the tests" --assignee qa-dev --parents t_23f6 When to skip it Do not chain steps that do not truly depend on each other. A false chain turns work that could have run at once into a queue.
You know what you want but cannot yet name the tasks Triage · decompose
Why the board handles this well A card in Triage is read by the decomposer, which writes child cards and routes each one to the closest profile you actually have. Three per pass by default, so a vague card cannot flood the board.
hermes kanban decompose t_abcd When to skip it If you can already name the tasks, name them yourself. Decomposition spends a model call to invent structure you would have written better.
The job runs for hours and you want to walk away Long run · heartbeat
Why the board handles this well A worker is a real process, not a chat turn, so it can run far longer than a session. It must call kanban_heartbeat at least hourly. If it stops, the dispatcher treats the card as stale and gives it to a fresh worker rather than leaving it stuck forever.
hermes kanban runs t_abcd When to skip it The machine has to stay awake. A sleeping laptop is the single most common reason a long card comes back as crashed.
Nothing ships until you have looked at it Human in the loop · review
Why the board handles this well A worker that needs a decision calls kanban_block with its reason and stops. It does not guess. You read the reason, fix or answer it, and unblock. Work that needs sign-off lands in Review instead of Done.
hermes kanban list --status review When to skip it Do not gate everything. A board where every card waits for you is a to-do list with extra steps.
The same sweep every morning that you keep forgetting Scheduled · recurring
Why the board handles this well Scheduled is its own column, not a flavour of Todo, so waiting work is visible instead of buried. Pair it with a cron job that writes the card and the sweep stops depending on you remembering.
hermes kanban list --status scheduled When to skip it If the sweep produces nothing you read, deleting the habit beats automating it.
Two clients whose work must never mix Boards · hard boundary
Why the board handles this well A board is a separate file, and a worker spawned on one board cannot list, read or touch a card on another. That is a boundary in the process environment, not a filter in the interface.
hermes kanban boards create client-b When to skip it For work that is merely different, use --tenant on one board. Tenants filter; boards isolate. Reach for the heavier tool only when a leak would actually matter.
Two agents editing the same repository Lanes · one workspace each
Why the board handles this well Every card gets its own workspace directory, so two workers are not writing the same file at the same time. Give each lane its own git worktree and the merge is a merge, not a rescue.
hermes kanban show t_abcd --json When to skip it One agent and one branch is fine. Parallel edits to one repo need a plan for merging, and the plan is your job.
Fill the board at night, read it with coffee Queue · notify on endings
Why the board handles this well This is the pattern that turns into a habit, because the cue is stable: you already open the board in the morning. Endings arrive on Telegram, Discord or Slack, so you check a message instead of watching a screen.
hermes kanban notify-subscribe --kinds completed,gave_up When to skip it Subscribe to endings only. Subscribe to every event and you will mute the channel within a day, which is worse than no notifications.
When not to use the board at all The honest one
Why the board handles this well One task, well specified, that you can check in a single pass, does not need a board. Just run it. Benchmarks keep finding a single agent matching or beating multi-agent setups on most tasks, at a fraction of the cost, and coordination overhead is real money.
hermes chat When to skip it The board earns its keep when work is genuinely parallel, genuinely dependent, or genuinely long. Not before.
Screen 4 of 7.