菜单
Apply the BaseCode Removing Comments practice — delete what- and how-comments, improve names in their place, and keep only why-comments that explain non-obvious constraints.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Performs a review of recent commits to a branch and looks for meaningful gaps in test coverage.
Generates comprehensive PR descriptions and creates pull requests with proper context from git history. Invoke with /pr.
Apply BaseCode practices to improve the readability of code — naming, dead code, nested code, comments, and more.
Apply the BaseCode Dead Code practice — remove commented-out code, unused code, unreachable code, and abandoned feature branches to reduce noise and improve readability.
Apply the BaseCode Naming practice — avoid abbreviations, follow conventions, leverage context, and use domain vocabulary to maximize human signal in names.
Apply the BaseCode Nested Code practice — flatten structure using guard clauses, conditional boolean returns, and higher-order functions to bring the primary action to the top level.
| name | basecode:removing-comments |
| description | Apply the BaseCode Removing Comments practice — delete what- and how-comments, improve names in their place, and keep only why-comments that explain non-obvious constraints. |
Apply the BaseCode Removing Comments practice to improve the readability of the code under review. The goal is not shorter code or personal style — it is readability: making the code easier for the next human to read.
Every inline comment is a cost to the reader. Remove comments that do not earn their place.
Remove what-comments — any comment that only restates what the next line of code does should be deleted. If the code cannot explain itself, improve the code (rename, extract a method, restructure) rather than add a comment.
Remove how-comments — comments explaining implementation details indicate an opportunity to extract a well-named method or improve naming so the intent is self-evident.
Improve names, then remove the comment — when a comment describes a variable's purpose, use that description as the variable's name and delete the comment.
Keep why-comments — a comment explaining a non-obvious constraint, a workaround, a hidden business rule, or the reason a specific API endpoint was chosen over another has earned its place. Rewrite it in clear English if it is vague or grammatically incorrect.
Apply proximity — move a variable declaration close to where it is first used so the reader does not need a comment to maintain context.
