arn-spark-discover

Arness Discover

Guide a greenfield product idea from raw concept to structured product vision through iterative conversation, aided by product thinking from the arn-spark-product-strategist agent, competitive landscape research from arn-spark-market-researcher, and persona generation from arn-spark-persona-architect (greenfield agents in this plugin). This is a conversational skill that runs in normal conversation (NOT plan mode). The primary artifact is a product concept document written to the project's vision directory.

This skill covers the WHAT and WHY of the product, including the product pillars -- non-negotiable qualities that define the product's soul and guide all downstream decisions. Technology choices and system design are handled separately by /arn-spark-arch-vision.

Step 0: Ensure Configuration (Non-Blocking)

Read ${CLAUDE_PLUGIN_ROOT}/skills/arn-spark-ensure-config/references/step-0-fast-path.md and follow its instructions. This captures the user profile and configures ## Arness with Arness Spark fields.

Important: This skill is designed for exploratory use before a project may fully exist. If ensure-config encounters errors (e.g., no git repository, CLAUDE.md cannot be created), proceed anyway using fallback defaults: Vision directory = .arness/vision, Reports directory = .arness/reports. Do not hard-block.

After Step 0 completes (or falls back), determine the output directory:

1. Read the project's CLAUDE.md and check for a ## Arness section
2. If found, extract the configured Vision directory path — this is the source of truth
3. If NOT found (ensure-config fell back), use .arness/vision at the project root.
4. If the output directory does not exist, create it

Workflow

Step 1: Capture the Raw Idea

Accept the user's product idea in any form -- a single sentence, a paragraph, or a detailed description. If the idea was included in the trigger message, use it directly. If not, ask:

"What product or tool do you want to build? Describe it in whatever detail you have -- even a rough idea is a good starting point."

After receiving the idea, acknowledge with a brief restatement (2-3 sentences) to confirm understanding. Do not add interpretation or assumptions beyond what the user stated.

Step 2: Initial Analysis with Product Strategist

Invoke the arn-spark-product-strategist agent via the Task tool, passing the model from .arness/agent-models/spark.md as the model parameter (see plugins/arn-spark/skills/arn-spark-ensure-config/references/ensure-config.md "Dispatch convention" for fallback). Context:

• The user's raw idea description
• Any context from the conversation so far

The agent returns:

• A vision sketch (initial attempt at a vision statement)
• An assessment of what is clear and what is missing
• 3-5 probing questions organized by priority category
• Scope observations (what looks essential, what could be deferred)

Present the agent's findings to the user as a conversation starter. Frame it as: "Here is my initial read on your idea, with some questions to explore." Do NOT present it as a finished analysis.

Step 3: Guided Discovery Conversation (Iterative)

Enter a conversation loop. The goal is to cover eleven discovery categories, but do so through natural conversation -- not as a sequential questionnaire.

Load the discovery question bank for reference:

Read ${CLAUDE_PLUGIN_ROOT}/skills/arn-spark-discover/references/discovery-questions.md

Use the product strategist's output from Step 2 to drive the conversation. Start with the categories the agent flagged as weakest. Cover these categories through the conversation (not necessarily in order — the numbering and ordering here differs intentionally from the question bank and template, which are optimized for different purposes):

1. Vision & Problem -- what and why
2. Target Users & Personas -- who and when (AI-generated personas for validation)
3. Core Experience -- the primary interaction
4. Product Pillars -- the non-negotiable qualities that define the product's soul
5. Trust & Security Model -- how users establish trust
6. Platform & Constraints -- where and what limits
7. Participants & Scale -- how many, what topology
8. Scope Boundaries -- what is NOT v1
9. Business Model & Constraints -- revenue model, tenancy, compliance, cost limits
10. Competitive Landscape -- alternatives, market positioning (AI-researched)
11. Assumptions & Success Criteria -- validated hypotheses, measurable outcomes (AI-derived)

Product Pillars deserve special attention. Unlike the other categories which capture facts and decisions, pillars capture convictions. Listen for strong language throughout the conversation -- phrases like "it HAS to feel...", "the whole point is...", "I refuse to compromise on..." are pillar signals. When you hear them, name the pillar back to the user: "It sounds like [quality] is non-negotiable for you -- would you call that a core pillar of this product?" Collect pillars as they emerge naturally rather than asking for them all at once.

AI Assist Checkpoints

Product type signal: Early in the conversation (during Step 2 initial analysis or first rounds of Step 3), establish whether this is a commercial product (targeting a market/customers) or an internal tool / personal utility (for a team, personal use, or internal workflow). If ambiguous from the description, ask naturally: "Is this something you're building for customers, or more of an internal tool / personal utility?" Record the answer -- it affects framing of Checkpoints C and D, but NOT the depth of persona work (Checkpoint B is always full depth because personas feed downstream simulation skills regardless of product type).

Checkpoint A -- Problem Statement Draft (after vision is clear, rounds 1-3):

• Synthesize a crisp problem statement from the conversation (who/what/why/workarounds/severity)
• Present to user: "Based on what you've described, here's a draft problem statement. Does this capture it?"
• User validates/refines. No extra agent needed -- the skill does this directly from conversation context.

Checkpoint B -- Persona Generation (when target users discussed, rounds 2-4):

This is a two-phase process: concrete examples first (for user interaction), then abstracted moulds (for reuse).

1. Ask user to describe target users in their own words
2. Assess what the user provides:
3. Vague description (e.g., "developers who want to ship faster"):

Ask (using AskUserQuestion):

> I can generate concrete persona examples based on what you've described -- specific people you can picture and critique. Would you like me to draft those? > 1. Yes — Generate persona examples for review > 2. No — Skip persona generation, continue with what we have

• Concrete names/roles (e.g., "Bob is a PM who cares about velocity, Julie is a dev who hates context switching"):

Ask (using AskUserQuestion):

> I can expand those into full profiles with personality traits, pain points, and day-in-the-life scenarios. Want me to research and draft those? > 1. Yes — Expand into full persona profiles > 2. No — Keep as-is and continue

1. If agreed, invoke the arn-spark-persona-architect agent in discovery mode via the Task tool, passing the model from .arness/agent-models/spark.md as the model parameter (see plugins/arn-spark/skills/arn-spark-ensure-config/references/ensure-config.md "Dispatch convention" for fallback). Context: product vision, problem statement, user description (vague or concrete seeds), product pillars so far. The agent handles both cases -- generating from scratch or expanding user-provided specifics.
2. Phase 1 -- Concrete examples: Present the generated/expanded concrete personas (including personality traits): "Here are some specific people who would use this