Edit the docs
Improves existing Supabase docs pages: structure, order, connective text,
and clarity. Distinct from write-the-docs
(draft net-new or product-grounded rewrites from intent + code) and
review-the-docs (lint, build, PR triage).
Core rules
- Read before you rewrite. Open the target page and nearby pages of the same type. Name the reader's goal and the page type (explainer, guide, tutorial, troubleshooting) before moving sections.
- Improve structure and clarity; don't invent product truth. Preserve behavior claims, UI labels, and positioning unless you verify a change against code or product intent. Accuracy gaps or missing net-new content belong with
write-the-docs / pm-the-docs, not silent invention here.
- Follow CONTRIBUTING.md and WORD_LIST.md for voice, terminology, and formatting. See
apps/docs/CONTRIBUTING.md and apps/docs/WORD_LIST.md.
- Prefer brevity. Prefer broad strokes when mechanical detail doesn't help the reader's task. Cut redundancy; don't over-explain.
- Reuse sibling skills. IA/architecture via
ask-the-docs; validation and self-review via review-the-docs. Shared pitfalls live in write-the-docs/reference/common-pitfalls.md — apply them, don't duplicate them.
Phase 1 — Diagnose
- Identify the document type per CONTRIBUTING.md (explainer, tutorial, guide, reference, or troubleshooting).
- State the reader's goal and prerequisites in one or two lines.
- Note structural problems: mixed information types interrupting a procedure, missing intro navigation on a long page, weak transitions, redundancy, or over-explained mechanics.
- Summarize the diagnosis to the requester before large moves when the restructure would change how the page is read.
Phase 2 — Restructure
Apply the Mixed information types, Navigation, and Cross-references and glue guidance in apps/docs/CONTRIBUTING.md (Guides section), summarized here:
- Classify substantial sections as contextual, procedural, or reference content. In a mixed page, group sections by information type so that context doesn't interrupt the procedural path.
- For a long or mixed page, add a short introduction that links to its major section groups and tells readers when to use each one. Skip this navigation when a short page is already easy to scan.
- Connect contextual sections to their corresponding procedures when useful. Add introductions to section groups, transitions between information types, and outcomes after procedures. Don't link every adjacent section.
- Move and regroup first; preserve meaning. Don't silently rewrite facts while restructuring.
Phase 3 — Edit for clarity
- Use second person, present tense, short paragraphs, and ordered steps for sequential actions.
- Cut restated points and mechanical over-explanation.
- Apply
write-the-docs/reference/common-pitfalls.md: timelessness, no internal planning context in shipped MDX, redundancy, single-item lists, admonition restatement.
- Search
apps/docs/WORD_LIST.md when introducing or revising technical terms and UI actions.
- Keep code samples executable in their stated context; mark intentionally omitted code. Prefer partials under
apps/docs/content/_partials/ over copied blocks.
Phase 4 — Validate
Before handoff:
Mechanics (anchors, lint, format): follow write-the-docs/reference/drafting-mechanics.md. Before renaming or rewording headings, grep for #<old-anchor-slug> under apps/docs/content and update matches.
Then run review-the-docs local self-review (pnpm lint:mdx, and pnpm build:guides-markdown when guides/explainers/tutorials changed).
Additional resources
1---2name: edit-the-docs3description: Restructure, reorder, and improve existing Supabase docs pages under apps/docs — clarity, connective text, section grouping, and brevity. Use when asked to edit, reorganize, restructure, tighten prose, or add glue between sections on a page that already exists. Not for net-new feature drafts (use write-the-docs) or PR triage/verification (use review-the-docs).4---5
6# Edit the docs
7
8Improves **existing** Supabase docs pages: structure, order, connective text,
9and clarity. Distinct from [`write-the-docs`](../write-the-docs/SKILL.md)
10(draft net-new or product-grounded rewrites from intent + code) and
11[`review-the-docs`](../review-the-docs/SKILL.md) (lint, build, PR triage).
12
13## Core rules
14
151. **Read before you rewrite.** Open the target page and nearby pages of the same type. Name the reader's goal and the page type (explainer, guide, tutorial, troubleshooting) before moving sections.
162. **Improve structure and clarity; don't invent product truth.** Preserve behavior claims, UI labels, and positioning unless you verify a change against code or product intent. Accuracy gaps or missing net-new content belong with [`write-the-docs`](../write-the-docs/SKILL.md) / [`pm-the-docs`](../pm-the-docs/SKILL.md), not silent invention here.
173. **Follow CONTRIBUTING.md and WORD_LIST.md** for voice, terminology, and formatting. See [`apps/docs/CONTRIBUTING.md`](../../../apps/docs/CONTRIBUTING.md) and [`apps/docs/WORD_LIST.md`](../../../apps/docs/WORD_LIST.md).
184. **Prefer brevity.** Prefer broad strokes when mechanical detail doesn't help the reader's task. Cut redundancy; don't over-explain.
195. **Reuse sibling skills.** IA/architecture via [`ask-the-docs`](../ask-the-docs/SKILL.md); validation and self-review via [`review-the-docs`](../review-the-docs/SKILL.md). Shared pitfalls live in [`write-the-docs/reference/common-pitfalls.md`](../write-the-docs/reference/common-pitfalls.md) — apply them, don't duplicate them.
20
21## Phase 1 — Diagnose
22
231. Identify the document type per CONTRIBUTING.md (explainer, tutorial, guide, reference, or troubleshooting).
242. State the reader's goal and prerequisites in one or two lines.
253. Note structural problems: mixed information types interrupting a procedure, missing intro navigation on a long page, weak transitions, redundancy, or over-explained mechanics.
264. Summarize the diagnosis to the requester before large moves when the restructure would change how the page is read.
27
28## Phase 2 — Restructure
29
30Apply the **Mixed information types**, **Navigation**, and **Cross-references and glue** guidance in [`apps/docs/CONTRIBUTING.md`](../../../apps/docs/CONTRIBUTING.md) (Guides section), summarized here:
31
321. Classify substantial sections as contextual, procedural, or reference content. In a mixed page, group sections by information type so that context doesn't interrupt the procedural path.
332. For a long or mixed page, add a short introduction that links to its major section groups and tells readers when to use each one. Skip this navigation when a short page is already easy to scan.
343. Connect contextual sections to their corresponding procedures when useful. Add introductions to section groups, transitions between information types, and outcomes after procedures. Don't link every adjacent section.
354. Move and regroup first; preserve meaning. Don't silently rewrite facts while restructuring.
36
37## Phase 3 — Edit for clarity
38
39- Use second person, present tense, short paragraphs, and ordered steps for sequential actions.
40- Cut restated points and mechanical over-explanation.
41- Apply [`write-the-docs/reference/common-pitfalls.md`](../write-the-docs/reference/common-pitfalls.md): timelessness, no internal planning context in shipped MDX, redundancy, single-item lists, admonition restatement.
42- Search [`apps/docs/WORD_LIST.md`](../../../apps/docs/WORD_LIST.md) when introducing or revising technical terms and UI actions.
43- Keep code samples executable in their stated context; mark intentionally omitted code. Prefer partials under `apps/docs/content/_partials/` over copied blocks.
44
45## Phase 4 — Validate
46
47Before handoff:
48
49- [ ] Section groups follow information type; procedures aren't interrupted by long context
50- [ ] Intro navigation present only when the page needs it; links resolve
51- [ ] Connective text is selective, not link spam
52- [ ] Voice matches CONTRIBUTING.md / WORD_LIST.md
53- [ ] No invented behavior or positioning
54- [ ] Shared pitfalls checklist considered
55
56Mechanics (anchors, lint, format): follow [`write-the-docs/reference/drafting-mechanics.md`](../write-the-docs/reference/drafting-mechanics.md). Before renaming or rewording headings, grep for `#<old-anchor-slug>` under `apps/docs/content` and update matches.
57
58Then run [`review-the-docs`](../review-the-docs/SKILL.md) local self-review (`pnpm lint:mdx`, and `pnpm build:guides-markdown` when guides/explainers/tutorials changed).
59
60## Additional resources
61
62- Structure SoT: [`apps/docs/CONTRIBUTING.md`](../../../apps/docs/CONTRIBUTING.md) (mixed types, navigation, glue)
63- Structure ops: [`apps/docs/CONTRIBUTING.md`](../../../apps/docs/CONTRIBUTING.md) — Guides: Mixed information types, Navigation, Cross-references and glue
64- Pitfalls: [`write-the-docs/reference/common-pitfalls.md`](../write-the-docs/reference/common-pitfalls.md)
65- Mechanics: [`write-the-docs/reference/drafting-mechanics.md`](../write-the-docs/reference/drafting-mechanics.md)
66- Architecture/IA: [`ask-the-docs`](../ask-the-docs/SKILL.md)
67- Net-new drafts: [`write-the-docs`](../write-the-docs/SKILL.md)
68- Review: [`review-the-docs`](../review-the-docs/SKILL.md)