no-comments
Review scoped code comments and replace them with clearer code or an ADR candidate when they carry a fundamental decision. Use before review or when comments obscure the implementation.
- License 许可
- MIT
- 最近更新
- 2026-11-11
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- no-comments
- metadata
- { "author": "Brenden Bishop", "attribution": "../../ATTRIBUTION.md" }
- description
- Review scoped code comments and replace them with clearer code or an ADR candidate when they carry a fundamental decision. Use before review or when comments obscure the implementation.
- disable-model-invocation
- true
03 SKILL.md 正文
No comments
Inspect the caller's files or diff. If no scope is given, use the current change. Do not expand into unrelated code.
Find code comments, commented-out code, and suppressions in that scope. Remove narration and dead code. Where a comment explains behavior, improve names, data shape, or function boundaries until the code is clear without it. Investigate a suppression before removing it; fix the underlying cause and keep type and lint checks valid. Do not delete required license or generated-file notices as a style cleanup.
If a comment records a fundamental architecture choice that the code cannot express, consult the architecture decision process. Most explanations do not meet the ADR threshold. Do not create an ADR just to move a comment somewhere else.
Use a fresh delegate for an independent pass only when the host supports one and the scope warrants it. Pass this skill and the exact files to the delegate; no named Cursor agent or model is required. Review its findings against the code before editing. Do not claim independent review if none ran.
Run the relevant check after changes. Report what was removed or clarified and any comment or suppression that remains for a specific reason. Do not widen the task merely because a comment hints at another problem.
04 同仓库更多 Skills
why
Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.
unslop
Cut AI tells from any writing. Must always apply.
typescript-best-practices
TypeScript best practices. Use when reading or editing any .ts or .tsx file.
technical-writing
Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for /technical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.
teach
Explain a body of work plainly so a person actually understands it. Runs the `how` and `why` skills and weaves what they find into one clear explanation. Use for 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'.
tdd
Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.