supabase
@supabase Organization
Public Skills
ask-the-docs
by supabase
Answer questions about the Supabase docs app (apps/docs) using documented architecture, build pipeline, and review-pattern notes, and apply feature-design principles (codebase reuse, coding minimalism) when proposing or critiquing changes. Use when the user asks "how does X work in the docs app?", "where does Y live?", "is this approach OK for the docs app?", or before writing non-trivial changes under apps/docs/ — especially anything touching the MDX pipeline, markdown generation, content components, federated docs, or contributor-facing authoring patterns. Can answer architecture questions with Mermaid diagrams when helpful.
pm-the-docs
by supabase
Docs-PM decision support for the "Write the docs" authoring process — makes audience, stage, and cross-cutting scope calls during the Frame and Shape stages, and helps decide when a docs question needs to self-serve vs. escalate to a docs PM. Use when framing a new docs page or launch, deciding what product stage or audience a feature targets, or judging whether a docs question needs PM sign-off.
review-the-docs
by supabase
Review Supabase docs changes locally in ~/GitHub/supabase/supabase — either an open PR (triage, classify, verify) or your own branch before opening a PR (local self-review). Covers markdown pipeline, MDX content, tutorials, examples, Studio links, and docs tooling. Use when asked to review docs PRs, self-review a draft branch, check who has approved, verify build output, or evaluate supabase/supabase documentation changes.
write-the-docs
by supabase
Draft new or updated Supabase docs content for a feature or launch, grounded in Linear (the ticket plus its product/PM context), a read of the actual code, and the docs style guide once one exists. Use when asked to write docs for a new feature, a launch (e.g. Select 2026), or a Linear ticket that needs net-new content rather than a bug fix. Not for implementing existing docs bug reports — use work-linear-issue for that.
explorer
by supabase
Build and modify Studio Explorer surfaces, including notebooks, chats, SQL snippets, query cells, and their shared toolbar patterns.
react-hook-form
by supabase
Correct React Hook Form usage anywhere in the monorepo — data flow, subscriptions,
studio-ui-patterns
by supabase
Design system UI patterns for Supabase Studio. Use when building or updating
vitest
by supabase
Vitest API and config reference (Jest-compatible) — mocking with vi.*, spies, fake timers, coverage configuration, fixtures, snapshots, and test filtering. Use for Vitest API and configuration questions anywhere in the monorepo; for Studio-specific test strategy and component-test setup, start with studio-testing and studio-mock-api-tests.
studio-testing
by supabase
Testing strategy for Supabase Studio. Use when writing tests, deciding
copywriting
by supabase
Write or audit UI copy (buttons, labels, empty states, error messages, tooltips, form text) anywhere in the monorepo. Load it before shipping or reviewing any user-facing text — including when copy is incidental to the task, like a new feature that adds buttons, toasts, dialogs, or validation messages.
dev-toolbar-review
by supabase
Safety rules for the dev toolbar, PostHog client, and feature flags. Use
safe-sql-execution
by supabase
Use whenever code will build, return, fetch, or execute SQL that runs against a user's real Postgres database — even when the request reads like an ordinary feature or bug fix and never says "security," "injection," or "SafeSqlFragment." This covers: writing or editing any pg-meta function, query builder, or endpoint that builds/returns SQL for database objects (tables, views, functions, DB triggers, indexes, RLS policies); interpolating a schema/table/column/search/route-param value into SQL text; storing, fetching, or re-running SQL that round-trips from the database (a policy's definition, a function/view definition, a snippet's saved content); and any "Run"/"Apply"/"Execute" action that sends SQL to a project's database (SQL editor run-selection, policy editor apply, snippet runner). Load this BEFORE writing such code, not only when reviewing a finished diff. Skip only for changes that never touch SQL text or execution — styling, unrelated data hooks, non-SQL form validation, or UI layout work.
studio-e2e-tests
by supabase
Write and run Playwright E2E tests for Supabase Studio (e2e/studio).
studio-error-handling
by supabase
Error display and troubleshooting pattern for Supabase Studio. Use when
studio-queries
by supabase
React Query conventions for data fetching in Supabase Studio. Use when
telemetry-standards
by supabase
PostHog event tracking standards for Supabase Studio. Use when adding
docs-content
by supabase
Write, edit, organize, and review Supabase content anywhere in apps/docs — guides, explainers, tutorials, troubleshooting entries, reference docs, and partials. Use for MDX/TOML authoring, frontmatter, navigation, terminology, links, code samples, content listings, and docs validation.
clickhouse-logs-queries
by supabase
Write, review, and migrate Supabase logs queries against the ClickHouse-backed logs table (the logs.all.otel analytics endpoint). Use this whenever a task involves Logs Explorer SQL, the log_attributes map, querying a log source (edge_logs, postgres_logs, auth_logs, etc.), translating an old BigQuery cross join unnest(metadata) logs query to ClickHouse, or wiring analytics log SQL in apps/studio/data/logs and apps/studio/components/interfaces/Settings/Logs. Reach for it even when the user just says "logs query", "Logs Explorer", or pastes a BigQuery logs query to convert, not only when they name ClickHouse.
studio-mock-api-tests
by supabase
Component tests for Supabase Studio that mock API requests at the
vercel-composition-patterns
by supabase
React composition patterns that scale. Use when refactoring components with
e2e-studio-tests
by supabase
Run e2e tests in the Studio app. Use when asked to run e2e tests, run studio tests, playwright tests, or test the feature.
supabase
by supabase
"Use when doing ANY task involving Supabase. Triggers: Supabase products (Database, Auth, Edge Functions, Realtime, Storage, Vectors, Cron, Queues); client libraries and SSR integrations (supabase-js, @supabase/ssr) in Next.js, React, SvelteKit, Astro, Remix; auth issues (login, logout, sessions, JWT, cookies, getSession, getUser, getClaims, RLS); Supabase CLI or MCP server; schema changes, migrations, declarative schemas, security audits, Postgres extensions (pg_graphql, pg_cron, pg_vector); debugging and troubleshooting errors or unexpected behavior on Supabase projects (HTTP errors, Postgres errors, RLS surprises, permission denied, schema cache issues, timeouts, Edge Function crashes, Realtime drops, Storage failures) and reading or querying logs (Logs Explorer, ClickHouse)."
supabase-postgres-best-practices
by supabase
"Postgres best practices maintained by Supabase, for Postgres running anywhere. Load this skill BEFORE writing or changing anything that lives in a Postgres database: creating or altering tables and columns (including choosing column types), schema design, migrations and declarative schema files, RLS policies and the tests that verify them, indexes, triggers, database functions, queues and scheduled jobs (pg_cron, pgmq), vector/semantic search (pgvector), and restoring dumps (pg_restore) or importing data. Also load it when diagnosing slow queries, high CPU, timeouts, EXPLAIN plans, connection exhaustion, locking, bloat, or rows visible to the wrong user or tenant. This is not just a performance guide — schema, migration, security, and SQL authoring tasks need these rules too, even for a one-column change or a single query."