Review
Small, harness-neutral engineering skills for coding agents
npx -y skills add kevinb361/agent-skills --skill reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 13 days oldThe repository was created 13 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.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 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
Perform a read-only review of code changes for concrete bugs, security risks, regressions, performance problems, and missing tests. Use for staged, unstaged, commit, branch, or pull-request diffs.
SKILL.md
1.8 KB, as published. Nobody here has run it
Code review
Review only; do not edit files while this skill is active.
Scope
Determine the requested scope. With no explicit scope, inspect staged changes first, then unstaged changes, then the latest commit. For branch review, find the actual merge base rather than assuming a branch name.
Confirm the working directory before every Git command. Stop if there is no diff to review.
Method
- Read project instructions.
- Inspect the complete diff and changed-file list.
- Read enough surrounding implementation and tests to understand the changed behavior. Read full hand-written files when practical; do not waste context on generated files, lockfiles, or vendored code when a targeted inspection is sufficient.
- Trace callers, data boundaries, error paths, and state transitions affected by the change.
- Check tests for changed behavior, boundaries, and failure paths.
- Report only issues introduced or exposed by the reviewed change.
Prioritize correctness, security, data loss, concurrency, compatibility, resource leaks, operational failure modes, and meaningful performance regressions. Do not report formatting preferences or speculative concerns without a concrete failure scenario.
Findings
Order findings by severity. Each finding must include:
- severity
path:line- the concrete failure or risk
- why the change causes it
- a specific remediation
If no material issue is found, say so and mention any verification gap that limits confidence. Do not claim that code is safe to merge solely because no issue was found.