code-review

Perform a structured, rule-driven review of the current working-tree diff, checking for the most critical SaaS security and correctness properties. Non-autonomous: all findings are reported as a prioritized list; nothing is changed without the user's explicit sign-off on each fix.

Phases

1. Get the diff — read the current unstaged and staged changes. If no diff exists, ask the user which files or commits to review. Summarize the scope of the review (N files, N lines changed) before proceeding.
2. Check for secrets — scan all changed files for patterns that look like hardcoded secrets: API keys, JWTs, connection strings, private keys, and Stripe secret keys. Any match is a BLOCKING finding. Cross-check that .env.example uses placeholders and that .gitignore covers .env*.
3. Verify RLS and tenant scoping — for any server action or route handler, confirm that: (a) the Supabase client is initialized with the session cookie (not the service role key unless justified), (b) all queries that touch tenant data include a tenant-scoping filter, and (c) tenant ID is never sourced from unvalidated client input.
4. Validate Stripe handling — for any webhook handler, verify: (a) stripe.webhooks.constructEvent is called with the raw request body and STRIPE_WEBHOOK_SECRET, (b) event types are handled with idempotency (check for a processed-event record or Supabase upsert pattern), and (c) the handler returns 200 quickly and does heavy work asynchronously if needed.
5. Check input validation — confirm that all server actions and route handlers validate inputs with Zod (or equivalent) before any database or Stripe call. Note any handler that accepts any typed input or skips validation.
6. QA coverage advisory (qa-engineer perspective) — scan the list of changed source files and check whether each has a corresponding test file (*.test.*, *.spec.*, or a matching path under e2e/). For every changed file with no accompanying test, note it as a NOTE-level finding with the suggestion: "Consider running /write-tests to add coverage for this file." This check is advisory only — it does not block the review verdict.
7. Security pass advisory (security-engineer perspective) — perform a quick, targeted scan of the diff for the following patterns, each reported as a WARNING unless it overlaps with an already-BLOCKING finding from earlier phases: (a) any token-shaped string that looks like a committed secret not caught by phase 2, (b) server actions or route handlers that read tenant data without an explicit RLS or tenant-scoping guard, (c) server actions or route handlers that accept inputs without Zod validation, and (d) Stripe webhook handlers missing stripe.webhooks.constructEvent. Skip any issue already reported in phases 2–5; this advisory only surfaces NEW test-coverage or security observations not already covered. Close this phase with: "For a comprehensive security review run /security-audit." This advisory does not auto-fix or block; all findings are reported for human review.
8. Report findings — present findings grouped by severity: BLOCKING (must fix before ship), WARNING (should fix), and NOTE (consider fixing). For each finding, include the file path, line reference, and a one-sentence fix suggestion. Under full review, discuss each finding; under lean/solo, present the list and ask for a single go/no-go to apply suggested fixes. Once all findings are resolved or acknowledged, return to the skill that invoked this review (e.g., /build-feature) or continue the current phase.