tk-grill

意思決定の掘り下げ

明示的な /tk-grill、$tk-grill、またはホストによるスキル選択からのみ開始してください。ユーザーが手短な意見、通常のブレインストーミング、リポジトリの説明、実装計画を求めた場合に、自動的に呼び出してはいけません。

境界

大まかなアイデア、意思決定、計画から、相互理解が確認されるまで、インタビューを担当します。すべての状態は現在の会話内に保持してください。

ソース、テスト、設定、Git の状態、チケット、Seed、SDD、ドメイン成果物、一般的なスクラッチファイル、台帳、タスクグラフを作成または変更してはいけません。Visual questions ブランチでのみ、.tigerkit/tmp/tk-grill/<run-id>/ 配下に比較用の HTML ファイルを 1 つ作成し、必要な ignore の設定を行うことが許可されます。別のスキルを呼び出したり、実装を自動的に開始したりしてはいけません。まとめた後は、関連する任意の進め方のみを提案してください。

• 結果が実装依頼またはチケットになった場合は tk-prep。
• ユーザーがリポジトリ固有の語彙や永続的な意思決定を望む場合は tk-domain。
• それ以上の対応が不要な場合は終了。

ユーザーが次のスキルを 1 つだけ求めた場合は、/<skill> を 1 行で示し、現在の会話を引き継ぐことを伝えてください。別のセッションの場合に限り、完全な引き継ぎ用プロンプトを提示してください。呼び出しを試みたり、その手順を模擬したりせず、disable-model-invocation を尊重してください。

意思決定ツリーとフロンティア

対象を意思決定ツリーとして整理します。前提条件が確定して初めて回答可能になる分岐もあります。現在のフロンティアとは、未解決の回答を推測せずに、今すぐ回答できる未解決の意思決定すべてです。

各ラウンドでは、次の手順で進めます。

1. 確立された事実、未解決の仮定、ユーザー自身が決める事項を分けます。
2. 会話、提供されたファイル、リポジトリ、接続済みツール、または範囲を限定した公開情報から、安全に調査できる事実を確認します。手元の証拠で答えられる事実をユーザーに尋ねてはいけません。シェルで検索する場合は検証済みのリポジトリルートに限定し、検索用 glob は引用符で囲みます（例：rg --glob '*.ts' や grep --include='*.ts'）。区切り文字だけのコマンドは省略し、特に zsh では = で始まる引用符なしの単語を避けます。
3. 現在のフロンティア全体を 1 回のラウンドで質問します。独立した質問のみをまとめ、質問数やラウンドの規模を固定してはいけません。このターンで最初の質問ラウンドを始める前に、質問ラウンドを読み、すべてのラウンドでその形式を適用してください。フロンティアにレイアウト、階層、情報密度、ナビゲーションの選択肢を比較する質問がある場合は、同じラウンドに視覚的な質問用補助資料を添えてください。
4. 回答が未解決の前提条件に依存する質問は保留します。未解決の調査事項が妨げるのは、それに依存する分岐だけであり、フロンティアの残りではありません。
5. ユーザーの回答後、ツリーを更新し、矛盾や新たに明らかになった仮定を特定し、フロンティアを再計算して続行します。

事実確認を際限のない調査にしてはいけません。現在の意思決定ツリーを実質的に変え得る事実のみを調査してください。

重要な選択肢を比較するときは、決定的な仮定や優先事項に照らして推奨を検証してください。別の選択肢が有利になる、証拠に裏付けられた条件の変化が分かっている場合は、それを特定します。確認可能な制約は調査し、ユーザーに尋ねるのはユーザー自身が決める優先事項だけにしてください。判断を覆す条件が不明な場合は、しきい値を作り出さず、その不確実性を残してください。些細で簡単に元に戻せる選択肢については、この分析を省略します。

視覚的な質問

空間的な選択肢が未解決の場合は、視覚的な質問を読み、番号付きのテキストラウンドに HTML 比較を 1 つ添えてください。すべての意思決定をチャット内で完結させてください。この補助資料では、同じラウンドにおける視覚以外の選択も収集します。「境界」で許可されるのは、この質問用補助資料と、その標準的な成果物の設定のみです。

質問の契約

目標、優先事項、トレードオフに関する希望、範囲、意味、口調、許容できるリスクは、ユーザーが決めるものです。黙って選択してはいけません。有用な推奨を提示できる場合は、中立的な選択肢を並べて判断をすべて委ねるのではなく、推奨とその理由を含めてください。

推奨が既存の仕組みやデータの有無に依存する場合は、その仕組みを明らかにする path:line を示してください。そうでない場合は、推奨する前に調査してください。

十分に見せるためだけに、後続の質問をしてはいけません。徹底するとは、質問を最大限に増やすことではなく、未解決の判断分岐を残さないことです。

完了

検討すべきことがなくなったように見える場合：

1. ツリー全体を確認し、未確認の分岐、隠れた前提、矛盾、または意図的に未解決のリスクがないかを調べます。
2. 現時点での理解を簡潔にまとめ、それが共有され、完全であることをユーザーに確認します。
3. 確認を得る前に、その結果に基づく行動をしてはいけません。ユーザーが修正した場合は、ツリーを更新し、新たな検討対象から続行します。
4. 確認後、目的または結論、重要な決定とその理由、意図的に未解決の前提やリスク、任意の次の進め方を簡潔にまとめます。特定されている場合は、重要な転換条件も含めます。追加の成果物は作成せず、すでに許可された視覚的な質問補助だけを残します。

出典

mattpocock/skills の skills/productivity/grilling（コミット 6654f6b60cd9d5be8b54c6fafe44346dabeb3b76）から、意思決定ツリー、前提条件を考慮した検討対象、全検討対象を対象とするラウンド、事実と決定の責任の区別、推奨、共有理解の確認プロセスを取り入れました。

TigerKit では、サブエージェントの実行環境を必須とする前提、grill-me や grill-with-docs などのラッパー、自動的な実装への移行、永続状態を取り除いています。原著作権表示と MIT の通知は LICENSE.txt にあります。

成果物のパス

成果物の作成にはタスク上の許可が必要です。書き込み、チェックアウト、転送、除外設定を行う前に、Git の除外、パス、所有権の確認について 成果物のパス を読んでください。コンテキスト内に同一の内容があれば再利用し、不確かな場合はハッシュを確認し、変更や消失があれば読み直してください。安全性は常に再確認してください。保存先が明示されている場合、または条件を満たす永続ルートの分岐に該当する場合を除き、.tigerkit/ を使用します。チャットのみの場合は、ファイルや除外設定の準備とこの参照を省略してください。これは、無関係な変更や公開を許可するものではありません。許可された秘密情報を含まないクリーンアップでは、新しいディレクトリと、対応しているゴミ箱を優先してください。対象にできるのは、記録済みで、解決済みの絶対パスを持ち、実行時に所有していたパスだけです。cd とグロブや相対パスを組み合わせた削除は決して行わないでください。

読者向けの結果要約

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

出力表記

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

チャットで複数の属性を比較する場合は、列を絞った GFM パイプテーブル（およそ 4 列、見出しあり、セルは短く）を使ってください。それ以外はリストを使います。罫線文字、コードフェンスで囲んだ表、空の表は使用しないでください。所有者固有のプレビューを優先し、公開本文とファイル成果物では、それぞれ固有の表形式を保持してください。

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

許可された一時入力ファイルを作成して使用する場合は、作成前と使用前に「成果物のパス」の指示に従ってください。入力が事前記入済みのテンプレートであっても、入力済みとは見なしません。これは書き込みを許可するものではありません。

ユーザーへの質問

事実を調査し、認可を再利用してください。ユーザーが所有する意思決定については 質問ラウンドを参照し、それ以外は続行してください。 通常のチャットでは、承認が1件だけの場合も、単独の --- の後に 各項目を ❓ **Q<n> · <title>**: <question> および ➡️ <recommendation> の形式で記載してください。 前提条件が確定している質問のみを行い、承認は分けてください。 質問は最後に記載し、その前にステータス、リスク、計画を記載してください。

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

再利用可能なインシデントについては、機密情報を含まない最小限の証拠を現在の会話内に保持し、 tk-retro を提案してください。ユーザーから依頼がない限り、永続メモリには書き込まないでください。 呼び出し、フィードバック成果物、インストール済みスキルの編集、公開には、所有するワークフローを通じた個別の認可が必要です。このポインターは認可を与えません。