pipa-huddle-beta

Pipa Huddle ベータ版

ユーザーが現在使用しているエージェントとの音声ハドルを開始し、声に出して作業について話し合えるようにします。

出力の目標：ホスト型音声ブリッジを開始し、コンテキストと保持について明確に伝え、必要に応じて簡潔な引き継ぎメモを作成します。

コミュニケーションスタイルの契約：~/.pipa/communication-style.md が存在する場合はそれを適用し、存在しない場合は skills/pipa/references/communication-style.md が利用可能であれば適用します。表現上の好みが、このスキルのワークフロー、出力契約、プライバシールール、開始条件に優先することはありません。

ワークフロー

実行する前に、このチェックリストをコピーし、作業メモの中で最新の状態に保ってください。

Voice Session Progress
- [ ] Step 1 complete: intent and voice-session scope confirmed
- [ ] Step 2 complete: available agent context and session limits stated
- [ ] Step 3 complete: local OpenCode voice bridge availability checked
- [ ] Step 4 complete: browser voice session started or blocker returned
- [ ] Step 5 complete: session notes synthesized without treating raw transcript as durable state
- [ ] Step 6 complete: optional handoff produced when the user wants to continue execution

ステップ 1：意図を確認する

ユーザーが Pipa またはアクティブなエージェントと音声で話したいと依頼した場合に、このスキルを使用します。別のブラウザーからのホスト型セッションやリレー経由のセッションも含みます。音声アーティファクトは pipa-audio-brief に、人間同士のビデオ会議は別の適切な場所に振り分け、リアルタイムの音声コーディングや口頭での承認依頼には、明確なスコープ上のブロッカーを設けます。

ステップ 2：セッションの契約を明示する

references/session-contract.md に従います。

セッションの開始時に、次の内容を伝えます。

• 利用可能なエージェント／コンテキスト
• 音声セッションで現在できること
• V1 ではできないこと
• 生の音声／文字起こしが一時的なものか、保存されるのか

音声モードが独立した別のエージェントの頭脳であるかのように説明しないでください。音声セッションは、現在のエージェントコンテキスト上の対話レイヤーです。

ステップ 3：ローカルの OpenCode 音声ブリッジを起動する

references/transport-prototype.md、references/hosted-relay.md、references/template-contract.md、references/privacy-and-retention.md に従います。

ブリッジは、最初の音声／テキストターンでハドル専用の OpenCode セッションを作成し、opencode run --format json からその新しいセッション ID を取得します。その後は --session <id> を使って、ハドルの残りの間も同じセッションを再利用します。これにより、opencode session list から推測したり、音声ターンを無関係な既存スレッドに紐付けたりすることを避けられます。

起動前に、起動元のスレッドにハドルで続ける価値のある実質的な会話コンテキストがある場合に限り、簡潔なインラインコンテキストを作成します。コンテキストは次のような内容にします。「あなたは現在、ユーザーとの会話を続けるハドルに参加しています。以前の会話のコンテキストは次のとおりです。」その後、役立つ会話コンテキストだけを含めます。たとえば、ユーザーが話していたこと、関連する決定や好み、未解決の質問、その会話を理解するために必要なファイルやリポジトリの詳細です。

ハドルを開始することを指示する「現在の目標」は含めないでください。ユーザーの以前の会話に固有のものでない限り、一般的なリポジトリコンテキスト、セッションのスコープ、「想定しないこと」といった定型文は含めないでください。ユーザーのハドル開始依頼、このスキルの実行手順、デーモン／ブリッジの詳細、URL、モデル／ランタイムの詳細、セッション作成の仕組みは含めないでください。「ハドルを始めて」という内容以外に実質的な会話がなければ、コンテキストを渡さないでください。

コンテキストが役立つ場合は、PIPA_VOICE_SESSION_CONTEXT を使ってインラインで渡します。ブリッジはこのコンテキストを最初のハドルターンにのみ挿入するため、起動元のスレッドを引き継がずに、ハドル専用セッションを必要な情報がある状態で開始できます。通常のワークフローの一部として、起動コンテキストファイルを作成または更新しないでください。

現在の OpenCode モデルを --model <current-opencode-model> でブリッジに渡し、ハドルでも起動元のセッションと同じモデルを使います。OpenCode のデフォルトに頼らず、スキル内でプロバイダー固有のモデルをハードコードしないでください。アクティブなエージェントセッションのモデル ID を使います。現在のランタイムが OPENCODE_MODEL を公開している場合、ブリッジはそれも尊重しますが、デーモンやホスト型の起動を確認しやすくなるため、明示的な --model の指定を優先します。

サンドボックス環境またはリモートブラウザーからの利用には、管理されたホスト型リレー経路を使用します。本番リレーは https://voice.usepipa.com です。起動するたびに /s/<session-id> 配下の個別のセッション URL が作成され、ローカルのブリッジデーモンが /ws/<session-id> に向けて外向きに接続します。 同じコンピューター上でのローカルフォールバックおよび開発用パスとして、同梱のブリッジ skills/pipa-huddle-beta/scripts/start-voice-session.mjs を使用してください。このブリッジは localhost のブラウザー UI を提供し、ブラウザー API で音声を取り込み、各ターンを opencode run に送信して、OpenCode の応答をブラウザーの音声合成で読み上げます。

常にマネージドデーモンの JSON パスから起動してください。このブリッジは長時間稼働する HTTP/WebSocket プロセスであるため、シェルやツール呼び出しの実行期間に連動させてはいけません。新しいマネージド起動では、.pipa/voice-session/bridge.pid に記録されたプロジェクトローカルの Pipa Huddle ブリッジのみを停止し、.pipa/voice-session/session.json に新しいメタデータを書き込み、ハドルセッションが終了すると終了します。

ローカルブリッジは references/template-contract.md で定義されている決定的なハドルテンプレートを提供します。デフォルトでは、スキル内のファイル templates/huddle.html をレンダリングします。明示的なテンプレート実験の場合に限り、PIPA_VOICE_SESSION_TEMPLATE=/absolute/path/to/index.html を設定してください。

リポジトリのルートから実行するデフォルトのホストモード起動コマンド：

node skills/pipa-huddle-beta/scripts/start-voice-session.mjs --daemon --print-url-json --model <current-opencode-model>

引き継ぐべき実質的な過去の会話がある場合は、その起動に限り、インラインで渡してください：

PIPA_VOICE_SESSION_CONTEXT='<prior conversation context>' node skills/pipa-huddle-beta/scripts/start-voice-session.mjs --daemon --print-url-json --model <current-opencode-model>

ローカルフォールバック：

node skills/pipa-huddle-beta/scripts/start-voice-session.mjs --daemon --print-url-json --local --model <current-opencode-model>

ホストモードでは、リレーセッションを作成し、ローカルブリッジデーモンに接続して、ブラウザー URL、デーモンの PID、ログパス、停止コマンドを含む JSON イベントを出力します。ホストモードでは、デフォルトで OpenCode のフラグは追加されません。ユーザーが音声またはテキストで入力したターンをローカルの OpenCode ブリッジに転送します。OpenCode の通常のセッションおよび権限の動作は引き続き適用されます。

デフォルトでは、呼び出し元のスレッドを続行しないでください。ハドルは別室として動作します。最初のターンで新しい OpenCode セッションを作成し、その後は --session <id> を使用して、すべてのハドルターンをそのセッション内で続行します。既存のハドルセッションを再開する場合に限り --huddle-session <id> を使用し、手動デバッグの場合に限り --allow-latest-session を使用してください。

ブリッジを起動できない場合は、明確にブロックしてください。確認せずに、ブラウザーの STT、Daily/WebRTC、その他のプロバイダーが利用可能であるかのように振る舞わないでください。

ステップ 4：音声セッションを実行する

セッション中は、次の点に従ってください。

• ブラウザー音声が出力となるため、ターンは非常に短く、会話調に保ちます
• 音声での返答は、デフォルトで短い 1〜2 文にします
• ユーザーが詳細を明示的に求めない限り、箇条書き、番号付きリスト、見出し、Markdown 形式、長い説明は避けます
• ユーザーの指示が曖昧または矛盾している場合は、明確化のために質問します
• 有用なコンテキスト、決定事項、好み、阻害要因、未解決の質問を把握します
• とりとめのない発話は、ユーザーが確認しない限り、最終的な指示ではなく発見のための入力として扱います
• デフォルトでは、生の文字起こしや音声を保存しないでください

テキスト入力は、デバッグおよびアクセシビリティのための入力パスとして使用できます。ただし、エージェントの返答は OpenCode から得るか、ブロッカーを返す必要があります。

ステップ 5：任意のコンテキスト引き継ぎ

セッションが実行の意図をもって終了した場合、またはユーザーがエージェント内で続行するよう求めた場合に限り、references/context-handoff.md に従ってください。

ステップ 6：ステータスまたはブロッカーを返す

問題なく完了した場合の最終応答：

Ready to join the huddle: `<session URL>`

ブロックされた場合の最終応答：

Voice session blocked.

- **Blocked at:** <transport|microphone|privacy|scope>
- **Why:** <specific blocker>
- **Next:** <minimum action needed>

参考資料

• references/session-contract.md
• references/context-handoff.md
• references/transport-prototype.md
• references/hosted-relay.md
• references/template-contract.md
• references/privacy-and-retention.md