review-code

Name: review-code
Author: avibebuilder

109stars17forks

How to install review-code?

avibebuilder/claude-prime/review-code

$npx -y skills add avibebuilder/claude-prime --skill review-code

Installs into the current project.

Summary

Review code for quality, correctness, and fit. Use when the user wants judgment on code that already exists — their own changes, a teammate's patch, a PR, branch, commit, diff, staged changes, or one or more files to look over. Activate on requests like review, look over, sanity

Files · 1

View on GitHub

SKILL.md

1	ultrathink
2
3	## Process
4
5	Critique only — no fixes or implementation. Understand why the code exists before judging it.
6
7	### 1. Identify the review target
8
9	Prefer in order: explicit `<target>`, changes made in this conversation, working diff. If unclear, ask.
10
11	Then gather enough context (PR/issue text, plans, surrounding code) to avoid misreads. Don't turn every review into archaeology — if a missing detail would materially change judgment, ask briefly.
12
13	### 2. Match depth to risk
14
15	- Quick — small, local, low-risk; keep output brief
16	- Standard — normal feature or refactor
17	- Deep — risky, cross-cutting, security-sensitive, or surprising
18
19	### 3. Review flow first, then details
20
21	Understand how important parts work before commenting line by line. Focus on load-bearing logic, edge cases, scope drift, and intentional tradeoffs.
22
23	### 4. Report
24
25	For each finding: file path + line, why it matters, severity.
26
27	- Critical — correctness, safety, broken edge cases, scope violations. Requires evidence in the code — speculative failure modes belong in Questions.
28	- Suggestion — non-blocking improvements
29	- Question — missing context or unconfirmable concerns
30
31	If something looks odd but context supports it, acknowledge rather than flag.
32
33	### 5. Output format
34
35	```
36	## Code Review: [scope]
37
38	Verdict: {Approve \| Request Changes \| Reject}
39
40	### Inferred Intent
41	[Only when context supports it]
42
43	### Critical Issues (Must Fix)
44	- `path/to/file:line` — concise description. Why: [reason]
45
46	### Suggestions (Nice to Have)
47	- `path/to/file:line` — concise description
48
49	### Questions
50	- [Clarifications on intent or tradeoffs]
51
52	### Summary
53	[1-2 sentences]
54	```
55
56	Include only sections with content. Always include Verdict and Summary.
57
58	## Boundaries
59
60	- Read surrounding code when the diff alone is misleading.
61	- Deliberate decisions (inline comments, user-stated tradeoffs) are not defects — raise as Question only with concrete evidence.
62	- Don't judge by personal preference when project fit explains the choice.
63	- Name the right approach ("needs parameterized queries") but don't write corrected code.
64
65	## Target
66
67	<target>$ARGUMENTS</target>

People who liked this also viewed

6 picks

Type

review-code

109stars17forks

View on GitHub

How to install review-code?

avibebuilder/claude-prime/review-code

$npx -y skills add avibebuilder/claude-prime --skill review-code

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	ultrathink
2
3	## Process
4
5	Critique only — no fixes or implementation. Understand why the code exists before judging it.
6
7	### 1. Identify the review target
8
9	Prefer in order: explicit `<target>`, changes made in this conversation, working diff. If unclear, ask.
10
11	Then gather enough context (PR/issue text, plans, surrounding code) to avoid misreads. Don't turn every review into archaeology — if a missing detail would materially change judgment, ask briefly.
12
13	### 2. Match depth to risk
14
15	- Quick — small, local, low-risk; keep output brief
16	- Standard — normal feature or refactor
17	- Deep — risky, cross-cutting, security-sensitive, or surprising
18
19	### 3. Review flow first, then details
20
21	Understand how important parts work before commenting line by line. Focus on load-bearing logic, edge cases, scope drift, and intentional tradeoffs.
22
23	### 4. Report
24
25	For each finding: file path + line, why it matters, severity.
26
27	- Critical — correctness, safety, broken edge cases, scope violations. Requires evidence in the code — speculative failure modes belong in Questions.
28	- Suggestion — non-blocking improvements
29	- Question — missing context or unconfirmable concerns
30
31	If something looks odd but context supports it, acknowledge rather than flag.
32
33	### 5. Output format
34
35	```
36	## Code Review: [scope]
37
38	Verdict: {Approve \| Request Changes \| Reject}
39
40	### Inferred Intent
41	[Only when context supports it]
42
43	### Critical Issues (Must Fix)
44	- `path/to/file:line` — concise description. Why: [reason]
45
46	### Suggestions (Nice to Have)
47	- `path/to/file:line` — concise description
48
49	### Questions
50	- [Clarifications on intent or tradeoffs]
51
52	### Summary
53	[1-2 sentences]
54	```
55
56	Include only sections with content. Always include Verdict and Summary.
57
58	## Boundaries
59
60	- Read surrounding code when the diff alone is misleading.
61	- Deliberate decisions (inline comments, user-stated tradeoffs) are not defects — raise as Question only with concrete evidence.
62	- Don't judge by personal preference when project fit explains the choice.
63	- Name the right approach ("needs parameterized queries") but don't write corrected code.
64
65	## Target
66
67	<target>$ARGUMENTS</target>

People who liked this also viewed

6 picks

Type