The band and stop cards

On this page

The band is the strip above Claude Code's prompt. It shows the ticket you're on, where the team has got to, what it is waiting on you for and how full the context window is, in one row. The examples below are drawn as text, as the terminal draws them; colors are left out. In the desktop app, on mobile and in VS Code the Kotharo mark and the context ring are drawn as shapes.

The row

›◆ ABC-53  Approve the plan?  ●●○○○○○ plan   #45 ✓  +2 waiting  ◔ 42%  Approve the plan  Details

Read it left to right:

The Kotharo mark, ›◆: its diamond's color says what the team is doing: teal while it works, amber while a stop waits on you, red when something failed, and grey when nothing needs you.
The key links to the ticket in Jira, Linear or GitHub Issues. A local key (LOCAL-3), held while the ticketing tool was down, has no page yet and no link. In the desktop app, on mobile and in VS Code it is teal, and the stop's question takes the diamond's tone: amber while it waits, coral when something failed. The terminal draws these in its own theme colors.
Then the status: the stop's question, or what is going on.
Then the stages: a dot for each stage of the lane and the name of the current one. Stages done are green, the current one takes the diamond's color, and the rest are slate and faint.
At the right edge, the ticket's pull request when it has exactly one not yet merged, such as #45 ✓, which opens it; at most one chip for what the band leaves out, manual mode when the session runs in a mode other than auto, the context ring and the buttons.

State	The status reads	Buttons
Working	`2 helpers working`, which opens the helpers pane	none
Working, quiet	`may be waiting on a permission prompt`, once a helper has run for `limits.prompt_quiet_minutes` (10 by default) with no word from the team, until the team reports again	none
Waiting	the stop's question, such as `Approve the plan?`	the default choice, and Details
Trouble	what failed, then the question: `tenant-safety failed · Fix it now?`	the default choice, and Details
Fixing	`fixing tenant-safety · round 1`, while the team fixes a failed check with nothing to ask you	Details, which opens the helpers pane
Held	`Plan stop · 3 ahead`	Open
In flight	`in flight, team not on it`, when the branch has commits or a pull request but the team has no record of it	Join. See Work already under way.
Ticket only	the ticket's title, or nothing: the branch name is never shown	none
Merged	`merged`, in a quiet tone, once the branch's pull request is merged	none
No ticket	`No ticket here`	none

The context ring is covered in Context ring.

The default choice is the one filled button. Every other button, Details and Save notes among them, is outlined, and in the terminal each is plain text you can press.

When Kotharo finds a tool the repo uses that no slot binds, it asks once in a row under the band, question first: Bind Jenkins for deploy? Found in this repo's files. Bind Not here. The row waits until no stop is waiting on you, no check has failed and Claude is idle.

The stages

Press the stage dots or the stage's name to unfold a row of every stage under the band, and press again to fold it. In the desktop app, on mobile and in VS Code the press is the small ▾ button after the stage's name, ▴ while the row is open. The band remembers your choice for the session, so it stays open or folded as the team moves on.

█████████ █████████ ░░░░░░░░░ ░░░░░░░░░ ░░░░░░░░░ ░░░░░░░░░ ░░░░░░░░░
plan      build     review    QA        ship      deploy    close-out

In the terminal each stage gets a bar with its name under it. In the desktop app, on mobile and in VS Code the row lists the names: the current one in the diamond's color and bold, the ones done green with ✓, and the rest slate and faint. The merge stage reads ship until the branch has a pull request, then merge. There are no stages until the team is on the ticket.

The one chip

The band folds everything else into one chip, so it stays one row. It picks the first that applies:

Other tickets waiting on you. Beside a stop this session shows, it reads +2 waiting; otherwise 2 need you, in amber. The count is every row its list shows that still needs you; a stale row is left out, and with only stale rows the chip reads 1 stale. Press it for the list: see When several tickets wait.
Several pull requests in one repo not yet merged: 2 of 3 ready. Press it for the stop card with a row per PR.
Your other worktrees: +2 more. Press it to list them.

With no ticket here, your other worktrees read 2 working beside the need you chip. The band never says working beside waiting.

When the ticket has one pull request, it gets a chip that opens it, such as #45 ✓, whatever the band's state. When it has pull requests in more than one repo, each gets a chip that opens it, such as api #13 ✓ and web #8 …. In both, ✓ is ready to merge, ✗ is failing or closed without merging, and … is a draft or still running its checks. Past two repos, the rest fold into +N more.

A merged pull request leaves the band, since there is nothing left to do on it: the chips and N of M ready count only the ones not merged, and once every one is merged the band shows no pull request chip. The stop card's Result table, its Details and the Docs list still show every pull request with its link.

When room is short

On a narrow window the band drops the chip's words first (+2 for +2 waiting, #45 for #45 ✓), then the context ring's percent, then the stage's name, keeping the dots, then the pull request's chip. It stays one row.

A stop card

When the team reaches a stop, the band asks its question and offers the default choice. Press Details, an outlined button beside the default, for the whole card. In the terminal it opens under the band, and a second press folds it away:

╭─ STOP · plan · ABC-53 ──────────────────────────────────────────────────╮
│ Approve the plan: CSV invoice export for the caller's tenant, 3 tasks?  │
│ Evidence: criteria 1 to 4 map to the tasks; no migration                │
│ Also: should the export include voided invoices?                        │
│ 1: Approve the plan  2: Change...  3: Show plan  4: Not quite...        │
╰─────────────────────────────────────────────────────────────────────────╯

The first line is the one decision, as a question. Then the evidence it rests on, a diff summary at the review and merge stops, any questions the team parked for you, and the choices, the default first. A merge stop looks like this:

╭─ STOP · merge · ABC-53 ─────────────────────────────╮
│ Merge PR #318 with its 4 fixes?                     │
│ Evidence: CI green; tenant-safety passed; QA 6 of 6 │
│ Diff: +120 -30 in 6 files                           │
│ 1: Merge  2: Not quite...                           │
╰─────────────────────────────────────────────────────╯

A card titled BLOCKED is the team stuck on something only you can fix or answer.

The stop pane

In the desktop app, on mobile and in VS Code, Details opens the card in its own pane beside the chat. A choice in the pane and the band's default send the same answer.

Each stop asks a fixed question, so you can tell them apart at a glance:

Stop	The line asks
scope	Is this the right scope?
design	Approve the design?
plan	Approve the plan?
build	Approve the build?
review	Accept the review?
qa	Accept the QA result?
ship	Push and open the PR?
merge	Ship it? until the pull request is open, then Merge PR #318?, or Merge 3 PRs? when the ticket has several
deploy	Deploy to staging?, naming the environment
close-out	Close the ticket?, or with checks still open the card's own question, such as Move ABC-53 to Awaiting Deploy, with deploy and cleanup still open?
fix-loop	Fixes aren't settling. What next?
approval	Approve this command?
budget	Over the estimate. Continue?
question	the team's own question, cut to fit
access	Needs access: and what it needs
blocked	Blocked: and why

When the branch already has an open pull request, the end card's Ship reads Push to PR #318. When the ticket has several pull requests, the default reads Merge 2, for the ready ones: they merge in order, and the team stops at the first that fails. While Claude is still replying, the default button is hidden, and once pressed it reads Sent: Approve the plan.

The pane has room for more, in labeled sections with a gap between each:

Decision: the question, and the team's recommendation;
Not met: at close-out, each check still open with what it waits on, checks waiting on the same thing on one row;
Change: the Intent, the Riskiest area and the PR, a label beside each;
Progress: the lane as a small diagram, with where you are and where a yes leads;
What changed since you last saw the ticket, and What the team understood;
Follow-ups: the top 3 as a numbered list, and how many more;
the parked questions, split into those that need you and those the team will answer its own way unless you say otherwise;
Evidence: each gate once, with a pass or fail mark, the tests, and Reviewed by, leaving out anything the Result table already shows;
Size: the diff, and a note when the PR is oversized;
each choice with a line on what happens after it. Choices that lead to the same thing, such as close-out's Success, Partial and Off target, share one frame and one line.

A close-out card for a ticket merged but not yet deployed reads like this:

Decision
Move ABC-53 to Awaiting Deploy, with deploy and cleanup still open?
The verdict is on the work so far; the deploy comes as its own ask and cleanup runs as its own step.

Not met
deployed,       waiting on the dev deploy of 4f7e3ea
deploy-verified,
watched
cleaned-up      waiting on untracked docs/work/ABC-53 in the worktree

Result
Pull request #45   ✓ merged
QA                 ✓ AC1-6 met

Evidence
tenant-safety   ✓ passed
release note written

The Result table and the gates use the same marks: ✓ met, merged or passed, ✕ failed, … still running, and • only for a status with no state word.

While Claude is still replying, the foot of the pane says the buttons return when the reply ends. In the terminal the pane keeps the same sections in the same order, with the lane as a line of text.

Chat then says only which stop is waiting and asks you to read the pane first.

How to answer

Press the band's default, or a choice in the card, or type its number into an empty prompt.
A choice ending in ..., such as Not quite..., fills the prompt for you to finish in your own words.
Or answer in chat, however you like. To answer a parked question, name it by its number.

Each answer is recorded in the ticket's handoff.md. A new stop sends a notification, so you can work elsewhere while the team runs.

When several tickets wait

The other tickets that need you, across your sessions and worktrees in the repo, show as the band's chip: +2 waiting or 2 need you. The ticket whose stop the band already shows is left out. Press the chip for the list, one row per ticket, oldest first:

ABC-12  Ship it?            20m             Merge             Details
ABC-9   Approve the plan?   5m · queued     Approve the plan  Details

The list sits under a thin divider. Each row shows the key, a link to its ticket where the band can name one, the stop's question, how long it has waited, the stop's default choice and Details, an outlined button. In the desktop app, on mobile and in VS Code the key is teal, the question takes its stop's tone (amber, or coral for a blocked stop), the wait is slate and the rows have a little room between them; a queued row stays dim.

Press the default to answer that stop in its own session, the same as pressing it on that session's band. The row then reads sent, with the stage the ticket is at. A choice that asks for your own words, such as Not quite..., is answered in its session, not from the list.
Press Details to open that ticket's card in a pane here, with all its choices. The pane keeps the card current and empties once the stop is answered.
When that session isn't running, the row says so and offers Copy resume, which copies the command that opens it again.

Rows clear themselves once the ticket is done, even when nobody closed it out. Every minute, and when a session starts, the band checks each row, reading its PR at most once every 5 minutes:

Once the PR is merged and the session that raised the stop isn't running, the row goes at once. While that session still sits at the stop, it goes limits.queue_clear_minutes (60 by default) after the merge woke it. A toast says Cleared ABC-12: PR #7 merged, and the ticket gets a close-out record with verdict merged, no close-out.
A row whose ticket has a close-out record newer than its stop goes too.
A row whose session isn't running, whose worktree is gone and which has no open PR (a closed PR counts as none) stays, faint and marked stale, with Dismiss in place of its default. Dismiss takes the team off the ticket as /kotharo:leave does, with a left record that says it was dismissed from the list. Work that never merged is never cleared on its own.

Clearing never moves the ticket, posts, pushes, or deletes a branch or worktree. When the PR can't be read, the row stays as it was.

Answering from the list sends a short message to the other session, which answers only a press the plugin recorded for the stop it is waiting on now, within the last two minutes. A message on its own answers nothing, and a press for a stop that has since changed or been answered is dropped.

When 3 already wait, a new stop that isn't urgent is held until you answer one: it sends no notification and opens no pane by itself. Held stops come last in the list, dim, marked queued. In its own session the band reads Plan stop · 3 ahead with Open, so you can still answer it right there, and the team states the question and its choices in chat. A stop that needs your login or your OK to go on is never held. A stop that waits an hour sends one reminder.

Next: Context ring. All docs