[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MSKSXGQ6RFBXB73NEFCVT":3,"skill-same:01M71MSKSXGQ6RFBXB73NEFCVT":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":14,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":50,"updatedAt":51,"install":52,"resources":64},"01M71MSKSXGQ6RFBXB73NEFCVT","recall",null,"Reconstruct your recent working context from your own chat history, live state, and the shared record (user reports, prior fixes, incidents), then hand back a tight current-state brief. Use for 'recall my work on X', 'catch me up', 'what have I been working on', 'where did I leave off', before starting or resuming work.","bbishdotdev\u002Fai-tools","bbishdotdev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5323528?v=4","01M71MHYW2Q0DVZA22Q79M8KER","Brenden Bishop","01M71MHYWSMQWFPGA8CBJYQANH",0,"MIT","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Frecall\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"record","resuming","catch","fixes","for","hand","true","incidents","shared","chat","state","back","reports","up","use","work","history","work on","brief","2026-11-10 10:56:23",false,"---\nname: recall\ndescription: \"Reconstruct your recent working context from your own chat history, live state, and the shared record (user reports, prior fixes, incidents), then hand back a tight current-state brief. Use for 'recall my work on X', 'catch me up', 'what have I been working on', 'where did I leave off', before starting or resuming work.\"\ndisable-model-invocation: true\n---\n\n# Recall\n\n**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.**\n\nKeep it tight and on-topic. Read only what the in-scope threads need, then stop.\n\nYour 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.\n\nTranscripts live at `~\u002F.cursor\u002Fprojects\u002F\u003Cslug>\u002Fagent-transcripts\u002F\u003Cuuid>\u002F\u003Cuuid>.jsonl`, where `\u003Cslug>` is the workspace path with the leading slash dropped and each \"\u002F\" turned into \"-\" (so `\u002FUsers\u002Fyou\u002Fproj` becomes `Users-you-proj`). Every line is one chat message.\n\n1. 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.\n2. 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\".\n3. Fan out across your chat history. Spawn parallel subagents on a fast, cheap model, each taking a slice of the corpus. Tell every subagent to order candidates by real modification time (`ls -t`) and never by UUID name, grep the topic first and then read only the matching chats and only their relevant regions, and skip the current chat plus obvious noise (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 (PRs, tickets, branches), each citing the 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.\n4. 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.\n5. 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 transcript, not just a trimmed local copy.\n6. Write the brief to the contract below. Group by thread. Stay on the named topic.\n\n## Output contract\n\nLead with the capsule, then the thread status, then the problems, then the next move. Deeper detail goes below or gets cut.\n\n- **Capsule.** At most 5 bullets. What this work is and where it stands overall.\n- **Threads.** One line each, prefixed with exactly one status tag: `[merged #N]`, `[open PR #N]`, `[in flight \u003Cbranch>]`, `[verified, uncommitted]`, `[reverted #N]`, or `[planned, not started]`. A thread with no tag is not done yet, so tag it.\n- **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.\n- **Next move.** The single most useful next action, concrete.\n\nAn 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.\n\n**Reply:** the brief, to the contract above.\n","# Recall\n\n**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.**\n\nKeep it tight and on-topic. Read only what the in-scope threads need, then stop.\n\nYour 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.\n\nTranscripts live at `~\u002F.cursor\u002Fprojects\u002F\u003Cslug>\u002Fagent-transcripts\u002F\u003Cuuid>\u002F\u003Cuuid>.jsonl`, where `\u003Cslug>` is the workspace path with the leading slash dropped and each \"\u002F\" turned into \"-\" (so `\u002FUsers\u002Fyou\u002Fproj` becomes `Users-you-proj`). Every line is one chat message.\n\n1. 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.\n2. 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\".\n3. Fan out across your chat history. Spawn parallel subagents on a fast, cheap model, each taking a slice of the corpus. Tell every subagent to order candidates by real modification time (`ls -t`) and never by UUID name, grep the topic first and then read only the matching chats and only their relevant regions, and skip the current chat plus obvious noise (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 (PRs, tickets, branches), each citing the 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.\n4. 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.\n5. 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 transcript, not just a trimmed local copy.\n6. Write the brief to the contract below. Group by thread. Stay on the named topic.\n\n## Output contract\n\nLead with the capsule, then the thread status, then the problems, then the next move. Deeper detail goes below or gets cut.\n\n- **Capsule.** At most 5 bullets. What this work is and where it stands overall.\n- **Threads.** One line each, prefixed with exactly one status tag: `[merged #N]`, `[open PR #N]`, `[in flight \u003Cbranch>]`, `[verified, uncommitted]`, `[reverted #N]`, or `[planned, not started]`. A thread with no tag is not done yet, so tag it.\n- **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.\n- **Next move.** The single most useful next action, concrete.\n\nAn 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.\n\n**Reply:** the brief, to the contract above.\n",{"name":5,"description":7,"disable-model-invocation":43},true,"main","e7c8126d1ad4df934236dba12521dcbe7fcd9d74","bstack\u002Fupstream\u002Fpstack\u002Fskills\u002Frecall","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools","https:\u002F\u002Fgithub.com\u002Fbbishdotdev","bbish.dev","Husband | Father | Technologist\r\nEngineering leader helping product and delivery teams use AI to build better systems, habits, and tools.","2026-11-11 11:13:39",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":43},[54,57,60],{"tool":55,"command":56},"npx","npx skills add bbishdotdev\u002Fai-tools --skill recall",{"tool":58,"command":59},"bunx","bunx skills add bbishdotdev\u002Fai-tools --skill recall",{"tool":61,"command":62},"pnpm","pnpm dlx skills add bbishdotdev\u002Fai-tools --skill recall","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Frecall\u002FSKILL.md",[],[66,96,107,122,154,177],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":77,"publishedAt":38},"01M71MT5NBY3RY660EA06K9CA1","why","Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002FSKILL.md",[72],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[68,78,79,80,81,82,83,84,85,86,87,88,89,90,34,91,92,93,94,95],"how","parallel","observability","warehouse","returns","infrastructure","source","analytics","data","issue","read","tracker","product","design","product analytics","time","error tracking","error",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":38},"01M71MT4CFF7AK4TRV40P7ZZ30","unslop","Cut AI tells from any writing. Must always apply.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Funslop\u002FSKILL.md",[],[98,103,25,104,105,106],"cut","ai tells","apply","writing",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":38},"01M71MT37W015EGE0EB82JQYAM","typescript-best-practices","TypeScript best practices. Use when reading or editing any .ts or .tsx file.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftypescript-best-practices\u002FSKILL.md",[],[114,115,116,33,117,118,119,120,25,121],"typescript","typescript best practices","best practices","tsx","when","editing","file","reading",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":139,"publishedAt":38},"01M71MT1092N34HQMGECW170JP","technical-writing","Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for \u002Ftechnical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftechnical-writing\u002FSKILL.md",[128,133,136],{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":134,"categoryName":135,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":137,"categoryName":138,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000036","内容创作者",[140,106,141,142,143,144,145,146,147,148,118,149,150,33,25,151,124,23,152,153],"technical","technical writing","commit messages","google","syntax","style","structure","layered","english","commit","Rules","messages","pr","standard",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":163,"publishedAt":38},"01M71MSYRMT7KZPQFY7A2ZHGMB","teach","Explain a body of work plainly so a person actually understands it. Runs the `how` and `why` skills and weaves what they find into one clear explanation. Use for 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fteach\u002FSKILL.md",[160],{"categoryNo":161,"categoryName":162,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000039","教师与教育",[156,23,78,164,165,166,34,167,168,169,170,171,33,172,173,25,174,175,68,176],"me","explanation","change","help","one","it","explain","body","teach me","understand","clear","person","find",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":38},"01M71MSWTVAEVMZAG7SMWFE1FE","tdd","Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftdd\u002FSKILL.md",[],[179,33,184,185,186,118,187,25,188,189,190,191,192,23,193,194],"path","user","regression test","only","local","failing","bug","integration","regression","target","test"]