Landscape — Morning Catch-up

Show a consolidated landscape of where you are and what to do next, pulling from multiple sources at once. Designed for the start of a work session (especially Monday mornings) to quickly orient.

Usage

/landscape          # Full landscape
/landscape quick    # Skip PR details and review requests (faster, Jira + working-copy + beads-if-present only)
/landscape resume   # Compact local resume-or-next orientation; no Jira or GitHub requests
/loop 30m /landscape quick   # Unattended refresh through the day (Claude Code); pair with /watch-prs for CI

Resume mode

Select the mode before any fetch. For /landscape resume, run only the three read-only helpers below, read handoff fields, render the compact summary, then return. Do not enter the full/quick procedure. No Jira or GitHub requests, liveness network probes, settings checks, background loops, or automatic follow-up workflow invocations.

~/.agents/skills/handoffs/scripts/list.sh --summary-only
~/.agents/skills/next/scripts/next-bd --in-progress --avoid-busy
~/.agents/skills/landscape/scripts/working-copy.sh

Use fresh output every time. The working-copy line describes only the cwd repository and its worktrees, not a full workspace Git audit. next-bd owns ranking, readiness, owner identity, busy filtering and source diagnostics; use its emitted order without a separate ranking algorithm. Retain repository qualifiers in workspace candidates/claims. CURRENT-REPO-LIVE is an offline eligibility hint, not proof of session activity. Member counts are raw/unclassified, not live counts.

Do not load or archive a handoff, create/recover a worktree, change tracker state, or start coding. A failed/missing helper or malformed section is unavailable, never an empty-success signal. Retain healthy sources; summarize unavailable source names in one diagnostics line and point to the full owner for details. Missing optional tools do not authorize installation or authentication.

Output at most 15 lines, including headings/blank lines. Do not reproduce the full helper tables. Each field below stays one line: sanitize embedded newlines in labels, show at most three recent handoff slugs and three owner-qualified claim IDs, and use +N more for the rest. All tracker claims have session activity unverified. No full handoff content is loaded by this mode.

## Resume or next
Working copy: {cwd repo / branch / dirty / ahead / other-worktree warning, or unavailable}
Recent handoffs: {up to 3 eligible slugs with branch; +N more / none / unavailable}
Workspace handoffs: {raw count, unclassified / none / unavailable}
Tracker claims: {up to 3 owner-qualified IDs; +N more / none / unavailable}; activity unverified
Ready: {first owner-qualified candidate and title / none / unavailable}
Sources: {unavailable/partial sources, or local snapshot; remote liveness not checked}
**Next:** {one recommendation, never an action taken}

Recommendation order: unresolved working-copy risk → inspect that risk; eligible current-repo handoff on the current branch (or newest eligible handoff) → /handoffs; claims → inspect the identified claim rather than assuming it belongs to this session; unclassified member handoffs → /handoffs; ready work → /next safe; otherwise /triage. When relevant evidence is unavailable, recommend resolving that gap instead of declaring there is no work. Recommendations carry no selection indexes or automatic claim; /handoffs owns loading/recovery and /next owns claiming.

What It Shows

Separate blocks, rendered from broadest context to most immediate. Order matters — the last block is the most load-bearing for "what am I doing right now":

1. 📋 Jira — tickets assigned to you, not Done (with sprint and latest discussion)
2. 🔀 PRs — org-wide open PRs, recently closed, unresolved threads
   • 👀 Review requests — open PRs requesting your review in this repo and registered workspace repos (full mode only)
3. 🎯 Beads — in-progress and top ready beads in this repo (skipped if bd not installed)
4. 📍 Working copy — current branch and uncommitted/unpushed work; at a multi-repo workspace root this becomes one per-repo table over every member instead, since the root's own branch is never where the work is
5. Next — single-sentence suggestion for the most load-bearing action

Each block is independent — if one source fails, the others still render.

Instructions

MUST re-fetch on every invocation. Only the full/quick modes follow this procedure; resume mode returns above. Each full/quick run MUST execute every applicable fetch from scratch — date, the Jira MCP query, the gh-pr-list-* and gh-pr-details.sh scripts, beads.sh, and working-copy.sh. NEVER reuse output from a previous run in the same session and NEVER extrapolate timestamps. State changes (PR merges, new approvals, ticket transitions) happen between runs; reusing stale tables has caused real merges to be missed in /pr-status and the same risk applies here.

MUST use the dedicated helper scripts. Never construct ad-hoc bd … or git … shell pipelines for this skill. Specifically: do NOT chain command -v bd probes with bd list … && … or … || bd list --ready inside a single Bash call. Always invoke ~/.agents/skills/landscape/scripts/beads.sh instead — it handles probing, repo gating, and listing internally. Likewise, do NOT hand-walk sibling service repos with your own for … git -C … loop — always go through ~/.agents/skills/wrap-up/scripts/multirepo.sh (§4b), which handles workspace detection and per-repo state. Inline chaining bypasses the per-script permission allowlist and produces noisy permission prompts.

Render the blocks in the order listed below. Some data fetches can run in parallel at the top.

0. Header

date '+%A %Y-%m-%d %H:%M'

Output:

## Landscape — {Weekday} {YYYY-MM-DD} {HH:MM}

If the weekday is Monday, add a subtitle: _Monday — extra catch-up across the weekend._

1. 📋 Jira — assigned to you

Query Jira for open tickets assigned to the current user, including sprint membership. The sprint field is the Jira Cloud default custom field customfield_10020. Use the MCP tool:

mcp__jira__jira_get
  path: /rest/api/3/search/jql
  queryParams:
    jql: assignee = currentUser() AND statusCategory != Done ORDER BY cf[10020] ASC, priority DESC, updated DESC
    fields: summary,status,priority,issuetype,updated,customfield_10020
    maxResults: 20
  jq: issues[*].{key: key, summary: fields.summary, type: fields.issuetype.name, status: fields.status.name, priority: fields.priority.name, updated: fields.updated, sprint: fields.customfield_10020}

The sprint field is an array of sprint objects. Extract the active sprint's name (first sprint where state == "active"), or the most recent if none are active. If the array is empty or null, show — (ticket not in a sprint — possibly backlog).

Sort the rows before rendering. JQL's cf[10020] sort is unreliable across sprint states, so re-sort client-side:

1. Bucket by sprint state: active sprints first, then future sprints (by startDate ascending), then no-sprint / backlog last.
2. Within each bucket, sort by priority P1 → P2 → P3 → P4 → P5 (treat missing/unknown priority as lowest).
3. Within equal priority, preserve the JQL updated DESC order.

Keep it as a single table — the Sprint column makes the group boundary visible without subheadings.

Render:

### 📋 Jira — assigned to you

| Key | Sprint | Type | Pri | Status | Updated | Discussion | Summary |
|-----|--------|------|-----|--------|---------|------------|---------|
| [AB-649](https://.../browse/AB-649) | Sprint 42 | Task | P1 | In Progress | 2h | 💬 3 · Jane · 40m | Stabilise identity cookies |

• Key: markdown link to the Jira issue. Use the Jira base URL from the issue's self field, or a site-configured base (e.g. https://yourorg.atlassian.net/browse/{key}).
• Sprint: active sprint name. Truncate numeric-only names to S{N} if the column gets wide. — if none.
• Type: issuetype name (Task / Story / Bug / Sub-task).
• Pri: shorten long names — P1 Critical → P1, P2 High → P2, etc.
• Status: status name (In Progress / Code Review / Ready for QA / …).
• Updated: relative time since updated (e.g. 2h, 4d).
• Discussion: filled by the latest-discussion lookup below.
• Summary: truncate to ~50 chars.

If no tickets are assigned, show _No open Jira tickets assigned to you._

If the Jira API returns an error, show _Jira unavailable: {error}_ and move on — do not fail the whole skill.

After the table, note whether the tickets span one sprint or multiple. Example: _All 6 in Sprint 42._ or _Spans 2 sprints: Sprint 42 (4), Sprint 43 (2)._ This answers "am I focused or scattered?" at a glance.

Latest Jira discussion

After the assigned-ticket search succeeds, fetch the newest comment for every returned ticket. These calls may run in parallel, but do not skip tickets just because their updated value is old:

mcp__jira__jira_get
  path: /rest/api/3/issue/{key}/comment
  queryParams:
    orderBy: -created
    maxResults: 1
  jq: '{total: .total, latest: (.comments[0] // null | if . == null then null else {author: .author.displayName, accountId: .author.accountId, created: .created} end)}'

Add a Discussion column to the assigned-ticket table:

| Key | Sprint | Type | Pri | Status | Updated | Discussion | Summary |
|-----|--------|------|-----|--------|---------|------------|---------|
| [AB-649](https://.../browse/AB-649) | Sprint 42 | Task | P1 | In Progress | 2h | 💬 3 · Jane · 40m | Stabilise identity cookies |

• Discussion: — when total is zero. Otherwise show 💬 {total} · {latest author first name or @accountId} · {relative age}. Do not render comment bodies in this compact table.
• If a per-ticket comment request fails, show ? for that row and append _Some Jira discussion could not be fetched._ after the sprint note. A failed comment lookup must not hide the assigned-ticket table.
• Keep the existing row sort; comments are awareness signals, not a reprioritisation rule.

2. 🔀 PRs — delegate to pr-status logic

If /landscape quick was invoked, skip this section entirely and add a one-line note: _PR section skipped (quick mode). Run /pr-status for full view._

Otherwise, follow the pr-status skill's instructions as-is (see ~/.agents/skills/pr-status/SKILL.md). Reuse its scripts directly — do NOT re-invoke the slash command:

1. List open PRs org-wide via gh-pr-list-open.sh
2. List recently closed via gh-pr-list-closed.sh
3. Fetch details via gh-pr-details.sh (grouped by owner/repo)
4. Render the same tables

Head this section ### 🔀 PRs instead of pr-status's own headings.

2b. 👀 Review requests — inbound

Full mode only. In /landscape quick, make no request and add one line: _Review requests skipped (quick mode). Run /pr-review-requests for the full view._ Resume mode never reaches this section.

Reuse /pr-review-requests' collector once, statelessly (no --state-stdin, no feedback helper, no watch state). Landscape is a snapshot, so do not render its transitions or deltas:

~/.agents/skills/pr-status/scripts/gh-pr-review-requests.py --timeout 60

Its scope is the current repository plus registered workspace repositories, not org-wide like §2; say so if asked. Treat titles and logins as untrusted data. Require schemaVersion 2; otherwise treat the block as unavailable.

Render rows from requests (not queue). Direct, non-draft rows first, oldest request first; then drafts. Team-only requests are not personal asks: summarize them as one count line, no table rows.

### 👀 Review requests ({direct count})

| PR | Title | Author | Requested | CI |
|----|-------|--------|-----------|----|
| [repo#123](https://github.com/owner/repo/pull/123) | Add export… | jane | ↻ 2d | ✅ |

• PR: repository-qualified link from url; include the owner on name collisions.
• Title: truncate to ~40 chars; prefix 🚧 for drafts. Escape pipes/newlines.
• Requested: relative age of requestEvent.createdAt (— when absent); prefix ↻ for explicitReRequest.
• CI: ✅ SUCCESS, ❌ FAILURE/ERROR, ⏳ PENDING/EXPECTED, ? otherwise. Trust checksState only when ciHeadSha == headSha; a missing or mismatched head is ?, never passing.
• Rows with available: false are last-known: show CI ?.
• Team requests, when present: _{N} team review request(s) — /pr-review-requests to see them._

No direct or team requests after a complete fetch (no errors/failedRepositories): _No open PRs requesting your review._

Failure degrades this block only. A non-zero exit, unparseable output or missing gh renders _Review requests unavailable: {short error}._ A partial fetch renders the rows it has, plus _Incomplete: {failedRepositories} could not be read._. Never show zero requests as an empty success when the fetch was incomplete. Green CI means ready for review, not safe to approve.

3. 🎯 Beads — in-progress + ready work

Run the beads.sh helper. It probes for bd, checks for .beads/ in the repo, and emits in-progress + ready listings as delimited sections. Do not call bd directly from this skill — always go through this script:

~/.agents/skills/landscape/scripts/beads.sh

Output sections (delimited by ---<NAME>---):

• ---STATUS--- — OK, NO_BD (bd not installed), or NO_BEADS_IN_REPO (no .beads/ here)
• ---IN-PROGRESS--- — output of bd list --status=in_progress (only if STATUS=OK)
• ---READY--- — JSON array from next-bd --json (or plain text from bd list --ready fallback) (only if STATUS=OK)

If STATUS is NO_BD, render _Beads not installed — skipping._ and skip this block only. If STATUS is NO_BEADS_IN_REPO, render _No beads in this repo._ and skip this block only. Continue to Working copy; a missing tracker must not end orientation. Otherwise render the tables below.

In-progress beads

**In progress ({count})**
| ID | Pri | Type | Labels | Title |
|----|-----|------|--------|-------|

• Include a Labels column. Show — if none.
• If no in-progress beads: show _No in-progress beads._
• These are tracker claims; session activity and ownership are unverified, not implied by status.

Ready beads — sorted by sprint

The ---READY--- section is a JSON array (from next-bd --json). Each item has id, title, priority, issue_type, and rank.

Step 1 — Extract Jira keys. For each bead, scan title for the first match of [A-Z]+-\d+. If no match, the bead has no Jira link.

Step 2 — Batch Jira sprint lookup. If any keys were found, call:

mcp__jira__jira_get
  path: /rest/api/3/search/jql
  queryParams:
    jql: key in ({comma-separated keys})
    fields: summary,status,issuetype,priority,customfield_10020
    maxResults: 50
  jq: issues[*].{key: key, status: fields.status.name, sprint: fields.customfield_10020}

For each ticket's sprint array, pick the active sprint (first with state=="active"). If none active, pick the earliest future sprint (lowest startDate with state=="future"). If neither, treat as no-sprint.

Step 3 — Sort and cap. Bucket order: active sprint(s) → future sprints (by startDate) → no-sprint (has Jira key) → no Jira link. Within each bucket preserve the rank order from next-bd. Cap the total at 5 beads. If more exist: _+{N} more — run /next sprint to see all._

Step 4 — Render. One table:

**Ready ({shown} of {total})**
| # | ID | Pri | Type | Jira | Sprint | Status | Title |
|---|----|-----|------|------|--------|--------|-------|

• # is display order, not a selectable /next index (the rows were sprint-sorted). To start a task, suggest /next <owner-qualified selector>, never claim it from landscape.
• Jira column: markdown link [KEY](https://yourorg.atlassian.net/browse/KEY). Show — if no Jira key.
• Sprint column: number + state suffix only (31 (active), 32 (future)) — strip the project prefix from sprint names like "PROJ Sprint 31". Show — if no sprint or no Jira.
• Status column: Jira status. Show — if no Jira.
• If no ready beads at all: _No ready beads. Run /triage to add work._
• If the ---READY--- section is not valid JSON (fallback plain text): render it as-is, capped at 5 lines.
• If the Jira call fails: render the table without Jira/Sprint/Status columns; add a footnote _Jira unavailable._

4. 📍 Working copy

Rendered LAST because it's the most immediate context — the branch you're sitting on right now, what needs committing/pushing, and whether it's in sync.

Run the working-copy.sh helper, which emits delimited sections for branch, repo toplevel, dirty status, ahead/behind, last commit, and on-branch stash count:

~/.agents/skills/landscape/scripts/working-copy.sh

Output is grouped by ---SECTION--- markers. Parse and render from that.

Pick the mode first

This section has two shapes, chosen by comparing working-copy.sh's ---TOPLEVEL--- against multirepo.sh's ---ROOT--- (§4b runs in parallel; you have both before rendering):

MARKER != none alone is not enough to pick the workspace shape. multirepo.sh resolves the workspace from inside a member repo too (its sibling .mgit.conf child-directory step), so a member repo also reports marker=mgit. Only TOPLEVEL == ROOT means "sitting at the root". Inside a member repo the field table is the most load-bearing block on the page — it's the feature branch you're on — so never collapse it there.

Mode: single repo (or inside a member repo)

Render:

### 📍 Working copy

| Field | Value |
|-------|-------|
| Branch | fix/AB-649-device-cookie-combined |
| Dirty | clean _(or: 3 modified, 1 untracked)_ |
| vs upstream | ✅ in sync _(or: ⬆ 2 ahead, ⬇ 1 behind)_ |
| Last commit | `abc1234` commit subject (2h ago) |

Notes:

• If @{u} fails (no upstream), show no upstream tracking.
• If output is empty for dirty, show clean.

Mode: workspace root (§4a)

At the root, the field table is redundant and misleading, so it is replaced — not supplemented — by a single table over every member repo:

• multirepo.sh already emits the root as its own row, so the field table re-renders data §4b would show anyway. Rendering both forces ad-hoc dedup the skill never specified, and the row gets dropped inconsistently.
• The fields are structurally uninteresting at a root: it holds no feature branches, no upstream is often permanent by design (a deliberately local workspace repo), and its dirt is usually infra noise (.envrc, editor config).
• Worse, §4b's "only members with something to report" rule suppresses the root row — so "which branch am I on, is my cwd clean" could vanish from the page entirely.

Render one table from multirepo.sh's ---REPOS---, in emitted order (root first), including clean members — at the root the full inventory is the point:

### 📍 Working copy — {N} repos in this workspace

| Repo | Branch | Unpushed | Behind | Uncommitted |
|------|--------|----------|--------|-------------|
| `workspace` 📍 | main | local-only | — | 2 untracked |
| `repos/web-app` | main | 0 | — | ✅ clean |
| `repos/docs` | main | 2 | — | ✅ clean |

• {N} is the member count (rows emitted, root included).
• Repo: the {name} field. Append 📍 to the root row — that's where you're standing.
• Branch: the {branch} field. Do not abbreviate; a member sitting on an unexpected branch is a real signal.
• Unpushed: {ahead}, or local-only when upstream=no (never pushed — for a deliberately local repo this is the intended state, not a warning).
• Behind: {behind} when >0, else —. When diverged (ahead>0 AND behind>0) it needs a rebase/pull before it can push — flag it in this cell: 🔶 diverged — N ahead / M behind.
• Uncommitted: {modified} modified / {untracked} untracked, omitting zero parts; ✅ clean when both are zero.

Then skip §4b entirely — this table is §4b, promoted. Carry the most urgent member (diverged, then unpushed, then uncommitted) into §5 exactly as §4b specifies.

Extras — both modes

These come from working-copy.sh and have no equivalent in the roll-up, so they render under either mode. In workspace-root mode they describe the root repo (the 📍 row); scope them explicitly so that reads unambiguously.

• Stashes: do NOT include a stash row in the table. Only surface stashes if there are stashes on the current branch. If non-empty, add a one-line footnote below the table:

  ⚠️ {N} stash(es) on this branch — run `git stash list` to review.

  Global stash count is not interesting — omit it.
• Other worktrees: the OTHER-WORKTREES-UNSAFE section lists only worktrees (excluding the current one) that have uncommitted changes or unpushed commits. If empty, render nothing — worktrees that are clean and pushed are not interesting. If non-empty, add a footnote below the table:

  ⚠️ Other worktrees with unsaved work:
  - `/path/to/other` on `fix/X` — 3 modified, 2 unpushed

  Omit the dirty/unpushed parts that are zero (e.g. 3 modified alone, or 2 unpushed alone).

• Recent handoffs for this repo: probe ~/.agents/handoffs/ via:

  ~/.agents/skills/handoffs/scripts/list.sh --summary-only

  Parse from the output:

  • ---STORAGE--- → when legacy or mixed, the counts include read-only handoffs from the retired ~/.claude/handoffs; add one line _Handoff storage migration pending (legacy handoffs are listed read-only)._. When partial, say a handoff location could not be read, so the counts may be incomplete.
  • ---SUMMARY--- → current_repo_recent_live — recent handoffs for this repo that are still live work: not superseded and not finished (uses the same Mon→3 / Tue→4 / else→3 weekend buffer as the closed-PR list). "Finished" here means all referenced beads are closed — a local bd check that runs even on this offline (--summary-only, no --check-branches) call, so a handoff whose task shipped no longer counts as a live thread to resume. Re-wraps of the same branch still collapse to one. (Merged-PR / Jira-Done detection needs the network and only applies under /handoffs's --check-branches; landscape's offline count catches the bead-closed case.)
  • ---CURRENT-REPO-LATEST--- → a single {slug}|{branch}|{date} line for the newest current-repo handoff (the "last session"), or empty if none.
  • ---CURRENT-REPO-LIVE--- → one {slug}|{branch}|{date}|{time} line per recent live (non-superseded, non-finished) current-repo handoff, newest first (these are the threads behind the current_repo_recent_live count). The first line equals ---CURRENT-REPO-LATEST--- when the newest handoff is itself still live; if the newest one is finished it's absent here, so the first line is the most recent resumable thread instead.

  If current_repo_recent_live > 0, render its own table (N = current_repo_recent_live) — a footnote got lost among the other tables, so give it the same ### {emoji} {Name} + table shape as the sections above:

  ### 📥 Recent handoffs ({N} live, last {RECENT-WINDOW-DAYS}d)
  
  | Handoff | Branch | When |
  |---------|--------|------|
  | `{slug}` 📍 | `{branch}` | {age} |
  | `{slug}` | `{branch}` | {age} |
  
  _`/handoffs` to browse and resume._

  • One row per ---CURRENT-REPO-LIVE--- line, newest first.
  • Handoff: the {slug}. Append 📍 to the row whose {slug} matches the ---CURRENT-REPO-LATEST--- line — that's the last session, the most likely resume target. When the newest handoff is already finished it won't appear here; the first row is then simply the most recent resumable thread, left unmarked.
  • Branch: the {branch}; render — when it is ? or empty.
  • When: relative age of {date} (e.g. today, 2d).
  • Cap at 5 rows (newest first). When N > 5, render the first 5 and replace the caption with _+{N − 5} more — /handoffs to browse._

  • ---SUMMARY--- → workspace_member_handoffs (M) — handoffs owned by workspace member repos, 0 outside a multi-repo workspace. When M > 0, add a second caption line:

    _{M} in workspace members — `/handoffs` to see them._

    Deliberately a raw count, not a live count. Member rows are only classified under --check-branches, which this call does not pass (workspace_classified=0), so every member row arrives unclassified — and unclassified reads as live. Rendering them as a liveness figure would report already-shipped member work as resumable, the exact failure current_repo_recent_live exists to prevent. The count itself is computed on this call regardless of the flag, so it adds no work and no network.

  Suppress the table when current_repo_recent_live == 0 — silence is shorter. But when M > 0, still render the heading and the member caption line alone, with no table:

  ### 📥 Recent handoffs
  
  _17 in workspace members — `/handoffs` to see them._

  From a workspace root the current repo is usually the emptiest one, so an empty count there means "the threads are in the members", not "nothing to resume" — suppressing outright is what made the root's silence misleading. Older, superseded, or finished handoffs are still browsable via /handoffs; this table is just a fresh-work hint, deliberately offline (no --check-branches, so no branch-staleness here). This call can run in parallel with working-copy.sh.

4b. 🗂️ Other repos in this workspace

Only renders in single-repo mode — i.e. when cwd is inside a member repo, where §4's field table covers your branch and this section covers the siblings. At the workspace root, §4a has already absorbed this table; do not render it twice.

working-copy.sh (§4) inspects only the cwd repo (plus its own worktrees). In a multi-repo workspace — mgit services (.mgit.conf) or git submodules (.gitmodules) — that silently misses uncommitted/unpushed state in sibling service repos. This is the single biggest blind spot at session start: you orient on one repo and never notice that, say, dispatch was left with unpushed commits last night. Roll them up:

~/.agents/skills/wrap-up/scripts/multirepo.sh

It emits ---MARKER--- (mgit | submodules | none), ---ROOT---, and ---REPOS--- lines: {name}|{branch}|{ahead}|{behind}|{upstream}|{modified}|{untracked} (ahead/behind are - with no upstream; the root repo appears as its own row). Always run it — §4 needs its ---ROOT--- to pick a mode — and run it in parallel with working-copy.sh. It's the same roll-up /wrap-up §3b uses.

• ---MARKER--- is none → single repo, no workspace; skip this whole section silently (§4 already covered it).
• TOPLEVEL == ROOT → workspace root; skip silently, §4a rendered it.
• Otherwise render only the members with something to report (ahead>0, behind>0, or modified+untracked>0), excluding the cwd repo's own row — §4's field table already covers it in this mode. A clean+pushed member is noise. Skip the table entirely if every other member is clean — in a healthy workspace this section shows nothing, which is the point.

### 🗂️ Other repos in this workspace

| Repo | Branch | Unpushed | Behind | Uncommitted |
|------|--------|----------|--------|-------------|

• Unpushed: {ahead}, or no upstream when upstream=no (local-only, never pushed).
• Behind: show only when >0. A member that's diverged (ahead>0 AND behind>0) needs a rebase/pull before it can push — flag it explicitly: 🔶 diverged — N ahead / M behind.
• Uncommitted: {modified} modified / {untracked} untracked (omit zero parts).

Carry the most urgent member (diverged, then unpushed, then uncommitted) into the §5 Next suggestion — a sibling repo left in that state is exactly what a fresh session forgets.

5. Next step suggestion

After all blocks render, add a short footer with a concrete next step, picked from what's visible. Prefer the most load-bearing single action:

• If the current branch's PR is approved, CI green, 0 threads, clean merge state → suggest merging it (this unblocks stacked PRs).
• If the current branch's PR has unresolved review threads → suggest /review-comments.
• If the current branch's PR is behind main → suggest /rebase main.
• If there is uncommitted work → suggest committing or stashing.
• If a workspace member repo (§4a or §4b) is diverged → suggest rebasing/pulling it before it can block a push (name the repo).
• If a sibling service repo has unpushed commits or uncommitted work → suggest pushing/committing it (name the repo).
• If §2b shows a direct, non-draft review request with ✅ CI → suggest /review-pr owner/repo#N for the oldest one. Someone is waiting on you, so this ranks ahead of picking new work. Never suggest it from team-only, draft, failing, running or unknown-CI rows.

Once those "finish / unblock" actions are clear, the suggestion becomes a pick-what-to-work-on decision. This is the morning "resume a handoff or start fresh?" question — arbitrate it here rather than leaving the user to choose between /handoffs and /next. Use the handoff signals from §4 (current_repo_recent_live and the ---CURRENT-REPO-LATEST--- {slug}|{branch}|{date} line):

• If a recent live handoff is on the current branch (its {branch} equals ---BRANCH---, which in workspace-root mode is the 📍 row's branch — handoffs are recorded per repo, so this stays the cwd repo's branch either way) → strongest resume signal: you're already sitting on its branch and it carries the open threads + suggested next step the bare branch doesn't. Suggest Resume {slug} — /handoffs.
• If exactly one in-progress bead and no current-branch handoff → suggest inspecting that claim (show its owning repository and ID); tracker status is not permission to take it over.
• If nothing decisive above but a recent live handoff exists (current_repo_recent_live > 0) → lead with the handoff and name the fallback in one sentence, e.g. Resume {slug} (last session's thread) via /handoffs — or /next safe for fresh work. A warm thread beats a cold start, but the user keeps the choice.
• If no live handoff and nothing in progress but ready beads exist → suggest /next.
• Otherwise → suggest /triage or pulling a Jira ticket.

Format as one line:

---
**Next:** _{suggestion}_

Single sentence. Pick one action — don't list a menu. The one exception is the handoff-fallback branch above, which deliberately names a single fallback (Resume {slug} … — or /next safe …) so the morning "resume or start fresh?" choice stays visible in one sentence.

Failure modes

Each block is independent — a failure in one must not prevent the others from rendering.

• Not in a git repo: skip the Working-copy block, print _Not in a git repository._ in its place.
• No Jira MCP configured: skip the Jira block, print _Jira MCP not configured._.
• gh not authenticated: skip the PR block, print _GitHub CLI not authenticated (run \gh auth login`)._`; the review-requests block renders its unavailable line.
• No beads in repo: skip the Beads block, print _No beads in this repo._.
• Single repo (no .mgit.conf/.gitmodules): the §4b roll-up emits MARKER=none — skip that block silently; §4 already covers the one repo.
• multirepo.sh fails or emits no ---ROOT---: fall back to §4's single-repo field table. An unknown mode must degrade to the always-valid shape, never to a blank Working-copy block.

Performance notes

• Run the git commands in parallel (single Bash call, or parallel tool calls).
• The PR and review-request sections dominate runtime — that's why /landscape quick skips both. The review-request collector can run in parallel with §2's fetches.
• Don't re-render pr-status's "deltas since last check" — landscape is a snapshot, not a diff.