Review

When to invoke

Use when asked to "review this PR", "code review", "pre-landing review", or "check my diff".

Proactively suggest when the user is about to merge or land code changes.

Preamble

eval "$(~/.vibestack/bin/vibe-slug 2>/dev/null)" 2>/dev/null || SLUG="unknown"
_LEARN_FILE="${VIBESTACK_HOME:-$HOME/.vibestack}/projects/${SLUG:-unknown}/learnings.jsonl"
if [ -f "$_LEARN_FILE" ]; then
  _LEARN_COUNT=$(wc -l /dev/null | tr -d ' ')
  echo "LEARNINGS: $_LEARN_COUNT entries loaded"
  if [ "$_LEARN_COUNT" -gt 5 ] 2>/dev/null; then
    ~/.vibestack/bin/vibe-learnings-search --limit 5 2>/dev/null || true
  fi
else
  echo "LEARNINGS: none yet"
fi

{{include lib/snippets/session-host.md}}

{{include lib/snippets/decision-brief.md}}

{{include lib/snippets/working-protocols.md}}

{{include lib/snippets/state-protocols.md}}

Step 0: Detect platform and base branch

First, detect the git hosting platform from the remote URL:

git remote get-url origin 2>/dev/null

• If the URL contains "github.com" → platform is GitHub
• If the URL contains "gitlab" → platform is GitLab
• Otherwise, check CLI availability:
• gh auth status 2>/dev/null succeeds → platform is GitHub (covers GitHub Enterprise)
• glab auth status 2>/dev/null succeeds → platform is GitLab (covers self-hosted)
• Neither → unknown (use git-native commands only)

Determine which branch this PR/MR targets, or the repo's default branch if no PR/MR exists. Use the result as "the base branch" in all subsequent steps.

If GitHub:

1. gh pr view --json baseRefName -q .baseRefName — if succeeds, use it
2. gh repo view --json defaultBranchRef -q .defaultBranchRef.name — if succeeds, use it

If GitLab:

1. glab mr view -F json 2>/dev/null and extract the target_branch field — if succeeds, use it
2. glab repo view -F json 2>/dev/null and extract the default_branch field — if succeeds, use it

Git-native fallback (if unknown platform, or CLI commands fail):

1. git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||'
2. If that fails: git rev-parse --verify origin/main 2>/dev/null → use main
3. If that fails: git rev-parse --verify origin/master 2>/dev/null → use master

If all fail, fall back to main.

Print the detected base branch name. In every subsequent git diff, git log, git fetch, git merge, and PR/MR creation command, substitute the detected branch name wherever the instructions say "the base branch" or ``.

---

Pre-Landing PR Review

You are running the /review workflow. Analyze the current branch's diff against the base branch for structural issues that tests don't catch.

---

Step 1: Check branch

1. Run git branch --show-current to get the current branch.
2. If on the base branch, output: "Nothing to review — you're on the base branch or have no changes against it." and stop.
3. Run git fetch origin --quiet && git diff $(git merge-base origin/ HEAD) --stat to check if there's a diff. If no diff, output the same message and stop.

---

Step 1.5: Scope Drift Detection

Before reviewing code quality, check: did they build what was requested — nothing more, nothing less?

1. Read TODOS.md (if it exists). Read PR description (gh pr view --json body --jq .body 2>/dev/null || true).

Read commit messages (git log origin/..HEAD --oneline). If no PR exists: rely on commit messages and TODOS.md for stated intent — this is the common case since /review runs before /ship creates the PR.

1. Identify the stated intent — what was this branch supposed to accomplish?
2. Run git diff origin/...HEAD --stat and compare the files changed against the stated intent.

1. Evaluate with skepticism (incorporating plan completion results if available from an earlier step or adjacent section):

SCOPE CREEP detection:

• Files changed that are unrelated to the stated intent
• New features or refactors not mentioned in the plan
• "While I was in there..." changes that expand blast radius

MISSING REQUIREMENTS detection:

• Requirements from TODOS.md/PR description not addressed in the diff
• Test coverage gaps for stated requirements
• Partial implementations (started but not finished)

1. Output (before the main review begins):

\\\ Scope Check: [CLEAN / DRIFT DETECTED / REQUIREMENTS MISSING] Intent: Delivered: [If drift: list each out-of-scope change] [If missing: list each unaddressed requirement] \\\

1. This is INFORMATIONAL — does not block the review. Proceed to the next step.

---

Plan File Discovery

1. Conversation context (primary): Check if there is an active plan file in this conversation. The host agent's system messages include plan file paths when in plan mode. If found, use it directly — this is the most reliable signal.

1. Content-based search (fallback): If no plan file is referenced in conversation context, search by content:

setopt +o nomatch 2>/dev/null || true  # zsh compat
BRANCH=$(git branch --show-current 2>/dev/null | tr '/' '-')
REPO=$(basename "$(git rev-parse --show-toplevel 2>/dev/null)")
# Compute project slug for ~/.vibestack/projects/ lookup
_PLAN_SLUG=$(git remote get-url origin 2>/dev/null | sed 's|.*[:/]\([^/]*/[^/]*\)\.git$|\1|;s|.*[:/]\([^/]*/[^/]*\)$|\1|' | tr '/' '-' | tr -cd 'a-zA-Z0-9._-') || true
_PLAN_SLUG="${_PLAN_SLUG:-$(basename "$PWD" | tr -cd 'a-zA-Z0-9._-')}"
# Search common plan file locations (project designs first, then personal/local)
for PLAN_DIR in "$HOME/.vibestack/projects/$_PLAN_SLUG" "$HOME/.claude/plans" "$HOME/.codex/plans" ".vibestack/plans"; do
  [ -d "$PLAN_DIR" ] || continue
  PLAN=$(ls -t "$PLAN_DIR"/*.md 2>/dev/null | xargs grep -l "$BRANCH" 2>/dev/null | head -1)
  [ -z "$PLAN" ] && PLAN=$(ls -t "$PLAN_DIR"/*.md 2>/dev/null | xargs grep -l "$REPO" 2>/dev/null | head -1)
  [ -z "$PLAN" ] && PLAN=$(find "$PLAN_DIR" -name '*.md' -mmin -1440 -maxdepth 1 2>/dev/null | xargs ls -t 2>/dev/null | head -1)
  [ -n "$PLAN" ] && break
done
[ -n "$PLAN" ] && echo "PLAN_FILE: $PLAN" || echo "NO_PLAN_FILE"

1. Validation: If a plan file was found via content-based search (not conversation context), read the first 20 lines and verify it is relevant to the current branch's work. If it appears to be from a different project or feature, treat as "no plan file found."

Error handling:

• No plan file found → skip with "No plan file detected — skipping."
• Plan file found but unreadable (permissions, encoding) → skip with "Plan file found but unreadable — skipping."

Actionable Item Extraction

Read the plan file. Extract every actionable item — anything that describes work to be done. Look for:

• Checkbox items: - [ ] ... or - [x] ...
• Numbered steps under implementation headings: "1. Create ...", "2. Add ...", "3. Modify ..."
• Imperative statements: "Add X to Y", "Create a Z service", "Modify the W controller"
• File-level specifications: "New file: path/to/file.ts", "Modify path/to/existing.rb"
• Test requirements: "Test that X", "Add test for Y", "Verify Z"
• Data model changes: "Add column X to table Y", "Create migration for Z"

Ignore:

• Context/Background sections (## Context, ## Background, ## Problem)
• Questions and open items (marked with ?, "TBD", "TODO: decide")
• Review report sections (## VIBESTACK REVIEW REPORT)
• Explicitly deferred items ("Future:", "Out of scope:", "NOT in scope:", "P2:", "P3:", "P4:")
• CEO Review Decisions sections (these record choices, not work items)

Cap: Extract at most 50 items. If the plan has more, note: "Showing top 50 of N plan items — full list in plan file."

No items found: If the plan contains no extractable actionable items, skip with: "Plan file contains no actionable items — skipping completion audit."

For each item, note:

• The item text (verbatim or concise summary)
• Its category: CODE | TEST | MIGRATION | CONFIG | DOCS

Verification Mode

Before judging completion, classify HOW each item can be verified. The diff alone cannot prove every kind of work — items outside the current repo or system are structurally invisible to git diff.

• DIFF-VERIFIABLE — A code change in this repo would manifest in git diff origin/...HEAD. Examples: "add UserService" (file appears), "validate input X" (validation logic appears), "create users table" (migration appears).
• CROSS-REPO — Item names a file or change in a sibling repo (e.g. ~/Development//docs/dashboard.md). The current diff CANNOT prove this.
• EXTERNAL-STATE — Item names state in an external system: managed-DB config/RLS, DNS records, hosting env vars, OAuth allowlists, third-party SaaS. The current diff CANNOT prove this.
• CONTENT-SHAPE — Item requires a file to follow a specific convention. In this repo: diff-verifiable. In another repo or system: see CROSS-REPO / EXTERNAL-STATE.

Verification dispatch:

• DIFF-VERIFIABLE → cross-reference against the diff (next section).
• CROSS-REPO → if the sibling repo is reachable on disk (try ~/Development//, ~/code//, the parent of the current repo), run [ -f ]. File exists → DONE (cite path). Missing → NOT DONE (cite path). Path unreachable → UNVERIFIABLE (cite the manual check).
• EXTERNAL-STATE → UNVERIFIABLE. Cite the system and the specific check the user must perform.
• CONTENT-SHAPE in another repo → if the file exists, run any project-detected validator (see below) before falling back to UNVERIFIABLE. Pass → DONE; fail → NOT DONE (cite output). No validator available: UNVERIFIABLE, citing both the path and the convention to confirm.

Path concreteness rule. If a plan item names a concrete filesystem path (absolute, ~/..., or /), it MUST be classified DONE or NOT DONE based on [ -f ]. UNVERIFIABLE is only valid when the path is genuinely abstract ("DNS record", "managed-DB allowlist") or the sibling root is unreachable on this machine. "I don't want to check" is not unreachable.

Validator detection. Before falling back to UNVERIFIABLE on a CONTENT-SHAPE item, scan the target repo's package.json for a script matching validate-*, check-docs, lint-*, or similar. If found, invoke it with the relevant path argument. A passing validator promotes the item from UNVERIFIABLE to DONE; a failing one demotes it to NOT DONE.

Honesty rule. Do NOT classify an item DONE just because related code shipped. Code that handles a deliverable is not the deliverable. When in doubt between DONE and UNVERIFIABLE, prefer UNVERIFIABLE — better to surface a confirmation prompt than silently miss a deliverable.

Cross-Reference Against Diff

Run git diff origin/...HEAD and git log origin/..HEAD --oneline to understand what was implemented.

For each extracted plan item, run the verification dispatch from the previous section, then classify:

• DONE — Clear evidence the item shipped. Cite the specific file(s) changed in the diff for DIFF-VERIFIABLE items, or the verified path that exists for CROSS-REPO items with a reachable sibling repo.
• PARTIAL — Some work toward this item exists but it's incomplete (e.g., model created but controller missing, function exists but edge cases not handled).
• NOT DONE — Verification ran and produced negative evidence (file missing, code absent in the diff, sibling-repo file confirmed absent).
• CHANGED — The item was implemented using a different approach than the plan described, but the same goal is achieved. Note the difference.
• UNVERIFIABLE — The diff and any reachable sibling-repo checks cannot prove or disprove this. Always applies to EXTERNAL-STATE items and to CROSS-REPO items where the sibling repo isn't reachable. Cite the specific manual verification the user must perform.

Be conservative with DONE — require clear evidence. A file being touched is not enough; the specific functionality described must be present. Be generous with CHANGED — if the goal is met by different means, that counts as addressed. Be honest with UNVERIFIABLE — better to surface items the user must manually confirm than silently classify them DONE.

Output Format

PLAN COMPLETION AUDIT
═══════════════════════════════
Plan: {plan file path}

## Implementation Items
  [DONE]      Create UserService — src/services/user_service.rb (+142 lines)
  [PARTIAL]   Add validation — model validates but missing controller checks
  [NOT DONE]  Add caching layer — no cache-related changes in diff
  [CHANGED]   "Redis queue" → implemented with Sidekiq instead

## Test Items
  [DONE]      Unit tests for UserService — test/services/user_service_test.rb
  [NOT DONE]  E2E test for signup flow

## Migration Items
  [DONE]      Create users table — db/migrate/20240315_create_users.rb

## Cross-Repo / External Items
  [DONE]          Add dashboard doc — ~/Development/other-repo/docs/dashboard.md (file exists)
  [UNVERIFIABLE]  DNS-only mode for dashboard.example.com — confirm in your DNS provider

─────────────────────────────────
COMPLETION: 5/9 DONE, 1 PARTIAL, 1 NOT DONE, 1 CHANGED, 1 UNVERIFIABLE
─────────────────────────────────

Fallback Intent Sources (when no plan file found)

When no plan file is detected, use these secondary intent sources:

1. Commit messages: Run git log origin/..HEAD --oneline. Use judgment to extract real intent:

• Commits with actionable verbs ("add", "implement", "fix", "create", "remove", "update") are intent signals
• Skip noise: "WIP", "tmp", "squash", "merge", "chore", "typo", "fixup"
• Extract the intent behind the commit, not the literal message

1. TODOS.md: If it exists, check for items related to this branch or recent dates
2. PR description: Run gh pr view --json body -q .body 2>/dev/null for intent context

With fallback sources: Apply the same Cross-Reference classification (DONE/PARTIAL/NOT DONE/CHANGED) using best-effort matching. Note that fallback-sourced items are lower confidence than plan-file items.

Investigation Depth

For each PARTIAL or NOT DONE item, investigate WHY:

1. Check git log origin/..HEAD --oneline for commits that suggest the work was started, attempted, or reverted
2. Read the relevant code to understand what was built instead
3. Determine the likely reason from this list:

• Scope cut — evidence of intentional removal (revert commit, removed TODO)
• Context exhaustion — work started but stopped mid-way (partial implementation, no follow-up commits)
• Misunderstood requirement — something was built but it doesn't match what the plan described
• Blocked by dependency — plan item depends on something that isn't available
• Genuinely forgotten — no evidence of any attempt

Output for each discrepancy:

DISCREPANCY: {PARTIAL|NOT_DONE} | {plan item} | {what was actually delivered}
INVESTIGATION: {likely reason with evidence from git log / code}
IMPACT: {HIGH|MEDIUM|LOW} — {what breaks or degrades if this stays undelivered}

Learnings Logging (plan-file discrepancies only)

Only for discrepancies sourced from plan files (not commit messages or TODOS.md), log a learning so future sessions know this pattern occurred:

~/.vibestack/bin/vibe-learnings-log '{
  "type": "pitfall",
  "key": "plan-delivery-gap-KEBAB_SUMMARY",
  "insight": "Planned X but delivered Y because Z",
  "confidence": 8,
  "source": "observed",
  "files": ["PLAN_FILE_PATH"]
}'

Replace KEBAB_SUMMARY with a kebab-case summary of the gap, and fill in the actual values.

Do NOT log learnings from commit-message-derived or TODOS.md-derived discrepancies. These are informational in the review output but too noisy for durable memory.

Integration with Scope Drift Detection

The plan completion results augment the existing Scope Drift Detection. If a plan file is found:

• NOT DONE items become additional

…

Source & license

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

• Author: timurgaleev
• Source: timurgaleev/vibestack
• License: MIT

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