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.
Backfill this project's recall memory store from past Claude Code session transcripts, mining prior conversations for durable learnings and deferred work.
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.