opencode-workflow/skills/write-a-prd/SKILL.md

---
name: write-a-prd
description: Create a pure PM PRD through user interviews and requirement refinement. The primary output is a PRD file for downstream PM stages; a GitHub issue is optional only if explicitly requested.
---

This skill will be invoked when the user wants to create a PRD. You may skip steps if you don't consider them necessary.

1. Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.

2. Clarify the target users, current workflow, pain points, constraints, desired outcomes, and release boundaries.

3. Interview the user relentlessly about every aspect of the problem until you reach a shared understanding. Walk down each branch of the product decision tree, resolving scope, behavior, and acceptance expectations one-by-one.

4. Once you have a complete understanding of the problem, goals, scope, and user-visible behavior, use the template below to write the PRD file.

If a research brief exists, use it to inform problem framing, success metrics, functional requirements, non functional requirements, and risks. Do not copy competitor solutions mechanically.

Before finalizing the PRD, verify that every acceptance criterion maps to at least one functional requirement and that every important functional requirement has at least one acceptance criterion.

**Announce at start:** "I'm using the write-a-prd skill to create the PRD."

**Primary inputs:**
- `docs/brainstorm/{date}-{feature}-design.md`
- Optional `docs/research/{date}-{topic}.md`

**Context:** This should usually run after brainstorming has produced the product direction document.

**Save plans to:** `docs/prd/{date}-{feature}.md`
- (User preferences for plan location override this default)

**Optional secondary output:** If and only if the user explicitly requests it, the PRD may also be submitted as a GitHub issue after the file has been written.

<prd-template>

## Research Inputs

Summarize relevant market, competitor, user, or regulatory insights when they materially influence the PRD. Omit this section if no research was needed.

## Problem

From the user's perspective, the problem they are currently facing and why it matters now.

## Goals

Specific outcomes this feature must achieve for the user and the business.

## Non Goals

Explicitly list what this PRD does not attempt to solve.

## Scope

Describe the in-scope behaviors, flows, and boundaries for this release.

## Success Metrics

List measurable outcomes that can be evaluated after delivery.

## User Stories

From the user's perspective, a detailed, numbered list of user stories. Each user story should follow this format:

1. As a <role>, I want to <feature>, so that I can <benefit>

<user-story-example>
1. As a mobile banking customer, I want to see my account balance, so that I can make more informed decisions about my spending.
</user-story-example>

This list of user stories should be very detailed, covering all aspects of the functionality.

## Functional Requirements

Define user-visible behavior and contractual product behavior only.

- Focus on what the system must do from the user's or consumer's perspective
- Do not include architecture, module design, schema design, API path design, or implementation details
- Tailor requirements to the feature context instead of using a fixed boilerplate list
- Include error handling, retry behavior, permissions, idempotency, or observability only when the user context makes them materially necessary

## Acceptance Criteria

For each user story or feature, define the specific, testable conditions that must be met for the feature to be considered complete and working correctly.

- Every criterion must be measurable, testable, and rejectable
- Every criterion must be implementation independent
- Always use `Given / When / Then`
- Focus on observable behavior rather than implementation details
- Every criterion must be observable and unambiguous
- Every criterion must map to at least one functional requirement

### Coverage Check

For each PRD, explicitly check whether requirements are needed for:

- Error handling
- Retry behavior
- Idempotency
- Permissions and roles
- Auditability and observability
- Performance and latency
- Availability and reliability
- Scalability and concurrency

If the feature is API-based, async, bulk, or integration-heavy, also check for:

- Status and outcome behavior
- Required response fields
- Time constraints
- Duplicate prevention behavior
- Partial failure behavior

## Edge Cases

List meaningful product edge cases based on context, such as empty input, invalid input, duplicates, retries, timeouts, concurrency, partial completion, permission conflicts, and large payloads when relevant.

## Non Functional Requirements

List only the NFRs that matter for this feature and explain them in measurable product terms when possible.

- Examples may include performance, availability, scalability, security, privacy, auditability, accessibility, retention, or compliance
- Do not force irrelevant NFR categories into the PRD

## Risks

List product, operational, compliance, or adoption risks that could affect delivery or outcome.

## Assumptions

List assumptions this PRD depends on being true.

## Dependencies

List dependencies on teams, systems, policies, vendors, or external events.

## Open Questions

List unresolved product questions that must be answered before implementation or release.

</prd-template>

## Guardrails

This is a pure PM skill.

Do:
- Define the problem, value, scope, user-visible behavior, and release boundaries
- Define measurable success metrics
- Define context-appropriate functional requirements and non functional requirements
- Define acceptance criteria in `Given / When / Then`
- Ensure PRD minimum completeness before handoff

Do not:
- Design architecture
- Design modules or internal system boundaries
- Design API paths, handlers, schemas, or databases
- Choose technologies or implementation patterns
- Break work into engineering tasks
- Write pseudocode or code

The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints to keep requirements grounded, but must not derive or prescribe implementation design from internal code structure.

## Minimum Completeness Gate

The PRD must contain:
- Problem
- Goals
- Non Goals
- Scope
- Success Metrics
- User Stories
- Functional Requirements
- Acceptance Criteria
- Edge Cases
- Non Functional Requirements
- Risks

Add these when relevant:
- Research Inputs
- Assumptions
- Dependencies
- Open Questions
- Error handling
- Idempotency
- Observability