to-prd

This skill takes the current conversation context and codebase understanding and produces a PRD. Do not interview the user—just synthesize what you already know.

The issue tracker and triage label vocabulary should already have been provided to you—if not, run /setup-matt-pocock-skills。

Process

If you haven't already done so, explore the repository to understand the current state of the codebase. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.
Outline the major modules that will need to be built or modified to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.

A deep module (as opposed to a shallow module) is one that encapsulates a large amount of functionality behind a simple, testable, and rarely changing interface.

Confirm these modules with the user to check whether they match their expectations. Confirm with the user which modules they want tests written for.

Write the PRD using the template below, then publish it to the project issue tracker. Apply the ready-for-agent triage label - no additional triage needed.

Problem Statement

The problem the user is facing, from the user's perspective.

Solution

The solution to the problem, from the user's perspective.

User Stories

A long, numbered list of user stories. Each user story should be in the following format:

As a <role>, I want <feature>, so that <benefit>

This user story list should be very extensive, covering all aspects of the feature.

Implementation Decisions

A list of implementation decisions made. This can include:

The modules that will be built/modified
The interfaces of those modules that will be modified
Technical clarifications for developers
Architectural decisions
Schema changes
API contracts
Specific interactions

Do not include specific file paths or code snippets. They may become outdated very quickly.

Exception: if a prototype produced snippets that encode decisions more precisely than prose (state machines, reducers, schemas, type shapes), inline it in the relevant decision and briefly note that it came from the prototype. Trim to the decision-rich parts—not a working demo, just the important parts.

Testing Decisions

A list of testing decisions made. Including:

A description of what constitutes a good test (only testing external behavior, not implementation details)
Which modules will be tested
Precedents for tests (i.e., similar types of tests in the codebase)

Out of Scope

A description of things that are out of scope for this PRD.

Further Notes

Any further notes about the feature.