writing-code-comments

Reviews and rewrites code comments to explain why rather than restate what the code does.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill writing-code-comments
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: writing-code-comments
Source: https://github.com/PostHog/posthog-foss/tree/main/.agents/skills/writing-code-comments
Command: npx skills add https://github.com/PostHog/posthog-foss --skill writing-code-comments

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Codebases accumulate low-value comments that restate the code, record change history, or contain stale measurements, which mislead readers and add maintenance noise. This Skill gates every comment before it is written or edited so only comments that explain a non-obvious why survive.

Core Features & Use Cases

  • Comment gating: Applies a single test—what does this tell a reader that the code cannot—and deletes narration, change-history notes, perishable measurements, commented-out code, and redundant docstrings.
  • Keep criteria: Preserves comments that explain a non-obvious why, warn about non-local consequences, or point to external context like specs and tickets.
  • Style rules: Enforces explicit technical writing, ASD-STE100 Simplified Technical English, no em-dashes, and density matching the surrounding file.
  • Use Case: While reviewing a diff that adds # increment the counter above counter += 1 and # per PR #1234, the Skill flags both for deletion and suggests a better variable name instead.

Quick Start

Review the comments in my pull request diff and remove or rewrite any that restate the code instead of explaining why.

Frequently Asked Questions about writing-code-comments

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

FAQPage Schema
How do I decide whether a code comment should exist?

Ask what the comment tells a future reader that the code itself cannot. If it only restates what the code does, delete it and improve the name or extract a function instead. Keep it only when it explains a non-obvious why.

What types of code comments should be deleted?

Delete narration that restates code, change-history and chat-context notes like "per PR #123" or "AI:", perishable measurements and "currently" stamps, commented-out code, and docstrings that repeat the function name in prose.

When is it acceptable to keep a code comment?

Keep comments that explain a non-obvious why such as a workaround or ordering constraint, warn about consequences elsewhere in the system, or point to context a reader cannot reconstruct, like a spec or ticket link.

Does this apply to all programming languages?

Yes, the rules apply to comments in Python, TypeScript, Go, Rust, and SQL, and to any diff review that adds comments. It does not cover user-facing copy or commit messages, which follow separate conventions.

Are numeric values ever allowed in comments?

Numbers stay when they are dated snapshots, restate an adjacent code literal, cite a platform constant, state a target or budget, or link to cited evidence. Bare measured timings rot silently and should be replaced with the durable relationship.