Pimp My IDE / garage dispatch
Back to garage
October 3, 2026 | attention / developer workflow

Your dashboard needs a clutch.

GitHub put agent sessions, issues, and pull requests on one work surface. Keep the feed on a separate shaft. Decide what can engage your attention before the dashboard decides for you.

A dashboard should answer "What needs my move?" A feed should answer "What changed?" Mixing those questions turns useful context into queue pressure.
Attention clutchFeed disengaged
Work queueUpdate feed
One surface, two jobsPull requests, issues, and agent sessions can drive work. Feed items stay available without taking the wheel.

GitHub split work from catch-up.

GitHub made its new dashboard the default on October 1. The company says it puts active agent sessions, issues, and pull requests in one place. Each list can hold up to 12 items. The update feed now has its own tab.[1]

That separation matters more than the new layout. Work objects carry an expected move. A pull request may need review. An issue may need a decision. An agent session may need inspection. A feed item may only need awareness. They should not all arrive with the same visual force.

Put work on the dashboard. Put ambient change in the feed. Give both a return path.

The queue still needs a rule.

GitHub's dashboard reference lists recent pull requests that you authored, reviewed, were mentioned on, or were asked to review. It lists issues assigned to you or involving you. The page also exposes running and past Copilot cloud agent sessions.[2]

Those categories describe involvement. They do not rank consequence. "Mentioned" can mean a blocker or a courtesy copy. "Assigned" can mean work for today or work for next month. A dashboard can collect the right objects and still leave the operator to set the order.

Use a short queue. Choose the first question before opening it. "Who am I blocking?" produces a different order than "What can I close in ten minutes?" Keep that choice visible.

Do not optimize for empty.

GitHub's notification tutorial suggests choosing whether to handle the most important updates first or clear easy distractions first. It also proposes asking "Who am I blocking?" for high-priority triage and "What was I blocked on that I'm no longer blocked on?" for follow-up.[3]

An empty dashboard is not a delivery metric. Clearing low-value items can feel productive while one review blocks a release. Keep a visible capacity limit, but sort by the cost of waiting before the ease of dismissal.

Build a dashboard contract.

  1. Name the question for this pass, such as unblock, follow up, or explore.
  2. Set a visible item cap. GitHub allows up to 12 per list. Fewer can protect focus.
  3. Choose which work signals may enter the queue.
  4. Keep update-feed browsing separate and time-boxed.
  5. End with a handoff. Record what moved, what remains blocked, and when to return.

The contract can fit on five lines. Its job is to stop the dashboard from becoming a single surface for every kind of attention.

Interactive makeover / attention clutch

Set the work shaft.

Traditional purpose replaced: one dashboard that asks every visible item to compete. Better version: choose a triage question, cap the queue, admit specific work signals, and generate a short operating card.

Queue controls

These controls draft a dashboard policy. They do not connect to a GitHub account or read live work.

Question for this pass
6 items
3 / narrow12 / GitHub list limit
Signals admitted to the work queue
Generated operating card

See what gets torque

The bars show which signal classes can occupy this pass. They do not measure a live backlog.

Teaching view / selected signals3 work signals engaged
Work pass configured.Unblock is selected with 3 work signals and a 6-item cap. The update feed stays parked.
A configured card records intent. It does not prove that a queue was reviewed, a blocker moved, or an agent session was inspected.

Sources read

Source log and evidence boundary
  1. GitHub Changelog, "New dashboard experience now the default", published October 1 and read October 3, 2026. It supports the default rollout, the active agent session, issue, and pull request lists, the 12-item limit, the separate Feed tab, and the dashboard action examples.
  2. GitHub Docs, "Personal dashboard", read October 3, 2026. It supports the listed dashboard categories and inclusion criteria. The page still labels the updated home view as a public preview, while the newer changelog says the experience is now the default. We use the changelog for rollout status and the reference for category details.
  3. GitHub Docs, "Customizing a workflow for triaging your notifications", read October 3, 2026. It supports the high-priority versus easy-clear triage choice and the two blocking questions quoted in the article.

Evidence boundary. GitHub documents the product behavior. The attention clutch is our editorial method. It drafts a policy in the browser and does not connect to GitHub, inspect a live dashboard, rank real work, or save account settings.