Spec interview · Test first · Graded review · Quality gate
An approved issue becomes a review-ready PR.
With evidence against the acceptance criteria and a plain account of what remains uncertain. A Product Teammate turns a request into a spec, an Engineering Teammate implements it with tests and opens the PR, and a QA Teammate grades it 1 to 6 on a fixed rubric. Anything that falls short of the grade you set goes back to the engineer, with approve mode on only high-quality changes are approved, and your branch rules decide the merge. Greenlight is the name for that workflow; every setting of it lives on one dashboard page of the same name. Any codebase counts, a plain marketing website included. Start with a second review of the PRs you already have, before anything writes code.
Up and running today. Bring your repo.
No spec. No QA. PRs piling up.
AI coding tools start writing code the moment you hit enter — no requirements gathering, no acceptance criteria, no edge case analysis. Then nobody checks the output before it reaches your reviewers.
Code starts before the spec does
AI tools start generating code from a one-line prompt. No requirements gathering. No edge case analysis. No acceptance criteria. You get code that "works" but doesn't do what you actually needed.
Tool sprawl, zero integration
One tool generates code. Another reviews it. A third runs tests. None of them share context, and you're the glue holding it together.
AI code with no QA gate
AI-generated code lands in PRs and your senior engineers are the only safety net. Nobody writes tests. Nobody checks against the spec.
PR review is the bottleneck
PRs sit for days waiting for review. Your best engineers spend more time reviewing than building. Velocity drops while the backlog grows.
From backlog to merge — one multi-Teammate pipeline
The developer doesn't grade their own homework. Every pull request is graded by a separate reviewer before a human ever looks at it.
Spec Creation
Every feature starts with a conversation, not a cursor. The Product Teammate sits down with you and interviews you like a senior engineer would — one question at a time, probing edge cases, surfacing constraints you hadn't considered, cross-referencing failure patterns unique to your codebase. What comes out the other side is a complete spec: acceptance criteria, known risks, testing strategy, and clear boundaries on what's in scope and what isn't. By the time code starts, everyone — human and machine — agrees on what "done" looks like.
Spec Approved
You read the spec, tweak what needs tweaking, and approve it. The card moves to Ready in your project tracker. That's it — that's your last manual step before code starts flowing. Everything from here is automated.
Implementation, test first
The Engineer Teammate reads the approved spec, writes the test first and shows it failing for the stated reason, then writes the implementation following your conventions and architecture, and opens a pull request whose body carries the test output, the docs it checked and the questions only a human can answer.
Adversarial Code Review
A separate QA agent tears the PR apart. It reviews against the original spec, then cross-checks a library of failure patterns built from past review comments and fix PRs on your project — real bugs, real mistakes your engineer agent has made before. These aren't generic lint rules. They're your team's institutional knowledge, read before every review.
Graded 1 to 6
The reviewer scores correctness, verification, scope and risk from the facts in the diff, each with a file and line, and only then reads the PR description, which can lower the grade but never raise it. By default an approving grade also needs CI to show the new tests failing on the old code and passing on the new. Out of the box it comments only; turn approve mode on and it approves at grade 5 or 6, your choice.
Agent Review Loop
When QA finds issues, it sends them back to the engineer. The engineer fixes. QA reviews again. The engineer fixes again. Every push is graded again. No human needs to babysit this — the Teammates work through the findings between themselves.
Human Review
By the time your team opens the PR, it's already survived adversarial, graded review. You're reviewing clean, tested, spec-compliant code — not debugging someone else's first draft. And if you do request changes? The cycle restarts: fix, re-grade, agent loop. Same rigor, every iteration, until you're satisfied and hit merge. CI config, keys, certificates and secret files always need a person, whatever the grade.
Continuous Self-Improvement
Review comments and fix PRs are mined for new failure patterns — what the QA agent missed, what the human reviewer caught, what broke in ways nobody expected. Those patterns get folded into the file both the engineer and the reviewer read before their next pass. Over time, fewer mistakes make it to human review.
The Engineer Agent
A senior-level Engineering Teammate that interviews you on requirements, builds a complete spec, then writes code with tests, follows your conventions, and opens clean PRs — working alongside your team, not replacing them.
AI-assisted spec interview
Before writing a line of code, the Product Teammate interviews you — asking clarifying questions one at a time, checking edge cases, referencing known failure patterns from your codebase. The output is a complete spec with acceptance criteria, constraints, and testing notes.
Works from an approved issue
Takes an approved issue in your tracker from spec to pull request. Works from the full spec — not just a ticket title and a prayer.
Tests are part of every change
The test is written first and shown failing, then made to pass. Tests run on the Teammate's own server before the PR is opened, and the output goes in the PR body.
Follows your conventions
Reads your codebase, learns your patterns, follows your linting rules and architecture. Doesn't impose its own style.
Small, focused PRs
One concern per PR. Clear titles, context-rich descriptions. Uses git worktrees so parallel tasks never conflict.
Reports back
Lets the team know when work is done, what decisions were made, and why. No black-box surprises.
Grades 1 to 6 on a fixed rubric
Correctness, verification, scope and risk, each scored from the facts in the diff with a file and line. The grade comes from the facts, not from the PR description.
Reviews against the spec
Every PR is checked against the original issue requirements — not just code style or linting rules.
Knows your failure patterns
Maintains a library of past bugs specific to your codebase, so the same class of bug gets caught at review next time.
Verifies before posting
Traces code paths, checks surrounding context, confirms the issue is real. Signal, not noise.
Inline PR comments
Actionable findings on the exact line, with severity and fix suggestions. Findings are advisory; your branch rules decide what merges.
Protected paths go to a person
CI config, keys, certificates and secret files are never auto-approved, whatever the grade. Add your own paths.
The QA Agent
An adversarial QA Teammate that reviews every PR against the spec and known failure patterns and grades it 1 to 6 before a human ever looks at it. Every push is graded again.
info Out of the box the QA agent comments only. Turn approve mode on and it approves at the grade you set, on the exact commit it graded, and withdraws that approval when the next push falls short. Your branch rules always make the final call.
Every PR gets a grade, not just comments
Most AI review tools post opinions. Greenlight grades every pull request, whoever opened it, 1 to 6 on a fixed rubric computed from the facts in the diff, and approves only at the grade you set.
The diff is scored first
Correctness, verification, scope and risk, each scored 0 to 3 with a file and line or a fact behind it. The reviewer has not read the PR description yet.
Then the description is checked against it
Claims in the write-up are compared with the facts. They can lower the grade, never raise it, and text aimed at the reviewer caps the grade below approval.
Fails-first proof from your CI
By default an approving grade needs CI to show the new tests failing on the old code and passing on the new. Teams whose CI can't produce that use a CI-green floor instead.
Approve at 5 or 6, your choice
Out of the box the reviewer comments only. Turn approve mode on and it approves the exact commit it graded, re-grades every push, and withdraws when a push falls short. CI config, keys and secret files always go to a person.
Every setting has a default and a range. The grade to approve at, the verification floor, protected paths, size limits and per-repository overrides are edited on one dashboard page, the API or MCP tools, and nothing applies until you deploy. A PR can never change Greenlight's settings.
Whether you have a team or need one
CTOs & Engineering Leads
You have a dev team. You want to augment capacity without the headcount — and without sacrificing code quality.
- — PR reviews that take days, not minutes
- — Junior devs shipping without test coverage
- — AI-generated code with no QA process
- — Velocity lost to review bottlenecks
Add a senior engineer and dedicated QA reviewer — without the headcount.
Non-Technical Founders
You need dev capacity you don't have — and you're tired of outsourced work coming back wrong with no QA process.
- — Contractor work that doesn't match the spec
- — No tests, no reviews, flying blind
- — Bugs discovered by your users, not your process
- — No visibility into what's being built or why
A development team that follows best practices by default.
Works With Your Stack
Commits, PRs, and code reviews happen on GitHub. Each Teammate gets its own GitHub App identity with role-scoped permissions: the Engineer can push and open PRs, the reviewer can only review, and no profile can edit your CI configuration. CI runs wherever you run it.
update More VCS platforms coming soon. GitHub is where commits and reviews live today.
Pull Requests
Full PR lifecycle with inline review comments
One identity per Teammate
Role-scoped GitHub App permissions; the reviewer can only review
Any CI
The grade reads your CI results through commit statuses and check runs
Your Repos
Works with your existing repository structure
Hire your Engineering Teammate today.
Up and running today. Point the Engineering Teammate at your repo, and it’ll be opening PRs the same afternoon.
The same platform runs the rest of your company: sales, marketing and operations Teammates on the same servers.