code-review

Name: code-review
Author: tranhieutt

69stars41forks

How to install code-review?

tranhieutt/software_development_department/code-review

$npx -y skills add tranhieutt/software_development_department --skill code-review

Installs into the current project.

Summary

Performs architectural and quality code review checking coding standards, SOLID principles, architectural compliance, and common software issues. Use when reviewing a file or directory before merge, or when the user mentions code review, PR review, or quality check.

Files · 1

View on GitHub

SKILL.md

1	When this skill is invoked:
2
3	1. Read the target file(s) in full.
4
5	2. Read the CLAUDE.md for project coding standards.
6
7	3. Identify the system category (api, service, repository, component, utility, infrastructure)
8	and apply category-specific standards.
9
10	4. Evaluate against coding standards:
11	- [ ] Public methods and classes have doc comments
12	- [ ] Cyclomatic complexity under 10 per method
13	- [ ] No method exceeds 40 lines (excluding data declarations)
14	- [ ] Dependencies are injected (no singletons for business state)
15	- [ ] Configuration values loaded from external config, not hardcoded
16	- [ ] Systems expose interfaces (not concrete class dependencies)
17
18	5. Check architectural compliance:
19	- [ ] Correct dependency direction (infrastructure ← domain ← application)
20	- [ ] No circular dependencies between modules
21	- [ ] Proper layer separation (UI does not own business logic)
22	- [ ] Events/messages used for cross-service communication
23	- [ ] Consistent with established patterns in the codebase
24	- [ ] Interfaces are earning their complexity: prefer deep modules over thin pass-through wrappers
25	- [ ] Suspected abstractions survive the deletion test: deleting them would reintroduce complexity across callers, not simplify the system
26
27	6. Check SOLID compliance:
28	- [ ] Single Responsibility: Each class has one reason to change
29	- [ ] Open/Closed: Extendable without modification
30	- [ ] Liskov Substitution: Subtypes substitutable for base types
31	- [ ] Interface Segregation: No fat interfaces
32	- [ ] Dependency Inversion: Depends on abstractions, not concretions
33
34	7. Check for common web/software issues:
35	- [ ] No N+1 query patterns (use eager loading or joins)
36	- [ ] Proper async/await usage (no unhandled promises, no floating async)
37	- [ ] Input validation at system boundaries (user input, external APIs)
38	- [ ] Proper error handling with meaningful, safe messages (no stack traces exposed)
39	- [ ] No secrets or sensitive data hardcoded (API keys, passwords, tokens)
40	- [ ] Resource cleanup (DB connections, streams, subscriptions, event listeners)
41	- [ ] Thread/concurrency safety where required
42
43	8. Output the review in this format:
44
45	```
46	## Code Review: [File/System Name]
47
48	### Standards Compliance: [X/6 passing]
49	[List failures with line references]
50
51	### Architecture: [CLEAN / MINOR ISSUES / VIOLATIONS FOUND]
52	[List specific architectural concerns]
53
54	### SOLID: [COMPLIANT / ISSUES FOUND]
55	[List specific violations]
56
57	### Web/Software Concerns
58	[List web and software-specific issues found]
59
60	### Positive Observations
61	[What is done well — always include this section]
62
63	### Required Changes
64	[Must-fix items before approval]
65
66	### Suggestions
67	[Nice-to-have improvements]
68
69	### Verdict: [APPROVED / APPROVED WITH SUGGESTIONS / CHANGES REQUIRED]
70	```
71
72	## Protocol
73
74	Architecture vocabulary to use when it helps clarify a finding:
75
76	- Module — unit with an interface and implementation
77	- Deep module — small interface, high leverage behind it
78	- Shallow module — interface nearly as complex as implementation
79	- Deletion test — if deleting a wrapper mostly removes indirection instead of
80	reintroducing complexity in callers, the abstraction may be shallow
81
82	Use this vocabulary to sharpen architectural findings, not to force jargon into
83	every review.
84
85	- Question: Auto-starts from argument (file or directory path); no clarification needed
86	- Options: Skip — single review path
87	- Decision: Skip — verdict is advisory
88	- Draft: Full review shown in conversation only
89	- Approval: Skip — read-only; no files written
90
91	## Output
92
93	Deliver exactly:
94
95	- Risk Tier (Low / Medium / High) with one-sentence justification
96	- Standards & Architecture compliance score (X/6, X/5)
97	- Blocking issues — must fix before merge (or "None")
98	- Suggestions — optional improvements, max 3
99	- Verdict: `APPROVED` / `APPROVED WITH SUGGESTIONS` / `CHANGES REQUIRED`

People who liked this also viewed

6 picks

Type

code-review

69stars41forks

View on GitHub

How to install code-review?

tranhieutt/software_development_department/code-review

$npx -y skills add tranhieutt/software_development_department --skill code-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	When this skill is invoked:
2
3	1. Read the target file(s) in full.
4
5	2. Read the CLAUDE.md for project coding standards.
6
7	3. Identify the system category (api, service, repository, component, utility, infrastructure)
8	and apply category-specific standards.
9
10	4. Evaluate against coding standards:
11	- [ ] Public methods and classes have doc comments
12	- [ ] Cyclomatic complexity under 10 per method
13	- [ ] No method exceeds 40 lines (excluding data declarations)
14	- [ ] Dependencies are injected (no singletons for business state)
15	- [ ] Configuration values loaded from external config, not hardcoded
16	- [ ] Systems expose interfaces (not concrete class dependencies)
17
18	5. Check architectural compliance:
19	- [ ] Correct dependency direction (infrastructure ← domain ← application)
20	- [ ] No circular dependencies between modules
21	- [ ] Proper layer separation (UI does not own business logic)
22	- [ ] Events/messages used for cross-service communication
23	- [ ] Consistent with established patterns in the codebase
24	- [ ] Interfaces are earning their complexity: prefer deep modules over thin pass-through wrappers
25	- [ ] Suspected abstractions survive the deletion test: deleting them would reintroduce complexity across callers, not simplify the system
26
27	6. Check SOLID compliance:
28	- [ ] Single Responsibility: Each class has one reason to change
29	- [ ] Open/Closed: Extendable without modification
30	- [ ] Liskov Substitution: Subtypes substitutable for base types
31	- [ ] Interface Segregation: No fat interfaces
32	- [ ] Dependency Inversion: Depends on abstractions, not concretions
33
34	7. Check for common web/software issues:
35	- [ ] No N+1 query patterns (use eager loading or joins)
36	- [ ] Proper async/await usage (no unhandled promises, no floating async)
37	- [ ] Input validation at system boundaries (user input, external APIs)
38	- [ ] Proper error handling with meaningful, safe messages (no stack traces exposed)
39	- [ ] No secrets or sensitive data hardcoded (API keys, passwords, tokens)
40	- [ ] Resource cleanup (DB connections, streams, subscriptions, event listeners)
41	- [ ] Thread/concurrency safety where required
42
43	8. Output the review in this format:
44
45	```
46	## Code Review: [File/System Name]
47
48	### Standards Compliance: [X/6 passing]
49	[List failures with line references]
50
51	### Architecture: [CLEAN / MINOR ISSUES / VIOLATIONS FOUND]
52	[List specific architectural concerns]
53
54	### SOLID: [COMPLIANT / ISSUES FOUND]
55	[List specific violations]
56
57	### Web/Software Concerns
58	[List web and software-specific issues found]
59
60	### Positive Observations
61	[What is done well — always include this section]
62
63	### Required Changes
64	[Must-fix items before approval]
65
66	### Suggestions
67	[Nice-to-have improvements]
68
69	### Verdict: [APPROVED / APPROVED WITH SUGGESTIONS / CHANGES REQUIRED]
70	```
71
72	## Protocol
73
74	Architecture vocabulary to use when it helps clarify a finding:
75
76	- Module — unit with an interface and implementation
77	- Deep module — small interface, high leverage behind it
78	- Shallow module — interface nearly as complex as implementation
79	- Deletion test — if deleting a wrapper mostly removes indirection instead of
80	reintroducing complexity in callers, the abstraction may be shallow
81
82	Use this vocabulary to sharpen architectural findings, not to force jargon into
83	every review.
84
85	- Question: Auto-starts from argument (file or directory path); no clarification needed
86	- Options: Skip — single review path
87	- Decision: Skip — verdict is advisory
88	- Draft: Full review shown in conversation only
89	- Approval: Skip — read-only; no files written
90
91	## Output
92
93	Deliver exactly:
94
95	- Risk Tier (Low / Medium / High) with one-sentence justification
96	- Standards & Architecture compliance score (X/6, X/5)
97	- Blocking issues — must fix before merge (or "None")
98	- Suggestions — optional improvements, max 3
99	- Verdict: `APPROVED` / `APPROVED WITH SUGGESTIONS` / `CHANGES REQUIRED`

People who liked this also viewed

6 picks

Type