---
name: nf
description: >-
  Conduct in-depth feature discovery interview to explore, challenge, and document a new trading feature.
  Use when asked to 'detail a feature', 'explore a new feature', 'feature discovery',
  'interview about feature', or 'spec out a feature'. NOT for quick brainstorming,
  NOT for implementation tasks (use /ct).
argument-hint: "[feature-name]"
user-invocable: true
---

# New Feature Discovery — ETNA_TRADER

## Objective

Conduct a comprehensive interview to fully understand and document a new trading feature using collaborative brainstorming, then create a formal specification. Trading features carry significant business and regulatory implications — challenge assumptions rigorously.

## Guidelines

- **Use `AskUserQuestion` tool for ALL clarifications** — provides interactive options for user to choose from
- **Never assume behavior**: if any behavior is unclear/ambiguous (order routing logic, risk rules, regulatory constraints, error states), you MUST ask
- Ask non-obvious, thought-provoking questions — especially about edge cases in financial workflows
- Actively challenge assumptions; do not be a yes-bot
- Offer alternatives, shortcuts, and "go deeper" paths
- Continue until the feature is fully understood
- Document everything in the specification file

## Workflow

### Platform Skill Gate (MANDATORY when feature touches UI/screens)

**Trigger:** If the feature will create or modify screens, components, grids, or styles in the ACAT frontend.

**MANDATORY steps (do BEFORE writing recommendations in the discovery/spec):**
- Read `.claude/rules/trading-component-patterns.md`
- Explicitly state in the discovery/spec that the rule was read and will be applied
- Extract relevant UI/component rules and record them under a "Skill Compliance" section

### Step 1: Codebase Exploration

Launch 1-3 parallel Explore agents based on feature complexity. Use Task tool in **single message**.

**Agents:**
1. Existing feature code and patterns in `frontend/ACAT/src/` and relevant backend API projects
2. Domain models, contracts, existing repositories: `src/Etna.Trading.Contracts/`, DAL projects (if 2+ agents)
3. Docs, existing tests, DB schema in `db/`, `qa/`, `docs/` (if 3 agents)

Synthesize findings, then proceed to design exploration.

### Step 2: External Research (Optional)

Default: skip for token efficiency.

Run only when:
- User explicitly asks for deeper/strict discovery
- Internal codebase context is insufficient
- Decision depends on external constraints (regulatory, exchange protocols, financial standards)

### Step 3: Design Exploration Phase

With gathered context:
- Ask questions to refine the idea (batch related questions)
- Propose 2-3 different approaches with trade-offs
- Present design incrementally for validation
- Consider ETNA_TRADER architecture constraints:
  - Which layer does this belong to? (Contracts → Services → DAL → API)
  - New service or extend existing? (`IOrderService`, `IPositionService`, etc.)
  - Backend-only, frontend-only, or full stack?
  - Database schema changes? New SSDT objects or alter existing tables?
  - EF or NHibernate for data access in this area?

### Step 4: Challenge & Deep-Dive

After design exploration, run one structured challenge pass:
- Identify assumptions and question each one
- Suggest 2-3 alternative approaches (including a lean/shortcut path)
- Flag potential risks, hidden costs, or complexity traps

**Technical Implementation:**
- Edge cases and failure scenarios specific to trading (partial fills, market closes, order expiry)
- Performance implications (high-frequency order flow, real-time position updates)
- Integration points with existing services (clearing, risk engine, market data feed)
- Security implications (account authorization, order tampering, privilege escalation)
- Concurrency and race conditions (double-click order placement, position race on close)

**Trading Domain Specifics:**
- Order lifecycle: New → Partially Filled → Filled / Cancelled / Rejected
- Position impact: long/short, cost-basis, unrealized P&L
- Account impact: buying power, margin, balance
- Market data dependencies: quotes, depth, halt status
- Regulatory / compliance considerations (e.g., pattern day trader rules, short-sale restrictions)

**Business & Product:**
- Success metrics and how to measure them
- MVP vs future scope boundaries (e.g., just Market orders first, Limit/Stop later)
- Multi-account / multi-user implications

### Step 5: Specification Writing

After design exploration and interview completion:

1. **Read template**: Read `docs/product-docs/templates/discovery-template.md` (if exists), otherwise use standard structure below
2. **Create task directory**: `tasks/task-<date>-[feature-name]/`
3. **Write specification** with at minimum these sections:
   - **Feature Summary**: one-paragraph description
   - **Business Context**: why this feature matters, who uses it
   - **Trading Domain Concepts**: orders/positions/accounts/market-data involved
   - **Acceptance Criteria**: numbered, testable
   - **Architecture Impact**: layers touched, new files/projects, DB changes
   - **Skill Compliance** (if UI): rules from `trading-component-patterns.md` that apply
   - **Open Questions**: unresolved items needing product/business decision
   - **Out of Scope**: explicit exclusions to prevent scope creep
   - **Risks**: technical and business risks
   - Output file: `discovery-[feature-name].md`
4. **Present summary** to user for confirmation

**If design exploration reveals the feature is not viable**: Document reasons in `discovery-[feature-name]-rejected.md` with rationale, and stop here.

## Output

`tasks/task-<date>-[feature-name]/discovery-[feature-name].md`