Status

/status — Session TLDR

Purpose

A terse, action-oriented snapshot of the current session. Built for the moment you context-switch back and need to know in 15 seconds: did anything ship, what's left, what's next.

Distinct from neighboring skills:

• /recap — long-form structured prose recap
• /checkpoint — persists state to disk so you can resume across sessions
• /status — read-only TLDR. No file writes. No questions back. Just the snapshot.

When to invoke

Trigger on any of these:

• User types /status
• "give me an update", "what's the status", "where are we", "what did we ship"
• "TLDR what just happened", "what's left", "TL;DR"
• User returns after a break and needs to re-orient
• End of a long working session before they switch context

Do NOT trigger when the user is mid-task and the question is about ONE specific thing ("what did the build say?"). That's a direct question, not a status request.

Output format

Always use this exact structure. Markdown tables when useful. Code blocks for commit hashes. Use short sentences.

## TL;DR

### Shipped
- <one-liner per shipped item with commit hash if applicable>

### Committed (this session)
| Hash | Subject |
|---|---|
| `abc1234` | feat(scope): one-line subject |

### Pending (your action)
1. <one specific action the user needs to take>
2. <next user action>

### Pending (my action)
1. <one specific action I should take next>

### Next step
<exactly one sentence saying what should happen next>

If a section has no items, omit the entire section heading. Do not write "N/A" or "None" placeholders.

Terminal state

If, after gathering all signals, you find:

• No work in progress
• No uncommitted changes in the working copy that this session created
• No items left on the active todo list
• No follow-up actions implied by the conversation

…then output exactly this and stop. Do not append anything:

Nothing pending. Ready for new task.

What to gather (in order)

1. Active todo list — read the most recent TodoWrite state from the conversation. Items still pending or in_progress go under Pending. Items completed this session go under Shipped.

2. Git commits this session — run git log --oneline origin/main..HEAD if there's a remote, else git log --oneline -10 and filter to commits the assistant authored. Don't list pre-existing commits the user shipped before this session.

3. Uncommitted working-copy changes — run git status --short. If files were modified/created by the assistant this session but not yet committed, those are "Pending (my action) — commit and push X". If files were modified by the user or a parallel session and are unrelated to this session's work, NOTE them in a "Heads-up" line at the bottom but don't list them as pending.

4. Open questions or decisions — anything the user was asked but hasn't answered, or anything the assistant flagged for the user to confirm. These go under Pending (your action).

5. Implicit follow-ups from the conversation — e.g. "this scaffold needs a pilot customer to validate", "first integration test is deferred", "the broken build gate is pre-existing not mine". Surface as a Heads-up if relevant but don't pad the Pending list with speculative work.

Hard rules

• Be terse. One line per item. No paragraphs.
• No flattery, no preamble. Don't write "Here's your status:" — go straight to the ## TL;DR heading.
• Quote commit hashes verbatim in backticks. Don't invent hashes.
• Quote file paths in markdown link form when referencing specific files: [path/to/file.ts](path/to/file.ts). Click-through saves the user a copy-paste.
• Never say "everything looks good" or "all set" — either there's a Next step or you hit terminal state. Pick one.
• No em dashes. No banned vocabulary (leverage, robust, seamless, unlock, transformative, etc. — see ~/.claude/CLAUDE.md for full ban list).
• One Next step sentence at the end. If everything is genuinely done, that single sentence is the terminal "Ready for new task" line and nothing else follows.

Example output (reference, not template)

## TL;DR

### Shipped
- R046 Customer Intelligence Brief scaffold (skill + template + intake checklist + PRIME docs)
- 7 community skills installed globally, all malware-scanned clean

### Committed (this session)
| Hash | Subject |
|---|---|
| `10123a3` | feat(prime): customer intelligence brief scaffold (R046, REQ-123) |
| `82bbe73` | chore(prime): close R046 — mark released, move folder |

### Pending (your action)
1. Commit the REQ-129 entry in REQUEST-LOG.json (parallel session left it uncommitted)
2. Decide whether to schedule the broken-cloak-gate cleanup as a new REQ

### Next step
You commit the REQUEST-LOG.json housekeeping, then we can start a new task.

And the terminal state example:

Nothing pending. Ready for new task.

Anti-patterns (do not do these)

• ❌ Listing every TodoWrite item that ever existed in the session — only completed-this-session and still-active
• ❌ Speculating about future releases the user didn't actually authorize
• ❌ Writing prose like "We had a productive session today!"
• ❌ Asking the user a follow-up question — this is read-only output
• ❌ Repeating yourself across sections (don't list a commit AND its underlying shipped item AND its release notes — pick one)
• ❌ Producing a status report longer than 25 lines for a normal session

Related

• /recap — when the user wants prose detail, not a TLDR
• /checkpoint — when the user wants state saved to disk for resumption later
• /roadmap — when the user wants project-level status, not session-level