qcheck

Code Review

Step 0: Apply Auto-Memory

The memory index is already loaded in your system prompt — no re-read needed. As you review, apply the relevant feedback_* entries (analogous code, redundancy patterns, qbcheck-before-reporting, actor-critic review, single-source-of-truth, etc.). When a finding maps to a known memory, cite the entry name in the report so the user can trace the rule.

If a specific memory file looks relevant to a finding, read just that one file from the auto-memory directory listed in the system prompt.

---

Step 1: Gather Changes & Context

1.1 Get Git SHAs

BASE_SHA=$(git merge-base HEAD develop)
HEAD_SHA=$(git rev-parse HEAD)

If git merge-base fails (detached HEAD, or running on develop/main), STOP and ask the user for an explicit base — don't silently fall back to HEAD~1. Reviewing just the last commit on develop is almost never what's wanted; the user usually means a specific PR range, a Jira branch they forgot to switch to, or a tag.

1.2 Gather Diff

git diff --stat $BASE_SHA..$HEAD_SHA
git diff $BASE_SHA..$HEAD_SHA

Also check for unstaged/staged changes not yet committed:

git diff
git diff --cached

1.3 Read Guidelines

Read the review guidelines:

• Project-level: CLAUDE.md in the repository root
• User-level: ~/.claude/CLAUDE.md (user preferences and lessons learned)

1.4 Identify What Was Built

Summarize from the diff and recent commits:

• What feature/fix was implemented
• Which files were changed and why
• The plan or requirements (if a plan file exists in docs/plans/)

---

Step 2: Launch Parallel Review Agents

Deploy BOTH review agents simultaneously in a single message with two Task tool calls:

2.1 Superpowers Code Reviewer

Dispatch using the superpowers:code-reviewer subagent type:

Task(
  subagent_type: "superpowers:code-reviewer",
  description: "Comprehensive code review",
  prompt: |
    You are reviewing code changes for production readiness.

    Your task:
    1. Review: <WHAT_WAS_IMPLEMENTED>
    2. Compare against: <PLAN_OR_REQUIREMENTS> (or "No formal plan -- review based on code quality and correctness")
    3. Check code quality, architecture, testing
    4. Categorize issues by severity
    5. Assess production readiness

    What Was Implemented: <DESCRIPTION>
    Requirements/Plan: <PLAN_REFERENCE>
    Git Range: Base: <BASE_SHA>, Head: <HEAD_SHA>

    Run: git diff --stat <BASE_SHA>..<HEAD_SHA>
    Run: git diff <BASE_SHA>..<HEAD_SHA>

    Review Checklist:
    - Code Quality: separation of concerns, error handling, type safety, DRY, edge cases
    - Architecture: design decisions, scalability, performance, security
    - Testing: tests test logic (not mocks), edge cases covered, integration tests
    - Requirements: all plan requirements met, no scope creep, breaking changes documented
    - Production Readiness: migrations, backward compatibility, documentation

    Output Format:
    ### Strengths
    ### Issues (Critical / Important / Minor with file:line references)
    ### Recommendations
    ### Assessment: Ready to merge? [Yes/No/With fixes]
)