to-prd

To PRD

Take the current conversation context and codebase understanding and produce a PRD as a GitHub issue. Do NOT interview the user — synthesize what you already know.

Workflow

1. Explore the repo to understand the current state of the codebase, if you have not already.

2. Sketch the major modules you would build or modify 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 — encapsulates a lot of functionality behind a simple, testable interface that rarely changes. See improve-codebase-architecture for the deepening discipline.

   Check with the user that these modules match their expectations. Check which modules they want tests written for.

3. Write the PRD using the template below and submit it as a GitHub issue with gh issue create.

PRD template

## 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 in the format:

1. As an <actor>, I want a <feature>, so that <benefit>

This list should be extensive and cover all aspects of the feature.

## Implementation Decisions

Decisions made during synthesis:

- The modules that will be built or modified
- The interfaces of those modules that will change
- Technical clarifications from the developer
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions

Do NOT include specific file paths or code snippets. They go stale quickly.

## Testing Decisions

- A description of what makes a good test (only test external behavior, not implementation details)
- Which modules will be tested
- Prior art for the tests (similar tests already in the codebase)

## Out of Scope

What is deliberately not in this PRD.

## Further Notes

Anything else worth recording.

Rules

• Do NOT interview the user. The skill exists to compress shared context into an artifact.
• Use the project's domain language (UBIQUITOUS_LANGUAGE.md / CONTEXT.md if present) for entities and module names.
• No file paths or line numbers in the issue body.
• After filing, print the issue URL and a one-line summary of what the PRD covers.