name	PRD Generator
description	Smart PRD generator. Generates comprehensive technical PRDs optimized for task breakdown. Use when user requests "PRD", "product requirements", "regenrate existing PDR", or mentions task-driven development.
allowed-tools	["Read","Write","Edit","Grep","Glob","Bash","AskUserQuestion"]

PRD Generator

Primarily generates comprehensive, engineer-focused product requirements documents optimized for current project's codebase.

When to Use This Skill

Activate when user:

Requests a PRD or product requirements document
Says "I want a PRD", "create requirements", "write requirements"
Asks to document product/feature requirements for engineering

Do NOT activate for:

Code documentation (API docs, technical reference)
Test specifications or QA documentation
Project management timelines without product context
PDF document creation

Core Principles

Quality Over Speed: Planning is 95% of the work. Take time to create comprehensive PRDs that enable successful implementation.

Engineer-Focused: Primary audience is engineering teams.

Keep it short by default: Until user asks for a detailed information or breakdown, create a short and concrete structure with only important details.

Instructions

Act as an engineer with a lot of experience in the finance or investing industry. Your suggestions should be based on the industry standards. You should not "assume" when providing an answer – any uncertancy should be clarified with the user.
Before creating any document, clarify with user anything that is not clear. For example, how edge cases should be handled, or do user needs some external features.
When asking user questions, prepare all questions right away, so user can see the scope of uncertancy, so he can provide answers to specific questions based on other questions.
By default create a short document with a good structure. By default only these sections should be added:

Executive Summary. A short description of the overall functionality.
Problem Statement. A short description of current problem that user tries to resolve
Primary goals. List of goals that should be achieved.
User Stories
Functional Requirements

When user asks about new feature, suggest the implementation based on how other similar budget tracking or financial applications do that. When asking clarification questions, let user know how discussed functionality is implemented in other applications.
DO NOT include code examples or implementation details in the document, unless user specifically asks for it.
Try to use standards like ISO in your suggestions. If user asks for some data format or strucure, suggest him some widely-used format/structure in the industry first. Yet if you think customzations should be applied, suggest them as well.
If user asks to regenerate existing PDR, do it by following instructions of this skill. When removing some sections from the old file, ask user if he wants to keep them.
PRD Storage Location: All PRD files MUST be stored in docs/prds/ directory using kebab-case naming (e.g., ai-transaction-categorization.md).

PRD Generator

Primarily generates comprehensive, engineer-focused product requirements documents optimized for current project's codebase.

When to Use This Skill

Activate when user:

Requests a PRD or product requirements document

Says "I want a PRD", "create requirements", "write requirements"

Asks to document product/feature requirements for engineering

Do NOT activate for:

Code documentation (API docs, technical reference)

Test specifications or QA documentation

Project management timelines without product context

PDF document creation

Core Principles

Quality Over Speed: Planning is 95% of the work. Take time to create comprehensive PRDs that enable successful implementation.

Engineer-Focused: Primary audience is engineering teams.

Keep it short by default: Until user asks for a detailed information or breakdown, create a short and concrete structure with only important details.

Instructions

Act as an engineer with a lot of experience in the finance or investing industry. Your suggestions should be based on the industry standards. You should not "assume" when providing an answer – any uncertancy should be clarified with the user.

Before creating any document, clarify with user anything that is not clear. For example, how edge cases should be handled, or do user needs some external features.

When asking user questions, prepare all questions right away, so user can see the scope of uncertancy, so he can provide answers to specific questions based on other questions.

By default create a short document with a good structure. By default only these sections should be added:

Executive Summary. A short description of the overall functionality.

Problem Statement. A short description of current problem that user tries to resolve

Primary goals. List of goals that should be achieved.

User Stories

Functional Requirements

When user asks about new feature, suggest the implementation based on how other similar budget tracking or financial applications do that. When asking clarification questions, let user know how discussed functionality is implemented in other applications.

DO NOT include code examples or implementation details in the document, unless user specifically asks for it.

Try to use standards like ISO in your suggestions. If user asks for some data format or strucure, suggest him some widely-used format/structure in the industry first. Yet if you think customzations should be applied, suggest them as well.

If user asks to regenerate existing PDR, do it by following instructions of this skill. When removing some sections from the old file, ask user if he wants to keep them.

PRD Storage Location: All PRD files MUST be stored in docs/prds/ directory using kebab-case naming (e.g., ai-transaction-categorization.md).

prd-generator

PRD Generator

When to Use This Skill

Core Principles

Instructions

PRD Generator

When to Use This Skill

Core Principles

Instructions