code-review-and-quality

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

20stars2forks

How to install code-review-and-quality?

pimenov/codex-first-skills-pack/code-review-and-quality

$npx -y skills add pimenov/codex-first-skills-pack --skill code-review-and-quality

Installs into the current project.

Summary

Reviews code changes across correctness, tests, readability, architecture, security, and performance before they are merged, shipped, or called done. Use when the user asks for a code review, when reviewing a PR/diff/commit/agent-produced code, after implementation or bugfix befo

Files · 1

View on GitHub

SKILL.md

1	# Code Review And Quality
2
3	## Overview
4
5	Use this skill as the normal code quality gate for finished or nearly finished code changes. The review should find real bugs, regressions, missing tests, unsafe assumptions, confusing structure, and verification gaps.
6
7	This is not praise, style commentary, or a rewrite plan by default. Lead with actionable findings.
8
9	## Relationship To Other Skills
10
11	- Use `context-engineering` first when the change intent, source of truth, or local conventions are unclear.
12	- Use `doubt-driven-review` for high-stakes claims or risky production/auth/data decisions, especially before mutation.
13	- Use `codex-security:*` for deep or scoped security review when security is the primary task.
14	- Use `impeccable` for frontend visual/UX/design review.
15	- Use `test-driven-development` when review finds a behavior gap that needs a regression guard.
16	- Use `source-driven-development` when review depends on current framework, SDK, API, CLI, or platform behavior.
17
18	## Do Not Use
19
20	- Pure prose, documentation, or strategy review with no code artifact.
21	- Design critique of UI aesthetics; route to `impeccable`.
22	- Deep security audit; route to `codex-security:*`.
23	- High-stakes operational approval where the artifact is a deploy/migration/rollback decision; route to `doubt-driven-review`.
24	- Reviewing without a concrete diff, files, commit, PR, patch, or generated code to inspect.
25
26	## Review Contract
27
28	Before reviewing, establish:
29
30	- what the change is trying to accomplish;
31	- the expected behavior or acceptance criteria;
32	- the diff, files, commit, PR, or generated code under review;
33	- relevant tests or verification evidence;
34	- local conventions and nearest `AGENTS.md`;
35	- whether production, data, auth, secrets, billing, or public APIs are touched.
36
37	If the contract is missing and affects correctness, ask or run read-only discovery before reviewing.
38
39	## Review Order
40
41	### 1. Read Intent Before Diff
42
43	Find the task, issue, spec, commit message, user request, or nearby notes. If no intent exists, infer cautiously and label the inference.
44
45	Do not judge code only by taste. Review against the contract and the codebase's existing patterns.
46
47	### 2. Inspect Tests First
48
49	Tests show what the author thinks matters.
50
51	Check:
52
53	- tests exist for behavior changes and bug fixes;
54	- tests assert behavior, not incidental implementation details;
55	- edge cases are covered: null/empty/boundary/error paths;
56	- test names describe expected behavior;
57	- a bugfix has a regression guard;
58	- test updates did not simply bless broken behavior.
59
60	Missing or weak tests are findings when they reduce confidence in changed behavior.
61
62	### 3. Review Implementation Across Six Axes
63
64	Use these axes for every changed area.
65
66	Correctness
67
68	- matches the spec, issue, or user-visible requirement;
69	- handles edge cases, race conditions, concurrency, time zones, idempotency, retries, and partial failure where relevant;
70	- preserves existing behavior outside scope;
71	- avoids off-by-one, stale state, cache invalidation, and ordering bugs;
72	- does not silently swallow errors.
73
74	Tests And Verification
75
76	- focused tests/checks cover the changed behavior;
77	- broader checks are appropriate for the blast radius;
78	- manual verification is described when automation is unrealistic;
79	- build/typecheck/lint results are relevant and current;
80	- screenshots or browser checks exist for UI behavior when needed.
81
82	Readability And Simplicity
83
84	- names are clear and consistent with local conventions;
85	- control flow is direct;
86	- abstractions earn their complexity;
87	- comments explain non-obvious intent, not obvious syntax;
88	- no cleverness, dead branches, temporary scaffolding, or debug leftovers.
89
90	Architecture
91
92	- fits existing module boundaries and ownership;
93	- dependencies flow in the expected direction;
94	- no unjustified new framework, dependency, global state, or cross-layer shortcut;
95	- shared code is extracted only when reuse is real;
96	- public contracts and schemas remain compatible unless the breaking change is explicit.
97
98	Security And Data Safety
99
100	- no raw secrets, tokens, private keys, or full env files;
101	- input is validated at trust boundaries;
102	- authorization/authentication remains enforced;
103	- queries and shell calls avoid injection;
104	- external data, logs, tickets, and fixtures are treated as untrusted data;
105	- sensitive data is not exposed in logs, errors, telemetry, or UI.
106
107	Performance And Operations
108
109	- no obvious N+1 queries, unbounded loops, unpaginated lists, or excessive data fetches;
110	- no hot-path a

People who liked this also viewed

6 picks

Type

code-review-and-quality

20stars2forks

View on GitHub

How to install code-review-and-quality?

pimenov/codex-first-skills-pack/code-review-and-quality

$npx -y skills add pimenov/codex-first-skills-pack --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	Use this skill as the normal code quality gate for finished or nearly finished code changes. The review should find real bugs, regressions, missing tests, unsafe assumptions, confusing structure, and verification gaps.
6
7	This is not praise, style commentary, or a rewrite plan by default. Lead with actionable findings.
8
9	## Relationship To Other Skills
10
11	- Use `context-engineering` first when the change intent, source of truth, or local conventions are unclear.
12	- Use `doubt-driven-review` for high-stakes claims or risky production/auth/data decisions, especially before mutation.
13	- Use `codex-security:*` for deep or scoped security review when security is the primary task.
14	- Use `impeccable` for frontend visual/UX/design review.
15	- Use `test-driven-development` when review finds a behavior gap that needs a regression guard.
16	- Use `source-driven-development` when review depends on current framework, SDK, API, CLI, or platform behavior.
17
18	## Do Not Use
19
20	- Pure prose, documentation, or strategy review with no code artifact.
21	- Design critique of UI aesthetics; route to `impeccable`.
22	- Deep security audit; route to `codex-security:*`.
23	- High-stakes operational approval where the artifact is a deploy/migration/rollback decision; route to `doubt-driven-review`.
24	- Reviewing without a concrete diff, files, commit, PR, patch, or generated code to inspect.
25
26	## Review Contract
27
28	Before reviewing, establish:
29
30	- what the change is trying to accomplish;
31	- the expected behavior or acceptance criteria;
32	- the diff, files, commit, PR, or generated code under review;
33	- relevant tests or verification evidence;
34	- local conventions and nearest `AGENTS.md`;
35	- whether production, data, auth, secrets, billing, or public APIs are touched.
36
37	If the contract is missing and affects correctness, ask or run read-only discovery before reviewing.
38
39	## Review Order
40
41	### 1. Read Intent Before Diff
42
43	Find the task, issue, spec, commit message, user request, or nearby notes. If no intent exists, infer cautiously and label the inference.
44
45	Do not judge code only by taste. Review against the contract and the codebase's existing patterns.
46
47	### 2. Inspect Tests First
48
49	Tests show what the author thinks matters.
50
51	Check:
52
53	- tests exist for behavior changes and bug fixes;
54	- tests assert behavior, not incidental implementation details;
55	- edge cases are covered: null/empty/boundary/error paths;
56	- test names describe expected behavior;
57	- a bugfix has a regression guard;
58	- test updates did not simply bless broken behavior.
59
60	Missing or weak tests are findings when they reduce confidence in changed behavior.
61
62	### 3. Review Implementation Across Six Axes
63
64	Use these axes for every changed area.
65
66	Correctness
67
68	- matches the spec, issue, or user-visible requirement;
69	- handles edge cases, race conditions, concurrency, time zones, idempotency, retries, and partial failure where relevant;
70	- preserves existing behavior outside scope;
71	- avoids off-by-one, stale state, cache invalidation, and ordering bugs;
72	- does not silently swallow errors.
73
74	Tests And Verification
75
76	- focused tests/checks cover the changed behavior;
77	- broader checks are appropriate for the blast radius;
78	- manual verification is described when automation is unrealistic;
79	- build/typecheck/lint results are relevant and current;
80	- screenshots or browser checks exist for UI behavior when needed.
81
82	Readability And Simplicity
83
84	- names are clear and consistent with local conventions;
85	- control flow is direct;
86	- abstractions earn their complexity;
87	- comments explain non-obvious intent, not obvious syntax;
88	- no cleverness, dead branches, temporary scaffolding, or debug leftovers.
89
90	Architecture
91
92	- fits existing module boundaries and ownership;
93	- dependencies flow in the expected direction;
94	- no unjustified new framework, dependency, global state, or cross-layer shortcut;
95	- shared code is extracted only when reuse is real;
96	- public contracts and schemas remain compatible unless the breaking change is explicit.
97
98	Security And Data Safety
99
100	- no raw secrets, tokens, private keys, or full env files;
101	- input is validated at trust boundaries;
102	- authorization/authentication remains enforced;
103	- queries and shell calls avoid injection;
104	- external data, logs, tickets, and fixtures are treated as untrusted data;
105	- sensitive data is not exposed in logs, errors, telemetry, or UI.
106
107	Performance And Operations
108
109	- no obvious N+1 queries, unbounded loops, unpaginated lists, or excessive data fetches;
110	- no hot-path a

People who liked this also viewed

6 picks

Type