recall

• SKILL.mdcore · 5,357 bytes
• SKILL.mdcore · 5,357 bytes
• SKILL.mdcore · 5,357 bytes
• SKILL.mdcore · 5,357 bytes

# 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.**

Keep it tight and on-topic. Read only what the in-scope threads need, then stop.

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 threads alone.

Chat history lives in T3 threads. `t3_thread_search` finds them by topic and `t3_thread_read` reads one, scoped to the active project.

1. 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.
2. 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 project. Never read another project's threads without being asked). State the scope back. Never quietly turn "all" into "recent N".
3. Fan out across your chat history. Use `delegate_task` with `mode: "async"` to spawn parallel workers on the `how explorer` role, each taking a slice of the corpus. Every brief stands alone, since the worker gets only the brief and never your context. It must say read-only, inspect only, no writes. Tell every worker to order candidates by real last-activity time and never by thread ID, run `t3_thread_search` on the topic first and then `t3_thread_read` only the matching threads and only their relevant regions, and skip the current thread plus obvious noise (delegated-task, eval, and test threads). Each returns the same schema, one block per thread: topic, the user's goal, decisions, open threads, struggles and corrections, and artifacts (PRs, tickets, branches), each citing the thread ID. For one or two threads, skip the fan-out and search directly. Drain with `task_status`. The raw threads stay in the workers. The main thread gets only their findings.
4. Sweep the shared record whenever the topic names a feature, file, subsystem, area, or bug. This is the default, not a judgment call, and "my work on X" does not exempt it. Hand it to the **why** skill's source investigators, but steer their question from "why was this built this way" to "what's the current state, what's been tried and didn't hold, and what are users still reporting". Reuse its per-source playbooks, run the investigators in parallel with the chat-history mining, and inherit its posture: one investigator per source, null results are findings, skip an unavailable MCP and say so. Fold what comes back into the brief. Skip this step only for pure activity recall with no named target ("what did I do this week"), where your own history and live state are the entire answer.