status

status

Purpose

Give the user a quick, readable read-out of the session so far: what's been accomplished and what's still outstanding. This is a stock-taking skill, not a closing skill. It is the lightweight counterpart to /end.

This skill is user-level (~/.claude/skills/status/), so it is available in every repo automatically.

How it differs from /end

• /status is read-only. It does NOT store entities, file tasks, write memory, invoke store-neotoma, or render the 🧠 Neotoma turn report. It just reports. (Read-only retrieval of an existing plan is allowed — see Project-aware mode — but it never writes.)
• /end is the closing audit — it files and persists. Reach for /end at the natural close of a session; reach for /status any time mid-session to check in.

Whole-session coverage (read the transcript when context is partial)

/status must report on the whole session, not just the portion currently in context. Long sessions get compacted: the active context window may hold only a recent slice (a pre-compaction summary plus the last few turns), so reporting from context alone silently under-represents earlier work.

Before composing the report, decide whether context is whole-session or partial. Treat it as partial whenever any of these hold:

• A compaction/summary boundary is present in context (a "This session is being continued…" summary block, or an injected session-summary).
• The session spans multiple days or many turns.
• The user signals the read-out missed earlier work.

When partial, reconstruct the full arc from the transcript before reporting:

1. Locate the transcript JSONL — by identity, not recency. Resolve the path in this strict order, stopping at the first that yields exactly one file:
   1. The exact path named in the compaction/summary block in context (it almost always states it verbatim) — use it directly.
   2. The harness-provided session id (e.g. a <session-id> / transcript path in environment context) → ~/.claude/projects/<project-slug>/<session-id>.jsonl.
   3. Only if neither is available: list ~/.claude/projects/<project-slug>/*.jsonl. If exactly one exists, use it. Do not silently pick "the most recently modified" when several exist — a concurrent or prior-day session in the same project would make recency select the wrong file. If multiple remain and none can be disambiguated by the session id, treat it as transcript unresolved (see the not-found handling below) rather than guessing.
2. Do not read the whole file into context — it can be multiple MB. Extract a skeleton deterministically: parse the JSONL line by line; keep entries where type/role is user and the text does not match ^\s*<(system-reminder|command-name|command-message|local-command); drop tool_result content entirely; drop standalone "Continue from where you left off." lines; optionally keep short assistant summary lines. The "filter out tool_result" rule targets the tool_result content type, not user-pasted log/test output inside a genuine user message — keep the latter. This yields the session's request arc in a few hundred chars.
3. Compose Achieved / Remaining from that whole-session skeleton, not just the in-context tail.