To Prd

Name: To Prd
Author: akillness

akillness/oh-my-skills

145 installs
40 repo stars
Updated August 4, 2026
akillness/oh-my-skills

to-prd is a Claude Code skill that generates a structured Product Requirements Document from existing conversation and codebase context and publishes it to the project issue tracker.

About

to-prd generates a structured Product Requirements Document from existing conversation context and codebase state, synthesizing knowledge rather than interviewing the user. A developer uses it to document requirements for a feature or change and publish it to the project issue tracker before decomposing work into tickets. It matters because it produces a formal, user-facing spec (problem, solution, user stories, out-of-scope) that prevents scope creep.

Generates a structured PRD from existing conversation and codebase state without interviewing
Emphasizes deep modules with simple, testable interfaces and stable contracts
Publishes the PRD to the issue tracker with a needs-triage label

To Prd by the numbers

145 all-time installs (skills.sh)
Ranked #573 of 1,879 Documentation skills by installs in the Skillselion catalog
Data as of Aug 5, 2026 (Skillselion catalog sync)

At a glance

to-prd capabilities & compatibility

Capabilities: prd generation · requirements capture · user story writing
Use cases: documentation · planning · project management

From the docs

What to-prd says it does

Convert current conversation context into a structured PRD for publication to the project issue tracker.

SKILL.md

Do not interview the user — synthesize from existing context.

SKILL.md

npx skills add https://github.com/akillness/oh-my-skills --skill to-prd

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/akillness/oh-my-skills/to-prd.svg)](https://skillselion.com/skills/akillness/oh-my-skills/to-prd)

Installs	145
repo stars	★ 40
Last updated	August 4, 2026
Repository	akillness/oh-my-skills ↗

What it does

Synthesize a structured PRD from existing conversation and codebase context and publish it to the issue tracker.

Who is it for?

Documenting requirements from existing discussion into a formal PRD before making tickets

Skip if: Breaking work into tickets (use to-issues), internal technical docs, or quick task notes

When should I use this skill?

Documenting requirements for a feature or change to publish to the issue tracker

What you get

A structured PRD published to the issue tracker with a needs-triage label

Structured PRD
Problem statement
User stories

By the numbers

5-item quality checklist
PRD template with problem, solution, user stories, out-of-scope

Files

SKILL.mdMarkdownGitHub ↗

To PRD

Convert current conversation context into a structured PRD for publication to the project issue tracker.

When to use this skill

Documenting requirements from existing discussion
Creating a formal spec before breaking work into issues
Recording architectural decisions alongside user stories

When not to use this skill

Breaking work into tickets → use to-issues
Writing technical internal docs → use technical-writing
Quick task notes → use task-planning

Process

1. Explore and understand

Review the codebase using the project's domain vocabulary (CONTEXT.md) and relevant ADRs. Do not interview the user — synthesize from existing context.

2. Design modules

Identify the major components to build or modify. Emphasize deep modules: simple, testable interfaces with stable contracts. Validate assumptions with the user and confirm which modules need test coverage.

3. Document and publish

Complete the PRD template and submit to the issue tracker with the needs-triage label.

PRD template

# [Feature/Change Name]

## Problem Statement

[User-facing description of the issue or opportunity. What pain does this solve?]

## Solution

[User-facing description of the resolution approach.]

## User Stories

1. As a [actor], I want [feature], so that [benefit].
2. As a [actor], I want [feature], so that [benefit].
[... comprehensive list covering all use cases]

## Implementation Decisions

### Modules

[Major components to build/modify with interface descriptions]

### Technical Choices

[Architecture decisions, schema design, API contracts — avoid file paths and code snippets]

### ADR References

[Links to relevant Architecture Decision Records]

## Testing Decisions

[Testing philosophy for this feature, which modules need coverage, relevant test precedents]

## Out of Scope

- [Explicitly excluded item]
- [Explicitly excluded item]

## Further Notes

[Additional context, open questions, or dependencies]

Quality checklist

[ ] Problem statement is user-facing (not technical)
[ ] User stories cover all actors and use cases
[ ] Implementation decisions reference existing domain vocabulary
[ ] Out of scope section prevents scope creep
[ ] No file paths or code in the PRD (these belong in issues)

Instructions

1. Identify the task trigger and expected output. 2. Follow the workflow steps in this skill from top to bottom. 3. Validate outputs before moving to the next step. 4. Capture blockers and fallback path if any step fails.