avav25/code-review
plugin/skills/code-review/SKILL.md
Use this skill when reviewing a pull request, merge request, or code change before merge, conducting an architecture review, auditing code for security/performance/quality, or running a pre-merge quality gate — including when applied by a Reviewer or QA subagent — to produce a verdict (APPROVE / REQUEST_CHANGES / COMMENT) using Google's eng-practices framing (code health over perfection) and conventional comments vocabulary (nit / suggestion / issue / praise). Distinct from /security-scan (no dependency CVE scan) and /security-audit (no full OWASP audit).
$ install --global
skillsauthnpx skillsauth add avav25/ai-assets code-reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 23, 2026, 4:31 AM62.7s3 files scanned
SKILL.md
- name:
- code-review
- description:
- Use this skill when reviewing a pull request, merge request, or code change before merge, conducting an architecture review, auditing code for security/performance/quality, or running a pre-merge quality gate — including when applied by a Reviewer or QA subagent — to produce a verdict (APPROVE / REQUEST_CHANGES / COMMENT) using Google's eng-practices framing (code health over perfection) and conventional comments vocabulary (nit / suggestion / issue / praise). Distinct from /security-scan (no dependency CVE scan) and /security-audit (no full OWASP audit).
<!-- ARCHITECTURAL NOTE: intentional model-invocable companion — deliberately no `context: fork` and no `disable-model-invocation`. This skill is applied by the Reviewer subagent (via `@code-review`) and other workflows; a forked body could not be applied inside a Reviewer/QA subagent, and disabling model-invocation would stop agents auto-loading it on review tasks. Not a defect — do not reclassify. -->
Code Review
Systematic code review skill with layered checklists. Produces consistent, actionable feedback across all review types.
When to Use
- Reviewing pull requests or merge requests
- Conducting architecture reviews
- Auditing code for security, performance, or quality
- Pre-merge quality gates
When NOT to Use
- Writing new code (use
/feature-devor/bugfixinstead) - Validating plugin-shipped AI asset files (use
/plugin-doctorfor plugin self-diagnostic) - Running automated checks before commit (use
/pre-commit)
Reviewer Principles
Adapted from Google's eng-practices "The Standard of Code Review". Primary purpose: improve code health over time, not chase perfection.
Apply at every review:
- Code health over time — does this CL improve the codebase, even if not perfect? If yes, approve. Do not block on hypothetical future improvements.
- Technical facts override preferences — opinion vs fact. If the reviewer prefers style A but the author wrote style B and both are valid, defer to the author. Disagreement on style without a documented standard is non-blocking.
- Forward progress vs importance of suggestions — small improvements should not block merge unless they prevent code health from improving long-term. Convert non-blocking suggestions to follow-up issues.
Effectiveness ceilings (Microsoft Research on code review):
| Signal | Ceiling | Implication | |---|---|---| | Defect-finding rate | Plateaus past ~60-min sessions | Split large CLs | | Throughput | ~200 LoC/hour | Push back on >400 LoC PRs | | Reviewers | 1 sufficient for most CLs | Add a 2nd reviewer only for high-risk changes (auth, payments, schema, infra) |
Review Process
0. Gather Context
Read CLAUDE.md (or AGENTS.md) at the project root to identify:
- Tech stack (determines which language-specific patterns to check)
- Code conventions (naming, structure, formatting rules)
- Architecture patterns in use (helps evaluate structural decisions)
1. Understand the Change
Before reviewing code, answer:
- What is being changed? (feature, bugfix, refactor, dependency update)
- Why is it being changed? (linked issue, PRD, bug report)
- Scope: How many files, which modules, what's the blast radius?
2. Apply Checklists
Use the appropriate checklist(s) based on change type:
| Change Type | Checklists to Apply |
|---|---|
| New feature | review-checklist.md + security-checklist.md |
| Bug fix | review-checklist.md (focus: root cause, regression test) |
| Refactor | review-checklist.md (focus: behavior preservation, tests) |
| API change | review-checklist.md + security-checklist.md |
| Infrastructure | security-checklist.md |
| Dependencies | security-checklist.md (focus: supply chain) |
3. Provide Feedback
Use Conventional Comments vocabulary so each comment signals intent. Format: <label>[(decoration)]: <subject>.
| Label | Use for | Blocks merge? |
|---|---|---|
| praise: | Positive feedback (research links praise to productivity — do not skip) | No |
| nitpick: / nit: | Minor / preference / style | No |
| suggestion: | Concrete change request | Sometimes |
| issue: | Problem requiring change before merge | Yes |
| todo: | Leftover work for a follow-up CL | No |
| question: | Clarification needed | Maybe |
| thought: | Speculative / tangential | No |
| chore: | Small task (e.g., update docs) | No |
Optional decoration: (blocking), (non-blocking), (if-minor). Example:
issue (blocking): SQL query is concatenated, not parameterized — risk of injection.
nit (non-blocking): inconsistent naming — `userId` elsewhere, `user_id` here.
praise: nice extraction of the retry logic into a helper.
Verdict template:
## Review Summary
**Verdict**: APPROVE | REQUEST_CHANGES | COMMENT
### Blocking (issue / suggestion (blocking))
- [ ] [file:line] `issue:` description — why it matters + how to fix
### Non-blocking (suggestion / todo / question)
- [ ] [file:line] `suggestion (non-blocking):` description — rationale
### Nits (nitpick / chore)
- [ ] [file:line] `nit:` description
### Praise
- [file:line] `praise:` what worked well
Rules:
- Every blocking comment must explain why and how to fix
- Link to relevant documentation or standards when applicable
- Include at least one
praise:comment when warranted — do not skip - Never approve code with an open
issue (blocking): - Flag missing tests for new logic paths
Integration
- Follows rules:
Agent(software-engineer)(architecture, code quality) - Used by workflows:
/develop(REVIEW stage),/bugfix(REVIEW stage),/create-pr(PR description quality),/security-audit(line-level security comments) - Companion checklists:
review-checklist.md,security-checklist.md
Related Skills
avav25/knowledge-sync
development
VerifiedTrustedCommunity
Use this skill when running the recurring (daily) knowledge-base rescan for a repo that already has knowledge/.knowledge-sync.yml — the main-thread dispatcher that reads the config, computes the git delta since last_scanned_sha, maps changed paths to affected doc areas, early-exits cheaply when nothing changed, then fans out one Agent(content-writer) per affected area, applies the propose/direct update policy, advances the baseline only on success, and writes an L4 run log — all with the G1 untrusted-content choke-point, secret-scan, deny-list, and budget controls woven in. For first-time setup use /knowledge-sync-init.
1SKILL.mdUpdated May 24, 2026
avav25/knowledge-sync-init
development
VerifiedTrustedCommunity
Use this skill when bootstrapping scheduled knowledge-base sync for a repo that has no knowledge/.knowledge-sync.yml yet — to run one-time setup that detects the knowledge_root from CLAUDE.md/AGENTS.md, maps doc areas to source globs, records opt-in external sources (Linear/Notion/WebFetch, all disabled by default), captures a baseline last_scanned_sha, sets the per-area update policy, generates or seeds knowledge/CONVENTIONS.md, provisions the L4 memory dir, and offers to register the daily routine. Routes ongoing recurring sync operations to /knowledge-sync.
1SKILL.mdUpdated May 24, 2026
avav25/ai-skills-init
tools
VerifiedTrustedCommunity
Use this skill when bootstrapping a target repository to be ai-skills-aware — on the first run of any ai-skills workflow in a fresh repo, when adopting the ai-skills plugin in an existing repo, or after upgrading to a plugin version that adds new memory paths or templates, including when the user does not say "init" but asks to "set up" or "onboard" the repo — to detect codebase type, create CLAUDE.md + AGENTS.md scaffolding, initialize the .ai-skills-memory/ directory tree from L1 templates, and configure .gitignore. Idempotent — safe to re-run. Accepts `--codebase-type <type>` and `--overwrite`. Not for re-initializing only memory — use `/memory-init` instead.
1SKILL.mdUpdated May 18, 2026
avav25/plugin-author
tools
VerifiedTrustedCommunity
Use this skill when extending, repairing, or improving plugin assets, when ingesting a `/feedback` report as a fix-cycle backlog, or when you do not remember which lower-level command is right for the job — the umbrella workflow for ai-skills plugin-asset authoring and maintenance: creating, auditing, fixing, improving, refactoring, and migrating skills, agents, rules, hooks, prompts, schemas, and rubrics inside the plugin. Auto-classifies the request, loads the right knowledge skills (`@prompt-engineering`, `@context-engineering`, `@team-protocols`), and spawns the right subagents (`prompt-engineer`, `system-architect`, `python-engineer`, `software-engineer`, `qa-engineer`, `eval-judge`) via the `Agent` tool.
1SKILL.mdUpdated May 14, 2026