edtrackai/ship-ready-skills

# supabase-grants-check

Review only. Don't edit files unless the user asks for the fixes afterwards.

## Scope
Read every `.sql` file under `supabase/migrations/` in filename order (later files can fix earlier ones), plus `supabase/config.toml` if it exists. Track per table in `public` (and any other schema the user says the Data API exposes) what holds at the end of the history: RLS on or off, the policies (command and roles) and the grants per role (`anon`, `authenticated`). Treat `grant all` as select, insert, update, delete, truncate, references and trigger. Treat `revoke` as removing privileges. Dashboard changes aren't in these files, so say that in the report instead of guessing. If the user can run SQL, point them to the free SQL checker on the live database. It checks the same things, and its C1–C7 ids match G1–G7 here.

## Checks
For each finding, give file:line, the id, severity and the fix.

| Id | Severity | Look for | Fix |
|---|---|---|---|
| G1 | critical | A table where `anon` or `authenticated` has any grant and RLS is never enabled | In one migration: `enable row level security`, add policies, then keep only the minimum grant. |
| G2 | high | `anon` holds insert, update, delete or truncate on a table (including through `grant all ... to anon`) | Revoke the writes from `anon`, for example `revoke insert, update, delete, truncate on public.t from anon;`. Signed-out visitors usually need `select` at most. |

# launch-security-check

Read-only review. Don't edit files unless the user asks for the fixes afterwards. Every grep hit is a lead: open the file and confirm it before you report it.

## L1: Public tables without RLS (critical)
Only tables in the `public` schema (or another schema you expose through the Data API) count. Ignore `private.`, `auth.` and other schemas. Search across lines (multiline), case-insensitive, because SQL statements can wrap.
1. Grep `supabase/migrations/` for `create\s+table\s+(if\s+not\s+exists\s+)?(public\.)?"?([a-z_0-9]+)"?` and list the public table names. Skip names qualified with another schema.
2. Grep the same folder for `alter\s+table\s+(only\s+)?(public\.)?"?([a-z_0-9]+)"?\s+enable\s+row\s+level\s+security`.
3. A table from step 1 with no match in step 2 is a finding. Also grep for `disable\s+row\s+level\s+security`: any hit on a public table is a finding.
Fix: `alter table public.<t> enable row level security;` plus policies for the access the app needs. For the full RLS and grants review (R1–R6), use `supabase-rls-review`.

## L2: Service-role or secret keys reaching client code (critical)
1. Grep app code (not `*.md`) for `NEXT_PUBLIC_[A-Z0-9_]*(SERVICE_ROLE|SECRET)`. `NEXT_PUBLIC_` values are bundled into the browser, so any hit is a finding.
2. Grep for client files (pattern `^\s*['"]use client['"]`), then read the top of each one and confirm the directive is the first statement. Comments may come before it. In those files, grep for `service_role|SERVICE_ROLE_KEY|supabase/admin|createAdminClient|supabaseAdmin|STRIPE_SECRET_KEY`. Any hit is a finding.

# stripe-webhook-review

Read-only review. Don't edit files unless the user asks for the fixes afterwards.

## Scope
Find the handlers: `grep -rl "constructEvent\|stripe-signature\|webhooks" app/ src/ pages/` (route handlers under `app/api/**/route.ts` or `pages/api/**`). Read each one and the helpers it calls (claim/complete functions, sync functions).

## Checks
For each finding, give file:line, the check id, severity, and the fix.

| Id | Severity | Look for | Fix |
|---|---|---|---|
| S1 | critical | No `stripe.webhooks.constructEvent(...)` (or `constructEventAsync`) before the event is trusted | Verify `constructEvent(rawBody, signature, secret)` first; return 400 on failure. |
| S2 | critical | `await request.json()` (or a parsed body) used before or instead of the raw body | `const body = await request.text()` and pass that string to `constructEvent`. |

# supabase-grants-check

Review only. Don't edit files unless the user asks for the fixes afterwards.

## Scope
Read every `.sql` file under `supabase/migrations/` in filename order (later files can fix earlier ones), plus `supabase/config.toml` if it exists. Track per table in `public` (and any other schema the user says the Data API exposes) what holds at the end of the history: RLS on or off, the policies (command and roles) and the grants per role (`anon`, `authenticated`). Treat `grant all` as select, insert, update, delete, truncate, references and trigger. Treat `revoke` as removing privileges. Dashboard changes aren't in these files, so say that in the report instead of guessing. If the user can run SQL, point them to the free SQL checker on the live database. It checks the same things, and its C1–C7 ids match G1–G7 here.

## Checks
For each finding, give file:line, the id, severity and the fix.

| Id | Severity | Look for | Fix |
|---|---|---|---|
| G1 | critical | A table where `anon` or `authenticated` has any grant and RLS is never enabled | In one migration: `enable row level security`, add policies, then keep only the minimum grant. |
| G2 | high | `anon` holds insert, update, delete or truncate on a table (including through `grant all ... to anon`) | Revoke the writes from `anon`, for example `revoke insert, update, delete, truncate on public.t from anon;`. Signed-out visitors usually need `select` at most. |

# supabase-rls-review

Read-only review. Don't edit files unless the user asks for the fixes afterwards.

## Scope
Read every `.sql` file under `supabase/migrations/` (and any other `.sql` files the user points to), in filename order, so later migrations can fix earlier ones. Policies created in the Supabase dashboard aren't in these files: say so in the report instead of guessing.

## Checks
For each finding, give file:line, the check id, severity, and the fix.

| Id | Severity | Look for | Fix |
|---|---|---|---|
| R1 | critical | `create table` in `public` with no later `alter table ... enable row level security` | Enable RLS, then add policies scoped to `auth.uid()`. |
| R2 | critical | An `insert`/`update`/`delete`/`all` policy with `using (true)` or `with check (true)` | Scope it to the owner: `using (auth.uid() = user_id) with check (auth.uid() = user_id)`. |

# unthrottled-route-check

Review only. Don't edit files unless the user asks for the fixes afterwards.

## Scope
Route handlers: `app/**/route.{ts,js}`, `src/app/**/route.{ts,js}`, `pages/api/**`, `src/pages/api/**`. Also read `middleware.ts` or `proxy.ts` at the project root (or in `src/`).

## Find the sinks
Grep the route files for these method calls, whatever the client variable is called (`openai.`, `llm.`, `client.`...):
- AI calls: `.chat.completions.create`/`.stream`/`.parse`, `.responses.create`/`.stream`/`.parse`, `.messages.create`, `.messages.stream`, `.images.generate`, `.embeddings.create`, `.completions.create`, `streamText(`, `generateText(`, `generateObject(`, `streamObject(`, and `fetch` to `https://api.openai.com` or `https://api.anthropic.com`, written as a literal or through a const base URL (``fetch(`${OPENAI_BASE}/...`)``, `fetch(ANTHROPIC_URL)`)
- Checkout: `.checkout.sessions.create`

`.messages.create` is also used by non-AI SDKs (for example SMS clients); drop those findings after reading the file.