Requesting code review
Skill roronoazoroshao369/vibe-coding-os/skills/core/requesting-code-review
Vibe Coding OS — Claude/Codex/Cursor skill framework with 139 skills, 111 commands, 95 templates, 22 tracked sources, 28/28 validation gates PASS. Quality Shield, Engineering Discipline Pack, plugin marketplace.
npx -y skills add roronoazoroshao369/vibe-coding-os --skill requesting-code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 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.
SKILL.md
2.6 KB, 492 tokens by cl100k_base, as published. Nobody here has run it
Skill: Requesting Code Review
Purpose
Package a change for useful review by making scope, intent, diff, risks, and verification evidence easy to inspect.
When to use
Use after a patch is ready for another human or agent pass, before merge readiness, or when a risky decision needs independent scrutiny.
Inputs
Spec or task, implementation plan, current diff, changed files, validation results, known risks, and questions for the reviewer.
Workflow
- Review your own diff first and remove unrelated changes.
- Summarize intent, user-visible behavior, and non-goals.
- List changed files by purpose instead of dumping the diff.
- Provide exact tests/checks run and any failures or limitations.
- Ask focused review questions for risky areas.
- Stop claiming readiness if validation or attribution obligations are unresolved.
Outputs
A review request containing scope, summary, changed files, risks, verification evidence, and specific questions.
Optional: intelligence-map generation
When the change is non-trivial (multiple files, cross-module, shared interface changes), consider including a request for an intelligence map in the review request. Add a note that you would like the reviewer to run code-intelligence-review or vibe-review-intelligence before analysis. This gives the reviewer a structural understanding of the change's reach — call graph, dependency chains, data flow, and test gaps — and surfaces ripple effects that flat line-by-line review may miss.
Optional: incremental mode
If this change has been reviewed before in an earlier iteration, indicate that the reviewer may use incremental review mode. Include the previous review output and baseline diff so the reviewer can compute only what changed since the last round. This avoids re-reading the full change surface and focuses the review on the new delta. Use templates/incremental-review-template.md for the incremental findings.
Failure modes
- Sending a review request without validation status.
- Hiding known risks or failed checks.
- Asking for generic review when a focused question is needed.
- Including noisy or unrelated diff.
- Requesting an intelligence map for a trivial change where the overhead of map construction outweighs insight.
Verification checklist
- Diff was self-reviewed first.
- Review request names scope and non-goals.
- Validation evidence is explicit.
- Open questions are actionable.
Gives 0 of the 12 instructions most code review skills give in 492 tokens
Counted across 610 of the 674 authors here whose files we hold, read 2026-08-06
- push back with technical reasoning if wrongin 60 of 610, across 24 files
- ask for clarification on unclear itemsin 51 of 610, across 16 files
- fix critical issues immediatelyin 45 of 610, across 29 files
- implement one item at a timein 45 of 610, across 11 files
- group findings by severityin 44 of 610, across 43 files
- verify feedback against the codebasein 42 of 610, across 8 files
- dispatch a code reviewer subagentin 39 of 610, across 23 files
- fix important issues before proceedingin 37 of 610, across 22 files
- test each fix individuallyin 35 of 610, across 7 files
- reply in github comment threadsin 33 of 610, across 5 files
- check for security vulnerabilitiesin 31 of 610, across 27 files
- factualize corrections without over-explainingin 30 of 610, across 2 files
Said here and by no other author read
- remove unrelated changes
- summarize intent and non-goals
- provide exact tests run and failures
- ask focused review questions
- stop claiming readiness if validation is unresolved
- request intelligence map for non-trivial changes
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.