Update to pstack

{
  "description": "Reconstruct recent working context from prior conversations, remembered context, and connected project sources, then give a concise current-state brief. Use for 'recall my work on X', 'catch me up', 'what have I been working on', 'where did I leave off', or before resuming earlier work.",
  "included_files": [],
  "name": "recall",
  "skill_md_contents": "---\nname: recall\ndescription: \"Reconstruct recent working context from prior conversations, remembered context, and connected project sources, then give a concise current-state brief. Use for 'recall my work on X', 'catch me up', 'what have I been working on', 'where did I leave off', or before resuming earlier work.\"\n---\n\n# Recall\n\nReconstruct the user's working context before they resume something.\n\nThe goal is not a transcript summary. Work out what the user was trying to achieve, what changed, what is true now, what remains unresolved, and what they should do next.\n\nUse this skill for questions like:\n\n* \"Recall my work on X.\"\n* \"Catch me up.\"\n* \"Where did I leave off?\"\n* \"What have I been working on?\"\n* \"What was the state of this project?\"\n* \"What should I pick up next?\"\n* \"We worked on this before. Where were we?\"\n\nKeep the answer focused on the requested work.\n\n## Use the context ChatGPT actually has\n\nUse the best available evidence.\n\nThis may include:\n\n* the current conversation\n* relevant prior conversation context available to ChatGPT\n* remembered user context\n* connected GitHub repositories\n* issues and pull requests\n* connected project trackers\n* documents\n* email or team communication when relevant and available\n* other connected sources that contain the current state\n\nDo not pretend you can access a conversation, repository, document, or service that is unavailable.\n\nIf the user already supplied a good state summary, use it instead of reconstructing the same information again.\n\nDo not ask them to repeat details that are already available.\n\n## Work out what kind of recall they want\n\nThere are two common cases.\n\n### Project recall\n\nThe user names a project, feature, bug, ticket, repository, or other target.\n\nExamples:\n\n* \"Catch me up on Parking Edge.\"\n* \"Where did we leave MFO-347?\"\n* \"Recall the pricing work.\"\n* \"What happened with that authentication bug?\"\n\nFor project recall, combine previous working context with the current project state.\n\n### Activity recall\n\nThe user asks what they have been doing over a period.\n\nExamples:\n\n* \"What did I work on this week?\"\n* \"What have I been doing lately?\"\n* \"Catch me up on yesterday.\"\n\nFor activity recall, focus on the user's work history during that period.\n\nDo not drag unrelated project history into an activity recap.\n\n## Set the scope\n\nRespect the scope the user gives you.\n\nThat may include:\n\n* a project\n* a feature\n* a ticket\n* a repository\n* a time period\n* a particular problem\n\nIf they say \"recent\", use roughly the last seven days unless the conversation makes another range more sensible.\n\nIf they say \"all\", do not silently reduce it to recent activity.\n\nIf the topic is clear, proceed without asking for clarification.\n\nIf several unrelated projects share the same name or reference, clarify only when choosing the wrong one would materially change the answer.\n\n## Reconstruct the working thread\n\nFind the important pieces of the previous work.\n\nFor each relevant thread, recover:\n\n* what the user wanted\n* decisions that were made\n* work that was completed\n* work that was started but not finished\n* problems encountered\n* corrections to earlier assumptions\n* rejected approaches\n* PRs, tickets, branches, documents, or other artifacts\n* the last meaningful state\n\nDo not reproduce the conversation turn by turn.\n\nCompress repeated discussion into the decision that survived.\n\nIf the user changed direction, use the later decision as the current one and mention the earlier approach only when it explains something important.\n\n## Check the shared project record\n\nWhen the user names a feature, bug, repository, issue, PR, or subsystem, previous conversation history is only part of the answer.\n\nCheck connected project sources when available.\n\nUseful sources include:\n\n* GitHub PRs\n* GitHub issues\n* commits\n* Linear or another tracker\n* design documents\n* incident reports\n* relevant team discussion\n* CI or deployment state\n\nLook for what happened after the previous conversation too.\n\nA PR may have merged.\n\nA ticket may have closed.\n\nA fix may have been reverted.\n\nA new bug may have appeared.\n\nSomeone else may have changed the same code.\n\nUse the `why` skill when the shared record needs deeper historical investigation.\n\n## Distinguish history from current state\n\nSomething being true in an old conversation does not make it true now.\n\nTreat these as history:\n\n* \"PR is open.\"\n* \"Ticket is in progress.\"\n* \"Branch has not merged.\"\n* \"We still need to implement X.\"\n* \"This bug is unresolved.\"\n\nWhen the answer matters and a connected source can verify the current state, check it.\n\nPrefer current project state over remembered status.\n\nFor example:\n\n```text\nPrevious state:\nPR #42 was waiting for review.\n\nCurrent state:\nPR #42 has since merged.\n```\n\nDo not present stale history as current truth.\n\n## Preserve decisions\n\nA useful recall answer tells the user what was decided.\n\nExamples:\n\n```text\nUse Ubuntu Server, not Desktop.\n```\n\n```text\nMender handles production OTA. Cloudsmith is optional for package distribution.\n```\n\n```text\nThe POS records cash or card but does not integrate with a payment terminal in the MVP.\n```\n\nDo not bury decisions inside a chronological retelling.\n\nIf a decision was tentative, say so.\n\nIf it was later reversed, give the current decision.\n\n## Preserve corrections\n\nCorrections matter because they stop the user from repeating dead ends.\n\nInclude them when relevant.\n\nFor example:\n\n```text\nOriginally we planned to modify the existing sidebar. That was changed.\nThe ticket now requires a brand-new sidebar component with feature parity.\n```\n\nOr:\n\n```text\nThe first fix was merged but did not solve the production issue, so a new ticket replaced it.\n```\n\nDo not include every disagreement. Keep corrections that affect the next piece of work.\n\n## Find unresolved work\n\nSeparate finished work from open work.\n\nLook for:\n\n* unmerged PRs\n* open tickets\n* unanswered questions\n* known bugs\n* deferred decisions\n* follow-up work\n* dependencies\n* tests or verification that still need to happen\n\nDo not revive something merely because it appeared in an older conversation.\n\nIf later evidence shows it was completed, treat it as completed.\n\n## Identify the next move\n\nEnd with one concrete next action when there is a clear one.\n\nGood:\n\n```text\nNext: start MFO-331. Its dependencies are merged and the ticket is ready.\n```\n\nGood:\n\n```text\nNext: upload the updated plugin bundle and verify that the six adapted skills pass scanning.\n```\n\nWeak:\n\n```text\nNext: continue development.\n```\n\nIf several tasks can start independently and the user asked what is available, list those instead.\n\nDo not manufacture a next step when the work is already finished.\n\n## Handle incomplete memory\n\nSometimes the available context is not enough.\n\nSay what you can establish and what you cannot.\n\nFor example:\n\n```text\nI can recover the design decision and the open PR, but I do not have access\nto the conversation where the migration plan was finalized.\n```\n\nThen use available connected sources to fill the gap when possible.\n\nDo not invent missing decisions because they fit the surrounding story.\n\n## Resolve contradictions\n\nPrevious conversations and current project sources may disagree.\n\nWhen they do, prefer current evidence for current state.\n\nPreserve the contradiction if it explains how the project changed.\n\nFor example:\n\n```text\nWe originally treated #21 as the next implementation ticket. That is stale.\nIt has since merged, and #24 is now the first unblocked ticket.\n```\n\nIf two current sources disagree, show the disagreement rather than choosing one without evidence.\n\n## Keep adjacent work out\n\nA nearby ticket, feature, or project does not belong in the recall unless it:\n\n* blocks the requested work\n* changed the requested work\n* explains a decision\n* is the obvious next step\n\nThe user asked to recover a working context, not everything you know about them.\n\n## Output\n\nFor a substantial project recall, use this shape when it helps.\n\n### Capsule\n\nAt most five bullets.\n\nCover:\n\n* what the work is\n* the goal\n* the important design decisions\n* where it currently stands\n\n### Threads\n\nGive one compact line for each active or recently completed thread.\n\nUse a status when you can establish one, such as:\n\n```text\n[merged #35]\n[open PR #41]\n[in progress]\n[done]\n[blocked]\n[planned]\n[reverted]\n```\n\nDo not invent PR numbers, branches, or statuses.\n\n### Problems\n\nInclude only recurring or unresolved problems that matter to resuming the work.\n\nPreserve failed fixes or reverted approaches when repeating them would waste time.\n\nKeep this short.\n\n### Next move\n\nGive the single most useful next action.\n\nFor a simple recall question, do not force this structure. A few paragraphs may be enough.\n\n## Activity recap\n\nFor questions like \"what did I work on this week?\", group related work rather than recounting every conversation.\n\nPrefer:\n\n```text\nParking Edge\n\nYou finished the paid-exit flow, worked through the POS and rate-card\ntickets, then moved onto deployment and fleet management. The deployment\ndirection settled on Ubuntu Server with Mender.\n```\n\nover:\n\n```text\nMonday you asked X.\nThen you asked Y.\nThen on Tuesday you asked Z.\n```\n\nMention dates only when they help establish sequence or scope.\n\n## Evidence\n\nUse concrete references when available.\n\nExamples:\n\n* PR number\n* issue number\n* Linear ticket\n* commit\n* document\n* prior decision\n* connected-source citation\n\nDo not expose private internal context that the user did not ask for.\n\nDo not claim a status is current unless you have current evidence or make clear that it comes from previous context.\n\n## Writing\n\nApply `unslop` to the answer.\n\nKeep the recap compact.\n\nUse the project's real names and terminology.\n\nPrefer decisions and current state over chronology.\n\nDo not narrate how you searched for the context.\n\nDo not repeat the user's entire history.\n\nGive them enough context to continue working without reopening old conversations.\n\nReply with the brief itself.\n"
}