openclaw-handoff

引き継ぎ

特定のタスクについて調査、議論、または作業するための、クリップボードにコピーしてすぐ使えるプロンプトを別のエージェント向けに作成します。

ユーザーが handoff <task>、「引き継ぎを書いて」、「これを委任して」と依頼した場合、または別のエージェント向けのプロンプトを求めた場合に使用します。

ワークフロー

1. ユーザーのテキストからタスクを特定します。ユーザーが短いラベルだけを指定した場合は、現在のリポジトリ、最近の議論、ブランチ名、リンクされている issue／PR、ドキュメント、周辺の明白なコンテキストから推測します。
2. 有用な引き継ぎを書くために十分なコンテキストを集めます。リポジトリ／製品の識別情報、関連する issue／PR／ブランチ名、関連しそうなモジュール、制約、既知の症状を確認します。引き継ぎ先エージェントが行う独立したレビューをすべて実施したり、最終的な技術方針を決めたりしないでください。
3. 新しいエージェントがそのまま使える、独立したプロンプトを作成します。
4. プロンプト全文をクリップボードにコピーします。
5. 最終返信では、タスク名を含む簡潔な確認だけを返します。ユーザーから求められない限り、プロンプト全文を貼り付けないでください。

引き継ぎプロンプトのルール

プロンプトでは、次のことを行ってください。

• 命令だけの作業指示ではなく、議論を始める形にします。
• 変更を加える前に、引き継ぎ先エージェントが広範囲な独立レビューを行うよう依頼します。
• そのレビューの責任は引き継ぎ先エージェントにあり、引き継ぎでは開始時のコンテキストと既知の制約のみを伝えることを明確にします。
• そのタスクが適切な案か、古くなっているか、すでに解決済みか、範囲が広すぎるか、別の方法で対処する方がよいかを判断するよう依頼します。
• 引き継ぎ先エージェントは、リポジトリ、その親ディレクトリ、ワークスペースディレクトリ、またはホームディレクトリから開始し、自分でリポジトリを見つけられるものとします。
• ファイルシステム上のパスは避けます。ユーザーから明示的に求められない限り、絶対パス、ホームディレクトリのパス、チェックアウト名、リポジトリ相対パスを含めないでください。
• 代わりに、リポジトリの所有者／名前、製品／モジュール名、issue／PR の URL、ブランチ名、パッケージ／プラグイン名、公開シンボル、コマンド名、設定キー、正確なエラーテキスト、ドキュメントのタイトル、検索語など、場所を特定する手がかりを使います。
• 適切なリポジトリ、対象範囲、望ましい成果を把握できるだけのコンテキストを含めます。
• 制約、対象外事項、検証に関する期待、望ましい出力形式を含めます。
• 関連する場合は、リポジトリ／GitHub／CI の最新状況を再確認するよう伝えます。
• 引き継ぎで明示的に依頼されていない限り、プッシュ、マージ、issue／PR のクローズ、ラベル付け、公開コメントの投稿をしないよう伝えます。

プロンプトのテンプレート

通常は、次の形式を使用します。

I want to discuss and possibly work on: <short task title>

Context:
- <portable repo/product context>
- <what triggered this task>
- <known current state, branch/issue/PR names or URLs if relevant>
- <important constraints and ownership boundaries>

Before doing any implementation:
- Find the right repository from the current directory, a parent directory, or the usual workspace.
- Read the local agent/repo instructions.
- Inspect the relevant code, docs, tests, recent commits, and linked issue/PR state.
- Decide whether this task is still real, whether the proposed direction is a good idea, and whether a smaller/better fix exists.
- Call out stale assumptions, hidden risks, and anything that should stop the work.

Task:
- <what to investigate or implement if the review supports it>
- <expected behavior or decision criteria>
- <non-goals>

Validation:
- <focused tests/checks/live proof expected>
- <what evidence should be included>
- <what is explicitly not required>

Output:
- Start with your review findings and recommendation.
- Then give the proposed plan or patch summary.
- If you edit code, keep changes scoped and report exact proof run.
- Do not push, merge, close issues/PRs, label, or post public comments unless explicitly told.

クリップボード

macOS の場合：

pbcopy < /tmp/handoff-prompt.txt

一時ファイルまたはパイプを使用します。バッククォート、$、引用符、ユーザーのテキストを含むプロンプトでは、シェルに直接引用符で囲んで渡さないでください。

pbcopy が使えない場合は、プラットフォームに適したクリップボードツール（wl-copy、xclip、clip.exe）を使用するか、プロンプトを出力して、クリップボードにコピーできなかったことを伝えてください。

品質基準

• 事実を捏造しないでください。確認した事実として記載するのは、実際に確認した後に限ります。
• パスを漏らさないでください。誤って含めたパスは、シンボル、モジュール、コマンド、issue／PR の URL、検索語などに置き換えます。
• 新しいエージェントが状況を把握できるだけのコンテキストを含めますが、過剰な情報は避けます。
• 引き継ぎ先エージェントへの最初の実質的な指示は、レビュー、議論、評価のいずれかにします。