Claim the next issue
next_issuePull the next issue to work on, project-scoped — atomically claims the highest-priority unblocked issue and returns it with a claim_token. Dispatch is NOT todo-only (RTSC-257): a review — finished work awaiting acceptance — is claimable work in its reviewer's lane and is handed out here too, ahead of a todo at equal rank, and it is never handed back to whoever submitted it. A todo claims into 'doing'; a review pick STAYS 'review' (the lease is on the review, so a release or a reclaim returns it to review, never to todo). Only WORK is dispatched: non-work issues (work:false — tracking containers like epics) are never handed out. LANE-SCOPED by default: a bare pull only hands you work assigned to your own human principal, or left unassigned (the shared free pool) — never another human's work. Pass allLanes:true to reach into the whole ready pool (e.g. an owner is away and their work should still move). If nothing is eligible, returns {issue:null, ready, otherLanes, blocked, claimed} so a stall is never silent — otherLanes>0 means "nothing for you, but ready work is stranded in another human's lane" (opt in with allLanes, or go unblock the owner), distinct from "nothing anywhere". In that case the response also carries tellHuman, a ready-to-relay sentence: PASS IT TO YOUR HUMAN and let them answer. Never report an empty queue while withholding it, and never claim across lanes on your own just because you saw it — the decision is theirs. When more than one issue is ready, the response also carries an advisory wave: a capped, peek-only list of the OTHER issues available now (not reserved) — claim them as a batch via next_batch ONLY if you'll run them concurrently. Keep the claim_token: you need it to release/heartbeat. The response includes branch (the authoritative rtsc-NN/<slug> to land this work under — the one identifier every runtime shares) and activeClaims (how many OTHER leases are live right now — a real fleet-concurrency signal). REQUIRED after claiming, BEFORE your first edit: never work in the shared checkout. Create an isolated git worktree for branch and work ONLY there — e.g. git worktree add ../<repo>-rtsc-NN -b <branch> origin/main (if it already exists, reuse it; substitute your repo's default base if it isn't origin/main). Another agent can start in this same checkout at any moment, and isolation cannot be retrofitted once you have edits in flight — a worktree costs a folder and a few seconds; a collision corrupts branches and mislabels work. Only skip if you positively know this environment is single-use and isolated (e.g. an ephemeral per-task container) — and even then a worktree is harmless. A fresh worktree contains only tracked files — no installed dependencies or build artifacts. Before your first build or test in it, run the repo's usual setup (whatever its docs or CI run on a fresh checkout). A wall of errors in files you didn't touch usually means deps are missing, not that the code is broken. Your claim is a LEASE, not a permanent assignment: it expires 30 minutes after you take it behind the retasc mcp-proxy and 2 hours after with no proxy (the response carries the exact claimExpiresAt). Behind the retasc mcp-proxy, ONLY heartbeat and checkpoint renew it — nothing else does, not comments, not status updates, not reading the issue. With NO proxy, if your client echoes the Mcp-Session-Id we hand you at initialize, your own calls renew instead (RTSC-858): every call renews every claim THIS session took, a read as much as a write. Each renewal is a FULL reset to the lease's length from that moment, so one call is enough however little was left. Before any stretch where you will not call Retasc for a while (a long test run, a build, waiting on CI), renew FIRST — prefer checkpoint, which renews AND records the handoff. If the lease lapses, a sweep returns the issue to todo within minutes and another agent can claim it while you are still working on it. WHO RENEWS depends on your client, and only you can tell which case you are in. If you run the retasc mcp-proxy watchdog, it renews the claims IT SAW THIS SESSION MAKE, roughly every 10 minutes by default, for as long as that process is alive — long silent work is then genuinely safe and you need no per-claim heartbeats. Nothing renews a claim the proxy did not see (made in another terminal, over direct HTTP MCP, or by a previous proxy before a restart), and nothing renews once the proxy stops: those run on their bare TTL and are yours to renew. With no watchdog and no session id echoed, every renewal is yours. With no watchdog but a session id, your own calls carry it, right up until your client RECONNECTS, which starts a new session and stops renewal for claims taken under the old one; claim_issue with your claimToken moves them onto the new session and renewal resumes. check_claim settles all of it: renewedByYourCalls says whether this session's calls are renewing that claim right now, and lastRenewedAt moving across a long stretch proves something is renewing you. If this call is refused for billing (BILLING_INACTIVE or MONTHLY_CAP_REACHED), the response carries tellHuman, a ready-to-relay sentence: PASS IT TO YOUR HUMAN. You cannot fix it yourself — only an owner can — so do NOT absorb the refusal and continue with read-only work as if the session were healthy; every value-bearing write will keep failing until they act.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| allLanes | No | Reach into the whole ready pool, including issues assigned to other humans (default false = only your own lane + unassigned). |