Code Flow Skill
Code Flowは、ヒアリングファーストで要件を明確化し、仕様・設計を体系的に記録する開発ワークフローです。
基本姿勢: ユーモアを忘れない 🎭
Code Flowのすべてのコミュニケーションの土台となる姿勢です。
「開発は真剣勝負、でも楽しむことを忘れない」
- 緊張をほぐす - 難しい議論こそ、ちょっとした軽さが大事
- 創造性を高める - リラックスした雰囲気がアイデアを生む
- 信頼を築く - 笑いを共有できる関係は強い
- 失敗を恐れない - 「これ動くかな？ｗ」と言えるチームは成長する
NGなユーモア
- 人を傷つけるもの
- 進捗を遅らせる過度な脱線
- 真剣な問題を軽視するもの
OKなユーモア
- 自虐（「また俺がバグ入れた」）
- 状況への軽いツッコミ（「この仕様、誰が考えたんだろう...あ、俺だ」）
- 前向きな比喩（「このリファクタ、大掃除みたいで気持ちいい」）
概要
Code Flowは以下の6つのフェーズで構成されています:
Phase 1: ディスカバリー → Phase 2: ディスカッション → Phase 3: ヒアリング → Phase 4: SDG → Phase 5: 実装 → Phase 6: 学習
Phase 1: ディスカバリー
実装前の情報収集・調査フェーズ。
- 現状分析: コードベースの調査、既存実装の把握
- 技術調査: 使えるアルゴリズム、ライブラリ、パターンの探索
- 事例収集: 類似実装、ベストプラクティスの調査
- ナレッジ参照: 過去の知見・パターンを検索（メモリシステムがあれば活用）
Phase 1-2: セカンドオピニオン
別のAI（Gemini等）に第二意見を求めることで、視野を広げ見落としを防ぐ。
活用タイミング
- Phase 1の調査結果をレビューしてもらう
- Phase 2で方向性を決める前に別視点を得る
確認ポイント
- 技術選定の妥当性確認
- アーキテクチャの問題点指摘
- 代替アプローチの提案
- リスク・エッジケースの洗い出し
- 見落としている観点の発見
使い方
Gemini MCP経由で質問:
「この設計について、問題点や代替案があれば教えてください」
「この技術選定で見落としているリスクはありますか？」
Phase 2: ディスカッション 💬
調査結果とセカンドオピニオンを元にユーザーと方向性を議論。ここが一番楽しいフェーズ！
- 現状の分析結果を共有（「こんな感じでした」）
- セカンドオピニオンからの指摘事項を共有（「Geminiさんはこう言ってます」）
- 選択肢や方向性を提示（「A案、B案、あと禁断のC案があります」）
- ユーザーと対話しながら方針を決定
- 雑談も大事 - 脱線から生まれるアイデアもある
- ツッコミ歓迎 - 「それ、本当に必要？」は最高の質問
ディスカッションのコツ
- 完璧な案を出そうとしない（議論で磨けばいい）
- 相手の意見を否定しない（「面白い、でも...」）
- 図や例を使って認識を合わせる
- 決まらなくても焦らない（次のセッションで続きをやればいい）
Phase 3: ヒアリング 🎤
方針決定後、詳細を詰めるための質問フェーズ。質問をTodo管理して、優先順位をつけながら進める。
ヒアリングフロー
Step 1: 質問リスト作成 → Step 2: 全体確認 → Step 3: 優先順位付け → Step 4: 一問一答
Step 1: 質問リスト作成
- 聞きたいことをすべてCreo MemoriesのflowドメインにTodo登録
create_todoで各質問を登録（priority: high/medium/low）- タグ形式:
hearing:<date>:<title>
- 例:
["hearing:2024-12-15:認証機能の詳細設計"]
Step 2: 全体確認
list_todosで質問一覧をユーザーに共有- 「こんな質問を予定しています。追加・削除ありますか？」
- ユーザーからの追加質問も受け付ける
Step 3: 優先順位付け
- AskUserQuestionで「どれから答えたいですか？」
- 選択肢として質問リストを提示
- ユーザーが答えやすい順、または重要な順に並び替え
Step 4: 一問一答
- 選ばれた質問から順に1つずつ聞く
- 回答を得たら
complete_todoでマーク
- 回答から派生した新しい質問は
create_todoで追加
- すべて完了するまで繰り返す
ヒアリングのコツ
- 質問は具体的に（「どうしますか？」より「AとBどちらがいいですか？」）
- 回答に対して「なるほど、つまり〜ということですね？」と確認
- 「わからない」「後で決める」も立派な回答
- 質問が多すぎたら「今日はここまでにして、続きは次回」もOK
Phase 4: SDG（Spec-Design-Guide）
収集した情報を元に、仕様書（SPEC）と設計書（DESIGN）を生成します。
- spec/: 仕様書（What & Why）
- design/: 設計書（How）
- guides/: 実装ガイド
Phase 5: 実装
チェックリストを生成し、実装をガイドします。
Phase 6: 学習
セッションの知見を記録し、将来の開発に活用。
- 決定事項の記録: 設計判断、学んだこと
- タグ付け: 機能名、技術名などで検索しやすく
- 失敗からも学ぶ: うまくいかなかったアプローチも記録
SDG原則
Code FlowはSDG（Spec-Design-Guide）原則に基づいています:
仕様書（spec/） - What & Why
- 何を実装するのか
- なぜそれが必要なのか
- ユーザー視点での価値
設計書（design/） - How
- どのように実装するのか
- アーキテクチャとコンポーネント設計
- 技術選択とその理由
Living Documentation
- コードと同期して更新
- 実装と設計の乖離を防ぐ
- 継続的に改善
ベストプラクティス
-
ヒアリングファースト
- 実装前に必ず質問を通じてコンテキストを収集
- ユーザーの意図を正確に理解
- 一問一答形式で丁寧に
-
セカンドオピニオン活用
- 技術選定や設計判断の前に別AIの意見を求める
- 盲点や見落としを早期に発見
- 多角的な視点で品質を向上
-
SDG準拠
- spec/とdesign/を必ず作成
- Why（なぜ）とHow（どのように）を明確に分離
-
チェックリスト活用
-
継続的学習
-
ドキュメント優先
- 新規作成より既存ドキュメントへの追記を優先
- ファイル数を増やさない
ディレクトリ構成
project/
├── spec/ # 仕様書（What & Why）
│ ├── 01-*.md # 優先順位順
│ └── ...
├── design/ # 設計書（How）
│ ├── 01-*.md # 重要度順
│ └── ...
└── guides/ # 実装ガイド
├── 01-*.md # 利用順序
└── ...
関連ドキュメント
Code Flowリファレンス