LGTM is an open-source (MIT) orchestration framework for Claude Code that converts a high-level idea into structured issues, dispatches AI agents in parallel with each one working in its own git worktree, and routes every change through a GitHub pull request that a human reviews and merges. It ships with 7 agent definitions, 16 skills, 8 Python scripts, and 3 rule sets. The code is at github.com/syedsaif666/LGTM.
The tagline is the whole pitch: from "build me this" to a PR you'd actually approve. If vibe coding makes accountability invisible, LGTM is the counterweight: a structured way to work with AI where every decision stays traceable.
What is LGTM?
LGTM is a system for running multiple Claude Code agents against one codebase without losing control of it. You describe what you want, an orchestrator decomposes it into a plan of small, well-specified issues, and agents execute those issues in parallel. Nothing lands in your codebase except through a pull request you personally review.
The core philosophy fits in four lines:
- Ideas become PRs. Plans decompose into issues; each issue maps to one branch and one PR.
- Git is the documentation. Commit messages explain why, diffs show what, PRs link to the issues they solve.
- Big problems are small problems in disguise. Complex work becomes a graph of well-defined, reviewable tasks.
- Control the chaos. Work isolation stops bad output from poisoning the rest of the project.
I built it because I kept hitting the same wall, which I'll get to in a moment. First, some disambiguation, because the name collides with half the industry.
What LGTM is not
LGTM is not the Grafana LGTM stack (Loki, Grafana, Tempo, Mimir; that's observability). It is not lgtm-ai, the AI code-review GitHub Action. It is not the retired Semmle LGTM.com analysis platform. Those tools sit on the review side of the table: an AI judging code that already exists. My LGTM sits on the other side. Its agents produce pull requests, and the only reviewer in the system is you. The name is the point: the goal of every dispatch is a PR where your honest reaction is "looks good to me."
The problem with vibe coding: accountability disappears
Vibe coding is describing what you want, accepting whatever the agent produces, and judging the result by whether it seems to work. Everyone does it now, and I don't just mean beginners. Engineers vibe too. It's a perfectly good way to prototype and a terrible way to build anything you have to live with, because it makes accountability invisible. Changes pile up that nobody scoped, nobody reviewed, and nobody can explain.
The bane of vibe coding arrives the day you get stuck. Something is broken, and no amount of prompting will fix it, because neither you nor the model can say which change introduced the problem or why that change was made. The project's history is a smear. There's nothing to bisect, nothing to roll back to, no reasoning to re-read.
LGTM's answer is to make every decision atomic. One issue, one branch, one PR: each change enters the codebase as a scoped, reviewed, traceable unit. When something breaks, you hone in on exactly what changed and where (the issue spec that asked for it, the PR that delivered it, the commit that explains it) instead of prompting in circles.
And the documentation for all of it is your GitHub. Every commit message records why the change was made; the what you can decipher from the code itself. Six months later, the reasoning is still attached to the exact lines it justified. That's also why this isn't an experts-only tool: the structure is enforced by the system, not by the discipline of the person using it. Anyone working with AI gets the traceability for free.
Why orchestrate Claude Code agents at all?
A single Claude Code session stops scaling the moment your task has more than one independent part. One context window, one branch, one thread of work: the agent finishes step one, you review, it moves to step two, and you spend the afternoon as a serial bottleneck for work that has no reason to be serial.
That was my wall. I was shipping real projects with Claude Code and the sessions themselves were fine. The problem was everything around them: three tasks that could run at once but didn't, half-finished work tangled together on one branch, and no clean way to throw away one bad result without unpicking it from two good ones.
Orchestration is the fix, but orchestration without governance just multiplies the mess. Five agents finishing at once is worse than one, unless each result arrives isolated, reviewable, and rejectable on its own. That constraint shaped every design decision that follows.
How LGTM breaks an idea into issues
Before any agent writes code, the work gets decomposed. You describe requirements to the orchestrator agent; it produces a plan with milestones and a dependency graph. An Issue Writer agent then turns each unit of work into a self-contained spec file with acceptance criteria and test cases, grounded in the actual codebase.
The hierarchy: Initiative → Project → Milestone → Issue
LGTM organizes work in a three-tier hierarchy under the repo:
Initiative (the repo)
└── Project (plan file + base branch + milestone)
└── Milestone (section in plan)
└── Issue (spec file + branch + PR)The issue is the atomic unit. Every issue gets an ID like P2M1-003 (project 2, milestone 1, issue 3), and that ID follows the work everywhere: it names the spec file, it prefixes the PR title, it labels the worktree. When a PR called P2M1-003: Add rate limiting middleware shows up, you can trace it back to its spec without any extra tooling.
Why filesystem specs instead of GitHub Issues
LGTM stores issue specs as files in the repo instead of GitHub Issues, because agents read the filesystem faster than an API, specs version with the code they describe, and a cold-start agent needs no auth or network access to load its entire contract. GitHub Issues are built for humans discussing work. Spec files are built for agents executing it: structured frontmatter, machine-readable formatting, and acceptance criteria in a predictable place.
How to run multiple Claude Code agents in parallel without conflicts
The short answer: give every agent its own git worktree. A worktree is a separate working directory attached to the same repository, checked out to its own branch. Agents never touch the same files on disk, never fight over the index, and share nothing except git history. Conflicts, when they exist, surface at merge time, where git's normal tooling handles them.
One worktree per agent
In LGTM, dispatching an issue means creating a worktree for it:
.claude/worktrees/
├── P2M1-001/ → branch: auth-oauth-setup
├── P2M1-002/ → branch: auth-callback-handler
└── P2M2-001/ → branch: auth-rate-limitingPlenty of guides cover worktrees as a parallelism trick for Claude Code. In LGTM they're something stricter: a fault-isolation policy. An agent that goes sideways can be killed and its worktree deleted, and the blast radius is exactly one issue. Nothing it did can leak into a sibling's working directory, because it physically can't reach one.
The git model
Branching follows one shape, always:
master
└── develop
└── {project}-base
├── {project}-feature-a # one issue
├── {project}-feature-b # one issue
└── {project}-feature-c # one issueIssue PRs target the project's base branch. When every milestone in a project completes, a single project PR rolls the base branch into develop. Nothing merges locally; every change reaches a base branch through its own PR.
One PR per issue: the fault-isolation boundary
Every issue becomes exactly one pull request, because the PR is where fault isolation pays off. A bad PR gets rejected or sent back for rework, and the damage is contained: it blocks only the issues that depend on it, never the whole project. Good sibling PRs merge on their own schedule.
This is also what keeps AI-generated code reviewable. A PR scoped to one small, well-specified issue is a diff a human can actually hold in their head. The alternative (one sprawling branch where an agent did nine things) is how you end up rubber-stamping code you didn't really read.
The trust model in one paragraph
You review every PR on GitHub, and merging is how code lands. That's the entire trust model. No auto-merge, no agent approving another agent's work, no confidence scores standing in for judgment. Agents propose; the human disposes. Every guide I found on multi-agent coding covered how to run the agents and went quiet on what happens when five of them finish and someone has to decide what to trust. LGTM's answer is deliberately boring: the same PR review you already do, at a size you can actually do it.
Cold-start agents: no conversation history, on purpose
LGTM agents never read conversation history. The orchestrator hands each agent a self-contained prompt: the issue spec, the file paths, the constraints, and nothing else. No shared memory, no accumulated chat state.
Most writing about subagents treats context isolation as a limitation to engineer around. I think it's a feature worth designing for. A cold-start agent is restartable: kill it mid-task and dispatch a fresh one, and the spec is still the entire contract. It's replaceable: any agent (or a newer model) can pick up any issue. And it's debuggable, because when an agent produces something strange, the cause is in one readable spec file, not somewhere in twenty thousand tokens of chat drift. Shared state is where multi-agent systems go to die; the spec file is the only interface, so it's the only thing that has to be right.
Design decisions I'd defend
A few decisions in LGTM look odd until you've run agents in anger. Each earned its place.
Real timestamps via a script, because LLMs hallucinate dates
Every LGTM agent gets timestamps by running python scripts/now.py instead of writing dates from memory, because language models confidently produce wrong dates. A model's sense of "today" comes from training data and context clues, not a clock. The first time I saw a neatly formatted log entry dated months into the past, dated logs became untrustworthy logs, and an untrustworthy log is worse than none. One trivial script ends the whole problem class: if a date appears in an artifact, a real clock produced it.
No AI attribution in commits
LGTM strips AI attribution from commits (no Co-Authored-By trailers, no "generated with" footers) because attribution adds noise without accountability. It also litters GitHub history with "Unverified" badges. The commit message's job is to explain why the change exists. Authorship, in the sense that matters, belongs to whoever reviewed and merged it. That's you.
Worktrees over branches, one PR per issue, specs over Issues
The rest of the load-bearing decisions appear above, but they compress to one sentence each. Worktrees over branches, because branch-switching in a shared directory means agents stepping on each other's uncommitted state. One PR per issue, because fault isolation beats batch efficiency the first time an agent produces garbage. Filesystem specs over GitHub Issues, because agents execute contracts, and contracts should version with the code.
Beyond code: a system for building systems
Nothing in LGTM's model is actually about code. Decompose a goal into a hierarchy, write each unit as a self-contained spec, dispatch agents against the specs, review every result before it lands: that loop runs anything that decomposes. I've applied the same mental model to content pipelines, translation workflows, and SEO audits, with the same payoff: atomic, reviewable units instead of one long vibe.
That's the ambition underneath the framework. LGTM is in its infancy, but what it's growing toward is a system for creating arbitrary systems: a repeatable, systematic way to take any problem, break it into accountable pieces, and put a human judgment gate in front of every piece that ships. Coding is where it started, because git and pull requests supply the review infrastructure for free. It isn't where it ends.
Limitations and roadmap
LGTM is built for Claude Code today, and I won't pretend otherwise. The agent definitions, skills, and dispatch mechanics assume Claude Code's runtime.
The architecture underneath is deliberately agent-agnostic, though: the hierarchy model, issue specs, workspace structure, git conventions, and orchestration patterns contain nothing Claude-specific. Native support for other coding agents is in development. There's also honest overhead to acknowledge: decomposing an idea into specs costs time up front, and for a one-file fix, a plain Claude Code session is still the right tool. LGTM starts paying for itself when the work has enough independent parts to parallelize.
FAQ
What is LGTM?
LGTM is an open-source (MIT) orchestration framework for Claude Code that turns high-level ideas into structured issues, runs AI agents in parallel in isolated git worktrees, and delivers every change as a GitHub pull request a human reviews and merges.
Is LGTM a code review tool?
No. Unlike lgtm-ai or PR review bots, LGTM's agents produce pull requests; the human is the only reviewer. It sits upstream of review tools, not among them.
How is LGTM different from vibe coding?
Vibe coding accepts whatever the AI produces and judges it by whether it seems to work, so accountability disappears. LGTM structures the same AI work into atomic issues, branches, and human-reviewed PRs, so every change is scoped, explained, and traceable when something breaks.
How does LGTM prevent parallel agents from conflicting?
Each issue gets its own git worktree, branch, and PR. Agents share only git history; conflicts surface at merge time, where standard git tooling handles them.
Why one PR per issue?
Fault isolation: a bad PR is rejected or reworked without contaminating sibling work, and the issue ID in the PR title (for example, P2M1-003) gives traceability for free.
Why do LGTM agents start with no conversation history?
Cold-start agents are restartable and replaceable; a self-contained issue spec is the entire contract, so any agent, or a fresh retry, can pick up any issue.
Is LGTM only for coding?
No. The workflow (decompose a goal into self-contained specs, dispatch agents in parallel, review every result) applies to any problem that decomposes, including content pipelines, translation workflows, and SEO audits. Code is where it started because git and pull requests supply the review infrastructure for free.
Does LGTM work with agents other than Claude Code?
Currently it is Claude Code-specific. The architecture (hierarchy, specs, git conventions, orchestration patterns) is agent-agnostic, and support for other coding agents is on the roadmap.
Why does LGTM use a script for timestamps?
LLMs hallucinate dates. A Python script supplies real timestamps so logs and artifacts are trustworthy.
Try it
The repo is github.com/syedsaif666/LGTM: copy the source files into your project, run the sync script, run /onboard to fill in project-specific config, and tell the orchestrator what to build. PRs start arriving as agents finish.
If you want to see what I'm applying the same generate-then-review philosophy to outside of code, I'm building Latent, an AI social post generator with a human review lane.