# Review

> Review code changes and return prioritized, actionable findings

- **Type:** Skill
- **Install:** `agentstack add skill-oevortex-vtx-coding-agent-review`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [OEvortex](https://agentstack.voostack.com/s/oevortex)
- **Installs:** 0
- **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml)
- **Latest version:** 0.1.0
- **License:** Apache-2.0
- **Upstream author:** [OEvortex](https://github.com/OEvortex)
- **Source:** https://github.com/OEvortex/vtx-coding-agent/tree/main/src/vtx/builtin_skills/code-review/review

## Install

```sh
agentstack add skill-oevortex-vtx-coding-agent-review
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

Review the requested code changes as if you are reviewing another engineer's PR.

User-provided target or constraints (honor these):
$ARGUMENTS

## Target selection

- If no target is provided, review the current code changes: staged, unstaged, and untracked files.
- If the user provides a base branch, review the changes that would merge into that branch. Find the merge base and inspect the diff from that commit.
- If the user provides a commit SHA, review only the changes introduced by that commit.
- If the user provides a PR number, PR URL, or text like `PR#68 feat/headless-mode "feat: add non-interactive prompt mode"`, assume the GitHub CLI is available. Use `gh pr view` to inspect PR metadata, resolve the base/head branches, fetch as needed, compute the merge base, and review the PR diff. Do not checkout a different branch unless the user explicitly asks or confirms.
- For PRs, do not assume the head branch exists on `origin`; it may live on a contributor fork. Prefer `gh pr checkout --detach ` only if checkout is acceptable, or fetch the head repository/ref reported by `gh pr view --json headRepository,headRefName` into a temporary remote/ref before diffing.
- For a PR scenario such as `/review PR#68 feat/headless-mode "feat: add non-interactive prompt mode"`, use the PR number/title/branch as hints, verify them with `gh pr view 68`, then review the code changes relative to the PR base branch.

## Review rubric

Only report issues the original author would likely fix if they knew about them.

Flag a finding only when:
- it meaningfully affects correctness, security, performance, reliability, or maintainability;
- it is discrete and actionable;
- it appears introduced by the reviewed change;
- you can identify the affected code path or user scenario;
- it is not merely a style preference, nit, or intentional behavior change.

Do not stop at the first issue. Return all qualifying findings. If there are no findings worth fixing, say so clearly.

## Investigation guidance

Use repository tools to inspect the actual diff and surrounding code. Prefer precise commands such as:
- `git status --short`
- `git diff --staged`
- `git diff`
- `git diff ...HEAD`
- `git show `
- `gh pr view  --json number,title,body,baseRefName,headRefName,url,author`

Read nearby implementation and tests when needed to prove whether a suspected issue is real. Avoid speculative findings.

## Priority rubric

Use these severity levels for finding titles:
- `[P0]` — Drop everything to fix. Blocking release, operations, or major usage. Only use for universal issues that do not depend on assumptions about inputs.
- `[P1]` — Urgent. Should be addressed in the next cycle.
- `[P2]` — Normal. Should be fixed eventually.
- `[P3]` — Low. Nice to have.

## Finding format

For each finding, include:
- priority tag in the title: `[P0]`, `[P1]`, `[P2]`, or `[P3]`;
- concise title;
- file path and line range;
- one short paragraph explaining why this is a bug and when it matters;
- confidence score if useful.

Keep line ranges as short as possible and make sure they overlap the reviewed diff when possible.

End with an overall verdict:
- `patch is correct` if existing code/tests should not break and no blocking issues were found;
- `patch is incorrect` if the patch has blocking correctness, security, reliability, or maintainability issues that should prevent merging.

Do not mark a patch incorrect for non-blocking issues such as style, formatting, typos, documentation nits, or ordinary `[P2]`/`[P3]` follow-ups unless they still indicate the patch should not merge.

Do not fix the code unless the user asks after the review.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [OEvortex](https://github.com/OEvortex)
- **Source:** [OEvortex/vtx-coding-agent](https://github.com/OEvortex/vtx-coding-agent)
- **License:** Apache-2.0

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-oevortex-vtx-coding-agent-review
- Seller: https://agentstack.voostack.com/s/oevortex
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.