Use when proposing new features/products, documenting product requirements, creating concise specs for stakeholder alignment, pitching initiatives, scoping projects before detailed design, capturing user stories and success metrics, or when user mentions one-pager, PRD, product spec, feature proposal, product requirements, or brief.
When NOT to use: Detailed technical design docs (use ADRs instead), comprehensive product strategy (too high-level for one-pager), user research synthesis (different format), post-launch retrospectives (use postmortem skill).
Copy this checklist and track your progress:
One-Pager PRD Progress:
- [ ] Step 1: Gather context
- [ ] Step 2: Choose format
- [ ] Step 3: Draft one-pager
- [ ] Step 4: Validate quality
- [ ] Step 5: Review and iterate
Step 1: Gather context
Identify the problem (user pain, data supporting it), proposed solution (high-level approach), target users (personas, segments), success criteria (goals, metrics), and constraints (technical, business, timeline). See Common Patterns for typical problem types.
Step 2: Choose format
For simple features needing quick approval → Use resources/template.md one-pager format (1 page, bullets). For complex features/products requiring detailed requirements → Use resources/template.md full PRD format (1-2 pages). For writing guidance and structure → Study resources/methodology.md for problem framing, metric definition, scope techniques.
Step 3: Draft one-pager
Create one-pager-prd.md with: problem statement (user pain + why now), solution overview (what we're building), user personas and use cases, goals with quantified metrics, in-scope flows and out-of-scope items, constraints and assumptions, open questions to resolve. Keep concise—1 page for one-pager, 1-2 for PRD.
Step 4: Validate quality
Self-assess using resources/evaluators/rubric_one_pager_prd.json. Check: problem is specific and user-focused, solution is clear without being overly detailed, metrics are measurable and have targets, scope is realistic and boundaries clear, constraints acknowledged, open questions identified. Minimum standard: Average score ≥ 3.5.
Step 5: Review and iterate
Share with stakeholders (PM, design, engineering, business). Gather feedback on problem framing, solution approach, scope boundaries, and success metrics. Iterate based on input. Get explicit sign-off before moving to detailed design/development.
User Pain (Most Common):
Competitive Gap:
Strategic Opportunity:
Technical Debt/Scalability:
Simple Feature (Weeks):
Medium Feature (Months):
Large Initiative (Quarters):
B2B SaaS:
B2C Consumer:
Enterprise:
Internal Tools:
Problem:
Solution:
Metrics:
Scope:
Constraints:
Red Flags:
Resources:
resources/template.md - One-pager and PRD templates with section guidanceresources/methodology.md - Problem framing techniques, metric trees, scope prioritization, writing clarityresources/evaluators/rubric_one_pager_prd.json - Quality criteriaOutput: one-pager-prd.md with problem, solution, users, goals/metrics, scope, constraints, open questions
Success Criteria:
Quick Decisions:
Common Mistakes:
Key Insight: Brevity forces clarity. If you can't explain it in 1-2 pages, you haven't thought it through. One-pager is thinking tool as much as communication tool.
Format Tips:
Stakeholder Adaptation:
Google Workspace CLI for Gmail, Calendar, Drive, Contacts, Sheets, and Docs.
Manage Apple Notes via the `memo` CLI on macOS (create, view, edit, delete, search, move, and export notes). Use when a user asks OpenClaw to add a note, list notes, search notes, or manage note folders.
Work with Obsidian vaults (plain Markdown notes) and automate via obsidian-cli.
Use when you need to control Slack from OpenClaw via the slack tool, including reacting to messages or pinning/unpinning items in Slack channels or DMs.
Manage Apple Reminders via remindctl CLI (list, add, edit, complete, delete). Supports lists, date filters, and JSON/plain output.
Manage Trello boards, lists, and cards via the Trello REST API.
Category:productivity