brief

コンテキスト： このサブスキルは、より広範な ui-craft スキルの一つの視点です。ui-craft スキルもインストールされている場合は、まずその SKILL.md を読んで、Discovery + Anti-Slop + Craft Test を確認してから、以下の個別の視点を適用してください。

作業を進める前に、brief の形式を確認するため references/brief.md を読み込んでください。

ステップ 1：既存の brief を検出する

.ui-craft/brief.md が存在するか確認してください。.ui-craft/ に対して Read または ls を使います。

存在する場合： 内容を読み込みます。$ARGUMENTS に具体的な更新内容（「principles を更新」「対象ユーザーを変更」「対象外を追加」など）が指定されている場合は、その内容に焦点を当て、変更のないセクションはスキップしてください。それ以外の場合は brief の内容を要約し、「何を変更したいですか？」と尋ねてください。

存在しない場合： ステップ 2 に進みます。また、リポジトリのルートに DESIGN.md または design-tokens.json がないか確認してください（チームによっては既に管理しているエコシステム上の慣例です）。存在する場合は読み込み、質問し直すのではなく、その内容をもとに brief の回答を事前に記入してください。情報源も明記します。brief は既存のデザイン契約を補完するものであり、それに矛盾してはなりません。

ステップ 2：新しい brief を作成する（存在しない場合）

必須の 5 セクションについて、一度にユーザーに確認してください。各セクションにつき、質問は簡潔に 1 つだけにします。ユーザーが詳しく尋ねない限り、5 つの質問を別々に投げかけないでください。

簡潔な質問テンプレート：

「デザイン brief を作成するために 5 つの情報が必要です。簡潔な回答で構いません。こちらで構成を整えます。

1. プロダクトの目的 — 何をするものですか？ 1 文で説明してください。
2. 主なユーザー — どのような役割の人が、どのような状況で使いますか？
3. 原則 — このプロダクトが大切にしていることは何ですか？ 3〜5 個の立場を挙げてください。（まだ決まっていない場合は、そうお知らせください。原則を検討するワークショップを行います。）
4. 成功指標 — 「この画面でユーザーが成功した」とは、観察可能な行動としてどのような状態ですか？
5. 対象外 — この画面が意図的に行わないことを 3〜5 個挙げてください。」

原則を検討するワークショップの場合： ユーザーが「まだ原則がありません」と言ったり、「良いものにする」「シンプルにする」のように曖昧な回答をしたりした場合は、曖昧な情報から原則を作り出さないでください。まず references/principles-catalog.md を読み込みます。このカタログには、8 つのプロダクトカテゴリーにわたる 42 個の原則の具体例があります。文字どおり採用するテンプレートではなく、会話のきっかけとして使ってください。ユーザーのプロダクトに最も近いカテゴリーから 2〜3 個を示し、どれに共感するか、またはどれを反転させたいかを尋ねます。その後、references/brief.md にある原則ワークショップを、焦点を絞ったサブフローとして進めます。議論のあった過去のデザイン決定を 3 つ尋ね、そのパターンから候補となる原則を導き出します。ありきたりな表現は受け入れず、内容を掘り下げるよう促してください。

長い入力の解析： ユーザーがプロダクトの説明や PRD を提示した場合は、既に示されている情報を再度尋ねず、5 つのセクションに整理してください。抽出した内容を伝え、確認または修正を依頼します。

情報が不十分な回答： デザイン上の判断を絞り込むには曖昧すぎる回答の場合は、焦点を絞った追加質問を 1 つ行います。セクションごとの追加質問は最大 2 回とし、その後は不完全であることを明記して次に進みます。

ステップ 3：書き込む前に提示する

ファイルに書き込む前に、必ず提案する brief の全体を提示してください。「この内容でよいですか？ 調整したい点はありますか？」と尋ねます。

確認を得るまでは書き込まないでください。

ステップ 4：ファイルを書き込む

.ui-craft/ が存在しない場合は作成します。確認済みの内容を .ui-craft/brief.md に書き込みます。

ファイルには、references/brief.md と完全に一致する見出しで、5 つのセクションすべてを含めてください。省略してはいけません。

ステップ 5：書き込み後

ファイルの場所が .ui-craft/brief.md であることをユーザーに伝え、コミットを提案します。

「.ui-craft/brief.md をリポジトリにコミットしてください。これは設定ファイルではなくドキュメントです。エージェントはセッションごとにこのファイルを読み込みます。」

自動でコミットしないでください。プロジェクトのルールに従い、コミットにはユーザーからの明示的な指示が必要です。

制約

• 5 つのセクションはすべて必須です。ひとつでも本当に不明な場合は、ギャップがわかるように、日付入りのプレースホルダー [TO DEFINE — YYYY-MM-DD] として記載してください。
• 更新時には、ブリーフへの追記を基本とします。過去の内容は削除せず、非推奨にする場合は日付と理由を記載してください。
• ユーザーのブリーフには、ブランド名、製品例、一般的な SaaS 関連の表現を含めないでください。ブリーフにはテンプレートではなく、ユーザーの製品について記載します。

次のステップ： /tokens — ブリーフで意図を定め、トークンでそれを表現します（2 段目）。