⌘K
ChangelogSign inJoin waitlist
Docs/Core concepts/Tickets & statuses
// CORE CONCEPTS

Tickets & statuses

A ticket is the unit of work in Leroy — one bug, change, or request. It usually becomes a single pull request; a change that spans more than one repo opens one PR per repo, and the ticket ships once they're all merged. Everything Leroy does happens on a ticket, and every ticket carries an owner (Leroy or you) and a status that tells you exactly where it is.

01 What a ticket is

Think of a ticket as one scoped piece of work. It usually resolves to a single pull request — or, when the change touches more than one repo, one PR per repo. It might come from a bug you file, a Sentry error, a Linear issue, or a request in chat — whatever the source, it lands as a ticket. The ticket holds the description, the plan Leroy writes, the diff, and the review, so the whole story of a change lives in one place.

Bigger efforts — many related changes — are grouped as a project, a set of related tickets, but each ticket inside it is still its own unit of work.

02 The lifecycle

A ticket starts as not started. When Leroy owns it, it runs through an agent loop — queued, triaging, planning, coding, revising, reviewing — and comes out the other side as in review, where the PR waits (or merges, depending on your ship gate). When it merges, the ticket is done.

But Leroy doesn't barrel ahead. At each step it checks it actually has what it needs — enough context, a clear-enough plan, a passing build — and when something's missing or ambiguous, it holds and asksinstead of guessing. A ticket can pause to ask you a question (it's waiting on your answer), wait at a gate for your approval, go blocked when it needs something it can't get on its own, or sit parked for later. Whenever it needs you, the ticket surfaces in your needs-youqueue with exactly what it's waiting on.

i
It asks before it guesses. Where Leroy pauses on purpose is up to you — your policy gatesdecide whether it waits at intake, plan, and ship. On top of that, Leroy will always stop and reach out the moment it hits something it isn't sure about, rather than charging forward on a bad assumption.

03 Statuses & buckets

Under the hood, Leroy flows each ticket through a detailed set of statuses — queued, triaging, planning, coding, reviewing, blocked, and more. That's how it tracks exactly where every piece of work is and routes it through the system. You don't manage those. Every status maps automatically to one of five buckets, so the board always reads simply:

Bucket
What rolls into it
Not started
Filed but not picked up yet — including a ticket waiting for you to approve before Leroy starts.
In progress
Leroy is on it — queued, triaging, planning, coding, revising, reviewing — and the moments it needs you: a question to answer, a plan to review, or work that's blocked or stuck.
In review
The pull request is open — waiting for your review, or for checks before an auto-merge.
Paused
Parked for later, until you pick it back up.
Done
Shipped — the PR (or PRs) merged. Cancelled work lands here too, tucked away by default.
i
Buckets, not noise.The detailed statuses are Leroy's own bookkeeping; the board only ever shows these five, so you see the shape of the work at a glance. Open any ticket to see its exact status and what it's waiting on.

04 Refs

Every ticket has a short reference like PIT-693 — a stable id you can use to find it, link to it, or mention it in chat and over MCP. Refs make it easy to point at one specific piece of work without copying a URL.

← Prev
Connect your tools