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.
SkillScore83Maintained
Automatic
◆Doc Ops pack
Last verified 9/27/2026
What it changes
Passed 17 of 21 test cases with the skill, and 6 of 21 without it.
Without skill29%
With skill83%
Checks it passed that the model alone missed
The command specified is pnpm lint:mdx.
The response categorizes the pull request as docs tooling.
The ripgrep command searches for Obsidian or vault references using rg -n.
and 12 more in the full report
13 fixed7 passed either way4 still failing0 broke
Pass-rate lift
+54 pp
Tokens
+172%
Agent turns
0%
Response time
-54%
Model gemini-3.6-flashMeasured 9/27/2026v220 of 24 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 13
Prompt
When performing content review on modified files under `apps/docs/content/guides/auth/`, what pnpm lint command is run from `apps/docs` to check MDX syntax?
What was checked, without and with the skill
Checked
Without skill
With skill
The command specified is pnpm lint:mdx.
Missed
Passed
case-15 · gemini-3.6-flash · 9/27/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md397 linessingle file
Review docs PRs
Local review workflow for supabase/supabase docs changes. Classify first, then follow the matching checklist.
Two modes:
Open PR review (default) — triage via gh, checkout, verify, report. Start at Phase 1.
Local self-review — no open PR yet; verify the current branch before opening one. Start at Local self-review.
For implementing docs fixes (Linear tickets, worktrees, platform E2E), use work-linear-issue instead.
Core rules
Classify before reviewing — path patterns determine which checklist applies.
Review stacked PRs bottom-up — each PR may base on the previous branch.
Run verification locally — do not approve from diff alone.
Compare against master when the PR claims to fix missing or broken output.
One report per batch — sequential review, consolidated output at the end.
Separate blockers from nits — type/style notes are suggestions unless output breaks.