tk-domain

リポジトリのドメインコンテキスト

承認の継続性

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

このスキルは、リポジトリが所有する共通言語と、簡潔で長期的に有用な意思決定コンテキストの作成または改善にのみ使用してください。 用語集とADRは別個の成果物です。これは汎用メモリストア、ルール集、アーキテクチャ文書、実装ガイド、トラブルシューティングの記録ではありません。

根拠

リポジトリのソース、製品資料、提供された会話の根拠を調査し、プロジェクト固有の具体的な用語を1つ確認してください。正規の表記、意味、有用な別表現を確認します。意味についてコードの挙動を主張する場合は、現在のソースを根拠としてください。正規の用語が製品やドメインに関する判断であり、根拠から解決できない場合に限り、ユーザーに確認してください。

最初の実際の用語を確認する前に、成果物を作成してはいけません。重複作成せず、既存のリポジトリの用語集の慣例に従ってください。

曖昧さによって成果物や判断が変わる場合に限り、漠然とした表現や多義的な表現を明確にしてください。関係性をほかの方法で解決できない場合に限り、具体例を1つ使用してください。古い用語集の記述より新しいコードや実行時の根拠を優先し、古い記述との矛盾を黙って残さず、明示してください。通常の言葉遣いの曖昧さを、ドメイン上の正式な検討事項にする必要はありません。

成果物

1つのコンテキストについて、ルートの CONTEXT.md を必要最小限の形式で作成または改善します。

# Domain Context

## Language

**<canonical term>**
<short project-specific meaning>
_Avoid_: <misleading synonym>, <unwanted translation>

_Avoid_ は省略可能です。正規の用語の一部である韓国語／英語の表記、頭字語、大文字・小文字、スペースは、正確に維持してください。

ファイルパス、クラス／関数／テーブル、デバッグのヒント、一般的なプログラミング用語、一時的な値、タスクの受け入れ基準、一般的なエンジニアリングルール、長大な製品仕様は含めないでください。動作上の不変条件は用語集ではなく、リポジトリ内で適切な担当先に移してください。

複数コンテキストへの任意のエスカレーション

既定ではルートの CONTEXT.md を使用します。モノレポであることや複数のパッケージがあることだけでは、分割の根拠になりません。同じ用語の意味が異なる、無関係な語彙が繰り返し混在する、あるいは作業者が別のコンテキストの言葉を必要とすることがまれであるなど、実際に明確な境界を持つコンテキストが存在する場合に限り、CONTEXT-MAP.md を提案してください。この構造変更には、現在のタスクに対する明示的な承認が必要です。

マップには、関係性を含む関連コンテキストのパスのみを記載し、用語集の項目を重複させないでください。承認後、各用語集を自然な境界コンテキストのパスに配置し、マップ内のすべてのパスを検証してください。

簡潔で永続的な決定

次の3つの基準をすべて満たす場合に限り、ADRを提案します。

1. 元に戻すのが難しい：方針の変更に、無視できないロールバックや移行のコストが伴う。
2. 背景がなければ意外に思われる：将来の保守担当者が、理由を知らずにその選択を取り消す可能性がある。
3. 実際のトレードオフがある：少なくとも2つの妥当な選択肢があり、理由に基づいてその中から決定した。

実装の局所的な根拠は、コードコメントまたはリポジトリ固有の適切な場所に残します。チケットの計画、テスト方法、コーディング規約、単純なライブラリ選定、簡単に元に戻せる選択をADRにしないでください。

リポジトリで確立されているADRの規約を優先してください。そのような規約がない場合は、最小限の代替形式として docs/adr/0001-<slug>.mdを使い、無関係なファイルを読まずに、ファイル名の最大番号に1を加えます。最初の実際のADRが必要になるまで、docs/adr/は作成しません。代替形式にはタイトルと、通常は背景、決定、その理由を述べる1～3文を記載します。ステータス、代替案、結果、その他の項目は、情報を伝える場合にのみ追加します。

新しいADRを提案する前に、その決定に関係する既存のADRの根拠だけを読みます。現在のコードと照らし合わせ、依頼が重複、詳細化、または置き換えのどれに当たるかを判断します。既存の根拠を黙って上書きしたり、矛盾させたりしないでください。決定に変更がなければ再利用し、前提が変わっている場合は、変更された前提と明示的なrefine or supersedeの方針を示してrevisit ADRを提示します。無関係なADRやコンテキストのツリーを走査しないでください。

🔴 チェックポイント · 🛑 停止

書き込みの前に、用語または永続的な決定、根拠、正確な対象パス、提案する文言、除外事項、およびこれがルートの詳細化、承認済みの複数コンテキストにまたがる変更、新規ADR、詳細化、置き換えのいずれに当たるかを提示します。実行する変更そのものについて、現在のタスクでの承認を得てください。根拠またはスコープにずれが生じた場合、承認は無効になります。

承認後、最小限の成果物をアトミックに書き込み、再度読み込みます。用語集の用語と_Avoid_の値が正確であること、またはADRに根拠、決定、その理由、既存の根拠との関係が保たれていることを検証します。除外した実装やルールの内容が、どちらの成果物にも含まれていないことを確認します。中央のTigerKit状態、ホスト固有のメモリ、学習コーパス、自動リポジトリスキャンは作成しないでください。

変更したパス、標準用語または決定、根拠、検証結果、実際のステータスを返します。 Pass | Blocked | Unverifiable | Fail

次のステップとしてユーザーのみが実行できるスキルが求められた場合は、/<skill>を1行で示し、現在の会話が引き継がれることを伝えます。完全な引き継ぎプロンプトを提示するのは別のセッションの場合に限ります。disable-model-invocationを尊重し、呼び出したり、呼び出したかのように振る舞ったりしないでください。

成果物のパス

成果物の作成にはタスク上の権限が必要です。書き込み、チェックアウト、転送、除外設定を行う前に、Gitの除外、パス、所有権を確認するため成果物のパスを読みます。同一のコンテキスト内にある内容が一致する場合は再利用します。不確実な場合はハッシュを確認し、変更や消失があれば読み直します。安全性は必ず再確認してください。宛先が明示されている場合、または適格な永続的ルートの条件に該当する場合を除き、.tigerkit/を使用します。チャットのみの場合は、ファイルや除外設定の準備、およびこのリファレンスの確認を省略します。これは無関係な変更や公開の権限を与えるものではありません。承認済みの機密情報以外の削除では、新しいディレクトリと、サポートされているゴミ箱機能を優先します。対象には、記録済みのリテラルな解決済み絶対パスで、実行時に所有しているものだけを指定します。cdとグロブまたは相対パスによる削除は決して行わないでください。

読者向けの結果概要

結果、実際に行った検証、重要な制約、直接参照できる成果物へのリンクを含む、簡潔な概要を返します。計画または省略した確認と、実際に実行した作業を区別します。未完了の手動確認、および実際に必要な後片付け、ブロッカー、人による対応の詳細は残します。未検証の完了や後片付けを主張しないでください。所有者が必須とする成果物、公開プレビュー、承認の境界、機械向けの返却内容、正確なステータスやフッター、最後の質問ブロックは保持します。入れ子の返却内容は簡潔にし、空のセクションは省略します。

出力表記

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

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

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

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

ユーザーからの質問

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

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

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