Write Spec
Turn a vague feature idea or user request into a structured PRD with goals, metrics, and acceptance criteria before you commit engineering time.
Overview
Write Spec is an agent skill most often used in Validate (also Build) that turns a problem statement or feature idea into a structured PRD with goals, non-goals, metrics, and acceptance criteria.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill write-specWhat is this skill?
- Accepts feature names, problem statements, user requests, or vague onboarding-style ideas as input
- Conversational context gathering: users, success metrics, constraints, prior art
- Structured PRD output with goals, non-goals, and acceptance criteria
- Phased spec breakdown for large asks
- Slash-style invocation: /write-spec with feature or problem argument
Adoption & trust: 1.8k installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a feature name or fuzzy user pain but no shared spec with metrics, boundaries, or testable acceptance criteria for you or your agent.
Who is it for?
Solo founders and indie builders scoping the next feature, drafting PRDs from customer feedback, or formalizing a big ask before touching the repo.
Skip if: Teams that already have an approved spec locked in version control and only need line-by-line code changes with no scope rework.
When should I use this skill?
Turning a vague idea or user request into a structured document, scoping with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.
What do I get? / Deliverables
You leave with a structured feature or PRD document scoped for phased delivery and ready to hand off to implementation planning or coding.
- Feature specification or PRD with goals, non-goals, and acceptance criteria
- Phased breakdown for large features when applicable
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Feature scoping and PRD writing is the canonical validate move: you prove what to build and what to defer before the build phase. Scope subphase is where problem statements become bounded specs with success metrics and phased delivery—not ad-hoc chat threads.
Where it fits
Enterprise auth requests get turned into a phased SSO spec with explicit non-goals before any backend work.
A CSV export request is scoped with user segments and success metrics tied to retention, not just a one-off endpoint.
Onboarding drop-off is documented as measurable acceptance criteria for the next sprint instead of unstructured tweaks.
How it compares
Use for structured PRD authoring from conversation—not as a substitute for codebase-wide architecture reviews or automated test generation.
Common Questions / FAQ
Who is write-spec for?
Solo and indie builders using Claude Code–style agents who need a PRD or feature spec before implementation, especially when input is still a problem statement or vague idea.
When should I use write-spec?
During validate when scoping a feature with goals and non-goals; early build when PM-style docs are missing; anytime you are turning a user request into success metrics and acceptance criteria rather than coding immediately.
Is write-spec safe to install?
It is primarily a documentation and planning workflow; review the Security Audits panel on this Prism page and any connector permissions in CONNECTORS.md before linking external tools.
SKILL.md
READMESKILL.md - Write Spec
# Write Spec > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md). Write a feature specification or product requirements document (PRD). ## Usage ``` /write-spec $ARGUMENTS ``` ## Workflow ### 1. Understand the Feature Ask the user what they want to spec. Accept any of: - A feature name ("SSO support") - A problem statement ("Enterprise customers keep asking for centralized auth") - A user request ("Users want to export their data as CSV") - A vague idea ("We should do something about onboarding drop-off") ### 2. Gather Context Ask the user for the following. Be conversational — do not dump all questions at once. Ask the most important ones first and fill in gaps as you go: - **User problem**: What problem does this solve? Who experiences it? - **Target users**: Which user segment(s) does this serve? - **Success metrics**: How will we know this worked? - **Constraints**: Technical constraints, timeline, regulatory requirements, dependencies - **Prior art**: Has this been attempted before? Are there existing solutions? ### 3. Pull Context from Connected Tools If **~~project tracker** is connected: - Search for related tickets, epics, or features - Pull in any existing requirements or acceptance criteria - Identify dependencies on other work items If **~~knowledge base** is connected: - Search for related research documents, prior specs, or design docs - Pull in relevant user research findings - Find related meeting notes or decision records If **~~design** is connected: - Pull related mockups, wireframes, or design explorations - Search for design system components relevant to the feature If these tools are not connected, work entirely from what the user provides. Do not ask the user to connect tools — just proceed with available information. ### 4. Generate the PRD Produce a structured PRD with these sections. See **PRD Structure** below for detailed guidance on what each section should contain. - **Problem Statement**: The user problem, who is affected, and impact of not solving it (2-3 sentences) - **Goals**: 3-5 specific, measurable outcomes tied to user or business metrics - **Non-Goals**: 3-5 things explicitly out of scope, with brief rationale for each - **User Stories**: Standard format ("As a [user type], I want [capability] so that [benefit]"), grouped by persona - **Requirements**: Categorized as Must-Have (P0), Nice-to-Have (P1), and Future Considerations (P2), each with acceptance criteria - **Success Metrics**: Leading indicators (change quickly) and lagging indicators (change over time), with specific targets - **Open Questions**: Unresolved questions tagged with who needs to answer (engineering, design, legal, data) - **Timeline Considerations**: Hard deadlines, dependencies, and phasing ### 5. Review and Iterate After generating the PRD: - Ask the user if any sections need adjustment - Offer to expand on specific sections - Offer to create follow-up artifacts (design brief, engineering ticket breakdown, stakeholder pitch) ## PRD Structure ### Problem Statement - Describe the user problem in 2-3 sentences - Who experiences this problem and how often - What is the cost of not solving it (user pain, business impact, competitive risk) - Ground this in evidence: user research, support data, metrics, or customer feedback ### Goals - 3-5 specific, measurable outcomes this feature should achieve - Each goal should answer: "How will we know this succeeded?" - Distinguish between user goals (what users get) and business goals (what the company gets) - Goals should be out