Purpose
Turn a PRD or feature spec into a working UX writing brief that inventories every copy surface, exposes the user states and edge cases the document left unstated, and produces a ranked list of clarifying questions — so content design starts with a complete picture instead of writing into gaps discovered mid-build.
When to Use
Invoke this skill when the user asks to:
- Convert a PRD, feature spec, or engineering ticket into a UX writing brief
- Figure out what copy a new feature actually needs before starting to write
- Surface missing information or open questions in a product spec from a content perspective
- Build a content design plan or copy inventory for an upcoming feature
- Review a requirements doc for gaps that would block or slow UX writing
- Prepare clarifying questions for a PM or engineer before a copy kickoff
Inputs Required
Before starting, collect:
- PRD or spec text: The full requirements document, feature spec, or ticket description
- Feature name: What the feature or flow is called
- Product context: What the product is and who uses it (1–2 sentences)
- Platform(s): Web / iOS / Android / email / desktop — affects character limits and patterns
- Voice & tone reference: Link or description of existing voice guidelines, or "none yet"
- Localization scope: Single language or translated (affects length and idiom constraints)
- Delivery deadline or stage: Design phase, near dev handoff, etc. — affects how much to flag vs. assume
If voice guidelines or localization scope are missing, assume a neutral, plain-language default and English-only, and note the assumption in the brief.
Instructions
Step 1: Copy Surface Inventory
Read the PRD and extract every place text will appear. For each surface, capture: the surface type, where it lives in the flow, and the job that copy does there.
Scan systematically for these surface categories:
- Entry & navigation: menu labels, tab names, buttons that lead into the feature
- Primary actions: CTA buttons, submit/confirm actions, primary and secondary button pairs
- Instructional & inline: field labels, placeholder text, helper text, tooltips, onboarding hints
- Feedback & system states: success messages, confirmations, loading states, progress indicators
- Empty states: first-use, no-data, no-results, and cleared states
- Errors & recovery: validation errors, system errors, permission errors, dead ends
- Notifications & lifecycle: in-app notices, emails, push, reminders tied to the feature
- Legal & consent: disclaimers, consent copy, permission prompts, terms references
Output this as a numbered inventory. If a surface is implied but not named in the PRD (e.g., an error state for a required field), include it and mark it [inferred].
Step 2: User State & Journey Mapping
The PRD usually describes the happy path. Map the states copy must cover across the full journey:
- First-time vs. returning users on this surface
- Success, partial success, and failure paths for each action
- Edge conditions: offline, slow connection, expired session, insufficient permissions, empty data, maximum limits reached
- Interruption & re-entry: what copy says if the user leaves mid-flow and returns
For each mapped state, note whether the PRD addressed it or left it open.
Step 3: Requirements & Constraints Extraction
Pull the hard constraints that will shape word choice and length:
- Character/length limits by surface (from platform and design components)
- Mandatory terminology: product terms, feature names, regulated language that must appear verbatim
- Forbidden terms: internal jargon, deprecated names, legally risky words
- Accessibility requirements: reading level target, screen-reader considerations, plain-language mandates
- Voice & tone: how this feature's copy should feel, tied to the voice reference or the noted default
- Localization constraints: expansion headroom, avoiding idioms, date/number formats
Step 4: Gap & Ambiguity Analysis
Critically review the PRD for what a writer cannot proceed without. For each gap, classify it:
- Blocking — copy cannot be written accurately until resolved (e.g., what actually happens after the CTA)
- Shaping — copy can be drafted but a decision changes the approach (e.g., formal vs. casual tone)
- Nice-to-have — a detail that would improve copy but has a safe default
Do not paper over gaps with assumptions. Name them.
Step 5: Clarifying Questions
Convert every Blocking and Shaping gap into a specific, answerable question directed at the right owner (PM, designer, engineer, legal). Rank them Blocking-first. Each question should:
- Reference the exact surface or decision it unblocks
- Offer 2–3 plausible options where possible, so the answer is a choice not an essay
- State the consequence of leaving it unanswered
Step 6: Assemble the Brief
Compile Steps 1–5 into a single handoff-ready document with the sections listed in Output Format. Lead with a 2–3 sentence summary of the feature and the top three things that must be resolved before writing.
Output Format
- Structure: Single structured brief; copy inventory as a numbered list or table; questions as a ranked list grouped by priority
- Length: 800–1,300 words depending on PRD size
- Format: Structured document with headers; inventory and constraints in table form where dense
- Sections: Summary & top blockers → Copy Surface Inventory → User States & Edge Cases → Requirements & Constraints → Gaps & Ambiguities → Ranked Clarifying Questions → Recommended Next Step
- Tone: Content design specialist — precise, skeptical of unstated assumptions, oriented toward unblocking the work
Quality Checklist
Before delivering output, verify:
- [ ] Every copy surface in the PRD is inventoried, plus inferred surfaces marked [inferred]
- [ ] Each primary action has its success, error, and empty/edge states accounted for
- [ ] Every gap is classified Blocking / Shaping / Nice-to-have — none left unlabeled
- [ ] Each clarifying question names a specific surface or decision and offers options where possible
- [ ] Questions are ranked Blocking-first, not listed in PRD order
- [ ] Constraints section captures at least length limits, mandatory terms, and voice — not just one
Notes
- The most common miss in PRDs is error and empty states — always assume they exist even when unmentioned, and inventory them.
- A good clarifying question offers options; it forces a decision instead of inviting a meeting.
- If the PRD is a thin ticket rather than a full spec, expect the Gaps section to be the largest — that is the correct outcome, not a failure of the input.
- Distinguish "the PRD didn't say" from "the PRD contradicts itself" — flag contradictions explicitly, as they need a different conversation than missing detail.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills