Product Requirements Document (PRD)

Try it: /pm-skills:deliver-prd "Your context here"

A Product Requirements Document is the primary specification artifact that communicates what to build and why. It bridges the gap between problem understanding and engineering implementation by providing clear requirements, success criteria, and scope boundaries. A good PRD enables engineering to build the right thing while maintaining flexibility on implementation details.

When to Use

After problem and solution alignment, before engineering work begins
When specifying features, epics, or product initiatives for handoff
When multiple teams need to coordinate on a shared deliverable
When stakeholders need to approve scope before investment
As reference documentation during development and QA

When NOT to Use

The problem is still unframed or contested -> use define-problem-statement first; a PRD assumes an agreed problem
You need a one-page pitch to align stakeholders on an approach -> use develop-solution-brief; the PRD comes after that alignment
You only need the work broken into tickets for a sprint -> use deliver-user-stories
You are recording a technical or architectural decision -> use develop-adr

How to Use

Invoke the skill by name (/pm-skills:deliver-prd on Claude Code, $deliver-prd on Codex):

/pm-skills:deliver-prd "Your context here"

Or reference the skill file directly: skills/deliver-prd/SKILL.md

Instructions

When asked to create a PRD, follow these steps:

Summarize the Problem Start with a brief recap of the problem being solved. Link to the problem statement if available. Ensure readers understand why this work matters before diving into what to build.
Define Goals and Success Metrics Articulate what success looks like. Include specific, measurable metrics with baselines and targets. These metrics should connect directly to the problem being solved.
Outline the Solution Describe the proposed solution at a high level. Focus on user-facing functionality and key capabilities. Include enough detail for stakeholders to evaluate the approach without over-specifying implementation.
Detail Functional Requirements Break down what the system must do. Use user stories or requirement statements. Each requirement should be testable - someone should be able to verify if it’s met.
Link AI Behavior to Evidence (only when the feature’s output comes from a model) Skip this step entirely for deterministic features. When a model produces the output, the behavior varies run to run, so “it works” is a claim that needs evidence attached. Name the behaviors that are requirements of this release and, for each one, how it will be shown to hold and at what threshold. Refusal and abstention get their own rows: a model has no dependable default for either, so what the feature does when it should not answer is a requirement, not an implementation detail. Score each component of a multi-step feature separately, because an end-to-end pass rate hides which step failed. State how the case set was sized as a method, never as a borrowed number.
Define Scope Boundaries Explicitly state what’s in scope, out of scope, and deferred to future iterations. Clear scope prevents scope creep and sets realistic expectations.
Address Technical Considerations Note any technical constraints, architectural decisions, or integration requirements. Don’t design the system, but surface considerations engineering needs to know.
Write the Agent Execution Contract (only when an executor will implement this without the authoring context) Skip this step entirely when the implementers were in the room. A coding agent, an outside contractor, or a team picking this up cold cannot infer what you already know, so declare it: which sources are authoritative and which wins when two disagree, what must not be touched and why, how each FR-n is verified and by whom, and the conditions where the executor must stop and escalate rather than decide. Name an owner for every escalation; an escalation with no addressee becomes a guess. A requirement with no verification is not ready to hand off, because nothing distinguishes “done” from “the executor believes it is done”.
Identify Dependencies and Risks List external dependencies, assumptions, and risks that could impact delivery. Include mitigation strategies where applicable.
Propose Timeline and Milestones Outline key phases and checkpoints. This helps stakeholders understand the delivery plan without committing to specific dates prematurely.

Project Memory Contract

Active only when .claude/pm-skills.local.md exists. With no file, ignore this section entirely and behave exactly as described above.

Reads: active_initiative, and any interpretation artifacts recording personas or research findings. Use them instead of asking for context that has already been produced. If none exist, ask as normal and never invent a persona to fill the gap.
Writes: the PRD as a decision artifact, and its committed scope boundaries and success metrics to the ## Decisions section.
Posture: propose the entry and wait for confirmation before writing, unless memory_auto_append: true is set, in which case append and echo what was written.
Write discipline: re-read the file immediately before writing, never from the copy that produced the proposal. If it changed in between, merge your entry into the current state and re-propose rather than overwriting; add only your own entry and leave every other field and section byte-identical. Nothing enforces this at runtime and the file is gitignored, so a careless whole-file write loses another session’s work with no way to recover it.

This is the reader half of the demonstration loop: when discover-interview-synthesis has already recorded personas, do not ask the user to supply them again.

Output Format

Use the template in references/TEMPLATE.md to structure the output. A complete PRD fills every template section: Overview; Goals & Success Metrics; User Stories; Scope; Solution Design; Technical Considerations; Dependencies & Risks; Timeline & Milestones; Open Questions; the Appendix when supporting material exists; AI Behavior and Evaluation when the feature’s output comes from a model; and the Agent Execution Contract when an executor will implement it without the authoring context.

The last three are conditional by design. A PRD that omits a section its feature does not need is complete; a PRD that includes an empty one is not.

Examples

See references/EXAMPLE.md for a completed example.

Output Template

PRD: [Feature/Initiative Name]

Overview

Problem Statement

[Problem summary]

Solution Summary

[Solution summary]

Target Users

[Target user description]

Goals & Success Metrics

Goals

[Primary goal]
[Secondary goal]
[Secondary goal]

Success Metrics

Metric	Current Baseline	Target	Timeline
[Primary metric]	[Value]	[Value]	[Date]
[Secondary metric]	[Value]	[Value]	[Date]

Non-Goals

[Non-goal 1]
[Non-goal 2]

User Stories

ID	User Story	Priority
US-1	As a [user], I want [action] so that [benefit]	P0
US-2	As a [user], I want [action] so that [benefit]	P0
US-3	As a [user], I want [action] so that [benefit]	P1

See [link to detailed user stories] for full acceptance criteria.

Scope

In Scope

[Feature/capability 1]
[Feature/capability 2]
[Feature/capability 3]

Out of Scope

[Excluded item 1]
[Excluded item 2]

Future Considerations

[Future item 1] - [Rationale for deferral]
[Future item 2] - [Rationale for deferral]

Solution Design

Functional Requirements

[Requirement Area 1]

FR-1: [Requirement statement]
FR-2: [Requirement statement]

[Requirement Area 2]

FR-3: [Requirement statement]
FR-4: [Requirement statement]

User Experience

[UX notes or link to designs]

Edge Cases

Scenario	Expected Behavior
[Edge case 1]	[Behavior]
[Edge case 2]	[Behavior]

AI Behavior and Evaluation

Behavior Requirements and Their Evidence

ID	Behavior required	How it is evaluated	Passing threshold
AB-1	[What the feature must do in the normal case]	[Cases, rubric, or check]	[Threshold, and how it was chosen]
AB-2	[What it must refuse, and what it says instead]	[Cases, rubric, or check]	[Threshold, and how it was chosen]
AB-3	[How it abstains when it cannot ground an answer]	[Cases, rubric, or check]	[Threshold, and how it was chosen]

Evaluation Set

Where the cases live: [Path or system]
Slices that must be covered: [Derive them, do not guess. At minimum: every AB-n row above; every refusal and every abstention case; and the input classes where a failure costs the most - name the cost, not just the class]
Floor per slice, and what it commits you to: [For each slice: the minimum cases you will not go below, and why that slice earns that floor. Say what the floor buys in coverage terms, which is that a named failure mode was searched for deliberately rather than incidentally. Do not state or imply a failure rate]
Held-out cases: [The cases not used while tuning, kept back to check the thresholds still hold. If none are held out, say so and say why the thresholds are not overfit]
Slices scored separately: [The segments reported on their own, never only in the aggregate. An aggregate that passes while one slice fails is a failing evaluation]
If someone asks for a rate: [This set does not support one, and saying so is the correct answer. Report the raw counts per slice and the floor each was held to. A rate claim needs a designed sample, not a curated evaluation set, and inventing one here is how a PRD ends up carrying a number nobody can defend]

Technical Considerations

Constraints

[Constraint 1]
[Constraint 2]

Integration Points

[System/API 1]: [Integration notes]
[System/API 2]: [Integration notes]

Data Requirements

[Data notes]

Agent Execution Contract

Authoritative Sources

Source	Path or link	Definitive for
[Source 1]	[Path or link]	[Scope it settles]
[Source 2]	[Path or link]	[Scope it settles]

Do Not Touch

Path or system	Reason it is off limits
[Path or system]	[Reason]

Requirement Verification Map

Requirement	How it is verified	Who verifies
FR-1	[Test, check, or observation that proves it]	[Automated / QA / PM]
FR-2	[Test, check, or observation that proves it]	[Automated / QA / PM]

Stop and Escalate

Condition	Escalate to
[Condition that must not be resolved unilaterally]	[Owner]
[Condition that must not be resolved unilaterally]	[Owner]

Dependencies & Risks

Dependencies

Dependency	Owner	Status	Impact if Delayed
[Dependency 1]	[Team/Person]	[Status]	[Impact]
[Dependency 2]	[Team/Person]	[Status]	[Impact]

Risks

Risk	Likelihood	Impact	Mitigation
[Risk 1]	[H/M/L]	[H/M/L]	[Mitigation strategy]
[Risk 2]	[H/M/L]	[H/M/L]	[Mitigation strategy]

Timeline & Milestones

Milestone	Description	Target Date
[Milestone 1]	[Description]	[Date]
[Milestone 2]	[Description]	[Date]
[Launch]	[Description]	[Date]

Open Questions

[Question 1] - Owner: [Name]
[Question 2] - Owner: [Name]

Appendix

Problem Statement - add link or path
User Research - add link or path
Design Specs - add link or path
Technical Design - add link or path

Revision History

Version	Date	Author	Changes
1.0	[Date]	[Author]	Initial draft

Example Output

PRD: Recurring Tasks

This is a fictional worked example. TaskFlow does not exist and no research was run. The research findings, baselines and targets are invented to demonstrate structure.

Overview

Problem Statement

Users of TaskFlow spend significant time manually recreating repetitive tasks that occur on predictable schedules. Our research shows that 34% [fictional] of all tasks created are duplicates of previous tasks, and power users report spending 2+ hours per week [fictional] on this manual work. This friction reduces productivity and causes users to miss recurring deadlines when they forget to recreate tasks.

Solution Summary

Add recurring task functionality that allows users to create tasks that automatically regenerate on defined schedules. Users can set weekly, monthly, or custom recurrence patterns, and the system will create new task instances automatically while preserving the connection to the original recurring series.

Target Users

Primary: Team leads and project managers who manage ongoing operational tasks (weekly reports, monthly reviews, recurring meetings)
Secondary: Individual contributors who have personal recurring responsibilities (timesheets, 1:1 prep, status updates)

Goals & Success Metrics

Goals

Reduce time spent on manual task recreation by 80%
Decrease missed recurring deadlines by 50%
Increase weekly active usage among power users

Success Metrics

Metric	Current Baseline	Target	Timeline
Duplicate task creation rate	34% [fictional]	15%	90 days post-launch
Missed recurring deadlines	12 per user/month [fictional]	6 per user/month	90 days post-launch
Power user WAU	67% [fictional]	75%	90 days post-launch
Feature adoption (% using recurring)	0%	40%	90 days post-launch

Non-Goals

Task dependencies or predecessor relationships
Automated task assignment rotation (e.g., round-robin)
Integration with external calendar systems (deferred to v2)

User Stories

ID	User Story	Priority
US-1	As a team lead, I want to create a task that repeats weekly so that I don’t have to manually recreate it	P0
US-2	As a user, I want to edit a single instance without affecting the series so that I can handle exceptions	P0
US-3	As a user, I want to see upcoming instances of recurring tasks so that I can plan my workload	P0
US-4	As a user, I want to pause and resume a recurring series so that I can handle temporary schedule changes	P1
US-5	As a team lead, I want to edit the entire series at once so that I can make bulk changes efficiently	P1
US-6	As a user, I want to set an end date for recurrence so that temporary projects don’t create tasks forever	P1

See User Stories Document for full acceptance criteria.

Scope

In Scope

Create recurring tasks with daily, weekly, monthly patterns
Edit single instance vs. entire series
View upcoming instances (next 4 weeks)
Pause/resume recurring series
Set recurrence end date or occurrence count
Delete single instance vs. entire series
Recurring tasks visible in list view, calendar view, and board view

Out of Scope

Custom recurrence patterns (e.g., “every 3rd Tuesday”) - v2
Calendar sync (Google Calendar, Outlook) - v2
Task assignment rotation - future consideration
Recurring subtasks - future consideration
Bulk operations on multiple recurring series

Future Considerations

Custom patterns (v2): Complex scheduling like “first Monday of each month” or “every 2 weeks” - deferred due to UI complexity; standard patterns cover 85% [fictional] of use cases
Calendar sync (v2): Two-way sync with external calendars - deferred due to integration complexity and scope
Assignment rotation: Auto-rotate assignee for team tasks - requires additional UX research to understand use cases

Solution Design

Functional Requirements

Task Creation

FR-1: Users can mark any new task as recurring during creation
FR-2: Recurrence options include: Daily, Weekly (select days), Monthly (select date or day-of-week)
FR-3: Users can set recurrence to end after X occurrences or on a specific date
FR-4: Default recurrence end is “never” with system limit of 52 weeks forward generation

Instance Management

FR-5: Each recurring task generates instances up to 4 weeks in advance
FR-6: Completing an instance marks only that instance complete and triggers next instance generation
FR-7: Editing an instance shows option: “Edit this instance only” or “Edit all future instances”
FR-8: Deleting an instance shows option: “Delete this instance only” or “Delete entire series”

Series Management

FR-9: Users can pause a recurring series, stopping new instance generation
FR-10: Paused series display visual indicator and can be resumed
FR-11: Users can view and edit the recurrence pattern from any instance

User Experience

Creation Flow:

User clicks “Add Task”
User enters task details
User clicks “Make Recurring” toggle
Recurrence panel expands with pattern options
User selects pattern and confirms
First instance created immediately, future instances generated

Visual Indicators:

Recurring tasks show refresh icon in list/board views
Instance number displayed (e.g., “#3 of series”)
Paused series show pause indicator with muted styling

See Figma Design Specs for detailed mockups.

Edge Cases

Scenario	Expected Behavior
User deletes instance that’s in progress	Prompt: “This task has logged time. Delete anyway?”
Series created with past start date	Create instance for next valid date, not retroactively
Monthly recurrence on 31st	Use last day of month for shorter months
User changes recurrence pattern	Apply to future instances only, preserve completed instances
User completes instance early	Next instance still generates on schedule

Technical Considerations

Constraints

Maximum 52 weeks of forward instance generation (prevent database bloat)
Recurrence calculations must handle timezone correctly (user’s local time)
Instance generation must be idempotent (safe to re-run)

Integration Points

Notification Service: Recurring task reminders use existing notification infrastructure
Activity Feed: Instance completion logs to activity feed as normal task completion
Reporting: Recurring tasks aggregate into existing productivity reports

Data Requirements

New recurring_series table linking instances to parent series
recurrence_pattern stored as RRULE-compatible format for future calendar sync
Soft delete for series to preserve historical data
Migration: No data migration required (new feature)

Agent Execution Contract

Authoritative Sources

Source	Path or link	Definitive for
This PRD	(this document)	Scope, functional requirements, and what is deferred
Figma design specs	Figma Design Specs	All visual treatment, copy in dialogs, and the pause indicator
RFC 5545 (RRULE)	Public spec	The stored format of `recurrence_pattern`; do not invent a serialization
Existing notification service contract	Platform Team’s service docs	Reminder payload shape and delivery guarantees

When the PRD and the Figma specs disagree on behavior, the PRD wins. When they disagree on wording or layout, Figma wins.

Do Not Touch

Path or system	Reason it is off limits
The existing `tasks` table schema	Recurrence lives in a new `recurring_series` table; altering `tasks` would put a migration in the critical path, and this PRD commits to none
Notification service internals	We are a consumer of it. Behavior changes there affect four other features [fictional] and belong to the Platform Team
The activity-feed writer	Instance completion must log through the existing normal-task-completion path so reporting keeps working unchanged

Requirement Verification Map

Requirement	How it is verified	Who verifies
FR-1	E2E: create a task with the recurring toggle on, assert a series row exists	Automated
FR-2	Unit: each of Daily, Weekly-with-days, Monthly-by-date and Monthly-by-weekday round-trips through RRULE	Automated
FR-3	Unit: series ends after N occurrences; series ends on a given date. Both assert no instance past the boundary	Automated
FR-4	Unit: an unbounded series stops generating at 52 weeks forward	Automated
FR-5	Unit: at any point in a live series, exactly the next 4 weeks of instances exist	Automated
FR-6	E2E: complete one instance, assert siblings unchanged and exactly one new instance appears	Automated
FR-7	Manual: the two-option dialog appears and each branch behaves as labelled	QA
FR-8	Manual: the two-option dialog appears; series delete is soft and history survives	QA
FR-9	E2E: pause a series, advance the clock, assert no new instances	Automated
FR-10	Manual: paused series shows the indicator and resumes correctly from the UI	QA
FR-11	Manual: the pattern is reachable and editable from an arbitrary instance, not only the first	QA

Stop and Escalate

Condition	Escalate to
Any change that requires a migration on `tasks`	PM, before writing it. The no-migration commitment is load-bearing for the timeline
A DST or timezone case where “the same local time” is ambiguous or does not exist	PM plus Platform Team. Pick nothing by default; the wrong choice is silent and users notice weeks later
The 52-week generation cap proving too low for a real user pattern	PM. The cap is a database-bloat trade-off, not a technical limit
Design specs still In Review blocking a screen	Design Team, and build behind the agreed FR rather than guessing at the visual

Dependencies & Risks

Dependencies

Dependency	Owner	Status	Impact if Delayed
Calendar view refactor	Frontend Team	In Progress	Cannot show recurring instances in calendar
Background job infrastructure	Platform Team	Complete	None
Design specs finalized	Design Team	In Review	Delays development start

Risks

Risk	Likelihood	Impact	Mitigation
User confusion about instance vs. series editing	Medium	Medium	Clear UI copy, confirmation dialogs, user testing
Performance impact of instance generation	Low	High	Lazy generation, batch processing, monitoring
Feature complexity delays launch	Medium	Medium	MVP scope locked, defer edge cases to v1.1
Low adoption if UX isn’t intuitive	Medium	High	User testing before launch, in-app education

Timeline & Milestones

Milestone	Description	Target Date
Design Complete	Final mockups approved	Jan 24, 2026
Backend Complete	API and data model ready	Feb 7, 2026
Frontend Complete	UI implementation done	Feb 21, 2026
QA Complete	Testing and bug fixes	Feb 28, 2026
Beta Launch	10% rollout	Mar 3, 2026
GA Launch	100% rollout	Mar 10, 2026

Open Questions

Should we support “business days only” recurrence? - Decision: No, defer to v2
How do we handle recurring tasks when user loses access to project? - Owner: Product
Should paused series auto-resume after X time? - Owner: Product
What’s the right default reminder time for recurring tasks? - Owner: Design

Appendix

Revision History

Version	Date	Author	Changes
0.1	Jan 10, 2026	Sarah Chen	Initial draft
0.2	Jan 12, 2026	Sarah Chen	Added edge cases, updated scope
1.0	Jan 14, 2026	Sarah Chen	Final review, approved by stakeholders

Real-World Examples

See this skill applied to three different product contexts:

Storevine (B2B): Storevine B2B ecommerce platform . Campaigns (built-in email marketing)

Prompt:

deliver-prd

Feature: Campaigns . native email marketing for Storevine merchants

Context: Storevine all-in-one ecommerce + web builder, ~18k active merchants
[fictional]. See: competitive-analysis (filed last week), problem-statement
(Q4 discovery doc).

Discovery: Email marketing is a top-3 churn driver. Exit survey: 22% of churned
accounts in Q4 cited "had to use a separate email tool" as a primary reason
[fictional]. Power merchants patch with Klaviyo or Mailchimp; smaller merchants
skip email entirely because setup friction is too high.

Validated solution: Built-in Campaigns . broadcast email + basic audience
segmentation. Phase 1 email only, SMS deferred. Pre-built templates, audience
builder using order/tag data we already have. No custom HTML editor v1.

Success targets:
- 40% of active merchants send ≥1 campaign in first 90 days post-launch [fictional]
- Reduce email-churn contribution by 30% at 6 months [fictional]
- Campaigns becomes a net-new revenue line (paid tier above free send limit)

Scope locked with eng: v1 = broadcast email + 3 automations (abandoned cart,
welcome, re-engagement). No SMS, no A/B testing, no multi-step sequences.

Technical decisions already made:
- Sending via SendGrid (existing account)
- Audience builder queries existing customer/order tables . no new pipeline
- Legal review on CAN-SPAM + GDPR required before launch (not yet started)

Stakeholders: Growth PM (owner), Eng Lead (aligned), Design (in progress),
Legal (needs to review compliance section), Marketing (will dog-food).

Output:

PRD: Storevine Campaigns

Brainshelf (Consumer): Brainshelf consumer PKM app . Resurface feature PRD for Sprint 8 build

Prompt:

deliver-prd

resurface prd for sprint 8. pulling everything together: solution brief,
adr (resend), design rationale (text layout), spike (tfidf).

building the daily email digest that surfaces 3-5 saved items matched
to recent reading. opt-in required. 7:30 AM local time. tfidf for
topic matching. resend for email. text-only layout.

target users: active savers (10+ items, active in last 30 days) .
about 9,800 users [fictional].

metrics: 7-day return rate 18%→25% [fictional], email CTR ≥15% [fictional],
unsub ≤2%/week [fictional].

scope: digest email, topic matching, opt-in flow, cadence setting,
one-click read, analytics events. NOT doing: in-app resurfacing,
push notifications, smart collections.

timeline: sprint 8 build (feb 3-16), setup week (mar 2-8),
a/b test (mar 9 - apr 5), decision (apr 11).

Output:

PRD: Resurface . Morning Email Digest

Workbench (Enterprise): Workbench enterprise collaboration platform - Blueprints v1 PRD for required-section enforcement and approval gates

Prompt:

deliver-prd

Here is the structured brief for the Blueprints v1 PRD.

**Product context:**
- Workbench collaboration platform, ~500 enterprise customers [fictional], Series B
- Blueprints = reusable document templates with required sections and approval gates
- Core problem: 38% of Blueprints reach approval with ≥1 empty section [fictional]; median time to first approval is 4.0 days [fictional]; 60% of enterprise projects lack an approved kickoff doc at handoff [fictional]

**Prior decisions to incorporate:**
- ADR-012: Yjs CRDTs selected for real-time co-editing (45ms merge latency at 20 concurrent editors [fictional], +38KB gzipped [fictional])
- Design rationale: Hybrid wizard/canvas -- guided wizard for first-time authors, blank canvas for returning authors
- Opportunity tree: Priority path is documentation governance gap → required-section enforcement
- Hypothesis: Required sections reduce time-to-approved from 4.0 days to ≤2.5 days [fictional]; validation via A/B test (Mar 9 -- Apr 5, 2026)

**Target users:** Enterprise ops managers (creators), department heads (approvers), IT security leads (admin/provisioning)

**Key features for v1:**
1. Required-section enforcement (submit button disabled until all required sections complete)
2. Native approval gates (role-based routing, sequential and parallel approval)
3. Yjs real-time co-editing (offline-first, sub-document-level sync)
4. Hybrid wizard/canvas creation flow
5. Enterprise security suite (SAML SSO, audit logs, role-based access)

**Timeline:** Closed beta running now with 80 accounts [fictional]; A/B test Mar 9 -- Apr 5; GA target April 2026

**Success metrics:** Time-to-approved ≤2.5 days [fictional], empty-section rate ≤10% [fictional], enterprise account growth from 500 to 650 in 12 months [fictional]

Please generate a complete PRD following the standard template.

Output:

PRD: Workbench Blueprints v1

Quality Checklist

Before finalizing, verify:

Product Requirements Document (PRD)

When to Use

When NOT to Use

How to Use

Instructions

Project Memory Contract

Output Format

Examples

Output Template

PRD: [Feature/Initiative Name]

Overview

Problem Statement

Solution Summary

Target Users

Goals & Success Metrics

Goals

Success Metrics

Non-Goals

User Stories

Scope

In Scope

Out of Scope

Future Considerations

Solution Design

Functional Requirements

[Requirement Area 1]

[Requirement Area 2]

User Experience

Edge Cases

AI Behavior and Evaluation

Behavior Requirements and Their Evidence

Evaluation Set

Technical Considerations

Constraints

Integration Points

Data Requirements

Agent Execution Contract

Authoritative Sources

Do Not Touch

Requirement Verification Map

Stop and Escalate

Dependencies & Risks

Dependencies

Risks

Timeline & Milestones

Open Questions

Appendix

Related Documents

Revision History

Example Output

PRD: Recurring Tasks

Overview

Problem Statement

Solution Summary

Target Users

Goals & Success Metrics

Goals

Success Metrics

Non-Goals

User Stories

Scope

In Scope

Out of Scope

Future Considerations

Solution Design

Functional Requirements

Task Creation

Instance Management

Series Management

User Experience

Edge Cases

Technical Considerations

Constraints

Integration Points

Data Requirements

Agent Execution Contract

Authoritative Sources

Do Not Touch

Requirement Verification Map

Stop and Escalate