---
name: plan-features
description: Interviews the user about an app feature, then writes an implementation-ready design doc for another agent to execute. Use when you need upfront clarification and a file-based feature implementation plan.
---

# Plan Features

Create implementation-ready feature plans for app features.

## Goal

Turn a rough product idea and approach into a concrete design doc that another agent can implement with no extra context.

## Workflow

### 1) Intake

Start by asking the user for the feature idea, desired approach, and any known constraints.

### 2) Clarify until confident

Ask concise follow-up questions until the plan is unambiguous enough to implement without more context.

Rules:
- Ask only the questions needed to remove real uncertainty.
- Prefer a few high-signal questions over many low-value ones.
- Keep asking until you can confidently define scope, behavior, and implementation approach.
- Stop once another agent could implement safely without more product discussion.
- Avoid long interview loops; if only minor preferences remain, capture them as assumptions instead of continuing to question.
- If you still need to make an assumption, state it clearly and keep it minimal.
- Do not broaden scope or introduce speculative solutions.
- Do not lock in a technical approach before the problem, scope, and constraints are clear.

Focus questions on:
- the user problem and desired outcome
- exact scope and non-goals
- existing behavior that must change or stay the same
- UX / interaction details
- data, state, API, and persistence implications
- dependencies, constraints, and edge cases
- rollout, migration, and test expectations

### 3) Inspect relevant repository context

Before finalizing the plan, inspect the relevant parts of the repository when doing so will improve accuracy.

Use repository context to:
- confirm existing architecture, naming, and folder structure
- identify likely files, modules, and components to change
- verify whether relevant behavior already exists
- align the plan with established patterns instead of proposing generic solutions

Do not over-research the codebase. Read only what is needed to ground the plan.

### 4) Draft the plan

Once enough context is gathered, write a Markdown implementation plan that stands on its own.

The plan should be:
- concise and direct
- implementation-ready
- specific enough for a new agent to execute without extra discussion
- free of estimates unless explicitly requested
- grounded in relevant repository context when useful
- explicit about what is confirmed, assumed, and still unresolved

If questions remain, distinguish clearly between:
- blocking open questions
- non-blocking open questions
- assumptions that are safe enough to proceed with

### 5) Write the plan to a file

Save the finished plan as a Markdown file in the working directory unless the user gives a different path.

Suggested default:
- `feature-plans/<feature-slug>.md`

If the directory does not exist, create it.

After writing the file, reply with the path and a short summary of what was written.

## Planning template

Use the template in `references/feature-plan-template.md` as the default structure unless the user requests otherwise.

## Quality bar

A good plan:
- clearly states the problem and intended outcome
- defines scope and non-goals
- explains the proposed implementation approach
- identifies affected areas of the codebase
- distinguishes confirmed facts, assumptions, and unresolved questions
- covers dependencies, constraints, edge cases, and failure modes
- includes concrete acceptance criteria and validation/testing steps
- notes risks only when they materially affect implementation or rollout
- avoids over-engineering and unnecessary technical speculation

## If context is missing

If the user has not provided enough detail, keep asking questions before drafting the plan.

Do not guess at major product or implementation details when they can be clarified first.