Supabase

**Judgement:** This is a powerful, general-purpose Supabase integration that exposes most of what you can do with Supabase/Postgres (including pgvector) to an agent. It is well-documented and flexible, but comes with **significant safety and data-integrity risks** if given broad access to a production database. **What it does well** - Covers a wide range of operations: raw SQL (`query`), filtered `select`, `insert`/`update`/`upsert`/`delete`, `rpc` for stored procedures, table listing, schema inspection, and `vector-search` using pgvector. - Clearly defined CLI interface with many examples, which is friendly for LLM planning and reduces ambiguity in how to form commands. - Supports vector search with configurable thresholds and limits, and recommends proper pgvector setup (extension, index, similarity function), enabling performant semantic search use cases. **Key risks and limitations** - **Service role key risk:** The recommended `SUPABASE_SERVICE_KEY` has full access and bypasses row-level security. In the hands of an agent, this allows: - Unbounded `DELETE` or destructive `UPDATE` statements. - Arbitrary `query` commands, including `DROP TABLE`, schema changes, or mass data modifications. - **Lack of guardrails:** The skill exposes raw SQL and broad CRUD with no built-in protections such as: - Read-only mode, whitelisting of tables, or query allowlists. - Confirmation steps for destructive commands. - **Injection / prompt-risk surface:** Because the agent composes SQL and filters from natural language, malicious or unintentionally dangerous instructions can directly translate into harmful database operations. - **Operational fragility:** Correct behavior depends on external configuration (Supabase project, pgvector extension, indexes, environment variables, OpenAI API key for embeddings). Misconfiguration will lead to failures that the skill itself does not mitigate. **Recommended scenarios** Use this skill **where high capability is more important than strict safety**, and where you can constrain the environment: - **Staging / development databases** where data loss is acceptable and you want rapid iteration on: - Analytics and reporting via SQL. - Prototyping agent-based backends and CRUD flows. - Experimenting with Supabase + pgvector RAG setups. - **Internal tools and ops agents** with: - Carefully scoped schemas (e.g., a separate DB or schema for the agent). - Preferably restricted keys (anon or custom policies) when possible instead of the full service role key. For **production or sensitive data**, this skill should only be used with: - Strong external safeguards (read-only roles, separate databases/schemas, or middleware that filters SQL). - Clear, enforced policies on which operations the agent is allowed to perform (e.g., analytics only, no `delete`/`update`/raw `query` on critical tables). In short, this skill is **highly capable but low-guardrail**. It is best suited to controlled environments, staging systems, and well-scoped internal automations rather than direct, unconstrained access to critical production databases.