Enhance /status with health indicators, stale detection, team mode, and quick-win improvements

[sebastientaggart]

Problem to Fix

The /status skill provides a basic summary of open PRs, merged PRs, and upcoming issues, but it lacks several pieces of context that developers need to make quick decisions: whether CI checks are passing or failing on open PRs, whether reviewers have requested changes, whether PRs have merge conflicts, whether work has gone stale, and what the team-wide picture looks like. There is also no distinction between draft and published PRs, no at-a-glance summary counts, and no visibility into PRs waiting for your review.

Why it Matters

Developers and team leads waste time clicking through GitHub to answer questions that /status should surface instantly. A PR with failing checks or requested changes needs immediate attention but looks identical to one awaiting first review. Stale work silently rots. Team leads have no single-command way to see the full picture for standups. These gaps reduce the value of /status as a decision-making tool.

General Approach

Enhance the /status skill prompt with seven improvements:

1. PR health indicators — show CI check status and review decision on every open PR
2. Stale work detection — flag PRs and issues not updated within a configurable threshold
3. Team mode (--team) — aggregate view of all open PRs and issues grouped by person
4. Draft PR indicator — distinguish draft PRs from published ones
5. Summary counts line — scannable one-liner at the top of personal mode output
6. PRs requesting your review — new section showing PRs where your review is pending
7. Merge conflict indicator — warn when open PRs have conflicts

All changes are in the skill prompt file. A new STALE_DAYS config key is added for the staleness threshold.

Complexity

Verification / QA effort: significant
Each enhancement adds new output sections, formatting rules, and edge cases (no stale items, no team members, draft-only PRs, etc.) that need to be verified across personal, milestone, and team modes.

Acceptance Criteria

• Open PRs in personal and team modes show check status (passing/failing/pending) and review decision (approved/changes requested/awaiting review)
• Items not updated within the configured stale threshold are flagged with age context
• /status --team shows all open PRs and issues grouped by person with health indicators
• Draft PRs display a visible draft badge distinct from published PRs
• Personal mode output begins with a summary counts line
• A "Review requested" section appears when there are PRs awaiting the user's review
• Open PRs with merge conflicts show a conflict warning badge
• Empty sections are still omitted (no empty headings)
• Milestone mode in-progress items also show health indicators

[sebastientaggart]

Agent Implementation Notes

All seven enhancements modify one primary file: skills/status.md. Two config files get minor additions. After editing, ./sync.sh propagates to all adapter files.

Files to change

File	Change
skills/status.md	All 7 enhancements (primary source)
.codecannon.yaml	Add STALE_DAYS: "14" to config
config.schema.yaml	Document STALE_DAYS key

Enhancement details

1. PR health indicators (Step 2 + Step 4 + Step 5)

• Add reviewDecision,statusCheckRollup,updatedAt,mergeable,isDraft to open PRs gh pr list --json fields in Step 2
• Step 4: derive check status per PR: all checks COMPLETED+SUCCESS = passing; any FAILURE = failing; otherwise pending. Derive review badge: APPROVED = approved, CHANGES_REQUESTED = changes requested, else awaiting review
• Step 5: append badges to each "In progress" item line
• Step M2: add same --json fields to the milestone PR fetch; show badges on milestone in-progress items

2. Stale work detection (new Step 4b + Step 5)

• Use updatedAt (already fetched) to flag items older than {{STALE_DAYS}} (default 14)
• Add stale badge inline on affected items
• Add a "Stale" summary section at the bottom listing all stale items with last-updated dates
• Works in personal and team modes; omitted in milestone mode

3. Team mode (new Steps T1-T3)

• Parse --team flag in Step 1; mutually exclusive with --milestone
• Step T1: fetch all open PRs and open issues without author/assignee filter (with full health fields)
• Step T2: group by person (PR author / issue assignee); classify same as personal mode; flag stale
• Step T3: output grouped by person with counts header, health badges, stale flags
• Unassigned issues get their own group at the bottom
• No "What's next" section in team mode

4. Draft PR indicator (Step 2 + Step 5)

• isDraft already added to --json fields in enhancement 1
• Show [draft] badge before health indicators on draft PRs

5. Summary counts line (Step 5)

• Add one-line summary after heading in personal mode
• Omit zero-count segments

6. PRs requesting your review (new Step 2 query + Step 5 section)

• New parallel query in Step 2: gh pr list --search "review-requested:@me" --state open
• New "Needs your review" section between "Done" and "Up next"
• Only shown in personal mode with subject=@me
• Feed count into summary line and What's Next logic

7. Merge conflict indicator (Step 2 + Step 5)

• mergeable already added to --json fields in enhancement 1
• Show conflicts badge on PRs where mergeable is CONFLICTING

Key decisions

• Health badges use emoji prefixes for scannability, consistent with existing compass in What's Next
• --team is mutually exclusive with --milestone and username arguments
• Stale detection uses updatedAt not createdAt — activity resets the clock
• "Needs your review" only appears for @me
• STALE_DAYS defaults to 14 if not configured; set to 0 to disable stale detection

[sebastientaggart]

Resolution

The /status command now shows much richer information at a glance: each open PR displays whether CI checks are passing or failing, whether reviewers have approved or requested changes, whether the PR is a draft, and whether it has merge conflicts. Work that hasn't been touched in 14 days (configurable) is automatically flagged as stale. A new "Needs your review" section surfaces PRs waiting for your feedback, and a new --team flag gives team leads a full picture of everyone's open work in one command. A summary counts line at the top makes the output scannable at a glance.

See #107 for full technical details.