Stats
Actions
Tags
From bytA
Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or when asked to create a PRD. Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out.
How this skill is triggered — by the user, by Claude, or both
Slash command
/bytA:prd-generatorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create Product Requirements Documents that focus on the **"What"** and **"Why"** — not the technical "How". Technical implementation details belong in the Technical Specification (Phase 0 of the full-stack-feature workflow).
Create Product Requirements Documents that focus on the "What" and "Why" — not the technical "How". Technical implementation details belong in the Technical Specification (Phase 0 of the full-stack-feature workflow).
"A PRD should avoid anticipating or defining how the product will do it, in order to later allow designers and engineers to use their expertise to provide the optimal solution." — Wikipedia
docs/prds/prd-[feature-name].mdImportant:
Ask only critical questions where the initial prompt is ambiguous. Focus on:
1. What is the primary goal of this feature?
A. Improve user onboarding experience
B. Increase user retention
C. Reduce support burden
D. Other: [please specify]
2. Who is the target user?
A. New users only
B. Existing users only
C. All users
D. Admin users only
3. What is the MVP scope?
A. Minimal — just the core functionality
B. Standard — core + nice-to-haves
C. Full — complete feature set
This lets users respond with "1A, 2C, 3B" for quick iteration.
Generate the PRD with these sections:
Brief description of the feature and the problem it solves. Answer:
Specific, measurable objectives (bullet list). What does success look like?
Each story needs:
Format:
### US-001: [Title]
**Description:** As a [user type], I want [action] so that [benefit].
**Acceptance Criteria:**
- [ ] User can [observable behavior]
- [ ] System displays [expected feedback]
- [ ] [Edge case] is handled gracefully
Rules for User Stories:
Good Examples:
Bad Examples (too technical):
priority field to Task model"OrderService with cancelOrder() method"Numbered list of what the system must do (not how):
Be explicit and unambiguous, but stay at the functional level.
What this feature will NOT include. Critical for managing scope and expectations.
Note: This is NOT a wireframe or design spec. Just describe the expected experience.
High-level constraints that affect the feature:
Note: Do NOT include technical architecture here. That's the Architect-Planner's job.
How will success be measured?
Remaining questions or areas needing clarification before implementation.
After saving the PRD file, present it to the user and ask:
PRD gespeichert unter docs/prds/prd-[feature-name].md
Soll ich ein GitHub Issue (Epic) mit dieser PRD erstellen?
Use gh issue create to create the Epic issue. The PRD content becomes the issue body.
Rules:
feat: [Feature Name] (derived from the PRD title)epic and feature (create if they don't exist)Command pattern:
mkdir -p docs/prds
gh label create "epic" --description "Epic - contains multiple user stories" --color "3E4B9E" --force
gh label create "feature" --description "New feature" --color "0E8A16" --force
gh issue create --title "feat: [Feature Name]" --label "epic" --label "feature" --body-file "docs/prds/prd-[feature-name].md"
Important:
--body-file to pass the PRD content (avoids shell escaping issues)After creating the Epic issue, ask the user:
Epic Issue #[N] erstellt: feat: [Feature Name]
Das Epic enthält [X] User Stories. Soll ich diese als separate Sub-Issues anlegen?
A. Ja, Sub-Issues erstellen (empfohlen für größere Features)
B. Nein, als Checkliste im Epic behalten (für kleinere Features)
For each User Story in the PRD, create a Sub-Issue linked to the Epic.
Rules:
[US-00X] [User Story Title] (e.g., [US-001] Set task priority)user-story (create if it doesn't exist)gh issue develop or body referenceCommand pattern for each User Story:
gh label create "user-story" --description "User story - implementable unit of work" --color "C2E0C6" --force
# Create Sub-Issue with reference to Epic
gh issue create --title "[US-001] [Title]" --label "user-story" --body "$(cat <<'EOF'
Parent Epic: #[EPIC_NUMBER]
## [US-001]: [Title]
**Description:** As a [user type], I want [action] so that [benefit].
**Acceptance Criteria:**
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]
EOF
)"
After creating all Sub-Issues:
Sub-Issues erstellt:
- #[N1] [US-001] Set task priority
- #[N2] [US-002] See priority at a glance
- #[N3] [US-003] Filter by priority
- #[N4] [US-004] Sort by priority
Jede User Story kann jetzt einzeln mit /byt8:full-stack-feature #[N] implementiert werden.
After creating Sub-Issues, update the Epic's User Stories section:
# Read current Epic body, replace User Stories section with links
gh issue edit [EPIC_NUMBER] --body "$(cat <<'EOF'
[... PRD content until User Stories section ...]
## User Stories
> Die User Stories wurden als separate Issues angelegt:
- #[N1] [US-001] Set task priority
- #[N2] [US-002] See priority at a glance
- #[N3] [US-003] Filter by priority
- #[N4] [US-004] Sort by priority
[... rest of PRD content ...]
EOF
)"
.md)docs/prds/prd-[feature-name].md (kebab-case)epic + feature labelsuser-story label# PRD: Task Priority System
## Overview
Users need a way to mark tasks as high, medium, or low priority so they can focus on what matters most. Currently, all tasks appear equal, making it hard to identify urgent work.
**Target Users:** All users who manage tasks in the system.
## Goals
- Enable users to quickly identify their most important tasks
- Reduce time spent deciding what to work on next
- Improve task completion rates for high-priority items
## User Stories
### US-001: Set task priority
**Description:** As a user, I want to assign a priority level to my tasks so that I can indicate which ones are most urgent.
**Acceptance Criteria:**
- [ ] User can select priority (high, medium, low) when creating a task
- [ ] User can change priority on existing tasks
- [ ] New tasks default to medium priority
- [ ] Priority change is saved immediately
### US-002: See priority at a glance
**Description:** As a user, I want to see task priority visually so that I can quickly identify urgent tasks without clicking into them.
**Acceptance Criteria:**
- [ ] Each task displays a visual priority indicator (color, icon, or badge)
- [ ] High priority is visually distinct from medium and low
- [ ] Priority indicator is visible in all task list views
### US-003: Filter by priority
**Description:** As a user, I want to filter my task list by priority so that I can focus on high-priority items when I'm busy.
**Acceptance Criteria:**
- [ ] User can filter to show only high/medium/low priority tasks
- [ ] Filter state persists when navigating away and back
- [ ] Clear indication when a filter is active
- [ ] Easy way to clear the filter and see all tasks
### US-004: Sort by priority
**Description:** As a user, I want to sort my task list by priority so that urgent tasks appear at the top.
**Acceptance Criteria:**
- [ ] User can sort tasks by priority (high → medium → low)
- [ ] Sort option is easily accessible
- [ ] Sort can be combined with other sorting options (e.g., due date)
## Functional Requirements
- FR-1: The system must support three priority levels: high, medium, low
- FR-2: The system must allow priority to be set during task creation
- FR-3: The system must allow priority to be changed on existing tasks
- FR-4: The system must display a visual indicator for each priority level
- FR-5: The system must support filtering tasks by priority
- FR-6: The system must support sorting tasks by priority
## Non-Goals
- Priority-based notifications or reminders
- Automatic priority assignment based on due date
- Priority inheritance for subtasks
- Priority analytics or reporting
## User Experience Considerations
- Priority selector should be quick to use (max 2 clicks)
- Visual indicators should be colorblind-accessible
- Mobile users should be able to change priority easily
- Consider keyboard shortcuts for power users
## Constraints & Dependencies
- Must work with existing task management workflow
- Should not significantly increase page load time
- Priority data must be included in any existing export features
## Success Metrics
- 70% of users assign priority to at least one task within first week
- Users report finding urgent tasks faster (survey)
- No increase in task abandonment rate
## Open Questions
- Should priority affect the default sort order automatically?
- Should we allow custom priority labels in the future?
- How should priority be displayed in calendar/timeline views?
Before finishing:
docs/prds/prd-[feature-name].mdepic + feature labelsuser-story label and Epic referencenpx claudepluginhub byteagenten/byteagenten-marketplace --plugin bytADrafts lightweight PRDs via guided conversation for feature ideas, requirements brainstorming, sprint planning, user stories, and acceptance criteria expansion.
Transforms product ideas, feature requests, or stakeholder requirements into structured PRDs with user stories, acceptance criteria, and GitHub issues.
Generates Product Requirements Documents (PRDs) for features via clarifying questions on goals, users, and scope. Structures into user stories, requirements; saves to tasks/prd-[feature].md.