From hb
Creates a Product Requirements Document through user interviews, codebase exploration, and module design. Walks through scope, data, behavior, display, access, boundaries, and integration decisions.
How this skill is triggered — by the user, by Claude, or both
Slash command
/hb:prd <idea><idea>The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Skip satisfied steps. If argument provided, skip to Step 2.
Skip satisfied steps. If argument provided, skip to Step 2.
Interactive prompts: present options as a numbered list and wait for the user's choice.
The argument is: $ARGUMENTS
If empty, go to Step 1; derive slug after gathering the idea. If provided, derive slug:
— or – (if present)<slug>Output: .specs/prds/<slug>.md. If file exists, present options and wait:
Ask the user for a detailed description of the problem and any solution ideas.
Map current state: data models, services, API routes, frontend, tests. Note exists vs. must build.
Research protocol: codebase first, then docs. Unverifiable claims → flag as uncertain, never fabricate.
One question at a time. Lead with your recommended answer (mark it (Recommended) and list first). Explore code instead of asking when possible. Present 2–4 options for each question — structured choices are faster than free-text.
| Branch | Key questions | Skip when |
|---|---|---|
| Scope & Surface | Where? New page or integrated? Roles? | CLI/library, no new entry points |
| Data & Concepts | Definitions, existing vs missing data | Never skip |
| Behavior | Interaction patterns, filtering, search | No user-facing behavior |
| Display | Numbers, tables, charts, exports | No UI |
| Access & Privacy | Who sees what? Sensitive data? | Single-user, no auth |
| Boundaries | Out of scope, deferred features | Never skip |
| Integration | Schema, services, external deps | Self-contained change |
Surface ambiguities, contradictions, unstated assumptions. For each gray area, present proposed resolution options. Resolve all before continuing.
Sketch modules. Favor deep modules — simple interface (1-3 entry points) hiding large implementation over shallow modules where interface ≈ implementation.
Shallow signals: many small 1:1 functions, callers compose multiple calls, feature changes require interface changes.
Present modules. Confirm which need tests.
Save to .specs/prds/<slug>.md (create dir if missing).
# Feature Name
PRD body structure. Omit empty sections. No file paths or code snippets.
## Problem Statement
## Current State (skip if greenfield)
## Solution (user experience, not architecture)
## User Stories (numbered, cover happy + edge + error)
## Implementation Decisions
### New Modules (name, purpose, interface signatures)
### Architectural Decisions (definitions, data flow, state)
### Schema Changes
### API Contracts
### Navigation
## Testing Decisions (behavior tests, key cases, prior art)
## Out of Scope (be specific)
Present options and wait for the user's choice:
/plan <slug> (Recommended)npx claudepluginhub helderberto/agent-skills --plugin hbGenerates a structured Product Requirements Document (PRD) from feature descriptions. Analyzes codebase (package.json, configs, README), processes references, asks clarifying questions, saves to .plans/. Use for new feature planning.
Synthesizes a PRD for big features from project context and ADRs. Asks before creating a GitHub issue. Use when scoping a substantial new feature.
Conducts in-depth PRD interviews to uncover hidden assumptions, edge cases, and technical/UI implications, then refines the PRD file.