code-reviewing

Name: code-reviewing
Author: pavel-molyanov

241stars75forks

How to install code-reviewing?

pavel-molyanov/molyanov-ai-dev/code-reviewing

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill code-reviewing

Installs into the current project.

Summary

Code review methodology and quality standards for comprehensive code analysis. Use to understand WHAT and HOW to review code: 11 review dimensions, process, quality standards. Use when: "проверь код", "code review", "ревью кода", "review this code", "check code quality

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Code Review Methodology
4
5	Comprehensive code review methodology for ensuring production-ready quality and maintainable architecture.
6
7	## Review Dimensions
8
9	Perform systematic analysis across these 11 dimensions:
10
11	### 1. Architectural Patterns
12
13	- Evaluate adherence to established architectural patterns (MVC, MVVM, Clean Architecture, etc.)
14	- Assess design patterns usage (Factory, Strategy, Observer, etc.)
15	- Verify layer separation and dependency direction
16	- Check for architectural anti-patterns (circular dependencies, god objects, tight coupling)
17
18	### 2. Separation of Concerns
19
20	- Validate single responsibility principle compliance
21	- Examine module boundaries and cohesion
22	- Review business logic vs presentation logic separation
23	- Assess data layer abstraction and persistence logic isolation
24
25	Good practices:
26	- One file = one responsibility (UserService in one file, PaymentService in another)
27	- Functions < 50 lines; if larger, break into smaller functions
28	- Maximum 3 levels of nesting; use early returns to reduce nesting
29	- High-level modules should not depend on low-level details
30
31	### 3. Code Readability & Maintainability
32
33	- Evaluate naming conventions (variables, functions, classes)
34	- Assess code organization and file structure
35	- Check for appropriate use of comments and documentation
36	- Review complexity metrics (cyclomatic complexity, nesting depth)
37	- Verify consistent code style and formatting
38
39	Good practices:
40	- Meaningful comments focus on "why" rather than obvious "what"
41	- DRY principle: extract repeated code into functions/modules
42	- Readable > clever: clear code is better than short but cryptic code
43	- No magic numbers: extract to named constants (`MAX_UPLOAD_SIZE` not `5242880`)
44
45	### 4. Error Handling & Logging
46
47	- Examine error propagation strategy
48	- Verify appropriate use of try-catch blocks
49	- Check error messages clarity and actionability
50	- Assess graceful degradation and fallback mechanisms
51
52	Good practices (error handling):
53	- Always use try-catch for operations that can fail (API calls, DB operations, file I/O)
54	- Don't swallow errors: always re-throw after logging (unless explicitly handling)
55	- Fail fast: validate inputs early; throw errors immediately when invalid
56	- User-friendly errors: show generic message to users, log details internally
57
58	Logging review checklist:
59	- Key operations have logs (external calls, auth events, state transitions, business operations)
60	- Structured format used (JSON / logger library), not string concatenation or `console.log`
61	- Every log includes context: userId, action, resourceId (not just a bare message)
62	- Correlation/request ID propagated through call chain
63	- Log levels used correctly (info for success, warn for recoverable, error for failures)
64	- Error logs include stack traces
65	- No secrets or PII in logs (passwords, tokens, API keys, emails, phone numbers)
66	- No empty catch blocks (`catch (e) {}` — silent error swallowing)
67	- No logging inside tight loops (generates thousands of duplicate lines)
68
69	Automatic severity mappings:
70
71	\| Pattern \| Severity \|
72	\|---------\|----------\|
73	\| Secrets or PII logged (tokens, passwords, emails in plaintext) \| critical \|
74	\| Empty catch block — error swallowed without logging \| major \|
75	\| External call (API, DB) without any logging \| major \|
76	\| Missing correlation/request ID in service handling requests \| minor \|
77	\| `console.log` / `print` used instead of structured logger \| minor \|
78
79	### 5. Type Safety (TypeScript/typed languages)
80
81	For TypeScript or other typed codebases:
82
83	- Validate type definitions completeness and accuracy
84	- Check for inappropriate use of `any` type (TypeScript) or equivalent loose typing
85	- Assess interface and type alias design
86	- Review generic type usage and constraints
87	- Verify null/undefined handling and optional chaining
88	- Check for type assertions and their justification
89
90	### 6. Testing Coverage
91
92	- Evaluate unit test presence and quality
93	- Assess test coverage for critical paths
94	- Review test organization and naming
95	- Check for integration and E2E test needs
96	- Verify mocking strategies and test isolation
97	- Assess edge case and error scenario coverage
98
99	Good practices:
100	- Tests needed for: business logic, validations, transforms, error handling
101	- Tests not needed for: simple getters/setters, one-line configs, trivial updates
102	- Rule: if mocking >3 dependencies → wrong test type, use integration test
103
104	### 7. Dependencies Management
105
106	- Review new dependencies necessity and appropriateness
107	- Check for dependency version conflicts
108	- Assess bundle size impact
109	- Verify security vulnerabilities (outdated packages)
110	- Evaluate licensin

People who liked this also viewed

6 picks

Type

code-reviewing

241stars75forks

View on GitHub

How to install code-reviewing?

pavel-molyanov/molyanov-ai-dev/code-reviewing

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill code-reviewing

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Code Review Methodology
4
5	Comprehensive code review methodology for ensuring production-ready quality and maintainable architecture.
6
7	## Review Dimensions
8
9	Perform systematic analysis across these 11 dimensions:
10
11	### 1. Architectural Patterns
12
13	- Evaluate adherence to established architectural patterns (MVC, MVVM, Clean Architecture, etc.)
14	- Assess design patterns usage (Factory, Strategy, Observer, etc.)
15	- Verify layer separation and dependency direction
16	- Check for architectural anti-patterns (circular dependencies, god objects, tight coupling)
17
18	### 2. Separation of Concerns
19
20	- Validate single responsibility principle compliance
21	- Examine module boundaries and cohesion
22	- Review business logic vs presentation logic separation
23	- Assess data layer abstraction and persistence logic isolation
24
25	Good practices:
26	- One file = one responsibility (UserService in one file, PaymentService in another)
27	- Functions < 50 lines; if larger, break into smaller functions
28	- Maximum 3 levels of nesting; use early returns to reduce nesting
29	- High-level modules should not depend on low-level details
30
31	### 3. Code Readability & Maintainability
32
33	- Evaluate naming conventions (variables, functions, classes)
34	- Assess code organization and file structure
35	- Check for appropriate use of comments and documentation
36	- Review complexity metrics (cyclomatic complexity, nesting depth)
37	- Verify consistent code style and formatting
38
39	Good practices:
40	- Meaningful comments focus on "why" rather than obvious "what"
41	- DRY principle: extract repeated code into functions/modules
42	- Readable > clever: clear code is better than short but cryptic code
43	- No magic numbers: extract to named constants (`MAX_UPLOAD_SIZE` not `5242880`)
44
45	### 4. Error Handling & Logging
46
47	- Examine error propagation strategy
48	- Verify appropriate use of try-catch blocks
49	- Check error messages clarity and actionability
50	- Assess graceful degradation and fallback mechanisms
51
52	Good practices (error handling):
53	- Always use try-catch for operations that can fail (API calls, DB operations, file I/O)
54	- Don't swallow errors: always re-throw after logging (unless explicitly handling)
55	- Fail fast: validate inputs early; throw errors immediately when invalid
56	- User-friendly errors: show generic message to users, log details internally
57
58	Logging review checklist:
59	- Key operations have logs (external calls, auth events, state transitions, business operations)
60	- Structured format used (JSON / logger library), not string concatenation or `console.log`
61	- Every log includes context: userId, action, resourceId (not just a bare message)
62	- Correlation/request ID propagated through call chain
63	- Log levels used correctly (info for success, warn for recoverable, error for failures)
64	- Error logs include stack traces
65	- No secrets or PII in logs (passwords, tokens, API keys, emails, phone numbers)
66	- No empty catch blocks (`catch (e) {}` — silent error swallowing)
67	- No logging inside tight loops (generates thousands of duplicate lines)
68
69	Automatic severity mappings:
70
71	\| Pattern \| Severity \|
72	\|---------\|----------\|
73	\| Secrets or PII logged (tokens, passwords, emails in plaintext) \| critical \|
74	\| Empty catch block — error swallowed without logging \| major \|
75	\| External call (API, DB) without any logging \| major \|
76	\| Missing correlation/request ID in service handling requests \| minor \|
77	\| `console.log` / `print` used instead of structured logger \| minor \|
78
79	### 5. Type Safety (TypeScript/typed languages)
80
81	For TypeScript or other typed codebases:
82
83	- Validate type definitions completeness and accuracy
84	- Check for inappropriate use of `any` type (TypeScript) or equivalent loose typing
85	- Assess interface and type alias design
86	- Review generic type usage and constraints
87	- Verify null/undefined handling and optional chaining
88	- Check for type assertions and their justification
89
90	### 6. Testing Coverage
91
92	- Evaluate unit test presence and quality
93	- Assess test coverage for critical paths
94	- Review test organization and naming
95	- Check for integration and E2E test needs
96	- Verify mocking strategies and test isolation
97	- Assess edge case and error scenario coverage
98
99	Good practices:
100	- Tests needed for: business logic, validations, transforms, error handling
101	- Tests not needed for: simple getters/setters, one-line configs, trivial updates
102	- Rule: if mocking >3 dependencies → wrong test type, use integration test
103
104	### 7. Dependencies Management
105
106	- Review new dependencies necessity and appropriateness
107	- Check for dependency version conflicts
108	- Assess bundle size impact
109	- Verify security vulnerabilities (outdated packages)
110	- Evaluate licensin

People who liked this also viewed

6 picks

Type