vf-design

Vibe Flow Design

概要

アイデアを対話的に探求し、GitHub Issueとして実行可能な設計ドキュメントに仕上げる。

開始時の宣言: 「vf-design スキルを使って、設計セッションを開始します。」

プロセス

1. アイデアの理解

• まずプロジェクトの現状を確認する（ファイル、ドキュメント、最近のコミット）
• 質問は1回に1つだけ投げる
• 可能な限り選択肢形式で質問する（自由回答でもOK）
• 1つのトピックに深掘りが必要な場合は、複数の質問に分ける
• 目的・制約・成功基準を把握することに集中する

2. アプローチの探求

• 2〜3のアプローチをトレードオフ付きで提案する
• 推奨案を先に示し、その理由を説明する
• 会話的に選択肢を提示する

3. 設計の提示

• 理解が十分だと判断したら、設計を提示する
• 200〜300語ごとのセクションに分けて段階的に提示する
• 各セクションの後に「ここまで問題ないですか？」と確認する
• カバーする内容：アーキテクチャ、コンポーネント、データフロー、エラー処理、テスト
• YAGNIを徹底する — 不要な機能は含めない
• 不明点があれば前のステップに戻って確認する

4. 設計の拡張

設計が承認されたら、以下のセクションを追加する:

Issue 分解:

設計を実装可能な単位に分解する。各Issueは:

• 単一の、スコープが明確な作業単位
• 独立してテスト可能
• 「完了」の定義が明確

フォーマット:

## Issue 分解

### Issue 1: [タイトル]
**説明:** [実装内容]
**受入基準:**
- [ ] [基準1]
- [ ] [基準2]

### Issue 2: [タイトル]
...

実行記法:

リスト/セット記法で実行順序を定義する:

• [] = シリアル（順次実行）
• () = パラレル（並列実行）
• 番号は仮ID（/vf-issue-create で GitHub Issue 番号に置換される）

## 実行順序

`[1, (2, 3), 4]`

5. 保存

docs/plans/YYYY-MM-DD-<topic>-design.md に保存し、コミットする。

6. ハンドオフ

• /vf-flow から呼び出された場合: 設計ドキュメントのパスを返し、次のステップに進む
• 単体で呼び出された場合: 保存パスを報告し、/vf-issue-create <パス> の実行を提案する

連携

呼び出し元:

• vf-flow — E2Eフローの最初のステップとして