From flywheel-pm
Create comprehensive product specs through structured AskUserQuestion interviews or review existing specs against a detailed completeness checklist. Use when creating specs from scratch (no solution doc) or reviewing spec quality.
npx claudepluginhub abhitsian/compound-pm-marketplace --plugin flywheel-pmThis skill uses the workspace's default tool permissions.
Provide two complementary spec workflows:
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.
Provide two complementary spec workflows:
| Group | Questions | Focus |
|---|---|---|
| A. Problem & Context | 1-4 | User pain, persona, goals, business justification |
| B. Scope & Prioritization | 5-7 | MVP vs future, dependencies, constraints |
| C. User Flows & Experience | 8-12 | Happy path, entry points, UI layout, feedback, responsive |
| D. Business Logic & Validation | 13-16 | Input rules, business rules, data dependencies, limits |
| E. Edge Cases & Error Handling | 17-20 | Errors, error communication, concurrency, boundaries |
| F. Permissions & Security | 21-24 | Access control, role permissions, privacy, security risks |
| G. Cross-Cutting Concerns | 25-28 | Accessibility, loading states, offline, existing patterns |
| H. Success Metrics | 29-31 | KPIs, analytics tracking, launch criteria |
| I. Assumptions & Risks | 32-34 | Assumptions, open questions, failure modes |
Rules:
AskUserQuestion Pattern:
Instead of: "What are the requirements?" Ask: "What happens when a user tries to [action] but [constraint]? Should we show an error, disable the button, or handle it differently?"
Instead of: "How should this work?" Ask: "If two users are editing the same item simultaneously, should we lock it, show a warning, auto-merge, or let the last save win?"
Instead of: "What validations do you need?" Ask: "For the email field, should we validate format on blur or submit? What's the exact error message? Are temporary email addresses like 10minutemail allowed?"
Problem & Context:
Scope:
User Experience:
Business Logic:
Edge Cases:
Security & Access:
Accessibility:
Metrics:
Risks & Assumptions:
| Dimension | Criteria |
|---|---|
| Clarity | Understandable by all audiences; no ambiguous language; acceptance criteria are testable; error messages written exactly |
| Consistency | Terminology used consistently; no contradictions; follows existing patterns |
| Completeness | Engineer implements without questions; designer creates mockups; QA writes test cases; all interactions have outcomes |
| Realism | Technically feasible; timeline achievable; dependencies available; constraints respected |
| Priority | Criteria |
|---|---|
| Critical | Must-fix before implementation — blocks eng, design, or QA |
| Important | Should-fix for quality — spec works but has gaps |
| Nice-to-have | Would improve but not blocking — polish items |
A complete spec enables:
The full spec template with all 34 interview questions, 14-section spec structure, and review checklist is available in references/spec-template.md.