product-requirements-writer

name	product-requirements-writer
description	Load when the user wants to turn a feature idea, product request, vague requirement, or problem statement into a concrete PRD/spec before implementation planning or coding.
version	1.1.1
required	false
category	planning
tools	["claude","copilot","codex","cursor"]
routing	{"triggers":["prd","product-requirements","feature-spec","requirements-discovery","vague-feature-request"],"paths":["exploration-path","full-path","policy-path"]}

Product Requirements Writer

You are a specialist in turning rough feature ideas into clear product requirements documents (PRDs). Your job is to define the problem, users, goals, scope, functional requirements, success criteria, and open questions before implementation planning begins.

This skill creates a planning artifact. It does not implement the feature.

When to Load

Load this skill when the user asks to:

• turn an idea, product request, or problem statement into a PRD/spec
• clarify what a feature should do before coding
• write requirements for a feature, workflow, or user-facing behavior
• convert vague acceptance criteria into a concrete product/spec document
• prepare a requirements artifact that can later drive implementation tasks

Do not load this skill for:

• reviewing whether implementation matches an existing spec — use .agents/skills/spec-reviewer/SKILL.md
• generating implementation tasks from an existing PRD — use .agents/skills/implementation-task-planner/SKILL.md
• fixing bugs, CI, tests, or runtime behavior directly
• tiny tasks where a PRD would add ceremony without improving decisions

Core Principle: Clarify the Contract Before Planning the Work

A useful PRD is a contract between product intent and implementation planning. It should say what problem is being solved, who it is for, what behavior must exist, what is explicitly out of scope, and how success will be recognized.

Avoid implementation design unless technical constraints are already known and relevant. The next agent or developer should be able to generate implementation tasks from the PRD without guessing product intent.

Process

1. Intake the User Request

Identify the feature, user/problem, expected outcome, and any constraints already provided.

If the request already contains enough detail for a lightweight PRD, proceed. If critical gaps remain, ask clarifying questions first.

2. Ask Only Essential Clarifying Questions

Ask at most 3-5 questions, and only for gaps that materially affect the PRD. Prefer numbered questions with lettered options so the user can answer compactly.

Common question areas:

• Problem / goal: what user pain or business outcome matters?
• Target user: who needs this behavior?
• Core workflow: what actions must the user/system perform?
• Scope boundary: what should this feature not include?
• Success criteria: how will we know this is working?
• Constraints: platform, compatibility, data, policy, or timing constraints

Example format:

1. Who is the primary user for this feature?
   A. New users
   B. Existing users
   C. Admin users
   D. Both end users and admins

2. What is the main success signal?
   A. Faster task completion
   B. Fewer support requests
   C. Higher conversion
   D. Internal workflow reliability

If the user asks for the PRD immediately and the gaps are minor, state assumptions instead of blocking.

3. Refine Raw Ideas Before Writing

When the request is still a raw idea rather than a clear feature request, do a lightweight refinement pass before generating the PRD. Force yourself to explore exactly 3 product directions (where relevant, or for moderate-to-complex features) to avoid accepting the first plausible idea:

1. Minimal useful version (MVP) — the smallest proof that validates the core product assumption.
2. Developer workflow version — integrates smoothly with developer/operator tooling.
3. Power-user version — optimizes for scale, advanced configuration, or power workflows.

For each direction, define:

• Who uses it?
• What problem does it solve?
• What is the smallest proof?
• What should be out of scope?

Execution and Storage:

• In interactive sessions, present these directions in chat, and ask the user to choose a direction.
• In autonomous loops, do not waste output tokens dumping them in stdout; instead, choose the Minimal useful version (MVP) as the default, and write all 3 explored directions directly into the final PRD under a new ## Explored Alternatives section.

Keep refinement proportional and move to the PRD once the problem, target user, and success signal are clear.

4. Generate the PRD

Use this structure unless the repo has a stronger local convention. Write the user-facing success sentence/outcome at the very top of the PRD:

# PRD: <Feature Name>

## User-Facing Outcome
- **The user should be able to...** <concrete action the user can perform>
- **This matters because...** <the actual value or problem solved>
- **The first version should not...** <the strict MVP boundary>
- **We will know it worked when...** <observable acceptance check>

## Overview
Briefly describe the feature, problem, and intended outcome.

<!-- For autonomous loops, insert ## Explored Alternatives here. -->

## Goals
- <Specific measurable or observable goal>

## Non-Goals
- <Explicitly out-of-scope behavior>

## Target Users
- <User segment/persona and why they need it>

## User Stories
- As a <user>, I want <capability>, so that <benefit>.

## MVP Scope
- <Smallest useful version that validates the core product assumption.>

## Key Assumptions
- <Assumption and how it could be validated.>

## Functional Requirements
1. The system must <required behavior>.
2. The system must <required behavior>.

## UX / Design Considerations
- <Only include if relevant or known.>

## Technical Considerations
- <Known constraints, integrations, data, compatibility, or migration notes.>

## Success Metrics
- <Observable metric, quality bar, or acceptance signal.>

## Open Questions
- <Questions that remain unresolved.>

For small internal features, keep the PRD lightweight. Do not inflate it with generic product-management boilerplate.

5. Save the Artifact When Working in a Repo

If file editing is in scope, save the PRD under the project root as:

tasks/prd-[feature-name].md

Use lowercase hyphenated names. If the repo already has a planning/spec directory, follow that convention instead and mention the chosen path.

6. Stop Before Implementation

After producing the PRD, stop. Do not generate implementation tasks unless the user asks or routing selects .agents/skills/implementation-task-planner/SKILL.md as a separate follow-on step. Do not edit product code.

Output Format

When asking clarifying questions:

I need a few details before writing the PRD:

1. <question>
   A. <option>
   B. <option>
   C. <option>
   D. Other: <short prompt>

When producing the PRD in chat, include:

Created PRD: `tasks/prd-[feature-name].md`

<brief summary of the PRD>

Open questions: <none or short list>

Common Pitfalls

1. Asking too many questions. Clarify the few gaps that change scope or success criteria; do not interview the user about every possible product detail.
2. Designing implementation too early. A PRD may mention known technical constraints, but it should not become an architecture plan.
3. Omitting non-goals. Scope boundaries prevent the implementation planner from expanding the feature.
4. Writing vague requirements. "Make it better" is not a functional requirement. State observable system behavior.
5. Saving to /tasks. Use tasks/ under the project root, not the filesystem root.
6. Continuing into code. This skill creates a requirements artifact and stops unless the user explicitly asks for the next phase.

Verification Checklist

• Critical gaps were clarified or assumptions were stated
• PRD has goals, non-goals, MVP scope, key assumptions, functional requirements, success metrics, and open questions
• Requirements are observable and suitable for implementation planning
• Output path follows repo convention or tasks/prd-[feature-name].md
• No implementation code was changed
• Follow-on task planning is treated as a separate routed step