dev-hub: Mission Control for Claude Across My Repos

I have a handful of research and side-project repos that all need the same kind of upkeep: tests that were never written, dated packaging, automated checks (continuous integration, or CI) that don’t exist, outdated READMEs. None of it is hard, but it never makes it to the top of the list; a lot of development stops once things work, as in plenty of research codebases.

This is why I built dev-hub, a small private GitHub repo that acts as mission control for Claude to operate and work on small tasks across GitHub repos.

dev-hub holds no code. It holds a task board listing a set of tasks for every repo I track, a playbook of rules every Claude session follows to complete tasks and integrate changes into the GitHub repos, and a record of what each task did. I name a task, Claude works it on a branch, and I get back a pull request to review. My own dev-hub is private, but there’s a generic copy, dev-hub-template (MIT), that you can fill in with your own repos.

The first half of this post gets you started and covers the key pieces. Everything under Going further is optional reading and dives deeper into how dev-hub works.

Try it

Getting started takes four steps:

1. Create a private repo from dev-hub-template. It holds your plans and tasks, so keeping it private is a good idea, though not necessary.
2. Open it in Claude Code, or in claude.ai/code with the repo attached, and run add-repo <owner>/<repo> for each project you want tracked.
   • Using claude.ai/code or a Claude Project? Connect GitHub in claude.ai (Settings → Connectors) and install the Claude GitHub App on GitHub. Installing it on all your repos is easiest, but you can select only the ones you add to dev-hub.
3. Run refresh-overview, then scan-repo <name> to get a first task table for that repo.
4. Pick a small (S) task and run run-task <ID>: Claude plans it and carries on. Or run plan-task <ID> to agree on a plan with Claude first.

A first session with one of my repos looked like this:

add-repo kylermurphy/gmag   # track the repo; it gets the prefix GMAG-
scan-repo gmag              # Claude proposes GMAG-1 … GMAG-5; I merge the board PR
plan-task GMAG-1            # Claude proposes a plan and waits for my go; then work starts
                            # Claude opens a gmag PR; I review and merge it
mark-done GMAG-1            # mark it done on the task board, log finalized, learnings saved

The template’s examples/ folder walks through the same steps on an imaginary repo, from an empty board to a finished task.

How it works

GitHub is the hub

Claude can work on code in a few places: Claude Code on my machine, Claude Code on the web or app (good for running from a mobile device), or a claude.ai Project (good if you don’t have access to Claude Code). These can’t see each other, and a chat’s context is gone once it ends. GitHub is the one thing they can all reach, so all state lives there. Any session can pick up any task from its board row and log alone.

flowchart TD
  surf["<b>any surface</b><br/>Claude Code on the web,<br/>in the app or on my computer,<br/>or a claude.ai Project"]
  surf -->|"name a task"| todo
  todo["<b>dev-hub</b><br/>⏩ Todo: a row on TASK_BOARD.md"]
  todo -->|"plan-task<br/>plan in chat, wait for your go"| plan
  todo -->|"run-task<br/>Claude plans it (S/M)"| plan
  plan["<b>dev-hub</b><br/>🟠 WIP: plan saved to log/ID.md"] --> work
  work["<b>target repo</b><br/>branch task/ID-slug<br/>sync CLAUDE.md, do the work<br/>open a draft PR<br/><i>log kept current in dev-hub</i>"]
  work -->|"stops"| stop["<b>dev-hub</b><br/>‼️ Blocked: question in the log<br/>or 🛑 Usage-stopped"]
  stop -->|"pickup-task"| work
  work --> review["<b>target repo</b><br/>you review and merge the PR"]
  review -->|"mark-done"| done["<b>dev-hub</b><br/>🟢 Done: board and log updated,<br/>learnings saved to the repo's master"]
  classDef hub fill:#e8f0fb,stroke:#4a6fa5,color:#1b1b1b
  classDef repo fill:#fcefdc,stroke:#b8782f,color:#1b1b1b
  classDef surface fill:#f1f1f1,stroke:#777777,color:#1b1b1b
  class todo,plan,stop,done hub
  class work,review repo
  class surf surface

Each box says where the step happens: grey is wherever I’m working, blue is dev-hub (the board, the log and the repo’s instructions), and orange is the target repo (the branch and the PR). Both repos live on GitHub.

What’s in the repo

Everything is plain markdown:

Plan → Launch → Track → Land

Every task, and every feature, follows the same loop:

• Plan. scan-repo sets each task’s definition of done. plan-task then drafts a fuller plan with me and waits for my go; run-task has Claude plan a small task itself and carry on. Either way, the plan is saved to the log before any heavy work.
• Launch. Claude works the task on its own branch (task/<ID>-<slug>) in the target repo. It never commits to main. Naming a task ID on its own, like “do GMAG-2”, means run-task.
• Track. The first commit copies the repo’s master CLAUDE.md in from dev-hub. Every step after that is logged, so a stopped task can resume where it left off.

• Land. Claude opens a draft PR. I review and merge it, and mark-done closes the task on the board in the dev-hub repo.

  mark-done also saves anything the task learned (a build quirk, a gotcha) into the repo’s master CLAUDE.md. That’s dev-hub’s light version of a memory bank: the next task in that repo reads it before it starts. More in Memory.

The definition of done is written on the task’s board row before work starts, so “finished” is never a judgment call made at the end. A task’s status is one of ⏩ Todo, 🟠 WIP, ‼️ Blocked (waiting on a decision from me), 🛑 Usage-stopped (paused by usage limits) or 🟢 Done, and the board shows the icon with the word. Only mark-done sets Done, and only after checking that the PR merged.

The commands

Commands are just words typed into a Claude session. There are three groups.

Board maintenance keeps the boards current. Each run is a branch and a PR in dev-hub, with no task log.

Task lifecycle commands run the loop above, for tasks and features.

Projects work on the research layer above the boards (more on projects).

Put plan in front of any command (plan scan-repo gmag, plan GMAG-2) for a dry run. Claude does the read-only part and proposes the changes. Nothing is committed until I say “go”.

The task board

Here’s a trimmed copy of my live board, showing just the gmag and smurphs_cooking repos. Each Done task links to its merged PR so you can follow the trail.

Reading the board

• Tracked Repos is the input. It’s the only table I edit (through add-repo). Its Prefix column is where task IDs come from, and setting Tracking to paused shelves a repo.
• Repo overview is derived. refresh-overview regenerates it, so I never edit it. The State column is a quick health check: gmag has no tests and no CI, which is why GMAG-2 and GMAG-3 exist.
• Each task has a definition of done and an effort size. Effort (S / M / L) decides which model runs the task and whether it can run unattended.
• Status is the only column that changes as work happens, and only the commands change it.

TASK_LOG.md keeps a running index of every task that’s been started, newest first:

Where it runs

The workflow is documented for several surfaces, but I’ve only run real tasks through the first three. The claude.ai Project handback surface is particularly useful if you don’t have Claude Code. It provides Git-formatted commit patches and zips of the changed files, since a Project can’t push. The workflow is a bit more user intensive, but not by much. You can read more about it here.

Some Claude Code on the web sessions are branch-restricted: they can push to only one branch. There, dev-hub’s bookkeeping arrives as a dev-hub PR instead of landing on main, and Claude says so in chat. The task isn’t fully closed until that PR merges too.

Going further (optional)

That’s the core of dev-hub. The sections below cover what’s built on top of it, plus one task in detail. Two bigger additions have posts of their own: features for larger work on one branch, and projects for research plans above the boards.

A worked example: GMAG-1

Batches

multi-task COOK-2 COOK-3 COOK-5
multi-task smurphs_cooking      # Claude proposes a batch of the repo's small tasks

Overnight runs

Subagents

Memory

Other coding agents