light-comments

Rewrites code comments and doc blocks to be short and reason-focused.

2|1|Updated Jun 28, 2026
One-click install
npx skills add https://github.com/lxsmnsyc/overwander --skill light-comments-lxsmnsyc
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: light-comments
Source: https://github.com/lxsmnsyc/overwander/tree/main/.agents/skills/light-comments
Command: npx skills add https://github.com/lxsmnsyc/overwander --skill light-comments-lxsmnsyc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases accumulate bloated comments that restate the code, narrate history, and bury the one useful fact. This Skill enforces a consistent commenting style so every comment says something the code cannot. ## Core Features & Use Cases - Comment review and rewriting: Trims doc blocks and inline comments to 1-4 lines focused on the why, cutting history, build-up, and restatement. - Doc block conventions: Keeps /** */ blocks on exported functions, types, and constants that state what the thing is and the one thing a caller could get wrong. - Preservation rules: Keeps lint directives, external links, formulas, and warnings that prevent bugs or data loss verbatim. - Use Case: While reviewing a TypeScript pull request, apply this Skill to condense a ten-line doc block into three lines that state the query reason, the consumer, and the caveat. ## Quick Start Review the comments in this file and rewrite any that restate the code or narrate history into short why-focused notes.

Frequently Asked Questions about light-comments

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write better code comments?▼

Write comments that state the non-obvious reason, constraint, or trap rather than restating what the code does. Keep most blocks to one to four lines, cut history and build-up, and delete comments on code that is already plainly readable.

How long should a doc block be?▼

Most doc blocks should be one to four lines. A block over roughly eight lines needs a real reason to exist, such as a formula, a protocol, a subtle invariant, or a module header.

What should a doc block for an exported function contain?▼

It should answer what the thing is and the one thing a caller could get wrong, not how it works inside. Interface fields get one line each unless the field carries a rule like a default or a stored-empty convention.

When should I delete an inline comment instead of rewriting it?▼

Delete an inline comment when the code is plainly readable and the comment only restates the line. Keep an inline comment only when it explains a line that looks wrong but is actually right.

Which comments should never be trimmed?▼

Keep verbatim any lint directives such as oxlint-disable, external links, formulas, and warnings that prevent a bug or data loss. These carry information that cannot be recovered from the code.