Code Review And Quality Skill 安全审计

910Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers five axes: correctness, readability, architecture, security, and performance.11

141142### Step 1: Understand the Context143144Before looking at code, understand the intent:145146```147- What is this change trying to accomplish?148- What spec or task does it implement?149- What is the expected behavior change?150```151

192193### Step 5: Verify the Verification194195Check the author's verification story:196197```198- What tests were run?199- Did the build pass?200- Was the change tested manually?201- Are there screenshots for UI changes?202- Is there a before/after comparison?203```204

204205## Multi-Model Review Pattern206207Use different models for different review perspectives:208209```210Model A writes the code211    │212    ▼213Model B reviews for correctness and architecture214    │215    ▼216Model A addresses the feedback217    │218    ▼219Human makes the final call220```221

230231## Dead Code Hygiene232233After any refactoring or implementation change, check for orphaned code:2342351. Identify code that is now unreachable or unused2362. List it explicitly2373. **Ask before deleting:** "Should I remove these now-unused elements: [list]?"238239Don'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.240

280281Part of code review is dependency review:282283**Before adding any dependency:**2841. Does the existing stack solve this? (Often it does.)2852. How large is the dependency? (Check bundle impact.)2863. Is it actively maintained? (Check last commit, open issues.)2874. Does it have known vulnerabilities? (`npm audit`)2885. What's the license? (Must be compatible with the project.)289290**Rule:** Prefer standard library and existing utilities over new dependencies. Every dependency is a liability.291

2932941. **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.2952. **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.2963. **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.2974. **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.2985. **Keep the lockfile honest.** Commit it, review its diff, and never hand-edit it. The lockfile is the thing that actually pins what ships.299