discover

/discover — vague intent → framed problem → one chosen direction

Goal: serve the altitude above /harness-claude:spec. The pipeline's front door assumes you can already state what you want — /harness-claude:spec sharpens a known request, /harness-claude:research is reuse-first on a known problem, /harness-claude:design does UX for an already-chosen feature. /harness-claude:discover is for the step before all of them: a vague itch where you don't know the shape of the answer. It is a divergent→convergent move — open up the space of what could be done, then close it to one direction /harness-claude:spec can consume.

Opt-in & conditional. Invoked explicitly; nothing auto-routes here. If the request is already clear enough to spec, this skill says so and steps aside (see step 0) — no ceremony. Git boundary: /harness-claude:discover is read-only — it never commits, pushes, or branches.

When /harness-claude:discover, when /harness-claude:spec

• /harness-claude:discover — you want something but can't yet state what: the goal is fuzzy, the options are unknown, or you're asking "what would make the best use of X?". It produces the request.
• /harness-claude:spec — you can already state the request; you need it sharpened into testable acceptance criteria. If you're here, skip /harness-claude:discover.

It is strictly upstream of /harness-claude:spec, /harness-claude:research, and /harness-claude:design — it never duplicates them. It frames the problem and picks a direction; it leans on /harness-claude:research for any heavy feasibility search and hands the chosen direction to /harness-claude:spec for criteria.

How it works

[0] spec-ready?  →  [1] interrogate  →  [2] map ≤5 options  →  [3] CONVERGE to one  →  hand to /spec
        └─ if already clear: say so, route straight to /spec (no interview)

Do this

1. Spec-ready check first (anti-ceremony). Before any interview, assess whether the request is already clear enough to spec: is the goal stated, the scope bounded, the "done" recognizable? Use the concrete test — if fewer than 3 critical unknowns (goal, target user/surface, scope boundary, success signal, hard constraints) are missing, it's spec-ready: say so and route straight to /harness-claude:spec without running the interview. Only genuinely vague intent proceeds. (AC-4)
2. Interrogate the real goal (Socratic). Surface the underlying goal/pain/constraint behind the vague ask — ask focused questions via AskUserQuestion (group them; offer concrete options, not open-ended prose). If AskUserQuestion is unavailable, ask the same questions inline. Do not invent a direction and run with it unilaterally — pull the intent out first. (AC-5)
3. Map the opportunity space — bounded. If step 1's answer is still a category (e.g. "novel," "make it better") rather than a direction, do not ask the user to sub-categorize it in the abstract — that fails. A vague intent means they have no pre-formed sub-axis to name; offering abstract "flavors" to choose between gets "none of these fit" (lived failure mode). Instead ground first, then show concrete: do the light mgrep / codebase pass now, then put the candidate directions in front of them as concrete things to react to — people recognize the right direction when they see it far more reliably than they can synthesize it from axes. Generate at most 5 candidates, each one line: what it is, who it serves, rough value-vs-effort, grounded in feasibility and fit (what the project already has) — not pure speculation. Defer any heavy reuse search to /harness-claude:research; this is a quick reality check, not the full hunt. Never dump an unbounded list. (AC-1, AC-7)
4. CONVERGE — pick exactly one (the non-negotiable step). End with one recommended direction + a one-line rationale. A runner-up shortlist is allowed, but the recommendation is singular and explicit. The terminal output is a decision, not a catalog — ending with "here are some options" and no pick is an invalid exit and a failure of this skill. When the choice is genuinely the user's to make, present the ranked options via AskUserQuestion and converge on their answer — but still exit with one chosen direction, never a tie. (AC-2, AC-3)
5. Hand off to /harness-claude:spec — and stop. Emit a tight intent statement (one screen): the framed problem, the one chosen direction, and the key constraints surfaced. This is what /harness-claude:spec restates into acceptance criteria. Do NOT write acceptance criteria here — that is /harness-claude:spec's job; producing them blurs the seam. /harness-claude:spec should be able to pick up the intent statement without re-interrogating from scratch. (AC-6, AC-8)