Commenting Intent

Guides writing code comments that explain intent and decisions rather than restating mechanics.

Updated Dec 4, 2025
One-click install
npx skills add https://github.com/dallascrilley/dowser --skill commenting-intent-dallascrilley
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: Commenting Intent
Source: https://github.com/dallascrilley/dowser/tree/main/skills/commenting-intent
Command: npx skills add https://github.com/dallascrilley/dowser --skill commenting-intent-dallascrilley

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code comments often just restate what the code already shows, adding noise instead of value. This Skill teaches you to comment WHY code exists—decisions, trade-offs, and non-obvious reasoning—instead of WHAT it does. ## Core Features & Use Cases - Intent-First Commenting: Explains the four things worth commenting: non-obvious decisions, algorithm trade-offs, magic number sources, and workarounds with issue references. - Anti-Pattern Detection: Shows concrete before/after examples of over-commenting obvious code and restating standard patterns like loops and assignments. - The Comment Test: Provides a three-question checklist to decide whether each comment should be kept, deleted, or replaced with clearer code. - Use Case: During code review, when asked to add more comments, apply this Skill to document why Redis was chosen for rate limiting and where the 100 req/min limit came from, rather than narrating each line. ## Quick Start Review the comments in my code and rewrite them to explain intent and decisions instead of restating what the code does.

Frequently Asked Questions about Commenting Intent

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

FAQPage Schema
How do I write good code comments?▼

Good code comments explain WHY the code exists, not WHAT it does. Document non-obvious decisions, algorithm trade-offs, magic number sources, and workarounds with issue references, while deleting comments that merely restate the code.

When should I add comments to code?▼

Add comments when a future maintainer would ask why this approach was chosen: unusual algorithms, business rule origins, constants derived from testing or SLAs, and workarounds for library bugs. Skip comments on obvious assignments and standard patterns.

What comments should I delete from my code?▼

Delete comments that restate the code, such as narrating loops, assignments, or standard patterns like binary search boundaries. If the comment adds no information beyond the code itself, remove it or improve the code's clarity instead.

Does this commenting approach work for all programming languages?▼

Yes, the intent-first commenting principles apply to all languages, as stated in the skill metadata. The examples use Python, but the WHY-over-WHAT rule is language-agnostic.

How do I document magic numbers in code?▼

Annotate each magic number with its source: testing results, SLA guarantees, incident reports, or business requirements. For example, note that a retry count of three handles 99.9% of transient failures based on testing.