At Sourcelabs, we spend a lot of time turning well-defined GitHub issues into pull requests. It’s satisfying work — but it’s also repetitive. Write a ticket, plan the implementation, scaffold the code, run the tests, open the PR. Repeat. So we asked ourselves: what if Claude Code could do all of that for us?
The result is github-claudomator, an automated pipeline that picks up tickets from a GitHub Project board, plans and implements them using Claude Code, and delivers ready-to-review pull requests — all controlled through a simple web dashboard.
The Problem With Manual Ticket Grooming
Before we built this, our workflow looked like most teams’: a developer would grab a ticket from the “Ready” column, spend time understanding the context, write some code, and open a PR. Nothing wrong with that. But for well-scoped tickets — small features, bug fixes, refactors — the mechanical overhead adds up fast.
We wanted a way to automate the boilerplate while keeping humans firmly in the loop for the decisions that matter.
How the Pipeline Works
The system revolves around six stages, each handled by a dedicated shell script and orchestrated through a Next.js dashboard.
Scan — The pipeline starts by fetching all issues sitting in the “Ready” column of a GitHub Project board using the GitHub GraphQL API and the gh CLI.
Assess — Claude Code reads each ticket and evaluates whether it contains enough context to move forward. If a ticket is vague or missing key details, the system automatically posts a clarifying question as a GitHub issue comment and marks the ticket as needs_clarification. Nothing proceeds until the ticket is ready.
Plan — Once a ticket passes assessment, Claude Code spins up an isolated git worktree and creates a full set of OpenSpec artifacts: a proposal, a design document, a technical spec, and a breakdown of concrete tasks. These artifacts get committed and a draft PR is opened so the team can see exactly what Claude intends to build.
Review — A human looks at the draft PR on the dashboard. The dashboard streams real-time logs and shows the current state of every ticket. You can approve the plan or reject it with one click.
Implement — On approval, Claude Code works through the task list: writes the code, runs the test suite, runs the linters, and marks the PR as ready for review.
Verify & Archive — After implementation, the pipeline runs a verification pass. If something is off, it gets up to two automatic fix attempts. Once everything passes, the OpenSpec artifacts are archived and the ticket lifecycle is complete.
Each ticket runs in its own git worktree, so multiple tickets can be in-flight simultaneously without stepping on each other.
The Tech Stack
The dashboard is a Next.js app that acts as the control plane. It exposes API routes for each pipeline action — scan, start, approve, reject — and uses SQLite (via src/lib/db.ts) to track ticket states across the full lifecycle. GitHub integration is handled through a combination of the GraphQL API and the gh CLI.
The pipeline scripts themselves are bash, wrapping claude -p invocations through a central claude-stream.sh helper that handles log streaming and enforces sandboxing.
Speaking of sandboxing: because the pipeline runs Claude Code in headless mode with --dangerously-skip-permissions (required so it doesn’t hang waiting for interactive prompts), sandboxing is mandatory. The project uses OS-level isolation — Seatbelt on macOS, bubblewrap on Linux — configured through Claude Code’s settings.json. Without it, you’d be giving an AI model unrestricted access to your filesystem and network, which is obviously not something you want.
It’s very cool.
Ticket States at a Glance
A ticket moves through the following states:
queued → planning → plan_ready → approved → implementing → pr_created
At any point it can branch into needs_clarification or blocked, with the system posting comments directly on the GitHub issue to keep everyone informed.
Getting Started
The setup is intentionally minimal. You need Node.js 18+, the Claude Code CLI, the GitHub CLI authenticated against your repo and project, and jq. From there it’s three steps: install dashboard dependencies, point config.yaml at your repo and project board, and run ./start.sh.
1target:
2 repo: "owner/repo-name"
3 project_number: 4
4 columns:
5 ready: "Ready"
6 in_progress: "In progress"
7dashboard:
8 port: 3000
The dashboard is available at http://localhost:3000. Hit Scan, click Start on a ticket, review the plan, approve it, and watch the PR appear.
What This Changes
The most important design decision in github-claudomator is the human review gate between planning and implementation. Claude Code doesn’t write a single line of production code without a human signing off on the plan first. This keeps the system from going off in the wrong direction on ambiguous tickets, and it means the team stays in control of what actually lands in the codebase.
For well-specified tickets — the kind that already have a clear acceptance criterion and a defined scope — the turnaround time shrinks dramatically. The plan appears as a draft PR within minutes. Implementation follows shortly after approval. What used to take a developer an hour of context-switching now happens in the background while they focus on the work that actually needs human creativity.
It’s not about replacing developers. It’s about giving them back the time they were spending on the parts of software development that didn’t need them.
The repo is at github.com/sourcelabs-nl/github-claudomator .