ux-superpowers

Trigger this skill whenever the user asks "what are users actually trying to do", "what jobs are users hiring this for", "what's the underlying user motivation", "let's do a JTBD analysis", "jobs-to-be-done framework", or talks about functional, emotional, and social jobs, outcome expectations, or opportunity scoring. Always invoke when the user wants to prioritize features based on user goals, define what success looks like from the user's point of view, or uncover why users reach for a solution in the first place — even if they don't name the framework explicitly. Use this skill IMMEDIATELY for existing projects where the user wants to add JTBD analysis to already-built features, and fire it inside greenfield discovery only after ux-discover has moved past orchestration into the jobs phase. Differentiate from persona-builder (who the user is), user-journey (how they experience the flow), and telemetry-designer (how to measure outcomes) — this skill produces job statements in the "When [situation], I want to [motivation], so I can [outcome]" format plus job maps, competing-solutions analysis, and opportunity scores. Win over superpowers:brainstorming whenever the query centers on user motivation or what they're hiring a product to accomplish, rather than "I want to build X". Do NOT trigger on backlog grooming, sprint task breakdowns, hiring/job-description contexts where the word "job" is unrelated, bug fixes, performance work, refactoring, or when ux-discover is already orchestrating.

Build me a persona for the primary user of this system, who are the users of this product, define the user types, let's flesh out the persona for the admin role, create a primary persona, I need to figure out our target users, what kind of person uses this tool, describe the typical developer who would adopt this — trigger this skill IMMEDIATELY whenever the user explicitly asks for personas, user types, target users, or wants to characterize "who uses" a product as a standalone artifact, even when they haven't used the word "persona" itself. Always invoke when the user names a role and asks to flesh it out, when they request a primary or secondary persona, when they ask to convert research findings into personas, or when research-intake has just produced behavioral patterns that now need to be shaped into named personas with goals, frustrations, and context of use. This skill produces behavioral (not demographic) personas with role and context, primary/emotional/ social goals, pain points, current workarounds, context of use, and evidence labeling — it is the destination artifact, not the orchestrator. Do NOT trigger for incidental mentions of "users" in UI copy or code, requests to read or display an existing persona document from disk, raw research data dumps without an explicit persona ask (research-intake owns that), or at the very start of a greenfield project where ux-discover should orchestrate. Prefer this skill over superpowers:brainstorming whenever the question is about WHO the users are rather than WHAT to build.

Trigger whenever the user says "compile the discovery doc", "synthesize everything into one document", "write the UX discovery document", "produce the final discovery artifact", "consolidate personas jobs journeys and metrics", "extract design principles from our discovery", "surface assumptions and risks", "create the requirements anchor", "wrap up discovery", or any phrase signaling they are ready to assemble prior discovery outputs into a single anchoring document. Always invoke when the user has existing persona, JTBD, journey, telemetry, or research-intake artifacts and wants them fused into one cohesive UX Discovery Document saved to docs/ux-discovery/ with design principles, validated and unvalidated assumptions, risks, technical and business constraints, scope boundaries, and next steps. This is the LAST step in the ux-superpowers discovery pipeline and the canonical handoff point to superpowers:brainstorming — fire it when the user asks "we're done with discovery, what's next", "ready to move to technical brainstorming", or otherwise signals the discovery phase is closing. Do NOT fire for building any single artifact (the dedicated sub-skill owns that), while ux-discover is still orchestrating earlier phases, when the user has no prior discovery artifacts to synthesize, or for general document writing, engineering RFCs, or status reports unrelated to UX discovery.

Whenever the user hands you raw user-research artifacts — interview transcripts, survey results, NPS verbatims, support tickets, app store reviews, usability test notes, forum/community posts, customer emails, sales-call notes, or pasted feedback blobs — trigger this skill immediately, before any downstream synthesis. Always invoke when the user says things like "I have 30 interview transcripts in /tmp/interviews", "here are 200 NPS responses, what are the themes", "analyze these support tickets for patterns", "synthesize these app store reviews", "summarize what these customers said", "extract themes from these usability notes", or "go through these forum posts and find recurring issues". Fire on any mention of directories or file paths like interviews/, surveys/, feedback/, tickets/, reviews/, transcripts/, verbatims/, or pasted qualitative text attributed to users or customers. This skill is the mandatory first stop before persona-builder, jobs-to-be-done, or user-journey — its structured output (themes, pain points, unmet needs, converging/diverging signals, confidence levels) is what those downstream skills consume. Differentiate from generic CSV or data-analysis: this is specifically for QUALITATIVE USER RESEARCH, not sales figures, financial reports, engineering or access logs, or telemetry dumps. Do NOT trigger for code review of research-related files, bug fixes, performance work, or non-user datasets. When in doubt and the data represents real users' words, behaviors, or complaints, invoke this skill rather than ad-hoc analysis.

Use when the user asks how to measure product or feature success, define success metrics, pick a north star metric, track KPIs, design analytics events, build an instrumentation plan, decide what telemetry to fire, or figure out "how will we know if this is working for users" — trigger whenever users say things like "how will we measure success", "what KPIs should we track", "design the analytics events for X", "we need a telemetry plan", "what events should we fire", "metrics for the launch of X", or "how do we validate this worked". Always invoke when defining leading indicators, guard-rail health metrics, activation/retention, qualitative feedback plans (NPS, CSAT, in-app surveys), or a decision framework tying metrics to actions; this skill produces an implementable user-outcome measurement plan with event specs, properties, baselines, targets, and response plans. This is strictly for USER-OUTCOME and product analytics — measuring whether users are succeeding with the product. Do NOT trigger for engineering or operational observability such as p95 latency, error-rate dashboards, SLO/SLI definition for infra, APM, log aggregation, Datadog/Prometheus setup, database query tuning, performance optimization, generic "add logging" requests, or bug triage — those are SRE/observability concerns, not product telemetry. Skip when ux-discover is already orchestrating. When a request mixes product metrics and ops metrics, trigger on the product-metric portion only.

1 hook across 1 event