write-comment

Enforces comment-writing conventions for Ruby code in the dd-trace-rb repository.

417|417|Updated Aug 24, 2016
One-click install
npx skills add https://github.com/DataDog/dd-trace-rb --skill write-comment-datadog
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: write-comment
Source: https://github.com/DataDog/dd-trace-rb/tree/main/.claude/skills/write-comment
Command: npx skills add https://github.com/DataDog/dd-trace-rb --skill write-comment-datadog

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases accumulate noisy comments that narrate obvious code, restate types, or duplicate documentation, making reviews harder and comments less trustworthy. This Skill enforces the dd-trace-rb comment conventions so every comment earns its place by explaining why, warning of hazards, or citing external sources. ## Core Features & Use Cases - Comment quality rules: Defines when to write a comment (non-obvious tradeoffs, thread-safety hazards, external citations, field invariants) and what to never write (narration, section banners, type restatements, copy-pasted comments). - Comment removal guidance: Provides rules for reviewing and deleting existing comments, including fixing the underlying defect (renaming, moving types to sig/) rather than just deleting. - Style and ratio checks: Enforces terse one-line comments and a ratio check of roughly one comment per 15 lines of new code, with exemptions for declaration-only blocks and @public_api YARD docstrings. - Use Case: While reviewing a pull request in lib/ or ext/, ask the AI to evaluate whether each new comment follows the repo conventions and to suggest deletions or renames where comments merely narrate the code. ## Quick Start Review the comments in my current diff and tell me which ones violate the repo comment conventions and how to fix them.

Frequently Asked Questions about write-comment

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

FAQPage Schema
How do I write good code comments in a Ruby project?▼

Write comments only when they explain why, not what: non-obvious tradeoffs, workarounds for upstream bugs, thread-safety hazards, or citations of external specs and RFCs. Keep them terse, preferring one line or a fragment over full sentences.

When should I remove an existing code comment?▼

Remove comments that narrate nearby code, restate types, repeat good identifier names, or duplicate docstrings. First fix the underlying defect, such as renaming the identifier or moving type info to sig/ RBS files, before deleting.

Should I write YARD docstrings for public API methods?▼

Yes, @public_api docstrings are exempt from the no-comment default and follow normal YARD conventions with @param, @return, @raise, @example, and @see tags, since they ship as customer documentation. The method body still follows the standard comment rules.

Can I reference internal tickets or wiki pages in code comments?▼

No, comments must only cite external sources a non-Datadog reader can look up, such as specs, RFCs, or public documentation. Internal wikis, Slack threads, JIRA tickets, and incident references are never allowed, even by name.

What is the comment-to-code ratio limit for a diff?▼

A diff should have roughly no more than one comment per 15 lines of new code. Declaration-only blocks like struct field documentation are exempt, since density there does not imply narration.