Supabase Sentinel — backwards-compat shim

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.

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.

What this shim does

When invoked, this skill:

1. Loads the parent database-sentinel skill's workflow.
2. Forces the audit to Supabase only — even if other backends are detected in the working directory, only the Supabase audit runs.
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.

How to invoke

Same as before — say things like:

• "Audit my Supabase project for security issues"
• "Is my Supabase database exposed?"
• "Check my RLS policies"
• "Run a security review of this Supabase app"

The shim will dispatch to the multi-backend database-sentinel skill with backend=supabase pinned.

Behavior contract

The shim must:

• Run the same 7-step workflow as the v1 Supabase Sentinel.
• Produce a report indistinguishable from the v1 output (same scoring, same finding format, same Passing section, same footer).
• 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.
• Skip detection of other backends (the user invoked the Supabase-specific skill explicitly).

The shim must not:

• Audit Firebase, MongoDB, or self-hosted SQL backends, even if signals are present.
• Emit a "cross-backend interactions" section (single-backend mode only).
• 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.

Migration

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.

If only Supabase is in use, database-sentinel and supabase-sentinel produce identical output. The rename is purely about expanding the trigger surface.

---

Implementation pointer

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.