# Nextjs Supabase Guard

> Use after writing or modifying code in a Next.js + Supabase project, before committing, or when reviewing such a PR — "validate the stack", "full-stack guard", "check the supabase integration". Orchestrates code-quality, react-guard, nextjs-guard, and Supabase-specific skills through a phased workflow. NOT for projects without Supabase (nextjs-guard) or without Next.js (react-guard).

- Skill: `b4r7x/nextjs-supabase-guard` (Agent Skill)
- Install (CLI): `npx skillmds@latest add b4r7x/nextjs-supabase-guard`
- Raw SKILL.md: https://api.skillmd.com/api/skills/b4r7x/nextjs-supabase-guard/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: b4r7x (https://skillmd.com/u/b4r7x)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/b4r7x/nextjs-supabase-guard

---


# Next.js + Supabase Guard

Full-stack validation orchestrator. Loads composable sub-guards and Supabase-specific skills.

## Composable Architecture

This skill is built from independent layers that can also be used standalone:

| Layer | Skill | Standalone? |
|---|---|---|
| Universal | `code-quality` | Yes — any project, any language |
| React | `react-guard` | Yes — any React project |
| Next.js | `nextjs-guard` | Yes — any Next.js project |
| Supabase | This skill | No — requires all above |

## When to Use

- During or after implementing any feature in a Next.js + Supabase project
- After writing or modifying components, actions, queries, middleware
- Before committing — as a final quality gate
- When reviewing your own work

## Workflow

### Phase 1: Load Context

Read the git diff to understand what changed:

```bash
git diff --stat
git diff
```

Also read `CLAUDE.md` in the project root — it contains project-specific conventions that override general best practices.

### Phase 2: Load Skills by Domain

Load skills based on what changed. Always start with the universal layer.

**Always load:**
1. `code-quality` — DRY, KISS, YAGNI, SRP principles

**React (if any .tsx/.jsx changed):**
2. `react-guard` — loads all React skills automatically

**Next.js (if routes, layouts, middleware, or server code changed):**
3. `nextjs-guard` — loads Next.js + React skills automatically

**Supabase + Auth (if auth, queries, or DB-related code changed):**
4. `nextjs-supabase-auth`
5. `supabase-postgres-best-practices`
6. `security-review`

**Styling (if className or CSS changed):**
7. `tailwind-patterns`

**Tests (if test files changed or new code lacks tests):**
8. `test-behavior-not-implementation`

**Code simplification (always):**
9. `anti-slop`
10. `code-simplifier`

### Phase 3: Validate Changes

For each changed file, check against the loaded skills. Report issues grouped by severity:

**BLOCKER** — Must fix before merge:
- Security issues (auth bypass, injection, exposed secrets)
- Broken dependency rule (app/ importing from features/ internals, shared code importing features/)
- `'use client'` on a component that doesn't need interactivity
- Business logic in route files (app/)
- Missing Zod validation in Server Actions
- Hardcoded colors instead of Tailwind theme classes
- DRY violations: 3+ occurrences of the same pattern without extraction
- Throwing exceptions from Server Actions (return errors as data)

**WARNING** — Should fix:
- Anti-patterns from loaded React/Next.js skills
- Over-engineering or AI slop (unnecessary abstractions, defensive code)
- Missing `revalidatePath()` before `redirect()` in actions
- Relative imports going up more than one level
- Memoization issues (unnecessary useMemo/useCallback, missing where needed)
- KISS violations: overly complex solutions for simple problems
- YAGNI violations: building features before they're needed

**INFO** — Consider:
- Simplification opportunities from `code-simplifier`
- Performance patterns from `vercel-react-best-practices`
- Testing gaps
- SRP violations: functions/components doing too many things

### Phase 4: Report

Output a structured report:

```
## Guard Report

### Files reviewed
- list of files

### BLOCKER (X)
- [file:line] description — skill reference

### WARNING (X)
- [file:line] description — skill reference

### INFO (X)
- [file:line] description — skill reference

### Verdict
PASS / PASS WITH WARNINGS / BLOCKED
```

## Example Convention Set to Check

The project's OWN instruction files (CLAUDE.md, AGENTS.md) are the authority — read them first and check what they actually mandate. The list below is an example convention set from a reference project, useful as a default checklist when the project defines none; wherever the project's rules differ, the project wins:

1. **Dependency rule**: `app/ -> features/ -> components/, lib/, types/`
2. **Thin route files**: No business logic in `app/` — import and render only
3. **Feature public API**: Cross-feature imports MUST go through `index.ts`
4. **No relative imports** going up more than one level
5. **Server Components by default** — `'use client'` only when needed
6. **Zod validation** in all Server Actions
7. **Return errors as data** from Server Actions, not exceptions
8. **kebab-case** for all files and directories
9. **`@/` path alias** always — never `../../`
10. **No hardcoded hex colors** — use Tailwind theme classes
11. **DRY** — extract patterns repeated 3+ times
12. **KISS** — simplest solution that works
13. **SRP** — one responsibility per function/component