flutter-brainstorming

Flutter の機能をブレインストーミングして設計する

概要

自然な対話を通じて、アイデアを具体的な Flutter の設計と仕様にまとめるのを支援します。

まず、現在のプロジェクトのコンテキスト（pubspec.yaml、lib/ の構成、既存の機能）を把握し、次に一度に1つずつ質問してアイデアを掘り下げます。何を作るのかを理解したら、設計を200～300語の小さなセクションに分けて提示し、各セクションの後に、ここまでの内容で問題ないか確認します。

開始時に伝えること：「flutter-brainstorming スキルを使って、この機能を設計します。」

プロセス

フェーズ 1：アイデアを理解する

まずプロジェクトのコンテキストを確認します：

# Check pubspec.yaml for dependencies
cat pubspec.yaml

# Check existing lib/ structure
ls -la lib/

# Check existing features
ls -la lib/features/ 2>/dev/null || echo "No features folder yet"

一度に1つずつ質問します：

• 可能な場合は選択式の質問を優先します
• 1回のメッセージにつき質問は1つだけにします
• 目的、制約、成功基準の理解に集中します

検討する主な質問：

1. この機能は、どのようなユーザーの問題を解決しますか？
2. この機能にはどのようなデータが必要ですか？
3. どのような UI 操作が必要ですか？
4. どのような状態を管理する必要がありますか？
5. 外部依存関係（API、データベース）はありますか？

フェーズ 2：アプローチを検討する

トレードオフとともに、異なるアプローチを2～3個提案します：

状態管理の例：

Approach A: Riverpod + Freezed (Recommended for new projects)
- Pros: Compile-time safety, immutable states, no boilerplate with codegen
- Cons: Learning curve, requires build_runner
- Best for: Most Flutter projects

Approach B: BLoC Pattern
- Pros: Separation of concerns, testable, scalable
- Cons: More boilerplate
- Best for: Complex state, multiple streams, large teams

Approach C: Provider + ChangeNotifier
- Pros: Simple, familiar
- Cons: Less structured, harder to test
- Best for: Simple local state, small projects

Riverpod + Freezed パターンの例：

// State with freezed (3.x: union classes must be sealed; use Dart 3
// switch patterns instead of the removed .when()/.map())
@freezed
sealed class AuthState with _$AuthState {
  const factory AuthState.initial() = AuthInitial;
  const factory AuthState.loading() = AuthLoading;
  const factory AuthState.authenticated(User user) = AuthAuthenticated;
  const factory AuthState.error(String message) = AuthError;
}

// Notifier with riverpod_generator
@riverpod
class Auth extends _$Auth {
  @override
  AuthState build() => const AuthState.initial();

  Future<void> login(String email, String password) async {
    state = const AuthState.loading();
    try {
      final user = await ref.read(authRepositoryProvider).login(email, password);
      state = AuthState.authenticated(user);
    } catch (e) {
      state = AuthState.error(e.toString());
    }
  }
}

推奨案を最初に示し、その理由を説明します。

フェーズ 3：設計を提示する

設計を200～300語のセクションに分けて提示します：

1. 機能の概要

   • 目的と範囲
   • ユーザーストーリー

2. クリーンアーキテクチャの構成

   lib/features/<feature_name>/
   ├── domain/
   │   ├── entities/          # Business objects
   │   ├── repositories/      # Repository interfaces
   │   └── usecases/          # Business logic
   ├── data/
   │   ├── models/            # DTOs (fromJson, toJson)
   │   ├── datasources/       # Remote & Local data sources
   │   └── repositories/      # Repository implementations
   └── presentation/
       ├── bloc/ or provider/ # State management
       ├── widgets/           # Reusable UI components
       └── screens/           # Full screen widgets
   

3. データフロー

   • API コントラクト（該当する場合）
   • ローカルストレージのスキーマ（該当する場合）
   • 状態遷移

4. UI/UX 設計

   • ウィジェット階層
   • ナビゲーションフロー
   • エラー状態

5. テスト戦略（優先度順）

   • 優先度1：Repository、DataSource のユニットテスト
   • 優先度2：状態管理（BLoC/Provider）のユニットテスト
   • 優先度3：ウィジェットテスト（任意）
   • 優先度4：ゴールデンテスト（任意、ビジュアルリグレッション）

各セクションの後に質問します：「ここまでの内容で問題ありませんか？」

設計後

ドキュメント

検証済みの設計を次の場所に書き込みます：

docs/plans/YYYY-MM-DD-<feature>-design.md

設計ドキュメントのテンプレート：

# <Feature Name> Design

## Overview
[1-2 sentences describing the feature]

## User Stories
- As a user, I want to...

## Clean Architecture

### Domain Layer
- Entities: [list]
- UseCases: [list]
- Repository interfaces: [list]

### Data Layer
- Models: [list]
- DataSources: [list]
- Repository implementations: [list]

### Presentation Layer
- State Management: [BLoC/Provider/Riverpod]
- Screens: [list]
- Widgets: [list]

## Data Flow
[Diagram or description]

## API Contract
[If applicable]

## Testing Plan
- Unit tests: [list]
- Widget tests: [list]
- Integration tests: [if needed]

## Dependencies
[New packages needed in pubspec.yaml]

設計ドキュメントを Git にコミットします：

git add docs/plans/
git commit -m "docs: add <feature> design document"

実装（続行する場合）

**「実装計画を作成しますか？」**と質問します。

はいの場合：

• 詳細な実装計画の作成には flutter-craft:flutter-planning を使用します
• 分離されたワークスペースが必要な場合は flutter-craft:flutter-worktrees を使用します

必須のサブスキル

ブレインストーミングを完了し、設計をドキュメント化した後、必ず以下を呼び出してください： → Skill ツール：flutter-craft:flutter-planning

これは任意ではありません。詳細な実装計画がなければ、ワークフローは完了していません。

主な原則

• 一度に質問は1つだけ - 複数の質問で圧倒しないでください
• 選択式を優先 - 自由回答より答えやすくなります
• 常にクリーンアーキテクチャを採用 - Domain → Data → Presentation のレイヤー順
• YAGNI を徹底する - すべての設計から不要な機能を取り除きます
• 代替案を検討する - 絞り込む前に、必ず2～3個のアプローチを提案します
• 段階的に検証する - 設計をセクションごとに提示し、それぞれを検証します
• テストの優先順位 - Repository/DataSource → State → Widget

注意すべき兆候

次のような理由でブレインストーミングを決して省略しないでください：

• 「単純なウィジェットにすぎない」→ ウィジェットにもアーキテクチャのコンテキストが必要です
• 「何を作るかはもう分かっている」→ ユーザーの期待は異なるかもしれません
• 「時間がない」→ 設計が不十分だと、後でより多くの時間がかかります
• 「明らかだ」→ 思い込みはバグの原因になります