提案セッションでアイデアをコードに変換する
ページを編集リクエストが重要すぎて 1 つの自由形式のプロンプトとして処理できない場合、提案セッションは適切なエントリ ポイントです。すぐに編集するのではなく、HagiCode はまずリクエストを目標、スコープ、タスク、検証基準に変換してから、実行に移ります。
提案セッションを開始する前に、次のことを確認してください。
- 完成した デスクトップへのインストール
- 完成した ウィザードのセットアップ 少なくとも 1 つのプロジェクトを作成しました
- 変更を説明するのに十分なプロジェクトのコンテキスト。そうでない場合は、から始めてください 会話セッションを作成する
提案セッションの目的
Section titled “提案セッションの目的”提案セッションは次の場合に最適に機能します。
- 編集を開始する前に、変更には明確な範囲が必要です
- 複数のリポジトリ、モジュール、または成果物が関係する
- 作業はレビュー可能なステップに分割する必要があります
- 推論と実行の証跡を後で表示したままにしたい場合
リポジトリの理解や簡単なディスカッションのみが必要な場合は、会話セッションの方が高速です。構造とトレーサビリティが必要な場合は、ここに進んでください。
ワークフローの概要
Section titled “ワークフローの概要”現在の提案フローは次のように要約できます。
| ステージ | ユーザーアクション | システム結果 |
|---|---|---|
| 提案書を作成する | を開きます New Idea 引き出しを作成し、リクエストを説明します | 提案は明示的なプロジェクトとリポジトリの範囲から始まります |
| 構造を確認する | セッションの詳細ビューとワークフローの状態を確認する | より深く実行する前に、AI が目標、ステップ、ステータスを説明します |
| 進捗状況を追跡する | セッションボードを使用して、保留中のアイテム、アクティブなアイテム、およびアーカイブされたアイテムを監視します | 複数の提案の管理が容易になります |
| 結果を確認する | 完了したセッション ビューに戻る | コミットノートとセッション履歴を最初からやり直す代わりに再利用できます |
ステップ 1: 変更を定義する New Idea 引き出し
Section titled “ステップ 1: 変更を定義する New Idea 引き出し”現在のプロポーザルのエントリ ポイントは、 New Idea 引き出し。短いテキストのリクエストを受け入れるだけではありません。また、リクエストを具体的なプロジェクトとリポジトリのスコープに強制的に適用します。
まずは次の領域を確認してください。
- プロジェクト セレクター: どのプロジェクトがリクエストを所有しているかを確認します
- リポジトリ スコープ: 境界内にあるリポジトリを選択します
- プレビューエリア: システムが何をターゲットスコープとして扱うかを確認します。
- リクエストボックス: 自然言語での実際の変更について説明します
作業がドキュメント、フロントエンド、バックエンドに一緒に関わる場合は、実行中に後で境界を追加するのではなく、ここでその境界を定義します。
ステップ 2: プロポーザルの詳細ビューで目標、ステップ、ステータスを確認する
Section titled “ステップ 2: プロポーザルの詳細ビューで目標、ステップ、ステータスを確認する”作成後、HagiCode はすぐに編集に入りません。まず、ワークフローの状態、提案コンテンツ、セッション コンテキストをまとめた詳細ビューが開きます。
この画面は、提案セッションが通常の会話セッションと異なる理由を示しています。
- センターパネルはチャットだけではありません。提案関連のコンテンツを常に表示できるようにします
- ワークフローステッパーは現在の状態を明示します
- セッション リストと詳細領域では、長時間実行される作業のコンテキストが保持されます。
ここでも目標、範囲、またはタスクの内訳が間違っていると思われる場合は、次に進む前に提案を修正してください。それがこのワークフローのポイントです。
ステップ 3: セッションボードで複数の提案を追跡する
Section titled “ステップ 3: セッションボードで複数の提案を追跡する”プロジェクトに複数の提案、複数の実行ラウンド、または保留中の作業と完了した作業が混在している場合、セッション ボードが最も明確な概要になります。
このビューは、次の 3 つのことに特に役立ちます。
- まだ開始されていない提案を特定する
- 複数のアクティブなセッションのペースを比較する
- 完了した作業をアーカイブして、ワークスペースを読み取り可能な状態に保つ
日常のフローに複数の並列スレッドが含まれる場合、多くの場合、一度に 1 つの詳細ビューを開くよりもボード ビューの方が適しています。
ステップ 4: 完了した実行状態を再確認する
Section titled “ステップ 4: 完了した実行状態を再確認する”提案書が終わるまでに、通常は単純な「完了」マーカー以上のものが必要になります。また、何が変更されたか、コミットの概要がどのように構成されているか、同じコンテキストを次のラウンドに継続できるかどうかを確認する必要もあります。
この完了状態ビューは、次の 2 つのフォローアップ タスクに役立ちます。
- 生成されたコミットノートとメインの実行結果を確認する
- すべてを最初から再構築するのではなく、同じセッションコンテキストから継続します
言い換えれば、提案セッションは 1 回限りのイベントではありません。耐久性のあるワークフロー記録です。
プロポーズセッションを希望する場合
Section titled “プロポーズセッションを希望する場合”次の場合に最初に提案セッションを選択してください。
- 変更は複雑なので、AI が早すぎる間に即興で対応することは望ましくありません。
- 作業は後でレビューされるか、他の人と共有されます
- 複数のリポジトリ、モジュール、またはロールが関係する
- 実行履歴と根拠を再利用可能な状態に保ちたい場合
タスクがまだ小規模で探索的な場合は、通常、会話セッションがより軽い方法です。