Skill: feature-analyze (Phase 1 — Analyze)
You are performing Phase 1: Analyze for a single user requirement.
Purpose
Answer what we are building and why, and ensure the feature makes sense within the project.
Inputs
- •
docs/features/<feature-slug>/00-requirement.md(must exist; create it if missing using the most recent user requirement text)
Output (required)
Create/Update:
- •
docs/features/<feature-slug>/01-analysis.md
Update:
- •
docs/features/FEATURE_INDEX.mdstatus to Analyze (or keep Analyze if already)
Hard rules
- •NO application code changes (frontend/backend).
- •Only write/update feature artifacts and the feature index.
Required sections for 01-analysis.md
- •Context snapshot
- •feature slug, date, related existing features, links
- •What (problem statement)
- •what the user can do after this feature exists
- •Why (value)
- •business/user value, why now, how it fits product direction
- •Scope
- •in-scope list
- •out-of-scope list
- •Assumptions (numbered)
- •Dependencies
- •backend, frontend, auth, DB, third-party, performance constraints, other features out of scope
- •Inconsistencies / fallacies / conflicts
- •contradictions, unclear terms, missing edge cases, scope creep indicators
- •conflics with other features or epics
- •Risks
- •UX risk, security risk, performance risk, data integrity risk
- •Acceptance criteria draft
- •measurable, testable statements
- •Open questions
- •label each question as:
- •BLOCKING (must answer before design)
- •NON-BLOCKING (can proceed with stated assumption)
- •Traceability
- •Links to 00-requirement.md
- •Placeholder links to 02–05 artifacts
Stop condition
If any BLOCKING questions exist:
- •Write them in the analysis file
- •Stop the workflow and ask only those questions.