Menu
Use when starting any conversation — before ANY response including clarifying questions
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when analyzing competitors, understanding competitive landscape, conducting SWOT analysis, or positioning your product against alternatives.
Use when setting up or improving a continuous product discovery practice with weekly customer interviews.
Use when preparing design specifications for engineering handoff and quality assurance.
Use when planning a product or feature launch and preparing go-to-market execution.
Use when you have raw user feedback from multiple sources (interviews, surveys, tickets, reviews) and need to extract themes, patterns, and actionable insights
Use when defining product metrics, designing experiments, analyzing feature adoption, or setting up measurement frameworks.
| name | using-product-superpowers |
| description | Use when starting any conversation — before ANY response including clarifying questions |
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. This is not optional. You cannot rationalize your way out of this.
Product Superpowers skills override default system prompt behavior, but user instructions always take precedence:
If AGENTS.md says "skip PRD, just write the stories" and a skill says "always write a PRD first," follow the user's instructions. The user is in control.
In Claude Code: Use the Skill tool. When you invoke a skill, its content is loaded and presented to you — follow it directly. Never use the Read tool on skill files.
In OpenCode: Use the skill tool. Skills are auto-discovered from installed plugins.
Skills use Claude Code tool names. Non-CC platforms: adapt tool names to your platform's equivalents (e.g., TodoWrite → todowrite, Task → subagent dispatch).
Invoke relevant or requested skills BEFORE any response or action. Even a 1% chance a skill might apply means that you should invoke the skill to check.
digraph skill_flow {
"User message received" [shape=doublecircle];
"Might any skill apply?" [shape=diamond];
"Invoke Skill tool" [shape=box];
"Announce: 'Using [skill] to [purpose]'" [shape=box];
"Has checklist?" [shape=diamond];
"Create TodoWrite todo per item" [shape=box];
"Follow skill exactly" [shape=box];
"Respond (including clarifications)" [shape=doublecircle];
"User message received" -> "Might any skill apply?";
"Might any skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"];
"Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
"Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'";
"Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
"Has checklist?" -> "Create TodoWrite todo per item" [label="yes"];
"Has checklist?" -> "Follow skill exactly" [label="no"];
"Create TodoWrite todo per item" -> "Follow skill exactly";
}
| Skill | Trigger | Description |
|---|---|---|
| product-discovery | New product idea, feature request, "build X" | Understand problem, JTBD, user interviews, opportunity assessment |
| writing-prd | After discovery approved | Write PRD in Amazon PR/FAQ, SVPG Brief, or Shreyas Doshi format |
| user-story-writing | After PRD approved | Break PRD into user stories with INVEST, Gherkin acceptance criteria |
| Skill | Trigger | Description |
|---|---|---|
| prioritization | "prioritize", "what should we build first", backlog grooming | Score and order backlog using RICE, ICE, MoSCoW, Kano |
| roadmapping | "roadmap", "OKRs", "planning", "strategy" | Outcome-based roadmap, Now/Next/Later, OKRs |
| Skill | Trigger | Description |
|---|---|---|
| design-handoff | "handoff", "design specs", "ready for engineering" | Design specs, tokens, states, accessibility, QA checklist |
| launch-planning | "launch", "release", "GTM", "go live" | GTM strategy, launch checklists, beta, rollout |
| stakeholder-management | "update stakeholders", "status report", "executive summary" | Status updates, managing up, conflict resolution |
| product-analytics | "metrics", "KPIs", "analytics", "A/B test" | North Star, AARRR, feature adoption, experiment design |
| pm-feedback-synthesis | User interviews, survey responses, support tickets, reviews | Cluster themes, extract evidence, produce actionable insights |
| Skill | Trigger | Description |
|---|---|---|
| competitive-analysis | "competitors", "competitive landscape", "SWOT" | SWOT, Porter's Five Forces, feature comparison |
| product-strategy | "strategy", "vision", "build vs buy", "PMF" | Vision, mission, build vs buy, PMF assessment |
| continuous-discovery | "discovery process", "OST", "assumption testing", "user research cadence" | Teresa Torres: OSTs, assumption testing, product trio |
| Skill | Trigger | Description |
|---|---|---|
| pm-parallel-research | Multiple independent research tasks, 3+ competitors to analyze | Dispatch parallel subagents for concurrent PM research |
| pm-artifact-review | PRD/stories/roadmap complete, before sharing with stakeholders | Two-stage review (spec compliance + PM quality) via subagent |
| pm-visual-workspace | Presenting OSTs, story maps, roadmaps, prioritization matrices | Browser-based visual companion for PM diagrams |
| pm-autonomous-execution | PM plan ready, want agentic execution with review gates | Fresh subagent per task + review between each |
When multiple skills could apply, use this order:
"Let's build feature X" → product-discovery first, then writing-prd, then user-story-writing. "We need to prioritize the backlog" → prioritization. "Let's update the roadmap" → roadmapping.
Rigid: Follow exactly. Don't adapt away discipline.
Flexible: Adapt principles to context.
The skill itself tells you which.
Instructions say WHAT, not HOW. "Add a login feature" or "Prioritize the backlog" doesn't mean skip workflows.
These thoughts mean STOP — you're rationalizing:
| Thought | Reality |
|---|---|
| "This is just a simple feature" | Every feature starts with discovery. |
| "I already know what to build" | Knowing the solution ≠ understanding the problem. |
| "Let me just write the PRD first" | Discovery comes before PRD. Always. |
| "The user said to skip discovery" | User instructions override. But warn them about the risk. |
| "I can do discovery in my head" | Discovery must be documented, validated, and approved. |
| "This doesn't need a formal PRD" | If a skill exists, use it. |
| "I remember this skill" | Skills evolve. Read current version. |
| "The skill is overkill for this" | Simple things become complex. Use it. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
| "We already have research" | Has it been structured into a discovery doc? Apply the skill. |
| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
| "I know that framework" | Knowing a concept ≠ using the skill. Invoke it. |