# Create Prd

> Use when creating a Product Requirements Document from a conversation or feature request through structured context gathering

- **Type:** Skill
- **Install:** `agentstack add skill-giladresisi-ai-dev-env-create-prd`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [giladresisi](https://agentstack.voostack.com/s/giladresisi)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [giladresisi](https://github.com/giladresisi)
- **Source:** https://github.com/giladresisi/ai-dev-env/tree/main/skills/create-prd

## Install

```sh
agentstack add skill-giladresisi-ai-dev-env-create-prd
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Create PRD: Generate Product Requirements Document

## Overview

Generate a comprehensive Product Requirements Document (PRD) through strict context gathering, API research, and structured documentation. This command produces a production-ready PRD serving as the single source of truth for implementation.

**Output File**: `$ARGUMENTS` (default: `PRD.md` in project root)

---

## ⚠️ CRITICAL INSTRUCTIONS

**DO NOT CREATE THE PRD UNTIL YOU HAVE COMPLETE CONTEXT**

**Workflow**:
1. **Discover** project type and scope through targeted questions
2. **Research** external APIs/SDKs if applicable (mandatory, not optional)
3. **Gather** all required information - ask questions until complete
4. **Confirm** with user before writing
5. **Write** PRD using appropriate template
6. **Backup** existing file if one exists

**Principles**:
- ❌ **No assumptions** - ask instead of guessing
- ❌ **No placeholder sections** - complete or explicitly skipped by user
- ✅ **Complete context first** - gather all info before writing
- ✅ **Research external dependencies** - understand APIs before documenting

---

## STEP 1: PROJECT TYPE & CONTEXT DISCOVERY

**Required Questions** - Ask the user:

1. **Project Type**: AI Agent / Web App / API/Service / Library/Package / CLI Tool / Desktop App / Mobile App / Other
2. **Core Functionality**: In 2-3 sentences, what does this product do?
3. **Target Users**: Who will use this? Technical level?
4. **MVP Scope**: What must be in first version vs. later?
5. **Technology Preferences**: Required/preferred technologies?
6. **External Dependencies**: External APIs, services, or SDKs?
7. **Deployment Context**: How deployed/distributed?
8. **Existing Documentation**: Related docs or research?

**Do not proceed without**:
- ✓ What you're building (type + core function)
- ✓ Who it's for (target users)
- ✓ What's in scope for MVP
- ✓ What external dependencies exist

---

## STEP 2: API RESEARCH (IF APPLICABLE)

**Mandatory if external APIs or unfamiliar SDKs involved.**

### Identify & Determine Research Needs

List all external APIs/SDKs, then **ask user for each**:
```
This project integrates with [API name].

Options:
1. Do you have existing research documents? (provide paths)
2. Should I research [API name] before creating PRD?
3. Skip research and document based on current knowledge (not recommended for unfamiliar APIs)

Your preference?
```

### Conduct Research

For each API requiring research:
1. **Execute**: `/explore-api [API name]`
2. **Read**: `.agents/research/[api]-research.md`
3. **Verify**: POC tests passed

### Critical Verification Requirements

**For EVERY external API/service, research MUST verify:**

1. **Feasibility**: Is what we want to achieve **technically possible** with this API?
   - Does the API provide the required features/endpoints?
   - Are there version/compatibility constraints?
   - Are there known limitations that block our use case?

2. **Allowability**: Is what we want to achieve **permitted** by the service?
   - Rate limits sufficient for our needs?
   - API tier/plan supports required features?
   - Terms of Service allow our intended use?
   - Geographic/regulatory restrictions?

3. **Setup Requirements**: What external setup is needed?
   - Account creation/API key generation steps
   - Dashboard/console configuration
   - Webhooks or callback URL setup
   - OAuth app registration
   - Service-specific prerequisites

**Do not proceed without**:
- ✓ User confirmation on research approach
- ✓ Completed API research (if chosen)
- ✓ Research documents read (if provided)
- ✓ **Feasibility verified** (we CAN do what we want)
- ✓ **Allowability verified** (we're ALLOWED to do what we want)
- ✓ **Setup requirements documented** (we know HOW to configure it)

---

## STEP 3: GATHER COMPLETE REQUIREMENTS

### Information Gathering Strategy

For each template section:
1. Check conversation history for details
2. Ask specific questions for missing info
3. Confirm understanding before next section
4. Mark sections to skip (with explicit confirmation)

### Required Information Checklist

**Business Context**:
- [ ] Product mission and value proposition
- [ ] Target user personas and needs
- [ ] MVP success criteria

**Technical Context**:
- [ ] Technology stack with versions
- [ ] Architecture approach and patterns
- [ ] External API integrations (with research if applicable)
- [ ] Security and configuration

**Scope Definition**:
- [ ] In-scope features for MVP
- [ ] Explicit out-of-scope items
- [ ] User stories with examples
- [ ] Implementation phases with parallelization strategy

**Parallel Execution Design**:
- [ ] Workstream boundaries identified
- [ ] Interface contracts between teams defined
- [ ] Shared context and dependencies mapped
- [ ] Integration checkpoints planned
- [ ] Mock/stub strategies for blocked work

**Risk Management**:
- [ ] 3-5 key risks identified
- [ ] Mitigation strategy per risk
- [ ] API integration risks (if applicable)

### Example Questions (Adapt to Project Type)

**AI Agents**: Tools/capabilities? Registration pattern? Conversation flow? Result presentation?
**Web Apps**: User workflows? Frontend framework? API design? Auth requirements?
**APIs/Services**: Endpoints? Request/response formats? Rate limiting? Versioning?
**Libraries**: Public API surface? Installation? Usage examples? Dependencies?
**Universal**: Error handling? Logging? Tests (unit/integration/e2e)? Documentation?

**Parallel Execution Planning**:
- Can frontend and backend be built concurrently?
- What shared interfaces/contracts need to be defined first?
- Which components have no dependencies and can start immediately?
- What mock/stub strategies enable parallel development?
- Where are the integration points that require synchronization?

---

## STEP 4: FILE HANDLING & PRD CREATION

### Backup Existing PRD

If PRD exists:
```bash
mv PRD.md PRD.backup-$(date +%Y%m%d-%H%M%S).md
```

### Confirm Before Writing

```
Ready to create PRD:
- Project Type: [type]
- Target File: [path]
- API Research: [completed/skipped/N/A]
- Sections: [number]
- Skipped: [list or "none"]

Proceed? (y/n)
```

---

## PRD TEMPLATE STRUCTURE

Follow this hierarchical structure. Adapt sections based on project type.

### Section Format

Each section below shows:
- **Req**: Required/Optional
- **Format**: Markdown syntax
- **Examples**: For different project types (AI Agent, Web App, API, Library)

---

### `# Product Requirements Document: [Product Name]`

**Req**: Yes | **Format**: H1 with "Product Requirements Document: " prefix

---

### `## Executive Summary`

**Req**: Yes | **Format**: H2, 2-3 paragraphs

**`[Product Name]` - [One-liner]**
- AI Agent: `**Paddy** is an AI agent enabling Obsidian users to interact with vaults using natural language.`
- Web App: `**TaskFlow** is a collaborative PM app helping remote teams coordinate through task boards and async video.`
- API: `**PaymentHub** is a unified payment API abstracting multiple providers behind one interface.`

**`MVP Goal:` [One sentence]**
- AI Agent: Enable vault query/management through natural language with user's choice of LLM.
- Web App: Allow teams to create task boards and share video updates without real-time presence.

---

### `## Mission`

**Req**: Yes | **Format**: H2, 1-2 sentences

**`### Core Principles`** - Numbered list with bold names

```markdown
1. **[Principle]** - [Explanation]
2. **[Principle]** - [Explanation]
3. **[Principle]** - [Explanation]
```

---

### `## Target Users`

**Req**: Yes | **Format**: H2 with subsections

**`[User Group]` who want to:**
- Bullet list of goals

**`Technical Comfort Level:`** [Description]

---

### `## MVP Scope`

**Req**: Yes | **Format**: H2 with H3 subsections

**`### In Scope`** - Categorized bullets:
- **Core Functionality**: User-facing features
- **Technical**: Implementation details
- **Integration**: Third-party tools (if applicable)
- **Deployment**: Packaging/distribution

**`### Out of Scope (Future Considerations)`** - Bullet list

---

### `## User Stories`

**Req**: Yes | **Format**: H2 with H3 subsections

**`### Primary User Stories`** - Numbered list:

```markdown
1. **As a [role], I want to [action]**, so that [benefit].
   - Example: "[concrete example]"
```

**`### Technical User Stories`** - Same format (optional)

---

### `## Core Architecture & Patterns`

**Req**: Yes | **Format**: H2 with H3 subsections

**`### Architecture`**
- Architecture style/pattern name
- High-level description
- Directory structure (code block)

**`### Key Patterns`** - Numbered, bold-labeled:

```markdown
**1. [Pattern]**
- [Description]
- [Code example if helpful]
```

---

### `## Tools` (AI Agents) OR `## Features` (Others)

**Req**: Yes | **Format**: H2 with H3 per tool/feature

**For AI Agents**:
```markdown
### Tool N: `tool_name`

**Purpose:** [What it does]
**Operations:**
- [Operation 1]
- [Operation 2]

**Key Features:**
- [Notable feature 1]
```

**For Other Products**:
```markdown
### Feature N: [Name]

**Description:** [What users get]
**Components:**
- [Component 1]

**User Experience:**
- [Interaction pattern]
```

---

### `## Technology Stack`

**Req**: Yes | **Format**: H2 with H3 per category

```markdown
### [Category]

- **[Tool]** (version) - [Purpose]
```

Categories: Backend / Frontend / Database / Infrastructure / Testing

---

### `## Parallel Execution Architecture`

**Req**: Yes | **Format**: H2 with H3 subsections

**Purpose**: Enable independent team/agent workstreams to execute concurrently

```markdown
## Parallel Execution Architecture

### Team Structure

**Workstream Teams:**
- **Team A - [Name]**: [Responsibility scope]
  - Focus: [What they build]
  - Expertise: [Required skills]
  - Works with: [Other teams they depend on]

- **Team B - [Name]**: [Responsibility scope]
  - Focus: [What they build]
  - Expertise: [Required skills]
  - Works with: [Other teams]

### Interface Contracts

**CRITICAL**: These contracts enable parallel development

#### Contract 1: [Name] (Team A → Team B)

**Provider:** Team A
**Consumer:** Team B

**Interface Definition:**
```[language]
# API endpoint, data schema, or contract definition
```

**Delivery Timeline:** [When available for consumption]
**Mock Strategy:** [How Team B can work before Team A completes]

#### Contract 2: [Name]

[Repeat structure for each interface]

### Shared Context

**What ALL teams must know:**
- [Global architectural decision 1]
- [Global constraint 1]
- [Naming convention 1]

**Central Configuration:**
```[language]
# Shared config that all teams use
```

### Synchronization Points

**Integration Checkpoint 1:** [When]
- **Participants:** Teams A, B, C
- **Purpose:** [What gets validated]
- **Success Criteria:** [How to verify integration works]

**Integration Checkpoint 2:** [When]
- [Repeat structure]

### Dependency Graph

```
Phase 1 (Parallel)
├── Workstream A: [Independent]
├── Workstream B: [Independent]
└── Workstream C: [Independent]
    ↓
Phase 2 (After Phase 1 completes)
├── Workstream D: [Depends on A, B]
└── Workstream E: [Depends on C]
    ↓
Phase 3 (Final Integration)
└── Workstream F: [Depends on D, E]
```

### Risk Mitigation for Parallel Work

**Risk:** [Parallel workstreams diverge or create conflicts]
**Mitigation:**
- [Strategy 1 - e.g., daily integration tests]
- [Strategy 2 - e.g., shared type definitions]

**Risk:** [Blocked waiting for dependencies]
**Mitigation:**
- [Strategy - e.g., mock implementations, contract-first development]
```

---

### `## Security & Configuration`

**Req**: Yes | **Format**: H2 with H3/H4 subsections

**`### Authentication`** (if applicable)
```markdown
#### **[Method]:** [Details]
[Explanation paragraph or bullets]
```

**`### Deployment Method & Data Access`** (if applicable)
```markdown
#### **[Mechanism]:**
[Description]

#### **How It Works:**
1. [Step 1]
2. [Step 2]

#### **Security Benefits:**
- [Benefit 1]
```

**`### Configuration Management`**
```markdown
#### **Environment Variables (`.env`):**
```[language]
# Variables
```

#### **[Orchestration] Configuration:**
```[language]
# Config file
```

#### **Configuration Class:**
```[language]
# Settings code
```
```

**`### Security Scope`**
```markdown
#### **In Scope:**
- [Measure 1]

#### **Out of Scope (Keep Simple):**
- [Excluded 1]
```

---

### `## API Specification`

**Req**: If applicable | **Format**: H2 with H3 sections

**`### External API Integrations`** (if applicable) - H4 per API:

```markdown
#### API: [Name] v[Version]

**Documentation:** [URL]
**Research Document:** `.agents/research/[api]-research.md` (if applicable)
**Purpose:** [Why used]
**Authentication:** [Method]

**Supported Features:**
- [Feature X]: ✓ Supported via [method]
- [Feature Y]: ✗ Not supported - Alternative: [approach]

**Integration Pattern:**
```[language]
# Init, usage, error handling examples
```

**Compatibility Notes:**
- [Requirement/limitation]

**Validation Strategy:**
- POC: [Description]
- Expected: [Success criteria]
- Fallback: [Alternative]
```

**`### Internal Endpoints`** (if applicable) - H4 per endpoint:

```markdown
#### Endpoint: `[METHOD] [PATH]`

**Purpose:** [What it does]

**Request:**
```[language]
[Example]
```

**Response:**
```[language]
[Example]
```

**Authentication:** [How]
**Error Responses:**
- `[Code]`: [Condition]
```

---

### `## Success Criteria`

**Req**: Yes | **Format**: H2 with H3

**`### MVP Success Definition`** - Three bold-labeled lists:

```markdown
**Functional Requirements:**
- [Must work 1]

**Quality Indicators:**
- [Quality bar 1]

**User Experience:**
- [UX goal 1]
```

---

### `## Implementation Phases`

**Req**: Yes | **Format**: H2 with H3 per phase

**CRITICAL FOR PARALLEL EXECUTION**: Each phase must include:
- **Parallelization Strategy**: Which workstreams can run concurrently
- **Team Assignments**: Suggested agent roles for each workstream
- **Dependencies**: What must complete before this phase starts
- **Integration Points**: Where parallel work synchronizes
- **Handoff Artifacts**: What each workstream delivers to others

```markdown
### Phase 1: [Name] ([Period])

**CRITICAL FOR EXTERNAL DEPENDENCIES:**
If project uses external APIs/services, Phase 1 MUST include:
- **External Service Setup**: Complete all account creation, API key generation, dashboard configuration
- **External Service Verification**: Test that ALL external services work as expected with our requirements
- **Fallback Planning**: Document what to do if external service setup/verification fails

**Goal:** [One sentence]

**Parallelization Strategy:**
- **Concurrent Workstreams**: [Number] independent workstreams
- **Can Start After**: External service verification passes (if applicable), or "Day 1" (if no external dependencies)

**Workstreams:**

#### Workstream A: External Service Setup & Verification (If Applicable)
**Assigned To:** integration-specialist
**Dependencies:** None - must happen FIRST
**Deliverables:**
- All external API accounts created and configured
- API keys/credentials securely stored
- Dashboard/console settings configured
- Connectivity tests passing
- Feature compatibility verified

**Setup Tasks:**
- Create accounts on [Service A], [Service B]
- Generate API keys and store in secure config
- Configure webhooks/callbacks if needed
- Set up OAuth apps if needed
- Test basic API connectivity

**Verification Tests:**
```bash
# Test each external service
# Verify required features are accessible
# Confirm rate limits and quotas are sufficient
```

**Critical Checkpoints:**
- [ ] All external services accessible with credentials
- [ ] Required API features verified as available
- [ ] No blocking compatibility issues discovered
- [ ] Setup documented for team reference

**If Verification Fails:**
- Document the blocker (missing feature, access denied, etc.)
- Evaluate alternatives (different API tier, alternative service)
- Update implementation plan OR escalate for requirement changes
- DO NOT P

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [giladresisi](https://github.com/giladresisi)
- **Source:** [giladresisi/ai-dev-env](https://github.com/giladresisi/ai-dev-env)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-giladresisi-ai-dev-env-create-prd
- Seller: https://agentstack.voostack.com/s/giladresisi
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.