生産的思考
Tim Hurson の生産的思考モデルを用いた構造化設計セッションをファシリテートし、必要に応じて RFC としてまとめます。
入力
$ARGUMENTS
- 入力が
rfcで始まる場合、RFC モード を実行します。それ以降はオプションのタイトルまたは出力パスとして扱います。 - それ以外の場合は インタラクティブモード を実行し、入力を問題文として扱います。入力が空の場合は、ユーザに問題を一文か二文で説明するよう依頼してから、他の操作を行います。
ファシリテーションの方法
- すべてをコードに基づかせる。 各ステップの前に、関連するファイル、スキーマ、設定、ドキュメントを検索して読み込み、それらに依存する場合はパスを明示します。このセッションの価値は、ホワイトボードでの議論とは異なり、結論がシステムの実際の動作に基づいている点にあります。したがって、推測ではなく確認を行います。多くのファイルを広範囲にスキャンする必要がある場合は、Explore サブエージェントに委譲し、セッションのコンテキストを議論に集中させます。
- ユーザの負担を軽く保つ。 一度に最大5つの質問に絞り、発見に基づくあなた自身の回答案をペアで提示することで、ユーザが「はい、ほぼその通りですが…」と答えられるようにし、白紙の状態から始めなくて済むようにします。
- 1ターンに1ステップ。 各ステップは
Step 2 of 6 — What's success?のようなヘッダーで開始し、そのステップを実行したら停止して待機します。ユーザの準備ができてから次のステップに進みます。ユーザがステップをスキップしたり、再訪したり、間を行き来できるようにします。 - 進行中のノートファイルを維持する。 各ステップの後、合意された成果を
<rfc-dir>/<slug>.notes.mdに追記します（<rfc-dir>は RFC モードのステップ3で説明するように選択します）。長いセッションは後で圧縮または再開できます。ノートファイルがあれば、RFC モードや新しいセッションでも決定事項を失うことなく引き継げます。最初にノートファイルを作成したときは、その場所をユーザに伝えます。
6つのステップ
1. 現状はどうなっているか？
目標：現在の現実と目標とする将来についての共通認識を形成する。 影響を受ける領域の既存の実装、呼び出し箇所、データモデル、最近の git 履歴を調査する。 対象：問題点やボトルネック（エラー、メトリクス、コードなどの証拠を添えて）、影響を受けるモジュールとサービス、誰が影響を受けるか、「解決された」状態がどのようなものか。
2. 成功とは何か？（DRIVE）
目標：すべての選択肢を評価する基準。ステップ1からドラフトを提案し、ユーザが修正できるようにする。
- Do（やるべきこと）：ソリューションが必ず実現しなければならないこと
- Restrictions（制約）：ハードな制約（下位互換性、パフォーマンス予算、技術スタック、コンプライアンス）
- Investment（投資）：チームが費やす意思のある時間、人員、複雑さ
- Values（価値観）：判断の軸となるエンジニアリング原則（シンプルさ、テスト容易性など）
- Essential outcomes（不可欠な成果）：譲れない結果、可能な限り測定可能であること
また、明示的に非目標も記録する。
3. 問いは何か？
2～3の「How might we…（どうすれば…できるか）」形式の問いを提案し、課題を異なる角度から捉え直します。例えば、狭い問いと、ステップ1の前提に挑戦する問いを一つずつ提案します。ユーザが選択または書き換えた問いが、残りのセッションの問題文となります。
4. 答えを生み出す
コードベースに基づいた、本当に異なる2～3のアプローチを提案します（単一のアイデアのバリエーションではありません）。各アプローチについて：簡潔なスケッチ、影響を受けるファイルやモジュール、主なリスクを提示します。このステップでは判断を保留し、ユーザ自身のアイデアも歓迎します。
5. 解決策を練り上げる
各アプローチを DRIVE 基準に照らして評価します（小さな表で十分です）。一つを推奨し、受け入れるトレードオフを明確にします。次に、それを堅牢化します：障害モード、エッジケース、移行上の懸念、未解決の質問。他の選択肢が採用されなかった理由を記録します。これが「代替案の検討」となります。
6. リソースを調整する
個別のチケットではなく、提供の全体像について合意します：フェーズやマイルストーンと各フェーズで何が実証可能になるか、最初に証明すべき最もリスクの高い部分、フィーチャーフラグと移行戦略、テスト戦略、ロールアウトとロールバック、監視すべき項目。詳細なチケット分解は、後で /task-breakdown を使用して RFC から生成します。最後に RFC の生成を提案します。
RFC モード
- セッションを見つける：これまでの会話と、存在する場合はノートファイルを使用します。セッションがまったく存在しない場合は、その旨を伝え、セッションを開始することを提案します：問題文を尋ね、ステップ1を開始します。
- 欠けているステップがある場合は、それをリストアップし、今すぐ埋めるか、それらのセクションを TBD とマークして RFC をドラフトするかを尋ねます。ユーザが行っていない決定をでっち上げないでください。
- 出力場所を選択します。RFC、ノート、タスクファイルは開発者のローカル作業ドキュメントです：デフォルトでは追跡対象外 であり、コードと一緒にコミットされません。それら用の既存のローカルで git 無視されたフォルダがないか確認し（
.gitignoreと.git/info/excludeを確認）、その命名規則に従います。存在しない場合は、.rfcs/YYYY-MM-DD-<slug>.mdを提案し、.rfcs/を.git/info/excludeに追加します。これにより、リポジトリの.gitignoreを変更せずにローカルでのみ無視されます。チームが RFC をコミットする場合にのみ、docs/rfcs/などの追跡対象フォルダを使用します。 - templates/rfc.md を使用して RFC を作成し、各セクションをセッションの内容で埋め、コードベースに関する主張にはファイルパスを関連付けます。
- ユーザにパスを伝え、TBD のセクションと未解決の質問があればリストアップします。
- 次のステップを提案します：
/task-breakdown <rfc-path>で RFC を1ストーリーポイントのチケットに分割し、チームが着手できるようにします。