# Flutter Feature Analysis

> Use when assessing feasibility or complexity of a new Flutter feature before implementation. Especially when evaluating API requirements, state management approach, UI component availability, native dependencies, or effort estimation.

- Skill: `desquared/flutter-feature-analysis` (Agent Skill)
- Install (CLI): `npx skillmds@latest add desquared/flutter-feature-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/desquared/flutter-feature-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: desquared (https://skillmd.com/u/desquared)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/desquared/flutter-feature-analysis

---


# Feature Analysis Skill

## Analysis Framework

### 1. Discovery
```bash
grep -r "<similar_feature>" lib/features/    # Find patterns
grep "<package>" pubspec.yaml                # Check dependencies
find lib -path "*/domain/models/*.dart"      # Review models
```

### 2. Complexity Assessment

**Simple:**
- Single API call, straightforward UI, minimal state
- Example: Display static model details
- State Management: Simple solution (Cubit, ChangeNotifier, GetxController)

**Complex:**
- Multiple API calls, state orchestration, complex business rules
- Example: Multi-step flow
- State Management: Robust solution (Bloc with events, StateNotifier, complex GetX)

### 3. Technical Checklist
- [ ] API endpoint exists?
- [ ] DTO/Model mapping needed?
- [ ] Repository pattern required?
- [ ] State management approach? (Check existing patterns in project)
- [ ] UI components available in design system?
- [ ] Native platform features needed?
- [ ] Accessibility considerations?
- [ ] Performance implications?

### 4. Dependencies
- Check `pubspec.yaml` for existing vs new packages
- Check native side: `plugin/ios/`, `plugin/android/`

### 5. Output Format
```markdown
# Feature Analysis: [Name]

## Feasibility: ✅ / ⚠️ / ❌

##State Management**: [Based on project patterns: Bloc/Provider/GetX/Riverpod]
**Rationale**: [Why this approach fits]

## Technical Requirements
- API: [endpoint]
- New Models: [list]
- UI Components: [available/needed]
- Native Features: [yes/no]
- State Management: [Match existing patternse/needed]
- Native Features: [yes/no]

## Dependencies
- Existing: [packages]
- New: [packages]

## Risks
1. [Risk]
2. [Risk]

## Estimated Effort
- Development: X hours
- Testing: Y hours
```