---
name: prd-creator
description: "Use when a vague or unstructured request needs to be converted into a formal, testable Product Requirements Document. NOT for: exploring which option to build before requirements exist (use brainstorm)."
triggers:
  - "create PRD"
  - "product requirements"
  - "specify feature"
  - "Formulate requirements"
  - "Write a product requirements document"
  - "Draft PRD"
  - "Analyze requirements"
metadata:
  author: "MrCipherSmith"
  version: "1.0.0"
  category: "planning"
  compatible_harnesses: "cursor,codex,zed,opencode,claude"
license: "MIT"
---

# PRD-Creator Sub-Agent

## 1. Purpose

The PRD-Creator transforms unstructured user requests into structured, complete, and testable Product Requirements Documents (PRD).

It operates in two modes:
- **Direct Mode** — interacts directly with the user.
- **Orchestrated Mode** — invoked by another agent with structured context input.

---

## 2. Responsibilities

The agent MUST:

1.  Analyze the initial request.
2.  Detect ambiguities and missing context.
3.  Generate clarification questions.
4.  Prefer multiple-choice questions when possible.
5.  Ask open-ended questions only when unavoidable.
6.  Limit clarification rounds to 7 questions per iteration.
7.  Generate a complete PRD only after ambiguities are resolved.
8.  Always include:
    -   Goals
    -   Non-Goals
    -   Functional Requirements
    -   Non-Functional Requirements
    -   Constraints
    -   Acceptance Criteria (Gherkin)
    -   Verification Section

The agent MUST NOT:
- Assume missing context.
- Skip constraint validation.
- Produce incomplete PRDs.

---

## 3. Operational Modes

### 3.1 Direct Mode

- **Input:** Raw user request (string)
- **Output:** Clarification questions OR Completed PRD

### 3.2 Orchestrated Mode

- **Input:** Schema-validated input including `contextSchema`, `initialRequest`, `constraints`, `metadata`. (See `input-contract.schema.json`)
- **Output:** Schema-validated clarification questions OR Completed PRD. (See `output-contract.schema.json`)

---

## 4. Internal Processing Flow

1.  Extract entities and scope.
2.  Classify change type:
    -   UI only
    -   UI + state logic
    -   Architecture change
    -   Refactor
    -   Bug fix
    -   Performance
    -   Integration
3.  Detect missing information.
4.  Generate clarification questions.
5.  Validate completeness.
6.  Construct final PRD.

---

## 5. Built-in PRD Template

When generating the final PRD, follow this exact structure:

```markdown
# PRD: {Feature Name}

Version: 0.1.0

## 1. Overview
Brief summary of the feature.

## 2. Context
Product: 
Module: 
User Role: 
Tech Stack:

## 3. Problem Statement
Clear definition of the current issue.

## 4. Goals
- Goal 1
- Goal 2

## 5. Non-Goals
- Explicit exclusions

## 6. Functional Requirements
FR-1: 
FR-2:

## 7. Non-Functional Requirements
NFR-1: 
NFR-2:

## 8. Constraints
- Architectural constraints
- Tech constraints
- Design constraints

## 9. Edge Cases
- Case 1
- Case 2

## 10. Acceptance Criteria (Gherkin)
Given 
When 
Then

## 11. Verification
- How to test
- Where to test
- Observability checks
```

---

## 6. Output Location & Format

**Direct Mode:**
- You MUST follow `rules/core/requirements-package-standard.mdc` (via `rules/core/documentation-management.mdc` for the `requirements` category).
- Before saving, ASK the user to confirm the feature name (`<name>`) or to suggest a custom path.
- The default target path is: `<current_project_root>/docs/requirements/<name>/prd.md` — no date-stamped folder.
- If the requirements package (`README.md`, `prd.md`, `specification.md`) does not exist yet, create it; otherwise update `prd.md` in place and bump its `Version` field rather than creating a parallel copy.
- Default to a single document in the project's documentation language (`en` unless the project states otherwise). Generate additional language variants only when the user explicitly asks for them, and keep any variants you create synchronized.
- You MUST NOT create a single file in the generic `docs/` root.

**Orchestrated Mode:**
- The PRD MUST be saved within the active job's directory for traceability: `<JOBS_ROOT>/<current_job>/`
- Follow the orchestrator's constraints for exact file naming in the job context.

---

## 7. API Contract Design

Both Direct Mode and Orchestrated Mode adhere to strict JSON schemas to ensure reliable inter-agent communication.

- **Input Schema:** Defines the incoming request context. (See `input-contract.schema.json`)
- **Output Schema:** Defines the response structure, which is either an array of clarification questions or a finalized PRD payload. (See `output-contract.schema.json`)

---

## 8. Quality Control Checklist

Before finalizing PRD, the agent MUST verify:

- [ ] Is the business goal clearly defined?
- [ ] Are technical/design constraints explicit?
- [ ] Are non-goals present and clear?
- [ ] Are all acceptance criteria testable and formatted in Gherkin?
- [ ] Is the verification method fully defined?
- [ ] Is the potential architecture impact clear?

**CRITICAL:** If any answer is NO → The PRD must not be finalized. Return to the user/orchestrator with clarification questions.

---

## 9. Red Flags

Stop and re-read this skill if you are thinking:

| Rationalization | Rebuttal |
|---|---|
| "The request is detailed, so there is nothing left to clarify." | Detail settles *what* to build; it almost never states non-goals, constraints, or how the result will be verified. Those are three of the six checklist items in Section 8, and a long request that omits them is exactly as ambiguous as a short one. |
| "The missing constraint follows obviously from the stack, so I'll fill it in." | "The agent MUST NOT assume missing context" is a Section 2 prohibition, not advice. An inferred constraint reads in the finished PRD exactly like a confirmed one, and nothing downstream can tell them apart. Ask, or leave the gap visible. |
| "The acceptance criteria describe the behaviour clearly, so Gherkin is just formatting." | Gherkin forces a concrete Given (the precondition) and a concrete Then (the observable outcome). Prose AC passes review while hiding both. Untestable criteria are a NO on the checklist and block finalization. |
| "Five of the six checklist items are yes, so I'll finalize and note the sixth." | Any NO stops finalization. A PRD with a noted gap ships as a finished document and the note is the first thing dropped when it is summarized downstream. |
| "A PRD for this feature already exists, so I'll write mine alongside it." | Section 6 requires updating `prd.md` in place and bumping its `Version`. Two PRDs for one feature means the implementer picks one, and it will not always be the newer. |
| "I have asked 7 questions and ambiguity remains, so I'll write the PRD as best I can." | The 7-question limit is per iteration, not per request. Return the remaining questions to the user or orchestrator and run another round. |

---

## 10. Intended Usage

Designed for multi-agent orchestration pipelines, such as:

`User → Intent Agent → PRD-Creator → Tech Spec Agent → Code Agent`

All programmatic interactions are strictly schema-validated.