Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Feature requirements document builder

Transforms raw feature ideas, customer feedback, or stakeholder requests into a complete feature requirements document with problem framing, user stories, acceptance criteria, scope boundaries, edge cases, dependencies…

download .md

Purpose

Turn a raw feature idea or a pile of customer feedback into a review-ready requirements document — with a clear problem statement, user stories, testable acceptance criteria, explicit scope boundaries, and flagged open questions — so engineering and design can estimate and start work without a discovery meeting to fill in gaps.

When to Use

Invoke this skill when the user asks to:

  • Write a PRD, feature spec, or requirements document for a new feature
  • Turn customer feedback or support tickets into a buildable feature request
  • Prepare a feature for engineering estimation or design review
  • Define user stories and acceptance criteria for a feature
  • Scope a feature and clarify what's in and out of the first version
  • Convert a loose idea from a stakeholder or executive into a structured spec

Inputs Required

Before starting, collect:

  • Feature idea or feedback: The raw input — an idea, a customer quote, a support theme, or an exec request
  • Target users: Who will use this feature (role, segment, or persona)
  • Problem/motivation: What problem this solves, or the trigger that raised it
  • Current workaround: How users solve this today (or why they can't)
  • Success metric: How the team will know the feature worked (activation, retention, ticket reduction, etc.)
  • Known constraints: Technical, timeline, compliance, or platform limits already known
  • Scope ambition: MVP / full v1 / phased rollout

If success metric or scope ambition is missing, default to an MVP-scoped document and flag the missing metric as an open question rather than inventing one.

Instructions

Step 1: Problem Framing

Reframe the raw input into a crisp problem statement before writing any solution.

  • Write a one-sentence problem statement in the form: "[User] can't [goal] because [obstacle], which causes [consequence]."
  • Separate the problem from the proposed solution — if the input is phrased as a solution ("add a bulk export button"), infer the underlying problem and state it explicitly.
  • Note the evidence: what signal supports this being worth building (feedback volume, revenue at risk, strategic fit).
  • If the problem statement can't be written cleanly, that itself is the top open question — flag it.

Step 2: Goals and Non-Goals

Bound the work before detailing it.

  • Goals: 2–4 outcomes this feature must achieve, each tied to the problem.
  • Non-Goals: 2–4 things this feature explicitly will not do in this version — the single most effective tool for preventing scope creep during engineering review.
  • Each goal should be outcome-phrased ("Users can recover a deleted record within 30 days"), not task-phrased ("Build a recovery API").

Step 3: User Stories

Write the feature as a set of user stories covering the primary flow and key variations.

  • Format: "As a [user type], I want to [action] so that [benefit]."
  • Cover the primary flow (happy path) plus 2–4 secondary flows (permissions, empty states, error recovery, different user roles).
  • Order stories by priority: P0 (must ship), P1 (should ship), P2 (nice to have).
  • Aim for 4–8 stories total for an MVP; more for a full v1.

Step 4: Acceptance Criteria

Translate each P0 and P1 story into testable criteria engineering and QA can verify.

  • Use Given / When / Then format for each criterion.
  • Every criterion must be binary — a reviewer can mark it pass or fail with no judgment call.
  • Include criteria for validation, error handling, and permissions where relevant — not just the success case.
  • Attach criteria directly under each story so the mapping is unambiguous.

Step 5: Edge Cases and Error States

List the situations that break naive implementations.

  • Cover: empty/zero states, maximum limits, concurrent actions, permission boundaries, network failures, and partial-data scenarios.
  • For each edge case, state the expected behavior — not just the risk.
  • Flag any edge case where the correct behavior is genuinely undecided as an open question in Step 7.

Step 6: Dependencies and Design Notes

Surface what else must exist or change for this to ship.

  • Technical dependencies: APIs, data models, third-party services, or platform changes required.
  • Cross-team dependencies: Anything that needs design, data, legal, or another squad.
  • Design considerations: Key UI states, accessibility notes, or reference to existing patterns — not full mockups, but enough to orient a designer.
  • Data/analytics: Events to instrument to measure the success metric from intake.

Step 7: Open Questions and Risks

End with what's unresolved so review is productive.

  • List open questions as decisions someone must make, each with a suggested owner (PM / Eng / Design / Data).
  • List risks with a one-line mitigation or "accept" note.
  • Do not paper over ambiguity — an honest open-questions section is what makes the doc trustworthy in review.

Output Format

  • Structure: Structured document with clear H2 sections and nested user-story/acceptance-criteria blocks
  • Length: 700–1,100 words for an MVP; up to 1,600 for a full v1
  • Format: Structured document — problem statement in prose; goals/non-goals, stories, and criteria as labeled lists; edge cases and open questions as tables or bulleted lists
  • Sections: Problem Statement → Goals & Non-Goals → User Stories (prioritized) → Acceptance Criteria → Edge Cases & Error States → Dependencies & Design Notes → Open Questions & Risks
  • Tone: Product manager writing for engineers — precise, unambiguous, decision-forcing; no marketing language, no hedging

Quality Checklist

Before delivering output, verify:

  • [ ] Problem statement is stated separately from the proposed solution
  • [ ] Non-Goals section contains at least 2 explicit exclusions
  • [ ] Every user story follows the "As a / I want / so that" format and carries a P0/P1/P2 priority
  • [ ] Every P0 and P1 story has at least one Given/When/Then acceptance criterion that is binary pass/fail
  • [ ] Edge cases include empty state, permission boundary, and error handling — not just the happy path
  • [ ] Open Questions section lists each item with a suggested owner and contains no unresolved ambiguity buried elsewhere in the doc

Notes

  • The Non-Goals and Open Questions sections are what separate a real spec from a wish list — resist the urge to fill open questions with assumptions to make the doc look finished.
  • When the input is customer feedback, translate verbatim complaints into the underlying job-to-be-done before writing stories; users describe symptoms, not requirements.
  • If the feature is large, recommend splitting it into a phased sequence (MVP → v1 → v2) rather than producing one oversized document — smaller specs get reviewed and shipped faster.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills