Recall
Before you start or resume work, you rebuild the user's recent working context and hand back a tight capsule of where things stand now and what to do next. Use for "recall my work on X", "catch me up", "what have I been working on", or "where did I leave off".
Keep it tight and on-topic. Read only what the in-scope threads need, then stop. The heavy reading fans out to parallel subagents. The main thread keeps only their findings and the final brief.
Your context lives in two records. Your own chat history holds what you did and decided. The shared record holds everything that happened around the same code under other names: the symptoms users keep reporting, the fixes that shipped and got reverted, the errors still firing in prod. That second record is what the why skill searches, across source control, the issue tracker, chat and issue channels, long-form docs, and error tracking. A feature with a long bug tail keeps most of its story there, so don't reconstruct it from your transcripts alone.
Resolve scripts/find-transcripts.mjs relative to this SKILL.md. Run it with node, --host claude, and --workspace set to the active workspace to list this workspace's transcripts. The helper reads JSONL cwd metadata, matches the workspace path exactly, and sorts results by modification time. It does not inspect another workspace's message content.
- Classify, then route. One specific prior chat to resume is the
session-pickup playbook, not this. Turning habits into a durable skill is automate-me. A human-readable summary of your work is a different task. Recall loads working context across recent chats before you act. If the user already gave you a full state capsule (paths, branch, the change), use it and skip the mining.
- Lock the scope before searching. Pin the window ("recent" is a real range, default the last 7 days), the topic if named, and the workspace (default the active one; never read another project's transcripts without being asked). State the scope back. Never quietly turn "all" into "recent N".
- Fan out across your chat history. Spawn parallel subagents on a fast, cheap model, each taking a slice of the ordered paths returned by the helper. Tell every subagent to grep the topic first, then read only matching chats and their relevant regions. Skip the current chat plus obvious noise such as subagent, eval, and test chats. Each returns the same schema, one block per chat: topic, the user's goal, decisions, open threads, struggles and corrections, and artifacts such as PRs, tickets, and branches. Cite each chat UUID. For one or two chats, skip the fan-out and search directly. The raw transcripts stay in the subagents. The main thread gets only their findings.
- Follow shared records when a linked issue, incident, or unresolved historical question affects the requested brief. Use the why skill's relevant source playbook. Do not sweep every source merely because the task names a feature or file. Stop when the requested context is recovered or no useful accessible lead remains.
- Verify against live state. A transcript or a stale ticket is history, not current truth, so take the PRs, branches, and tickets that the mining and the sweep surfaced and check them with
git and gh. When the answer hinges on what an agent actually did (the tools it ran, files it read, errors it hit), read the full transcript, not just a trimmed local copy.
- Write the brief to the contract below. Group by thread. Stay on the named topic.
Output contract
Lead with the capsule, then the thread status, then the problems, then the next move. Deeper detail goes below or gets cut.
- Capsule. At most 5 bullets. What this work is and where it stands overall.
- Threads. One line each, prefixed with exactly one status tag:
[merged #N], [open PR #N], [in flight <branch>], [verified, uncommitted], [reverted #N], or [planned, not started]. A thread with no tag is not done yet, so tag it.
- Problems. At most 5, the recurring ones. Include the symptoms users keep reporting and any fix that shipped and was reverted, so the next attempt starts where the last one failed.
- Next move. The single most useful next action, concrete.
An adjacent feature or ticket stays out unless it blocks this one. When the capsule and thread lines outgrow a screen, cut detail before you cut threads. Write the brief through the unslop skill, cite chat findings by UUID and shared-record findings by their source (PR #, ticket ID, chat permalink, error-tracker issue), and sanitize private context before any public output.
Reply: the brief, to the contract above.
1---2name: recall3description: Recover recent work and open decisions from relevant task history when the user asks to recall or resume work.4---56# Recall78**Before you start or resume work, you rebuild the user's recent working context and hand back a tight capsule of where things stand now and what to do next.** Use for "recall my work on X", "catch me up", "what have I been working on", or "where did I leave off".910Keep it tight and on-topic. Read only what the in-scope threads need, then stop. The heavy reading fans out to parallel subagents. The main thread keeps only their findings and the final brief.1112Your context lives in two records. Your own chat history holds what you did and decided. The shared record holds everything that happened around the same code under other names: the symptoms users keep reporting, the fixes that shipped and got reverted, the errors still firing in prod. That second record is what the **why** skill searches, across source control, the issue tracker, chat and issue channels, long-form docs, and error tracking. A feature with a long bug tail keeps most of its story there, so don't reconstruct it from your transcripts alone.1314Resolve `scripts/find-transcripts.mjs` relative to this `SKILL.md`. Run it with `node`, `--host claude`, and `--workspace` set to the active workspace to list this workspace's transcripts. The helper reads JSONL `cwd` metadata, matches the workspace path exactly, and sorts results by modification time. It does not inspect another workspace's message content.15161. Classify, then route. One specific prior chat to resume is the `session-pickup` playbook, not this. Turning habits into a durable skill is `automate-me`. A human-readable summary of your work is a different task. Recall loads working context across recent chats before you act. If the user already gave you a full state capsule (paths, branch, the change), use it and skip the mining.172. Lock the scope before searching. Pin the window ("recent" is a real range, default the last 7 days), the topic if named, and the workspace (default the active one; never read another project's transcripts without being asked). State the scope back. Never quietly turn "all" into "recent N".183. Fan out across your chat history. Spawn parallel subagents on a fast, cheap model, each taking a slice of the ordered paths returned by the helper. Tell every subagent to grep the topic first, then read only matching chats and their relevant regions. Skip the current chat plus obvious noise such as subagent, eval, and test chats. Each returns the same schema, one block per chat: topic, the user's goal, decisions, open threads, struggles and corrections, and artifacts such as PRs, tickets, and branches. Cite each chat UUID. For one or two chats, skip the fan-out and search directly. The raw transcripts stay in the subagents. The main thread gets only their findings.194. Follow shared records when a linked issue, incident, or unresolved historical question affects the requested brief. Use the **why** skill's relevant source playbook. Do not sweep every source merely because the task names a feature or file. Stop when the requested context is recovered or no useful accessible lead remains.205. Verify against live state. A transcript or a stale ticket is history, not current truth, so take the PRs, branches, and tickets that the mining and the sweep surfaced and check them with `git` and `gh`. When the answer hinges on what an agent actually did (the tools it ran, files it read, errors it hit), read the full transcript, not just a trimmed local copy.216. Write the brief to the contract below. Group by thread. Stay on the named topic.2223## Output contract2425Lead with the capsule, then the thread status, then the problems, then the next move. Deeper detail goes below or gets cut.2627- **Capsule.** At most 5 bullets. What this work is and where it stands overall.28- **Threads.** One line each, prefixed with exactly one status tag: `[merged #N]`, `[open PR #N]`, `[in flight <branch>]`, `[verified, uncommitted]`, `[reverted #N]`, or `[planned, not started]`. A thread with no tag is not done yet, so tag it.29- **Problems.** At most 5, the recurring ones. Include the symptoms users keep reporting and any fix that shipped and was reverted, so the next attempt starts where the last one failed.30- **Next move.** The single most useful next action, concrete.3132An adjacent feature or ticket stays out unless it blocks this one. When the capsule and thread lines outgrow a screen, cut detail before you cut threads. Write the brief through the **unslop** skill, cite chat findings by UUID and shared-record findings by their source (PR #, ticket ID, chat permalink, error-tracker issue), and sanitize private context before any public output.3334**Reply:** the brief, to the contract above.
shiwenbin1617