Edit the docs

Improves existing Supabase docs pages: structure, order, connective text, and clarity.

Not this skill: write-the-docs drafts net-new content or product-grounded rewrites from intent and code. review-the-docs covers lint, build, and PR triage.

Output is one pull request, with one change type per commit. A reviewer reads the style diff apart from the structure diff without holding several PRs in their head. Split into a stack of PRs only when the requester asks for one, or approves the split you offer because the diff turned out large. Phase 0 covers when to raise it, and reference/stacked-prs.md covers the mechanics.

Core rules

1. Read before you rewrite. Open the target page and nearby pages of the same type. Name the reader's goal and the page type before moving sections.
2. Don't invent product truth. Verify it, in its own PR. Style and structure work preserves behavior claims, UI labels, and positioning as written. Correcting a claim is PR 3 work, and adding one belongs to the additions branches above it. Those PRs follow write-the-docs grounding rules: read the code, separate shipped behavior from product intent, and flag what you inferred.
3. Follow CONTRIBUTING.md and WORD_LIST.md for voice, terminology, and formatting. See apps/docs/CONTRIBUTING.md and apps/docs/WORD_LIST.md.
4. Prefer brevity. Use broad strokes when mechanical detail doesn't help the reader's task. Cut redundancy. Don't over-explain.
5. Reuse sibling skills. Get IA and architecture from ask-the-docs. Get validation and self-review from review-the-docs. Apply the shared pitfalls in write-the-docs/reference/common-pitfalls.md rather than duplicating them here.
6. One change type per diff. A diff that mixes reworded prose with moved sections is unreviewable, because the reader can't tell a move from a rewrite. Separate them by commit in a single PR, or by branch in a stack.

Phase 0: Size and split