Run any Skill in Manus with one click

prune-comments

Stars0

Forks0

UpdatedJuly 9, 2026 at 14:09

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

natelandau

natelandau/cc-plugin

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	prune-comments
description	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.
disable-model-invocation	true

Prune comments

Clean up the inline comments in the work you have in flight so they explain why, not restate what the code already says. Reach for it any time you want to tidy a change's comments, for example right before you commit.

It edits the working tree in place and stops there. Committing is yours to do, so you can review the edits with git diff first.

What it does

Resolve what "the current changes" are. Look at the working tree, then pick the scope that actually holds the work:
```
git status --porcelain     # is anything uncommitted?
```
- Dirty tree (uncommitted changes present): the scope is that uncommitted work, git diff HEAD plus any new untracked files. This is the common case, where you have been editing and want the comments cleaned before you commit.
- Clean tree: fall back to the current branch's committed changes against its trunk. Establish the trunk (prefer main, else master) and the fork point, and review that range:
```
git merge-base <trunk> HEAD   # fork point; scope is <merge-base>..HEAD
```
- Clean tree on the trunk itself (no branch changes and nothing uncommitted): there is nothing to review, so say so and stop.
Dispatch the comment-pruner subagent (ships with this plugin) to do the work. Tell it the exact scope you resolved above so it reviews the right diff. It reads the changes and edits comments in place, deleting redundant what-comments, tightening verbose ones, keeping genuine why-comments, and never touching noqa/type: ignore or other tooling directives. It edits comments only, never code or docstrings, and returns a short summary. Running it as a subagent keeps the verbose, file-by-file review out of this conversation.

If the subagent is unavailable, do the pass yourself over the resolved diff, applying the same why-not-what rule.
Report and stop. Relay the subagent's summary: how many comments it removed, reworded, and left, and which files it changed. Do not stage or commit anything. Remind the user the edits are uncommitted, so they can review with git diff and commit when ready (comment-only edits fit the style conventional-commit type).

More from this repository

same repository

explain-diff

natelandau/cc-plugin

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).

2026-07-080

recall-backlog

natelandau/cc-plugin

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.

2026-07-080

recall-review

natelandau/cc-plugin

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.

2026-07-080

documentation-writer

natelandau/cc-plugin

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.

2026-07-080

zensical

natelandau/cc-plugin

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.

2026-07-080

recall-bootstrap

natelandau/cc-plugin

Backfill this project's recall memory store from past Claude Code session transcripts, mining prior conversations for durable learnings and deferred work.

2026-06-280

name	prune-comments
description	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.
disable-model-invocation	true

Prune comments

It edits the working tree in place and stops there. Committing is yours to do, so you can review the edits with git diff first.

What it does

Resolve what "the current changes" are. Look at the working tree, then pick the scope that actually holds the work:
```
git status --porcelain     # is anything uncommitted?
```
- Dirty tree (uncommitted changes present): the scope is that uncommitted work, git diff HEAD plus any new untracked files. This is the common case, where you have been editing and want the comments cleaned before you commit.
- Clean tree: fall back to the current branch's committed changes against its trunk. Establish the trunk (prefer main, else master) and the fork point, and review that range:
```
git merge-base <trunk> HEAD   # fork point; scope is <merge-base>..HEAD
```
- Clean tree on the trunk itself (no branch changes and nothing uncommitted): there is nothing to review, so say so and stop.
Dispatch the comment-pruner subagent (ships with this plugin) to do the work. Tell it the exact scope you resolved above so it reviews the right diff. It reads the changes and edits comments in place, deleting redundant what-comments, tightening verbose ones, keeping genuine why-comments, and never touching noqa/type: ignore or other tooling directives. It edits comments only, never code or docstrings, and returns a short summary. Running it as a subagent keeps the verbose, file-by-file review out of this conversation.

If the subagent is unavailable, do the pass yourself over the resolved diff, applying the same why-not-what rule.
Report and stop. Relay the subagent's summary: how many comments it removed, reworded, and left, and which files it changed. Do not stage or commit anything. Remind the user the edits are uncommitted, so they can review with git diff and commit when ready (comment-only edits fit the style conventional-commit type).