Review Supabase docs changes locally in your `supabase/supabase` checkout — 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.
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.
Execute runnable docs snippets and examples inside a disposable Docker Compose sandbox (runner container + local Supabase stack via `supabase start`). Use after Draft or during Self-review when asked to test the docs, fact-check CLI/SQL/code samples, or produce a verification report for a docs PR. Complements review-the-docs build and review checks; does not replace them.
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.
Draft new or updated Supabase docs content for a feature or launch, grounded in product intent (Linear when available), a read of the actual code, and the docs style guide. Use when asked to write docs for a new feature, a product launch, 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. Not for restructuring existing pages — use edit-the-docs for that.
Next.js app router + MDX. Dev server: pnpm dev:docs → http://localhost:3001/docs (the bare / 404s). style-guide/ holds the docs style guide as plain markdown. Load the file you need rather than the whole directory. No tool enforces the guide, so applying it is the author's job, or the skill's. Load these before working. pm-the-docs, write-the-docs, edit-the-docs, ask-the-docs, and review-the-docs back the docs authoring process. See CONTRIBUTING.md for which stage each covers. They apply the style guide above. For architecture questions…
When starting the dev server, run: Full documentation: https://docs.astro.build Consult these guides before working on related tasks: To run a full production build, run: Content lives under src/content/guides/*.{md,mdx}. Keep it plain GitHub-Flavored Markdown: - No custom/JSX components in guide bodies — content is also exported as plain .md (see below), and a component wouldn't survive that export. - For callouts, use GitHub's native alert syntax (> [!NOTE], > [!TIP], > [!IMPORTANT], > [!WARNING], > [!CAUTION]) — the build renders these…
Next.js pages router + TanStack Start (mid-migration, see below), React 19. Dev server: pnpm dev:studio → http://localhost:8082. Load the skills matching the task; stack them when a task spans areas: Studio is migrating from the Next.js pages router (pages/) to TanStack Start (routes/). Both runtimes ship side-by-side; the STUDIOFRAMEWORK env var selects which one pnpm dev/build runs (default: next, resolved in scripts/dispatch.js). Full route map and strategy: TANSTACKMIGRATION.md.
You are a code reviewer for a large TypeScript/Next.js/React monorepo. Your reviews must be low-noise and high-signal. The team acts on fewer than 20% of default Copilot suggestions, so every comment you leave must earn its place. Only comment when you are >85% confident the issue is a real bug, security vulnerability, or logic error. If you are unsure, do not comment. Silence is better than noise. Our CI pipeline already validates the following. Never comment on these topics: This…
Plain text files in a repository that tell a coding agent how the project works: commands to run, conventions to follow and things to avoid. CLAUDE.md, AGENTS.md, cursor rules and skills are the common kinds.
CLAUDE.md or AGENTS.md?
CLAUDE.md is read by Claude Code. AGENTS.md is an open format that Codex, Cursor and other agents read. Many projects keep one and point the other at it.
What is a skill?
A folder with a SKILL.md that describes one capability, such as filling PDFs or reviewing code. The agent loads it only when the task calls for it.
Can I search my own team's files too?
Your agents already can, over MCP, limited to the files you're allowed to read. Searching them from this page is coming.
SupabaseSkill