The agent said “done”. It wasn’t.
It said all tests pass. They never ran. Levr won’t let an agent close a task until your plan actually passes.
Free during preview · No credit card · Works with Claude Code, Cursor and Codex
⏺ All 6 steps are implemented and the tests pass. Marking ENG-412 done.
⏺ levr - transition_issue (MCP)(ENG-412 → Done)
Refused. 3 required gates are failing.
- failno_stubssrc/billing/refund.ts: 2 TODO markers
- failunit_test_passrefund.test.ts: 3 skipped, 0 ran
- failspec_conformancepartial refunds not handled (plan step 4)
- passtypecheckexit 0
- passfile_existssrc/billing/refund.ts
⏺ You’re absolutely right. refund.ts still has two stubs and the test file never ran. Fixing.
// what is levr?
A project and issue tracker that keeps your agents on plan and makes sure done is really done.
Keep the agent you already use. Levr plugs in over MCP.
- + any MCP client
// the problem
You’ve seen every one of these.
// TODO: implementStubbed the hard function and moved on.
expect(true).toBe(true)Wrote a test that can’t fail.
it.skip("refunds the remainder"Turned off the failing test instead of fixing the code.
Tests: 0 passed, 0 total“All tests pass.” None ran.
return MOCK_CUSTOMERS;Left the mock in where the real call should be.
✓ 5 of 6 stepsSkipped part of the plan and didn’t say so.
It’s in your CLAUDE.md, in caps. The agent did it anyway, because it grades its own work. Levr takes “is it done?” away from the agent.
// how it works
The agent doesn’t decide it’s done. The gates do.
- 1Step 1 of 3
Write the plan. Every task gets Levr Gates.
The checks and tests that must pass, written before the code. Your agent drafts them, you edit. Changing one later takes a reason.
levr · ENG-412 · gatesENG-412Partial refunds
Deliverable · To dogates written before any code · 6 required · 1 advisory
- presencefile_existssrc/billing/refund.tsrequired
- patternno_stubsno TODO / FIXME leftrequired
- executiontypecheckyarn typecheckrequired
- executionunit_test_passrefund.test.tsrequired
- executione2e_test_passrefund.e2e.tsrequired
- semanticspec_conformancepartial refunds, to the centrequired
- semanticedge_case_coveragealready-refunded, zero amountadvisory
- 2Step 2 of 3
The agent does the work, then runs the gates.
In any agent, in its own checkout. Levr reads the command, the exit code and the output. “It passed” doesn’t count. Zero tests ran is a fail.
zsh · your checkout$ levr gates run ENG-412
run test -f src/billing/refund.ts
passEXISTS
run grep -cE '(//|#) *(TODO|FIXME)' src/billing/refund.ts
fail2
run yarn typecheck
passexit 0
run yarn vitest run src/billing/refund.test.ts
failexit 0 · 3 skipped, 0 ran
…3 more
3 of 6 required gates failing · exit 1
- 3Step 3 of 3
Red gate? The task stays open.
The agent fixes it and runs again. Every attempt is kept, and a waiver needs a reason. You see what passed, what failed first and what got waived.
levr · ENG-412 · attempts- #114:02agent3 failingno_stubs · unit_test_pass · spec_conformance
- #214:09agent1 failingspec_conformance: rounding on partial refunds
- #314:16agentall pass6 of 6 required
- #414:21ciall passsame gates, run in CI
waived · edge_case_coverage (advisory)
sarah: “zero-amount refunds are blocked upstream, see ENG-398”
3 rounds to get from “done” to done
Done
// levr gates
What’s a Levr Gate?
A check or a test attached to a task, written before the work starts. Required gates have to pass before the task can move to Done, no matter what the agent says.
Six kinds of Levr Gate
20+ built-in gate types, plus your own shell checks
Presence
Is the thing there?
Catches: The file that never got created.
- file_exists
- module_imports
Pattern
Does the code say this, or not say that?
Catches: Leftover TODOs. The import you asked it to remove.
- no_stubs
- file_not_contains
Structure
Is it built the way the plan said?
Catches: Domain code reaching into the database layer.
- ast_pattern
- symbol_referenced
Execution
Does it typecheck, build and pass its tests?
Catches: Red tests, and green runs where nothing ran.
- typecheck
- e2e_test_pass
Semantic
Does it do what the task asked for?
Catches: Code that works but solves a different problem.
- spec_conformance
- guided
State
Did the thing actually happen?
Catches: An issue that never reached the state it should have.
- control_plane
// why six kinds
A grep isn’t a test. We learned that on our own code.
Our first gates were all greps. A text input passed all 8 and couldn’t take a keystroke. One test that types into it would have caught it. That’s why there are six kinds.
Then: 8 grep gates · all green
- TextInput.tsx exists
- contains onChange
- contains useState
- contains value=
- contains placeholder
- exports TextInput
- imported by the form
- contains a test file
Add 1 execution gate · red
e2e_test_pass · typed “hello” · input received nothing
Gate list paraphrased.
// we didn’t make this up
Read the code. Run the code. Keep the record.
That’s how NIST and IEEE already say software should be verified. Levr Gates work the same way.
NIST IR 8397 (opens in new tab)
Guidelines on Minimum Standards for Developer Verification of Software
Automated testing, static code scanning and code-based structural test cases.
Execution, Pattern and Structure gates.
NISTInteragency Report · referencedIR 8397NIST SP 800-218 (opens in new tab)
Secure Software Development Framework (SSDF) 1.1
PW.7: review and analyze the code. PW.8: test the executable code.
Structure and Semantic gates read it. Execution gates run it.
NISTSpecial Publication · referencedSP 800-218IEEE 1012-2024 (opens in new tab)
Standard for System, Software, and Hardware Verification and Validation
Plan verification and validation tasks for each stage of the work, and report the results.
Gates per task, written first. Every attempt kept.
IEEEStandard · referenced1012-2024
Aligned with these, not certified against them. The full mapping is in the docs (opens in new tab).
// tracker + tests, one place
QA used to be the next step. Agents broke that.
A separate QA pass could keep up with humans, not with agents. In Levr the tests live on the task, and a red one keeps it open. For many teams, that means no separate test management suite needed.
- ENG-409Refund reason codes4/4Done
- ENG-410Post refunds to the ledger5/5Done
- ENG-412Partial refunds5/7Gate verification
- ENG-413Refund receipt email1/3In progress
- ENG-417Admin refund override0/4Blocked
- ENG-415Rate-limit the refund API0/4To do
Levr Gates · 5/7
- passfile_existsrequired
- passtypecheckrequired
- passno_stubsrequired
- passunit_test_passrequired
- faile2e_test_passrequired
- runningspec_conformancerequired
- passedge_case_coverageadvisory
Linked tests · 3/4
- passRefund the full amountautomated · run by CI
- failPartial refund rounds to the centautomated · run by claude-code
- passRefund an already-refunded orderautomated · run by claude-code
- passRefund from the admin consolemanual · run by Sarah
✗ e2e_test_pass · refund.e2e.ts · expected 12.35, got 12.34
- Test cases, shared steps, data sets
- Agent, CI and manual runs
- JUnit · Cucumber · CTRF import
// context
Your tracker is your agent’s context.
Your agent reads everything in Levr over MCP. Every issue, plan, decision and test is vectorized for RAG, so it finds the old bug by meaning, not keyword.
- vector index built in
- hybrid semantic + keyword
- search_issues over MCP
Trackers like Jira were built for the era of human coding volume, and their AI support is bolted on. Levr was built for agentic dev from day one.
> customers say refunds are off by a penny, fix it
⏺ levr - search_issues (MCP)(“refund off by a penny”)
- ⎿ ENG-398 EUR partial refunds come out one cent short (Bug · Done)
- ⎿ ENG-401 Use banker’s rounding for all money math (Decision)
- ⎿ ENG-412 Partial refunds (Deliverable · In progress)
⏺ levr - get_issue (MCP)(ENG-398)
⎿ fixed in money.ts with roundHalfEven() · see ENG-401
⏺ Same bug as ENG-398, now in the new partial-refund path. Using the existing roundHalfEven() from money.ts instead of writing another one.
// dashboard
See what your agents actually did.
What shipped, what’s stuck and who’s carrying it, humans and agents alike. Live, from the same data the agents write to.
Open
218 ▼ 15
38 created this week
In progress
42 ▲ 6
avg age 4.2d
Blocked
7 ▼ 3
oldest 6d
Completed
511 ▲ 38
58% of all work done
Throughput
net backlog −23/wk
Cycle burndown
Cycle 14 · 2d left
72% complete · on track · scope +1 pt
Test health
tests per issue
4.6×
7,532 test cases · 94% automated · 457 manual
Workload
12 unassigned
Needs attention
7 blocked · 12 uncovered
- Blocked
Stripe webhook retries flaky on staging
LEV-897 · High · idle 3d
- Stalled
3-D Secure challenge times out on mobile
LEV-903 · Medium · idle 14d
activity · 1,284 events this week — 62% by agents · humans closed the last 41 approvals
// in their words
Don’t just take our word for it.
“One final major failure mode that we observed was Claude’s tendency to mark a feature as complete without proper testing.”
Anthropic (opens in new tab)Engineering blog · Nov 2025“As code throughput increased, our bottleneck became human QA capacity.”
OpenAI (opens in new tab)On building with Codex · Feb 2026“Your job is to deliver code you have proven to work.”
96%
of developers don’t fully trust AI-generated code to be correct. 48% always check it before committing.
Sonar survey, 1,100+ developers, Jan 2026 (opens in new tab)
~half
of agent pull requests that passed the benchmark’s tests would not have been merged by the projects’ own maintainers.
METR, Mar 2026. SWE-bench Verified, agents from mid-2024 to late 2025 (opens in new tab)
// also in the box
Everything else you’d expect.
Levr is the control plane for agentic development: one place for the plan, the issues and the tests, that you and your agents both work from.
Plans and issues
A tracker your agent can read and write: plans, tasks, bugs, decisions. The plan your agent works from is the one you’re looking at.
Built for the keyboard
Command palette, single-key shortcuts and undo, for when you’re the one in the app.
GitHub and Jira
Branches and PRs link to their issue and can close it on merge. Jira syncs both ways, so you can move one team at a time.
Any agent
An MCP server, a CLI and a Claude Code plugin. Claude Code, Cursor, Codex CLI, Gemini CLI, VS Code, Windsurf, Zed and more.
A name on everything
Every change and every check result records who did it: a human, an agent or CI.
API and SDK
A REST API for everything in the app, and a TypeScript SDK for the common calls.
// faq
Questions, answered.
What is Levr?
A project and issue tracker built for teams that code with agents. Your plan, tasks, tests and results live in one place that you and your agents both read and write. Every task can carry Levr Gates, and a task with a failing required gate can’t be closed.
What’s a Levr Gate?
A check or a test attached to a task, written before the work starts. “This file exists.” “No TODOs left.” “These tests run and pass.” “It does what the task says.” Required gates have to pass before the task can move to Done.
Which agents does it work with?
Anything that speaks MCP. The installer sets up Claude Code, Claude Desktop, Cursor, Windsurf, Zed, VS Code, Gemini CLI, Codex CLI, Grok Build and Antigravity. You can mix them on the same project.
Who writes the gates?
Usually your agent drafts them from the plan, and you can write or edit them yourself. Write them before the code. Once work has started, changing one takes a reason.
Can’t the agent just say the gate passed?
Not by saying so. It has to hand over the command it ran, the exit code and the output, and Levr decides pass or fail from those. No raw output is an error. A test run where nothing ran is a fail. If you want a run the agent can’t touch, run the gates in CI.
Where do gates run? Does Levr see my code?
The checks and tests run in your checkout, on your machine or in CI, not on Levr’s servers. Levr gets the command, the exit code and the tail of the output.
What if a gate is wrong?
Waive it. A waiver needs a reason, the reason stays on the task, and the failed attempt stays in the history.
Do I still need a separate test management tool?
Many teams won’t. Levr has test cases, shared steps, data sets, manual runs and cycles, and imports JUnit, Cucumber and CTRF results from CI. If you rely on formal test plans or need to bring years of history over from another tool, check those first.
Does Levr replace Jira?
Only if you want it to. Levr syncs issues both ways with Jira, so a team can work in Levr while everyone else stays in Jira, and nothing has to move at once. Or skip Jira entirely: Levr is a full issue tracker on its own, with projects, initiatives, cycles, labels and saved views. It works the same way with GitHub Issues, and links branches and pull requests to their issue.
What does it cost?
Levr is free during the preview. No credit card.
// try it on one task
Done means proven.
Connect your agent and give it one real task with gates. See what it says when it can’t just say “done.”
Free during preview · No credit card
# connect Claude Code, Cursor, Codex… to Levr
$ npx @levr-one/cli@latest mcp add
# in Claude Code: add the plugin, then start on a task
> /plugin marketplace add BitModern/levr
> /plugin install levr@levr
> /levr:work ENG-412
# run a task’s gates yourself, or in CI
$ levr gates run ENG-412