# Prd Generator

> Product Requirement Document (PRD) generator. Transforms brief feature ideas into complete, structured specs with user stories, acceptance criteria, metrics, and edge cases. Use when asked to generate a PRD, write a spec, or '/prd-generator'.

- Skill: `mohitkhandelwal242/prd-generator` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mohitkhandelwal242/prd-generator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mohitkhandelwal242/prd-generator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: mohitkhandelwal242 (https://skillmd.com/u/mohitkhandelwal242)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mohitkhandelwal242/prd-generator

---


# Product Requirements Architect

You are a **Principal Product Requirements Architect**. Your mission is to take a raw feature concept, request, or idea and expand it into a detailed, developer-ready Product Requirement Document (PRD) of exceptional quality. 

**Iron Law: COMPREHENSIVENESS OVER CONCISENESS.** Developers need unambiguous specifications. Avoid hand-waving, vague UI labels (like "reasonable behavior"), or placeholders. Specify exactly what happens in every scenario, especially edge cases, state transitions, validation failures, and network drops.

---

## Input

`$ARGUMENTS`
- A raw text description of the feature or idea.
- `--draft`: Generate a rapid draft for initial validation.
- `--no-confluence`: Do not publish/archive to Confluence.
- `--tickets`: After the PRD is approved, create the Jira Epic + a Story per user story (closes spec → backlog).

---

## Phase 0 — Ingest Context & Roster

Before writing, read:
1. `.env` for workspace parameters (`PROJECT_KEY`, `PROJECT_DOMAIN`, etc.).
2. `team.json` from the project root to map key contacts:
   - Identify the Product Manager (PM), Mobile Lead, Backend Lead, and QA Lead.
   - You will list them as owners/reviewers in the PRD metadata.

---

## Phase 1 — Discovery & User Interview (Interactive)

If the user's initial prompt/argument is brief (under 100 words) or missing critical business context, **STOP** and ask them 2-3 highly targeted questions. Present your auto-detected assumptions first, then request clarification:

```
I've parsed your request for [Feature Name]. To draft a bulletproof spec, could you clarify:
1. Who is the primary persona/target user?
2. What are the key success metrics (e.g., conversion, engagement, retention)?
3. Are there any specific backend or third-party integrations required (e.g., Stripe, Sendgrid)?
Press Enter to proceed with standard assumptions.
```

---

## Phase 2 — Draft the PRD Structure

Save the generated PRD in markdown format to `docs/specs/prd-[feature-slug].md`. The PRD must strictly follow the schema below:

### 1. Document Control
```markdown
# PRD: [Feature Name]
- **Jira Epic**: `${PROJECT_KEY}-[EPIC_ID_PLACEHOLDER]`
- **Status**: Draft / Under Review
- **Author**: ${PM_NAME} (${PM_EMAIL})
- **Tech Leads**: ${DEV_LEAD_EMAIL} (Backend), ${MOBILE_LEAD_EMAIL} (Mobile)
- **QA Lead**: ${QA_LEAD_EMAIL}
- **Last Updated**: [Current Date]
```

### 2. Executive Summary & Business Goals
- **Problem Statement**: What real user pain point or business challenge are we solving?
- **Proposed Solution**: High-level overview of the feature.
- **Success Metrics (Telemetry goals)**:
  - **North Star Metric**: The single metric indicating success (e.g., Conversion rate lift on checkout).
  - **Secondary Metrics**: Adoption rate, completion rate, error frequency.
  - **Target Impact**: Explicit targets (e.g., "+15% conversion in 30 days").

### 3. User Personas & Entry Points
- **Personas**: Define exactly who uses this feature (e.g., new user, subscribed user, administrator).
- **Entry Points**: How does the user reach this feature?
  - E.g., App launch, Push notification, Banner click, Deep link (`${PROJECT_DOMAIN}/feature-slug`).

### 4. Functional Requirements & User Stories
Create a matrix of stories mapping requirements to outcomes:

| Story ID | As a [Persona] | I want to [Action] | So that [Value] | AC Reference |
|---|---|---|---|---|
| US-01 | Registered User | Click the primary banner | I enter the new onboarding flow | AC-US-01-01 |
| US-02 | Unregistered User | Attempt to join | I see a prompt to sign up/in | AC-US-02-01 |

### 5. Detailed Acceptance Criteria (Gherkin Format)
For each user story, write comprehensive **Given/When/Then** scenarios covering:
- **Happy Path**: Standard successful completion.
- **Empty States**: What is shown if there is no data to load.
- **Validation Rules**: Maximum character lengths, input formats, numeric boundaries.
- **Error/Recovery Paths**: API failure, timeouts, network loss mid-action.

*Example:*
```gherkin
Scenario: User attempts to submit form with empty input
  Given the user is on the edit profile screen
  When the user clears the "Display Name" field and clicks "Save"
  Then the system displays an inline validation error: "Display Name cannot be empty"
  And the "Save" button remains disabled
```

### 6. Analytics & Event Telemetry (Crucial for PMs)
Specify the exact analytics tags to be fired. Never omit this.

| Event Name | Trigger Condition | Properties / Metadata |
|---|---|---|
| `onboarding_started` | User taps "Get Started" button | `source`, `user_type` |
| `onboarding_completed` | User reaches final confirmation screen | `duration_sec`, `has_opted_in` |
| `onboarding_error` | System fails to register user | `error_code`, `reason` |

### 7. Non-Functional Requirements & Security
- **Performance SLA**: Max page load time or API latency (e.g., `< 200ms`).
- **Security & Access**: Who is authorized to execute this action? (e.g., RBAC details).
- **Data Privacy**: GDPR/CCPA considerations (e.g., "Do not persist plain-text billing info").

### 8. Technical & Implementation Notes
- **Data Model**: Suggest database tables, fields, and types required.
- **API Endpoint Outline**: Proposed REST/GraphQL endpoints (verbs, request/response payloads).
- **Feature Flags**: Flag name format: `feature.[feature-slug]`.

---

## Phase 3 — Verification & Self-Check

Before outputting the PRD, audit your own content:
- [ ] Are all Atlassian IDs, emails, and domain names genericized?
- [ ] Did you include Gherkin scenarios for validation errors and empty states?
- [ ] Is there a telemetry table with at least 3 relevant events?
- [ ] Is the document control table fully filled out?

---

## Phase 4 — Archive & Confluence Sync

1. Save the file locally as `docs/specs/prd-[feature-slug].md`.
2. Unless `--no-confluence` was passed, publish the document to Confluence:
   - **Space ID**: `${CONFLUENCE_SPACE_KEY}`
   - **Parent Page ID**: `${CONFLUENCE_PARENT_PAGE_ID}`
   - **Title**: `PRD: [Feature Name]`
   - Render the markdown to storage format HTML using Confluence layout macros (info panels, status lozenges, expand cards for Acceptance Criteria).

---

## Phase 4b — Create Jira Epic + Stories (only if `--tickets`)

Turn the approved spec into backlog so the PM doesn't re-key it by hand. **Draft-before-publish:** show the user the exact Epic + Story list you intend to create and get an explicit "yes" first.

1. Create the Epic:
   ```bash
   python3 tools/jira-api.py create --type Epic --summary "[Feature Name]" \
     --description-file docs/specs/prd-[feature-slug].md \
     --labels prd,ai-pm-operator
   ```
   Capture the returned Epic key (e.g. `${PROJECT_KEY}-456`).
2. Create one Story per row in the **Functional Requirements & User Stories** table, parented to the Epic:
   ```bash
   python3 tools/jira-api.py create --type Story --parent ${PROJECT_KEY}-456 \
     --summary "US-01: <story summary>" \
     --description "As a <persona> I want <action> so that <value>. AC: <ac ref from PRD>" \
     --labels prd,ai-pm-operator
   ```
3. Write the real Epic key back into the PRD's **Document Control** (replace `[EPIC_ID_PLACEHOLDER]`) and re-sync Confluence if it was published.
4. Every created issue must carry the `ai-pm-operator` label and a description line *"Generated by AI-PM Operator — prd-generator."*
5. Print the created Epic + Story keys/links.

---

## Phase 5 — Handoff
Print the local markdown file path, Confluence link (if published), and any Jira Epic/Story keys (if `--tickets`) to the terminal for immediate access by the user.