jaktestowac/code-review
plugins/code-review/skills/code-review/SKILL.md
Performs a quick, lightweight review of a small diff or single file, giving concise feedback on correctness, readability, tests, and obvious risks. Use when the user asks for a fast sanity-check review of a small change. For test-automation suites, architectural refactors, security-sensitive paths, or multi-file reviews, use the code-review-advanced skill instead.
$ install --global
skillsauthnpx skillsauth add jaktestowac/awesome-copilot-for-testers 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: Jul 8, 2026, 8:17 AM135.0s1 file scanned
SKILL.md
- name:
- code-review
- description:
- Performs a quick, lightweight review of a small diff or single file, giving concise feedback on correctness, readability, tests, and obvious risks. Use when the user asks for a fast sanity-check review of a small change. For test-automation suites, architectural refactors, security-sensitive paths, or multi-file reviews, use the code-review-advanced skill instead.
- argument-hint:
- The diff, file, or snippet to review, plus the goal of the change
- user-invocable:
- true
Quick Code Review
This skill applies a consistent, lightweight assessment to a small code change. It focuses on key principles of code quality:
- Safety (avoid incorrect assumptions; call out uncertain areas)
- Clarity (structuring comments in positive and actionable form)
- Coverage (address correctness, tests, security, performance, readability)
When to Use
- The user asks for a quick review of a small diff, single file, or snippet.
- A change needs a fast sanity check before a fuller review.
- You need a compact checklist for a routine, low-risk change.
For large or multi-file pull requests, legacy audits, test-automation suites, or high-risk paths (auth, payments, data flows), use code-review-advanced instead.
Skill Behavior
- Start with a summary: what is changing, why, and whether the implementation is aligned with goals.
- Categorize findings:
- ✅ Strengths / wins
- ⚠️ Concerns / risks
- 🛠️ Suggestions / improvements
- Provide
short-termfix guidance pluslong-termdesign thoughts. - Flag any missing tests, docs, or standards violations.
- Respect context: mention the module/file/function names (not generic: "the code").
Quick Review Checklist
-
Correctness
- Does the code do what the ticket/PR describes?
- Are edge cases handled (null, errors, concurrency, format)?
- Any regression risk from changed behavior?
-
Maintainability
- Is the implementation easy to read and reason about?
- Are abstractions and naming appropriate?
- Any repeated logic that should be refactored?
-
Testing
- Are unit and integration tests present and relevant?
- Do tests cover both normal and boundary cases?
- Are tests deterministic and fast?
-
Security & Privacy
- Are user inputs validated/escaped and untrusted data treated carefully?
- Any secrets in code, logs, or config?
- Does the change introduce new permissions, cross-origin, or auth gaps?
-
Performance
- Any obvious O(N^2) loops or hot-path allocations?
- Are caching and batching used when appropriate?
- For network I/O, is retry/backoff and timeout handling present?
-
Style/Convention
- Follow team linting rules and style guide (naming, indent, line length).
- Approve clean diff with minimal noise in formatting.
-
Documentation
- Public APIs should be documented.
- Migration notes, config docs, and README changes included if needed.
Output Style
- Keep each comment concise (1-2 sentences plus the issue).
- Use bullet points for multiple issues.
- Use neutral, teammate-first language (
Consider,Could,Wouldinstead ofYou). - Include a final recommendation state:
approve,request changes, orcomment.
Related Skills
code-review-advanced- evidence-driven, severity-ranked review for complex, risky, or multi-file changestech-debt-analysis- when recurring review findings suggest a broader debt assessment
Definition of Done
This skill is complete when:
- the change is summarized with intent and alignment stated
- findings are categorized (strengths, concerns, suggestions) with concrete file/function references
- missing tests or docs are flagged
- a final recommendation (
approve,request changes, orcomment) is given
Related Skills
jaktestowac/testing-agent-skills
testing
VerifiedTrustedCommunity
Tests the customization assets themselves - skills, prompts, custom agents, instructions - the way a product is tested: activation cases that check an asset fires when it should and stays quiet when it should not, output-contract cases, safety cases, collision cases between assets competing for the same trigger, a weighted rubric scored blind, and a baseline-versus-candidate gate before an edit ships. Use when a skill is edited and nobody knows whether behaviour changed, when two skills fight over the same request, when a description is being tuned for discoverability, when a collection has grown past manual spot-checking, or when the request mentions skill evals, prompt regression, or "does this skill actually work".
113SKILL.mdUpdated Aug 29, 2026
jaktestowac/communicating-quality-findings
development
VerifiedTrustedCommunity
Shapes QA output for the person who has to act on it: result and blocker in the first two lines, one decision per report, findings ordered by what they cost, the long artifact in a file and the decisions in the message, and magnitude stated in units the reader can count. Use when a report is accurate but nobody acts on it, when a finding set is too long to read under time pressure, when the same findings must be retold for a developer, a release manager, and an on-call engineer, or when the request mentions "too long", "make this readable", "just tell me what to do", "so what", or "summarize this for stakeholders". Pairs with unslop-answers, which makes the same report honest.
113SKILL.mdUpdated Aug 29, 2026
jaktestowac/verifying-change-coverage
testing
VerifiedTrustedCommunity
Verifies that the lines and branches a change actually touched are executed by tests, using LCOV or Cobertura diff coverage instead of whole-repo percentages, and escalates uncovered high-risk changes into a blocking finding. Use when a pull request needs a coverage gate that unrelated tests cannot satisfy, when total coverage looks healthy but the diff is untested, when wiring diff coverage into CI, or when someone claims a change is covered because the suite is green.
113SKILL.mdUpdated Aug 26, 2026
jaktestowac/unslop-tests
development
VerifiedTrustedCommunity
Cuts AI tells from test code: tests that pass without proving anything, tautological assertions, mock-only tests, hardcoded waits, coverage theater, vague names, swallowed errors, retries used as fixes. Use whenever test code is written, changed, or reviewed, including tests produced as a side effect of a feature task, and when the request mentions "review these tests", "are these tests any good", "this test always passes", "this suite is flaky", or "clean up these tests". Must always apply to test code.
113SKILL.mdUpdated Aug 26, 2026