recall

Recall

A skill named in bold or in backticks, or run as /<name>, is the file ../<name>/SKILL.md beside this skill's directory, and a principle named without its prefix is ../principle-<name>/SKILL.md. Read the file and follow it. Most pstack skills are user-only, so your skill tool cannot load them. Every delegate_task call follows the defaults in the Subagents section of ../poteto-mode/SKILL.md.

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

Your chat history is this project's T3 threads. t3_thread_list enumerates them newest first (includeSubagents: true adds delegated children), t3_thread_search finds them by text, and t3_thread_read reads one as a timeline (view: "activity" includes tool calls).

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 one. Never read another project's transcripts without being asked). State the scope back. Never quietly turn "all" into "recent N".
3. Fan out across your chat history. Page t3_thread_list for this project until it passes the window, drop the current chat plus obvious noise (subagent, eval, and test chats), and split the remaining thread ids into slices, kept in t3_thread_list order (real last activity, never thread id). t3_thread_search is bounded, so its hits are a hint, never the corpus. Spawn parallel delegate_task children on a fast, cheap model from orchestrator_capabilities, one per slice, each with a title naming its slice and its explicit thread ids in the brief. Every brief says "read-only: inspect only, no writes, no git commands" and "Do not delegate", and tells the subagent to t3_thread_read each of its ids, keep only threads on the topic and only their relevant regions, follow nextPosition until hasMore is false, and recover truncated items with itemId plus textOffset. Each returns the same schema, one block per chat: 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 chats, skip the fan-out and search directly. The raw transcripts stay in the subagents. The main thread gets only their findings. Pick each subagent's reasoning level and fast or standard speed for the job, per the Subagents section of the poteto-mode skill.
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.
5. Verify against live state. 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 thread with t3_thread_read (view: "activity", following nextPosition until hasMore is false and recovering truncated items with itemId plus textOffset), not just a summary.
6. 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 thread id 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.