Review Monorepo Diff

Use this skill to review a local diff in tesslio/monorepo without loading the entire repo guidance surface.

Goal

Catch likely review issues early while staying narrow and low-noise.

• Load only guidance relevant to the changed files
• Prefer high-confidence findings over speculative advice
• Avoid re-litigating generated, vendored, or intentionally deferred patterns
• Do not mutate files unless the user explicitly asks for fixes

Inputs

• A local git diff, staged diff, branch diff, or explicit file list
• Optional review scope from the user, such as "pre-push", "backend only", or "forms only"

Workflow

1. Inspect the diff first.
   • Prefer git diff --cached for staged review
   • Otherwise use the diff scope the user asked for
2. List the changed files and group them by concern:
   • apps/backend/**
   • apps/frontend/**
   • packages/**
   • generated or vendored paths such as apps/backend/openapi.json, apps/backend/admin-openapi.json, apps/frontend/src/lib/api/types.d.ts, packages/tileworks-m/**, and generated vendor output
3. Load only the relevant guidance:
   • Backend broad conventions:
     • apps/backend/AGENTS.md
     • apps/backend/tiles/backend-typescript-rules/steering/rules.md
     • apps/backend/tiles/paths/steering/rules.md
     • apps/backend/tiles/ts-utils/steering/rules.md
   • Frontend broad conventions:
     • apps/frontend/AGENTS.md
     • apps/frontend/tiles/frontend-forms/steering/forms.md when the diff touches form code
   • Repo-wide review habit:
     • tiles/code-review/rules/review-after-changes.md if present in the local checkout or installed rules surface
4. Skip irrelevant guidance. Do not load every app or tile by default.
5. Review the diff against the selected guidance and report:
   • clear repo-guidance violations
   • likely behavioral regressions
   • missing tests where the repo conventions strongly imply them
   • generated or vendored file review mistakes
6. Suppress low-signal feedback:
   • style nits unless directly covered by active guidance
   • PR-specific "by design" patterns that are not durable repo guidance
   • speculative refactors
7. If there are no findings, say so clearly.

Routing Heuristics

• apps/backend/src/routes/**:
  • respect sortBy(...) pagination conventions
  • do not require ad hoc 400 response schemas for reply.badRequest()
  • remember default authz failures collapse to 404
• apps/backend/openapi.json, apps/backend/admin-openapi.json, apps/frontend/src/lib/api/types.d.ts:
  • treat as generated outputs
  • do not suggest hand-editing them; fix source schemas/helpers instead
• apps/backend/src/database/repositories/**:
  • apply no-spread-in-map guidance
• apps/backend/test/**:
  • respect existing vi.mock exceptions only where guidance explicitly says a sweep is pending; otherwise prefer dependency injection guidance
• apps/frontend/**:
  • do not suggest local import file extensions
  • prefer semantic Chakra tokens over raw palette tokens
  • use frontend API client and useTesslForm conventions
• packages/tileworks-m/**:
  • treat as vendored from m; recommend upstream fixes instead

Output

Return a concise review:

• findings first, ordered by severity
• include file references
• say explicitly when there are no findings

Do not overwhelm the user with every possible nit.