Product Requirements Skill

Purpose

This skill governs how the AI drafts, reviews, and structures all product requirement artifacts. It provides mandatory templates, decision logic, and quality gates — not generic writing advice. Every output must be traceable, unambiguous, and actionable by engineering, design, and QA.

Clarification — When to Ask

Ask before starting only when:

• The artifact type is unclear → "Are you drafting a full PRD, a single user story, or a scoped feature spec?"

• The target audience is unclear → "Is this for engineering review, stakeholder sign-off, or backlog grooming?"

• Context is missing (no product area, no problem description) → "What problem does this solve, and who is affected?"

Never ask about:

• Preferred format — always apply the templates defined in this skill

• Level of detail — always produce complete artifacts; flag missing information inline with [TBD: reason]

• Whether to include non-goals — always include them; they are mandatory

Artifact Standards

1. Product Requirements Document (PRD)

Use for: new features, major product changes, cross-functional initiatives.

Mandatory sections — always include all of them:

## Overview
One paragraph. State: what this is, why it exists, and what success looks like. No technical jargon. Written for a non-engineering stakeholder.

## Problem Statement

• Who is affected? (User segment or persona)

• What is the pain or opportunity?

• What evidence supports this? (data, user research, support tickets, business signal)

• What happens if we don't solve it?

## Goals
List 3–5 specific, measurable outcomes. Each goal must answer: How will we know we succeeded?

Format:

• Goal: [Outcome statement] — Metric: [How it is measured] — Target: [Threshold or value]

## Non-Goals
Explicitly state what this PRD does NOT cover. Every PRD must have at least 2 non-goals. Non-goals prevent scope creep and align stakeholders before work begins.

Format:

• Out of scope: [Topic] — Reason: [Why this is excluded now]

## User Stories
See User Story standards below. Include all stories required to deliver the goals.

## Acceptance Criteria
See Acceptance Criteria standards below. Link each criterion to a user story.

## Scope & Boundaries
Define what is in scope for this release. Distinguish between MVP scope and future scope explicitly.

## Decision Log
See Decision Logic standards below.

## Open Questions
List unresolved questions blocking or influencing decisions. Each must have an owner and a resolution deadline.

## Dependencies
List teams, systems, or external factors this PRD depends on.

## Launch Criteria
Define the minimum conditions that must be true before this ships. These are binary — met or not met.

2. User Stories

Mandatory format:

As a [specific user type],
I want to [action or capability],
so that [concrete benefit or outcome].

Quality rules — enforce all of them:

• "User" is never acceptable as the actor. Use a specific persona or role (e.g., "account admin", "first-time buyer", "support agent").

• The benefit must be a real outcome, not a restatement of the action. "So that I can use the feature" is rejected.

• Each story must be independently deliverable. If it can't ship alone, it's an epic — break it down.

• Each story maps to exactly one primary user type. Multi-actor stories must be split.

• Stories must be sized. Apply a relative effort label: XS / S / M / L / XL. Anything XL must be broken into smaller stories before it enters a sprint.

User Story ID convention:
Assign sequential IDs: US-001, US-002, etc. Reference these IDs in acceptance criteria and the decision log.

Example of a well-formed user story:

As a finance manager,
I want to export invoices as a filtered PDF report,
so that I can submit a monthly cost summary to my CFO without manual data entry.
Size: M | ID: US-007

Example of a rejected user story:

As a user, I want to see my data, so that I can use the platform.
Reason: Actor is generic, benefit is a tautology, scope is undefined.

3. Acceptance Criteria

Mandatory format — use Given/When/Then (Gherkin-style):

Given [precondition or context],
When [action or event],
Then [expected outcome — observable and verifiable].

Quality rules:

• Each criterion must be testable by a QA engineer without interpretation. If it requires judgment to evaluate, rewrite it.

• Avoid "should", "usually", "often", "may" — use "must", "does", "returns", "displays".

• Include both the happy path and at least one edge case or failure path per user story.

• Acceptance criteria are linked to user story IDs: label each block with the relevant US-XXX.

Example — Happy Path (US-007):

Given the user has the Finance Manager role and at least one invoice exists in the selected date range,
When they click "Export PDF" and confirm the filter settings,
Then a PDF is generated within 5 seconds containing only invoices matching the filter, formatted with the company logo and pagination.

Example — Edge Case (US-007):

Given the user selects a date range with no matching invoices,
When they click "Export PDF",
Then the system displays an inline message: "No invoices found for the selected period. Please adjust your filters." and no PDF is generated.

4. Scope & Non-Goals

Scope answers: What will be built in this release?
Non-Goals answer: What will explicitly NOT be built, and why?

Both are mandatory. Omitting non-goals is a quality failure — they exist to prevent implicit assumptions from becoming unplanned work.

Scope definition rules:

• Scope items must be atomic enough to estimate and assign.

• Each scope item must trace to at least one user story.

• Anything that is "nice to have" must be moved to future scope explicitly, not left ambiguous.

Non-goal rules:

• Every non-goal must include a reason (technical, strategic, timing, or resource-based).

• Non-goals are not permanent rejections — include a flag if the item is a candidate for a future release: [Candidate for v2].

• Common non-goal categories to always consider: performance optimization beyond MVP threshold, internationalization/localization, admin tooling, analytics/reporting beyond core metrics, mobile parity (if web-first), third-party integrations not in the critical path.

5. Decision Logic

The Decision Log captures all significant product decisions made during the PRD lifecycle. It exists to prevent re-litigation of settled questions and to give future contributors context.

When to log a decision:

• A design or scope tradeoff was made

• An alternative was considered and rejected

• A stakeholder disagreement was resolved

• A technical constraint influenced a product choice

• A non-goal was deliberately deferred rather than ruled out permanently

Mandatory format for each decision:

Example:

Process — Which Artifact to Produce

Follow this decision tree when the user's request is ambiguous:

• New feature or initiative, cross-functional impact → Full PRD (all sections)

• Single feature addition, one team → Lightweight PRD (Problem, Goals, Non-Goals, User Stories, Acceptance Criteria, Scope table)

• Existing ticket or backlog item needing detail → User Stories + Acceptance Criteria only

• Scope or boundary question → Scope table + Non-Goals section only

• Past decision needs documentation → Decision Log entry only

• Full audit or review of existing PRD → Apply all quality rules section by section; flag every violation with [Issue]: [Fix required]

Output Format Rules

• Use markdown throughout. All tables must render correctly.

• Every section header is a ## or ### heading — never bold text as a substitute for headings.

• Flag all missing information inline with [TBD: <what is needed and why>] — never silently omit required content.

• Do not use filler language ("This section will cover...", "As mentioned above..."). Every sentence must carry information.

• When producing a full PRD, use create_text_document to deliver it as a structured artifact.

• When producing a single user story or acceptance criterion, deliver inline in chat unless the user requests a document.

Quality Gate — Before Delivering Any Artifact

Check every output against this list. Fix violations before responding.

• All mandatory PRD sections present (if full PRD)

• Every user story has a specific actor, a concrete action, and a real benefit

• Every user story has a size label and an ID

• Every acceptance criterion is testable without interpretation

• At least one edge case or failure path per user story

• Non-goals section has at least 2 entries with reasons

• Scope table distinguishes this release from future releases

• Decision log entries include alternatives considered and rationale

• No open questions left without an owner and a deadline

• No [TBD] markers left without an explanation of what is needed