Lime

A Claude Code plugin that drives a Linear ticket through its development lifecycle, one stage per invocation, by dispatching superpowers skills and syncing status + comments back to Linear via the Linear MCP.

Lifecycle

Ticket status	Stage skill	What it runs	New status
Backlog / Todo	lime-design	using-git-worktrees → brainstorming (feature) or systematic-debugging (bug, Bug label) → plan	To Code
To Code	lime-implement	subagent-driven-development (resumes if interrupted)	To Review
To Review	lime-review	requesting-code-review — skipped when the tree already passed the implement stage's final whole-branch review (reviewed-tree marker)	To QA
To QA	lime-qa	human approval gate — approve → To Merge, reject → To Code	To Merge / To Code
To Merge	lime-merge	rebase onto default → if changed & related: inline review, fix + delta re-review (max 2 cycles); if changed but unrelated or tree already reviewed: skip review → local merge or merge request	Done / To QA / To Code
Done / Canceled / Dup	—	nothing	unchanged

/lime-next is a thin dispatcher: it resolves the ticket and the local repo/worktree, then invokes the one stage skill matching the status. Each stage skill is self-contained (own guards, own Linear sync) and can be invoked directly from the ticket's worktree — e.g. /lime-implement ABC-123 — so a launcher that already knows the status (Mojito) loads only the stage being run instead of the whole lifecycle.

Prerequisites

1. superpowers plugin installed (provides the dispatched skills).
2. Linear MCP connected and authorized.
3. Four workflow states added by hand in your Linear team — the MCP cannot create states:
   • To Code
   • To Review
   • To QA
   • To Merge
4. A project map at ~/.claude/lime-projects.json (see below) — required only when you invoke Lime with an explicit ticket ID from outside a worktree.

Project map

When you pass a ticket ID explicitly (/lime-next ABC-123), Lime needs to know which local repo that ticket lives in — Linear doesn't store your filesystem paths. Map your Linear team keys to absolute repo paths in ~/.claude/lime-projects.json:

{
  "ENG": "/Users/me/code/backend",
  "WEB": {
    "path": "/Users/me/code/web",
    "projects": {
      "Design System": "/Users/me/code/design-system"
    }
  }
}

• A string value maps the whole team to one repo (the common case).
• An object value sets a default path plus per-Linear-project overrides, for teams that span multiple repos.
• The keys under projects are Linear project names (exact). lime-next uses them to pick the right repo; lime-new uses them to assign the new ticket to that project.

Lime reads this map (Step 1.5), cds into the matching repo, then creates the worktree there. Bare /lime-next run from inside an existing worktree skips the map — the current directory is already the right repo.

Unmapped fallback: if a ticket isn't in the map but you run /lime-next <ID> from inside a git repo, Lime uses that repo instead of stopping. This covers teams that span many repos (or aren't worth mapping): cd into the right module and run /lime-next <ID> there. The map only matters when you invoke Lime from outside any repo.

Install

Lime is its own marketplace. From a Claude Code session:

/plugin marketplace add ricventu/lime
/plugin install lime@lime

For local development, point the marketplace at your clone instead: /plugin marketplace add /path/to/lime.

Usage

/lime-new "<title>"  # create a new ticket in Backlog (the `lime-new` skill)
/lime-next ABC-123        # act on a specific ticket (the `lime-next` skill)
/lime-next                # infer the ticket from the current worktree branch (stages 2–5)

/lime-next and /lime-new are skills — invoke them by name or just describe the action in natural language and they auto-activate. Lime runs exactly the one stage matching the ticket's current status, updates the status, and posts a summary comment. Re-run to advance the next stage. Stage 1 requires an explicit ticket ID (no worktree exists yet).

Session naming: at launch — right after its entry guards, before any stage work — the dispatched stage skill prints a ready-to-run /rename <project>/<TICKET-ID> [<work-status>] - <title> command (e.g. /rename Lime/RIC-46 [To Review] - To QA human-approval gate), on direct launches too. <work-status> describes the active work the dispatched stage performs — it is the status the stage was dispatched at, used verbatim (e.g. To Code, To Review, To QA, To Merge, Backlog/Todo), not the current or new status, and never translated — so resuming the session later tells you which stage's work it contains. /rename is a user-only built-in command, so Claude prints it but cannot run it for you.

Next step: at the end of a stage — after the status advances — /lime-next prints the /lime-next command that runs the next stage from the ticket's new status (e.g. /lime-next RIC-91 after To Review, /lime-next RIC-91 approve after To QA), so you copy-run it in a fresh session. Stage 5 (→ Done) is terminal and prints nothing. This replaces the old second /rename that used to close each stage.

/lime-new "<title>" is the pre-lifecycle entry point: it creates a Backlog ticket and prints its ID, so you can go idea → ticket → /lime-next <ID> without leaving the terminal. It resolves the team from --team KEY (or a leading KEY:), else by reverse-looking-up the current repo in the project map, else by asking. It also assigns a Linear project: the one you name in the prompt (e.g. "in the VEP project"), or — by default — the project whose repo you launched from, looked up in the project map. If no project resolves, the ticket is created without one. It only creates the ticket — it never auto-advances a stage.

/lime-rebase <TICKET-ID>

Rebase a ticket's worktree branch onto the default branch while it waits in To QA (the "first part" of To Merge, without the merge). Fetches the default branch if a remote exists (tolerates a local-only repo), rebases, and if the rebase changed code that is related to the branch's own changes runs a code review with up to two inline fix cycles — re-reviews cover only the fix commits (skipping the review when the upstream changes are unrelated or the resulting tree was already reviewed). Stays at To QA on success; escalates to To Code only when review findings can't be fixed inline. Never merges.

Manual test matrix

Lime is prompt logic with no runtime code. Verify behavior by walking a real ticket through these cases:

#	Setup	Expected
1	Backlog feature, /lime-next ABC-x	worktree created, brainstorm runs, status → To Code, comment posted
1b	Backlog ticket with Bug label	worktree created, systematic-debugging runs → plan, status → To Code
2	Ticket in Todo, /lime-next ABC-x	same as #1
3	Ticket in To Code, /lime-next in wt	impl runs (resumes if interrupted), status → To Review, comment
5	Ticket in To Review, /lime-next in wt	code review runs, status → To QA, comment
5j	To Review, tree unchanged since Stage 2's clean final review	review skipped via reviewed-tree marker, status → To QA, comment records the dedup
5k	To Review, commits landed after Stage 2 (marker stale)	full review runs as before; marker rewritten on a clean review
5g	Ticket in To QA, /lime-next (no arg)	prints QA summary (branch, commit range, spec/plan, diff link), stays To QA
5h	Ticket in To QA, /lime-next ABC-x approve	status → To Merge, approval comment posted
5i	Ticket in To QA, /lime-next ABC-x reject	asks for reason, posts comment, status → To Code
5b	Ticket in To Merge, /lime-next ABC-x local	rebase onto default, inline review if changed & related, local --ff merge (no push), status → Done
5c	Ticket in To Merge, /lime-next ABC-x mr	rebase, push, open PR/MR via detected host (gh/glab), status → Done
5d	Ticket in To Merge, no merge arg	asks merge vs mr before proceeding
5e0	To Merge, rebase changes content but upstream is unrelated to the branch's files	review skipped, merges in the same session, Done comment records the skip
5e01	To Merge, rebase changes content but POST tree equals the reviewed-tree marker (e.g. already reviewed by a To-QA rebase)	review skipped like PRE == POST, merges, Done comment records the marker hit
5e	To Merge, rebase changes content, inline review clean	merges in the same session, Done comment records the inline review
5e2	To Merge, inline review finds issues, delta re-review (FIX_BASE..HEAD) passes	fixes committed, status → To QA (human re-QA before merge), no merge yet
5e3	To Merge, findings still blocking after 2 fix cycles or need real rework	findings comment posted, status → To Code, no merge
5f	To Merge, rebase conflicts	rebase --abort, stays To Merge, reports manual resolution needed
6	Ticket in Done	no-op, "nothing to do"
7	To Code/To Review/To QA/To Merge state missing	stops, asks to create the states
8	Bare /lime-next outside any worktree	stops, asks for a TICKET-ID
9	/lime-next ENG-x, team mapped in JSON	cd's into mapped repo, then runs the stage there
10	/lime-next ENG-x unmapped, inside a repo	falls back to the current repo, runs the stage there
10b	/lime-next ENG-x unmapped, outside repos	stops, asks to add the mapping or run from the repo
11	/lime-new "Fix X" inside a mapped project repo	reverse-lookup finds team + project, ticket created in Backlog assigned to that project, ID printed
11b	/lime-new "Fix X in the VEP project"	project parsed from prompt, team derived from it, ticket assigned to VEP
11c	/lime-new "Fix X" from an unmapped dir	team resolved/asked, ticket created with no project
11d	/lime-new "Fix X for Frobnitz", no such Linear project	stops, lists the team's actual project names
12	/lime-new "Fix X" --team ENG	ticket created in ENG Backlog, ID printed
13	/lime-new "Fix X", team ambiguous	asks which team; never guesses
14	/lime-new with no title	stops, asks for a title
15	any /lime-next invocation	/rename <project>/<ID> [<work-status>] - <title> printed right after the ticket fetch, before any stage work
15b	any /lime-next status transition	report ends with the next-step /lime-next <ID> command for the new status — NOT a second /rename
15c	stage ends without a status change (failure, QA summary)	no closing next-step command (launch /rename already printed; in-stage re-run instruction stands)
15d	Stage 5 advances to Done	terminal — no next-step command printed
16	direct stage invocation at the wrong status (e.g. /lime-implement ABC-x on a To QA ticket)	STOP, points at /lime-next <ID> to dispatch the right stage
16b	direct stage invocation outside the ticket worktree	STOP (position guard), points at /lime-next <ID>