Review

Review

Review code changes on the current branch by first reading checkpoint transcripts to understand the intent behind each change, then auditing the actual diff for issues. This produces an intent-aware review that catches mismatches between what the developer wanted and what the code actually does.

Response Format

Begin the first response to this skill invocation with the line:

Entire Review:

followed by a blank line, then the content.

• Apply the header to the first response of the invocation only. Do not re-print it on follow-up turns within the same invocation.
• Do not include the header on error or early-exit responses (e.g. "not a git repository", "no commits found between branch and base").

Rules

1. This is a read-only audit. Do not modify any files during the review.
2. Always show a scope banner before findings so the user knows what is being reviewed.
3. If checkpoint context is unavailable, still perform the review using only the diff and commit messages. Clearly state that the review lacks intent context.
4. Group findings by file. Within each file, order by severity (Critical > High > Medium > Low).
5. Every finding must include a concrete suggestion or explanation, not just flag the issue.
6. After presenting findings, ask the user if they want a fix plan. Do not auto-fix.
7. Do not review generated files, lock files, or binary files unless the user explicitly asks for them.

Process

1. Verify environment

Run entire version to check if the CLI is available. If it is not installed, note that the review will proceed without checkpoint intent context (degraded mode).

2. Detect base ref

Find the mainline branch to diff against. Try these refs in order and use the first that exists:

git rev-parse --verify origin/HEAD 2>/dev/null
git rev-parse --verify origin/main 2>/dev/null
git rev-parse --verify origin/master 2>/dev/null
git rev-parse --verify main 2>/dev/null
git rev-parse --verify master 2>/dev/null

If none exist, tell the user no base ref was found and ask them to specify one.

3. Compute scope

git rev-list --count <base>..HEAD
git diff --stat <base>..HEAD

Record the number of commits and files changed. This forms the scope banner.

4. Gather checkpoint intent (skip in degraded mode)

git log --format='%H%x00%s%x00%b' <base>..HEAD

Extract Entire-Checkpoint: trailer values from commit bodies. Deduplicate checkpoint IDs.

For each unique checkpoint ID (up to 20):

entire checkpoint explain --checkpoint <checkpoint-id> --json --no-pager

Parse the JSON to extract session metadata. For each non-review session in the checkpoint, prefer the summary (intent + outcome). If no summary is available, fall back to the latest user prompt. Truncate each checkpoint detail to 320 characters.

If --json fails for a checkpoint, fall back to the bare human-readable output:

entire checkpoint explain --checkpoint <checkpoint-id> --no-pager

Do not use --full in the review workflow — it produces long narrative text harder for agents to parse in bulk. If that also fails, skip the checkpoint and note it was unavailable.

Additionally, read the current in-progress session (if any) for uncommitted work context:

entire session current --json

If this returns valid JSON, extract last_prompt and files_touched — these represent the intent behind uncommitted changes that are not yet captured in any checkpoint.

Build an intent map: for each file in the diff (committed + uncommitted), collect the relevant intent context from all checkpoints and the active session that touched it.

5. Read the diff

git diff <base>..HEAD

Also include uncommitted changes:

git diff HEAD

For large diffs (>5000 lines total), focus on the most critical files:

• Files with the most changes
• Files mentioned in checkpoint intents
• Source files over generated/config files

Read individual file diffs as needed rather than loading the entire diff at once.