interface-review

Topics in the source

• Interface review
• The change, not the codebase
• 1. Resolve the change scope first
• 2. With no change, ask rather than invent one
• 3. A diff is not a surface
• 4. Read the removed lines
• 5. Classify every finding
• 6. Hold the change to its stated intent

This skill reviews a change rather than a screen. It resolves the scope, expands the changed files to the surfaces they affect, reads both sides of the diff and classifies every finding. It owns the scope, the classification and the change-scoped report. Domain rules belong to the better- skills. Severity, consolidation, coverage, the cap and the verdict belong to better-interface, which this skill hands the review to. Correctness, tests, security and performance belong to the project's general code review. Name such a concern once, point at that review and drop it. The author is asking "did I make this worse?". Report what the change caused and stay mostly quiet about what it merely touched. Three pre-existing findings is a courtesy; thirty is a different review and one nobody asked for. Read the whole diff before forming an opinion of it. A skimmed diff produces findings about code the next hunk already fixed. The whole invocation is the target, so /interface-review pr 482 reviews pull request 482. Scope resolution holds the accepted targets and how each resolves. With no target supplied, resolve in this order and stop at the first match: 1. HEAD is ahead of git merge-base origin

This is an excerpt. Refer to the complete source and its current requirements.