From thinking-frameworks-skills
Creates concise one-pagers and PRDs aligning stakeholders on problem, solution, users, success metrics, and constraints. Useful for feature proposals, requirement docs, pitching initiatives, or project scoping.
npx claudepluginhub lyndonkl/claude --plugin thinking-frameworks-skillsThis skill uses the workspace's default tool permissions.
**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).
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
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: