Analysis to PRD

Overview

Generate a concrete, implementation-ready PRD from project analysis documents. The PRD is feature-centric: each feature gets its own complete section with screen-by-screen flows, edge states, data models, and testable DONE criteria.

Announce at start: "I'm using the analysis-to-prd skill to generate a PRD from your project documents."

Phase 1: Discover and Read All Source Documents

Search the working directory for ALL relevant documents:

Glob: **/*.md, **/*.yaml, **/*.yml, **/*.json, **/*.pdf, **/*.txt, **/*.docx

Priority documents (read these first):

• Requirements analysis (analiza_wymagan*, requirements*, analiza*)
• API specs (openapi*, swagger*, api*)
• Any other project docs (design docs, notes, constraints)

Skip: This skill file itself, any existing PRD files, files named MakindPRD* (skill reference, not project input), node_modules, .git

Read every relevant document. For PDFs, read all pages. Understand:

• Who are the stakeholders and their roles?
• What is the current process (as-is)?
• What are the user goals?
• What is in scope / out of scope?
• What constraints exist?
• What external systems are involved (and what is SSoT)?

Phase 2: Identify Features

From the source documents, extract a list of distinct features. A feature is a coherent unit of functionality with a clear user goal.

Do NOT invent features. Only include what the source documents explicitly describe or directly imply. If something is not mentioned (notifications, analytics, SLA tracking), it is out of scope - do not add it.

Do NOT add system architecture sections. No component diagrams, no deployment topology, no tech stack decisions. Only what is required for correct and consistent implementation.

Present the feature list to the user before writing the full PRD. Ask: "I identified these features from your documents: [list]. Should I proceed, or would you like to adjust?" This prevents wasted effort on the wrong feature breakdown.

Phase 3: Write the PRD

Write PRD.md in the working directory using the structure below.

PRD Document Structure

# PRD: [System Name]

## Document Info
- Version: 1.0
- Date: YYYY-MM-DD
- Status: Draft
- Source documents: [list all files read]

---

Then for EACH feature, write a complete section:

Per-Feature Section Template

## Feature: [Feature Name]

### Feature Goal
[One sentence: for WHOM and WHAT PROBLEM it solves.]

### Entry Point
[Where the user comes from to start this flow.]

### Exit Condition
[When this feature/flow is considered completed.]

### User Flow (Happy Path)

[Screen 1: Name]
- Goal: what the user wants to accomplish on this screen
- Visible elements: list of UI elements (buttons, fields, lists, labels)
- Action: what the user does
- Transition: what happens after the action, where the user goes next

[Screen 2: Name]
- Goal: ...
- Visible elements: ...
- Action: ...
- Transition: ...

(continue for all screens in the flow)

### ASCII Flow Diagram

[Block diagram or simple wireframe showing the flow]

### Edge States
- **Empty state:** what the user sees when there is no data
- **Error state:** what happens when something fails (API down, network error)
- **Validation rules:** what blocks progress (required fields, format constraints)
- **Permission restrictions:** what is restricted and for whom

### Data Used

| Object | Field | Type | Required | Mutable after creation | Deletable | Origin (SSoT) / Target |
|--------|-------|------|----------|----------------------|-----------|------------------------|
| ... | ... | ... | yes/no | yes/no | yes/no | e.g. "logistics system" or "local DB" |

### Assumptions
[Bullet list of things not explicitly stated in source docs but inferred for this feature.]

### Out of Scope
[What this feature explicitly does NOT cover.]

### API Endpoints
[Only if required for the system. Short description of each endpoint needed.]

| Method | Endpoint | Description |
|--------|----------|-------------|
| ... | ... | ... |

### DONE Criteria
[Max 3 points. Observable and testable. Clear system behavior, not vague statements.]

1. [Concrete, testable criterion]
2. [Concrete, testable criterion]
3. [Concrete, testable criterion]

### Flow Summary
[2-3 sentences: Does this flow make logical sense? Where might the user get stuck? What assumptions were made?]

After all features, add:

## Non-Functional Requirements
[Only requirements that DIRECTLY result from the source documents. Do not invent performance targets or SLAs unless the source docs mention them.]

- NFR-1: ...
- NFR-2: ...

## Open Questions
[Things not answered by source documents that should be resolved before or during implementation. Only list questions that genuinely affect the features described above.]

1. ...
2. ...

Critical Rules

These rules prevent the most common PRD generation failures:

Do NOT invent requirements

If the source documents do not mention notifications, analytics, SLA targets, audit logs, file attachments, or any other feature - do NOT add them. List them in a final "Open Questions" section if you think they matter, but do NOT include them as requirements.

Do NOT add system architecture

No component diagrams. No "Backend / API / Database" sections. No tech stack. The PRD describes WHAT the system does, not HOW it is built.

Do NOT use abstract descriptions

Every flow must be screen-by-screen with concrete UI elements. "The user submits a form" is too abstract. "The user fills in the Description field (textarea, required, max 2000 chars) and clicks Submit" is concrete.

Do NOT skip edge states

Every feature MUST have empty state, error state, and validation rules defined. These are where implementations diverge from intent.

Data model must be complete

Every field must specify: type, required/optional, mutable after creation (yes/no), deletable (yes/no), and origin (SSoT source or local). This prevents implementation guesswork.

DONE criteria must be testable

"System works well" is not a DONE criterion. "A customer who submits a complaint sees it appear in their complaint list with status NEW within 5 seconds" is testable.

Keep the language of the source documents

If source documents are in Polish, write the PRD in the same language. If they mix languages, default to the language used in the requirements analysis document. Only translate if the user explicitly asks.

Common Mistakes