/pm-prd

name: pm-prd
description: Генерирует структурированный PRD (Product Requirements Document) с шаблонами под тип продукта (B2C / B2B / внутренний инструмент / платформа) — фон, цели, детальный дизайн фич, acceptance criteria в Given-When-Then, аналитика и 10-пунктовый чеклист качества. User-invoked only — do NOT auto-trigger. Triggers on /pm-prd, "сделай PRD", "напиши PRD", "продуктовые требования", "make a PRD", "write a PRD", "draft requirements doc".

pm-prd — Generate a structured PRD

Part of the Personal Corp framework — running a one-person business through AI agents. Generate a delivery-ready Product Requirements Document from a feature description. Branches by product type — B2C, B2B, internal tool, platform — with each type emphasizing different modules. Includes a 10-item quality self-check that runs after generation.

Inputs

| Field | Required | Notes | |---|---|---| | Feature description | yes | What the feature does and what problem it solves; one sentence minimum | | Target user | no | Who it's for; inferred from the feature if not given | | Business goals | no | Expected business metrics (DAU, conversion, revenue, etc.) | | Product type | no | B2C / B2B / internal / platform; auto-detected if not given | | Constraints | no | Tech limits, deadlines, resource limits | | Depth | no | Outline (for review) / detailed (for development); default detailed |

If the user only says "write a PRD" with no feature, ask for the feature description. If they give feature + user + goals, go straight to generation.

Step 1 — Parse input and branch by product type

| Product type | PRD emphasis | Key differentiators | |---|---|---| | **B2C** | UX flow, growth metrics, A/B test plan | Heavy on interaction, heavy on data, write user journeys | | **B2B** | Permission model, multi-tenancy, SLA, integration APIs | Heavy on completeness, security, API contracts | | **Internal tool** | Operational efficiency, integration with existing systems, training cost | Heavy on practicality, light on visuals | | **Platform** | Multi-role interaction, supply-demand matching, ecosystem rules | Heavy on role separation, rules engine |

**Auto-detection rules:** mentions of "user / member / loyalty / marketplace" → B2C; "enterprise / SaaS / CRM / admin panel" → B2B; "internal / management system / ticketing" → internal tool; "platform / marketplace / two-sided" → platform.

**B2B PRDs must additionally cover:**

• Permission matrix (role × feature × data scope)
• Multi-tenant data isolation approach
• Integration interfaces with the customer's existing systems

**Platform PRDs must additionally cover:**

• Independent feature view per role (supplier / consumer / platform ops)
• Matching rules and ranking strategy
• Commission / take-rate / settlement rules

Step 2 — Structured requirement breakdown

**Three-method feature decomposition:**

1. **User journey:** trace the user's path from entry to goal completion; each node = one feature point 2. **Role split:** list every role involved (end user, admin, ops); each role's actions = one feature module 3. **CRUD:** for each core data object, walk through create / read / update / delete

For every feature module, fill:

• Feature description (one sentence)
• User story (As a {role}, I want to {action}, so that {value})
• Business rules (exhaustive — no "etc." or "other cases")
• Interaction (entry point → steps → success/failure feedback)
• Exception handling (timeouts, data anomalies, permission denied, edge cases)

Step 3 — Generate the PRD

Use this template. Comments next to each placeholder describe the fill logic.

# PRD: {feature name}

**Version:** v1.0
**Author:** {PM name, or [TBD]}
**Date:** {today}
**Status:** Draft

---

## 1. Background and Goals

### 1.1 Background
<!-- Answer three questions: why now? what happens if we don't? what changes if we do? -->
{problem state + user pain + why this is the right moment}

### 1.2 Target users
<!-- Use [role] + [trait] + [scenario]. Never write "all users". -->
| User role | Trait | Core need | Use scenario |
|---|---|---|---|

### 1.3 Business goals and success metrics
<!-- Each goal must be SMART — specific number + deadline. -->
| Goal | Metric | Target | Tracking method |
|---|---|---|---|

## 2. Requirement Overview
<!-- One paragraph, 30 words max, summarizing the core requirement. -->

## 3. Detailed Feature Design

### 3.1 {Module 1}
**Description:** {what it does}
**User story:** As a {role}, I want {action}, so that {value}
**Priority:** P0 (must launch) / P1 (strongly recommended) / P2 (nice-to-have)

**Business rules:**
1. {rule 1 — clear trigger condition + processing logic}
2. {rule 2}

**Interaction flow:**
<!-- Start at entry point, end at task completion, cover happy path + exception branches. -->
1. User enters from {entry}
2. {steps}
3. Success: {feedback}
4. Failure: {error message and handling}

**Exception handling:**
| Scenario | Handling | User-facing message |
|---|---|---|

(repeat format for each module)

## 4. Non-Functional Requirements
<!-- B2C → emphasize performance and experience; B2B → emphasize security and availability. -->
| Category | Requirement | Acceptance criterion |
|---|---|---|
| Performance | {e.g. page load time} | {e.g. < 2s} |
| Security | {e.g. data encryption} | {e.g. TLS 1.2+ in transit} |
| Compatibility | {browsers / devices} | {Chrome, Safari, mobile webview} |

## 5. Data Requirements (Analytics Events)
<!-- List every event to capture. Format: event name + trigger + attributes + purpose. -->
| Event | Trigger | Key attributes | Purpose |
|---|---|---|---|

## 6. Acceptance Criteria
<!-- At least 3 ACs per feature module, in Given-When-Then format. -->
| ID | Scenario | Given | When | Then |
|---|---|---|---|---|

## 7. Schedule
<!-- Break into design / dev / integration / launch. -->
| Phase | Estimate | Dependency | Risk |
|---|---|---|---|

## 8. Risks and Dependencies
| Risk | Probability | Impact | Mitigation |
|---|---