agentleFS
Sign inStart free
hamzafarooqhamzafarooq/claude-code-starter/.claude/skills/prd-generator/SKILL.md

prd-generator

Skill145 starsChanged 6 months agoMITView on GitHub

Generates a structured PRD from a feature description or brief. Use when asked to write, draft, or create a PRD.

We split this skill into the rules it gives an agent

5 rules. 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 24 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When triggered, ask the user for:

    line 8
  2. Distinctive:

    Should be specific enough that a QA engineer can write a test.

    line 41
  3. Distinctive:

    Write the full PRD directly — do not explain what you're about to write

    line 60
  4. Distinctive:

    Use plain English — avoid technical jargon

    line 61
  5. Very specific:

    Ask the user if they want to save it to docs/prd.md

    line 65

“Common” is measured: kept by at least 6 in 10 of the 24 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

What this skill does

When triggered, ask the user for:

  1. Feature name (one line)
  2. Problem being solved (1-3 sentences)
  3. Target user(s)
  4. Any known constraints or context (timeline, technical limits, compliance, etc.)

Then generate a full PRD using the structure below.

PRD Structure

1. Problem Statement

What pain are we solving and for whom? Why does this matter now?

2. Goals

3-5 measurable outcomes we want to achieve with this feature. Format: "Increase [metric] by [amount] within [timeframe]"

3. Non-Goals

What this feature explicitly will NOT do. Be specific. This section prevents scope creep.

4. Users & Use Cases

Who uses this feature and in what context? Include 2-3 concrete scenarios (short narrative, not bullets).

5. User Stories

Written as: "As a [user type], I want to [action] so that [outcome]." Group into: Must-have / Should-have / Nice-to-have

6. Acceptance Criteria

Written in Given/When/Then format for each must-have story. Should be specific enough that a QA engineer can write a test.

7. Risks & Assumptions

Two columns:

  • Risks — What could go wrong? What dependencies exist?
  • Assumptions — What are we treating as true that we haven't confirmed?

8. Open Questions

What must be decided before engineering starts? Format as questions, not statements. Assign an owner if known.

9. Success Metrics

How will we measure whether this feature succeeded? Include leading indicators (early signals) and lagging indicators (final outcomes).

How to respond

  • Write the full PRD directly — do not explain what you're about to write
  • Use plain English — avoid technical jargon
  • Mark any section where you made an assumption with [ASSUMPTION]
  • Mark anything that needs the PM's input with [NEEDS INPUT]
  • End with: "Review the [ASSUMPTION] and [NEEDS INPUT] sections before sharing with engineering."
  • Ask the user if they want to save it to docs/prd.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free