Deliver Prd
- 654 installs
- 518 repo stars
- Updated August 4, 2026
- product-on-purpose/pm-skills
deliver-prd is an agent skill (version 2.0.0) that generates a comprehensive Product Requirements Document with problem context, metrics, stories, and scope for developers who need a structured engineering handoff artifa
About
deliver-prd in product-on-purpose/pm-skills (version 2.0.0, Apache 2.0) creates a Product Requirements Document that bridges problem understanding and engineering implementation. The skill is example-anchored and template-contracted: agents mirror worked samples, fill enforced sections, and output problem statements, success metrics, user stories, scope boundaries, and dependencies. It belongs to the pm-skills library alongside 68 agent-ready skills, 10 workflow orchestrators, and 95+ sample outputs invoked via commands like /pm-skills:deliver-prd. The declarative contract enforces sections-present and sections-complete so agents produce stakeholder-ready specs without prompt engineering. Developers reach for deliver-prd after problem and solution alignment and before engineering starts, when stakeholders must approve scope or multiple teams need a shared specification. The Triple Diamond deliver phase framing ensures INVEST-ready stories, testable acceptance criteria references, and explicit out-of-scope lists. Triggers include specifying features, epics, or product initiatives for handoff.
- deliver-prd
- AI & Agent Building
- AI-coding skill
Deliver Prd by the numbers
- 654 all-time installs (skills.sh)
- +35 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #1,494 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/product-on-purpose/pm-skills --skill deliver-prdAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 654 |
|---|---|
| repo stars | ★ 518 |
| Last updated | August 4, 2026 |
| Repository | product-on-purpose/pm-skills ↗ |
How do you write a PRD for engineering handoff?
Helps with ai & agent building tasks.
Who is it for?
Product-minded developers and tech leads who need a stakeholder-ready PRD before sprint planning or multi-team feature work.
Skip if: Teams already in active implementation who only need ticket-level task breakdowns without a new specification document.
When should I use this skill?
User asks for a PRD, product requirements document, feature specification, or engineering handoff doc for an epic or initiative.
What you get
Completed Product Requirements Document with problem, metrics, user stories, scope boundaries, and dependency sections.
- Product Requirements Document
- Scope and dependency sections
By the numbers
- Skill version 2.0.0 in the pm-skills library with 68 skills and 95+ sample outputs
- Apache 2.0 licensed with template-enforced PRD sections
Files
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
Product Requirements Document (PRD)
A Product Requirements Document is the primary specification artifact that communicates what to build and why. It bridges the gap between problem understanding and engineering implementation by providing clear requirements, success criteria, and scope boundaries. A good PRD enables engineering to build the right thing while maintaining flexibility on implementation details.
When to Use
- After problem and solution alignment, before engineering work begins
- When specifying features, epics, or product initiatives for handoff
- When multiple teams need to coordinate on a shared deliverable
- When stakeholders need to approve scope before investment
- As reference documentation during development and QA
When NOT to Use
- The problem is still unframed or contested -> use
define-problem-statementfirst; a PRD assumes an agreed problem - You need a one-page pitch to align stakeholders on an approach -> use
develop-solution-brief; the PRD comes after that alignment - You only need the work broken into tickets for a sprint -> use
deliver-user-stories - You are recording a technical or architectural decision -> use
develop-adr
Instructions
When asked to create a PRD, follow these steps:
1. Summarize the Problem Start with a brief recap of the problem being solved. Link to the problem statement if available. Ensure readers understand why this work matters before diving into what to build.
2. Define Goals and Success Metrics Articulate what success looks like. Include specific, measurable metrics with baselines and targets. These metrics should connect directly to the problem being solved.
3. Outline the Solution Describe the proposed solution at a high level. Focus on user-facing functionality and key capabilities. Include enough detail for stakeholders to evaluate the approach without over-specifying implementation.
4. Detail Functional Requirements Break down what the system must do. Use user stories or requirement statements. Each requirement should be testable - someone should be able to verify if it's met.
5. Define Scope Boundaries Explicitly state what's in scope, out of scope, and deferred to future iterations. Clear scope prevents scope creep and sets realistic expectations.
6. Address Technical Considerations Note any technical constraints, architectural decisions, or integration requirements. Don't design the system, but surface considerations engineering needs to know.
7. Identify Dependencies and Risks List external dependencies, assumptions, and risks that could impact delivery. Include mitigation strategies where applicable.
8. Propose Timeline and Milestones Outline key phases and checkpoints. This helps stakeholders understand the delivery plan without committing to specific dates prematurely.
Output Format
Use the template in references/TEMPLATE.md to structure the output. A complete PRD fills every template section: Overview; Goals & Success Metrics; User Stories; Scope; Solution Design; Technical Considerations; Dependencies & Risks; Timeline & Milestones; Open Questions; and the Appendix when supporting material exists.
Quality Checklist
Before finalizing, verify:
- [ ] Problem and "why now" are clearly articulated
- [ ] Success metrics are specific and measurable
- [ ] Scope boundaries are explicit (in/out/future)
- [ ] Requirements are testable and unambiguous
- [ ] Technical considerations are surfaced without over-specifying
- [ ] Dependencies and risks are documented with owners
- [ ] Document is readable in under 15 minutes
Examples
See references/EXAMPLE.md for a completed example.
{
"schema": 1,
"skill": "deliver-prd",
"runs_per_query": 3,
"trigger_threshold": 0.5,
"queries": [
{
"q": "Write a PRD for the new self-serve onboarding flow",
"expect": "trigger",
"split": "train"
},
{
"q": "Engineering keeps asking what exactly we're building and why; I need one doc that settles scope, requirements, and success metrics before the sprint starts",
"expect": "trigger",
"split": "train",
"notes": "Intent-only ask, no artifact keyword"
},
{
"q": "We agreed on the problem and the approach for payment retries; now I need the full requirements doc for engineering handoff",
"expect": "trigger",
"split": "train"
},
{
"q": "Help me spec out the requirements for our Q3 epic so design, backend, and mobile are all working from the same source",
"expect": "trigger",
"split": "train"
},
{
"q": "Put together a product requirements document for migrating reporting to the new dashboard, including scope boundaries and success metrics",
"expect": "trigger",
"split": "train"
},
{
"q": "Stakeholders want to approve scope before we invest two quarters in this initiative; draft the spec doc they can sign off on",
"expect": "trigger",
"split": "train"
},
{
"q": "Draft a PRD for adding SSO support to the enterprise tier",
"expect": "trigger",
"split": "validation"
},
{
"q": "I have a one-pager and leadership buy-in; turn this into a complete requirements document the team can build from",
"expect": "trigger",
"split": "validation"
},
{
"q": "We're kicking off the offline mode initiative; create the spec that covers requirements, out-of-scope items, dependencies, and risks",
"expect": "trigger",
"split": "validation"
},
{
"q": "Three teams are coordinating on the shared checkout rebuild; write the document that aligns everyone on what we're building, why, and how we'll measure success",
"expect": "trigger",
"split": "validation",
"notes": "Intent-only ask, no artifact keyword"
},
{
"q": "Take this feature description and break it into user stories with acceptance criteria for next sprint's tickets",
"expect": "no-trigger",
"split": "train",
"near_miss_of": "deliver-user-stories",
"notes": "Ticket breakdown for a sprint belongs to the story skill, per the PRD's When NOT to Use"
},
{
"q": "Before we write any detailed spec, I need a one-page solution overview pitching the approach and trade-offs to stakeholders",
"expect": "no-trigger",
"split": "validation",
"near_miss_of": "develop-solution-brief",
"notes": "One-page pitch for approach alignment comes before the PRD"
},
{
"q": "Document the architectural decision to move from REST to gRPC for our internal services",
"expect": "no-trigger",
"split": "train",
"notes": "Technical decision record; develop-adr territory"
},
{
"q": "Write release notes announcing the new notifications feature to customers",
"expect": "no-trigger",
"split": "train"
},
{
"q": "Help me put together a pre-launch readiness checklist across marketing, support, and legal",
"expect": "no-trigger",
"split": "train"
},
{
"q": "Summarize what we learned from the 12 customer interviews last week",
"expect": "no-trigger",
"split": "train"
},
{
"q": "Write a SQL query that finds users who churned within 30 days of signup",
"expect": "no-trigger",
"split": "validation",
"notes": "Unrelated technical ask"
},
{
"q": "My Next.js build is failing with a module resolution error; help me debug it",
"expect": "no-trigger",
"split": "train",
"notes": "Unrelated debugging ask"
},
{
"q": "Book me a flight and hotel for the product offsite in Austin next month",
"expect": "no-trigger",
"split": "validation",
"notes": "Unrelated logistics ask"
},
{
"q": "Draft the OKRs for our platform team for next quarter",
"expect": "no-trigger",
"split": "validation"
}
]
}
deliver-prd - Version History
| Version | Date | Release | Effort | Type | Summary |
|---|---|---|---|---|---|
| 2.1.0 | 2026-06-10 | v2.26.0 | F-12-batch-1 | minor | Quality convergence: When NOT to Use + output-contract enumeration (F-12 Batch 1) |
| 2.0.0 | 2026-01-26 | - | - | baseline | Prior published version |
2.1.0 (2026-06-10)
Quality-convergence minor (F-12 Batch 1): added a "When NOT to Use" section with boundary pointers to neighboring skills, and the Output Format now enumerates the template sections a complete artifact fills. No template or example changes.
2.0.0 (2026-01-26)
Baseline row for the prior published version; see git history for its changes.
PRD: Recurring Tasks
Overview
Problem Statement
Users of TaskFlow spend significant time manually recreating repetitive tasks that occur on predictable schedules. Our research shows that 34% of all tasks created are duplicates of previous tasks, and power users report spending 2+ hours per week on this manual work. This friction reduces productivity and causes users to miss recurring deadlines when they forget to recreate tasks.
Solution Summary
Add recurring task functionality that allows users to create tasks that automatically regenerate on defined schedules. Users can set weekly, monthly, or custom recurrence patterns, and the system will create new task instances automatically while preserving the connection to the original recurring series.
Target Users
- Primary: Team leads and project managers who manage ongoing operational tasks (weekly reports, monthly reviews, recurring meetings)
- Secondary: Individual contributors who have personal recurring responsibilities (timesheets, 1:1 prep, status updates)
Goals & Success Metrics
Goals
1. Reduce time spent on manual task recreation by 80% 2. Decrease missed recurring deadlines by 50% 3. Increase weekly active usage among power users
Success Metrics
| Metric | Current Baseline | Target | Timeline |
|---|---|---|---|
| Duplicate task creation rate | 34% | 15% | 90 days post-launch |
| Missed recurring deadlines | 12 per user/month | 6 per user/month | 90 days post-launch |
| Power user WAU | 67% | 75% | 90 days post-launch |
| Feature adoption (% using recurring) | 0% | 40% | 90 days post-launch |
Non-Goals
- Task dependencies or predecessor relationships
- Automated task assignment rotation (e.g., round-robin)
- Integration with external calendar systems (deferred to v2)
User Stories
| ID | User Story | Priority |
|---|---|---|
| US-1 | As a team lead, I want to create a task that repeats weekly so that I don't have to manually recreate it | P0 |
| US-2 | As a user, I want to edit a single instance without affecting the series so that I can handle exceptions | P0 |
| US-3 | As a user, I want to see upcoming instances of recurring tasks so that I can plan my workload | P0 |
| US-4 | As a user, I want to pause and resume a recurring series so that I can handle temporary schedule changes | P1 |
| US-5 | As a team lead, I want to edit the entire series at once so that I can make bulk changes efficiently | P1 |
| US-6 | As a user, I want to set an end date for recurrence so that temporary projects don't create tasks forever | P1 |
See User Stories Document for full acceptance criteria.
Scope
In Scope
- Create recurring tasks with daily, weekly, monthly patterns
- Edit single instance vs. entire series
- View upcoming instances (next 4 weeks)
- Pause/resume recurring series
- Set recurrence end date or occurrence count
- Delete single instance vs. entire series
- Recurring tasks visible in list view, calendar view, and board view
Out of Scope
- Custom recurrence patterns (e.g., "every 3rd Tuesday") - v2
- Calendar sync (Google Calendar, Outlook) - v2
- Task assignment rotation - future consideration
- Recurring subtasks - future consideration
- Bulk operations on multiple recurring series
Future Considerations
- Custom patterns (v2): Complex scheduling like "first Monday of each month" or "every 2 weeks" - deferred due to UI complexity; standard patterns cover 85% of use cases
- Calendar sync (v2): Two-way sync with external calendars - deferred due to integration complexity and scope
- Assignment rotation: Auto-rotate assignee for team tasks - requires additional UX research to understand use cases
Solution Design
Functional Requirements
Task Creation
- FR-1: Users can mark any new task as recurring during creation
- FR-2: Recurrence options include: Daily, Weekly (select days), Monthly (select date or day-of-week)
- FR-3: Users can set recurrence to end after X occurrences or on a specific date
- FR-4: Default recurrence end is "never" with system limit of 52 weeks forward generation
Instance Management
- FR-5: Each recurring task generates instances up to 4 weeks in advance
- FR-6: Completing an instance marks only that instance complete and triggers next instance generation
- FR-7: Editing an instance shows option: "Edit this instance only" or "Edit all future instances"
- FR-8: Deleting an instance shows option: "Delete this instance only" or "Delete entire series"
Series Management
- FR-9: Users can pause a recurring series, stopping new instance generation
- FR-10: Paused series display visual indicator and can be resumed
- FR-11: Users can view and edit the recurrence pattern from any instance
User Experience
Creation Flow: 1. User clicks "Add Task" 2. User enters task details 3. User clicks "Make Recurring" toggle 4. Recurrence panel expands with pattern options 5. User selects pattern and confirms 6. First instance created immediately, future instances generated
Visual Indicators:
- Recurring tasks show refresh icon in list/board views
- Instance number displayed (e.g., "#3 of series")
- Paused series show pause indicator with muted styling
See Figma Design Specs for detailed mockups.
Edge Cases
| Scenario | Expected Behavior |
|---|---|
| User deletes instance that's in progress | Prompt: "This task has logged time. Delete anyway?" |
| Series created with past start date | Create instance for next valid date, not retroactively |
| Monthly recurrence on 31st | Use last day of month for shorter months |
| User changes recurrence pattern | Apply to future instances only, preserve completed instances |
| User completes instance early | Next instance still generates on schedule |
Technical Considerations
Constraints
- Maximum 52 weeks of forward instance generation (prevent database bloat)
- Recurrence calculations must handle timezone correctly (user's local time)
- Instance generation must be idempotent (safe to re-run)
Integration Points
- Notification Service: Recurring task reminders use existing notification infrastructure
- Activity Feed: Instance completion logs to activity feed as normal task completion
- Reporting: Recurring tasks aggregate into existing productivity reports
Data Requirements
- New
recurring_seriestable linking instances to parent series recurrence_patternstored as RRULE-compatible format for future calendar sync- Soft delete for series to preserve historical data
- Migration: No data migration required (new feature)
Dependencies & Risks
Dependencies
| Dependency | Owner | Status | Impact if Delayed |
|---|---|---|---|
| Calendar view refactor | Frontend Team | In Progress | Cannot show recurring instances in calendar |
| Background job infrastructure | Platform Team | Complete | None |
| Design specs finalized | Design Team | In Review | Delays development start |
Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| User confusion about instance vs. series editing | Medium | Medium | Clear UI copy, confirmation dialogs, user testing |
| Performance impact of instance generation | Low | High | Lazy generation, batch processing, monitoring |
| Feature complexity delays launch | Medium | Medium | MVP scope locked, defer edge cases to v1.1 |
| Low adoption if UX isn't intuitive | Medium | High | User testing before launch, in-app education |
Timeline & Milestones
| Milestone | Description | Target Date |
|---|---|---|
| Design Complete | Final mockups approved | Jan 24, 2026 |
| Backend Complete | API and data model ready | Feb 7, 2026 |
| Frontend Complete | UI implementation done | Feb 21, 2026 |
| QA Complete | Testing and bug fixes | Feb 28, 2026 |
| Beta Launch | 10% rollout | Mar 3, 2026 |
| GA Launch | 100% rollout | Mar 10, 2026 |
Open Questions
- [x] Should we support "business days only" recurrence? - Decision: No, defer to v2
- [ ] How do we handle recurring tasks when user loses access to project? - Owner: Product
- [ ] Should paused series auto-resume after X time? - Owner: Product
- [ ] What's the right default reminder time for recurring tasks? - Owner: Design
Appendix
Related Documents
- Problem Statement: Task Recreation Friction
- User Research: Recurring Task Needs
- Figma: Recurring Tasks Design
- Technical Design: Recurrence Engine
Revision History
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | Jan 10, 2026 | Sarah Chen | Initial draft |
| 0.2 | Jan 12, 2026 | Sarah Chen | Added edge cases, updated scope |
| 1.0 | Jan 14, 2026 | Sarah Chen | Final review, approved by stakeholders |
PRD: [Feature/Initiative Name]
Overview
Problem Statement
<!-- Brief recap of the problem. Link to full problem statement if available. -->
[Problem summary]
Solution Summary
<!-- High-level description of what we're building -->
[Solution summary]
Target Users
<!-- Who will use this feature? -->
[Target user description]
Goals & Success Metrics
Goals
<!-- What outcomes are we trying to achieve? -->
1. [Primary goal] 2. [Secondary goal] 3. [Secondary goal]
Success Metrics
| Metric | Current Baseline | Target | Timeline |
|---|---|---|---|
| [Primary metric] | [Value] | [Value] | [Date] |
| [Secondary metric] | [Value] | [Value] | [Date] |
Non-Goals
<!-- What are we explicitly NOT trying to achieve? -->
- [Non-goal 1]
- [Non-goal 2]
User Stories
<!-- Summary of key user stories. Link to detailed stories if available. -->
| ID | User Story | Priority |
|---|---|---|
| US-1 | As a [user], I want [action] so that [benefit] | P0 |
| US-2 | As a [user], I want [action] so that [benefit] | P0 |
| US-3 | As a [user], I want [action] so that [benefit] | P1 |
See [link to detailed user stories] for full acceptance criteria.
Scope
In Scope
<!-- What will be delivered in this iteration -->
- [Feature/capability 1]
- [Feature/capability 2]
- [Feature/capability 3]
Out of Scope
<!-- What will NOT be delivered -->
- [Excluded item 1]
- [Excluded item 2]
Future Considerations
<!-- Items deferred to future iterations -->
- [Future item 1] - [Rationale for deferral]
- [Future item 2] - [Rationale for deferral]
Solution Design
Functional Requirements
[Requirement Area 1]
<!-- Group related requirements -->
- FR-1: [Requirement statement]
- FR-2: [Requirement statement]
[Requirement Area 2]
- FR-3: [Requirement statement]
- FR-4: [Requirement statement]
User Experience
<!-- Key UX decisions, flows, or wireframe references -->
[UX notes or link to designs]
Edge Cases
<!-- Important edge cases to handle -->
| Scenario | Expected Behavior |
|---|---|
| [Edge case 1] | [Behavior] |
| [Edge case 2] | [Behavior] |
Technical Considerations
<!-- Technical constraints, architectural notes, or integration requirements -->
Constraints
- [Constraint 1]
- [Constraint 2]
Integration Points
- [System/API 1]: [Integration notes]
- [System/API 2]: [Integration notes]
Data Requirements
<!-- Any data migration, storage, or privacy considerations -->
[Data notes]
Dependencies & Risks
Dependencies
| Dependency | Owner | Status | Impact if Delayed |
|---|---|---|---|
| [Dependency 1] | [Team/Person] | [Status] | [Impact] |
| [Dependency 2] | [Team/Person] | [Status] | [Impact] |
Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| [Risk 1] | [H/M/L] | [H/M/L] | [Mitigation strategy] |
| [Risk 2] | [H/M/L] | [H/M/L] | [Mitigation strategy] |
Timeline & Milestones
| Milestone | Description | Target Date |
|---|---|---|
| [Milestone 1] | [Description] | [Date] |
| [Milestone 2] | [Description] | [Date] |
| [Launch] | [Description] | [Date] |
Open Questions
<!-- Unresolved questions that need answers before or during development -->
- [ ] [Question 1] - Owner: [Name]
- [ ] [Question 2] - Owner: [Name]
Appendix
Related Documents
- Problem Statement - add link or path
- User Research - add link or path
- Design Specs - add link or path
- Technical Design - add link or path
Revision History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | [Date] | [Author] | Initial draft |
Related skills
Setup Matt Pocock SkillsScaffold the per-repo configuration that Matt Pocock’s engineering agent skills rely on so they understand the issue tracker, triage labels, and domain documentation la495k196k
Lark AppsConnect Claude, Cursor or custom agents directly to Lark (Feishu) for messaging, document automation, approval workflows and enterprise data access.402k
CavemanSlash token usage by roughly 75% while keeping every technical detail intact when working with Claude Code, Cursor or similar agents.391k94.7k
Lark Skill MakerQuickly turn any Lark/Feishu OpenAPI call or multi-step workflow into a reusable agent skill with its own SKILL.md.386k16k
Running Claude Code Via Litellm CopilotRun Claude Code at a fraction of the cost by routing requests through LiteLLM to the GitHub Copilot Chat API.270k72
Codex PetGenerate a complete Codex Pet spritesheet and metadata from one reference image without needing an OpenAI key or Codex Pro.246k10How it compares
Pick deliver-prd for full PRD specifications; pick deliver-user-stories when only INVEST stories and acceptance criteria are needed without a full document.
FAQ
What sections does deliver-prd include?
deliver-prd fills a template-contracted PRD with problem context, success metrics, user stories, scope boundaries, dependencies, and explicit out-of-scope items ready for engineering handoff.
How do you invoke deliver-prd?
deliver-prd runs via /pm-skills:deliver-prd with a feature description; the agent loads version 2.0.0 instructions, mirrors worked examples, and outputs a complete PRD without manual prompt engineering.
When should deliver-prd be used?
deliver-prd fits after problem alignment and before engineering, when stakeholders must approve scope or multiple teams need a shared specification for features, epics, or product initiatives.