Code Review
Two roles — request a code review (dispatch reviewer subagent) and receive a code review (process feedback rigorously). Use after each task in planning full mode, before merge, or when stuck
Install
$ agentstack add skill-hnikoloski-imlazy-imlazy-code-review ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README — it links to the public security report.
Links to your public security report.[](https://agentstack.voostack.com/security/report/skill-hnikoloski-imlazy-imlazy-code-review) Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming — see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps — measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
code-review
When to use
- After each task in
planning(full mode) - Before merging a feature
- When stuck (fresh perspective unblocks you)
- After fixing a complex bug
Requesting a review
Step 1: Get git SHAs
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main for pre-merge review
HEAD_SHA=$(git rev-parse HEAD)Step 2: Dispatch code reviewer subagent using the template at code-reviewer.md (next to this skill). Fill in:
{DESCRIPTION}— brief summary of what was built{PLAN_OR_REQUIREMENTS}— what it should do{BASE_SHA}/{HEAD_SHA}— the commit range{GIT_DIFF}— output ofgit diff BASE_SHA..HEAD_SHA
Step 3: Act on feedback
- Critical → fix immediately, re-review
- Important → fix before proceeding
- Minor → note for later
- Reviewer is wrong → push back with technical reasoning and evidence; don't blind-implement
Never skip review because "it's simple". Never ignore Critical issues. Never proceed with unfixed Important issues.
Receiving a review
When you receive code review feedback, apply this process before implementing anything:
- Verify the feedback is technically correct. Read the cited file and line. Does the issue actually exist there?
- Distinguish severity. Critical issues block progress. Important issues should be fixed. Minor issues are optional. If the reviewer didn't label severity, ask for clarification.
- Never blind-implement Critical feedback without checking it first. A reviewer can be wrong. If something feels off, verify with a test or look at the actual code.
- Push back when the reviewer is wrong. "The test at line 42 already covers that edge case — here is the assertion: [paste test]." Technical evidence beats assertion.
- Fix, then re-request review. Don't mark "fixed" without actually running the test suite.
Common pitfalls:
- Implementing all feedback without verifying — can introduce new bugs
- Dismissing feedback without checking — misses real issues
- Treating Minor as Critical — wastes time on low-impact polish
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: hnikoloski
- Source: hnikoloski/imlazy
- License: MIT
- Homepage: https://hnikoloski.github.io/imlazy/
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.