code-review-and-quality

Name: code-review-and-quality
Author: jmxt3

32stars3forks

How to install code-review-and-quality?

jmxt3/gitscape.ai/code-review-and-quality

$npx -y skills add jmxt3/gitscape.ai --skill code-review-and-quality

Installs into the current project.

Summary

Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.

Files · 1

View on GitHub

SKILL.md

1	# Code Review and Quality
2
3	## Overview
4
5	Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers five axes: correctness, readability, architecture, security, and performance.
6
7	The approval standard: Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it. If it improves the codebase and follows the project's conventions, approve it.
8
9	## When to Use
10
11	- Before merging any PR or change
12	- After completing a feature implementation
13	- When another agent or model produced code you need to evaluate
14	- When refactoring existing code
15	- After any bug fix (review both the fix and the regression test)
16
17	## The Five-Axis Review
18
19	Every review evaluates code across these dimensions:
20
21	### 1. Correctness
22
23	Does the code do what it claims to do?
24
25	- Does it match the spec or task requirements?
26	- Are edge cases handled (null, empty, boundary values)?
27	- Are error paths handled (not just the happy path)?
28	- Does it pass all tests? Are the tests actually testing the right things?
29	- Are there off-by-one errors, race conditions, or state inconsistencies?
30
31	### 2. Readability & Simplicity
32
33	Can another engineer (or agent) understand this code without the author explaining it?
34
35	- Are names descriptive and consistent with project conventions? (No `temp`, `data`, `result` without context)
36	- Is the control flow straightforward (avoid nested ternaries, deep callbacks)?
37	- Is the code organized logically (related code grouped, clear module boundaries)?
38	- Are there any "clever" tricks that should be simplified?
39	- Could this be done in fewer lines? (1000 lines where 100 suffice is a failure)
40	- Are abstractions earning their complexity? (Don't generalize until the third use case)
41	- Would comments help clarify non-obvious intent? (But don't comment obvious code.)
42	- Are there dead code artifacts: no-op variables (`_unused`), backwards-compat shims, or `// removed` comments?
43
44	### 3. Architecture
45
46	Does the change fit the system's design?
47
48	- Does it follow existing patterns or introduce a new one? If new, is it justified?
49	- Does it maintain clean module boundaries?
50	- Is there code duplication that should be shared?
51	- Are dependencies flowing in the right direction (no circular dependencies)?
52	- Is the abstraction level appropriate (not over-engineered, not too coupled)?
53
54	### 4. Security
55
56	For detailed security guidance, see `security-and-hardening`. Does the change introduce vulnerabilities?
57
58	- Is user input validated and sanitized?
59	- Are secrets kept out of code, logs, and version control?
60	- Is authentication/authorization checked where needed?
61	- Are SQL queries parameterized (no string concatenation)?
62	- Are outputs encoded to prevent XSS?
63	- Are dependencies from trusted sources with no known vulnerabilities?
64	- Is data from external sources (APIs, logs, user content, config files) treated as untrusted?
65	- Are external data flows validated at system boundaries before use in logic or rendering?
66
67	### 5. Performance
68
69	For detailed profiling and optimization, see `performance-optimization`. Does the change introduce performance problems?
70
71	- Any N+1 query patterns?
72	- Any unbounded loops or unconstrained data fetching?
73	- Any synchronous operations that should be async?
74	- Any unnecessary re-renders in UI components?
75	- Any missing pagination on list endpoints?
76	- Any large objects created in hot paths?
77
78	## Change Sizing
79
80	Small, focused changes are easier to review, faster to merge, and safer to deploy. Target these sizes:
81
82	```
83	~100 lines changed → Good. Reviewable in one sitting.
84	~300 lines changed → Acceptable if it's a single logical change.
85	~1000 lines changed → Too large. Split it.
86	```
87
88	What counts as "one change": A single self-contained modification that addresses one thing, includes related tests, and keeps the system functional after submission. One part of a feature — not the whole feature.
89
90	Splitting strategies when a change is too large:
91
92	\| Strategy \| How \| When \|
93	\|----------\|-----\|------\|
94	\| Stack \| Submit a small change, start the next one based on it \| Sequential dependencies \|
95	\| By file group \| Separate changes for groups needing different reviewers \| Cross-cutting concerns \|
96	\| Horizontal \| Create shared code/stubs first, then consumers \| Layered architecture \|
97	\| Vertical \| Break into smaller full-stack slices of the feature \| Feature work \|
98
99	When large changes are acceptable: Complete file deletions and automated refactoring where the reviewer only needs to verify intent, not every line.

People who liked this also viewed

6 picks

Type

code-review-and-quality

32stars3forks

View on GitHub

How to install code-review-and-quality?

jmxt3/gitscape.ai/code-review-and-quality

$npx -y skills add jmxt3/gitscape.ai --skill code-review-and-quality

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Code Review and Quality
2
3	## Overview
4
5	Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers five axes: correctness, readability, architecture, security, and performance.
6
7	The approval standard: Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it. If it improves the codebase and follows the project's conventions, approve it.
8
9	## When to Use
10
11	- Before merging any PR or change
12	- After completing a feature implementation
13	- When another agent or model produced code you need to evaluate
14	- When refactoring existing code
15	- After any bug fix (review both the fix and the regression test)
16
17	## The Five-Axis Review
18
19	Every review evaluates code across these dimensions:
20
21	### 1. Correctness
22
23	Does the code do what it claims to do?
24
25	- Does it match the spec or task requirements?
26	- Are edge cases handled (null, empty, boundary values)?
27	- Are error paths handled (not just the happy path)?
28	- Does it pass all tests? Are the tests actually testing the right things?
29	- Are there off-by-one errors, race conditions, or state inconsistencies?
30
31	### 2. Readability & Simplicity
32
33	Can another engineer (or agent) understand this code without the author explaining it?
34
35	- Are names descriptive and consistent with project conventions? (No `temp`, `data`, `result` without context)
36	- Is the control flow straightforward (avoid nested ternaries, deep callbacks)?
37	- Is the code organized logically (related code grouped, clear module boundaries)?
38	- Are there any "clever" tricks that should be simplified?
39	- Could this be done in fewer lines? (1000 lines where 100 suffice is a failure)
40	- Are abstractions earning their complexity? (Don't generalize until the third use case)
41	- Would comments help clarify non-obvious intent? (But don't comment obvious code.)
42	- Are there dead code artifacts: no-op variables (`_unused`), backwards-compat shims, or `// removed` comments?
43
44	### 3. Architecture
45
46	Does the change fit the system's design?
47
48	- Does it follow existing patterns or introduce a new one? If new, is it justified?
49	- Does it maintain clean module boundaries?
50	- Is there code duplication that should be shared?
51	- Are dependencies flowing in the right direction (no circular dependencies)?
52	- Is the abstraction level appropriate (not over-engineered, not too coupled)?
53
54	### 4. Security
55
56	For detailed security guidance, see `security-and-hardening`. Does the change introduce vulnerabilities?
57
58	- Is user input validated and sanitized?
59	- Are secrets kept out of code, logs, and version control?
60	- Is authentication/authorization checked where needed?
61	- Are SQL queries parameterized (no string concatenation)?
62	- Are outputs encoded to prevent XSS?
63	- Are dependencies from trusted sources with no known vulnerabilities?
64	- Is data from external sources (APIs, logs, user content, config files) treated as untrusted?
65	- Are external data flows validated at system boundaries before use in logic or rendering?
66
67	### 5. Performance
68
69	For detailed profiling and optimization, see `performance-optimization`. Does the change introduce performance problems?
70
71	- Any N+1 query patterns?
72	- Any unbounded loops or unconstrained data fetching?
73	- Any synchronous operations that should be async?
74	- Any unnecessary re-renders in UI components?
75	- Any missing pagination on list endpoints?
76	- Any large objects created in hot paths?
77
78	## Change Sizing
79
80	Small, focused changes are easier to review, faster to merge, and safer to deploy. Target these sizes:
81
82	```
83	~100 lines changed → Good. Reviewable in one sitting.
84	~300 lines changed → Acceptable if it's a single logical change.
85	~1000 lines changed → Too large. Split it.
86	```
87
88	What counts as "one change": A single self-contained modification that addresses one thing, includes related tests, and keeps the system functional after submission. One part of a feature — not the whole feature.
89
90	Splitting strategies when a change is too large:
91
92	\| Strategy \| How \| When \|
93	\|----------\|-----\|------\|
94	\| Stack \| Submit a small change, start the next one based on it \| Sequential dependencies \|
95	\| By file group \| Separate changes for groups needing different reviewers \| Cross-cutting concerns \|
96	\| Horizontal \| Create shared code/stubs first, then consumers \| Layered architecture \|
97	\| Vertical \| Break into smaller full-stack slices of the feature \| Feature work \|
98
99	When large changes are acceptable: Complete file deletions and automated refactoring where the reviewer only needs to verify intent, not every line.

People who liked this also viewed

6 picks

Type