Repository navigation
Replies: 1 comment 3 replies
|
I have the same use case. I keep I prototyped this as a plugin using For my use case, I would prefer Native support would also avoid launching a plugin process and the race between listing Agents and focusing the selected pane. |
Uh oh!
There was an error while loading. Please reload this page.
idea / problem
With several agents running, the useful question is "which one is waiting on me?" — and herdr can already answer it two different ways, but neither is a keypress that takes me there.
ui.agent_panel_sort = "priority"sorts the panel bytab_attention_priority(blocked > done-unseen > working > idle), sonext_agentwalks the urgent ones first. But that ordering is also whatfocus_agentindexes into, so turning it on makes my indexed jumps move around as agents change state. Stable numbers or attention-ordered cycling — I can have either, not both.open_notification_targetcovers the most recent notification, but not "step through everything still waiting".So today, finding the blocked agent among five means either reordering the panel out from under my
focus_agentbindings, or cyclingnext_agentthrough the working and idle ones until I land on it.requested change
A keybinding that focuses the next agent needing attention, independent of
agent_panel_sort:This was already implemented in #1486 — filtering
agent_panel_entriesto blocked, finding the current position, wrapping with modulo, following the existingnext_agent/previous_agentpattern. That PR was closed on process (new contributors need maintainer approval first, and feature discussion belongs here rather than in a PR), not on the merits, and I couldn't find a Discussion where the idea itself got picked up. Opening one so the direction can be settled before anyone writes code again.Three things worth deciding:
tab_attention_priorityalready ranks those 4 and 3, and both are states where the agent has stopped and wants me. A single binding covering "priority >= 3" may be more useful than a strictly blocked-only one — or two bindings, if they're meaningfully different jobs.next_agentnot reaching agents in other workspaces; whatever this does should match that behavior from the start.next_blocked_agentis accurate if it stays blocked-only, but misleading if scope 1 goes the other way — something likenext_agent_needing_attentionwould survive both answers.why you want this
I run five Claude agents across six tabs in one workspace, and the state I care about is almost always "one of them is asking a question". Right now noticing that is a sidebar glance followed by counting rows, and acting on it is either a mouse click or cycling past the agents that are perfectly fine on their own.
The pinned-panel-order constraint is the part I'd emphasize: I deliberately keep
agent_panel_sort = "spaces"so myfocus_agent = "prefix+shift+1..9"bindings stay stable, which is exactly what rules out thepriorityworkaround. A dedicated binding sidesteps the conflict, since it doesn't need the panel reordered to find the right agent.All reactions