Skill

Skill GerardoRdz96/rlsgate/skill

The Supabase deploy-gate that runs where you vibe-code. Static OSS scanner for the RLS/secret holes that leak vibe-coded apps — CLI + Claude Code skill + GitHub Action.

Install

npx -y skills add GerardoRdz96/rlsgate --skill skill

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Run the rlsgate pre-deploy security gate on a Supabase-backed project. Use when about to deploy a vibe-coded / Supabase / Lovable / Bolt / Cursor app, or when the user asks to check for RLS holes, exposed secrets, anon-readable tables, public buckets, or unverified webhooks before shipping.

SKILL.md

2.4 KB, as published. Nobody here has run it

rlsgate — pre-deploy security gate

Run rlsgate against the project, bring the findings into the conversation, and help fix the blocking ones before the user ships. Detection is deterministic; you only reason over the findings and propose fixes — never claim a hole exists that rlsgate did not report.

Steps

Run the scan from the project root. Prefer JSON so you can reason over it:
```
rlsgate scan . --json          # if installed
# or, zero-install:
uvx rlsgate scan . --json
# or, from a source checkout:
python -m rlsgate scan . --json
```
If rlsgate is not installed, install it first: pip install rlsgate (add [ai] for AI-drafted fixes).
Summarize the result for the user: the counts by severity and a one-line-per-finding list (severity, rule, file:line, title). Lead with CRITICAL and HIGH.
For each blocking finding (CRITICAL/HIGH by default), explain in plain language why it leaks (from the finding's detail) and propose the concrete fix (from fix). Open the cited file:line, show the exact change, and apply it only after the user agrees — rlsgate's deterministic finding is the source of truth; never auto-apply a fix blind.
MEDIUM/LOW findings are review notes (often intended-public tables). Surface them, but don't block on them — ask the user to confirm the exposure is intentional.
Re-run rlsgate scan . after fixes and confirm the gate is green (exit 0) before the user deploys.

Notes

rlsgate is static and finite — a clean run means "none of the known high-signal holes are present," not "this app is secure." Say so; never imply a full audit.
The Supabase anon key is public by design and is never flagged; only the service_role key is.
Gitignored secret files are correct hygiene and are not flagged; a NEXT_PUBLIC_/VITE_ secret is flagged even if gitignored, because it inlines into the browser bundle.
Exit codes: 0 clean (or only sub-threshold findings) · 1 blocking findings · 2 usage error. Tune the gate with --fail-on critical|high|medium|low.