菜单
Write a consume-once handoff of the current session's working state into this project's recall store, so the next session picks up where this one left off. Most useful right before /compact or /clear. The next fresh session (compact, clear, or startup) injects the handoff and then deletes it.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when the user invokes /prune-comments to clean up inline code comments in the current changes. Reviews the uncommitted working-tree changes (or the branch-vs-trunk diff when the tree is clean), then deletes redundant what-comments, tightens verbose ones, and keeps genuine why-comments, leaving noqa/type:ignore and other tooling directives untouched. Edits the working tree in place and does not commit. User-invoked only.
Use when the user wants to understand a code change, diff, branch, or PR at the level of concepts and features rather than lines — the pieces that come together to make the whole change, explained across the files they touch. Trigger on requests like "explain this PR", "walk me through this branch", "help me understand what this change does", "what's going on in this diff", or reviewing an agent's work before merging. Produces a rich, self-contained HTML explainer (plain markdown on request).
Triage and curate this project's persisted recall backlog - validate the open items against the current repo, apply the resulting fixes (close finished work, remove obsolete items, correct drifted ones), then rank what remains by impact and effort to recommend what to do next. Pass --clean to apply removals automatically instead of confirming them.
Review and curate this project's persisted memory store - deduplicate learnings, prune stale entries, correct frontmatter, and close resolved backlog items. Pass --clean to apply the changes automatically instead of proposing them.
Use when writing, updating, editing, rewriting, reviewing, or improving user-facing documentation, including README files, CHANGELOGs, release notes, setup or install guides, API references, onboarding docs, contributing guides, and similar prose meant to help someone understand or use a project. Trigger on requests like "update the docs", "rewrite the README", "fix the documentation", "document this", "add a setup guide", "polish this README", "review my docs", "the docs are out of date", or any task that produces or edits prose explaining how to install, configure, or use the project. Always invoke this skill when documentation is being created or revised, even when the user does not say "documentation" explicitly. Covers writing standards including clarity, user-focused framing, and avoiding common AI writing patterns that erode reader trust.
Use when authoring, building, configuring, or reviewing documentation with the Zensical static-site engine. Trigger on any zensical.toml or mkdocs.yml work, running zensical new/build/serve, writing docs/ Markdown pages, or requests to make documentation richer with Mermaid diagrams, admonitions/call-outs, code annotations, content tabs, grids, or icons. Also use whenever writing Markdown that will be published with Zensical, even if the user does not say 'Zensical' by name. Actively reach for these rich elements whenever they make the docs clearer, not only when asked.
基于 SOC 职业分类
| name | recall-handoff |
| description | Write a consume-once handoff of the current session's working state into this project's recall store, so the next session picks up where this one left off. Most useful right before /compact or /clear. The next fresh session (compact, clear, or startup) injects the handoff and then deletes it. |
| disable-model-invocation | true |
Capture where work stands right now into a HANDOFF.md in this project's recall
store. This is a transient baton, not durable memory: SessionStart injects it into the
next fresh session and immediately deletes it. The end-of-session sweep handles durable
learnings separately, so a handoff is for the in-flight task you are about to carry
across a /compact, a /clear, or a new session.
Run the recall path resolver to get the absolute target path. It derives the project's store for you, so never re-derive the path by hand:
${CLAUDE_SKILL_DIR}/../../hooks/recall-path.py --handoff
Use the printed path as the write target below. The store directory may not exist yet; creating it via the Write tool is fine.
If a HANDOFF.md already exists at that path, read it before writing. The user may
be iterating, doing several rounds of work before compacting. Treat the existing file as
prior context and update it in place (carry forward still-relevant goals and notes,
revise progress, add new dead ends) rather than overwriting it blank. Only drop content
that is genuinely resolved or obsolete.
Write the document from the current conversation. Be concrete and specific. Prefer real file paths, command names, and decisions over vague summaries. The point is that a fresh agent with no memory of this session can resume immediately.
Use this structure. Omit a section only when it would be empty (keep Open questions out entirely if there are none):
# Handoff
## Goal
What we're trying to accomplish.
## Current progress
What's been done so far.
## What worked
Approaches that succeeded.
## What didn't work
Dead ends, so they are not repeated.
## Key files
Paths and locations touched, so the next session orients fast.
## Next steps
Concrete, ordered action items.
## Open questions
Decisions still pending. Omit this section if there are none.
Write the composed document to the resolved path with the Write tool, then report in one
line: the path written, and that the next /compact, /clear, or new session will
inject it and then remove it. Do not run /compact yourself; leave that to the user.