Take a rough request and draft it into a named document structure — a PRD, RFC, or changelog — filling in each section rather than writing one long undifferentiated block of prose. Use when the user asks to "draft a PRD for X", "write up an RFC for this", or "turn these notes into a proper doc". Do NOT use for a single paragraph, email, or short note — use clear-writing or just write it directly; this skill is for multi-section structured documents.
v1 · authored by Gryz · writing
Pairs with the “prd” first-party template.
Use it from any MCP-connected agent
Connect Gryz MCP, then call list_skills and get_skill({ name: "structured-doc-drafting" }). Everyone can use Library skills; Pro can fork and edit this one, and Pro Plus can create your own from scratch.
# Structured doc drafting
Turn a rough request or a pile of notes into a properly sectioned document —
a PRD, an RFC, a changelog — instead of one long paragraph.
## When to use
- "Draft a PRD for X", "write up an RFC for this", "turn these notes into a
proper doc".
## Do NOT use for
- A single paragraph, email, or short note. Use clear-writing on those, or
just write them directly — this skill is for documents with multiple named
sections.
## How to draft
1. **Pick the structure that fits the ask**, don't invent a new one each
time:
- **PRD:** Problem, Goals (and non-goals), Proposed solution, Scope,
Risks/open questions, Success metrics.
- **RFC:** Context, Proposal, Alternatives considered, Tradeoffs,
Decision needed.
- **Changelog entry:** What changed, why it matters (user-facing impact),
any action required.
2. **Draft section by section**, filling each with the actual content the
user gave you — don't pad a section with generic filler just to have
something under every heading. An honest "Open questions: none yet" beats
an invented one.
3. **State assumptions explicitly** when the request under-specifies a
section (e.g., no stated success metric) — call it out rather than
silently inventing one that looks authoritative.
4. **Use the paired PRD template** when drafting a PRD specifically: fetch
the first-party "PRD" template (`get_template`) and fill it in following
this skill's structure, rather than free-handing a new layout each time.
5. **Keep it scannable** — headings, short paragraphs, bullets for anything
listable. A PRD nobody skims is a PRD nobody reads before the meeting.
## Examples
**Request:** "draft a PRD for adding dark mode"
**Draft skeleton produced:**
```
# Dark mode
## Problem
Users working at night report the light-only UI is uncomfortable...
## Goals
- Ship a dark theme toggle, persisted per user.
## Non-goals
- Custom user-defined themes (future work).
## Proposed solution
...
## Risks / open questions
- Icon contrast in dark mode needs a design pass — flagged, not resolved
here.
## Success metrics
- % of active users who enable dark mode within 30 days of launch.
```
