Vaibtan No comments
Scope the review to changed files unless the user names a broader surface.
- Run a read-only reviewer, preferably with the
fastprofile, over comments in scope. It reports file and line, the comment's claim, whether code or a test already expresses it, and one disposition: remove, rewrite as the non-obvious reason, encode in structure, or keep. - Verify every finding against the surrounding code and callers. Reject advice that removes required API documentation, licensing, safety justification, protocol detail, or a real tradeoff.
- Apply the smallest accepted edit. A claimed invariant that matters should move into a type, assertion, lint, test, or API shape when practical.
- Run the relevant formatter, typecheck, lint, or focused test when the comment change affects syntax or generated documentation.
Comments should explain a reason the code cannot express. They should not narrate phases, restate names, preserve deleted approaches, or compensate for confusing structure.