/arn-spark-feature-extract

name: arn-spark-feature-extract
description: >-
  This skill should be used when the user says "feature extract",
  "arn feature extract", "extract features", "feature backlog",
  "create backlog", "list features", "what features do we need",
  "prioritize features", "feature list", "build the backlog",
  "what should we build", "upload features", "feature tracker",
  or wants to extract a structured, prioritized feature list with
  journey steps, validated components, use case context, and UI
  behavior details from all project artifacts, producing a feature
  backlog document with a Feature Tracker that bridges into
  arn-code-feature-spec and optionally uploads features to the issue tracker.
version: 3.0.0

Arness Feature Extract

Extract a structured, prioritized feature backlog from all available project artifacts through guided conversation, aided by the `arn-spark-product-strategist` and `arn-spark-ux-specialist` agents (greenfield agents in this plugin) for feature analysis, prioritization, and UX flow analysis. This is a conversational skill that runs in normal conversation (NOT plan mode). The primary artifact is a **feature backlog document** that feeds into `arn-code-feature-spec`.

This skill bridges the greenfield pipeline into Arness's existing development pipeline. It takes all upstream artifacts -- product concept, architecture vision, spike results, style brief, static prototype validation (including showcase and debate reports), clickable prototype validation (including showcase, screen manifest, and debate reports), use cases (including postconditions, business rules, and debate reports), and visual grounding assets -- and distills them into a prioritized list of features with a local Feature Tracker for dependency management.

Each feature carries lean context (description, journey summary, UI behavior unique to the feature, validated components, use case references, debate insights, technical notes, acceptance criteria) with references to upstream UC documents. `arn-code-feature-spec` expands these references at spec time by reading the referenced UC documents directly.

Optionally, features can be uploaded as issues to the configured issue tracker (GitHub or Jira) for team visibility and tracking.

Prerequisites

At minimum, a product concept document should exist. Check in order:

1. Read the project's `CLAUDE.md` for a `## Arness` section. If found, check the configured Vision directory for `product-concept.md` 2. If no `## Arness` section found, check `.arness/vision/product-concept.md` at the project root

**If a product concept is found:** Read it as the primary source for feature extraction.

**If no product concept is found:** Ask the user: "No product concept found. I can extract features from your description of the product. What are the main things users should be able to do?"

Read the configured directories from the `## Arness` section (use defaults if no config found):

• **Use cases directory** (default: `.arness/use-cases`)
• **Prototypes directory** (default: `.arness/prototypes`)
• **Vision directory** for the output (default: `.arness/vision`)
• **Visual grounding directory** (default: `.arness/visual-grounding`)

If no `## Arness` section exists or Arness Spark fields are missing, inform the user: "Arness Spark is not configured for this project yet. Run `/arn-brainstorming` to get started — it will set everything up automatically." Do not proceed without it.

> All references to `use-cases/`, `prototypes/`, and `visual-grounding/` in this skill refer to the configured directories determined above.

Also check for and load (if available):

• `[use-cases-dir]/README.md` and `[use-cases-dir]/UC-*.md` -- for structured behavioral specs with actor goals, main success scenarios, alternate flows, business rules, and postconditions that map directly to features
• `[use-cases-dir]/reviews/` -- for debate reports from `arn-spark-use-cases-teams` (consensus findings, business rule discovery, scope concerns, missing elements)
• `architecture-vision.md` (in Vision directory) -- for technical capabilities and platform features
• `spike-results.md` (in Vision directory) -- for validated/failed risks that affect feature scope, validated capabilities, and known limitations
• `style-brief.md` (in Vision directory) -- for UI patterns, visual tokens, and component style that imply features
• `dev-setup.md` (in Vision directory) -- for environment constraints that may affect feature scope
• `[prototypes-dir]/static/final-report.md` -- for validated visual components and their review scores
• `[prototypes-dir]/static/v[N]/showcase/showcase-index.md` -- for per-component visual captures with scores (scan for the latest version directory)
• `[prototypes-dir]/static/v[N]/showcase-manifest.json` -- for the component section list (maps library components to showcase sections)
• `[prototypes-dir]/static/reviews/` -- for debate reports from `arn-spark-static-prototype-teams` (expert scoring, consensus, divergence on visual fidelity)
• `[prototypes-dir]/clickable/final-report.md` -- for validated user journeys, interaction test results, and journey screenshots
• `[prototypes-dir]/clickable/v[N]/showcase/showcase-index.md` -- for per-screen visual captures with journey mapping (scan for the latest version directory)
• `[prototypes-dir]/clickable/v[N]/screen-manifest.json` -- for the canonical screen list with routes and functional areas
• `[prototypes-dir]/clickable/reviews/` -- for debate reports from `arn-spark-clickable-prototype-teams` (expert scoring, journey agreement, interaction quality debate)
• `[prototypes-dir]/criteria.md` -- for agreed validation criteria
• Prototype screens: scan `[prototypes-dir]/clickable/` for versioned prototype app directories. Also check the project's screen/view directories (the location depends on the framework -- look at the project structure) -- each screen suggests features
• User journey definitions from the clickable prot