tk-learn

スキル学習

承認の継続性

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

明示的な再利用可能スキルの作成意図、または意味的な改善意図がある場合は、まずドラフトを準備します。 適用できるのは、現在の依頼または以前の承認で同じ候補と対象が明示的に承認されている、 ユーザーまたはリポジトリが所有する正規の対象に限ります。必要な権限を備えた、検証済みの learn-ready 引き継ぎも対象に含まれます。外部からインストールされた上流版またはベンダー版は、 ドラフトの作成に限ります。書き込み可能であることや、一般的な改善依頼だけでは所有権は確認できません。 診断のみの引き継ぎ、一般的な相談、ファイルパスだけの提示、単発のヒントは、適用の権限を与えません。 これは TigerKit における唯一の意味的な create | improve | merge の編集担当です。通常の実装、 永続ルールの編集、ホスト間のインストール、公開は担当しません。

候補を設計する前に、スキルの品質を読みます。上流の出所、 昇格への適合性、説明と指示の簡潔さ、動作の比較、互換性を扱います。証拠の経路は 十分なものを1つ選びます。再利用可能な意図に加えてリポジトリの証拠がある場合や、別の 記載済み経路で十分な場合に、繰り返し発生した事例を重ねて求めてはいけません。未検証の主張は 保留中のドラフトに反映できますが、適用の承認条件を満たすことはできません。安全に確認できる事実は、 ユーザーに尋ねずに調査します。

候補と検証

1. 再利用可能な目的、根拠となる情報源、最小限の変更を明確にします。現在のスキル、既存の別の担当箇所、デフォルトのモデル動作、短いルールを比較します。既存のリポジトリ標準のチェックのほうが適切な担当箇所であれば、スキルの権限で実装せず、その範囲に限定した変更を提案します。
2. 対象がリポジトリまたはユーザーの所有物であることと、現在のホストにおけるネイティブなパスを正確に確認します。ホスト上の場所を捏造したり、書き込み可能なベンダーパッケージを所有物として扱ったり、複数のホストに展開したりしないでください。不明点は保留のままにします。
3. 操作、名前、呼び出しの種類、肯定／否定のトリガー、最小限の手順を作成します。ルーティングの判別条件は説明に、実行手順は本文に記載します。スキルを作成する場合は、小文字とハイフンで構成された、64 文字以内の動詞形の名前を使い、既存の名前を確認します。
4. Skill quality を使って、現実的な成功ケースと境界ケースで、スキル導入前の動作と候補を比較します。トレーニング時と検証時のルーティングを個別に確認し、ソースが存在するかどうかではなく、有意な結果、維持すべき境界、ポータブルなコアとホストとの互換性を確認します。具体的な懸念が解消されたら、不要な再テストを止めます。証拠がないことは合格を意味しません。

ドラフトには、レビュー可能なパケットを 1 つだけ用意します。

• Action：create | improve | merge | no-op、操作を表します。進行状況を表す状態ではありません。
• Status：Pending | Blocked | Pass、唯一の進行状況を表します。
• Candidate：目的、最小限のドラフト、名前／種類／トリガー、対象外事項。
• Evidence：ソースと、検証済み／未検証の主張。ソースを保持／調整／省略する判断も含めます。
• Checklist：残っているテストを含む、ゲートの結果と以下の証拠。
• Target path：スキルからの相対パスで示す正規の対象パスとドラフトパス、および実際の未変更／変更状態。非公開リポジトリやホームディレクトリのプレフィックスは一般化し、信頼できる対話環境では正確なネイティブ識別情報を保持します。
• Next step：具体的に残っている次のアクションを 1 つ、または「なし」。

成功、プレッシャー、境界の結果を観察できる現実的な検証シナリオ、スキル導入前の結果、候補の結果、未実施のチェックを含めます。参照情報を読んだだけで動作を主張しないでください。ドラフトでは非公開の対象識別子を一般化します。正規の書き込みを行う前に、現在の信頼できる対話環境で正確な適用先を保持し、解決してください。

Pending は、検証／承認待ちの提案や Action: no-op も含め、正規の適用が行われていないことを意味します。Blocked は特定された阻害要因があること、Pass は正規の適用が完了し、検証済みであることを意味します。結論に至った no-op も未適用であり、文章中にステータス欄は必要ありません。保存された提案を、適用済みのスキルと同一視してはいけません。適用を報告できるのは、正規の書き込みと検証が実際に成功した場合に限ります。別個の Decision または Disposition の状態フィールドを追加しないでください。単純な no-op では、その理由と変更がない結果だけを記載すればよく、パケットは不要です。

適用ゲート

チェック	合格を示す証拠
昇格	1つの証拠ルートと再利用可能な修正が、Skill の品質基準を満たしている
適合性	既存のオーナー／デフォルト機能と、機械的な防止策を比較している
アイデンティティ	ユーザーまたはリポジトリが所有する正規の対象、操作、名前／種類、明確に区別できるトリガーを確認している。外部のアップストリームからインストールされたコピーやベンダー提供のコピーは、決して合格としない
挙動	トレーニング／検証への振り分けと、現実的な成功時および境界での挙動が要件を満たしている
ベースラインと互換性	Skill なし／導入前との比較、および対象ホストとの互換性を確認している
権限	有効なリクエストまたは以前の承認が、この候補と対象を正確に対象としている

正規の書き込みを行う前に、該当するすべての行に合格する必要があります。引き継ぎやアップストリームの例があっても、これらのチェックは免除されません。適用の権限が得られるまでは、正規のパスとインストール可能な Skill のドラフトディレクトリに変更を加えないでください。以下のレビュー可能な Markdown 提案を書き込むことは、正規の適用には当たりません。該当する承認は、再度の呼び出しやフェーズ境界に関する質問をせずに再利用してください。対象の変更、重要なスコープ／証拠の矛盾、またはユーザー所有の判断の欠如がある場合は、まず解決する必要があります。

匿名ドラフトのチェックポイント

再利用可能な候補については、共有の追跡、除外設定、安全なパスのチェック後に、現在のリポジトリ内の .tigerkit/tmp/tk-learn/<run-id>/proposal.md に、GitHub Issue または PRD の Markdown ドラフトを1つ作成することをデフォルトとします。その絶対パスを報告してください。リポジトリが特定できない場合に限り、安全なホストのスクラッチパッドまたは実行専用の OS 一時ディレクトリを使用し、その理由を説明してください。リポジトリのチェックまたは書き込みに失敗しても、一時ディレクトリへのフォールバックは許可されません。明示された保存先や、ファイルを作成しないというリクエストがあれば、それに従ってください。

提案の文章はユーザーの言語で書いてください。対象 Skill の言語にするのは、正確な置換テキスト、識別子、コードのみとし、その旨をそばに明記してください。

明示的な永続保存、または引き継ぎ／復旧の場合のみ .tigerkit/learn.md を使用し、別の有効な候補がある場合はその内容を保持してください。別の状態モデルやアーカイブは追加せず、同じパケットに Updated を加えてください。安全でシンボリックリンクではない、実行専用の保存先を使用し、同じディレクトリ内の一時ファイルを使ってアトミックに置き換えてください。報告または承認の依頼をする前に、ファイル全体を再読み込みし、パケットのフィールド、シナリオ、内容を確認してください。書き込みまたは読み戻しに失敗した場合は、そのファイルに関する手順と正規の適用を中止してください。読み取れないドラフトへの承認を求めてはいけません。 再現または修正判断に必要な事実だけを残してください。それ以外の具体的な詳細 （フレームワーク／API、製品／機能、内部／外部の区分、ベンダー／ツール名、変更内容）は、 最小限の抽象的な条件に置き換えるか、削除してください。この必要性の判定は、 呼び出し元が提示した例や引き継ぎ文面にも適用してください。それらは入力であり、 承認済みの草案ではありません。条件を変更すると再現または修正の判断が変わる場合は、 具体的なバージョン、プラットフォーム、その他の条件を残してください。 書き始める前に、チケットキー、組織名／製品名、独自のドメイン用語、非公開リポジトリ名／パス、 人物名／メールアドレス、ホームディレクトリのパス、ユーザーの依頼文の逐語引用、 スクリーンショット、生ログを一般化してください。公開アップストリームの識別子／リビジョン、 スキル固有のファイル名／セクション名、一般化した再現手順は残してください。トークン、 Cookie、パスワード、その他の秘密情報は決して含めないでください。元の識別子を残す明示的な 依頼があれば匿名化の対象外にできますが、秘密情報は引き続き除外してください。 読み返した後、ファイル内を検索して、セッション中に把握した識別子（リポジトリ名、 チケットの接頭辞、組織のドメイン、ホームディレクトリのパス）を確認し、その他の識別情報や 秘密情報も調べてください。残っている具体的な詳細ごとに、それを削除しても再現または修正の 判断が変わらないかを確認してください。どちらも変わらない場合は、抽象化するか削除してください。 識別子のスキャンで一致がゼロ件だったとしても、それだけで匿名化が完了したとは言えません。 未承認の一致を削除し、両方の確認を繰り返してください。実際に行った識別子／秘密情報の スキャン結果と必要性の確認結果を、短い1行で報告してください。一致した機密情報の値は 決して報告しないでください。元の識別子を残す依頼があった場合は、意図的に残した識別子と 除外した秘密情報を区別してください。匿名化済みの草案だと主張しないでください。

ユーザーが所有していない、外部のアップストリームからインストールされたコピー／ベンダー版の場合は、 草案のパス、簡潔な概要、スキャン結果を最後に記載してください。アップストリームの チェックアウトへの適用、ローカルインストールへの変更、アップストリームへの課題／PRの公開を 提案しないでください。草案を転送するかどうかはユーザー自身の判断です。このスキルは、 ユーザーのアカウントを通じた寄与や、更新管理されているベンダー版の変更は行いません。 ユーザーが所有するソースチェックアウトが明示的に選択された場合は、別の適用先として扱い、 インストール済みコピーを所有物と見なすのではなく、適用ゲートを通じて所有権と具体的な権限を 確認してください。適格な所有対象については、草案のパス、簡潔な概要、スキャン結果を報告し、 その後に残る実行可能な対応を示してください。その他のゲートを通過していても、具体的な適用権限が ない場合は、question roundsに従って、番号付きの承認質問を メッセージの最後の実質的なブロックに記載してください。実際の回答を待ってください。 草案の承認が解決するのは、明示された範囲だけです。

Decision／Dispositionを含む古いパケットを再開する場合は、検証済みの操作、 実際の対象の状態、残作業だけを現在のパケットに引き継いでください。従来の pendingまたはappliedというラベルや成果物の存在だけでは、ユーザーの承認、 正規の変更、検証を証明できません。ラベルを移行するためだけに、古いファイルを書き換えないでください。

作成して返却

外部のアップストリームでインストールされた／ベンダー管理の対象では、レビュー済みのドラフトまでで停止してください。正規のアプリケーションには入力せず、その適用権限も求めないでください。適格な所有対象のみ、以下の手順に進めます。 適用する前に、具体的な候補を提示してください。他のすべてのゲートを通過し、適用に関する正確な権限だけが不足している場合に限り、自然な承認確認を1つだけ行ってください。それ以外の場合は、既存の権限の範囲内で続行してください。書き込み前の内容を保持し、アトミックに書き込み、再読み込みしてから、フロントマター、リンク、評価、対象ホストでの呼び出しを検証してください。 書き込みまたは検証に失敗した場合は、部分的な状態を正確に報告してください。この実行による変更を安全に元に戻せることが証明されている場合に限り、復元または削除してください。それ以外の場合は変更をそのまま保持し、Blocked | Unverifiable と報告してください。

明示的な適用承認を得た後は、同じセッションで適用ゲート、対象への正確な書き込み、再読み込み、検証まで続けてください。ドラフトのみの呼び出しでは、正規のパスには手を加えずに停止してください。適用がすでに承認されているリクエストでは、冗長な確認を挟まず続行してください。

最初に結果とスキルが実際に変更されたかどうかを伝え、その後に次のアクションまたは重要な制約を示してください。ドラフトのパスは存在する場合にのみ記載してください。報告は簡潔にし、パケット、未加工のログ、認証情報、繰り返しのステータス項目を出力しないでください。機械可読な引き継ぎには、Action と Status をそれぞれ1回だけ使用してください。何も変更しない場合は、形式的な承認確認をせずに終了してください。このスキルの権限では、コミット、プッシュ、公開、自動アーカイブ、またはユーザーが別途選択したスキルの呼び出しを行わないでください。

成果物のパス

このスキルのタスクで許可されている場合に限り、成果物を作成してください。成果物の書き込み、チェックアウト／転送用の一時領域、または除外設定を行う前に、成果物のパスを読み、Git の除外、安全なパス、所有権の各チェックを適用してください。単一の学習提案の既定の保存先は、現在のリポジトリ内の .tigerkit/tmp/tk-learn/<run-id>/proposal.md とし、絶対パスを報告してください。リポジトリを特定できない場合に限り、安全なホストのスクラッチパッドまたは実行専用の OS 一時ディレクトリを使用し、その理由を説明してください。リポジトリのチェックまたは書き込みに失敗しても、この代替手段の使用は許可されません。永続的な出力先には引き続き .tigerkit/learn.md を使用し、明示的に指定された保存先を尊重してください。会話内だけで完結する作業ではこの参照を省略し、ファイル作成や除外設定を行わないでください。成果物の取り扱いによって、無関係な変更や公開の権限が与えられることはありません。

出力表記

生成する見出し、リスト、選択肢、表、図、要約では、(1) Item や 1. Item のような ASCII の番号を使用し、マーカーの後にスペースを入れてください。順不同の項目には - Item を使用してください。Unicode の丸数字・囲み数字、1文字の括弧付き数字、キーキャップ絵文字を項目マーカーとして生成しないでください。ターミナルのレンダラーで隣接するテキストと重なることがあります。コード、コマンド、URL、引用、識別子、検証済みの UI ラベルは、編集が明示的に許可されていない限り正確な形のまま保持してください。このルールは周囲の説明に適用してください。

ユーザーが編集できる一時入力ファイルの作成が許可されている場合は、空のファイルや未加工のテキストファイルではなく、必要なキーを含み、未入力のテキスト値を空文字列にしたプレーンな JSON オブジェクトのテンプレートを一貫して提示してください。初期テンプレートのサイズがゼロでないことは、入力完了の判断基準になりません。作成および消費の前に、担当パッケージの「成果物のパス」の入力に関する分岐を適用してください。この表記ルールによって、成果物を書き込む権限が与えられることはありません。

ユーザーからの質問

ユーザーが所有する確認事項、選択、承認を送信する前に、このターンで質問のラウンドを読んでください。回答可能な質問をすべてまとめて、プレーンチャットで一度に尋ねてください。まず事実を確認し、既存の権限を維持し、決定事項が残っていない場合は質問の手順を省略してください。通常の TigerKit に関する質問には、質問ツールを使用しないでください。

すでによく知っている場合でも、最低限、次の形式にしてください。

❓ **Q1 · <short title>**: <question and relevant choices>

➡️ <recommendation and reason, when supported>

質問は---で区切ってください。質問ブロックの前にコンテキストを記載し、これを最後の実質的なブロックにしてください。その後に、計画、約束、「回答いただければ進めます」といった文を置かないでください。ただし、回答形式に関する短いヒントを1つだけ添える場合を除きます。承認を求める場合は、提案の中に埋め込まず、独立した番号付きのQにしてください。範囲が未解決の回答に左右される承認は、後回しにしてください。