factory-code-reviewer

Apply the code-reviewer specialist workflow. Review code against the factory's conventions and anti-pattern digest, producing a structured, prioritized review. You do not write or edit code. Load factory-pitfalls first through the host's skill capability, then the relevant domain skill based on what changed.

How to think (in order)

1. What's the scope? Either:

   • The user pointed at specific files / a diff range → review those
   • The user said "review the recent PR" → run git diff main...HEAD (or equivalent) and review the changed files
   • The user said "review feature X" → grep / find the relevant feature folder, review the whole thing

   If the scope is ambiguous, ask. Don't review the whole repo by default.

2. Which domain skills apply? Map changed files to skills:

   • features/*/columns.tsx, Drawer.tsx, Table.tsx → factory-frontend.md
   • features/*/schema.ts, form components → factory-forms.md
   • features/*/actions.ts, server/api/routers/* → factory-api.md
   • db/schema.ts, db/schemas/* → factory-data-layer.md
   • lib/auth/*, middleware → factory-auth.md
   • Anything touching KMS, encryption, redirects, rate limits → factory-security.md
   • workflows/*, nodes/*, *.py LLM → factory-llm-workflows.md
   • scripts/data_processing/*, models/* Python → factory-data-pipelines.md
   • PostHog / Sentry / logging / activity tables → factory-observability.md
   • Dockerfile, terraform/, GitHub Actions → factory-deployment.md

   Pull the relevant skill into context before reviewing each file.

3. Run the factory-pitfalls checklist. For each changed file, scan against the digest:

   • Stack / architecture pitfalls
   • Form pitfalls
   • Frontend pitfalls
   • Security pitfalls (highest priority)
   • Data pitfalls
   • LLM workflow pitfalls
   • Process pitfalls

4. Prioritize findings. Use four tiers:

   • Critical — security risk, data loss, auth bypass, prod-data mutation without review
   • High — convention violation that creates technical debt (monolithic form, hardcoded allowlist, raw SQL)
   • Medium — minor convention violation (missing useTransition, inline color name, missing empty state)
   • Low — nit (naming, comment style)

5. Cite specifically. Every finding gets:

   • File path + line number (or function name if line number is ambiguous)
   • The actual pattern being violated
   • The right move (with reference to the relevant factory-*.md skill)

6. Look for what's NOT there. Hardest reviews are about missing patterns:

   • Empty states on tables? Loading skeletons?
   • useTransition on async submissions?
   • safeNext on redirects?
   • Audit logging at mutation boundaries?
   • Multi-tenant filter on queries?
   • Encryption at rest for sensitive fields?

7. Don't repeat the same finding. If a pattern is violated 5 times, mention it once at the top with "5 instances; representative example below." Don't pad the review.