Stats
Actions
Tags
'%20stop-opacity%3D'0.16'%2F%3E%3Cstop%20offset%3D'1'%20stop-color%3D'rgb(200%2C90%2C60)'%20stop-opacity%3D'0.03'%2F%3E%3C%2FlinearGradient%3E%3C%2Fdefs%3E%3Crect%20width%3D'320'%20height%3D'200'%20fill%3D'url(%23g)'%2F%3E%3Ccircle%20cx%3D'250'%20cy%3D'56'%20r%3D'92'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.06'%2F%3E%3Ccircle%20cx%3D'64'%20cy%3D'172'%20r%3D'58'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.05'%2F%3E%3C%2Fsvg%3E)
From rust-toolkit
This skill should be used when the user asks to "explain a clippy lint", "what does <lint-name> mean", "explain clippy::<lint>", or wants the official rationale and example code for a specific clippy lint rule.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rust-toolkit:explainThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Explain a clippy lint rule.
Explain a clippy lint rule.
If the user provided a lint name (e.g. needless_return, redundant_closure, clippy::unwrap_used), run:
cargo clippy --explain <lint_name>
Strip the clippy:: prefix if present — the explain command expects just the lint name.
Display the full output: what the lint catches, why it matters, and example code.
If no lint name is provided, run clippy on the current directory to show active warnings:
cargo clippy -- -W clippy::all 2>&1
Then offer to explain any of the reported lints.
If the user provides multiple lint names, explain each one sequentially.
This skill is forward-looking: the canonical triage procedure lives in skills/diagnostic-review/SKILL.md and is invoked via Skill(skill: "rust-toolkit:diagnostic-review") with pass: explain CODE. Per-pass invocation wiring lands in a later chore (per the Path B cut-scope decision); for now the skill body above inlines the procedure that matches the legacy /explain command behavior.
npx claudepluginhub zaynram/code-marketplace --plugin rust-toolkitGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Synthesizes the current conversation into a structured spec (PRD) and publishes it to the project issue tracker with a ready-for-agent label, without interviewing the user.