Normalize code comments and apply safe non-semantic cleanup

This skill normalizes code comments and performs safe, non-semantic cleanup under a strict prime directive: comments and formatting are the job, logic is never the job. If a change would alter what the code does, not just what it says or how it's arranged, it is out of scope - no matter how obviously correct the fix seems. It runs a six-phase protocol: a full read of the file before any edits, auditing every existing comment into a category (junk/venting, placeholder, dead-code, redundant, outdated, valuable-but-informal, missing), applying narrowly scoped non-semantic cleanup, rewriting or adding comments to a professional standard, verifying the diff is behaviorally identical to the original, and reporting back what changed and why. A separate Security & Safety Notes list makes the boundary explicit: this skill never changes program logic or control flow, never restructures code (extracting/inlining functions, reordering execution, changing architecture), never renames anything public/exported/cross-referenced without explicit confirmation, never deletes a casual-toned comment without first checking whether it carries real information, and never fabricates a rationale it can't actually infer from context.

Use it when the user asks to clean up, professionalize, or polish existing code, when a file has a mix of human and AI-written comments needing one consistent voice, when comments are outdated, missing, redundant, or written casually, or when the user explicitly wants comments improved without touching logic. Do NOT use it to fix a bug, change behavior, do a full rewrite or architectural restructuring, or add new features/functionality - those are different jobs entirely.

Input: an existing code file or module. Output: the same file with comments classified and handled per category - junk/venting comments stripped of tone (real information underneath preserved or deleted if truly empty), placeholders converted to a proper TODO: note or removed if stale, dead-code comment blocks removed unless flagged as an intentional fallback, redundant comments deleted, outdated comments corrected and explicitly flagged as having been stale, and missing docstrings added for complex logic or public APIs. Permitted non-semantic cleanup is narrow: consistent indentation/whitespace/brace style, splitting long lines, removing unambiguous dead code, and renaming only private/local-scope variables (never anything exported or cross-referenced without calling it out first). A closing report states how many comments were touched and why, flags any informal-but-informative comment it preserved, and lists anything it left alone rather than guessing.

Rewritten comments follow the language's idiomatic doc format (JSDoc, Python docstrings, Rust ///, XML doc comments) and match whatever convention is already used in the file. Style rules for the rewritten prose: explain why, not what; be concise with no filler like "This function is responsible for..."; no informal register or first-person asides; no em-dashes; never fabricate a rationale the code itself doesn't reveal.

Developers preparing code for review, handoff, open-sourcing, or documentation who want casual or inconsistent comments professionalized without any risk of a logic change slipping in - and who understand this is a read-through diff check, not a test run, so the actual test suite should still confirm behavior afterward. Ambiguous judgment calls (is this dead code intentional or forgotten?) default to flagging rather than guessing, and comment quality is bounded by what the code's actual intent can be inferred from - if the why genuinely isn't recoverable, the honest output describes what, not an invented why. Large or unfamiliar files raise the risk of missing context in Phase 0, so uncertainty gets flagged in the report rather than presented as a settled rewrite.