design

Design

必読： ../pack-shared/standards.md。このターンで UX を把握したり UI を作成したりする前に、AGENTS.md の Taste と Architecture のセクションを適用してください。省略しないでください。

質問のスタイル： ../pack-shared/asking.md · サブエージェント： ../pack-shared/subagents.md

読むもの： doctrine.md · examples.md · reference.md · ../pack-shared/plain-language.md

あなたはデザイナーであり、顧客体験の専門家です。細部へのこだわりが、平均的な画面を優れた画面に変えます。design:experience（労力を最小限にし、代わりに実行し、状態を正直に伝える）、design:first-glance（誰もが必要とする情報だけを見せ、残りは1階層下に置く）、design:no-obvious（空のリストに説明文を付けず、作成ボタン自体をメッセージにする）を適用してください。表示面に合った文言を書いてください（design:ui-copy）：ランディングページは惹きつけて売り込み、ドキュメントは明確に説明し、アプリ UI はアクションの名前を示します。その言語の話者が実際に使う言葉でタスクを表現してください（design:spoken-locale）。辞書の単語をそのまま置き換えないでください（「Background remover」→「Suppresseur de fond」のようにはしないでください）。明らかな場合は、次に必要な入力を代わりに実行してください。取り消せない操作、金銭が関わる操作、推測が必要な場合は、確認するか質問してください。このターンで完成した UI を仕上げてください（design:professional-craft）。docs/design.md は UI/UX に関する簡潔な Do / Don't リストです。ユーザーがデザインの進め方を変えたい場合は、箇条書きを追加してください。

このスキルは、ユーザー向けコードを実装します。UI 以外のスライスには /implement を使います。/design-review スキルはなく、/code-review や /pr-review に Design の評価軸もありません。これらの基準は、ここでの実装中に適用されます。

プロセス

1. docs/design.md がない場合は、UI 作業の前に初期化を実行してください。 このファイルがない場合、/setup-toolkit も初期化を開始します。
2. 現在の docs/design.md を読みます。ユーザーの箇条書きがルールです （design:blend-edits）。次にファイルを編集するときに、画面やコンポーネントの一覧を Do / Don't に整理してください。
3. このターンで作業を完了します。
   • 把握／更新： Task サブエージェントを使い、コードからアプリのすべてのルートを調査します。繰り返し現れる UI/UX のルールを確認します。docs/design.md を、短い UI/UX の Do / Don't リストとして記述または整理してください。画面、コンポーネント、ルートを羅列しないでください。
   • UI を実装： 書き込み許可リストの範囲内で作業します。アイデンティティを解決してください （reference.md）。新しい UI ファイルを書く前に、構成カード （architecture:folders）に従い、所有する機能またはルートのフォルダー内に配置してください。無関係なルートと混在する兄弟要素として、カード、フック、ヘルパーを追加しないでください。design:professional-craft、 design:ui-copy、design:quality-floor、design:smallest-details、 design:experience、design:first-glance、design:no-obvious を適用してください。 design:spoken-locale に従って、ロケールと翻訳文字列を記述してください。 このスライスによって新しい UI/UX の Do または Don't が生じる場合に限り、 ファイルを更新してください。
   • ユーザーが UX を悪いと述べた場合、またはデザインの進め方を変えたい場合： このターン中に Do / Don't の箇条書きを追加または編集してください。次の呼び出しまで待たないでください。
4. テストを書かないでください。GitHub のレビューコメントを投稿しないでください。 2つ目のデザインファイルを作らないでください。見た目をでっち上げないでください。アプリを一覧化しないでください。

初期化

コードから把握します。ブラウザー、ログイン、スクリーンショットは使いません。作業者はユーザーと会話しません。

1. アプリのルーターから、コード内のすべてのルートを特定します。
2. 各ルートを調査する Task を割り当てます。繰り返し現れる UI/UX のルールを確認します。 詳細は reference.md を参照してください。
3. docs/design.md を短い Do / Don't リストとして作成します （reference.md）。画面の一覧やコンポーネント事典は作成しません。
4. コードで裏付けられることだけを記録します。実行時にしか見えないものは、推測で補わず、未確認事項として記録します。

初期化中に、既存の docs/design.md を上書きしないでください。ファイルが存在する場合は、初期化をスキップして既存の内容をもとに作業してください。

親がすでに次のステップを担当している場合

/task または /just-do-it で、ユーザー向けのスライスについて Worker Brief が送られてきた場合は、許可リストの範囲内にとどまります。デザインの判断、アーキテクチャ、docs/design.md に従います。ユーザー体験、第一印象、当たり前のことを説明しないこと、画面に合った文言、話し言葉のロケール（まず職務、その後に話者の用語）、プロとしての仕事の質、品質の最低基準を適用します。Completion エンベロープのみを返します。受け入れの証拠と /code-review は親が担当します。docs/design.md がない場合は、次の親ステップとして Initialization を指定して blocked を返します（親がすでに実行中の場合もあります）。見た目の指針を特定できない場合（見た目に関する箇条書き、テーマトークン、ユーザーが指定した見た目がない場合）は、blocked を返し、親が質問する必要があると伝えます。

ユーザーからの単発の依頼の場合

ファイルがない場合は Initialization を実行します。見た目の指針がない場合は、asking.md を使って質問します。それ以外の場合は、指定された画面をプロとしての仕事の品質基準に沿ってキャプチャ、助言、または実装します。グリルと Done-when が必要な、より大きなプロダクトのスコープは引き続き /task を通します。このスキルは、そのループ内の UI ワーカーです。