code-commenting

Guide when and how to write comments across source code languages.

59|12|Updated Feb 26, 2026
One-click install
npx skills add https://github.com/etylsarin/opencastle --skill code-commenting
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-commenting
Source: https://github.com/etylsarin/opencastle/tree/main/src/orchestrator/skills/code-commenting
Command: npx skills add https://github.com/etylsarin/opencastle --skill code-commenting

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill reduces noisy, redundant, and misleading comments by teaching when to avoid comments, when to explain rationale, and how to document public APIs so code remains readable and maintainable.

Core Features & Use Cases

  • Decision framework for whether to comment, refactor, or rename to make code self-documenting.
  • Examples and anti-patterns that show obvious, redundant, and outdated comments to avoid.
  • Annotation tags and checklist for TODOs, FIXMEs, performance, security notes, and public API documentation suitable for code review and authoring workflows.

Quick Start

Apply the code-commenting guidelines to a function or module and rewrite comments to explain the reasoning and constraints rather than restating what the code does.

Frequently Asked Questions about code-commenting

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

FAQPage Schema
What is the best way to write code comments that explain why instead of what?▼

The best way to write code comments is to document rationale, constraints, and public APIs rather than restating what the code does. Use a decision framework to determine when to refactor or rename instead of adding redundant comments.

How do I identify and avoid code comment anti-patterns during code review?▼

To avoid code comment anti-patterns during code review, look for obvious, redundant, and outdated comments. Apply a pre-commit quality checklist to ensure comments only document reasoning, TODOs, FIXMEs, and security notes.

When should I add comments to complex logic versus refactoring the code?▼

You should add comments to complex logic when explaining rationale and constraints, but refactor or rename variables when the code can be made self-documenting. Use a decision framework to distinguish when comments are necessary versus misleading.

What annotation tags should I use for documenting public APIs?▼

For documenting public APIs, use annotation tags for TODOs, FIXMEs, performance, and security notes. This ensures the API constraints and reasoning are clear during development and review workflows.

Can I apply code commenting guidelines across different programming languages?▼

Yes, you can apply code commenting guidelines across languages for authoring and reviewing source code. The principles of distinguishing why versus what and avoiding redundant comments remain consistent regardless of the programming language.