just-vibeGeneral · inspect by default
/review
Review a change, selected files, or an entire repository for actionable defects
Use for evidence-backed code review of a diff or current source; github-review handles a remote PR by number or URL with its discussion and checks. Choose a security/domain audit when the requested scope is that specific risk surface.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select review from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv review, /just-vibe review and /jv:review in Claude. See shortcut setup and context examples.
/just-vibe:review Review this branch against main for behavioral regressions./just-vibe:review Review my rebased branch against main where main already has unrelated warnings./just-vibe:review Review supplied diff only; mark missing surrounding source and tests as coverage limits./just-vibe:review Do a general code review of this repository; identify existing bugs and useful improvements without editing the product./just-vibe:review Review the evidence recorder and its callers for output-handling defects.What the agent does
- Select diff, repository or file review from the actual request. For diff review resolve base and head; for repository/file review map relevant entry points, persistence and effect boundaries before sampling implementations.
- Read surrounding contracts and callers, then select only matching security/language/domain guides. Trace input through transformation, side effect and persisted/report output; check the composed behavior as well as individual helpers.
- For each suspected defect establish the input/state trigger, reachable impact and expected invariant. Try to disprove it using existing guards or an isolated legitimate control. Reconfirm locations; distinguish source reasoning, exercised regressions and unavailable runtime evidence.
- Report prioritized actionable findings or an honest no-findings result with coverage limits. Do not fill a quota or repair the code during review. For a follow-up repair request, retain the exact selected findings and exclusions across “continue” messages.
Inputs
- Requested repository, change or file scope, inferred from the current project when unambiguous.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Actionable defects in the requested scope. Attribute introduced regressions only when comparison evidence establishes them; label existing issues separately.
- Writes
- No product edits or external review submission. A code review permits bounded local reproduction with synthetic data in owned temporary fixtures; preserve the reviewed tree and existing user work. Repair requires a repair request.
- Mode
- Inspect. Select diff review for an explicit base/PR, repository review for a broad request, or file review for named paths. General source review does not require a base revision.
- Prerequisites
- Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
Expected output
- Prioritized findings with locations, triggering conditions, impact, and verification gaps; explicitly state when none are found.
- Severity, location, trigger, impact, proposed correction and verification gap per finding.
How the work is checked
- A demonstrated regression includes a reproducible trigger; a pre-existing unrelated issue is not attributed to the patch.
When to stop or clarify
- Missing base revisions block confident change attribution only; continue a clearly requested current-source review. Do not manufacture findings to fill a template.
Handling missing context
- Infer
- Resolve diff/base for a named PR or branch comparison; otherwise use the current repository or named files and report scope. Inspect callers, contracts and current tests.
- Assume
- For “general code review,” examine current source and important integration boundaries without requiring a clean diff or inventing change attribution.
- Ask
- Ask only if the repository or intended comparison is ambiguous. Missing runtime access limits verification; it does not block source-established findings.
Technical guidance
- Evidence
- Inspect the selected diff/base, repository or file scope, surrounding contracts, callers, tests and generated artifacts.
- Method
- Use the review guide to select relevant security, async, data and compatibility checks; require trigger, reachable impact and location.
- Pitfall
- Style preferences, file length or theoretical edge cases without a trigger are not automatically defects.
- Check
- Challenge each finding with an existing guard or safe control, recheck changed head identity and return zero findings when evidence supports it.
Situational decisions
When the user requests a general repository review: Inspect existing source and cross-module boundaries; no base is required. Existing defects remain reportable without claiming they were introduced by a recent patch.
When the user names files: Limit findings to those files and their necessary callers/contracts; report unexamined areas rather than expanding into an unsolicited audit.
When the head changed while reviewing a diff: Recheck findings against the new diff before reporting.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.