code-review

Name: code-review
Author: testdouble

122stars12forks

How to install code-review?

testdouble/han/code-review

$npx -y skills add testdouble/han --skill code-review

Installs into the current project.

Summary

Run a comprehensive code review on local source files. Use this skill when the user asks to review, audit, inspect, evaluate, or check code, even if they never use the word \"review.\" Does not post comments to GitHub pull requests — use post-code-review-to-pr for that. Does not

Files · 1

View on GitHub

SKILL.md

1	When running a code review, follow the process outlined here.
2
3	## Project Context
4
5	- git installed: !`which git 2>/dev/null \|\| echo "not installed"`
6	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
7	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
8
9	## Review Constraints
10
11	Severity levels:
12	- Critical — Must fix before merge. Security vulnerabilities, data corruption risk, breaking API changes, data isolation failures.
13	- Warning — Should fix. Bugs that don't corrupt data, significant performance issues, missing required tests, missing error handling.
14	- Suggestion — Consider improving. Style improvements, optional performance gains, documentation gaps, refactoring opportunities.
15
16	Severity calibration is governed by Step 3.3 (the authoritative home for size-based demotion). Manual findings from Steps 4 to 6 follow the same size-based rules as agent findings classified at Step 7: Small changes escalate only Critical findings and default uncertain ones to the lower severity, Medium changes escalate Critical and Warning, Large changes prefer the higher severity when in doubt. Read `{size}` from Step 3.1. Include `file_path:line_number` references and code examples for suggested fixes.
17
18	Finding caps: Manual review findings (Steps 4-6) and agent findings (Step 7) are each capped at 30 items. Prioritize by severity: all CRIT first, then WARN, then SUGG. If either cap is exceeded, note that additional items were omitted and another code review is recommended after addressing current items. Security findings are not capped (see classification rubric).
19
20	Project pattern deference: A pattern that differs from general best practices but is consistent within the project is not a review finding. Only flag deviations from the project's own conventions.
21
22	YAGNI findings are a separate, non-correcting class. Apply the two-pass YAGNI procedure documented in [`references/review-checklist.md`](./references/review-checklist.md) (the canonical home for the procedure and the (a)/(b)/(c) recording requirement) to every change in the diff. YAGNI findings are listed in their own `### 🟡 YAGNI` section, separate from Critical / Warning / Suggestion, and do not appear under CRIT / WARN / SUGG. The YAGNI section opens with this exact statement: "These findings will not be corrected unless explicitly requested. They are documented so the team can decide consciously whether to keep, simplify, or defer the items." Severity calibration (the directive in Step 3.3, the authoritative home) does NOT apply to YAGNI; these findings are surfaced regardless of change size and are advisory, not corrective.
23
24	Automated tool boundary: If the project has a linter or formatter, trust it. Only flag style issues that automated tools can't catch.
25
26	Readability standard: The review report is a reader-facing deliverable. As it writes the finding prose and narrative, the skill loads and applies [`../../references/readability-rule.md`](../../references/readability-rule.md), holding the named audience: the author and reviewers of the change under review. The standard governs how each finding reads (lead with what to do and why, one idea per paragraph, short active sentences, plain words), never whether a required technical fact appears. It applies to the prose in finding bodies and narrative sections only; it never rewrites task IDs, severities, `file_path:line_number` references, `EXPLOIT:` fields, category labels, the fixed section headings and their order, the Review Summary table structure, or any code snippet. The dedicated `han-core:readability-editor` rewrite (Step 8.5) and the readability self-check (Step 9.2) carry the standard into the report.
27
28	### Task ID Assignment
29
30	Assign a unique task ID to each review item:
31	- CRIT-### for critical items (e.g., CRIT-001, CRIT-002)
32	- WARN-### for warnings (e.g., WARN-001, WARN-002)
33	- SUGG-### for suggestions (e.g., SUGG-001, SUGG-002)
34	- YAGNI-### for YAGNI candidates (e.g., YAGNI-001, YAGNI-002) — these are advisory and listed in their own section; they are not corrected unless the user explicitly requests it
35
36	IDs are sequential withi

People who liked this also viewed

6 picks

Type

code-review

122stars12forks

View on GitHub

How to install code-review?

testdouble/han/code-review

$npx -y skills add testdouble/han --skill code-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	When running a code review, follow the process outlined here.
2
3	## Project Context
4
5	- git installed: !`which git 2>/dev/null \|\| echo "not installed"`
6	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
7	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
8
9	## Review Constraints
10
11	Severity levels:
12	- Critical — Must fix before merge. Security vulnerabilities, data corruption risk, breaking API changes, data isolation failures.
13	- Warning — Should fix. Bugs that don't corrupt data, significant performance issues, missing required tests, missing error handling.
14	- Suggestion — Consider improving. Style improvements, optional performance gains, documentation gaps, refactoring opportunities.
15
16	Severity calibration is governed by Step 3.3 (the authoritative home for size-based demotion). Manual findings from Steps 4 to 6 follow the same size-based rules as agent findings classified at Step 7: Small changes escalate only Critical findings and default uncertain ones to the lower severity, Medium changes escalate Critical and Warning, Large changes prefer the higher severity when in doubt. Read `{size}` from Step 3.1. Include `file_path:line_number` references and code examples for suggested fixes.
17
18	Finding caps: Manual review findings (Steps 4-6) and agent findings (Step 7) are each capped at 30 items. Prioritize by severity: all CRIT first, then WARN, then SUGG. If either cap is exceeded, note that additional items were omitted and another code review is recommended after addressing current items. Security findings are not capped (see classification rubric).
19
20	Project pattern deference: A pattern that differs from general best practices but is consistent within the project is not a review finding. Only flag deviations from the project's own conventions.
21
22	YAGNI findings are a separate, non-correcting class. Apply the two-pass YAGNI procedure documented in [`references/review-checklist.md`](./references/review-checklist.md) (the canonical home for the procedure and the (a)/(b)/(c) recording requirement) to every change in the diff. YAGNI findings are listed in their own `### 🟡 YAGNI` section, separate from Critical / Warning / Suggestion, and do not appear under CRIT / WARN / SUGG. The YAGNI section opens with this exact statement: "These findings will not be corrected unless explicitly requested. They are documented so the team can decide consciously whether to keep, simplify, or defer the items." Severity calibration (the directive in Step 3.3, the authoritative home) does NOT apply to YAGNI; these findings are surfaced regardless of change size and are advisory, not corrective.
23
24	Automated tool boundary: If the project has a linter or formatter, trust it. Only flag style issues that automated tools can't catch.
25
26	Readability standard: The review report is a reader-facing deliverable. As it writes the finding prose and narrative, the skill loads and applies [`../../references/readability-rule.md`](../../references/readability-rule.md), holding the named audience: the author and reviewers of the change under review. The standard governs how each finding reads (lead with what to do and why, one idea per paragraph, short active sentences, plain words), never whether a required technical fact appears. It applies to the prose in finding bodies and narrative sections only; it never rewrites task IDs, severities, `file_path:line_number` references, `EXPLOIT:` fields, category labels, the fixed section headings and their order, the Review Summary table structure, or any code snippet. The dedicated `han-core:readability-editor` rewrite (Step 8.5) and the readability self-check (Step 9.2) carry the standard into the report.
27
28	### Task ID Assignment
29
30	Assign a unique task ID to each review item:
31	- CRIT-### for critical items (e.g., CRIT-001, CRIT-002)
32	- WARN-### for warnings (e.g., WARN-001, WARN-002)
33	- SUGG-### for suggestions (e.g., SUGG-001, SUGG-002)
34	- YAGNI-### for YAGNI candidates (e.g., YAGNI-001, YAGNI-002) — these are advisory and listed in their own section; they are not corrected unless the user explicitly requests it
35
36	IDs are sequential withi

People who liked this also viewed

6 picks

Type