Code review
AI Ready Software Template for Enterprise Multi-Model AI Context Architecture
npx -y skills add syniol/llm-software-project --skill code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 17 days oldThe repository was created 17 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Step-by-step instructions for performing a structured code review, including the exact checklist, severity classification, and required output format.
SKILL.md
2.8 KB, as published. Nobody here has run it
Code Review Skill
Use this skill when asked to review a diff, PR, or set of changed files. Follow every step in order. Do not skip sections.
Step 1: Establish Context
Before reviewing any code, read the following in order:
- The PR description (or task description if reviewing locally).
.agent/context/CODEBASE-MAP.mdto understand where the changed files fit.- Any referenced ADRs in
.agent/context/adr/if the change touches architecture.
Step 2: Run the Checklist
For every changed file, evaluate each category below. Log every finding with a severity level.
Security (persona: security-auditor)
- No hardcoded secrets, tokens, or credentials.
- All user input validated at the boundary (Zod schema present).
- No raw SQL string concatenation.
- No
dangerouslySetInnerHTMLor equivalent without justification. - Auth/authorisation middleware applied to all new routes.
Correctness
- Does the logic match the stated intent of the PR?
- Are edge cases handled (empty arrays, null values, concurrent requests)?
- Are errors caught and handled, not silently swallowed?
Architecture
- Does the change respect layer boundaries (controller → service → repository)?
- Is there any circular dependency introduced?
- Does it contradict any accepted ADR?
Testing
- Are new behaviours covered by unit tests?
- Do tests follow the
should_X_when_Ynaming convention? - Is coverage maintained above 80%?
Code Style
- Does the code follow
.agent/rules/02-code-style.md? - Are there any TODO/FIXME comments without a ticket reference?
Step 3: Classify & Report Findings
Use this exact output format:
## Code Review Summary
**Files Reviewed:** <count>
**Overall Assessment:** APPROVED | APPROVED WITH COMMENTS | CHANGES REQUESTED
### Findings
| Severity | File | Line | Issue | Recommendation |
|----------|------|------|-------|----------------|
| 🔴 Critical | auth/service.ts | 42 | JWT not validated before use | Add `verifyToken()` call before accessing `req.user` |
| 🟡 Warning | user/controller.ts | 18 | Missing input validation | Add Zod schema for `req.body` |
| 🔵 Note | shared/utils.ts | 7 | Minor naming inconsistency | Rename `getData` to `fetchUserById` for clarity |
Severity Definitions
| Severity | Meaning | Blocks Merge? |
|---|---|---|
| 🔴 Critical | Security vulnerability or data loss risk | Yes |
| 🟠 High | Logic bug or significant architecture violation | Yes |
| 🟡 Warning | Code smell, missing test, style issue | Recommended fix |
| 🔵 Note | Suggestion or minor improvement | No |
Gives 0 of the 12 instructions most code review skills give
Counted across 610 of the 674 authors here whose files we hold, read 2026-08-06
- push back with technical reasoning if wrongin 60 of 610, across 24 files
- ask for clarification on unclear itemsin 51 of 610, across 16 files
- fix critical issues immediatelyin 45 of 610, across 29 files
- implement one item at a timein 45 of 610, across 11 files
- group findings by severityin 44 of 610, across 43 files
- verify feedback against the codebasein 42 of 610, across 8 files
- dispatch a code reviewer subagentin 39 of 610, across 23 files
- fix important issues before proceedingin 37 of 610, across 22 files
- test each fix individuallyin 35 of 610, across 7 files
- reply in github comment threadsin 33 of 610, across 5 files
- check for security vulnerabilitiesin 31 of 610, across 27 files
- factualize corrections without over-explainingin 30 of 610, across 2 files
Said here and by no other author read
- follow every step in order
- do not skip sections
- read the task description first
- read the codebase map for changed files
- read referenced architecture decision records
- evaluate every changed file for each category
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.