tk-reflect

Reflect

再利用可能な候補を証拠から抽出する明示的な呼び出し、明確な依頼、または有効なアクティブドライブの末尾ハンドオフが1つある場合に適用します。通常の要約や実装の完了時には自動適用しません。暗黙モードはレポートのみです。以下の単一の範囲限定の診断ハンドオフを除き、別のスキルを呼び出してはいけません。

現在の会話、変更、差分、実装／テスト／レビューの結果、関連する .tigerkit/ の成果物、現在のホストで検出可能なファイルベースの永続メモリ、ユーザーが指定したソースを読み取ります。厳密に5つの軸—repo rule | repo skill | user rule | user skill | persistent memory—に分類し、propose | update | merge | no-op | discard を選択します。

ワークフロー

1. evidence：5つの軸に分類した、パス／コマンドを引用する verified | unverified の事実を作成します。アクセス失敗と既存候補の調査結果も含めます。
2. interpretation：事実とは別に、再利用に関する仮説を導き出します。
3. confidence：high | medium | low とその根拠を返します。
4. action：リポジトリ内の候補に配置基準を適用し、対象とアクションを選択します。文案の作成は別の Draft が担当します。
5. apply/receipt：候補、個別の承認、最新の対象状態を組み合わせて、遷移表の結果と参照先を提示します。候補の本文はコピーしません。

ドライブ末尾モード

Mode: drive-optimistic、Success state: Pass、Outstanding transition: final receipt がすべて含まれるハンドオフのみが、drive-optimistic reflection に定める範囲限定の権限を付与します。対象にできるのは既存の適格な repo rule のみで、.tigerkit/reflect.md に書き込みます。スキルへの昇格は行わず、Return to: tk-drive と未完了の遷移をそのまま返します。権限がない、または一致しない場合は変更せず、ドライブ末尾の成功レシートを返してはいけません。

条件付き Agent Skill 診断

根本原因に依存する propose | update | merge を昇格させる前に、以下の4つの条件がすべて確認できた場合に限り、tk-skill-diagnose に一度だけハンドオフします。

1. 特定の Agent Skill 名、または正確な SKILL.md パスがある。
2. 期待値と実測値の不一致、または測定されたリソースの異常が観測可能である。
3. 根本原因がまだ確認されていない。
4. 候補のアクションが、その原因が正しいことに依存している。

依頼は、スキルのインシデント、その振り返り、またはそのインシデントの証拠の再利用に明示的に関するものでなければなりません。過去への言及、既存の有効な診断レシート、no-op | discard、一般的な振り返りについてはハンドオフしてはいけません。ホストネイティブの兄弟ハンドオフが利用できない場合は、Diagnosis required のペイロードと Unverifiable を返します。新たな実証診断をその場で模倣してはいけません。

正確なインシデント ID、対象／パス、ホスト／呼び出し、観測されたプロンプト、期待される動作またはリソースの基準、観測された動作／メトリクス、証拠のパス／コマンド、候補／ベースラインの参照先、Caller: tk-reflect を送信します。不明点には unverified と記載します。

ハンドオフの返答後は、Reproduced と確認済みの根本原因のみを証拠として使用します。Not reproduced は、元の因果関係の主張を裏付けるものではありません。Inconclusive | Blocked | Unverifiable の場合は信頼度を low に維持し、根本原因に依存する昇格を行いません。効率性の証拠には、正確性が維持されていることも必要です。1回の実行で診断を複数回呼び出してはいけません。同じ Incident ID + target + blocker について再度呼び出してはいけません。また、診断から reflect を呼び戻させてはいけません。同等の再発は Blocked として終了します。

候補の遷移表

この表は、単独および通常の暗黙的な振り返りに適用されます。drive-tail の遷移には、そのリファレンスにある適格性、復元、および受領の表を使用します。

候補	条件	ステータス	変更
ルール `propose	update	merge`	個別の適用承認の前
ルール `no-op	discard`	適用するものがない	reported
ルール `propose	update	merge`	承認後に正確な対象へ適用／再検証済み
ルール	適用／再検証の失敗	`Fail	Blocked
スキル候補	エビデンス、正確な対象、作業中のドラフトを提示済み	pending	作成／意味的変更なし
すべての候補	検証済みのエビデンスなし	Unverifiable	なし

各候補には、次の情報が含まれます。

• Evidence：パス／コマンドと verified | unverified を含む、観測された差分／結果／反復。
• Interpretation：Evidence ID のみから導出された、再利用範囲／境界の仮説。指示的な表現や、事実のように述べる仮説は含めません。
• Confidence：high | medium | low、Basis: <Evidence IDs>、必要な場合のみ Uncertainty。
• Action：重複を避けるため、merge | no-op を優先します。ルールは継続的に適用する短い指示です。スキルにはトリガー、反復手順、入出力、および独立した価値が必要です。

次の順序で Action を選択します。既存の対象が完全に担っている場合は no-op、同じ対象に検証済みの境界が欠けている場合は update、重複する対象を統合する場合は merge、適切な対象がなく、ルール／スキルとしての条件を満たす場合は propose、一度限りのエビデンス、または未解決の未検証／矛盾するエビデンスの場合は discard です。Action は適用権限を与えるものではなく、すべてのスキル候補は pending のままです。

検出可能なファイルベースの永続メモリは、既存の資料として扱い、自動的な書き込み先にはしません。メモリが同じ振る舞いと範囲を完全に担っている場合は、no-op を選択します。メモリと候補が事実を共有していても、異なる振る舞いの軸を担っている場合は、その分離を Interpretation と Action に記録し、対象を別々に保ち、両方の正確な対象が分かっている場合に限り、相互参照を提案します。相互参照やメモリの変更は、個別に承認されるまで pending のままです。ホストのメモリパスが利用できない、または読み取れない場合は、unverified と記録します。メモリに既存の資料がないと断定してはいけません。

repo rule | repo skill では、Evidence は正規化された配置入力の生データを担い、Interpretation はルート／ネスト／スキルの境界を担い、Action は選択内容を担います。配置フィールドを重複して作成しないでください。しきい値に関するエビデンスが欠けている、または矛盾している場合、confidence は low のままとなり、昇格できません。

confidence が上がるのは、次の場合に限られます。high には、異なる発生事例／ソースタイプに由来する、独立して検証済みの Evidence ID が少なくとも 2 つあり、未解決の矛盾や反例がないことが必要です。medium には、検証済みの ID が少なくとも 1 つあるものの、反復、独立性、境界のいずれかが欠けていることが必要です。検証済みのエビデンスがない場合、または未解決の矛盾や反例がある場合は low となり、propose | update | merge への昇格はできません。

契約

リポジトリの対象はコードベース／ドメイン／ツール／チーム固有です。ユーザーの対象は複数のリポジトリにまたがって繰り返し適用されます。永続メモリは現在のホスト上にあるファイルベースの対象であり、そのネイティブパスを実証する必要があります。デフォルトは報告のみです。DESIGN、reuse-map、rule、または永続メモリのファイルにルールを書き込むには、有効な drive-tail モードにおける適格な既存リポジトリルールを除き、対象と範囲を明示した個別の承認が必要です。沈黙、作業の続行、過去の類似回答、または単独の reflect 呼び出しは承認ではありません。

新しいスキルの作成、またはスキルの意味的な更新／統合を行うのは tk-learn だけです。このスキルは、スキルに関する根拠、現在のホストにおけるネイティブな正確な対象、作業用ドラフト、および pending のみを報告します。tk-learn の呼び出しやスキルパスへの書き込みは行いません。

実行の終端ステータスは Pass | Pending | Fail | Blocked | Unverifiable | aborted です。適用可能な候補が適用判断待ちの場合は Pending、変更なしの報告が完了した場合または変更が再検証された場合は Pass、決定論的な主張または適用ゲートに違反した場合は Fail、ユーザーが停止した場合は aborted、競合がある場合または適用範囲が不明確な場合は Blocked を使用します。候補ごとの reported | pending | applied と、実行の終端ステータスを混在させてはいけません。

デフォルトでは、ファイルを変更せず、台帳も作成しません。明示的にレポート成果物を求められた場合は、対象への適用許可とは別に、以下に定める範囲内の .tigerkit/reflect.md 台帳を書き込めます。有効な drive-tail モードでは、その固有の限定的な権限の範囲で同じ台帳を書き込みます。レガシーなグローバル状態を調べたり、単発の回避策を一般化したりしてはいけません。RF-## は実行ごとの ID であり、永続的な識別子ではありません。承認後であっても、未加工の認証情報、ログ、スクリーンショットをそのまま昇格させてはいけません。

必須のソースが読み取れない場合は、パスとエラーを示して unverified とし、解釈の根拠として使用してはいけません。正確なアクセス方法／パス／コマンドが示された場合に限り、一度だけ再試行します。それ以外の場合は Unverifiable で修正します。適用／再検証の失敗については、遷移表に従います。

CHECKPOINT / STOP

有効な drive-tail モード以外では、対象、根拠、確信度、アクションを示した後、個別の明示的な適用承認を求めます。その前は pending | reported で停止します。drive-tail モードでは質問をせず、適格条件とロールバックのチェックポイントに従います。

出力の契約

発見順に RF-01、RF-02、... を一度ずつ割り当てます。チャットでは ## Disposition のみを出力し、適用承認が必要な場合に限り、その直後に判断を求める質問を挿入します。Disposition には、判断に関係する行を最大 5 行まで表示します。

ID	候補	アクション	対象	理由
RF-01	<short name>	<action/status>	<target>	<evidence refs>

長い本文の複製を避け、根拠のパスを引用してチャットを簡潔に保ちます。各 Action セルと Why セルには、人が読んでわかる次のアクションと理由を記載する必要があります。RF-## ID またはステータストークンだけでは結果になりません。行数は最大 5 行とし、追加の候補が .tigerkit/reflect.md に記載されている場合は、そのファイルを引用します。変更なしの場合は最小限にします。 ## Disposition 内に Draft ブロックを追加できるのは、アクション可能なルール／スキル候補に作業用の文案が必要な場合のみです。

drive-tail モード以外でレポート成果物を明示的に求められた場合、または有効な drive-tail 引き継ぎの場合に限り、.tigerkit/reflect.md を書き込むか置き換えます。単独の台帳には、候補ごとに ID、対象、根拠の参照、解釈、確信度、アクション、ステータス、任意のドラフトパスを記載した簡潔な行を 1 行ずつ含めます。drive-tail 固有のフィールドは、その仕様に従います。未加工のログ、トランスクリプト、差分の抜粋、繰り返しの理由、出力フィールドの複製は含めません。親ディレクトリは必要になった時点で作成し、原子的に書き込みます。スクラッチが ignore 対象でない場合は警告します。.gitignore は変更しません。 台帳には、終端ステータス、候補数、台帳自体のパス、判断が必要な ID を記録します。チャットの要約は Disposition テーブルの代わりにはならず、そのメタデータを追記してはいけません。候補がない場合は、— | None | no-op | — | 検証済みの再利用可能な根拠なし の行を 1 行出力します。

🔴 厳格なゲート · 実行可能なユーザー向け出力

スキルの標準出力契約をスキーマとして扱い、このゲートをその提示レイヤーとして扱います。必須の見出し、表、ID、ステータストークン、結果の上限、承認または安全性の境界、ホストが必須とする進捗通知、応答言語のルールは、決して削除または並べ替えないでください。応答言語のルールは、自由記述の節や文章形式の結果値すべてに適用してください。別の言語を保持するのは、標準トークン、コード識別子、コマンド、パス、正確な引用またはソースのリテラルに限ります。通常のワークフロー用語は文章であり、コード識別子ではありません。トークンを変更すると不正確になる場合を除き、翻訳してください。

最初に利用可能な自由記述欄では、前置きではなく、回答、結果、またはアクションから始めてください。複数ステップのユーザー作業では、上限を設けた番号付きステップを必要最小限にしてください。作業を継続する場合は、計画や結果を重複させずに、現在の状態と次の移行を言い直してください。完了した動作が分かるようにしてください。エラーは、観測された失敗、判明している場合は証拠に裏付けられた原因、具体的な復旧方法の順に記述してください。原因を捏造してはいけません。

脱線、儀礼的な書き出し、繰り返しの要約、締めくくりの社交辞令は省いてください。必須フィールドにすでに述べた結果が繰り返される場合は、値を結果への参照にするか、最小限に抑えてください。作業が残っている場合は、ユーザーまたはワークフローが実行する具体的な次のアクションを必ず1つだけ最後に示してください。作業が完了している場合は、次のアクションを作り出さずに終了してください。具体的な所要時間は、証拠に裏付けられ、かつ作業者の役に立つ場合にのみ示してください。

このゲートが標準出力契約またはホストハーネスと矛盾する場合は、より優先度の高い契約を守り、最初の文章値または欄の中に同じ形式を適用してください。ユーザーにラベルを付けたり、このゲートに言及したり、永続的なモードを明かしたり、このスキル外のランタイム参照を要求したりしないでください。

🔴 厳格なゲート · 最終的なユーザー向け要約

進捗コメント、内部引き継ぎ用エンベロープ、最終的なユーザー向け応答は、それぞれ別の出力面として扱ってください。ユーザー向けの最終応答では、最初の行の前に、単独の --- 行を必ず1行だけ出力し、その直後からスキルの標準結果見出しまたは結果文を始めてください。進捗コメント内や、正常なフェーズ受領通知と次のアクティブドライブフェーズ呼び出しの間には、この区切りを出力しないでください。

ユーザー向け要約に、受領通知の見出し、Outcome: ラベル、最終的な出所・ステータスブロックを表示しないでください。ホストまたはスキルが最終ステータスを要求する場合は、末尾のメタデータブロックではなく、結果を示すセクションに正確な Status: <token> の行を1行だけ出力してください。パス、ID、コミット、復旧の詳細は、ユーザーのアクションを変える場合、またはスキルの標準結果スキーマで要求される場合に限り提示してください。フェーズ受領通知は内部引き継ぎ用エンベロープとして扱ってください。アクティブな親ワークフローがフェーズ、ステータス、ID、Return to、Success state、または Outstanding transition を要求する場合、それらは親ワークフローにのみ返し、最終的なユーザー向け要約では繰り返さないでください。

出所情報は、スキルがすでに管理しているアーティファクトまたは台帳にのみ記録してください。そのような管理先がないスキルは、受領通知を保存する目的だけで管理先を作成してはいけません。また、読み取り専用のスキルは読み取り専用のままにしてください。このスキル外の共有ランタイム参照を要求してはいけません。

🔴 厳格なゲート · 応答言語

ユーザー向けの進捗、質問、要約を出力する前に、直近の明示的なユーザー言語指示から応答言語を決定してください。そのような指示がない場合は、現在のユーザーメッセージの言語を使ってください。ユーザー向けの自由記述の文と文章形式の結果値はすべて、決定した言語で記述してください。ソース、スキル本文、ツール、コードが英語だからという理由で英語に切り替えてはいけません。標準見出し、ステータストークン、ID、コマンド、パス、コード、正確な引用またはソースのリテラルは、バイト単位で変更せずに保持してください。保持したトークンの周囲は、決定した言語で説明してください。応答を返す前に、ユーザー向けの自由記述をすべて確認し、決定した言語から外れている文があれば書き直してください。

ユーザーの意思決定に関する質問

ユーザー自身が下す意思決定によって作業が進められない場合は、Recommendation の前に、単独で完結する Question を1つ提示します。意思決定に関係する根拠のみを示し、重要なトレードオフを伴う相互排他的な選択肢を2つまたは3つ提示し、(Recommended) または (추천) で終わるラベルをちょうど1つ付けます。

利用可能な場合は、ネイティブの構造化入力を使用します。Claude Code の AskUserQuestion、Codex の request_user_input、または Hermes Agent の clarify を使用してください。いずれも利用できない場合に限り、プレーンテキストを使用できます。呼び出しが失敗または拒否された場合は、入力手段が利用できないものとして扱わず、Pending | Blocked を維持してください。これは提示方法を変更するものであり、権限や停止条件を変更するものではありません。

禁止事項／アンチパターン

• 解釈を事実として提示したり、確信度を誇張したりしないでください。
• 既存のスキルを重複して作成したり、適用の承認なしに変更したりしないでください。
• 先行事例の確認で、発見可能な永続メモリを見落としたり、発見されていないホストのメモリパスを捏造したりしないでください。
• その場で診断したり、診断への引き継ぎを繰り返したり、振り返りと診断のサイクルを作ったりしないでください。
• 生の認証情報、ログ、スクリーンショット、または一度限りの回避策を推奨事項として提示しないでください。
• 候補 ID を省略、再利用、または振り直ししたり、概要を省略したりしないでください。