Code Review And Quality Skill Security Audit
What the author says it does (original text)
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.
No obvious risks found in this check
- Files checked
- 1
- Risks found
- 0
Inside this skill
This Skill is a code-review guide that evaluates changes across correctness, readability, architecture, security, and performance; the provided material contains no executable scripts or installation steps.
View source
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.The process asks the reviewer to understand the change and specification, inspect tests, implementation, and verification, and leave the final decision to a human; these are assessment steps and do not directly modify user files or accounts.
View source
### Step 1: Understand the ContextBefore looking at code, understand the intent:```- What is this change trying to accomplish?- What spec or task does it implement?- What is the expected behavior change?```### Step 5: Verify the VerificationCheck the author's verification story:```- What tests were run?- Did the build pass?- Was the change tested manually?- Are there screenshots for UI changes?- Is there a before/after comparison?```## Multi-Model Review PatternUse different models for different review perspectives:```Model A writes the code │ ▼Model B reviews for correctness and architecture │ ▼Model A addresses the feedback │ ▼Human makes the final call```The Skill explicitly asks reviewers to identify dead code after changes but obtain confirmation before deleting it, reducing the risk of silent file or code removal.
View source
## Dead Code HygieneAfter any refactoring or implementation change, check for orphaned code:1. Identify code that is now unreachable or unused2. List it explicitly3. **Ask before deleting:** "Should I remove these now-unused elements: [list]?"Don't leave dead code lying around — it confuses future readers and agents. But don't silently delete things you're not sure about. When in doubt, ask.The dependency-review section recommends checking maintenance, vulnerabilities, and licensing and reviewing changelogs, test results, and lockfile diffs; it does not instruct automatic dependency installation or upgrades.
View source
Part of code review is dependency review:**Before adding any dependency:**1. Does the existing stack solve this? (Often it does.)2. How large is the dependency? (Check bundle impact.)3. Is it actively maintained? (Check last commit, open issues.)4. Does it have known vulnerabilities? (`npm audit`)5. What's the license? (Must be compatible with the project.)**Rule:** Prefer standard library and existing utilities over new dependencies. Every dependency is a liability.1. **Read the changelog, not just the version number.** Semver is a promise the maintainer may not have kept — a "patch" can carry a behavioral change. For a major bump, read the migration notes and find what breaks.2. **One dependency per change.** Upgrade and merge them individually (or in small related groups). When a bulk bump breaks the build, you've lost which package did it; a single-package change makes the cause obvious and the revert clean.3. **Let the tests decide.** The upgrade is verified by a green suite before *and* after, not by "it installed." If coverage around the dependency's behavior is thin, that gap is the real finding — add a test first.4. **Mind the transitive graph.** Most installed packages are ones nobody chose directly. Review the lockfile diff, not just `package.json`; a single direct bump can pull in dozens of indirect changes.5. **Keep the lockfile honest.** Commit it, review its diff, and never hand-edit it. The lockfile is the thing that actually pins what ships.Files and check records1 files
Coverage and gaps
Content covered in each file
These are the source ranges included in this check, not a guarantee that every issue has been resolved.
SKILL.mdFull text included
This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.
SKILL.mdInstructions
Operations mentioned in code and instructions
Read files
**Watch file size, not just diff size.** A small diff can still push a file past a healthy boundary — around 1000 *total* lines in a single file (distinct from the ~1000 *changed*-lines threshold above) is a common inspection signal, not a hard cap. When a change materially grows an already-large file, ask whether to extract helpers, subcomponents, or modules *first*, before piling more on. Decompose, then add.- A refactor that moves code around without reducing the number of concepts a reader must hold- A change that grows an already-large file instead of decomposing it- New conditionals scattered into unrelated code paths (a missing abstraction)- Lines read
- 397
- File checksum (to compare versions)
- 81167a2e567ce881eb5af1b8c32a3016e54157b9142debe7beef64e22691283c