whats-next

Strategic product direction through persona-based analysis. You identify who actually uses a project — spanning the full range from power users to casual non-technical users — give each persona a voice, surface the gaps they hit, run five product lenses to catch what persona analysis misses, then verify the recommendations are complete before outputting.

After analysis, you offer to action the top pick.

When this skill applies

• "What should I build next for [project]?"
• "What do my users want?" / "What's missing?"
• "Analyze my repos" / "Give me product direction on Y"
• Any pasted user conversations, support emails, reviews, Discord logs

Input gathering

Accept whatever the user gives you: GitHub repo names / URLs / local paths / plain descriptions / pasted user conversations / combinations.

If the user gives you nothing specific, ask: "Which project or projects? Or should I look at your GitHub profile as a whole?"

If the user pastes raw user conversations: treat as primary signal — outranks everything else. See references/external-signals.md → "User signal injection."

Confirmation gate — mandatory before any analysis

Before collecting any signal, state what you're about to analyze and ask the user to confirm. Do not skip this even if the target seems obvious.

Format:

Analyzing: <what you understood — repo name, skill path, or description> Mode: Standard / Skill-as-project / Portfolio Correct? I'll start once you confirm.

Wait for confirmation. If the user corrects you, update your understanding and confirm again before proceeding.

Phase 1 — Signal collection

First: detect project type. This is a mandatory gate — run it before any other command.

Step 1a — Filesystem check (local paths only):

ls <given-path>/SKILL.md 2>/dev/null

If the file exists → this is a skill. Stop. Do not continue to Step 1b or signal collection.

Step 1b — Name/description check: If the input mentions "a skill I built", "a Claude Code skill", a skill name matching the available skills list, or a path that describes a skill — this is a skill. Stop.

If either check triggers: Read references/skill-mode.md in full. Do not run gh commands. Do not collect signals. Do not form personas. Follow skill-mode.md's signal collection path entirely.

Required output gate — must appear before Phase 2 begins:

> Mode: Skill-as-project (skill-mode.md loaded)

If this line is absent from your output, you have not followed the detection path. Do not proceed to persona identification without it.

If neither check triggers, proceed with standard signal collection:

For everything else, collect from four sources in parallel:

Source A — Repo data:

gh repo view <owner/repo> --json name,description,stargazerCount,forkCount,topics,primaryLanguage,readme
gh issue list --repo <owner/repo> --limit 50 --json title,labels,comments,state
gh pr list --repo <owner/repo> --limit 20 --json title,body,state
gh release list --repo <owner/repo> --limit 10

CHANGELOG bugs are especially valuable — a locale bug means real users in that locale; a 50MB import fix means someone hit it.

Source B — External conversations: What people say outside the repo (HN, Reddit, web). See references/external-signals.md. These are the users who didn't care enough to file an issue — often the most representative.

Source C — Competitor landscape: What alternatives exist and how users compare them. Required before writing elevation moves. See references/competitors.md.

Source D — Memory: Check ~/.claude/skills/whats-next-workspace/snapshots/ for a previous run. If found, read the full snapshot file — it is the baseline for the diff. Note the date in the signal header: "previous run from DATE (N days ago)". See references/memory.md for diff format.

Low-signal mode: When signal quality is Low, do not just label and proceed. Execute the Low Signal Protocol:

1. Label the quality — Signal quality: Low in the signal header.
2. Mark personas — tag all inferred personas as [Hypothesis].
3. Generate a validation block — append this section at the END of the output:

## Low Signal — Gather Before Re-Running

Signal quality is Low. The analysis above is hypothesis-based. To get higher-signal output, collect the following before re-running:

**3 validation questions to ask your users / community:**
1. [Domain-specific — e.g. for dev tools: "What made you try this instead of [most obvious alternative]?"]
2. [Gap-targeting — "What's the first thing you'd remove or change if you had 30 minutes?"]
3. [Adoption — "What almost stopped you from trying this?"]

**Signals to gather:**
- [ ] Any GitHub issues (even 1 is more than none)
- [ ] Any HN / Reddit / Discord mentions of the project name or category
- [ ] Any support emails or DMs from users
- [ ] A published GitHub repo (if local-only today)

Tailor the 3 questions to the project domain. Don't generate generic questions.

Phase 2 — Persona identification

Always span most technical → least technical. The non-technical user is the most overlooked.

Archetypes (adapt — don't force):

1. Power user / developer
2. Practitioner — serious use, not a developer
3. Evaluator — hasn't committed yet
4. Casual / non-technical user
5. Team deployer — installs it for others

Ask: who is the least technical person who could plausibly benefit? That persona belongs in the set.

Avoid overlap. Each persona must drive at least one different recommendation. Weight by signal volume — 40 HN comments > 1 GitHub issue; reflect this in confidence.

Anti-overlap test: Before finalizing, ask: "If I merged Persona A and Persona B into one card, would any layer item disappear?" If no — merge them and build a genuinely distinct persona instead. Two technical users with different feature requests are still the same persona if their underlying gaps are the same.

Specificity floor: Each persona's "Their context" must include at least one concrete lifestyle detail (not just a job title). Bad: "a developer who wants AI in their workflow." Good: "a developer who has Claude open in a browser tab all day and copies message text into it 10+ times before noon."

For each persona:

### [Persona Name] — [One-line role]
**Evidence:** [source + what it shows — must cite a specific signal, not "plausible" or "assumed"]
**Their context:** [goal + constraints + one concrete daily-life detail]
**Gap they hit:** [specific blocker costing them today — not a wish list item]
**What they'd demand next:** [concrete feature]

Gap ≠ demand. Gap is what's wrong now. Demand is what they want built. They're often at different levels of specificity.

Evidence requirement: If a persona has no signal support (no issue, no commit message, no HN comment, no release title pointing to this user type), mark it explicitly as [Hypothesis] and lower its weight in layer prioritization.

Pre-launch persona construction: For WIP / unreleased apps with no user data, the non-technical and evaluator personas cannot be grounded in usage evidence. Instead, ground them in launch audience characteristics: What audience is the Product Hunt / launch channel submission targeting? Who shares this type of app on Twitter/Reddit? What are the top App Store reviews for the nearest comparable? Use these as evidence sources when in-app signal is unavailable.

Phase 2.5 — Five product lenses (pre-synthesis)

Before writing the layers, run these five questions. They surface recommendations that persona gaps miss — a happy power user has no gap, but there may still be a promise gap or adjacency move worth surfacing.

Work through each fully — do not skip a lens. Each must produce at least one finding, even if it's "lens confirms gap already captured by Persona X." If a lens produces nothing, state why explicitly (it becomes "What we set aside" mate