mcpField
H
handoff

handoff

github.com/dobroslavradosavljevicエージェントワークフロー351 回インストール3 日前に更新
リポジトリ

handoff について

別のエージェントや後続セッションが同じ作業を継続できるよう、永続的な引き継ぎを作成・利用するスキルです。会話の要約ではなく、検証可能な状態、決定事項、リスク、次の手順を重視します。

主な機能

  1. 01引き継ぎの作成と利用
  2. 02目標・状態・決定事項の記録
  3. 03順序立てた検証可能な次の手順
  4. 04事実・仮定・未決事項の区別
  5. 05秘密情報の除外

活用シーン

  1. 01別のエージェントへの作業引き継ぎ
  2. 02後続セッションでの作業再開
  3. 03リポジトリの状態と未完了タスクの記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/dobroslavradosavljevic/skills --skill handoff

インストール後、Claude Code で/handoffを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yamlreferences/template.md

詳細

引き継ぎ

概要

目標、判断事項、リポジトリの状態、リスク、次の手順を保ったまま、別のエージェント(または後続のセッション)が同じ作業を続けられるよう、永続的な引き継ぎを作成または利用します。

モード

該当するモードを判断します。

  • 作成:現在の会話とワークスペースの状態を引き継ぎにまとめます。
  • 利用:既存の引き継ぎを信頼できる情報源として扱い、作業を再開します。

判断がつかない場合は、引き継ぎを作成するか、既存のものから再開するかを一度だけ質問します。

基本ルール

  • 前任エージェントの日記ではなく、次のエージェントに役立つ内容を優先します。
  • 物語風の振り返りよりも、具体的なパス、コマンド、判断事項、順序立てた次の手順を優先します。
  • 事実、前提、未解決の質問を分けます。
  • シークレット、トークン、パスワード、秘密鍵、シークレットの値全体は決して含めません。環境変数名のみを記載します。
  • 完了した作業を捏造しません。可能な場合は、ワークスペースで主張内容を検証します。
  • ハーネスに依存しない内容にします。ユーザーからファイルの指定がない限り、既定ではチャットに出力します。
  • 任意の ToDo リスト、プランモード、承認ワークフローがある場合は補助としてのみ使用します。引き継ぎ文書自体を、持ち運び可能な成果物として維持します。

作成ワークフロー

  1. 次のエージェントが引き継ぐべきミッションを確認します。
  2. 引き継ぎの根拠となる十分な最新状況を調べます。
    • 現在のブランチ、変更のあるファイル、最近のコミット、関連する実行中プロセス(確認できる場合)。
    • 変更済み、またはこれから変更する主要なファイル。
    • ユーザーがすでに確定した判断事項。
  3. references/template.md のテンプレートに記入します。空のセクションは、内容を埋めるためだけに追加せず省略します。
  4. 内容を短縮する必要がある場合は、次のセクションを優先します。
    • 目標と状況
    • 直ちに行う次の手順
    • 必ず把握しておくべきコンテキスト
    • してはいけないこと
  5. ユーザーがファイルパスを指定していない限り、チャットに引き継ぎを出力します。
  6. この引き継ぎから再開し、手順 1 に進んでください。 のように、ユーザーが次のセッションに貼り付けられる再開指示を一行で添えて締めくくります。
作成時の品質基準

一度読めば、別のエージェントが有意義な作業を開始できる引き継ぎにします。

以下を含めます。

  • ステータス:ready、needs-review、または blocked。blocked の場合は、障害となっている内容も記載します。
  • 完了したことと未完了のこと。
  • 未コミットまたは未完了の作業を、正確に記載します。
  • 順序立てられた、検証可能な次の手順。
  • 最初に読むべきファイルの短いリスト(通常は 3~7 個)と、それぞれの理由。
  • 前提、注意点、再調査が必要になりそうな却下済みの選択肢。
  • 重要だと分かっている正確なコマンドやチェック。

以下は避けます。

  • 会話の全文を貼り付けること。
  • 「実装を続ける」「機能を完成させる」のような曖昧な手順。
  • 関連するすべてのファイルを列挙すること。
  • 不確実な点を隠すこと。不明な点は明示します。

利用ワークフロー

  1. 変更を加える前に、引き継ぎ全体を読みます。
  2. 必要に応じて、目標、状況、最初の次の手順を一度に短くユーザーに確認します。
  3. 引き継ぎを鵜呑みにせず、最新の状態と照らし合わせて検証します。
    • ブランチ、変更のあるファイル、記載されたファイル変更。
    • 言及されているコミット、パス、コマンドが現在も存在するか。
    • 障害が現在も解消されていないか。
  4. ワークスペースの状態と引き継ぎに食い違いがある場合は、作業を停止し、先に不一致を報告します。
  5. 「してはいけないこと」と順序立てられた次の手順に従います。ただし、ユーザーから別の指示がある場合はそれに従います。
  6. まず記載されたファイルを読み、必要な場合に限って調査範囲を広げます。
  7. 引き継いだ作業が完了した場合、または再びセッションを中断する場合は、チャットの記憶に頼らず、更新した引き継ぎを作成します。

出力の既定値

  • 既定の出力先:チャット。単一の Markdown 文書として出力します。
  • ユーザーがパスを指定した場合は、その場所に書き込みます。一般的な選択肢:HANDOFF.md、docs/handoff.md、または指定された日付入りのパス。
  • 無関係なプロジェクト内に、求められていない引き継ぎファイルを作成しません。
  • 製品固有の UI メタデータを引き継ぎ本文に含めません。

最小限の再開プロンプト

引き継ぎを作成する場合は、次の短い開始文も提示します。

Use $handoff in consume mode.
Handoff is below / at <path>.
Verify it against the repo, then continue from Immediate Next Steps without re-litigating settled decisions unless they conflict with the workspace or user direction.

コメント