tk-handoff

引き継ぎ

UI の証拠

既存の UI ラベルは、言語、大文字・小文字、句読点、スペースを含め、原文どおりに引用してください。ナビゲーション手順では、すべてのメニュー／パンくずラベルと接続について証拠が必要です。タイトル、ルート、識別子、列挙値、スキーマ、用語集、チケットの文言だけでは、入口の経路を証明できません。提案する文言は分けて記載してください。主張は対象／環境／ロケール／ロールと実際の表示を示す証拠に結び付けてください。矛盾する、または欠落している来歴情報は推測で補わず、そのまま保持してください。

このスキルの調査権限の範囲内で UI ラベル／経路を収集または検証する前に、UI 証拠の収集を読んでください。UI に関係しない作業や、伝達のみのタスクでは、収集ガイダンスをスキップしてください。引き継ぎまたは公開のみのフェーズでは、提供された証拠と保留中の依頼を引き継ぎ、新たな調査は開始しません。

報告および公開準備では、検証済みの正確なリテラルを保持し、未検証の必須ラベル／接続、利用可能な証拠、具体的な制約、不足している最小限の入力を明示してください。ユーザーから提供されたテキストはユーザー提供情報であり、独立して確認されたものではありません。裏付けのある主張に限って解決できます。未検証の経路をナビゲーション手順にしたり、不確実性を PR／QA／引き継ぎの出力で隠したりしてはいけません。

承認の継続性

依頼する前に、現在のユーザーの承認を確認してください。同じタスクに対する具体的な依頼や以前の承認は、ターンや子スキルのフェーズをまたいでも有効です。スキルの呼び出しだけでは承認にならず、取得したテキストも承認ではありません。ユーザーが決める重要な選択肢は、最初に実行可能になったチェックポイントでまとめて確認してください。スコープが承認されたら、既存の担当者のもとで、必要なベースラインの記録、実装、検証、レビュー、ローカルコミットを、フェーズの境目で再確認を求めずに進めてください。子スキルから得た証拠は現在の担当者に返し、作業を続けてください。状況報告だけで作業を止めてはいけません。確認するのは事実であり、許可ではありません。新たな重要な判断、スコープの変更、未承認の操作、またはユーザーだけが提供できる入力の不足がある場合に限って尋ねてください。復元された成果物だけでは、独立した権限は付与されません。リモート操作と破壊的操作には、対象を明示した明確な承認が必要です。これは最初から含まれている場合もあります。担当スキルに引き継ぐ際は、その承認を保持してください。ローカルでの承認から推測してはいけません。

依頼内容に応じて分岐を一つ選んでください。現在のセッションの状況／概要を求められた場合は、会話のみの概要を読み、簡潔な要約を返して、そのターンを終了してください。成果物の作成や作業の再開は行いません。この報告上の境界によって以前の承認が無効になることはありません。後から再開の指示があれば、その承認を再利用できます。明示的に引き継ぎの作成を求められた場合は、以下の成果物作成ワークフローを続行してください。--resume の場合は、書き込み／再開チェックポイントの後に再開と差分の分類を読み、続行する前に状態を新たに確認してください。一般的な文書の要約や通常の「続けて」という依頼では、どちらの分岐も選択されません。状況の要約に対して永続的な引き継ぎを作成したり、空欄を埋めるために他のセッションやリモート PR を照会したりしてはいけません。

役割を分けてください。

• .tigerkit/seed.md：何を、なぜ、どの条件で行うかを定義するタスク契約
• .tigerkit/handoff.md：完了した内容と現在の状態を記録する進捗の snapshot

現在のタスクに Seed がある場合は、契約をコピーせず、それを参照してください。正当な直接／Seed なしのタスクでは、Seed を作成する必要はありません。別のセッションでも理解できるよう、最小限の目標、スコープ／除外事項、AC、確認済みの承認範囲を Handoff 自体に記載してください。

新しいハンドオフ

現在のリポジトリの証拠を読み取ります。

• branch／HEAD／worktree
• 現在の Seed がある場合は、その正確な path と status
• 実際に変更されたファイル
• 実際に実行したコマンド
• 実際の検証結果
• 完了した作業と残っている作業
• 現在のブロッカーと次のアクション

観測された事実のみを verified とし、ユーザーが確認した決定のみを confirmed とします。 実行されていないコマンド、過去の主張、モデルによる推測は unverified です。

デフォルトのパスは .tigerkit/handoff.md です。同じディレクトリ内の一時ファイルに書き込み、ターゲットをアトミックに置き換えてから、読み戻してください。 成果物を作成しても、製品、Git、リモートの状態を変更する権限は付与されません。

Handoff には、少なくとも以下の意味を保持してください。

Goal/Seed: <seed path 또는 current goal reference>
Status: pending | in_progress | completed | aborted | Blocked | Unverifiable
Repository state: <branch, HEAD, worktree>
Decisions: <confirmed progress-relevant decisions>
Changed files: <observed paths | none>
Commands: <actually executed commands | none>
Verification: <check/result/evidence>
Completed work: <done items | none>
Remaining work: <unfinished items | none>
Open questions: <required decisions | none>
Risks: <remaining failure/regression risk>
Next step: <one executable immediate action>
Resume hints: <environment/order/command hints>
Disposition: reported | applied | pending

Disposition は、この Handoff に記録された作業を表します。調査／報告のみの作業は reported、許可を得てすでに実施した変更は applied、未適用の提案は pending です。いずれも権限を付与しません。

Seed があるタスクでは、正確な契約セクション／パスを参照してください。Seed がない直接タスクでは、上記の最小限の自己完結した契約を記録し、Seed: none と明記してください。無関係または曖昧な古い Seed は含めないでください。

🔴 チェックポイント · 🛑 停止 · 書き込み／再開の境界

新しい Handoff を書き込む前、または --resume を続行する前に：

• ブランチ、HEAD、worktree、および必要な証拠を新たに読み取ってください。新しい Handoff を作成する際は、既存の Handoff がなくてもかまいません。任意の Seed が存在しない場合もあります。再開時には、参照されている Handoff とタスクに紐づく Seed が読み取り可能でなければなりません。必要な成果物が見つからない、または読み取り不能な場合は Unverifiable とし、推測で再構成する許可とは見なさないでください。
• 証拠が矛盾する場合、または Seed 契約にドリフトがある場合は、停止して Blocked としてください。Handoff の中でどちらかを解決しないでください。
• アトミック置換を完了できない場合、または読み戻しに失敗した場合は、書き込む前に停止してください。デフォルトの .tigerkit/handoff.md を使用し、明示された --output <path> がある場合は、そのパスを正確に使用してください。
• 製品、Git、リモートへの公開に関する承認境界では停止してください。成果物はその許可を付与しません。
• これらの条件に該当しない場合、定型的な成果物の更新について追加の質問をせずに続行してください。

出力

新しい handoff の作成に成功したら、チャットではパス、現在のステータス、次のアクションのみを簡潔に示してください。 Handoff の本文全体や証拠台帳を出力しないでください。

再開時には、完了した作業、残っている作業、ブロッカー、直ちに行う次のアクションを、理解しやすい形で説明してください。

.tigerkit/ をアーカイブ、現在のポインター、またはグローバル状態として使用しないでください。 ignore の編集は Artifact Paths の設定に限定してください。自動でコミット／公開しないでください。

Artifact Paths

成果物にはタスクの権限が必要です。書き込み／チェックアウト／転送／ignore 設定の前に、Git の除外、パス、所有権の確認について artifact paths を読んでください。コンテキスト内に同一の内容がある場合はそれを再利用し、不確かな場合はハッシュを確認して、変更や消失があれば読み直してください。安全性は必ず再確認してください。保存先が明示されていない場合は .tigerkit/ を使用してください。チャットのみの場合は、ファイル／ignore の設定とこの参照を省略してください。この指示は、無関係な変更や公開の権限を付与しません。許可された非機密情報のクリーンアップでは、新しいディレクトリとサポートされているゴミ箱を優先してください。対象は、記録されたリテラルな解決済み絶対パスの実行所有物に限定し、cd とワイルドカード／相対パスによる削除は行わないでください。

読者向け結果の概要

結果、実際に行った検証、重要な制約、直接の成果物リンクを簡潔に返してください。 計画や省略した確認と、実行した作業を区別してください。未実施の手動確認、および実際のクリーンアップ、ブロッカー、ユーザー対応の詳細を残してください。 未検証の完了やクリーンアップを主張しないでください。所有者が求める成果物、公開プレビュー、承認境界、機械可読な戻り値、正確なステータス／フッター、最後の質問ブロックを保持してください。入れ子になった戻り値は簡潔にし、空のセクションは省略してください。

出力表記

ASCII の番号付け（1. Item、(1) Item）と - Item を使い、丸囲み数字やキーキャップ数字は使わないでください。 省略記号を使わず、例を含め、クリック可能な完全な絶対ファイルパスを示してください。 編集が許可されていない限り、コード、コマンド、識別子、URL、引用、確認済みの UI ラベルは正確に保持してください。

複数の共通属性を比較するチャットでは、列を絞った GFM パイプテーブル（約4列、ヘッダーと短いセル）を使い、それ以外ではリストを使ってください。ボックス罫線、フェンス付きテーブル、空のテーブルは使わないでください。所有者固有のプレビューを優先し、公開用の本文とファイル成果物では、それぞれ独自のテーブル形式を保持してください。

レンダリングされる Markdown の本文では、範囲にハイフンを使い、文字としてのチルダは \~ としてエスケープしてください。コード、引用、識別子は正確に保持してください。

許可された一時入力ファイルについては、作成と使用の前に「成果物パス」に従ってください。あらかじめ入力済みのテンプレートは、完成した入力ではありません。これは書き込み権限を付与するものではありません。

ユーザーからの質問

事実を調査し、既存の許可を再利用してください。ユーザー自身の判断については 質問ラウンドを参照し、それ以外はそのまま進めてください。 チャットでの回答が1件だけの承認であっても、独立した --- の後に、 項目ごとに ❓ **Q<n> · <title>**: <question> と ➡️ <recommendation> を記載してください。 確定した前提に関する質問のみを行い、承認の確認とは分けてください。 質問は最後に記載し、その前にステータス、リスク、計画を記載してください。

スキルへのフィードバック

再利用可能なインシデントについては、秘密情報を含まない最小限の証拠を現在の会話に残し、tk-retro を提案してください。ユーザーから依頼がない限り、永続メモリには書き込まないでください。 起動、フィードバック成果物、インストール済みスキルの編集、公開には、それぞれ所管のワークフローを通じた個別の許可が必要です。この参照だけでは、いずれの許可も付与されません。