pre-commit-review

name	pre-commit-review
description	Review local staged and unstaged tracked-file changes before committing or before a pull request exists. Use when the user invokes /pre-commit-review, asks for a pre-commit review, asks to review local changes before commit, or wants a local working-tree review before a PR exists.

Pre-Commit Review

Review the local working-tree diff before a commit exists for review. At activation, announce the skill name and scope in one line:

[pre-commit-review] reviewing local working-tree diff before commit

What this skill does

• Reviews staged plus unstaged tracked-file changes against repo conventions (AGENTS.md), the code-reviewer severity model, and shared review anti-patterns.
• Includes a local UX gate on UI files. When the diff contains *.tsx, *.jsx, *.vue, *.svelte, *.css, *.scss, or *.swift changes, invokes .skills/ux-review/SKILL.md against the same diff and folds any P0/P1 UX findings into the report as blocking findings. P2/P3 UX findings are noted but do not block. A one-line CSS or component tweak triggers the rubric.
• Does not push, comment on PRs, write Quest decision artifacts, or commit on its own. The terminal choice (fix, skip, commit) rests with the user.

Run these checks before reviewing:

1. Verify this is a git repository:
   • Run git rev-parse --is-inside-work-tree.
   • If it fails, stop with: pre-commit-review requires a git repository; no review was run.
2. Refuse during an in-progress merge, rebase, or cherry-pick:
   • Resolve git metadata paths with git rev-parse --git-path MERGE_HEAD, git rev-parse --git-path CHERRY_PICK_HEAD, git rev-parse --git-path rebase-merge, and git rev-parse --git-path rebase-apply.
   • Check the resolved paths, not direct .git/... paths.
   • If any resolved path exists, stop with: pre-commit-review will not review during an in-progress merge/rebase/cherry-pick; finish or abort the operation first.
3. Verify the repository has a HEAD commit:
   • Run git rev-parse --verify HEAD.
   • If it fails, stop with: pre-commit-review requires at least one commit; no review was run.
4. Check for tracked-file changes:
   • Run git diff --cached --quiet -- and git diff --quiet --.
   • If both are quiet, stop with: No staged or unstaged tracked-file diff found; pre-commit review has nothing to review.
5. Warn about untracked files:
   • Run git status --porcelain.
   • If any line begins with ??, say that untracked files are not part of this review until staged and offer to stop so the user can run git add first.

Default review diff:

git diff --no-ext-diff HEAD --

This reviews staged plus unstaged tracked-file changes. Untracked files are not included until they are staged.

Review Process

1. Read AGENTS.md if present and apply repo rules.
2. Read .skills/code-reviewer/SKILL.md for the severity model only:
   • Blocker
   • Must fix
   • Should fix
   • Nit
3. Read .skills/review-anti-patterns.md and apply the shared review anti-pattern guidance.
4. Focus on correctness, security hygiene, tests for touched behavior, maintainability, and commit-readiness.
5. Keep feedback high signal. Omit Nit findings by default unless they are bundled with a higher-value issue or the user explicitly requested nits.

UI/UX Changes

If the review diff (staged plus unstaged tracked changes — same scope this skill already reviews) includes UI files (any of *.tsx, *.jsx, *.vue, *.svelte, *.css, *.scss, or *.swift), also invoke .skills/ux-review/SKILL.md against the same review diff and include any P0/P1 findings in the pre-commit report. P2/P3 UX findings are noted but do not block. The rubric source is .skills/ux-context/resources/ux-stress-test.md.

Do NOT inherit PR-only behavior from code-reviewer:

• No PR comment placement rules.
• No GitHub inline-first review handling.
• No manifest validation Step 0.
• No acceptance-criteria test coverage mapping unless the user provided specific acceptance criteria for the local change.
• No PR Comment output section.
• No GitHub CI, PR creation, PR update, or push workflow.

Output Format

Findings come first. Emit numbered findings in current-review order:

[N] Blocker|Must fix|Should fix|Nit - path:line - finding and concrete fix

Examples:

[1] Must fix - src/app.py:42 - The error branch swallows failed writes, so callers can commit data loss. Fix: return a non-zero result or raise the existing domain exception.

[2] Should fix - tests/test_app.py:18 - The changed validation path has no regression coverage. Fix: add a focused test for the invalid input case.

If there are no findings, say there are no findings and include a short commit-ready note. Do not show fix-oriented choices when there is nothing to fix.

Terminal Decision Flow

After findings, present only the choices that match the review result:

• If there are no findings, show only:
  1. commit
  2. skip
• If findings contain Blocker or Must fix, show:
  1. fix all Must
  2. fix selected [N...]
  3. skip
  4. commit
• If findings contain only Should fix or Nit, show:
  1. fix selected [N...]
  2. skip
  3. commit

If any Blocker or Must fix findings exist, recommend fixing them before commit.

Choice behavior:

• fix all Must: fix all Blocker and Must fix findings that are actionable in the working tree.
• fix selected [N...]: fix only the requested numbered findings.
• skip: leave the working tree unchanged.
• commit: create a local commit only if the user explicitly asks. Use git-commit-assistant where applicable.

These labels are only terminal decision labels. This skill runs outside the Quest pipeline and must not write review_backlog.json or any other Quest decision artifact.

Never push from this skill.