home / skills / ahonn / dotfiles / comment-cleanup

comment-cleanup skill

safe

This skill helps you clean up code comments by removing redundancy and adding essential context to improve maintainability.

npx playbooks add skill ahonn/dotfiles --skill comment-cleanup

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

2.4 KB

---
name: comment-cleanup
description: "Clean up code comments. Use when: improving comment quality, removing redundant comments. Triggers on: 'clean up comments', 'comment cleanup'."
allowed-tools: Read, Edit, Glob, Grep
disable-model-invocation: true
argument-hint: <file_path>
---

# Comment Cleanup

I'll analyze and improve the documentation in the specified file following strategic documentation principles.

## Target File

$ARGUMENTS

## Documentation Philosophy

### Core Principles

1. **Self-documenting code first** - Improve naming and structure before adding comments
2. **Comments capture design intent** - Document WHY, not WHAT (when WHAT is obvious)
3. **Reduce cognitive load** - Make implicit knowledge explicit
4. **Eliminate redundancy** - Never restate what code already makes clear

### What Makes GOOD Comments

- **Design decisions** - Why this approach over alternatives
- **Non-obvious behavior** - Complex logic that isn't immediately clear
- **Interface contracts** - What a function/module does, parameters, returns
- **Important context** - Background information needed to understand
- **Gotchas and edge cases** - Subtle behaviors that could cause issues
- **Dependencies** - How components relate to each other

### What to AVOID

- Redundant comments restating obvious code
- Comments duplicating well-named variables/functions
- Implementation details that are self-evident
- Comments that would become outdated easily

## Analysis Process

1. **Read the file** to understand its purpose and structure
2. **Identify naming improvements** that could make code more self-documenting
3. **Find complex logic** that needs explanation
4. **Locate design decisions** that should be documented
5. **Remove harmful comments** that add noise or are outdated
6. **Add strategic comments** where they reduce cognitive load

## Execution

I will:

1. First read and analyze the target file
2. Suggest and apply naming improvements if needed
3. Remove redundant or misleading comments
4. Add comments only where they:
   - Explain non-obvious behavior
   - Document design decisions
   - Clarify complex algorithms
   - Provide essential interface documentation
5. Ensure all changes follow the "campsite rule" - leave code cleaner than found

The goal is **minimal, high-value documentation** - make code so clear it needs few comments, then add comments only where they capture essential information not expressible in code.

Overview

This skill cleans up and improves code comments in a target file to make documentation high-value and minimal. It prioritizes self-documenting code and captures design intent, removing redundant or misleading comments. The outcome is clearer, lower-noise source files with comments only where they meaningfully reduce cognitive load.

How this skill works

I read the specified file to understand structure, behavior, and intent. I identify redundant or outdated comments, propose naming improvements to reduce the need for comments, and add targeted comments that explain non-obvious behavior, design decisions, interface contracts, and important edge cases. Changes follow the campsite rule: leave the codebase cleaner than found.

When to use it

When comment quality is inconsistent or noisy
Before releasing or open-sourcing code to improve readability
When onboarding new contributors to a project
After refactoring to ensure comments still match behavior
When comments repeat obvious code or contradict implementation

Best practices

Prefer clearer names and structure over explanatory comments
Document why something exists, not what a clear line of code does
Remove comments that duplicate well-named functions or variables
Keep comments short, precise, and tied to design intent
Use comments to record non-obvious tradeoffs, edge cases, and external dependencies

Example use cases

Clean up dotfiles and configuration scripts to make intent explicit
Improve Neovim Lua plugins where complex autocommands or keymaps need rationale
Clarify Nix expressions or build logic with reasoning about choices
Prune outdated comments in tmux or shell helper scripts after refactors
Add interface-level documentation to functions that must be stable across changes

FAQ

Will you change code behavior?

I focus on comments and naming; behavior changes are limited to renames or refactors that improve readability. Any behavioral change is flagged and requires explicit approval.

What kinds of comments will you add?

Only high-value comments: design decisions, non-obvious behavior, interface contracts, dependencies, and known gotchas. I avoid restating obvious code.

How do you decide a comment should be removed?

I remove comments that are redundant with clear code, misleading, or likely to become outdated. If context is necessary, I replace the comment with a clearer name or a concise rationale comment.