---
name: nf
description: >-
  Runs an in-depth feature-discovery interview that explores, challenges, and
  documents a new feature before planning. Use when asked to 'detail a feature',
  'explore a new feature', 'feature discovery', 'interview about feature', 'spec
  out a feature', 'design a feature', 'think through a feature', 'deep dive on a
  feature', 'discover [feature-name]', or 'what should we consider for
  [feature]'. NOT for quick brainstorming (/brainstorm), PRD/JTBD docs
  (/product), or implementation tasks (/ct).
argument-hint: [feature-description]
allowed-tools: Read, Write, Edit, Grep, Glob, AskUserQuestion, Task, Skill
---

# New Feature Discovery

> **Announcement**: Begin with: "I'm using the **nf** skill for feature discovery."

## Quick start
`/nf add streak freeze` → interview (design exploration → deep-dive → grill → validate) →
`tasks/task-YYYY-MM-DD-streak-freeze/discovery-streak-freeze.md` → next: `/vp` or `/ct`.

## Objective
Turn a rough feature idea into a clear, standalone discovery document — the entry point for
anyone who later visualizes (`/vp`), plans (`/ct`), or implements (`/si`) the feature.

## Guidelines
- Use `AskUserQuestion` for any unresolved clarification — structured options keep the interview auditable.
- If behavior is unclear (UX flow, edge cases, error handling, states), ask the user to define it rather than inferring — downstream `/vp` and `/ct` trust this doc as source of truth, so silent assumptions compound.
- Ask non-obvious, thought-provoking questions; challenge confident-but-underspecified answers by naming the gap ("You said X — does that cover case Y?").
- Offer alternatives, shortcuts, and "go deeper" paths. Continue until the feature is fully understood.
- Keep the discovery template in mind throughout — gather exactly what's needed to fill it clearly.

**Context management.** This workflow runs long. On a compaction / context refresh: re-read already-created task files and the discovery template, then resume from the last unanswered section — do not restart. Don't stop early over token-budget worries; the parent harness handles compaction.

## Workflow

### Argument Validation
If no `[feature-description]` is provided, `AskUserQuestion`: "What feature would you like to explore?" (include a free-text option). Derive the feature-name slug from the answer.

### Step 0 — Load Output Shape & Upstream Context
Read `.claude/docs/templates/discovery-template.md` first — it is the **output contract** (defines what the final doc contains). Don't duplicate its structure here; use the template as the source of truth for final shape.
Then load, if present:
- `docs/product-docs/PRD/PRD-*[feature-name]*.md` and `docs/product-docs/JTBD/JTBD-*[feature-name]*.md` — product-level "what & why"; reference them in the discovery doc.
- `docs/product-docs/UBIQUITOUS_LANGUAGE.md` — use its terms verbatim; flag conflicts with user wording immediately. If missing or new terms surface, plan to invoke `/ubiquitous-language` at the Step 4 → 5 transition.

### Step 1 — Context Gathering & Design Exploration
Invoke the `design-exploration` skill to ground discovery in the real codebase. Ask it for: key codebase findings & current fit, viable design directions, constraints, and risk flags. Prefer fit / options / constraints / risks over implementation decomposition.
**Checkpoint** — `AskUserQuestion`: "Does this direction look right?" → "Continue with this approach" / "Explore a different direction" / "I have corrections".

### Step 2 — External Research (if needed)
- **Quick lookups**: Exa MCP when the user asserts an external factual claim you can't verify from the codebase or prior turns. Skip for internal behavior (design-exploration covers it) or subjective preference.
- **In-depth**: spawn `comprehensive-researcher` only when the answer materially affects direction, scope, key requirements, or constraints. Ask for a concise **decision memo** (findings, implications for shape/scope, risks, unresolved unknowns) — not a broad report.

### Step 3 — Deep-Dive Questions
Drive the conversation toward the template sections with **non-obvious** questions. **Read `references/interview-guide.md` now** — it holds the full question bank (Overview, Usage Context, Chosen Direction, How It Works, Scope, Requirements, and Post-Action / Cross-Surface behavior).
Stop when every template section has an answer the user confirmed once — don't re-confirm. For sections that need speculation, ask once, accept "skip / TBD", and note as `[NEEDS CLARIFICATION: ...]`. The draft needn't be perfect before writing — the grill round catches real gaps.

### Step 4 — "Grill Me" Challenge Round
Invoke the `/grill-me` skill to pressure-test design and clarity. Before invoking, summarize: feature name/description, why it exists, chosen direction, how it works, in / out scope, key requirements, known risks.
After grilling: incorporate findings; tighten wording, scope boundaries, hidden assumptions, missing states / edge cases.
**Update glossary** (before writing): if new terms, synonym conflicts, or sharpened terms surfaced, invoke `/ubiquitous-language` to update `docs/product-docs/UBIQUITOUS_LANGUAGE.md` so downstream `/vp`, `/ct`, `/si` inherit the vocabulary.
**Checkpoint** — `AskUserQuestion`: "Proceed to discovery document" / "Revisit design based on findings" / "Cut scope based on grill findings".

### Completion Check
One pass (not a loop): verify each has a ≥ 1-sentence answer — what is it? why exist? how works? in scope? out of scope? what constraints shape it? If ≤ 2 are weak, flag inline and proceed (grill + cross-AI catch blockers). If > 2 missing, run one more question round, then proceed regardless.

### Step 5 — Discovery Document Writing
1. Re-read `.claude/docs/templates/discovery-template.md` (long interviews drift; re-reading prevents section/heading mismatches that `/vp` and `/ct` parsers depend on).
2. Create `tasks/task-YYYY-MM-DD-[feature-name]/` and write `discovery-[feature-name].md` by filling the template with resolved decisions, flows, scope, requirements, and constraints. (Writing the file creates the task directory.)
3. If any required section can't be filled clearly, continue discovery instead of finalizing.
4. Present a summary for confirmation.

### Step 6 — Cross-AI Validation
Run cross-AI validation per `.claude/docs/templates/cross-ai-protocol.md` — it is the single source of truth for the **configured validator set**, availability fallback, comparison table, and verdict format. Initialize each validator's CLI skill **sequentially first** (they mutate runtime state), then **dispatch all reviews in parallel** in a single turn.
- **FOCUS**: review as senior product analyst — entry-point readability, completeness, consistency, flow clarity, scope boundaries, feasibility, and hidden ambiguities that would confuse `/vp` or `/ct`.
- **FILE_REFS**: `discovery-[feature-name].md` + relevant codebase paths.
- **OUTPUT**: append "Cross-AI Validation: PASSED/FAILED" with consolidated verdict.

On failure → `AskUserQuestion`: "Revise discovery doc" / "Override and proceed" / "Abandon feature". **Skip** if no CLI available or the user opts out.

## Output
`tasks/task-YYYY-MM-DD-[feature-name]/discovery-[feature-name].md`

## Handoff — Next Steps
```
Discovery complete for [feature-name]:
- Document: tasks/task-YYYY-MM-DD-[feature-name]/discovery-[feature-name].md

Next steps:
→ Visualize the design: /vp [feature-name]
→ Skip to tech planning: /ct [feature-name]
```