no-comments
cursor/plugins
Remove unnecessary comments and encode constraints by spawning Comment Sicko analysis.
What is no-comments?
Analyzes code comments to identify and remove unnecessary ones while preserving intentional constraints. Use this when you need to clean up comment debt, enforce constraint encoding, and validate that kept comments are genuinely necessary.
- Spawns Comment Sicko subagent to audit comments in your code or diff
- Validates which comments are necessary vs. removable based on scope and intent
- Rejects unsafe deletions: application-code edits, scope escapes, and exception-protected removals
- Fixes trivial accepted flags by deleting dead code paths or updating APIs
- Encodes constraint comments ("do not remove", "talk to X") as type, runtime, test, or CI lint rules
- Reports deletions, restored comments, fixes, and unenforced constraints
How to install no-comments
npx skills add https://github.com/cursor/plugins --skill no-commentsHow to use no-comments
- 1.Run the skill on your code files or a diff against your base branch (default: main)
- 2.Review the Comment Sicko report and accept or reject its findings
- 3.For accepted flags, the skill will fix trivial issues directly or run /architect for complex shapes
- 4.Approve constraint encodings (type, runtime, test, or CI lint) or delete unenforced constraints
- 5.Review the final report of deletions, fixes, encodings, and any open work
Use cases
- Clean up comment debt in a codebase while preserving critical constraints
- Validate that TODO and FIXME comments have actionable reasons before removal
- Encode team constraints ("do not change without approval") as enforceable lint or type rules
- Audit a pull request diff to remove stale comments and fix underlying issues
- Ensure exception-protected code deletions are justified and scoped correctly
- Code reviewers managing comment quality and technical debt
- Teams wanting to encode constraints as lint rules instead of comments
- Developers refactoring code and removing obsolete comments
- Maintainers auditing diffs for unnecessary or misleading comments
no-comments FAQ
Comment Sicko is a subagent that audits comments in your code to identify which are necessary, which are stale, and which encode constraints that should be enforced differently.
It preserves comments about things you cannot change (e.g., external API quirks), correctness/safety suppressions, and scoped lint/TypeScript suppressions—only if they have proof.
No. It rejects application-code edits and scope escapes. It only fixes trivial issues like deleting dead paths or updating API calls for accepted flags.
The skill offers to encode them as type, runtime, test, or CI lint rules instead, then deletes the comment if approved. If not approved, it reports the constraint as open work.
You can reject findings. The skill will rerun with the failure named. A second rejection is reported as open and the command fails.
Full instructions (SKILL.md)
Source of truth, from cursor/plugins.
name: no-comments description: "Spawn Comment Sicko, fix accepted findings, and offer encodings for claimed constraints." disable-model-invocation: true
No comments
Spawn Comment Sicko. Act on accepted findings.
Defer to Comment Sicko's fresh perspective.
Scope
Use the caller's files or diff. Otherwise use the current diff against the base branch, default main, including the working tree.
Steps
- Spawn
Taskwithsubagent_type: "Comment Sicko". Pass the scope. Do not restate its rules. - Inspect its report and diff. Reject application-code edits, scope escapes, exception-protected deletions, misstated
MUST KILLreasons, and flags that treat kept intentional code as guilty. Reshape flags on our-code surprises stay actionable. Do not restore those comments. A keep survives only with proof it is about something we cannot change. Audit missed scoped lint and TypeScript suppressions. Correctness or safety suppressions stay actionableMUST KILLs. Restore deletions only with exact exceptions and scoped proof. Before accepting thinIMPORTANTordo not removekills or keeps, run/howor/whyon their symbol. If a kill is ambiguous, do not restore. If a keep is refuted or still ambiguous, delete it. Revert and rerun one rejected report with the failure named. Reject a second, report it open, and fail/no-comments. - Fix trivial accepted flags directly by deleting a dead path, dropping a parameter, or using the real API. If any fix needs a shape, run
/architectonce for the accepted set and surrounding code. Stop at the sketch. Architect shapes. Step 4 implements. - Implement the smallest root-cause fix in scope. Remove every named workaround. If the root cause is out of scope, land the smallest in-scope fix and report the rest open. The principle-fix-root-causes and principle-redesign-from-first-principles skills guide intent only. Neither authorizes widening the fence nor fixing instances outside it. Never bolt on symptom guards.
- Constraint comments say
do not remove,do not change wording, ortalk to X before changing. Leave keeps about things we cannot change. Offer the cheapest in-scope type, runtime, test, or CI lint. Wait for interactive approval. Unattended and eval require caller pre-approval. If approved, encode then delete. Otherwise delete, report the constraint open, and sketch out-of-scope work. - Report the deletion count, restored comments, reruns, architect sketch, fixes, encoding offers, encodings, unenforced constraints, and other open work.
Related skills
More from cursor/plugins and the wider catalog.

Poteto Mode
Poteto's deliberate agent style: concise responses, simple code, verified work, and rigorous decision-making.

pr-review-canvas
Generate interactive HTML walkthroughs of GitHub PRs with diffs, annotations, and moved-code detection.

principle-boundary-discipline
Concentrate validation at system boundaries; trust internal types and keep business logic pure.

principle-build-the-lever
Build tools (codemods, scripts, generators) to automate non-trivial work instead of doing it by hand.

principle-encode-lessons-in-structure
Encode recurring corrections as lint rules, metadata flags, and runtime checks instead of repeating instructions.

principle-exhaust-the-design-space
Explore 2-3 competing prototypes before committing to novel UI or architectural decisions.