메뉴
Use when writing, fixing, or editing comments or documentation in any language, especially commented-out code, stale docs, metadata comments, TODO banners, redundant comments, or unclear comment value.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when checking code for functional correctness, backwards compatibility, logic errors, security vulnerabilities, performance issues, or missing test coverage — not style.
Use when reviewing code, pull requests, branches, diffs, or changed files for quality, correctness, security, performance, and style issues.
Use when writing, fixing, editing, or refactoring TypeScript, Python, React, or CSS code. Not for PR or diff reviews — use clean-code-reviewer for those.
Use when naming or renaming identifiers in any language, especially cryptic names, ambiguous parameters, type or scope encodings, misleading side effects, or requests for clearer names.
Use when writing, fixing, or editing code in any language with duplicated logic, magic values, unclear one-liners, mixed responsibilities, clutter, arbitrary code, or inconsistent abstraction levels.
Use when writing, fixing, or editing Python async flows, coroutines, asyncio tasks, retries, timeouts, cancellation, shared mutable state across awaits, race conditions, or flaky async tests.
| name | clean-general-comments |
| description | Use when writing, fixing, or editing comments or documentation in any language, especially commented-out code, stale docs, metadata comments, TODO banners, redundant comments, or unclear comment value. |
Comments shouldn't hold metadata. Use Git for author names, change history, ticket numbers, and dates. Comments are for technical notes about code only.
If a comment describes code that no longer exists or works differently, delete it immediately. Stale comments become "floating islands of irrelevance and misdirection."
# Bad - the code already says this
i += 1 # increment i
user.save() # save the user
# Good - explains WHY, not WHAT
i += 1 # compensate for zero-indexing in display
If a comment is worth writing, write it well:
# DELETE THIS
# def old_calculate_tax(income: float) -> float:
# return income * 0.15
Who knows how old it is? Who knows if it's meaningful? Delete it. Git remembers everything.
The best comment is the code itself. If you need a comment to explain what code does, refactor first, comment last.
Good comments and docstrings usually explain constraints, surprising trade-offs, external contracts, or why an obvious-looking alternative is wrong.