documenting-code-comments_skill

This skill helps audit, clean up, and improve inline code documentation by enforcing self-documenting code and WHY-focused comments.
  • Shell

3

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill third774/dotfiles --skill documenting-code-comments

  • SKILL.md7.0 KB

Overview

This skill provides practical standards for writing self-documenting code and guidelines for when to add or avoid inline comments. It emphasizes naming, types, and structure first, and reserves comments primarily for explaining intent, edge cases, and external context. Use it when auditing, cleaning up, or improving inline documentation to reduce maintenance overhead and comment drift.

How this skill works

The guidance inspects existing comments for accuracy, relevance, and value, and recommends refactors that make code self-documenting before adding comments. It instructs preserving institutional knowledge during refactors, updating comments when behavior changes, and removing only demonstrably incorrect or obsolete comments. It also defines formats for single-line notes, TODOs, and JSDoc/TSDoc for public APIs.

When to use it

  • When auditing a codebase to remove stale or misleading comments
  • During refactoring to preserve or update important context
  • When writing code that has non-obvious business rules or constraints
  • When documenting workarounds, platform bugs, or external references
  • When deciding whether to add JSDoc/TSDoc for public APIs

Best practices

  • Prefer self-documenting code: clear names, small functions, and types before comments
  • Write comments to explain WHY, not WHAT; skip comments that restate code
  • Preserve comments that capture institutional knowledge or edge-case reasoning
  • Keep TODOs actionable with ticket references and context
  • Use sentence case for single-line comments and JSDoc/TSDoc for public API behavior

Example use cases

  • Refactor a messy function and keep its explanatory comment about a historical workaround
  • Audit a repo to find TODOs without tickets and convert them to actionable tasks
  • Add a comment explaining a non-obvious performance trade-off and its benchmark data
  • Document a browser-specific workaround with a link to the ticket or spec
  • Replace repetitive comments by introducing well-named constants and helper functions

FAQ

When it explains intent, why a decision was made, external constraints, or non-obvious edge cases that tests or types do not capture.

Should I remove comments during refactor?

Only remove comments if they are demonstrably incorrect, document deleted code, or the refactor eliminates the reason for the comment; otherwise preserve or update them.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational