Build a Hermes AI Engineering Manager

Turn Hermes into an Engineering Manager that plans a live GitHub sprint.

Introduction

30 Second Summary

Sprint planning can quickly become messy, scattered notes, open GitHub issues, and a team waiting for clear priorities.

In this project, you’ll turn Hermes into an AI Engineering Manager for TaskFlow. You’ll give Hermes the context it needs to understand your project, turn ideas into a structured sprint backlog, create an actionable plan, and use live GitHub work to identify delivery risks.

What You'll Build

You'll open TaskFlow's GitHub repository to see eight labeled Sprint 1 issues, a plan tied to those issues, and a readiness report grounded in the team's real workload.

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

  • A persistent Engineering Manager that enters every TaskFlow session with the same role, team, and operating rules.
  • A Sprint 1 backlog with eight scoped GitHub issues, visible priorities, work types, owners, and acceptance criteria.
  • An evidence-based sprint plan and readiness report that link to live issues and expose dependencies, blockers, and delivery risks.
  • Secret Mission: Connect Hermes to Slack through MCP and post a Sprint 1 kickoff announcement in the engineering channel.

Want a complete demo of how to do this project, from start to finish? Check out our walkthrough with Nikko.

Are there any prerequisites?

Hermes needs its OpenRouter and GitHub MCP connections before it can manage the sprint.

Complete or repeat the OpenRouter setup and the MCP setup on this computer, with Visual Studio Code installed for editing the configuration.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Verify Your Setup

Before Hermes can manage a GitHub project, every tool in the chain needs to be connected and working.

A broken MCP connection discovered mid-project wastes time and creates confusion about whether Hermes or the setup is at fault. In this step, you will verify each piece of your toolchain so you can build with confidence.

In this step, get ready to:
  • Confirm Hermes responds through OpenRouter.
  • Connect and verify the GitHub MCP Server.
  • Test the MCP connection with a live GitHub query.
Confirm Hermes and OpenRouter

Hermes routes requests through OpenRouter to reach whichever language model you configured in Part 1. A quick query proves that chain is still alive.

  • Press Cmd+Space (macOS), the Windows key (Windows), or the Super key (Linux) to open system search.
  • Type Terminal on macOS or Linux, or PowerShell on Windows. Press Enter to open it.
  • Set Hermes to use OpenRouter's free-model router by running this command:
hermes config set model openrouter/free

Keep the project free

OpenRouter's openrouter/free router selects an available free model that supports the request's required features. Free-model availability changes frequently, so the model used and its availability can vary between requests.

The current Free plan allows 50 requests per day. If you reach that allowance, wait for the daily reset to continue at no cost. Adding paid credits is optional. Check the OpenRouter pricing page for the latest limit.

  • Test your Hermes-to-OpenRouter connection by running this command:
hermes chat -q "Hello, what model are you using?"

✔️ Hermes responded with a model name

Hermes is connected to OpenRouter and ready to go. Move on to the next substep.

ⓧ Hermes returned an error or no response

If Hermes did not respond with a model name, reconfigure the OpenRouter provider.

  • Run the model configuration wizard by running:
hermes model
  • Select OpenRouter as the provider.
  • Enter your OpenRouter API key when Hermes requests it.
  • Choose the model with the ID openrouter/free so this project uses zero-cost inference.
  • Run the Hermes connection test again. You should receive a response that identifies the active free model.

Still not getting a response?

Check that the API key is active and that your OpenRouter account has free requests or paid credits available. Confirm that the selected model supports tools and at least 64K tokens of context.

Help me troubleshoot my Hermes and OpenRouter connection.

Verify Node.js, npm, npx, and Git

The Secret Mission uses Node.js to run its Slack MCP server. Later steps use Git to record and push the sprint documents, so verify both toolchains now.

  • Confirm Node.js, npm, npx, and Git are installed by running these checks:
node -v
npm -v
npx -v
git --version

✔️ I see four version lines

Your terminal should print four version lines. That confirms Node.js, npm, npx, and Git are ready for the remaining steps.

ⓧ A Node.js command fails

Install the current Node.js LTS release to add Node.js, npm, and npx.

  • Open the official Node.js download page.
  • Select the installer for your operating system.
  • Choose the release marked LTS.
  • Run the installer with its default options.
  • Close your current terminal after the installation finishes.
  • Open a new terminal through your operating system's search bar.
  • Run the four version checks again. You should see one result on each line.

Still missing Node.js, npm, or npx?

Help me restore the Node.js commands.

ⓧ Git is not recognized

Install Git before you continue. The later sprint steps use it to commit and push the files Hermes creates.

  • Open the official Git download page.
  • Select the installer for your operating system.
  • Run the installer with its default options.
  • Close your current terminal after the installation finishes.
  • Open a new terminal through your operating system's search bar.
  • Run the four version checks again. You should now see a Git version on the fourth line.

Still seeing a Git error?

Help me restore the Git command.

Git stores an author name and email in every commit. Check both now so your first local commit does not stop for a missing identity.

  • Check the global name and email Git will use by running these commands:
git config --global user.name
git config --global user.email

✔️ I see my name and email

You're set. Git can attach your identity to every commit you create on this computer.

ⓧ One or both lines are blank

A blank line means the matching global value is missing. Set both values once so Git can use them in every repository on this computer.

  • Configure your Git author name and email by running these commands:
git config --global user.name "[[GIT_USER_NAME="your name"]]"
git config --global user.email "[[GIT_USER_EMAIL="your email address"]]"
  • Run the two identity checks again.

You should see your name on the first line and your email on the second.

Git identity still missing?

Make sure each setup command includes --global and a value inside quotation marks. Then rerun the checks in the same terminal.

Help me configure my Git author identity.

Confirm GitHub MCP Server

The GitHub MCP Server gives Hermes the ability to create repositories, issues, labels, and more. It runs as a Docker container that connects to the GitHub API using your Personal Access Token.

✔️ I already have GitHub MCP connected

If you set up the GitHub MCP Server in a previous project, confirm it still works.

  • Verify your GitHub MCP tools are visible by running:
hermes chat -q "List all MCP tools you have available"

You should see tools prefixed with mcp__github__ in the output. Confirm the list includes create_repository, issue_write, label_write, and create_or_update_file.

Tools might take a moment to appear

If the tool list is empty on the first try, Docker may still be starting the MCP container. Wait a few seconds and run the command again.

ⓧ I need to set up GitHub MCP

Follow these steps to connect Hermes to GitHub via the MCP Server.

  • Confirm Docker is running by running:
docker info

✔️ I see Client and Server sections

Docker is ready. The Client and Server sections confirm that the Docker CLI can reach the running Docker Engine.

ⓧ Docker is installed but stopped

Docker is installed, but its engine is not running yet.

  • Press Cmd+Space on macOS or the Windows key on Windows to open search.
  • Enter Docker Desktop and press Enter.
  • Wait until Docker Desktop reports that the engine is running.
  • On Linux, follow the startup instructions in the official Docker Engine guide for your distribution.
  • Run the Docker check again. You should see both Client and Server sections.
Docker Engine still unavailable?

Help me start the Docker Engine.

ⓧ Docker is not installed

Install Docker before configuring the GitHub MCP server.

  • Open the official Docker installation guide.
  • Choose your operating system.
  • Complete the documented installation steps.
  • Open Docker Desktop on macOS or Windows after installation.
  • Open a new terminal through your operating system's search bar.
  • Run the Docker check again. You should see Client and Server sections.
Docker command still missing?

Help me restore the Docker command.

  • Create a GitHub Personal Access Token by visiting:
https://github.com/settings/personal-access-tokens/new
  • Sign in to your GitHub account if GitHub prompts you.
  • Enter Hermes MCP in the token name field.
  • Select All repositories under Repository access.
  • Expand Repository permissions under Permissions.

Limit the token permissions

The token only needs access to repository content and issue tracking for this project. Set each permission separately so GitHub grants no extra account access.

  • Set Contents to Read and write.
  • Set Issues to Read and write.
  • Set Administration to Read and write.
  • Click Generate token.
  • Copy the token value immediately. GitHub only displays it once.

Why these permissions?

Hermes needs to create repositories, push files, create issues, and manage labels. These permissions give it full control over repository content and issue tracking without granting access to unrelated account settings.

macOS

  • Press Cmd+Space to open Spotlight.
  • Enter Visual Studio Code and press Enter.
  • Click File in the top menu bar.
  • Click Open File.
  • Press Cmd+Shift+G in the file chooser.
  • Enter ~/.hermes/config.yaml and click Open.
  • Find the mcp_servers key and choose the matching outcome below.

Windows

  • Press the Windows key to open search.
  • Enter Visual Studio Code and press Enter.
  • Click File in the top menu bar.
  • Click Open File.
  • Enter %USERPROFILE%\.hermes in the file chooser's address bar.
  • Select config.yaml.
  • Click Open.
  • Find the mcp_servers key and choose the matching outcome below.

Linux

  • Press the Super key to open search.
  • Enter Visual Studio Code and press Enter.
  • Click File in the top menu bar.
  • Click Open File.
  • Press Ctrl+L in the file chooser.
  • Enter ~/.hermes/config.yaml and press Enter.
  • Find the mcp_servers key and choose the matching outcome below.

✔️ I already have mcp_servers

  • Add the github block beneath your existing mcp_servers key. Keep it aligned with your other server names.
github:
  command: "docker"
  args: ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"]
  env:
    GITHUB_PERSONAL_ACCESS_TOKEN: "github_pat_your-token-here"

ⓧ I do not have mcp_servers

  • Add the complete mcp_servers section to the end of the file.
mcp_servers:
  github:
    command: "docker"
    args: ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "github_pat_your-token-here"

What does this config do?

  • The command and args tell Hermes to spin up the official GitHub MCP Server Docker image each time it needs GitHub tools.
  • The env section passes your Personal Access Token into the container so it can authenticate with the GitHub API.
  • The --rm flag automatically removes the container when the session ends, keeping your system clean.
  • Replace github_pat_your-token-here with the fine-grained Personal Access Token you copied.
  • Save config.yaml.
  • Keep the token private. Do not commit the file or include the token in a screenshot.
  • Return to your normal terminal prompt after saving config.yaml.
  • Start the Hermes TUI by running this command:
hermes --tui
  • Wait until the Hermes TUI opens.
  • Reload the MCP servers by entering the slash command below inside the Hermes TUI. Do not run it at your normal shell prompt.
/reload-mcp

You should see output confirming the GitHub MCP server connected. Hermes will list the tools it discovered from the server.

MCP connection failed?

If you see errors about Docker or the container failing to start, check the following:

  • Run the Docker check again to confirm the Docker Engine is running.
  • Check that your YAML indentation uses spaces. The github key must sit directly beneath mcp_servers.
  • Verify that a fine-grained token starts with github_pat_. A classic token starts with ghp_.
  • Remove any spaces or quote characters that you accidentally copied around the token.

Help me fix my GitHub MCP Server connection in Hermes.

✔️ Awesome, I've got everything!

Great. Make sure you saved config.yaml and move on to the final test below.

ⓧ I'd like to double check the full code

Your mcp_servers section in ~/.hermes/config.yaml should contain this entry (your token will be different):

mcp_servers:
  github:
    command: "docker"
    args: ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "github_pat_your-token-here"
Test GitHub MCP with a quick action

The config looks right, but you need to prove the connection actually works end-to-end. A live query that hits the GitHub API confirms both the MCP server and your token are valid.

Before you run the next command, what do you think Hermes will return? If everything is working, it should be able to see your real GitHub repositories.

  • Ask Hermes to list your GitHub repositories by running:
hermes chat -q "What repositories do I have on GitHub?"

Hermes should return a list of repositories from your GitHub account. This proves the MCP connection and token are both working correctly.

Hermes cannot access GitHub?

  • If Hermes says it has no GitHub tools, Docker may still be starting the container.
  • Start a new Hermes TUI session by running the command from the previous substep.
  • Enter /reload-mcp inside the Hermes TUI.
  • Wait a few seconds before asking the GitHub question again.
  • If Hermes returns a permissions error, your token may be missing the required repository scopes. Generate a new token with Contents, Issues, and Administration set to Read and write.
  • If Docker shows a pull error, check your internet connection. The image ghcr.io/github/github-mcp-server needs to download on first use.

Help me debug why Hermes cannot access my GitHub repositories.

Great, your toolchain is verified and ready. Next up, you will create the TaskFlow startup repository and build an engineering team for Hermes to manage.

Create the Startup Repository and Team

Your tools are verified and connected. Hermes can talk to GitHub through the MCP server, which means it can create repositories, files, and issues on your behalf.

Now Hermes needs a real project to manage. You will create TaskFlow on GitHub first, then clone that remote repository to your Desktop so later steps can edit the same project locally.

In this step, get ready to:
  • Create a public GitHub repository with structured project documentation.
  • Clone the remote repository into a local taskflow-nextwork-project folder on your Desktop.
  • Generate seven engineering roles that report to Hermes, including a Lead Software Engineer.
Create the repository and project scaffold

Every engineering project starts with a repository and foundational documentation. You will prompt Hermes to create a new public repository and populate it with three key documents that define the product.

  • Open a terminal. On macOS, press Cmd+Space, type Terminal, and press Enter.
  • On Windows, press the Windows key, type Terminal, and press Enter.
  • On Linux, press Ctrl+Alt+T to open a terminal window.
  • Move to your Desktop by running this command:
cd ~/Desktop
  • Start the Hermes TUI by running this command:
hermes --tui

Why start from the Desktop?

Hermes creates the repository through GitHub MCP, so the first copy exists on GitHub. Starting from your Desktop gives the later git clone command a predictable destination for the local copy.

The remote repository uses the name you recorded in taskflow-your-github-username. The local ~/Desktop/taskflow-nextwork-project folder is the copy you edit on your computer.

  • Choose a unique repository name and record it here: taskflow-your-github-username.
  • Include your GitHub username or another personal suffix so you do not need to rename or alter an existing repository.
  • Create the repository and its documentation by pasting this prompt into Hermes:
Create a new public GitHub repository called '[[YOUR_REPO_NAME="taskflow-your-github-username"]]' with the description 'AI-powered project management platform'. Then create the following files in it:
- README.md with a professional project overview for TaskFlow, an AI-powered project management platform.
- PRODUCT-REQUIREMENTS.md with realistic product requirements covering user authentication, task boards, AI task suggestions, team collaboration, and notifications.
- ARCHITECTURE.md with a technical architecture covering a React frontend, a Python and FastAPI backend, a PostgreSQL database, and AWS infrastructure.

What does this prompt do?

Hermes uses its GitHub MCP tools to create the remote repository and write three Markdown files. You describe the outcome in natural language while Hermes chooses the required tools.

Hermes may pause before the multi-step action. If it asks for approval, enter yes to continue.

  • Wait for Hermes to report the result of each GitHub action.
  • Open https://github.com in your browser.
  • Sign in to the same GitHub account connected to Hermes.
  • Select taskflow-your-github-username from your repository list.

✔️ The repository was created

You should see README.md, PRODUCT-REQUIREMENTS.md, and ARCHITECTURE.md in the new repository. That confirms Hermes created the remote project scaffold.

ⓧ The name is already in use

Keep the existing repository untouched. Choose a more specific value for taskflow-your-github-username by adding a short suffix such as your initials or the current year.

  • Update the repository name you recorded above.
  • Paste the repository-creation prompt again with the new value.
  • Open the new repository after Hermes reports success.

ⓧ Hermes returned another error

The failure usually points to the GitHub MCP connection, token permissions, or Docker Engine.

  • Return to Step 1 and confirm that Hermes can list your GitHub repositories.
  • Confirm that Docker Engine is running.
  • Confirm that the token grants read and write access to Contents, Issues, and Administration.
  • Run the repository-creation prompt again. You should see Hermes report each completed GitHub action.

Repository still not appearing?

Help me troubleshoot the repository creation.

Move from remote to local

The repository now exists on GitHub, but later steps work from files on your computer. Clone it before adding the team so both copies stay connected through Git.

  • Return to the terminal running the Hermes TUI.
  • Exit the Hermes TUI by pressing Ctrl+C.
  • Click Code on the repository page.
  • Select HTTPS in the clone options.
  • Click the copy icon beside the repository URL.
  • Store the copied URL here: https://github.com/your-username/your-repository.git.
  • Clone the remote repository to your Desktop by running this command:
git clone [[YOUR_REPO_URL="https://github.com/your-username/your-repository.git"]] taskflow-nextwork-project

You should see Git download the repository without an error. The new ~/Desktop/taskflow-nextwork-project folder is now linked to taskflow-your-github-username on GitHub.

Clone did not finish?

If taskflow-nextwork-project already exists, confirm that it belongs to this project before changing it. Move that project folder to a backup location or choose another empty destination. Leave unrelated repositories untouched.

Help me troubleshoot the clone.

  • Move into the cloned taskflow-nextwork-project folder and start the Hermes TUI by running these commands:
cd taskflow-nextwork-project
hermes --tui

You'll see the Hermes TUI open inside your local TaskFlow project. Hermes can now use the repository files as local project context.

Generate the engineering team

A project without a team is just a pile of documents. Hermes needs to know who is responsible for what, so it can assign work intelligently during sprint planning.

  • Confirm that the Hermes TUI is open inside ~/Desktop/taskflow-nextwork-project.
  • Generate the team roster by pasting this prompt into the Hermes TUI:
Use the GitHub MCP Server to create or update TEAM.md in the public '[[YOUR_REPO_NAME="taskflow-your-github-username"]]' repository on its default branch. Use the create_or_update_file tool so the file is written directly to GitHub. Do not create or modify a local TEAM.md file.

Start TEAM.md with this reporting structure: Hermes is the Engineering Manager, and seven engineers report directly to Hermes. Do not create a separate human Engineering Manager persona.

Define these 7 direct-report roles: Lead Software Engineer, Frontend Engineer, Backend Engineer, Cloud Engineer, Data Engineer, QA Engineer, and Technical Writer. For each engineer, include a realistic name, their role, specific responsibilities, code or system ownership areas, and expected Sprint 1 deliverables.

When the write finishes, return the GitHub file URL and commit SHA.

Why seven direct reports?

TaskFlow has Hermes as Engineering Manager plus seven direct reports. Each engineer owns a product or delivery domain, which gives Hermes clear rules for assigning sprint work later.

The names and personas Hermes generates will be referenced throughout the rest of the project. Hermes will use these names when creating issues and assigning tasks in the next steps.

  • Approve the GitHub write if Hermes asks for permission.
  • Wait for Hermes to return the GitHub URL and commit SHA for TEAM.md.
  • Open the returned GitHub URL in your browser.
Verify the remote repository

Before you think about what happens next, take a guess. What do you expect to see if you open the taskflow repository on GitHub right now?

  • Open the taskflow repository on GitHub in your browser.
  • Click into each file and confirm the following:
  • README.md contains a professional project overview for TaskFlow.
  • PRODUCT-REQUIREMENTS.md covers user authentication, task boards, AI task suggestions, team collaboration, and notifications.
  • ARCHITECTURE.md describes a React frontend, Python/FastAPI backend, PostgreSQL database, and AWS infrastructure.
  • TEAM.md names Hermes as Engineering Manager and lists seven direct reports, including a Lead Software Engineer.
  • Each report has a name, responsibilities, ownership areas, and Sprint 1 deliverables.

Files missing or incomplete?

Stay inside the Hermes TUI session in ~/Desktop/taskflow-nextwork-project and ask Hermes to repair the remote documentation.

  • Create or expand any missing TaskFlow files by pasting this prompt inside Hermes:
Inspect the public 'taskflow' repository on GitHub. Ensure README.md, PRODUCT-REQUIREMENTS.md, ARCHITECTURE.md, and TEAM.md all exist and contain the requirements from this step. Create missing files and expand incomplete sections. Preserve unrelated files.

Help me repair the missing documentation.

  • Return to the terminal running the Hermes TUI after completing the GitHub verification.
  • Exit the Hermes TUI by pressing Ctrl+C to restore your normal shell prompt.
  • Sync the local taskflow-nextwork-project folder with GitHub and list its files by running these commands:
cd ~/Desktop/taskflow-nextwork-project
git pull
ls

You'll see README.md, PRODUCT-REQUIREMENTS.md, ARCHITECTURE.md, and TEAM.md in the terminal output. Your local and remote project copies now contain the same team context.

Local files still missing?

If git pull requests authentication, complete GitHub's browser or credential prompt and run the commands again. If a file is still missing, confirm that Hermes created it on GitHub before pulling.

Help me synchronize the local repository.

Your startup has a home base. The repository has structured documentation and a full engineering team ready to go. Next up, you will give Hermes a persistent identity so it always knows it is the Engineering Manager of TaskFlow.

Promote Hermes to Engineering Manager

Your TaskFlow repository now contains the product documents and team roster from the previous step. The local copy on your Desktop matches the remote repository.

However, a fresh Hermes TUI session does not remember the conversation that created them. You will expose that gap before giving Hermes a project-specific Engineering Manager identity.

In this step, get ready to:
  • Test how Hermes responds without TaskFlow context.
  • Create an AGENTS.md file inside the existing local repository.
  • Verify that a fresh session adopts the Engineering Manager identity.
Experience the amnesia problem

The context gap only becomes visible when Hermes starts outside the TaskFlow repository. This run deliberately excludes the project files.

  • Return to your terminal window.
  • Exit any active Hermes TUI session by pressing Ctrl+C.
  • Move outside the TaskFlow repository by running this command:
cd ~/Desktop
  • Start a fresh Hermes TUI session from the Desktop by running:
hermes --tui

Before you ask, do you think Hermes can name TaskFlow or its engineering team from this location?

  • Ask Hermes about its identity by entering this prompt:
Who are you, what project are you managing, and who is on your engineering team?

You will get a generic answer with no reliable TaskFlow role or team roster. That shortfall is intentional: the conversation ended, so the project identity disappeared with it.

Why does this happen?

Hermes sessions are isolated. Starting a new session clears the previous conversation, so project instructions need a durable home.

A project context file restores those instructions at startup. The identity then comes from the repository instead of an old chat.

  • Exit the generic Hermes TUI session by pressing Ctrl+C.
Create the project context file

Hermes discovers AGENTS.md from your current folder and walks up to the Git repository root. Keeping the file inside taskflow limits this identity to the TaskFlow project.

Why AGENTS.md instead of SOUL.md?

SOUL.md lives in the Hermes home folder and applies globally. AGENTS.md is project-local, so the Engineering Manager identity activates only inside TaskFlow.

Hermes checks .hermes.md, AGENTS.md, CLAUDE.md, and .cursorrules in that order. It loads the first project context file it finds.

  • Press Cmd+Space (macOS), the Windows key (Windows), or the Super key (Linux) to open system search.
  • Type Visual Studio Code and press Enter.
  • Click File in the top menu.
  • Click Open Folder.
  • Select the taskflow folder on your Desktop.
  • Click Open.
  • Create AGENTS.md from the Explorer sidebar.
  • Paste the project instructions below into AGENTS.md:
# Engineering Manager Context

## Your Identity
You are the Engineering Manager for TaskFlow, an AI-powered project management platform.
You manage the seven engineers listed in TEAM.md. They report directly to you.

## Project Overview
TaskFlow uses React, Python with FastAPI, PostgreSQL, and AWS.
Read PRODUCT-REQUIREMENTS.md, ARCHITECTURE.md, and TEAM.md before planning work.

## Your Responsibilities
- Plan and manage sprints.
- Create GitHub issues with clear acceptance criteria.
- Match work to each team member's ownership area.
- Identify dependencies, blockers, and delivery risks.
- Maintain planning documents that reference real issue numbers.

## Working Style
- Name the responsible team member in every work item.
- Apply one priority label and one type label to each issue.
- Group sprint work under the Sprint 1 milestone.
- Verify live repository data before creating a plan.

What does this file do?

  • The identity section defines the role Hermes adopts for TaskFlow.
  • The project overview points Hermes to the repository files that hold the ground truth.
  • The responsibilities define the decisions Hermes owns.
  • The working style sets observable rules for issues and planning documents.
  • Save AGENTS.md by pressing Cmd+S (macOS) or Ctrl+S (Windows and Linux).
  • Open the integrated terminal by pressing Ctrl+`.
  • Confirm the terminal opened inside the taskflow folder by running:
pwd

You should see a path ending in /Desktop/taskflow on macOS or Linux, or \Desktop\taskflow on Windows.

  • Commit the context file and push it to GitHub by running these commands:
git add AGENTS.md
git commit -m "Add Engineering Manager context"
git push

What do these commands do?

  • git add AGENTS.md stages the new context file.
  • git commit records the file in local history.
  • git push sends the commit to the remote repository.

You should see the push complete without an error. Refresh the repository on GitHub and confirm that AGENTS.md appears beside the other TaskFlow documents.

Commit or push failing?

  • Confirm that AGENTS.md is saved directly inside ~/Desktop/taskflow.
  • Complete GitHub's credential prompt if git push requests authentication.
  • If git commit reports Author identity unknown, configure your name and email by running these commands:
git config --global user.name "[[GIT_USER_NAME="your name"]]"
git config --global user.email "[[GIT_USER_EMAIL="your email address"]]"
  • Run the commit and push commands again.

Help me troubleshoot the commit or push.

✔️ Awesome, I've got everything!

Your saved AGENTS.md now exists locally and on GitHub.

ⓧ I'd like to double check the full code

Compare your file with this complete reference:

# Engineering Manager Context

## Your Identity
You are the Engineering Manager for TaskFlow, an AI-powered project management platform.
You manage the seven engineers listed in TEAM.md. They report directly to you.

## Project Overview
TaskFlow uses React, Python with FastAPI, PostgreSQL, and AWS.
Read PRODUCT-REQUIREMENTS.md, ARCHITECTURE.md, and TEAM.md before planning work.

## Your Responsibilities
- Plan and manage sprints.
- Create GitHub issues with clear acceptance criteria.
- Match work to each team member's ownership area.
- Identify dependencies, blockers, and delivery risks.
- Maintain planning documents that reference real issue numbers.

## Working Style
- Name the responsible team member in every work item.
- Apply one priority label and one type label to each issue.
- Group sprint work under the Sprint 1 milestone.
- Verify live repository data before creating a plan.
Verify the Engineering Manager identity

The context file is now in the repository. A fresh Hermes TUI session started from taskflow should load it automatically.

  • Start the Hermes TUI from the integrated terminal by running:
hermes --tui

Before you ask, do you think this session can name both its role and the team it manages?

  • Test the loaded identity by entering this prompt:
Who are you, what project are you managing, and who is on your engineering team?

Hermes should identify itself as TaskFlow's Engineering Manager. It should also name team members or roles from TEAM.md without you restating the project context.

Hermes still responding generically?

Exit Hermes and run pwd at the normal shell prompt. The path must end in /Desktop/taskflow.

Confirm that the filename is exactly AGENTS.md and that no higher-priority .hermes.md file exists in the repository.

Help me diagnose the context loading.

Hermes now enters TaskFlow with a persistent role and operating rules. Next, you will put that identity to work by turning the product requirements into a labeled Sprint 1 backlog.

Build the Sprint Backlog

Hermes now enters TaskFlow as its Engineering Manager. The existing product documents and team roster give it enough context to turn plans into tracked work on GitHub.

A sprint backlog needs more than issue titles. You will create the sprint container yourself, then use the MCP connection to create consistent labels and eight scoped issues.

In this step, get ready to:
  • Create the Sprint 1 milestone in GitHub.
  • Create seven priority and work-type labels with Hermes.
  • Build and review an eight-issue Sprint 1 backlog.
Create the Sprint 1 milestone

A milestone groups related issues and shows their completion as the sprint progresses. GitHub needs this container before Hermes can attach issues to it.

  • Open the TaskFlow repository in GitHub.
  • Click Issues under the repository name.
  • Click Milestones next to the search field.
  • Click New Milestone.
  • Enter Sprint 1 in the Title field.
  • Paste the following sprint definition into the Description field:
Track the TaskFlow MVP backlog selected for the first sprint. Every issue should include acceptance criteria, an owner, one priority label, and one type label.
  • Leave the Due date field blank for this project.
  • Click Create milestone.

You should see an open Sprint 1 milestone at 0% completion. The milestone page URL ends with its number.

Record the number at the end of the milestone page URL: SPRINT_MILESTONE_NUMBER.

Why create the milestone by hand?

The official GitHub MCP Server can assign issues to an existing milestone, but its current documented tools do not create repository milestones. Creating Sprint 1 in the GitHub interface gives Hermes a real sprint container to populate.

This manual action also shows you where GitHub tracks sprint scope, open work, and completion. You will use the same page to review the backlog after Hermes creates it.

🙋‍♀️ Cannot find Milestones?

Confirm that you are viewing the TaskFlow repository and that GitHub Issues are enabled. If Milestones is missing, open Issues first and look beside the issue search field.

Help me find the milestone controls.

Create the sprint labels

Labels make the backlog scannable. Each issue gets one priority label and one work-type label, so the team can see urgency and ownership area at a glance.

  • Return to the terminal running Hermes inside ~/Desktop/taskflow.
  • Paste this request into Hermes:
Using the GitHub MCP connection for the current TaskFlow repository, create these labels if they do not already exist:

- priority-high, color B60205, for sprint-critical work.
- priority-medium, color D93F0B, for important work.
- priority-low, color FBCA04, for lower-risk work.
- type-frontend, color 1D76DB, for React interface work.
- type-backend, color 0E8A16, for FastAPI and PostgreSQL work.
- type-infrastructure, color 5319E7, for AWS and delivery work.
- type-ai, color C5DEF5, for AI-powered features.

First, inspect the existing labels and avoid duplicates. Use label_write for label creation. When finished, report whether each label was created or already existed.

Hermes may ask you to approve GitHub write operations. Review the repository name in each request before approving it.

  • Approve each label write for the TaskFlow repository.
  • Wait for Hermes to report all seven labels.
  • Open the repository's Issues page.
  • Click Labels.

You should see three priority labels and four work-type labels. There should be no duplicate names.

What did Hermes use?

label_write creates, updates, or deletes repository labels. The request uses only its create operation and checks the existing labels first.

🙋‍♀️ Labels missing or writes rejected?

Run /tools in Hermes and confirm that the GitHub MCP tools are loaded. If GitHub rejects a write, reconnect the server with a token that can manage repository issues.

Help me troubleshoot the label creation.

Create and review the sprint issues

The backlog should reflect the repository documents instead of a generic feature list. Hermes will read the requirements, architecture, and team roster before it chooses the eight issues.

  • Paste this backlog request into the same Hermes session:
Read PRODUCT-REQUIREMENTS.md, ARCHITECTURE.md, TEAM.md, and AGENTS.md from the current TaskFlow repository.

Create exactly eight GitHub issues for Sprint 1. Before creating them, inspect the existing open issues and avoid duplicates.

For every issue:
- Write a specific title and implementation summary.
- Add three or four testable acceptance criteria.
- Name one owner from TEAM.md in the issue body.
- Add a Dependencies section.
- Add an Estimate section.
- Apply exactly one priority label and one type label from the seven TaskFlow labels.
- Assign milestone number [[SPRINT_MILESTONE_NUMBER="your Sprint 1 milestone number"]].
- Do not set a GitHub assignee unless TEAM.md contains that person's real GitHub username.

Use issue_write to create each issue. When finished, return a numbered list with every issue number, title, owner, labels, and milestone.

Hermes may request one approval per issue. Check that each write targets TaskFlow, then approve it.

Before you open GitHub, do you think all eight issues will share one milestone while still covering different ownership areas?

  • Wait for Hermes to report eight issue numbers.
  • Open the TaskFlow repository in GitHub.
  • Click Issues.
  • Click Milestones.
  • Open Sprint 1.

You should see exactly eight open issues in Sprint 1. Each issue should show one priority label and one work-type label.

  • Open one issue from the milestone.
  • Confirm that the body contains acceptance criteria, an owner, dependencies, and an estimate.

How did Hermes build the backlog?

issue_write creates or updates one GitHub issue. It accepts labels and an existing milestone number as part of the issue data.

The team names in TEAM.md describe delivery ownership. They stay in the issue body unless the file also provides real GitHub usernames.

🙋‍♀️ Backlog count or metadata wrong?

Compare Hermes's final report with the Sprint 1 milestone. If an issue is missing metadata, ask Hermes to update that issue number instead of creating a replacement.

If fewer than eight issues exist, ask Hermes to list the current milestone issues before creating only the missing items.

Help me reconcile the sprint backlog.

TaskFlow now has an eight-issue sprint backlog with visible priorities, work types, and ownership. Next, you will make Hermes review that live backlog before it writes the sprint plan.

Generate the Sprint Plan and Review

Your GitHub milestone now holds eight real issues with priorities, work types, and named owners. Hermes can use that live backlog as the source for an execution plan.

The proof comes from the details. Both documents must cite real issue numbers and team members, then arrive in your local clone through a deliberate remote-to-local Git sync.

In this step, get ready to:
  • Create SPRINT-PLAN.md directly in the remote repository.
  • Create SPRINT-REPORT.md as a critical readiness review.
  • Audit the documents and pull both files into the local clone.
Generate the sprint plan remotely

A sprint plan turns the backlog into an execution sequence. It should identify what starts first, what depends on earlier work, and which risks need attention.

  • Return to the terminal running Hermes inside ~/Desktop/taskflow.
  • Paste this planning request into Hermes:
Use only GitHub MCP tools for this task. Do not create a local file.

Read milestone number [[SPRINT_MILESTONE_NUMBER="your Sprint 1 milestone number"]] and all eight associated issues from the current TaskFlow repository. Verify each issue number, title, labels, and owner before writing.

Create or update SPRINT-PLAN.md on the repository's default branch with create_or_update_file. Include:
- A sprint goal grounded in the live backlog.
- A table of all eight issues with number, title, owner, priority, type, and estimate.
- Ranked priorities with reasons.
- An execution sequence that references issue numbers.
- Dependencies and blockers between issues.
- Delivery risks with mitigations.
- A definition of done and expected sprint outcome.

Use only issue numbers that you verified on GitHub. Do not use placeholders. After writing the file, return its GitHub URL and commit SHA.

Hermes may ask you to approve the remote file write. Check that the destination is the TaskFlow repository before approving it.

This request may take a minute while Hermes reads all eight issues and writes the file. A quiet pause during those tool calls is expected.

  • Approve the create_or_update_file operation for SPRINT-PLAN.md.
  • Wait for Hermes to return a GitHub URL and commit SHA.
  • Open the returned GitHub URL.

You should see SPRINT-PLAN.md rendered on GitHub. Its issue table should contain eight real issue numbers from Sprint 1.

Remote repository versus local clone

The create_or_update_file operation writes through the MCP server to the remote GitHub repository. It does not change the files inside ~/Desktop/taskflow.

That separation is deliberate. You verify the remote result first, then use git pull to synchronize the local clone after both documents exist.

🙋‍♀️ File created in the wrong place?

If Hermes reports a local path instead of a GitHub URL and commit SHA, stop before continuing. Repeat the request with this instruction: use GitHub MCP create_or_update_file and do not use local filesystem tools.

If the tool is unavailable, run /tools and confirm that the GitHub MCP server is connected.

Help me correct the file destination.

Generate the sprint readiness report

The plan describes the intended work. The report challenges that plan by checking workload, dependencies, blockers, and missing scope before development starts.

Why review the plan separately?

A useful review makes a second pass over the same evidence with a different question: can this team deliver this plan safely? That separation helps Hermes expose overload or missing dependencies instead of defending its first answer.

  • Paste this review request into the same Hermes session:
Use only GitHub MCP tools for this task. Do not create a local file.

Read the live Sprint 1 milestone, all eight issues, TEAM.md, AGENTS.md, and SPRINT-PLAN.md from the current TaskFlow repository.

Act as the Engineering Manager conducting a sprint kickoff review. Create or update SPRINT-REPORT.md on the repository's default branch with create_or_update_file. Include:
- An executive summary and readiness rating.
- The sprint goal and current backlog coverage.
- A workload table with real team member names and issue numbers.
- Dependency and blocker analysis.
- Technical and delivery risks with likelihood, impact, and mitigation.
- Missing work or scope gaps.
- Recommendations before development begins.
- A final go, at-risk, or no-go recommendation with reasons.

Use only verified issue numbers and team names. Do not use placeholders. After writing the file, return its GitHub URL and commit SHA.
  • Approve the remote write for SPRINT-REPORT.md.
  • Wait for Hermes to return a GitHub URL and commit SHA.
  • Open the returned GitHub URL.

You should see SPRINT-REPORT.md beside SPRINT-PLAN.md in the repository. The report should name real team members and cite the issues assigned to them.

Report missing evidence or judgment?

Confirm that Hermes returned a commit SHA rather than a local path. Open the repository's commit history and check that the latest commit adds or updates SPRINT-REPORT.md.

If the report repeats the plan without evaluating it, ask Hermes to revise the file with explicit workload conflicts, blockers, and a go or no-go decision.

Help me strengthen the sprint review.

Audit the evidence and sync locally

The final check proves that Hermes used live repository state. A real issue reference should open the matching issue instead of pointing to a placeholder or unrelated item.

Before you test a reference, do you think the linked issue will match the title and metadata quoted in the document?

  • Open SPRINT-PLAN.md on GitHub.
  • Click one issue-number reference in the execution sequence.
  • Confirm that the issue title matches the plan.
  • Confirm that the issue has exactly one priority label.
  • Confirm that the issue has exactly one work-type label.
  • Return to SPRINT-REPORT.md.
  • Compare one team member's issue numbers with the live milestone.

The issue link should open the same work item described in the document. That match proves the planning artifacts use live backlog data.

Issue references do not match?

Ask Hermes to list all eight live milestone issues before revising either document. Then instruct it to replace every incorrect reference with a verified issue number.

Help me repair the cross-references.

Both planning documents currently live in the remote repository. Pulling now brings those committed files into the local taskflow folder without creating a second source of truth.

  • Exit Hermes by pressing Ctrl+C.
  • Check the local working tree by running:
git status

You should see that the working tree is clean. If Git lists local changes, use the troubleshooting guidance below before pulling.

  • Pull the two remote commits into the local clone by running:
git pull

You should see SPRINT-PLAN.md and SPRINT-REPORT.md listed in the pull output.

  • Confirm both files exist locally by running:
ls SPRINT-PLAN.md SPRINT-REPORT.md

You should see both filenames in the terminal. Your local clone and remote repository now contain the same planning artifacts.

Git pull blocked by local changes?

If git status shows modified tracked files, save them with a commit or stash them before running git pull.

If Hermes created either sprint file locally by mistake, move that untracked file outside taskflow before pulling. This prevents the local copy from blocking the committed remote file.

Help me resolve the local sync safely.

You completed the full Engineering Manager loop: persistent context, a structured backlog, evidence-based planning, critical review, and a synchronized repository. Hermes now manages TaskFlow from live project state instead of generic conversation memory.

Secret mission

Announce Sprint 1 in Slack

Connect Hermes to Slack through MCP and post a Sprint 1 kickoff announcement grounded in the live backlog. You will verify the team sees the goal, owners, dependency, and readiness decision without exposing the bot token.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources, pause your work, or delete everything created for this project. The main path has no idle resource charges, while paid OpenRouter or Anthropic usage only accrues when you send model requests.

Resources you used:

  • GitHub repository (taskflow) with its issues, labels, milestone, and sprint documents.
  • Local clone of the taskflow repository on your computer.
  • Fine-grained GitHub Personal Access Token named Hermes MCP.
  • GitHub MCP server entry named github in ~/.hermes/config.yaml.
  • Optional Secret Mission: Slack MCP server entry named slack in ~/.hermes/config.yaml.
  • Optional Secret Mission: Hermes MCP Slack app installation in your workspace.
  • Optional Secret Mission: Slack workspace, only if you created it exclusively for this project.
  • Optional paid fallback: Anthropic Console API key and its local ANTHROPIC_API_KEY setting in ~/.hermes/.env.

Keep everything running

No action is needed. Choose this if you are still using Hermes as an Engineering Manager or want to revisit the sprint later.

  • Keep the GitHub repository and local clone available for future sprint work.
  • Keep the fine-grained GitHub token only while Hermes still needs GitHub access.
  • Keep the optional Slack resources only if you completed the Secret Mission and still use them.
  • Keep the optional Anthropic key only if you still use the paid fallback.

Pause - I'll come back to this later

No project server or cloud resource incurs an idle compute charge, so there is nothing to stop. Pausing means leaving the files in place without sending model requests.

  • Close any active Hermes sessions.
  • Leave the GitHub repository and local clone unchanged.
  • Remember that retained GitHub, Slack, and Anthropic credentials remain active until you revoke them.
  • Restart Hermes from the taskflow folder when you return.

Delete - I don't want to use this again

Remove only the resources you created for this project. Complete each matching cleanup group and skip every optional group you did not use.

Deletion is permanent

Deletion removes project data or access credentials. Check each resource name before you confirm it.

Back up anything you want to keep. Never delete an existing Slack workspace that you use outside this project.

Delete the GitHub repository

Check the repository first

Deleting taskflow removes its issues, milestone, labels, and sprint documents. GitHub warns that repository deletion removes team permissions and cannot be undone.

Review GitHub's official repository deletion guide.

  • Open the taskflow repository on GitHub.
  • Click Settings below the repository name.
  • Scroll to Danger Zone on the General settings page.
  • Click Delete this repository.
  • Click I want to delete this repository.
  • Click I have read and understand these effects after reviewing the warnings.
  • Enter taskflow in the confirmation field.
  • Click Delete this repository.
Verify the repository deletion
  • Refresh the repository page.

You should no longer see the repository contents. This confirms GitHub removed taskflow.

Remove the MCP entries

Keep unrelated MCP servers

Your Hermes configuration can contain live credentials. Remove only the complete github block and the optional slack block.

Keep every unrelated server under mcp_servers. Do not share or screenshot the configuration file.

macOS

  • Open ~/.hermes/config.yaml in your configured editor by running this command:
hermes config edit
  • Find the mcp_servers key.
  • Delete the complete github block, including its command, args, and env lines.
  • Delete the complete slack block if you completed the Secret Mission.
  • Delete the mcp_servers key only if it has no server entries left.
  • Save config.yaml.
  • Start the Hermes TUI by running this command:
hermes --tui
  • Reload the configured MCP servers by entering this command inside the Hermes TUI:
/reload-mcp
  • Ask Hermes to list its remaining MCP tools by entering:
List all MCP tools you have available

You should see no tools prefixed with mcp__github__ or mcp__slack__. This confirms both project entries are gone.

Windows

  • Open %USERPROFILE%\.hermes\config.yaml in your configured editor by running this command:
hermes config edit
  • Find the mcp_servers key.
  • Delete the complete github block, including its command, args, and env lines.
  • Delete the complete slack block if you completed the Secret Mission.
  • Delete the mcp_servers key only if it has no server entries left.
  • Save config.yaml.
  • Start an interactive Hermes session by running this command:
hermes chat
  • Reload the configured MCP servers by entering this command inside Hermes:
/reload-mcp
  • Ask Hermes to list its remaining MCP tools by entering:
List all MCP tools you have available

You should see no tools prefixed with mcp__github__ or mcp__slack__. This confirms both project entries are gone.

Linux

  • Open ~/.hermes/config.yaml in your configured editor by running this command:
hermes config edit
  • Find the mcp_servers key.
  • Delete the complete github block, including its command, args, and env lines.
  • Delete the complete slack block if you completed the Secret Mission.
  • Delete the mcp_servers key only if it has no server entries left.
  • Save config.yaml.
  • Start an interactive Hermes session by running this command:
hermes chat
  • Reload the configured MCP servers by entering this command inside Hermes:
/reload-mcp
  • Ask Hermes to list its remaining MCP tools by entering:
List all MCP tools you have available

You should see no tools prefixed with mcp__github__ or mcp__slack__. This confirms both project entries are gone.

Delete the GitHub token

Check where the token is used

Deleting the token immediately removes the access it grants. Finish the repository deletion first, and keep the token if another project still depends on it.

Review GitHub's official token deletion guide.

  • Click your profile picture on GitHub.
  • Click Settings.
  • Click Developer settings in the left sidebar.
  • Click Fine-grained tokens under Personal access tokens.
  • Click Delete beside the Hermes MCP token.
  • Confirm the deletion if GitHub requests confirmation.

Refresh the fine-grained token list. You should no longer see Hermes MCP.

Delete the optional Anthropic key

Deleting the key revokes access

Skip this group if you used OpenRouter throughout the project. Deleting an Anthropic API key revokes its access immediately.

Remove both the local Hermes setting and the key in Anthropic Console. Do not share or screenshot ~/.hermes/.env because it can contain other credentials.

macOS

  • Remove the local ANTHROPIC_API_KEY setting from ~/.hermes/.env by running:
hermes config unset ANTHROPIC_API_KEY

Windows

  • Remove the local ANTHROPIC_API_KEY setting from %USERPROFILE%\.hermes\.env by running:
hermes config unset ANTHROPIC_API_KEY

Linux

  • Remove the local ANTHROPIC_API_KEY setting from ~/.hermes/.env by running:
hermes config unset ANTHROPIC_API_KEY
  • Open the Anthropic API Keys page.
  • Click the three-dot menu beside the project key.
  • Click Delete API Key.
  • Confirm the deletion.
  • Refresh the API Keys page.

You should no longer see the project key in Anthropic Console. This confirms the remote credential is revoked.

Remove the optional Slack app

Remove the installation you created

Skip this group if you did not complete the Secret Mission. Removing the app revokes its workspace installation and stops the Slack MCP connection.

Review Slack's official app removal guide.

  • Click your workspace name in the Slack desktop sidebar.
  • Select Tools & settings.
  • Click Manage apps.
  • Select Installed Apps in the Slack Marketplace sidebar.
  • Select the Hermes MCP app.
  • Click App Details.
  • Click the Configuration tab.
  • Click Remove App in the Remove App section.
Verify the app removal
  • Return to Installed Apps.
  • Search for Hermes MCP.

You should no longer see the app in the installed list. This confirms it cannot access the workspace.

Delete the optional Slack workspace

Workspace deletion cannot be reversed

Delete the workspace only if you created it exclusively for this project and you are its Primary Owner. Keep an existing personal, school, or work workspace.

Slack permanently removes the workspace's messages and files. Export anything you need before continuing.

Review Slack's official workspace deletion guide.

  • Click Admin in the Slack desktop sidebar.
  • Select Workspace settings.
  • Scroll to Delete Workspace.
  • Click Delete Workspace.
  • Select the confirmation checkbox.
  • Enter your Slack account password.
  • Click Yes, delete my workspace.

Open the former workspace URL. You should no longer reach the workspace.

Delete the local clone

Check the local folder

The next command permanently removes the local repository and every unpushed file inside it. Confirm that taskflow is the folder you intend to delete before running the removal command.

macOS

  • Review the contents of the target folder by running:
ls "$HOME/Desktop/taskflow"
  • Delete the confirmed taskflow folder by running:
rm -rf "$HOME/Desktop/taskflow"
  • Verify that the folder is gone by running:
test ! -d "$HOME/Desktop/taskflow" && echo "taskflow deleted"

You should see taskflow deleted.

Windows

  • Review the contents of the target folder by running:
Get-ChildItem -LiteralPath "$HOME\Desktop\taskflow"
  • Preview the deletion without changing files by running:
Remove-Item -LiteralPath "$HOME\Desktop\taskflow" -Recurse -Force -WhatIf
  • Delete the confirmed taskflow folder by running:
Remove-Item -LiteralPath "$HOME\Desktop\taskflow" -Recurse -Force
  • Verify that the folder is gone by running:
Test-Path -LiteralPath "$HOME\Desktop\taskflow"

You should see False.

Linux

  • Review the contents of the target folder by running:
ls "$HOME/Desktop/taskflow"
  • Delete the confirmed taskflow folder by running:
rm -rf "$HOME/Desktop/taskflow"
  • Verify that the folder is gone by running:
test ! -d "$HOME/Desktop/taskflow" && echo "taskflow deleted"

You should see taskflow deleted.

That's a Wrap!

That's a Wrap!

You made it. Hermes now works as TaskFlow's AI Engineering Manager, with a structured backlog, an evidence-based sprint plan, and a readiness review grounded in live GitHub data.

You've learned how to:

  • Create a persistent agent identity with AGENTS.md so Hermes keeps its TaskFlow role and operating rules between sessions.
  • Use the GitHub MCP Server to create repository files, labels, and issues through natural-language requests. You also created the Sprint 1 milestone manually in GitHub before Hermes attached issues to it.
  • Generate and audit sprint planning artifacts that reference live issue numbers, team ownership, dependencies, and delivery risks.
  • Optionally connect Hermes to Slack and post a Sprint 1 kickoff announcement through MCP in the Secret Mission.

Ready to quiz yourself?