pm-the-docs

Docs-PM-Entscheidungsunterstützung für den „Write the docs“-Erstellungsprozess — trifft Entscheidungen zu Zielgruppe, Phase und übergreifenden Themenbereichen während der Frame- und Shape-Phasen,…

npx skills add https://github.com/supabase/supabase --skill pm-the-docs

PM the docs

Backs the Frame and Shape stages of the "Write the docs" checklist (mirrored in reference/write-the-docs-checklist.md) — the audience, product-stage, and cross-cutting scope calls a docs PM would normally make before drafting starts.

When to invoke

  • Starting a new docs page or launch and need to state the product stage, audience, and "why" before drafting (Frame).
  • Deciding content type, IA placement, or prerequisites for a page (Shape).
  • Unsure whether a docs question is self-serve or needs a docs PM's sign-off.

Not for drafting content itself (see write-the-docs) or docs-app architecture/IA placement mechanics (see ask-the-docs).

Answering a scope/stage/audience question

  1. Read the relevant stage in reference/write-the-docs-checklist.md — its checkboxes state exactly what needs deciding.
  2. Read whatever context exists for the feature: the linked issue/project, the PRD, the shipped code or PR. When code and PRD disagree, the code wins for behavior claims.
  3. Answer the checklist's questions directly: product stage, audience and job-to-be-done, the one-line "why," content type, IA placement, prerequisites.
  4. Distinguish confirmed fact (stated in the ticket/PRD/code) from inference (your best read) — flag inference explicitly rather than presenting it as settled.
  5. If a decision is genuinely open at the org level (not a docs-content call), say so and name who should decide instead of inventing an answer to look complete.

Self-serve vs. escalate

Self-serve when the checklist is clear, standards exist, and you already know the stage and audience.

Escalate to your docs team's PM when scope or stage is unclear, you need a review path, the bar is ambiguous, or the launch touches cross-cutting surfaces (quickstarts, API keys, tutorials, onboarding, platform concepts) — see the full "Ask the Docs PM" section in the checklist mirror.

Related skills

Mehr Skills von supabase

studio-e2e-tests
supabase
Schreibe und führe Playwright E2E-Tests für Supabase Studio aus. Verwende, wenn danach gefragt wird.
studio-best-practices
supabase
React- und TypeScript-Best-Practices für Supabase Studio. Verwenden beim Schreiben oder Überprüfen von Studio-Komponenten – umfasst boolesche Benennung, Komponentenstruktur, …
docs-content
supabase
Schreiben, Bearbeiten, Organisieren und Überprüfen von Supabase-Inhalten überall in apps/docs – Leitfäden, Erklärungen, Tutorials, Fehlerbehebungsbeiträge, Referenzdokumentation und…
studio-mock-api-tests
supabase
Komponententests für Supabase Studio, die API-Anfragen auf der Netzwerkebene mit MSW mocken. Verwenden Sie beim Schreiben oder Überprüfen eines Komponententests, der eine React…
studio-ui-patterns
supabase
Designsystem-UI-Muster für Supabase Studio. Verwenden Sie dies beim Erstellen oder Aktualisieren von Seiten, Formularen, Tabellen, Diagrammen, Leerzuständen, Navigation, Karten, Warnhinweisen oder Seitenleisten…
react-hook-form
supabase
Korrekte React Hook Form-Verwendung überall im Monorepo — Datenfluss, Subscriptions, Reset, Dirty State, Zahlen-Inputs und Regeln für kontrollierte Eingaben. Laden Sie dies…
studio-queries
supabase
React Query-Konventionen für das Datenabrufen in Supabase Studio. Verwenden Sie diese beim Schreiben oder Überprüfen von Query-Hooks, Mutations-Hooks oder Query-Keys in apps/studio/data/ —…
studio-testing
supabase
Teststrategie für Supabase Studio. Verwenden Sie beim Schreiben von Tests, bei der Entscheidung, ob eine Änderung Tests benötigt und welche Art, beim Extrahieren von Logik aus Komponenten in…