Update to VibeRaven

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,64 +1,26 @@
 ---
 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.
+description: Review Supabase migrations for row-access and grant gaps, inspect a public GitHub app's migrations from a chat without a terminal, or check a local Vercel and Supabase repository before release. Use the tools actually connected. Not for general SQL, unrelated stacks, or proof of live database security.
 ---
 
-# VibeRaven pre-launch check
+# VibeRaven repository review
 
-The check command, pinned to one release. This line is the only place the version appears; every step below means this exact command.
+Choose the smallest useful route for the user's task. A solved question does not require an installation, account or extra tool call. An installed plugin is not proof that its tools are connected or ready.
 
-```
-npx -y viberaven@1.5.3 check
-```
+## Choose an available route
 
-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.
+- Supplied Supabase migration text: if `check_supabase_migrations` is available, pass `sql` for one migration or `files` with each file's `path` and `content`. For a migration sequence, include earlier schema/policy/grant changes. Context needed by the grant rule can include `supabase/config.toml`, `package.json` and browser code. Never send secrets or `.env` contents.
+- Public GitHub repository: if `check_github_repo` is available, pass `repo` and an optional `ref`. It reads public migration files at one resolved commit, within file/byte caps. The result names the commit and coverage. It cannot inspect private repositories or dashboard-only schema. Never ask the user to make a repository public.
+- Local repository and shell: when running the check is requested or already authorized, run `npx -y viberaven@1.7.11 check` in the project root. This downloads an npm package if needed and writes reports under `.viberaven/`; local checks need no sign-in or API key. Respect the environment's execution permissions. Read `.viberaven/agent-tasklist.md`, then `.viberaven/gate-result.json`. Exit 1 with findings is a check result, not a connection failure. If a matching local MCP readiness tool is actually listed, it can provide the local path instead.
+- A named finding: use `explain_finding` when available. Error or setup guidance can use `search_guides`; dated provider guidance can use `recent_provider_changes`, and `provider_playbook` offers the provider packs it actually lists. None of these runs or verifies a provider fix.
+- No suitable tool or access: explain that boundary and give a concrete local command or a short request for nonsecret input only if needed. Do not claim a check ran. Help directly when the available information is sufficient.
 
-## What it is, and what it is not
+## Turn a result into useful work
 
-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.
+Report the finding, source file/line, commit or supplied-text scope, suggested repair and important omissions. Static findings are review candidates, not proof that data is exposed or that production is secure. No findings means only that these rules found none in the inspected input.
 
-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.
+Preserve intentional public reads and the existing ownership/authentication design. Confirm ambiguous access intent before changing policies. Make only authorized local repairs. Keep RLS enabled, retain required allowed access and test denied access too. After a repair, rerun the check on the changed input and test the intended operations in an isolated local/test environment when possible. State what remains unverified. A disappearing finding alone is not proof of a behavioral fix.
 
-## When to suggest it
+When a report link includes a commit, preserve it so the user sees the version that was checked. A later check is a separate action against the new version. Pasted SQL does not create a saved GitHub report; use the findings and fix prompt in the chat when that is enough.
 
-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.
+Continue the user's engineering task after the check. Offer repeat checking when migrations, access rules or relevant deployment configuration change, rather than repeating the same check without changed inputs or a new question. Optional sign-in or Pro continuation is separate from the free checks; never start login, account changes, payment or provider writes for the user without the applicable authorization.