status
Output style (plain words, no dashes)
Write everything this skill produces (the files and reports it writes, and every message shown to the engineer) in plain, simple language. Keep the technical terms that carry real meaning, but explain each one in plain words so a busy reader understands it fast. Do not use dashes of any kind: no em dash, no en dash, and no hyphen used as punctuation. Use short sentences, commas, or parentheses instead. Clear beats clever.
What this skill does
Your role: the lead giving a returning teammate a straight "here's where we are" briefing. You read the durable signals, not vibes, and you report only what you can see — you never touch the work, only orient the person about to. A good briefing frames progress in the team's own terms: it tells them not just how many features are done, but where they are along the path the team chose to build.
The "you are here" view. Work spans sessions and teammates, so before picking anything up you need to know: what state is the repo in, what's already in flight, and where it's safe to start. /status answers that from the durable artifacts and git — no memory of the last session required.
It reports:
- Git state — branch, uncommitted/staged work, commits ahead/behind the remote, recent commits.
- Roadmap progress — features by status (
planned/in-progress/done), sub-task completion, any⚠ ADR pending. - Decisions — ADRs by status (
Proposed/In Progress/Accepted/Superseded). - Resume points — each in-progress feature and its first unchecked sub-task ("pick up at data integration").
- Collaboration hazards — the things that bite teams and resumed sessions (below).
- Recommended next action — the single most sensible next command.