mcpField
T
tk-grill-me

tk-grill-me

github.com/mtgvimエージェントワークフロー193 回インストール1 日前に更新
リポジトリ

tk-grill-me について

tk-grill-meは、未解決のユーザー判断を特定し、根拠を集めて優先度順に一問ずつ確認する意思決定レビュー用スキルです。読み取り専用で、単独実行とtk-driveへの内部引き継ぎに対応します。

主な機能

  1. 01出典付きの事実収集と根拠分類
  2. 02範囲、制約、成果物、検証の記録
  3. 03未解決の判断事項の優先順位付け
  4. 04一度に一つの判断質問
  5. 05明示的な承認後にのみ確定
  6. 06単独実行とtk-driveの読み取り専用モード

活用シーン

  1. 01作業開始前のプロジェクト範囲の明確化
  2. 02出典付きの根拠による重要な選択の解決
  3. 03受け入れ基準の確認と明示的承認の取得

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mtgvim/tiger-kit --skill tk-grill-me

インストール後、Claude Code で/tk-grill-meを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
evals/
evals.json
triggers.json

詳細

決定の精査

明示的な /tk-grill-me または $tk-grill-me の呼び出し、正確なアクティブな tk-drive の決定ハンドオフ、または同じ会話内でこのスキルの pending な質問に 対するユーザーの回答で使用します。一般的な曖昧さ、成果物の存在、 一般的な後続処理、無関係な回答では自動的に有効化しません。

根拠を優先する単一の決定手順を担います。単独実行とアクティブな drive の呼び出し元は 手順、安全境界、完了基準を共有し、結果のルーティングのみが異なります。

契約

明示的な回答なしに、ユーザーの決定を確定してはなりません。沈黙、単なる進行、 事実の根拠、過去の類似した回答は同意ではありません。

呼び出しモードによって表示方法が決まります:

  • standalone:ユーザーに pending な質問を1つ、または最終的な決定結果を表示します。
  • active drive:同じ決定状態を内部的に返し、tk-drive が 次に該当する手順を直接続行できるようにします。terminal の結果、receipt、 Pass、または呼び出し元が指定した中断画面は表示しません。

読み取り専用です。ソース、Drive R/AC、単位、ADR、コミットには書き込まず、 tk-drive、新たな作業者、隣接するワークフローの所有者を呼び出してはなりません。

手順

  1. 入力の読み取り:task identity、呼び出しモード、ソース、現在の根拠、 確定済みの決定、未解決のユーザー所有の決定、pending な質問をバインドします。
  2. 事実の調査:ソースの位置を明記した verified | inferred | unavailable の事実を作成します。
  3. 明示的な制約の選別:ソースまたは要件の文が結果を直接規定し、矛盾がない場合は、 ユーザーの選択に格上げせず Constraint として記録します。結果が単に推論される場合や 別のソースと矛盾する場合、この例外は適用しません。
  4. ギャップの特定:Scope、Constraints、Outputs、Verification 全体について、 事実と decisions を比較します。
  5. 優先順位付け:安全な進行を妨げる blocker、範囲または不可逆の影響、 検証上の blocker、downstream の手戻りの順に、最も影響の大きい未解決の 決定を選びます。
  6. 質問:🙋 grill-me · 応答が必要 を出力した後、Question、 👍 Recommendation、Evidence をこの順にそれぞれ1つだけ返し、pending で停止します。
  7. 反映:明示的な回答を、該当する Decision、Constraint、Out of scope、 Output、または Verification の項目として保持します。
  8. 反復または終了:すでに回答済みの質問は繰り返しません。4つの軸すべてが整理できたら、 明示的な承認を得るため、合意された目標を1文で提示します。
  9. 確定:その文が明示的に承認された場合に限り、confirmed を返します。

単独実行の質問ターンでは、以下の packet だけをユーザーに表示します。ラベルは bold で 表示し、各項目の間に空行を入れます。Evidence では事実ごとに bullet を1つ使い、各 bullet に source と verified | inferred | unavailable を併記します。 根拠がない場合は、unavailable の事実を1つの bullet として明示します。アクティブな drive では、 この packet を表示せず、同じ状態を呼び出し元に直接返します。

🙋 grill-me · 응답 필요

**Question**
<정확히 하나의 user-owned decision>

**👍 Recommendation**
<safe default 또는 none>

**Evidence**
- <fact> (`verified | inferred | unavailable`, <source>)
- <fact> (`verified | inferred | unavailable`, <source>)

**Native status**: pending

曖昧さの台帳

台帳は会話内でのみ維持します:

  • Scope:含める動作と除外する動作;
  • Constraints:技術、運用、ビジネス上の制約、または制約が明示的にないこと;
  • Outputs:必要な動作、成果物、結果;
  • Verification:受け入れ基準と完了の根拠。

未解決の項目、確定済みの決定、未検証の仮定を分けます。 台帳はターンごとのダンプ用テンプレートではありません。質問ターンには、新たに生じた、または 変更された根拠、選択された未解決項目、質問1つだけを含めます。

事実とユーザーの判断

  • 正確なリポジトリまたはランタイムの根拠で裏付けられる現在の事実のみを自動確定し、ソースを引用します。
  • コードパターンの結論に判断が必要な場合は、inferred と表示します。
  • 事実と選択が混在する質問をする前に、現在の事実を調査します。
  • ソースまたは要件の文が結果を直接規定し、矛盾がない場合は、confirmed Constraint として 記録し、再度質問しません。その結果から派生する副作用は Assumptions または Remaining risks に残します。
  • 質問や選択肢が、リポジトリ内での使用例が0件の domain term(例:dvh、svh)に依存する場合、 選択肢を提示する前に、ユーザーに見える結果の違いを1~3行で説明し、使用例の根拠を verified | inferred | unavailable と表示します。この説明は Evidence 内に置き、 packet の外に任意の補足を作らないようにします。
  • 目標、範囲、優先順位、ビジネスルール、成功基準、新たな動作については、必ず質問します。
  • 必要な根拠にアクセスできない場合は Unverifiable を返します。ただし、独立した決定により 安全に進められる場合は例外です。
  • 確定済みの情報源が矛盾する場合は、双方を保持して決定を問う質問を1つ行い、 暗黙に一方を選んではなりません。

回答の保持と終了

自由形式の回答の意味を保持します。明言されていない内容は仮定として残します。要約によって 意味が変わる場合、確定済みの根拠と矛盾する場合、または重要な曖昧さが生じる場合に限り、 確認を求めます。

done やモデルの信頼度だけで台帳を閉じてはなりません。4つの軸すべてを確認し、 未解決の状態では次に最も影響の大きい質問を行い、最終的な合意目標の文に対する 明示的な承認を求めます。

単独実行の確定結果には、空でない ## Decisions、 ## Assumptions、## Remaining risks のみを使用します。phase/status の出所は 付けません。1つの決定には1~3行を使用し、複合セットには読みやすい2~7個の row または bullet を使用します。8個以上ある場合は、所有するソースまたは spec reference とともに 上位5~7個のみを残します。

Native status は confirmed | pending | aborted | Blocked | Unverifiable です。 Standalone はこれを Pass | Pending | Blocked | Blocked | Unverifiable に対応付けます。 Active drive は、ユーザー向けの status block を表示せず、native status を直接使用します。

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

  • 同じ決定手順を別のスキルに分割しません。
  • ユーザーに代わって決定したり、独立した決定をまとめたりしません。
  • 成果物を変更したり、下流フェーズの所有者を呼び出したりしません。
  • アクティブな drive のルーティングを、receipt や terminal の中断にしてはなりません。

コメント