grill-me

ステップ 0 — キットはここにありますか？ このスキルはキットのファイルを読み取ります。一度確認してください。 ls ${CLAUDE_SKILL_DIR}/../../../tokens >/dev/null 2>&1 && echo KIT_OK || echo KIT_MISSING KIT_MISSING の場合、インストールされたのはスキルフォルダーだけです。これは npx skills add の動作です。その旨をはっきり伝え、 npx ux-ui-agent-skills init またはプラグインのインストールを案内して、そこで終了します。 開けなかったファイルの内容を推測してはいけません。

ゲートは、誤って構築された画面を検出します。このリポジトリには、誤った要件に沿って正しく構築された画面を検出するものはありません。コストのかかる手戻りはそこから生じます。評価を4回実行したところ、ゲートでは14/14のスコアを獲得したにもかかわらず、/critique ではすべての指摘が、どのゲートにも検出できない判断ミスとして手戻り扱いになりました。

このコマンドでは、こうした種類の失敗を防ぐため、最初に5分をかけます。

対象：$ARGUMENTS（これから構築するものです。明確でない場合、そこが最初の質問になります）。

1. 質問する前に読む

リポジトリにすでに答えがあることを尋ねるのはノイズであり、答えても無駄だとユーザーに思わせてしまいます。質問を一つでも書く前に、次を確認します。

• 既存のブリーフ、CLAUDE.md、BRIEF.md、または reference/ フォルダーを探します。
• 既存のテーマを探します：${CLAUDE_SKILL_DIR}/../../../tokens/*.json、design-tokens.json、theme.css。 既存のテーマがあれば、テーマに関する質問への答えは出ています。尋ねてはいけません。
• 周辺の画面とコンポーネントを確認します。フレームワーク、規約、コンポーネントの一覧は、通常、未知ではなく確認できます。

この確認後に残る質問は、コードから本当に答えを得られないものだけです。

2. 質問バンク — ゲートでは検出できない項目別

次の中から選びます。すべて尋ねてはいけません。

目的と主役

• 誰のためのもので、ユーザーが完了するために訪れたタスクは何ですか？
• ユーザーの視線が最初に向かうべきものは何ですか？（4つのカードが同じ比重なら、答えは「何もない」です。これはデザイン以前の構成上の問題です。）
• ユーザーにとって成功とはどのような状態ですか？画面を離れるとき、何を終えていますか？

コンテンツの実態

• 項目が0件の場合はどう見えますか？1件の場合は？400件の場合は？
• 実際のユーザーが入力する最長の文字列は何ですか？60文字のプロジェクト名、9桁の金額、改行可能なスペースのないメールアドレスでしょうか？
• どの数値が実際の値で、どれがプレースホルダーですか？実際の値としてリリースされるプレースホルダーは、ユーザーにすぐ見抜かれる嘘です。

取り消せない操作

• どの操作がデータを破壊するか、取り消せない操作ですか？それらをどのように確認しますか？ （破壊的な操作は、表示されるすべての場所で危険を示すバリアントを使います。トリガーと確認ダイアログの両方が対象です。青い「削除」は即座に不合格です。）
• 操作が失敗した場合、どうなりますか？ユーザーには何と表示され、次に何ができますか？

テーマとプラットフォーム

• 新しいテーマですか、それとも既存のテーマですか？新しい場合、どのような方向性で、ダークモードも提供しますか？
• 対応が必要な最小幅はどれくらいですか？（キットの下限は280pxです。）
• 成果物に使うフレームワークは何ですか？RTL、AA、またはAAAへの対応は必要ですか？

範囲と完了条件

• 画面またはコンポーネントはいくつ必要で、明確に対象外となるものは何ですか？
• 完了とするために何を満たす必要がありますか？どのゲートを通過し、/critique は合格基準に含まれますか？

3. 質問する際のルール

• 質問は最大7つ、一度にまとめて尋ねます。 1つずつ小出しにするのは、誤った前提を置くより悪いことです。
• すべての質問が作業内容を変える必要があります。 どちらの答えでも同じものを構築するなら、それは質問ではなく既定値です。既定値を採用し、その旨を伝えます。
• 適切に選べることは尋ねてはいけません。 判断することも仕事の一部です。意図、コンテンツ、制約について尋ね、残りは自分で決めます。

4. 尋ねなかったことはすべて、前提として書き残す

黙って置かれた前提は、推測と区別できません。それぞれについて、前提とした内容、採用した既定値、誤っていた場合の影響を1行で記します。

Assumption: no dark mode requested -> shipping both anyway (the theme is already
dual, so the cost of including it is zero and the cost of retrofitting is not).

5. 出力：後から確認できるブリーフ

作業ファイルと同じ場所に、次の形式で BRIEF.md を作成します。

# <what is being built>

Goal            one sentence, from the user's side
User and task   who, and the task they came to finish
Deliverables    exact list; N screens means N screens
Lead            the one thing the eye lands on first
Content reality empty / one / many, longest string, real vs placeholder
Irreversible    which actions, what confirms them, what failure reads like
Theme           source of truth, dark mode, brand direction
Platform floor  narrowest width, framework, RTL, AA or AAA
Out of scope    what this is deliberately not
Assumptions     each with its default and its cost if wrong
Done when       the gates that must pass, and whether /critique is part of the bar

このファイルは、/critique と後からレビューする人が異議を唱える対象です。会話の中にしか存在しないブリーフは確認できないため、ブリーフとは言えません。

6. 次に、構築してから、その成果を証明します

/grill-me -> 構築 -> /gate -> /critique。このコマンドで曖昧さを取り除きます。品質を生み出すものではなく、何かを採点するものでもありません。また、成果をレンダリングして自分で確認することの代わりにはなりません。