prd

Generate a Product Requirements Document with EARS requirements and acceptance criteria.

1|Updated Feb 20, 2026
One-click install
npx skills add https://github.com/jamesaphoenix/tx-agent-kit --skill prd-jamesaphoenix
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: prd
Source: https://github.com/jamesaphoenix/tx-agent-kit/tree/main/.claude/skills/prd
Command: npx skills add https://github.com/jamesaphoenix/tx-agent-kit --skill prd-jamesaphoenix

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

PRD generation is often manual, error-prone, and hard to trace. This skill automates creating a formal Product Requirements Document using the tx doc primitive, aligning WHAT and WHY with a structured EARS-based format, and referencing a living plan stored locally.

Core Features & Use Cases

  • Scaffold a PRD draft from a feature name with a linked companion design doc.
  • Convert plan items into EARS requirements, acceptance criteria, and non-functional requirements for full traceability.
  • Output destinations: specs/prd/<name>.md, with plan references to ~/.claude/plans/<name>.md.

Quick Start

Run the PRD generation command with your feature name to create specs/prd/<name>.md.

Frequently Asked Questions about prd

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is the EARS format for product requirements?

EARS is a structured syntax for writing unambiguous product requirements. This skill converts plan items into explicit EARS requirements with acceptance criteria and non-functional requirements for full traceability.

How do I link a design doc to a product requirements document?

This skill scaffolds a PRD draft capturing WHAT and WHY while automatically linking a companion design doc for HOW, ensuring product requirements and technical design remain connected.

Do I need a living plan file to create traceable requirements?

The skill references a living plan file at ~/.claude/plans/<name>.md, converting existing plan items into explicit EARS requirements and acceptance criteria for full project traceability.

What's the best way to structure non-functional requirements in a PRD?

Using an EARS-based format with acceptance criteria is the best way to structure non-functional requirements. This skill automatically generates these sections alongside functional requirements for complete specification coverage.

Can I use the tx doc primitive for product specs and plan tracking?

Yes, this skill uses the tx doc primitive to generate product specs and references a living plan file at ~/.claude/plans/<name>.md, outputting the complete PRD to specs/prd/<name>.md.