supabase-sentinel

Name: supabase-sentinel
Author: Farenhytee

40stars5forks

How to install supabase-sentinel?

farenhytee/database-sentinel/supabase-sentinel

$npx -y skills add Farenhytee/database-sentinel --skill supabase-sentinel

Installs into the current project.

Summary

Audit any Supabase project for security vulnerabilities, RLS misconfigurations, exposed API keys, auth bypasses, and storage issues. Use this skill whenever the user mentions Supabase security, RLS policies, database security audit, security review, penetration testing a Supabase

Files · 1

View on GitHub

SKILL.md

1	# Supabase Sentinel — backwards-compat shim
2
3	> DEPRECATED. This skill exists only to preserve the original `supabase-sentinel` trigger surface for users who installed it before the multi-backend rename. New audits should use the `database-sentinel` skill (one level up at the repo root), which handles Supabase identically and adds Firebase, MongoDB, self-hosted Postgres, and self-hosted MySQL.
4	>
5	> Sunset date: TBD — keep at minimum through the next minor release of Database Sentinel. After that, this stub will be removed and `supabase-sentinel` will resolve to the multi-backend skill via skill-name aliasing.
6
7	## What this shim does
8
9	When invoked, this skill:
10
11	1. Loads the parent `database-sentinel` skill's workflow.
12	2. Forces the audit to Supabase only — even if other backends are detected in the working directory, only the Supabase audit runs.
13	3. Behaves identically to the v1 Supabase Sentinel: same 7-step workflow, same 27 anti-patterns (`SB-001..SB-027`), same fix templates, same CI workflow template.
14
15	## How to invoke
16
17	Same as before — say things like:
18
19	- "Audit my Supabase project for security issues"
20	- "Is my Supabase database exposed?"
21	- "Check my RLS policies"
22	- "Run a security review of this Supabase app"
23
24	The shim will dispatch to the multi-backend `database-sentinel` skill with `backend=supabase` pinned.
25
26	## Behavior contract
27
28	The shim must:
29
30	- Run the same 7-step workflow as the v1 Supabase Sentinel.
31	- Produce a report indistinguishable from the v1 output (same scoring, same finding format, same Passing section, same footer).
32	- Reference the same files: `../../backends/supabase/workflow.md`, `../../backends/supabase/anti-patterns.md`, `../../backends/supabase/audit-queries.md`, `../../backends/supabase/fix-templates.md`, `../../assets/ci/github-action-supabase.yml`.
33	- Skip detection of other backends (the user invoked the Supabase-specific skill explicitly).
34
35	The shim must not:
36
37	- Audit Firebase, MongoDB, or self-hosted SQL backends, even if signals are present.
38	- Emit a "cross-backend interactions" section (single-backend mode only).
39	- Mention the rename in the report itself unless the user asks how to migrate. The deprecation notice belongs in tool output / changelog, not in the user-facing audit report.
40
41	## Migration
42
43	Users who want multi-backend coverage should invoke `database-sentinel` instead — same triggers, broader coverage. No project changes are needed; detection picks up the additional backends automatically.
44
45	If only Supabase is in use, `database-sentinel` and `supabase-sentinel` produce identical output. The rename is purely about expanding the trigger surface.
46
47	---
48
49	## Implementation pointer
50
51	The actual workflow lives at `../../backends/supabase/workflow.md`. This file is intentionally thin — it exists so the `supabase-sentinel` skill name continues to resolve until the deprecation window closes.

People who liked this also viewed

6 picks

Type

supabase-sentinel

40stars5forks

View on GitHub

How to install supabase-sentinel?

farenhytee/database-sentinel/supabase-sentinel

$npx -y skills add Farenhytee/database-sentinel --skill supabase-sentinel

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Supabase Sentinel — backwards-compat shim
2
3	> DEPRECATED. This skill exists only to preserve the original `supabase-sentinel` trigger surface for users who installed it before the multi-backend rename. New audits should use the `database-sentinel` skill (one level up at the repo root), which handles Supabase identically and adds Firebase, MongoDB, self-hosted Postgres, and self-hosted MySQL.
4	>
5	> Sunset date: TBD — keep at minimum through the next minor release of Database Sentinel. After that, this stub will be removed and `supabase-sentinel` will resolve to the multi-backend skill via skill-name aliasing.
6
7	## What this shim does
8
9	When invoked, this skill:
10
11	1. Loads the parent `database-sentinel` skill's workflow.
12	2. Forces the audit to Supabase only — even if other backends are detected in the working directory, only the Supabase audit runs.
13	3. Behaves identically to the v1 Supabase Sentinel: same 7-step workflow, same 27 anti-patterns (`SB-001..SB-027`), same fix templates, same CI workflow template.
14
15	## How to invoke
16
17	Same as before — say things like:
18
19	- "Audit my Supabase project for security issues"
20	- "Is my Supabase database exposed?"
21	- "Check my RLS policies"
22	- "Run a security review of this Supabase app"
23
24	The shim will dispatch to the multi-backend `database-sentinel` skill with `backend=supabase` pinned.
25
26	## Behavior contract
27
28	The shim must:
29
30	- Run the same 7-step workflow as the v1 Supabase Sentinel.
31	- Produce a report indistinguishable from the v1 output (same scoring, same finding format, same Passing section, same footer).
32	- Reference the same files: `../../backends/supabase/workflow.md`, `../../backends/supabase/anti-patterns.md`, `../../backends/supabase/audit-queries.md`, `../../backends/supabase/fix-templates.md`, `../../assets/ci/github-action-supabase.yml`.
33	- Skip detection of other backends (the user invoked the Supabase-specific skill explicitly).
34
35	The shim must not:
36
37	- Audit Firebase, MongoDB, or self-hosted SQL backends, even if signals are present.
38	- Emit a "cross-backend interactions" section (single-backend mode only).
39	- Mention the rename in the report itself unless the user asks how to migrate. The deprecation notice belongs in tool output / changelog, not in the user-facing audit report.
40
41	## Migration
42
43	Users who want multi-backend coverage should invoke `database-sentinel` instead — same triggers, broader coverage. No project changes are needed; detection picks up the additional backends automatically.
44
45	If only Supabase is in use, `database-sentinel` and `supabase-sentinel` produce identical output. The rename is purely about expanding the trigger surface.
46
47	---
48
49	## Implementation pointer
50
51	The actual workflow lives at `../../backends/supabase/workflow.md`. This file is intentionally thin — it exists so the `supabase-sentinel` skill name continues to resolve until the deprecation window closes.

People who liked this also viewed

6 picks

Type