---
name: "prd-scope"
description: "First step of the PRD loop. Turns a rough requirement (client ask, app idea, feature request, ticket, or one-line task) into a scoped PRD or brief plus a Now/Next/Later priority list, asking only follow-ups that matter. Use when the user shares a requirement or idea and wants to plan, scope, break it down, or write a PRD, brief or priorities, or needs questions for a client, even if they never say PRD."
---

# PRD Scope

The first step of the PRD loop. Takes a messy requirement and returns two things: a document that says what is being made and why, and a priority list that says what to do first. The goal is that whoever reads it knows what is expected of them without a follow-up call.

The default reader is a single designer or builder planning their own work. Only write for a team, freelancer, or client audience if the user says so. Keep this in mind throughout: a solo reader does not need RACI tables, sign-off gates, or stakeholder theatre.

## Workflow

### 1. Read before writing

Read the whole requirement first. Note what is stated, what is implied, and what is missing. Do not draft anything yet.

### 2. Detect the mode and confirm it in one line

Pick one mode from the signals below.

| Mode | Signals | Document |
|---|---|---|
| Design | "design", "redesign", "UX", "flows", "screens", "wireframes", "audit", "case study", "brand", "portfolio" | [Design mode template](#design-mode-template) |
| Build | "build", "develop", "app", "API", "integrate", "website", "MVP", "feature", "automation", a tech stack named | [Build mode template](#build-mode-template) |
| Hybrid | Both, e.g. "design and build this app" | Read both, merge, and order the priorities so design decisions land before the build work they unblock |
| Task | A single deliverable, small scope, a ticket, a deadline-driven ask, "can you do X by Friday" | [Task mode template](#task-mode-template) |

Then confirm with one line, not a questionnaire. For example: "I read this as a **build** for a solo founder, MVP level, mobile app. Right, or should I treat it differently?" Wait for the reply. If the user already said "just go" or the session is unattended, proceed and state the reading at the top of the output.

If the signals are genuinely split, say which two modes you are choosing between and why, and let the user pick.

### 3. Close the gaps, but only the ones that change the document

Ask a follow-up question only if the answer would change scope, priorities, or what the reader has to do. Skip anything you can reasonably assume, and mark assumptions in the document instead.

- If the requirement is already clear, ask nothing and say so in a sentence.
- Ask at most **5 questions per round**. Group them, and offer a suggested default with each so the user can reply "yes to all".
- Run another round only if answers opened new gaps that matter. Stop when what is left can sit in the Open Questions section.
- Order questions by how much they change the outcome. Users, goal, and scope boundaries come before preferences and polish.

**When the answers belong to a client or stakeholder, not the user:** do not keep interrogating the user for things they cannot know. Instead, write a separate short **Client / Stakeholder Questions** list, using the [Client question bank](#client-question-bank) below to pick the relevant ones and phrase them in plain, non-jargon language the client can answer in one sitting. Carry on with the PRD using clearly marked assumptions so the user is not blocked while waiting.

### 4. Write the document

Open the template for the detected mode (below) and follow its structure. Scale depth to the real size of the work: a weekend task gets a one-pager, not twelve sections. Cutting sections that do not apply is correct; padding them is the common failure.

Writing rules that make the document usable:

- State the problem before any solution.
- Name a specific user, not "users".
- Number requirements (R1, R2...) so they can be referenced and tracked.
- Write acceptance criteria that someone can check as pass or fail. "Fast" is not checkable; "first screen renders in under 2 seconds on a mid-range phone" is.
- Write what is out of scope. This does more to prevent rework than any other section.
- Mark guesses as `[Assumption]` and unknowns as Open Questions with an owner (user, client, or a named person).
- Use plain punctuation. No em-dashes.

**Fidelity rules.** A PRD that reads as the source's own words but adds things the source never said is the main way this skill fails. The reader will obey a literal-sounding line, so every line must be honest about where it came from.

- **Tag the source of every requirement.** Each row in the requirements table carries one of: `Brief` (the source says it, in or close to its words), `Derived` (a direct consequence of something in the source, with the line it follows from named), or `Proposed` (not in the source, added to make the work doable). Never leave a requirement untagged.
- **Acceptance checks must not smuggle in new constraints.** A check may test the requirement, but it may not add a rule the source did not state. If a check needs a new rule to be testable (for example "only one tappable element" or "a single dismiss button"), either drop that part or mark it `Proposed` and move it to Open Questions. When the source says what a screen contains, do not add what it may not contain unless the source said so.
- **Do not invent the user.** Describe the user only with what the source says ("busy people"). Personas, job titles, frustrations, motivations and emotional language that the source did not state go under `[Assumption]` or are left out.
- **Do not invent non-goals, deliverables or sources.** Non-goals are only what the source excludes or clearly implies. Deliverables are only what the source asked for. Anything extra (prototypes, handoff packs, test studies, brand-asset sources, tool choices) is `Proposed`, listed separately under "Suggested additions" so the reader can accept or cut each one.
- **Quote, do not paraphrase, hard rules.** When the source states a rule ("never an underline", "no serif fonts anywhere"), copy its wording into the requirement and keep the sharp edges. Do not soften or extend it.
- **Surface contradictions.** If two parts of the source conflict, put the conflict in Open Questions with both quotes. Do not silently resolve it.

### 5. Build the priority list

Use **Now / Next / Later** unless the user asks for another framework (MoSCoW, P0/P1/P2, RICE). Detect the right shape from the input:

- **Now:** what must happen first. Keep it short enough that one person can actually do it. Each item gets a one-line reason.
- **Next:** what follows once Now is done. Note what each item depends on.
- **Later:** worth doing, not yet. No detail needed, since priorities may change before they matter.

Spread the items across the lifecycle phases that apply to the mode. The full lifecycle is discovery, design, build, QA, launch, and post-launch, but only list the phases the work actually touches. For phases that are not part of this scope, add one line such as "Launch: out of scope, handoff only" so the reader knows it was considered, not forgotten.

- Design mode usually runs discovery, research, flows, UI, validation, handoff.
- Build mode usually runs discovery, technical design, build, QA, launch, post-launch.
- Task mode needs only an ordered set of steps, grouped Now/Next/Later if there are more than a handful.

Make the list usable as a plan, not just a ranking:

- **Number the steps once, continuously** (1, 2, 3 ... across Now, Next and Later), and name the requirement IDs each step covers, for example "(R2, R3)". Other tools track progress against these numbers and IDs.
- **Every requirement ID appears in at least one step.** A requirement no step names is never checked. Rules that apply everywhere (typeface, wording, logo rules) get a final "standing rules" step that lists their IDs, and each step's own acceptance check still has to respect them.
- **Write dependencies in the step text** as "after step 3" or "before step 4", in Now as well as Next. If two steps feed each other (shared tokens and the screens that use them), order them so the one that produces comes first, or say they run together. Do not leave the order to be guessed.

### 6. Deliver

Produce:

1. **The main file**, as Markdown, named `<short-slug>-prd.md` (or `<short-slug>-brief.md` for task mode). It opens with a short TL;DR block, then the document, then the priority list, then Open Questions. If a client question list was needed, put it at the end under its own heading, so it can be copied out and sent.
2. **A brief in the chat reply**: five lines or fewer covering what is being made, for whom, what is in Now, the biggest risk or open question, and the file, plus the one-line Fidelity count from step 7. The user should be able to act on the chat reply without opening the file.

Save the file with whatever file-writing tool is available and hand it over with the file-delivery tool if there is one. If neither exists, give the Markdown in a single code block instead.

Then ask once whether they want it in another format. Offer the realistic options: a Claude doc, a Word file, a PDF, a Notion-friendly paste, slides, or a spreadsheet for the priority list. Do not convert unless they say yes.

### 7. Check before sending

Run a fidelity pass first, against the original source, not against your own draft:

1. List every ask in the source and confirm each has a requirement.
2. Go through every requirement, acceptance check, non-goal, deliverable and user detail. For each, find the line in the source it comes from. If there is none, it must be tagged `Proposed` or `[Assumption]`, or cut.
3. Check that no hard rule from the source was softened, extended or reworded into something different.
4. Check that any contradiction in the source is listed in Open Questions.
5. Add a short "Fidelity" line to the chat reply: how many requirements are `Brief`, `Derived` and `Proposed`, and what you added beyond the source.

Then the plan checks:

- Does every requirement ID appear in at least one priority step? List any that do not and fix them.
- Does any step use something another step produces? If so, is the order or the "after step N" written down?

Then the usability checks:

- Does the first screen of the document tell the reader what is expected of them?
- Is every Now item specific enough to start today?
- Could any acceptance criterion be argued about? If so, tighten it.
- Are out-of-scope items written down?
- Are assumptions and open questions marked, with owners?
- Is anything padded that the reader would skip?

## Examples of mode detection

**Input:** "Client wants their onboarding flow fixed, drop-off is high."
**Mode:** Design. Likely follow-ups: where in the flow the drop happens, what data exists, constraints on changing the product. Client question list needed for analytics access.

**Input:** "Need an app that locks my phone apps until I finish a morning checklist."
**Mode:** Build (personal project, solo). Likely follow-ups: platform, which apps, what counts as finishing, how strict the lock should be.

**Input:** "Design and build a booking site for a salon."
**Mode:** Hybrid. Design priorities first (flows, booking UI), build priorities after, with the handoff point called out.

**Input:** "Update the pricing page copy and swap the hero image by Friday."
**Mode:** Task. One-page brief: what changes, source of the copy and image, done criteria, deadline. No PRD sections.

## Templates

Everything this skill needs is below. Read only the template for the detected mode, plus the client question bank when a client list is needed.

- [Design mode template](#design-mode-template): design PRD structure and design lifecycle priorities
- [Build mode template](#build-mode-template): build PRD structure, requirement format, and lifecycle priorities
- [Task mode template](#task-mode-template): the one-page task brief
- [Client question bank](#client-question-bank): questions for clients and stakeholders, by topic

---

## Design mode template

Use when the work is mostly design: UX, UI, research, audits, redesigns, flows, brand, case studies. The document tells the designer what problem to solve, for whom, what to deliver, and what is off the table. Design work goes wrong mostly through unclear scope and missing context, so those get the most space.

### Structure

Keep each section to what the reader needs. Drop any section that adds nothing.

```markdown
# [Project name]: Design PRD

> **TL;DR:** [3 to 4 lines: what is being designed, for whom, the main outcome, the first thing to do]

## 1. Problem and context
[What is not working today, and for whom. What triggered this work. Include evidence if it exists: drop-off numbers, complaints, research.]

## 2. Users
[One primary user, described only with what the source says. Secondary users only if they change design decisions. Goal and frustration only if the source states them; otherwise mark `[Assumption]`.]

## 3. Goals and success
- Goal: [what the design should achieve, as the source states it]
- Success signal: [observable. If the source gave none, propose one and mark it `Proposed`]
- Non-goals: [only what the source excludes or clearly implies; anything else is `Proposed`]

## 4. Scope
**In scope:** [screens, flows, platforms, states, exactly as the source lists them]
**Out of scope:** [what the source excludes; plus clearly marked `[Assumption]` exclusions]
**Deliverables:** [what the source asked for]
**Suggested additions (Proposed, accept or cut):** [prototype, handoff specs, research, anything not asked for]

## 5. Requirements
| ID | Source | Requirement | Why it matters | Acceptance check |
|---|---|---|---|---|
| R1 | Brief / Derived / Proposed | | | |

`Source` is mandatory. `Brief` rows use the source's own wording for hard rules. `Derived` rows name the source line they follow from. `Proposed` rows are optional and also listed in Open Questions. An acceptance check never adds a rule the source did not state.

Cover as relevant: key flows, information architecture, content needs, states (empty, error, loading), responsive behaviour, accessibility target (e.g. WCAG AA), edge cases.

## 6. Constraints and inputs
[Existing design system or brand, tech limits, platform rules, legal or compliance, existing research, assets already available, deadline, budget.]

## 7. Research and validation plan
[What is already known, what needs finding out, and the lightest method that would answer it: interviews, usability test, analytics review, heuristic audit, competitor review.]

## 8. Handoff
[Who receives the design, in what format, and what they need: specs, tokens, component notes, redlines, prototype link.]

## 9. Risks and assumptions
- [Assumption] ...
- Risk: ... Mitigation: ...

## 10. Priorities (Now / Next / Later)
[See below.]

## 11. Open questions
| Question | Owner | Blocks |
|---|---|---|

### Resolved questions
| Question | Answer | Date |
|---|---|---|

## 12. Changes
[One dated line each time an answer or a decision changes the document: what changed, who decided, which requirements it touched.]
```

### Lifecycle phases for design priorities

Use only the phases that apply, and mark skipped ones as out of scope with a reason.

1. **Discovery:** understand the problem, gather existing material, align on goals.
2. **Research:** fill the gaps that would change design decisions.
3. **Structure:** information architecture, user flows, content outline.
4. **Wireframes and exploration:** low-fidelity options, pick a direction.
5. **UI design:** high-fidelity screens, states, components, responsive.
6. **Prototype and validation:** test the riskiest flow with real people.
7. **Handoff:** specs, assets, documentation, support during build.
8. **Post-launch review:** check the design against the success signal.

### Priority guidance

- Put what unblocks everything else in Now. Usually that is context gathering and the riskiest or most central flow, not the prettiest screen.
- Visual polish, secondary flows, and nice-to-have states belong in Later until the core flow is settled.
- If research is missing, make a small, specific research item Now, so the designer does not design on guesses.
- Number the steps once, continuously, and name the requirement IDs each covers. Every requirement ID appears in at least one step; rules that apply to every screen (typeface, wording, logo rules) get a final standing-rules step.
- Write dependencies as "after step N" (for example, the type and colour step comes before the screens that use them).

### Variants

- **Audit or critique:** replace Requirements with "Areas to review" and "Heuristics or standards used". Deliverable is a findings report ranked by severity.
- **Case study or portfolio piece:** add "Story and outcome" (problem, role, process, result) and replace Handoff with "Presentation format and audience".
- **Design system work:** add component inventory, token scope, adoption plan, and who maintains it.

---

## Build mode template

Use when the work is mostly building software: an app, website, feature, integration, automation, or API. The document says what must be true when it is done, in a form the builder (or an AI coding agent) can work from without guessing. A PRD says what and why. How is left to the builder unless a constraint forces it.

### Pick the depth first

| Situation | Depth |
|---|---|
| Small feature, one owner, clear idea | One-page brief: problem, user, what it does, acceptance criteria, out of scope |
| Personal or solo product, MVP | Short PRD: sections 1 to 8 below, tight |
| Handed to someone else or an AI coding agent | Full PRD, with file paths, stack constraints and a do-not-touch list, split into phases |
| Client or agency work | Full PRD, acceptance criteria written as sign-off checks |

### Structure

```markdown
# [Product or feature name]: PRD

> **TL;DR:** [3 to 4 lines: what is being built, for whom, the first milestone, the first thing to do]

## 1. Problem
[What is broken or missing, and what people do instead today.]

## 2. Users and jobs to be done
[One primary user, specific. The job they are trying to get done.]

## 3. Goals and success
- Goal: ...
- Success metric: [falsifiable, e.g. "a new user completes setup in under 3 minutes"]
- Non-goals: ...

## 4. Scope
**In scope (this version):** ...
**Out of scope:** ...
**MVP cut:** [the smallest version that proves the idea]
**Suggested additions (Proposed, accept or cut each):** [anything not in the source: extra integrations, analytics, tooling. Keep these out of the requirements table until accepted.]

## 5. Functional requirements
| ID | Source | Requirement | Acceptance criteria |
|---|---|---|---|
| R1 | Brief / Derived / Proposed | | Given ... when ... then ... |

`Source` is mandatory. `Brief` rows keep the source's own words for hard rules and "don't" lines. `Derived` rows name the source line they follow from. `Proposed` rows are optional and also listed under Suggested additions. An acceptance criterion may test the requirement but must not add a rule the source did not state.

Write each as one behaviour. Group by feature area. Include key states and failure cases.

## 6. Non-functional requirements
[Only those that apply: performance, security and privacy, accessibility, offline behaviour, platforms and devices, scale, reliability, compliance.]

## 7. Data and integrations
[Main entities and how they relate. External APIs or services, auth method, and what happens when they fail.]

## 8. Tech constraints
[Stack, hosting, existing codebase, libraries to use or avoid, anything the builder must not touch. Leave open unless a real constraint exists.]

## 9. Analytics and release
[What to measure, how it ships (store release, deploy, feature flag), rollback plan, who needs to be told.]

## 10. Risks and assumptions
- [Assumption] ...
- Risk: ... Mitigation: ...

## 11. Priorities (Now / Next / Later)
[See below. Number the steps once, continuously, name the requirement IDs each covers, and write dependencies as "after step N".]

## 12. Open questions
| Question | Owner | Blocks |
|---|---|---|

### Resolved questions
| Question | Answer | Date |
|---|---|---|

## 13. Changes
[One dated line each time an answer or a decision changes the document: what changed, who decided, which requirements it touched.]
```

Quote hard rules and "don't" lists from the source word for word and keep their sharp edges ("never auto-send", "no keys in the app"). Do not soften them into "should avoid". If two lines of the source conflict, put both quotes in Open Questions.

### Writing requirements well

- One behaviour per requirement, with an ID.
- Acceptance criteria are pass or fail. Prefer "Given / when / then" for behaviour.
- Describe the user-visible outcome, not the implementation, unless a constraint demands it.
- Include the unhappy paths: empty data, no network, permission denied, invalid input.
- If an AI feature is involved, say what acceptable output looks like and what happens when it is wrong, since probabilistic behaviour cannot be specified as a fixed rule.

### For an AI coding agent as the reader

Split the PRD into phases of one to two pages each. Add: stack and versions, folder and file conventions, the order to build in, what each phase must demonstrate, and a do-not-touch list. Keep requirement IDs stable so progress can be tracked against them.

### Lifecycle phases for build priorities

Use only the phases that apply, and mark skipped ones as out of scope with a reason.

1. **Discovery:** confirm the problem, user, and MVP cut.
2. **Design:** flows and screens, or confirm that design is handled elsewhere.
3. **Technical setup:** stack, project scaffolding, data model, accounts and keys needed.
4. **Core build:** the one flow that proves the idea, end to end, before anything else.
5. **Secondary features:** everything else in scope.
6. **QA and hardening:** testing, error states, performance, security pass.
7. **Launch:** release process, store or hosting setup, analytics on.
8. **Post-launch:** monitor, collect feedback, decide what moves up from Later.

### Priority guidance

- Now is the thinnest end-to-end slice, not the most important individual feature. A working core loop teaches more than a finished settings page.
- Anything that requires an external dependency (approval, API access, a client asset) is Now if it has a long lead time, even if the work itself is small.
- Auth, payments, and data migration go earlier than they feel they should, because they cause the most late surprises.
- Polish, admin tools, and extra integrations go in Later.
- Every requirement ID appears in at least one step. Rules that apply everywhere (privacy, security, never-do lists) get a final standing-rules step and are also checked inside each step.
- If a step needs something another step produces (auth before sync, a data model before screens), write "after step N" in the step.

---

## Task mode template

Use when the ask is a single deliverable or a small, bounded piece of work: a ticket, a quick change, a deadline-driven request, a one-off asset. A full PRD here is overkill and slows the reader down. The goal is that the person doing the work gets a crisp picture of what is expected in under a minute.

Use a task brief if the work can be finished by one person in days, not weeks, and there is no real product decision to make. If it turns out to need user research, cross-team alignment, or multiple deliverables, say so and switch to design or build mode.

### Structure

```markdown
# [Task name]

> **TL;DR:** [One or two lines: what to produce, by when.]

**What:** [The deliverable, one sentence.]
**Why:** [The reason it matters or what it unblocks, one sentence.]
**For whom:** [Who will use or review the result.]
**Deadline:** [Date, and whether it is hard or soft.]

## Inputs
[What you are starting from: files, links, copy, access, previous versions. Mark anything missing.]

## Steps (Now / Next / Later)
**Now:** [What to do first, in order]
**Next:** [What follows]
**Later:** [Optional extras, only if there is time]

## Done when
- [ ] [Checkable condition]
- [ ] [Checkable condition]
- [ ] Reviewed or approved by [name]

## Out of scope
[What is not part of this, so it does not creep in.]

## Open questions
| Question | Owner | Blocks |
|---|---|---|
```

### Guidance

- "Done when" is the most important part. Each line must be something a reviewer can tick or not tick without arguing.
- If the deliverable has a format (file type, dimensions, platform), state it in the first block.
- If the person has to wait on someone else for an input, make that the first item in Now, so the wait starts early.
- If something is ambiguous but small, state the assumption in the brief and carry on, instead of asking.
- Keep to what the source asked for. Anything you add (extra deliverables, nicer formats) is marked Proposed under the steps, not placed in Done when.
- Quote any hard rule from the source word for word in Done when.
- Priorities for a task are just the ordered steps. Only use Later if there are real optional extras.

---

## Client question bank

Use when the information needed to scope the work sits with a client, stakeholder, or someone else, not with the user. These questions come from what design and build briefs commonly need: business context, audience, goals, scope, constraints, and deliverables. Pick only the ones that fill real gaps in this requirement. Sending 30 questions gets none answered.

### How to use this bank

1. Read the gaps you found in step 3 of the main workflow.
2. Pick the questions below that close those gaps. Aim for 5 to 10 total, grouped by topic.
3. Rephrase each in plain language that fits the client. Remove jargon.
4. Put them in a section called "Client / Stakeholder Questions" at the end of the document, written so they can be copied straight into an email or chat message.
5. Tell the user which questions block the work and which are nice to know, so they can start before every answer comes back.

If the client is non-technical, give a suggested answer or options where possible (for example "Should this work on phones, desktop, or both?"), which gets faster replies than open questions.

### Question bank

#### Business and goal
- What is this for, and what should be different once it exists?
- How will you know it worked? Is there a number you are trying to move?
- Why now? Is there a launch, event, or deadline driving this?
- What happens if this is not done or is delayed?

#### Audience
- Who is the main person using this? What are they trying to do?
- Do you have any information about them: interviews, surveys, analytics, support tickets?
- Are there other groups who will use it or be affected by it (staff, admins, partners)?

#### Current state
- What exists today (site, app, process, tool)? Can we get access or screenshots?
- What is the main thing that is not working about it?
- Has anything been tried before? What happened?
- Do you have analytics, recordings, or complaints we can look at?

#### Scope
- What must be included? What can wait?
- What is explicitly not part of this?
- Are there specific pages, screens, features, or flows you already have in mind?
- Is this a one-time piece of work, or the first step of something larger?

#### References and direction
- Are there products, sites, or brands you like? What do you like about them?
- Any you want to avoid, and why?
- Do you have brand guidelines, a design system, logos, fonts, or tone of voice?

#### Content and assets
- Who provides copy, images, product data, and by when?
- Is any content still to be written or decided?

#### Technical and platform (for build work)
- Which platforms (web, iOS, Android, desktop)? Any device or browser requirements?
- Is there an existing codebase, hosting, CMS, or backend we must work with?
- Any tools or systems this must connect to (payments, CRM, analytics, email)?
- Any security, privacy, or legal requirements (data location, consent, accessibility standards)?

#### Timeline, budget, and people
- What is the deadline, and is it fixed or flexible?
- Are there milestones or review dates?
- What is the budget range, or the effort you expect this to take?
- Who makes the final decision? Who else needs to review, and how many rounds of feedback are expected?
- Who is the day-to-day contact, and how fast can they answer questions?

#### Deliverables and handoff
- What do you expect to receive at the end (files, prototype, working product, documentation)?
- In what format, and who takes it from there?
- Is there support or maintenance expected after delivery?

### Output format for the client list

```markdown
## Client / Stakeholder Questions

Context: [one sentence on what the questions are for]

**Needed before we can start**
1. ...
2. ...

**Helpful, but we can begin without it**
3. ...
4. ...

Assumptions we are working with until you reply:
- [Assumption] ...
```