cc-plugin

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.

Use when the user invokes /fast-forward to land a finished feature branch (or its worktree) onto the local main/master branch as a fast-forward of its logically grouped, changelog-worthy commits. Commits any outstanding work, syncs and rebases onto the local trunk, regroups the history into a few reviewable commits whose messages read as public changelog entries, fast-forwards them onto the trunk with no merge commit, then deletes the branch and removes its worktree. User-invoked only; local only, never pushes; irreversible and destructive.

Use when the user invokes /pr to open a pull request for the current branch. Commits any outstanding work, runs the project's linters and tests, pushes the feature branch, and opens a PR against the repo's default branch with a conventional-commit title and a factual, diff-grounded description. User-invoked only.

Use when the user invokes /cleanup-branch to repackage the current branch's commits into fewer, logically grouped, reviewable commits without changing the resulting code. Creates a backup branch first, verifies the regrouped tree is byte-for-byte identical to the original, prints the new commit list, and offers to delete the backup. Local only; never pushes. User-invoked only.

Use when the user invokes /squash to collapse a finished feature branch or worktree into a single commit on main. Commits any outstanding work, squash-merges the whole branch into one conventional commit on the local main/master branch, then deletes the branch and removes its worktree. User-invoked only; this is an irreversible, destructive workflow.

Use when the user asks to refactor, restructure, reorganize, extract, simplify, deduplicate, or "clean up"/"make this more readable"/"break this apart" any code, in any language, even when they don't say "refactor" explicitly. Keeps refactoring behavior-preserving and disciplined rather than freeform editing.

Use when building, reviewing, or auditing web UI for accessibility, including ARIA roles, keyboard navigation, focus management, color contrast, form labeling, target sizes, or WCAG 2.2 compliance. Also use when the user mentions a11y, screen readers, semantic HTML, focus traps, alt text, or asks "is this accessible", even if they do not say "accessibility" explicitly. Especially relevant when working on htmx fragments or daisyUI components.

Complete guide for building UIs with daisyUI v5 and Tailwind CSS, components, forms, theming, and responsive design. Use when building any user interface with daisyUI or Tailwind CSS, implementing UI components (buttons, cards, modals, tables, navbars), creating forms (inputs, selects, textareas, validation), configuring themes, or migrating from daisyUI v4 to v5. Also use when the user mentions daisyUI class names like btn, card, fieldset, input, select, or any daisyUI component patterns.

Build Python applications using Tortoise ORM v1.x, the async Python ORM inspired by Django. Use when writing or modifying Tortoise Model definitions, queries, relations (ForeignKeyField, ManyToManyField, OneToOneField), transactions, signals, validators, Pydantic integration, or Tortoise initialization. Also use when the user mentions Tortoise ORM, tortoise-orm, async ORM with asyncpg/asyncmy, fields.ForeignKeyField, fields.ManyToManyField, prefetch_related, select_related, Tortoise.init, RegisterTortoise, tortoise.contrib.pydantic, or any Tortoise ORM patterns, even if they don't explicitly say 'Tortoise.' Covers the full lifecycle, model definition, CRUD, relations, querying, transactions, signals, migrations, testing, and Pydantic serialization.

Build Python web applications with Flask 3+, using the application factory pattern and Blueprints. Use when developing Flask projects — blueprint structure, routes, authentication, error handling, working with sessions, implementing forms, configuring flask extensions, Jinja2 templates, CLI commands, logging, security, and deployment. Also use when the user mentions Flask routes, blueprints, app factory, Flask-Login, Flask-WTF, or any Flask extension, even if they don't explicitly say "Flask development."

Use when writing, debugging, or reviewing htmx attributes (hx-get, hx-post, hx-swap, hx-target, hx-trigger, hx-boost), AJAX interactions, server-side HTML fragment responses, out-of-band swaps, htmx events, loading indicators, or hypermedia-driven patterns. Also use when the user mentions htmx class names like htmx-indicator, htmx-request, or any hx-* attributes, even if they don't explicitly say "htmx."

Ideate and critique data visualizations using Edward Tufte's principles from "The Visual Display of Quantitative Information." Use this skill when: (1) Designing new data visualizations or charts (2) Critiquing or improving existing visualizations (3) Reviewing dashboards or reports for graphical integrity (4) Deciding between visualization approaches (5) Reducing chartjunk or improving data-ink ratio (6) Planning small multiples or high-density displays Applies principles: data-ink ratio, chartjunk elimination, graphical integrity, lie factor, small multiples, and data density.

Use whenever writing or editing Python code in a project that depends on the `nclutils` package. Trigger on any `import nclutils` or `from nclutils.*` line, and whenever about to hand roll filesystem operations, subprocess/shell calls, console output, interactive prompts, case conversion, ISO timestamps, or git automation

Analyze GitHub Actions failures and identify root causes. Use when asked to investigate a CI/CD GitHub Actions failure and recommend a fix.