Orchestrate Hermes Multi-Agents

Coordinate a manager-led Hermes team to build and verify TaskFlow.

Introduction

30 Second Summary

A feature can stall when every update depends on you relaying context between specialists. The coordination work grows faster than the feature itself.

In this project, you will give one TaskFlow feature brief to an Engineering Manager in Hermes Desktop. The manager will turn it into a durable Kanban graph that routes work through Backend, Frontend, QA, and DevOps.

What You'll Build

You will watch five Bots align in one room, turn their contract into a queued delivery graph, then open a live TaskFlow board whose cards and filters reflect the specialists' merged work.

By the end of this project, you'll have:

  • A visible TaskFlow Sprint Room where Bot Mode shows the manager inviting Backend, Frontend, QA, and DevOps into one bounded discussion.
  • A visible dependency-gated delivery graph where Backend and Frontend run in parallel. QA verifies both outputs before DevOps integrates them.
  • A live TaskFlow demo that loads four tasks from /api/tasks and updates the visible card count when you change filters.
  • Secret Mission: Route a post-release search improvement through Frontend, QA, and DevOps, then verify it in the live TaskFlow board.

Are there any prerequisites?

Complete Parts 1 through 4 and keep the TaskFlow repository available on macOS, Windows, or Linux. Use the instructions for your operating system throughout this project. You also need Hermes Agent v0.21.0 or newer, Git, Python 3, and a configured model provider whose normal usage or subscription costs may apply.

Before We Start

Before We Start...

Before you begin, lock in what you are building and why the manager-led workflow matters.

Set Up the Manager-Led Team

Your Part 4 TaskFlow repository is ready, but Hermes needs a defined team before it can route work. This step prepares one Engineering Manager to coordinate four specialists through Hermes Agent.

You will verify the required version and open Hermes Desktop. Then you will define the five-profile roster and limit the manager to orchestration.

In this step, get ready to:
  • Verify Hermes Agent and open Hermes Desktop.
  • Create or confirm the five-profile roster.
  • Configure the manager's orchestration toolsets.
Verify Hermes and open Desktop

The manager-led workflow requires Hermes Agent v0.21.0 or newer. Check the installed version before changing anything.

  • Print the installed Hermes Agent version by running this command:
hermes --version

Choose the tab that matches the version shown in your terminal.

✔️ I see v0.21.0 or newer

Your Hermes installation supports the manager-led workflow. Continue with the diagnostic check below.

ⓧ I see an older version

Update the existing Hermes installation before continuing.

  • Update Hermes Agent by running this command:
hermes update
  • Confirm the updated version by running this command:
hermes --version

Continue when the output shows Hermes Agent v0.21.0 or newer.

Update not completing?

Confirm that your device can reach the internet, then retry the update.

Help me diagnose my Hermes update.

ⓧ Command not found

Hermes Agent is missing from your command path. Complete the official Hermes installation guide, then run the version check again.

  • Check the Hermes configuration and required dependencies by running this command:
hermes doctor

Continue when the diagnostic reports no blocking configuration or dependency issues. Optional integration warnings do not block this project.

Hermes Doctor found an issue?

  • Apply supported repairs, then repeat the diagnostic by running these commands:
hermes doctor --fix
hermes doctor

Avoid forced npm audit repairs or manual changes inside Hermes-managed node_modules files. Help me interpret the remaining Hermes Doctor findings.

The first Desktop launch may take a minute while Hermes starts its local services. On Linux, the launch command may build the native app, so a quiet terminal during that build is expected.

macOS

  • Press Cmd+Space to open Spotlight.
  • Laund Hermes Desktop by running this command.
hermes desktop

Wait for Hermes Desktop to open, then confirm that Bots appears in the left sidebar.

Windows

  • Press the Windows key to open system search.
  • Type Hermes desktop and press Enter.

Wait for Hermes Desktop to open, then confirm that Bots appears in the left sidebar.

Linux

  • Launch Hermes Desktop by running this command:
hermes desktop

Wait for Hermes Desktop to open, then confirm that Bots appears in the left sidebar.

Bots missing from Desktop?

Close Hermes Desktop, then open it again using the instructions for your operating system. If Bots remains missing, reinstall Hermes Desktop from the official installation guide for your platform.

Confirm that Bots now appears in the sidebar. Help me restore Bots in Hermes Desktop.

Create the five-profile roster

Profiles give each worker a durable identity and routing description. The roster needs manager, frontend, backend, qa, and devops.

  • Open New Terminal
    • Press Cmd+Space (macOS) or the Windows key (Windows) to open system search.
    • Type Terminal (macOS) or Windows Terminal (Windows), then press Enter to open a new terminal window.
  • List the existing Hermes profiles by running this command:
hermes profile list

Choose the tab that matches the profile names in the output.

✔️ I see all five profiles

ⓧ One or more profiles are missing

Create only the missing profiles so existing profile configuration stays intact.

  • Run the complete creation line for each missing profile:
hermes profile create manager --clone
hermes profile create frontend --clone
hermes profile create backend --clone
hermes profile create qa --clone
hermes profile create devops --clone
  • Check the updated roster by running this command:
hermes profile list

You should now see separate entries for manager, frontend, backend, qa, and devops.

Profile creation rejected?

If Hermes reports that a profile already exists, skip that creation line. Run only the lines for names still missing.

Help me reconcile my Hermes profiles.

  • Apply the sprint routing descriptions to all five profiles by running these commands:
hermes profile describe manager --text "Plans the sprint, defines shared contracts, and routes Kanban cards without writing application code."
hermes profile describe frontend --text "Builds the browser interface, connects it to the API, and keeps the experience accessible."
hermes profile describe backend --text "Builds the Python API, manages task data, and defines responses for the frontend."
hermes profile describe qa --text "Tests acceptance criteria across the API and browser interface before release."
hermes profile describe devops --text "Combines completed branches, runs verification, and documents the local TaskFlow run flow."

Why add routing descriptions?

Hermes uses each description to decide which profile should receive a card. Clear ownership keeps implementation work away from the manager.

Each description command should return you to the prompt without an error. The manager and four specialists now have distinct routing boundaries.

Description command rejected?

Confirm that the profile name matches the roster exactly. Keep each description inside one pair of quotation marks.

Need help checking a line? Help me repair a Hermes profile description command.

Limit the manager to orchestration

A toolset defines the capabilities available to a profile. The manager uses the recognized top-level toolsets setting so it can plan and route work without receiving implementation tools.

  • Switch to the manager profile by running this command:
hermes profile use manager
  • Replace any unsupported platform override with the manager's orchestration toolsets by running these commands:
hermes -p manager config unset platform_toolsets.cli
hermes -p manager config set toolsets '["kanban","gateway","memory"]'

What do these toolsets enable?

  • The kanban toolset lets the manager create and route durable cards.
  • The gateway toolset supports dispatcher coordination.
  • The memory toolset preserves relevant sprint context.
  • platform_hints.cli is unrelated to tool access, so do not use the command-line suggestion from the warning.
  • Print the manager's configured toolsets by running this command:
hermes -p manager config get toolsets
  • Start a new manager chat before testing the toolsets. Existing chats keep their original tool schema.

Toolsets missing from the output?

The warning appears when hermes config set receives the unsupported nested key. Remove that override before relying on the recognized toolsets value.

  • Repair the manager configuration by running these commands:
hermes -p manager config unset platform_toolsets.cli
hermes -p manager config set toolsets '["kanban","gateway","memory"]'

Help me verify the manager toolsets.

Before you run the final check, which five profile names do you expect Hermes to list?

  • Restore the default profile and print the complete roster by running these commands:
hermes profile use default
hermes profile list

That is the team boundary in place. Hermes now has one orchestration-focused manager and four clearly described specialists.

Your manager-led team is ready. Next, you will watch those five profiles align on the TaskFlow contract in one shared room.

Watch the Team Align

Your manager-led roster is ready. Now you will bring those five profiles into one visible planning room before any sprint board exists.

Bot Mode Group Chat lets five profiles challenge and refine one another's ideas in a shared discussion. The later Kanban cards remain the durable source of truth for execution.

In this step, get ready to:
  • Create a room for the five-profile team.
  • Run one bounded autonomous ideation session.
  • Capture the visible agreement before pausing dispatch.
Start the team room

The gateway gives the room an active driver for turn scheduling. No sprint cards exist yet, so starting it cannot launch implementation work.

  • Return to the terminal you used to check the profile roster.
  • Start the gateway in the foreground by running this command:
hermes gateway run

You should see the gateway remain active instead of returning to the prompt. Keep this terminal open while the team room runs.

Gateway did not stay running?

  • Check whether another gateway process already owns the profile if the command exits immediately.
  • Read the final terminal line for a configuration or model-provider problem before retrying.
  • Help me start the Hermes gateway.
  • Return to the open Hermes Desktop window.
  • Select Bots in the left sidebar.
  • Select New Group Chat in the Bots pane.
  • Enter TaskFlow Sprint Room as the room name.
  • Add manager, backend, frontend, qa, and devops to the room.

You should see the TaskFlow Sprint Room open with manager, backend, frontend, qa, and devops listed as members.

Why use Group Chat before Kanban?

The room makes consultation visible. You can follow who speaks, when they speak, and which concern each specialist raises.

Kanban worker runs use separate task sessions later. The room aligns the team, while the manager's card contract controls execution.

Before the room starts talking, choose the tab that matches how you want to check each profile's AI model.

✔️ My models look right

  • Open a second terminal
  • Print the configuration summary for all five profiles by running these commands:
hermes profile show manager
hermes profile show backend
hermes profile show frontend
hermes profile show qa
hermes profile show devops

ⓧ One or more models need attention

  • Open a second terminal
  • Print the configuration summary for all five profiles by running these commands:
hermes profile show manager
hermes profile show backend
hermes profile show frontend
hermes profile show qa
hermes profile show devops
  • Open the affected profile's provider and model picker by running this command:
hermes -p [[PROFILE_NAME="profile name"]] model

Complete only the sign-in flow for a provider you intend to use, and never share the credential.

  • Select the provider you want this profile to use.
  • Select an available model from that provider.
  • Finish the picker to save the new default.

Hermes saves the choice for new sessions. Create a fresh TaskFlow Sprint Room with the same five profiles before sending the huddle prompt.

Run autonomous team ideation
  • Start the autonomous ideation session by pasting this message into the room:
Run an autonomous three-round pre-flight ideation session for TaskFlow Sprint 2.

Round 1: Establish the risks.
Manager: Open with a brief agenda and restate the fixed contract.
Backend: Identify one API or data risk. End your reply by mentioning the Frontend profile and asking it one concrete question.
Frontend: Identify one integration or interface risk. End your reply by mentioning the QA profile and asking it one concrete question.
QA: Identify one acceptance or failure-case risk. End your reply by mentioning the DevOps profile and asking it one concrete question.
DevOps: Identify one runtime or delivery risk. End your reply by mentioning the Backend profile and asking it one concrete question.
Do not mention the Manager profile during round 1.

Round 2: Challenge and refine.
Each specialist must answer the question directed at its role. State whether you agree, disagree, or need clarification. Update one safeguard or acceptance check based on the discussion.
End each round 2 reply by mentioning the Manager profile. The Manager should remain silent during this round.

Round 3: Reconcile the plan.
Manager: Review the specialist discussion. Reconcile disagreements and summarize the final contract, dependencies, safeguards, and acceptance checks.

Keep the contract fixed: four tasks with id, title, owner, and status; filters All, Todo, Doing, and Done.
Confirm this delivery order: Backend and Frontend first, QA after both, then DevOps.
Do not create Kanban cards or implement code.
Keep every specialist message to two to four sentences.

How does Hermes route this ideation session?

  • The opening message contains no direct profile mentions, so Hermes invites every room member into the first round.
  • Each specialist mentions a different teammate, which routes the second round into a cross-role challenge.
  • The specialists mention the Manager profile after refining their safeguards, which routes the final round back to the manager.
  • A Bot can still pass when it has nothing useful to add, so the role-specific questions give every specialist a concrete contribution.
  • Press Enter to start the huddle.

First, you should see all four specialists publish a role-specific risk and hand a question to another teammate. In the second round, each specialist should answer the incoming challenge and revise one safeguard or acceptance check.

Finally, the manager should reconcile the visible debate into the fixed contract, final safeguards, acceptance checks, and delivery order. These three autonomous rounds normally take two or three minutes, so short quiet pauses are expected.

Ideation session stalled or skipped a round?

  • Select Stop in the room if no visible message appears after five minutes.
  • Confirm that the gateway terminal is still running.
  • Check that the pasted opening message contains no direct profile mentions, because a direct mention narrows the first round.
  • Create a fresh group chat with the same five profiles before retrying the autonomous ideation session.
  • Help me diagnose the autonomous ideation session.
  • Choose one dependency or acceptance concern from the huddle.
  • Record it as one pre-flight risk from the huddle so the manager can carry it into the sprint contract.

This makes the consultation consequential. The same risk becomes a QA requirement when the delivery graph is created.

  • Return to the terminal running the gateway.
  • Press Ctrl+C to stop the gateway.

The terminal should return to its prompt. Your visible alignment is complete, while the dispatcher is paused before any cards exist.

You have watched the team challenge and confirm one shared contract. Next, you will turn that agreement into reusable Frontend and QA guidance before any cards exist.

Equip the Specialists with Skills

Your five profiles have agreed on one TaskFlow contract. Now you will give the Frontend and QA specialists reusable guidance before the manager assigns their cards.

Hermes Skills turn repeatable guidance into instructions that a specialist can load on demand. You will create one skill for UI delivery and one for quality checks.

In this step, get ready to:
  • Teach Frontend the TaskFlow UI contract.
  • Teach QA the TaskFlow quality contract.
  • Verify that both specialists can load their skill.
Teach Frontend the UI contract

The Frontend specialist needs the same endpoint, fields, and filters every time it works on TaskFlow. The first skill packages those constraints into one reusable playbook.

  • Return to the open Hermes Desktop window.
  • Select Bots in the left sidebar.
  • Select the frontend profile from the Bots list.

Create the Frontend skill by pasting this request into the message box:

/learn Create a reusable skill named taskflow-ui for TaskFlow frontend delivery. Teach the specialist to preserve the GET /api/tasks contract, render task id, title, owner, and status safely, provide All, Todo, Doing, and Done filters, and verify each filter before handoff.

This can take a minute while Hermes writes and checks the skill. You should see confirmation that taskflow-ui was created or approved.

What does /learn create?

/learn turns the described workflow into a reusable SKILL.md under ~/.hermes/skills/. The skill then becomes available as a slash command.

🙋‍♀️ Frontend skill not created?

  • Check the newest Frontend reply for a pending write-approval request.
  • Confirm that the request begins with /learn if Hermes treats it as an ordinary message.
  • Help me create the TaskFlow UI skill.
Teach QA the quality contract

The QA specialist needs checks that cover the browser page, API response, and risk captured during the huddle. The second skill turns those acceptance boundaries into a repeatable review.

  • Return to the Bots list in Hermes Desktop.
  • Select the qa profile.
  • Create the QA skill by pasting this request into the message box:
/learn Create a reusable skill named taskflow-quality for TaskFlow verification. Teach the specialist to check the browser page, GET /api/tasks, four task objects with id, title, owner, and status, every status filter, and the recorded pre-flight acceptance risk. Require clear evidence for each check before handoff.

You should see confirmation that taskflow-quality was created or approved.

QA skill not created?

  • Check that the skill name in the request is taskflow-quality.
  • Review any pending write request before sending the learning prompt again.
  • Help me create the TaskFlow quality skill.
Verify both specialist skills

Hermes Desktop loads a skill before the specialist answers with it. Enter the skill command first, then send the request as a separate message.

  • Return to the frontend Bot Chat.
  • Load the Frontend skill by entering this command:
/taskflow-ui

You should see Loading skill: taskflow-ui. That line confirms Desktop found the Frontend skill.

  • Ask Frontend to use the loaded skill by sending this separate message:
Summarize the TaskFlow UI contract and the checks you would run before handoff.
  • Return to the qa Bot Chat.
  • Load the QA skill by entering this command:
/taskflow-quality

You should see Loading skill: taskflow-quality. That line confirms Desktop found the QA skill.

  • Ask QA to use the loaded skill by sending this separate message:
Summarize the TaskFlow acceptance checks and the evidence required before handoff.

You should see QA cover the page, API shape, filters, and recorded pre-flight risk. Both specialists now have reusable instructions before dispatch begins.

Skill does not load?

Seeing Loading skill confirms that Desktop found the skill. Continue with the separate request shown above.

Use the terminal fallback only when the loading line does not appear or Desktop rejects the skill command.

  • Check that the earlier learning reply says the requested skill was created or approved.
  • Return to the terminal you used earlier.
  • Start the matching specialist profile by running one of these commands:
# Frontend profile
hermes -p frontend chat

# QA profile
hermes -p qa chat
  • Enter /reload-skills in the interactive terminal chat.
  • Return to the affected specialist's Bot Chat in Hermes Desktop.
  • Enter the bare skill command again.
  • Help me load the new TaskFlow skill.

Your specialists are aligned and equipped with reusable guidance. Next, you will connect a clean TaskFlow repository to a paused board and turn the contract into a delivery graph.

Prepare the TaskFlow Board

Prepare and Plan the TaskFlow Board

Your Frontend and QA specialists can now load reusable TaskFlow guidance. Next, you will give the equipped team a clean repository, a paused board, and a dependency-gated plan.

Kanban stores the sprint history, while a clean Git checkout gives every worker the same starting point. The gateway remains stopped so you can separate planning from execution.

In this step, get ready to:
  • Protect the TaskFlow starting point.
  • Create and connect the TaskFlow Sprint board.
  • Turn the sprint contract into a queued delivery graph.
Protect the TaskFlow starting point

Hermes creates preserved worktrees from the board's project directory. Check the existing TaskFlow repository before any specialist card can use it.

  • Select the terminal whose prompt is inside the TaskFlow repository from Part 4.
  • Print the repository's absolute path by running this command:
pwd
  • Record the printed path as your absolute TaskFlow repository path.
  • Inspect the checkout and linked worktrees by running these commands:
git status --short
git worktree list

A clean checkout prints no status changes. The worktree list should identify the main checkout without a new running TaskFlow worker.

Unexpected changes or worktrees?

  • Review every file listed by the status command before continuing.
  • Inspect any unfamiliar worktree before creating the board.
  • Help me make the TaskFlow checkout clean safely.
Create and connect the sprint board

The board is the manager's durable coordination surface. Its project directory tells implementation cards where to create isolated worktrees.

  • Create and select the TaskFlow Sprint board by running this command:
hermes kanban boards create taskflow-sprint --name "TaskFlow Sprint" --description "Manager-led delivery for TaskFlow Sprint 2" --switch

You should see confirmation that taskflow-sprint is the active board.

Board already exists?

Keep the existing taskflow-sprint board so its durable history stays intact. Select TaskFlow Sprint in the dashboard instead of deleting it.

Help me inspect the existing TaskFlow Sprint board.

Hermes Web Dashboard provides the visual settings for the active board. It runs independently from the stopped gateway.

  • Launch the Hermes Web Dashboard by running this command:
hermes dashboard
  • Keep the dashboard terminal open while the web interface runs.
  • Open the local dashboard URL printed in the terminal.
  • Select Kanban in the dashboard navigation.
  • Select the TaskFlow Sprint board.
  • Open Settings for the selected board.
  • Enter your absolute TaskFlow repository path in the Project directory field.
  • Click Save.

You should see the absolute TaskFlow path remain in the Project directory field after saving. The active board is now connected to the clean checkout.

Project directory not saving?

Check that the path begins at the filesystem root and ends at the existing TaskFlow repository. A relative path or parent directory points workers at the wrong files.

Help me verify the TaskFlow project directory.

Plan and inspect the delivery graph

The connected board can now hold the full sprint plan without launching workers. The manager will create the cards while the dispatcher remains stopped.

  • Return to the open Hermes Desktop window.
  • Click Bots in the left sidebar.
  • Select the manager profile from the Bots list.
  • Paste this Sprint 2 brief into the manager's message box:
Lead TaskFlow Sprint 2 as the Engineering Manager. Use your native Kanban tools and do not implement the feature yourself.

First inspect the available profiles. Decide one shared contract for a local Python process that serves the existing frontend and exposes GET /api/tasks. The response must contain four tasks with id, title, owner, and status. The frontend must provide All, Todo, Doing, and Done filters.

Treat this pre-flight concern as a QA acceptance requirement: [[PREFLIGHT_RISK="one pre-flight risk from the huddle"]].

Create Backend and Frontend implementation cards that can run in parallel. Require Backend to create backend/server.py. Require Frontend to load the taskflow-ui skill before updating the existing frontend files without changing the API contract.

Create a QA card gated on both implementation cards. Require QA to load the taskflow-quality skill before creating scripts/smoke_check.py. The script must verify the page, API, and recorded pre-flight concern. It must close its temporary server and print PASS: smoke-check succeeded when every check passes.

Create a DevOps integration card gated on QA. Require DevOps to combine the completed branches and run the smoke check with the correct Python command for the worker's operating system.

Every worker must commit its changes and report changed_files, verification, and branch in completion metadata. Reply with the card IDs and dependency order after the graph exists. Do not ask me to contact the specialists.

How does this brief shape the sprint?

  • The shared HTTP contract fixes the endpoint and response shape before parallel work begins.
  • Frontend and QA load the skills you created before carrying out their cards.
  • Backend and Frontend form the first parallel layer.
  • QA waits for both implementations. DevOps waits for QA.
  • Each worker must report its commit, changed files, verification, and branch.
  • Press Enter to send the brief.
  • Keep the manager's direct Bot Chat open.
  • Wait for the manager's reply beneath your message.

The manager may take about a minute while it inspects profiles and creates four linked cards. A quiet chat during that work does not mean it has stalled.

You should receive four card IDs and the dependency order in the manager's reply.

Manager did not create the graph?

  • Confirm that the brief was sent inside the manager profile's direct Bot Chat.
  • Remind the manager to route work through its native Kanban tools if it asks you to contact a specialist.
  • Confirm that the manager profile still has its orchestrator toolsets if it reports missing Kanban access.
  • Help me diagnose the missing TaskFlow graph.
  • Find the four specialist card IDs in the manager's newest reply.
  • Confirm that Frontend must load taskflow-ui.
  • Confirm that QA must load taskflow-quality.
  • Confirm that every worker reports changed_files, verification, and branch.
  • Return to the open Hermes Web Dashboard.
  • Select Kanban in the dashboard navigation.
  • Open the TaskFlow Sprint board.
  • Confirm that Backend and Frontend have no dependencies.
  • Confirm that QA depends on both implementation cards.
  • Confirm that DevOps depends on QA.

How do the dependency gates work?

  • Backend and Frontend form the first parallel layer.
  • QA unlocks only after both implementation cards finish.
  • DevOps unlocks only after QA verifies the combined result.

Before you check, do you think a recorded plan can change the repository while the dispatcher is stopped?

  • Inspect the queued board, main checkout, and linked worktrees by running these commands in the TaskFlow terminal:
hermes kanban list
git status --short
git worktree list

You should see Backend and Frontend waiting in the queue. QA should remain gated on both cards, while DevOps remains gated on QA.

The status check should print no changes. The worktree list should show no new running specialist workspace.

Why is everything still queued?

This is the intended shortfall. The manager has created durable specialist work, but the stopped dispatcher leaves ready cards queued.

Planning records what should happen. Execution begins only when a dispatcher can claim ready cards and launch workers.

  • Confirm that the TaskFlow Sprint board is selected if the four cards are missing.
  • Compare the board's dependency links with the manager's reported order if QA or DevOps is not gated correctly.
  • Help me verify the queued TaskFlow graph.

Your equipped team now has a clean starting point and a complete delivery graph. Next, you will start the dispatcher and watch the specialist skills, dependencies, and handoffs turn that plan into a working TaskFlow demo.

Run, Review, and Demo TaskFlow

Your manager has created a complete delivery graph, but every card is still queued. Now you will turn that plan into running work and a live TaskFlow demo.

Hermes Kanban records each handoff while the gateway dispatcher launches ready workers. Their isolated Git worktrees protect the main checkout until you merge the reviewed integration branch.

In this step, get ready to:
  • Run the queued delivery graph.
  • Review the manager's consolidated handoff.
  • Merge and demo the verified TaskFlow build.
Run the delivery graph

The event stream preserves the execution order even when workers finish quickly. Start watching before you release the queued cards.

  • Press Cmd+Space (macOS), press the Windows key (Windows), or open your app launcher (Linux).
  • Type Terminal on macOS or Linux. Type PowerShell on Windows.
  • Press Enter to open the watch terminal.
  • Start the Kanban event stream by running this command:
hermes kanban watch

You should see the event stream waiting for card updates. Keep this terminal open.

Before you start the dispatcher, which two cards do you expect to leave the queue first?

  • Open another terminal through system search.
  • Start the gateway dispatcher by running this command:
hermes gateway run

Keep the gateway terminal open because this process runs the dispatcher. The watch terminal should show Backend and Frontend moving first.

What does the gateway do?

The gateway launches ready cards as separate worker processes. QA remains queued until Backend and Frontend finish, then DevOps waits for QA.

The graph can complete faster than you can switch windows. The event stream preserves the sequence when every card reaches Done quickly.

Allow a few minutes for the workers to finish. Quiet periods are normal while each specialist completes its task and records the handoff.

  • Return to the open Hermes Web Dashboard.
  • Select Kanban in the dashboard navigation.
  • Open the TaskFlow Sprint board.
  • Confirm that Backend, Frontend, QA, and DevOps reach Done.
  • Inspect each card's Run History for its completed worker run.

That is the dispatcher gap closed. The queued plan has become four completed specialist handoffs in dependency order.

A card did not reach Done?

  • Check the gateway terminal for a worker failure or a card that remains running.
  • Open the stalled card's Run History to identify the failed handoff.
  • Help me diagnose the stalled TaskFlow graph.
Review the consolidated handoff

The board proves that work completed. The manager's report connects those card results into one reviewed delivery decision.

  • Keep the watch terminal open until the DevOps event reaches done.
  • Press Ctrl+C in the watch terminal to stop the event stream.
  • Return to the manager's direct Bot Chat in Hermes Desktop.
  • Scroll to the newest consolidated sprint report.
  • Find the completed Backend and Frontend summaries.
  • Read the QA verification evidence.
  • Compare the DevOps verification with the shared task contract.
  • Record the reported integration branch as the DevOps integration branch.

Consolidated report missing?

Send this follow-up only if the newest manager reply does not contain a consolidated report:

Review the TaskFlow board you created. Confirm every dependency is complete, summarize the QA evidence, and report the DevOps integration branch plus the exact verification it ran. If anything is blocked, route the smallest corrective card to the right specialist instead of implementing the fix yourself.

Wait for the manager to add the report to the same conversation.

Help me request the missing manager report.

Before you inspect the final board state, do you expect any implementation or verification card to remain incomplete?

  • Compare the board totals, completed DevOps card, and preserved worktrees by running these commands in the TaskFlow terminal:
hermes kanban stats
hermes kanban list --assignee devops --status done
git worktree list

What do these checks prove?

  • The board statistics should show all four specialist cards complete.
  • The filtered list should show the completed DevOps handoff.
  • The worktree list should show the preserved specialist branches created during execution.

Report and board do not agree?

Compare the DevOps completion summary with the manager's report. Ask the manager to inspect any mismatch or blocked dependency.

Help me reconcile the report and board.

Merge and demo TaskFlow

The reviewed branch remains isolated from your main checkout. Check the main checkout before you bring that work into the version you will demo.

  • Check the main TaskFlow checkout by running this command:
git status --short

A clean checkout prints no output. Stop before merging if the command lists a change you still need.

Seeing .worktrees/ in the status?

Hermes may preserve specialist workspaces inside .worktrees/. Keep that directory while excluding it from this repository's status checks.

  • Exclude the local worktree directory by running these commands:
echo ".worktrees/" >> .git/info/exclude
git status --short

The second command should return no output.

Merging changes the main checkout. Your clean status gives you a safe point to return to if the branch needs review.

  • Merge the DevOps integration branch into the main checkout by running this command:
git merge [[DEVOPS_BRANCH="the DevOps integration branch"]]

You should see a merge summary before the terminal returns to the prompt. The reviewed API, frontend, tests, and run scripts now live in your main checkout.

Seeing a merge conflict?

Keep both sides of the conflict intact while you ask the manager to route a neutral reconciliation card. This prevents either original implementation worker from choosing the winning version.

Help me request a neutral Git reconciliation.

Python runs a smoke check against the merged API contract and browser page. The script closes its temporary server after both checks.

Before you run the smoke check, do you expect the merged branch to pass every API and page check?

  • Verify the merged TaskFlow build by running this command:

macOS

python3 scripts/smoke_check.py

Windows

py scripts/smoke_check.py

Linux

python3 scripts/smoke_check.py

You should see PASS: smoke-check succeeded. This confirms that the merged branch satisfies the contract reported by DevOps.

  • Start the local TaskFlow server by running this command:

macOS

python3 backend/server.py

Windows

py backend/server.py

Linux

python3 backend/server.py

Keep this terminal open while the server runs. You should see Serving on http://localhost:8000/ (API at /api/tasks).

Smoke check fails or server does not start?

Read the failing smoke-check line to identify whether the API or page check failed. Confirm that the merge included scripts/smoke_check.py.

Another process may already use port 8000. Stop the earlier TaskFlow server before retrying.

Help me diagnose the TaskFlow verification failure.

Before you load the page, what task count do you expect when the All filter is active?

  • Open http://localhost:8000/ in a browser tab.
  • Confirm that the All view shows four task cards and 4 of 4 tasks.
  • Click Todo.
  • Click Doing.
  • Click Done.
  • Confirm that each filter shows only cards with the matching status.
  • Open http://localhost:8000/api/tasks in a second browser tab.
  • Confirm that the response contains four task objects with id, title, owner, and status.

You have closed the full delivery loop. One manager conversation produced a reviewed branch, a passing smoke check, and a working browser demo.

TaskFlow is live and verified. You have completed the manager-led delivery loop from feature brief to working browser demo.

Secret mission

Route a Post-Release Search Improvement

Route a post-release title-search request through the same manager-led team. Watch Frontend, QA, and DevOps complete a smaller dependency chain, then merge and demo the verified change.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your local resources running, pause them for later, or delete the project-specific coordination artifacts. Everything runs locally, so there are no ongoing infrastructure costs.

Resources you used:

  • The local TaskFlow server, Hermes gateway dispatcher, and Hermes Web Dashboard processes.
  • The taskflow-sprint Kanban board.
  • The linked Git worktrees created for specialist cards.

Keep everything running

No action is needed. Choose this if you are still reviewing delivery history or testing the live TaskFlow board.

  • Keep the TaskFlow server running to continue using the local demo.
  • Keep the gateway running to route more manager-created cards.
  • Keep the sprint board and worktrees to preserve the full handoff history.

Pause - I'll come back to this later

Shut down the running processes to free local ports and memory. Your board, worktrees, and merged TaskFlow files remain available.

  • Return to the TaskFlow server terminal and press Ctrl+C.
  • Return to the gateway terminal and press Ctrl+C.
  • Return to the Hermes Web Dashboard terminal and press Ctrl+C.

Each terminal should return to its normal prompt. Your saved coordination history stays on disk.

Delete - I don't want to use this again

Deleting the sprint board and linked worktrees permanently removes their local coordination history. Your merged TaskFlow source remains in the main repository.

  • Return to the TaskFlow server terminal and press Ctrl+C.
  • Return to the gateway terminal and press Ctrl+C.
  • Return to the Hermes Web Dashboard terminal and press Ctrl+C.
  • Move into the TaskFlow repository by running this command:
cd "[[TASKFLOW_REPO_PATH="your absolute TaskFlow repository path"]]"
  • List the main checkout and linked worktrees by running this command:
git worktree list

You should see the main TaskFlow checkout plus any linked specialist worktrees that remain.

  • Record one linked specialist path as linked specialist worktree path.
  • Remove that clean linked worktree by running this command:
git worktree remove "[[WORKTREE_PATH="linked specialist worktree path"]]"
  • Repeat the removal command for each remaining specialist worktree.
  • Confirm that only the main checkout remains by running this command:
git worktree list

You should now see only the main TaskFlow checkout.

Worktree not clean?

Git refuses to remove a worktree with uncommitted changes. Preserve any files you need, then commit or discard those changes before retrying.

Help me remove a linked worktree safely.

  • Delete the TaskFlow sprint board by running this command:
hermes kanban boards rm taskflow-sprint --delete

The command should return to the prompt without an error. The sprint board and specialist worktrees are now removed.

Nice Work!

Nice Work!

Nice work! You orchestrated a manager-led TaskFlow sprint from specialist assignment through integration, testing, and a working browser demo.

You've learned how to:

  • Lead a visible five-role Hermes team huddle in Bot Mode, with one Engineering Manager controlling the final delivery contract.
  • Turn one brief into a dependency-gated Kanban delivery graph that routes work through implementation, QA, and DevOps.
  • Integrate reviewed Git worktrees into a working TaskFlow demo with API-backed cards and status filters.
  • Complete the Secret Mission by routing title search through Frontend, QA, and DevOps, then verifying the merged change in the browser.

Ready to quiz yourself?