code-navigator

Gobby
Start with a task. Walk away. End with a PR.

---

gobby build '#1842'

That's the loop. Hand Gobby a task, walk away, come back to a PR.

Behind that one command: a plan, an expansion into staged subtasks, isolated worktrees, dispatched agents, hook-time guardrails, validation, review gates, and a commit-linked close. If something goes off the rails, Gobby stops and escalates instead of merging garbage.

Gobby built Gobby. 5K+ commits. 15K+ tasks across my projects. Two paying clients running production systems on it. The 0.4.x line was assembled through Gobby's own task, dispatch, review, and documentation flows — the receipts live in this repo's .gobby/tasks.jsonl.

---

Why this exists

The bottleneck in AI coding stopped being model capability a long time ago. The bottleneck is babysitting. Agents lose context across compactions. They drift from the rules you wrote in your CLAUDE.md. They duplicate work. They burn thousands of tokens reloading the same MCP schemas every turn. You still review every diff because you can't actually trust what comes back.

The fix isn't a better prompt. The fix is infrastructure around the agent.

Gobby is a local daemon that sits underneath the AI coding CLIs you already use — Claude Code, Codex, Gemini CLI, Qwen CLI, Factory Droid — and gives them what they're missing: shared sessions, a durable task ledger, hook-time rules, progressive MCP discovery, agent isolation, review gates, and a build loop that turns a task into a PR without you in the middle.

It is not another agent. It is the control plane the agents you already have are missing.

---

What Gobby is

A Python 3.13+ daemon you run locally. PostgreSQL is the runtime hub database, configured from bootstrap database_url settings. HTTP and the installed web UI run on :60887, WebSocket on :60888, dev web UI on :60889, with a stdio MCP server that your coding CLIs talk to.

Three things make Gobby load-bearing:

1. Stage-manifest dispatch + hook-time rules

Most autonomous agents are one giant prompt loop where the model decides everything. That's the failure mode you've already lived through.

Gobby splits the runtime in two. Dispatch is deterministic: a heartbeat scans tasks, reads the current stage manifest row (ideation → research → architecture → prd → planning → expansion → development → holistic_qa → pr → merge), evaluates ordered rules in src/gobby/dispatch/rules.py, acquires a per-task mutex, and executes one bounded action — start a stage, spawn an agent, create isolation, advance, escalate. No prompting, no model freelancing.

Inside a spawned worker, the agent gets full autonomy to plan, edit, verify, and commit. But every tool call passes through the rule engine on turn_start, before_tool, after_tool, and turn_end. Rules can block, rewrite, inject context, or set variables synchronously. They are evaluated as code, not hoped for in a prompt.

Agent freedom inside enforced boundaries. That's the only way gobby build gets to "hands-off" without lying about it.

2. Local-first, built with itself

Your database, transcripts, hooks, task ledger, workflows, and rules stay on your machine. No cloud control plane. No SaaS dependency. Apache 2.0.

The repo you're reading was built through its own build loop. 5K+ commits. 15K+ tasks. 0.4.x was assembled by spawned agents working through staged manifests, with the dispatcher routing review and merge. That's the production test bed: every regression in dispatch, hooks, isolation, or task lifecycle shows up as a stalled build the next morning.

I've also used it to ship production systems for two paying clients. It is the tool I needed to actually trust the output of an AI coding agent on real work.

3. Sits under your CLIs, not next to them