docs(skills): add comments rule to code-quality skill#6091
Open
pawelangelow wants to merge 1 commit into
Open
Conversation
🛡️ Jit Security Scan Results✅ No security findings were detected in this PR
Security scan by Jit
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The rule, in short:
good tests should carry the meaning.
or when the user explicitly asks for more (e.g. complex logic).
on what / why — not how, and not the story of the change
(that belongs in the commit message or PR description).
Motivation
Personal preference, but one worth writing down: comments are often a
code smell. They signal that something isn't clear enough from the
code itself, and an extra mechanism is needed to explain it. There's
a lot of material on this already — the goal here isn't to re-litigate
the debate, it's to be explicit about how this codebase treats them.
We do have comments today, and we'll keep adding them where they earn
their keep. The rule just restricts the broad, reflexive usage and
sets a shape for the ones that do stay: short, plain words, focused
on what the code does or why it has to exist — not how it
works, and not the story of the change.
Note
Low Risk
Documentation-only change to agent skills; no application or runtime behavior is affected.
Overview
Documents comment policy in the
code-qualityagent skill so AI assistants and contributors follow the same bar.The new Comments section says to default to fewer comments, use them only when code or tests can't carry the meaning (or when explicitly requested), and keep any comment short and focused on what/why—not implementation detail or change history. It includes good vs bad TypeScript examples and a short list of anti-patterns (restating names, duplicating tests, obvious block summaries).
The Pre-Commit Checklist gains an item to keep comments minimal and plain-language.
Reviewed by Cursor Bugbot for commit 539143a. Bugbot is set up for automated code reviews on this repo. Configure here.