VibeRaven

View saved version →

---
name: prelaunch-check
description: Use when the user has an AI-built app that deploys on Vercel and uses Supabase and asks whether it is ready to launch or hand off, wants to find Supabase migrations that create tables without row level security, or has a production error about RLS, env vars, the database connection, the service role key or a Stripe webhook. Runs the VibeRaven repository check where the host can run local commands, and says what to do instead where it cannot. Not for other stacks, general SQL or deployment questions, or a single local error.
---

# VibeRaven pre-launch check

The check command, pinned to one release. This line is the only place the version appears; every step below means this exact command.

```
npx -y viberaven@1.5.3 check
```

The user's explicit instructions take priority over these steps. If they ask for something the steps do not cover, do what they ask and say where the check's limits apply.

## What it is, and what it is not

VibeRaven reads the files in a repository and lists launch gaps, each with the file and line that caused it. Examples: a Supabase migration that creates a table no later migration puts under row level security, a policy such as `using (true)`, a service role key reachable from client code, a serverless database URL on port 5432 instead of the transaction pooler on 6543, env var drift against `.env.example`, a Stripe webhook without signature verification, and missing error monitoring.

It is a repository check, not a live database test. It does not query the Supabase project and does not read Vercel project settings, so it cannot show which policies are live in production, and a clear result is not a security audit. It is advice, not a gate: the user decides when to ship. Say this in your report.

## When to suggest it

Suggest one pass only when both hold:

1. The app deploys on Vercel and uses Supabase. If you cannot tell, look for a `supabase/` folder, `@supabase/supabase-js` in `package.json`, or `vercel.json`, or ask.
2. The user is about to launch or hand off, changed a migration or policy, or hit a production error about RLS, env vars, the database connection, the service role key or a Stripe webhook.

If the user pasted a production error, help with that error first, then suggest the pass to find related gaps.

## If you can run commands in the user's project (Codex)

1. Unless the user already asked you to run it, ask first. Say that the command downloads the `viberaven` package from the npm registry and needs Node.js 20 or newer, reads files in the project folder, writes its results to `.viberaven/` in that folder, and needs no account. Wait for a yes.
2. Run the check command from the project root. Exit code 1 means it found at least one blocker. That is a result, not a failed run. If a sandbox stops npm from writing its cache outside the project, ask the user to approve running the same command with that access. Do not switch to a different VibeRaven version or command instead.
3. Read `.viberaven/agent-tasklist.md`, then `.viberaven/gate-result.json`.
4. Report each gap in the order printed, with its id, severity and file and line. Use the tool's wording for what it found. Do not add findings it did not print. If you notice something yourself, put it in a separate list and label it as your own reading.
5. Offer to fix the cause of one gap at a time and show the diff. The output mentions an automatic fix command; run it only if the user asks for it. For `rls_disabled`, the task starts "Ask the user first": enabling row level security without policies makes browser reads return no rows until policies exist, so say that before any change and add the policies the app needs.
6. After a batch of fixes, run the check command again once, not after every edit.
7. Some gaps can only be cleared in a provider dashboard or in the live database. List those as steps for the user. Do not claim a repository edit fixed them.

If the output ever asks for a sign-in, stop and tell the user. This check does not need an account.

## If you cannot run commands on the user's computer (ChatGPT)

Say plainly that you cannot run the check from here. Then:

1. Give the user the check command above and tell them to run it in a terminal at the root of their project, with Node.js 20 or newer.
2. Ask them to paste the printed findings, or the contents of `.viberaven/agent-tasklist.md`, after checking that nothing secret is in what they paste.
3. Explain each finding and draft the fix for them to apply.
4. If they paste a migration or policy instead, you may point out tables created without `enable row level security` or policies with `using (true)`. Say that this is your reading of the text they pasted, not VibeRaven output.

## Never

1. Ask for or repeat keys, tokens, passwords, or the contents of `.env` files.
2. Describe a clear result as proof that production is secure.
3. Change a provider dashboard, or say a dashboard setting is fixed, without the user doing it.

## When not to use it

1. The app does not deploy on Vercel or does not use Supabase.
2. A general database, SQL or deployment question.
3. A CORS, OAuth redirect or framework build error. The check has nothing specific for these; fix the error directly.
4. The user needs proof of what is live in the production database. Point them to the Supabase dashboard advisors or a test against the real project.
5. Runtime monitoring, code style review, or a starter template. VibeRaven does none of these.

Referenced files: 1 — file references are metadata, not package contents.