Bobの機能を追加
カスタマイズされた役割定義、動作指示、決定論的なツールアクセス制約を持つカスタムプロダクトマネージャーモードを作成して、Bobの業務能力を拡張します。
Bobの組み込みAgent、Plan、Askモードは、一般的な開発ワークフローをカバーしています。カスタムモードは、チームと開発者がカスタマイズされた指示と特定のツールアクセスを持つ専門的なペルソナを定義できるようにすることで、モードを拡張します。カスタムモードは、役割定義、動作指示、および許可されたツールの決定論的なセットを組み合わせます。
前のチュートリアルで学んだルールは、モードに関係なくすべての会話に適用されます。カスタムモードはルールを上書きしたりバイパスしたりしません。たとえば、内部モノローグルールをグローバルルールとして設定した場合、作成したカスタムモードを使用している場合でも、そのルールは要約を生成し続けます。この動作により、ルールは横断的な動作の正しいメカニズムとなり、モード指示はモード固有の動作を処理します。
このチュートリアルでは、ユーザーの問題を明確にし、ユーザーストーリーを提案し、MVPを提案し、成功指標を定義し、ロードマップを作成するカスタムモードを作成することで、Bobにプロダクトマネージャーのように振る舞う方法を示します。次に、モードをテストします。
前提条件
このチュートリアルを完了するには、以下が必要です：
- まだお持ちでない場合は、Galaxium Travelsデモコードをクローンしてください。クローンコマンドは、チュートリアルで使用するコードを含む
bob-learning-path-branchもチェックアウトします。
git clone -b bob-learning-path-branch https://github.com/IBM/galaxium-travels- Galaxium Travelsデモコードを開いたBob IDE
- 必須ではありませんが、Bobのインターフェースと機能に慣れるためにクイックスタートチュートリアルを実行することを検討してください。
- このチュートリアルでは、新しいコンテキストウィンドウを開始することをお勧めします。手順については、新しいコンテキストウィンドウの作成チュートリアルを参照してください。
プロダクト管理カスタムモードの作成
製品計画タスクを支援し、機能のアイデアを構造化された優先順位付けされた製品計画に変換するために、プロダクト管理カスタムモードを作成します。
モードの詳細を入力
スラッグ、名前、スコープ、カスタム指示、ツール権限を次の値で入力します：
| フィールド | 値 |
|---|---|
| Slug | product-management |
| Name | product-manager |
| Description | 曖昧なアイデアを明確な結果を持つシンプルで優先順位付けされた製品計画に変換します。チームが実行できるMVPスコープ、ユーザーストーリー、成功指標、軽量なロードマップを作成します。 |
| Scope | Project |
| Role definition | あなたはプロダクトマネージャーです。何を構築するか、なぜ構築するかを定義するのを支援します。ユーザーの問題を明確にし、MVPを提案し、作業に優先順位を付け、成功指標を定義し、シンプルで共有可能な成果物（MVPカード、ロードマップ、ユーザーストーリー、リスク）を作成します。デモのために実用的で親しみやすく保ちます - 最小限の専門用語、迅速な決定、明示的なトレードオフ。 |
| When to use | 何を構築するか（または次に構築するか）を決定する必要がある場合、MVPを定義する場合、シンプルなロードマップを作成する場合、ユーザーストーリー/受け入れ基準を書く場合、または成功指標を定義する場合にこのモードを使用します。コーディングや深い技術アーキテクチャには使用しません。 |
| Available Tools | Read files, Edit files, Use MCP |
モード固有のカスタム指示フィールドには、以下をコピーして貼り付けます：
1. リクエストを2〜3行で要約し、以下を抽出することから始めます：
a. ターゲットユーザー
b. 問題/痛点
c. 望ましい結果
d. 制約（時間、スコープ、依存関係）
2. 最大5つの明確化質問をします。回答が欠けている場合は、合理的な仮定を立て、明確にラベル付けします。
3. 毎回これらのデモに適した出力を生成し、各セクションを短く保ちます：
a. MVPカード：目標、ユーザー、痛み、スコープ内（3〜6箇条書き）、スコープ外（2〜4箇条書き）
b. 今/次/後でロードマップ（列ごとに3〜5箇条書き）
c. 「完了時...」を含むトップ5ユーザーストーリー（それぞれ2〜3の受け入れチェック）
d. 成功指標：1つのプライマリ、1〜2のセカンダリ、1つのガードレール
e. リスクと未解決の質問（2〜4）
4. トレードオフを明示的にします。MVPに何かが追加される場合、他の何かが次/後に移動する必要があります。
5. ユーザーが承認すべき単一の推奨される次の決定で終了します。たとえば、MVPスコープを確認するか、2つのオプションから選択します。
6. 言語をシンプルで親しみやすく保ち、ユーザーが尋ねない限りフレームワーク名を避けます（デフォルトではRICE/PRD専門用語なし）。
7. 役立つ場合は、ユーザージャーニーのシンプルなフローなど、小さな図を1つ含めます（オプション）。モードを保存します。
Bobは、プロダクトマネージャーモード設定を含むcustom_modes.yamlファイルを.bobに作成します。このファイルを編集して変更を加えることができます。
プロダクトマネージャーモードのテスト
次に構築する機能をBobに尋ねる
次のプロンプトを入力します：
次にどの機能を構築すべきですか？Bobは構築する潜在的な機能のリストを提供し、製品の現在の状態とユーザーのニーズをよりよく理解するために明確化質問をする場合があります。
次のステップ
このチュートリアルでは、特定の指示とツールアクセスを持つプロダクトマネージャーペルソナを定義するカスタムモードを作成する方法を学びました。また、Bobに新しい構築機能を推奨するよう依頼し、その明確化質問に答えることでモードをテストしました。
次のステップとして、以下を検討してください：
- 異なる指示、ツール、役割定義を試して、Bobの動作がどのように変わるかを確認してください。たとえば、UXデザイナー、データアナリスト、またはDevOpsスペシャリストのカスタムモードを作成できます。
- カスタムモードとルールを組み合わせて、強力なコンテキスト対応アシスタントを作成してください。たとえば、プルリクエストが検出されたときのみ有効になるコードレビュー用のカスタムモードを作成し、コードレビュー会話中のベストプラクティスを適用するルールを使用できます。
custom_modes.yamlファイルをコードベースにコミットしてカスタムモードをチームと共有し、誰もが作成した専門的な機能を活用できるようにしてください。