skills.rest
williamthorsen
williamthorsenCOMMUNITY
Explore all skills by this author →
WebsiteGitHub

review-criteria

Defines evaluation criteria and finding classification rules for code review.

1|1|Updated Feb 25, 2026
Search Tags:#static analysis#code review#pull request#test coverage#pr comments#review criteria#finding classification
One-click install
npx skills add https://github.com/williamthorsen/codeassembly --skill review-criteria-williamthorsen
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: review-criteria
Source: https://github.com/williamthorsen/codeassembly/tree/main/packages/agents/content/skills/review-criteria
Command: npx skills add https://github.com/williamthorsen/codeassembly --skill review-criteria-williamthorsen

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often produce inconsistent, noisy, or unactionable feedback. This Skill standardizes how reviewers evaluate changes and classify findings so every comment is actionable, proportionate to risk, and focused on author-introduced code. ## Core Features & Use Cases - Evaluation criteria: Covers correctness, conventions, edge cases, test coverage, clarity, contracts, type safety, and modern patterns, while explicitly skipping lint and formatting issues handled by CI. - Finding classification: Applies the F/W/T/S/R finding scheme with a Legacy suffix for pre-existing issues, plus gates (proposed-change, actionability, insight) that filter out non-actionable observations. - Use Case: When reviewing a pull request, apply these criteria to trace logic through changed code, classify each issue by severity, format findings with repo-relative locations, and map them to PR comment labels like fixme: or warning:. ## Quick Start Review this pull request using the review-criteria skill and classify each finding with the standard finding scheme.

Frequently Asked Questions about review-criteria

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I classify findings in a code review?▼

Classify findings using the F/W/T/S/R scheme: F for defects, W for warnings, T for todos, S for suggestions, and R for recommendations. Pre-existing issues in unchanged code get a Legacy suffix like F1-L instead of a standard finding.

What should a code review focus on besides lint issues?▼

Focus on correctness, unhandled error paths, edge cases like zero values and empty collections, test quality, naming clarity, contract consistency, and type safety. Skip lint and formatting issues since CI linters already catch those.

When should a code review comment be dropped instead of posted?▼

Drop a comment when you cannot name a concrete change you would make, or when the change is not worth making now. Hedged language like 'no action this PR' signals the observation should be recorded as an insight or discarded.

How do I format code review findings as PR comments?▼

Map finding prefixes to descriptive labels: F becomes fixme:, W becomes warning:, T becomes todo:, S becomes suggestion:, and R becomes recommendation:. Legacy findings use labels like legacy fixme: instead of raw IDs.

Should I request tests for deleted code in a review?▼

No. Tests asserting that deleted code or behavior is absent are noise that only fails on verbatim reverts. The deletion is the fix; recommend positive assertions covering the replacement behavior instead.

Related Skills

Explore More Software Engineering Skills→
EpiphyticEpiphytic
7

code-review

Review source code changes for quality issues and improvement opportunities.

Official
Basic
superagent-aisuperagent-ai
76

pr-github-ops

Post Superagent PR security scan findings as inline GitHub review comments via gh CLI.

Official
Advanced
T-ravT-rav
5

test-audit

Audit unit test files for naming, structure, and anti-patterns.

Community
Advanced
aws-samplesaws-samples
18

code-generation

Generate scaffolded code from design documents with contract enforcement.

Official
Advanced