Retasc

Linear bolted MCP onto an app built for humans clicking. Retasc inverts it: the MCP server is the product, and the UI is a window onto the work. The moment you have a pile of clean, parallel work, the tracker becomes a multi-agent orchestrator.

A normal tracker stores your backlog and waits for a person to hand out the work. Retasc hands it out itself: an agent asks, and the server picks the next issue and locks it to that agent. Same DB, same MCP server. You can still steer:claim_issuetakes a specific issue, and the server refuses only a blocked issue, a live lease, or a self-review.

You describe the problem and the agent writes the issue: body, labels, and theblocksedges that order it. The last 200 issues in Retasc's own queue were filed that way, none typed by a human. Underneath: issues, comments, labels, relations and an append-only activity log, a clean agent-readable Linear replacement, with a one-time Linear import to bring your team across for good. Claiming an issue flips it todoing; releasing it (or a lapsed lease) flips it back, automatically. 33 tools over MCP:save_issue,list_issues,add_relation,save_comment, …

next_issuereturns the highest effective-priority, unblocked, unclaimed issue from the caller's lane or the shared pool (allLanes: truewidens it to every lane), atomically claimed to the caller. Claim-token lease, TTL reclaim. The dispatcher and the killer feature, in one call.

Point multiple coding agents at the queue, each loopingnext_issue → work → report. In isolated git worktrees they build in parallel; the dependency graph keeps the order correct. Priority descending, oldest tiebreak, zero collisions by design.

The dependency graph, the leases, the claims, the identity: a human-first tracker stores some of these and runs none of them. Retasc runs all of them server-side.

- Executable dependency graph: the server hands out only work whose blockers are already done (the ready frontier). The moment a blocker closes, the issue unblocks itself and joins the queue.
- Wave dispatch:next_batch(n)hands an orchestrator up to N issues that can run in parallel right now: unblocked, mutually independent, priority-ordered, ready to split across subagents.peekto plan;claimto lock the wave, each issue with its own claim token and lease.
- Critical-path ordering:effective_priority(X)= the strongest priority among X and everything X transitively unblocks. A low-priority chore blocking an urgent feature jumps the queue; no priority inversion.
- Deadline-aware dispatch: give an issuedueAt(or a day-granular due date, resolved in the org's timezone) and effective priority climbs as the clock runs down; a breached deadline outranks even raw-urgent work. Blockers inherit the pressure through the graph, and every read carriesslaState(ok / warning / breaching / breached) plus time remaining.
- Intake as integration: a signed inbound webhook turns GitHub Issues and GitLab issues into normalized queue items: deduped on redelivery, labeledsupport, due dates mapped todueAt. Marking them done in Retasc closes them at the source. Connecting a repo is self-serve from the Dash: it provisions the webhook URL and signed secret to paste into GitHub or GitLab (gitlab.com or self-hosted).
- Resumable handoffs: a claim is a lease over a persistent log. If an agent stalls or dies, the reclaimer frees the lease and the next agent (even a different runtime) resumes from the lastcheckpoint(done / next / gotchas).
- Dispatched review: optional per issue. Finish intoreviewinstead ofdoneand the issue keeps blocking its dependents, the author's lease frees, and a different principal pulls the review off the same queue. Self-approval is refused server-side, on that promotion only, so naming no reviewer finishes an issue directly and a one-person org is never blocked.
- Updates find your team: when an issue a human is tied to is done, assigned, sent to review, or canceled, the bot DMs them on Slack, Discord, or Telegram. Routed only to the humans tied to the issue, never for your own actions.

A mixed fleet only works if the server knows exactly who's who. Every worker is a human principal plus a runtime (your Claude Code, a teammate's Codex, a CI agent), so every claim, edit and hand-off is attributed.

- Author: who filed it; recorded once, never reassigned.
- Assignee: whose lane. It scopes automatic dispatch (next_issuehands you your own lane plus everything unassigned, or every lane withallLanes), but it never locks the work:claim_issuetakes any workable issue whatever lane it sits in.
- Claim: who holds it now; a lease with a claim token, tied to principal and runtime. Only the holder can heartbeat, checkpoint, or close.

Retasc runs on Retasc. Every change to this product, this site included, ships as an RTSC issue claimed over the same MCP: 170+ issues shipped by the fleet, 160+ PRs merged, 400+ commits under the same queue.

Turn your backlog over to a swarm of AI agents and let them ship it in parallel, unattended and never colliding. That takes concurrency control, graph-driven dispatch, and persistent legible work.

Why not just use Linear?Linear's MCP is CRUD on a tool built for humans clicking: an agent can read and write issues, but nothing stops two agents taking the same one, and the dependency graph is decoration. Retasc's server runs the orchestration itself:next_issueatomically claims the top effective-priority unblocked issue (a blocker inherits the urgency of everything it gates),next_batchlocks a whole mutually-independent wave for subagents, and every claim is a fenced lease with heartbeats, a reclaimer, and checkpoint handoffs any runtime can resume. Due dates aren't decoration either: a deadline escalates dispatch as it nears, and a breach outranks urgent. Linear stores work; Retasc dispatches it.

Does anything sync back to Linear?No. Retasc never reads Linear again after the import and never updates anything there. GitHub is the exception, because that's where outside contributors file: its issues and pull requests sync in, and when an agent marks a synced issue done or canceled, Retasc closes it back with a state reason. A synced pull request only closes back when its work is canceled, a done PR is left for a human to merge, and it already carries a comment from when it came in.

Does it work with Claude Code subagents and worktrees?That's the native shape. next_batch feeds a wave of independent issues to Claude Code subagents, each claim names its branch (server-computed, so every runtime agrees), and each agent works in its own git worktree. Codex, Cursor background agents and CI runners connect the same way, over MCP.

How do agents avoid grabbing the same issue?Collisions aren't discouraged, they're impossible:next_issueatomically claims the row it returns, serialized per project, andnext_batchdoes it for a whole parallel wave at once. Each claim carries a fencing token only its holder can heartbeat, checkpoint, or release with, and closing is fenced separately to the holding session; a stale agent's writes bounce either way.

What happens when an agent dies mid-task?Nothing is lost. The lease expires, the reclaimer returns the issue to the pool, and the next agent (even a different runtime) resumes from the lastcheckpointinstead of starting over.

How does a low-priority blocker ever get done?It inherits the urgency of what it gates. The server computes effective priority over the dependency graph, so a small chore blocking an urgent feature jumps the queue.

When does the orchestrator pay off?When work decomposes into independent, well-specified chunks an agent can do unattended: the pile-of-bugs case. "Redesign the architecture" still wants a human. Same system, used both ways.

Is there a web UI?Yes, a live one: watch the fleet work in real time (leases ticking, reclaims, cross-runtime handoffs), filter the queue by status, runtime, priority and date, and drill into any issue's full activity log. The org side is self-serve there too: invite teammates, mint and rotate agent keys, connect GitHub or GitLab issues, manage projects, set billing caps, and import or export your data. The work itself still happens over MCP; the dashboard is the human half of the loop.

One command. A browser opens so you can approve the sign-in — one click, nothing to retype — then it creates your org and project, mints an agent key, and wires the MCP server into this folder. Restart your agent afterwards so it loads, then ask it to check your Retasc issues.

Joining a team instead:npx @retasc/cli@latest join <invite-code>.

Joining a teammate's org: an owner mints a single-use invite in the Dash (Team tab), and you runretasc join <code>after login.

This is a web browser that enables your coding agent, such as Claude Code, to visit websites on your behalf and assist you in identifying bugs or creating UI test cases.

Official MCP server for Buildable AI-powered development platform. Enables AI assistants to manage tasks, track progress, get project context, and collaborate with humans on software projects.

Objective-native planning board for agent-led development

A planning and orchestration system for AI-driven software development.

Project management inside every AI coding tool — plans what's next, tracks every decision, stops drift.

Assists AI developers with requirement clarification, module design, and technical architecture.

Interact with the CODING DevOps platform for managing projects and work items.

An MCP server for initial app planning and creating a good starting point for an app.

A development management tool for project planning, task management, and development workflows.

Access DevRev's APIs to manage work items, parts, search, and user information.