build-screen

画面を作る

melta の契約から画面 1 枚を生成し、生成物を自分で lint して、「何を自動検査したか / 何を検査していないか」まで含めて報告する。依頼から提出までの往復を 1 回に潰すための手順書。

参照の実体は MCP ツールと AGENTS.md / DESIGN.md / design/contracts/ に置く。この手順書に仕様を複製しない（複製した瞬間に drift する）。

Step 1: 依頼の分類と契約の引き当て

1. AGENTS.md の「## タスクベース読み込みガイド」の表を読み、依頼を該当行に当てる。表をここに写さない（AGENTS.md が正）。複数の行に跨る依頼（例: 「サイドバー付きの設定画面」= サイドバー付きページ + 設定画面）は該当行の和集合を取る
2. 該当行が挙げるファイルを、表の順序どおりに読む
   • MCP が使えるなら get_component（契約の exact value）と search（どの契約が該当するかの探索）を優先する
   • MCP が無ければ design/contracts/components/*.contract.json を直接読む
   • 値の正本は契約、原則の正本は DESIGN.md。競合したら契約が勝つ（design/authority.md）
3. 引き当てた契約名と読んだファイルを控える。Step 5 でそのまま報告する

引き当てが 1 つも無い依頼（DS に契約が存在しないコンポーネントを含む）は、生成前にその旨を伝える。契約の無い部品を勝手に発明しない。

Step 2: 意図確認（最大 3 問）

下の質問バンクを上から見て、依頼文から答えが取れる問いは飛ばす。残ったものだけを 1 回でまとめて聞く。4 問以上聞かない。3 問を超える不確定さが残るなら、残りは仮置きして Step 5 の報告に「こう仮定した」と書く。

• Q1: 画面の主目的と主動作を 1 つ（例: 一覧から詳細へ / フォームを送信する）
• Q2: 含めるデータ状態（通常のみ / + 空状態 / + 読み込み中 / + エラー）
• Q3: 出力先パスと幅（ファイルパス / デスクトップのみ or レスポンシブ）

出力先が未指定なら提案する。examples/ は CI の Full Scan 対象なので、DS 公式サンプルにする意図が無い限り避ける。

拡張子は .html に揃える（Step 4 の CLI 経路が検査できるのは .html / .tsx / .jsx / .vue だけ。.htm などを渡すと検査自体が実行されない）。

ダークモードは聞かない。AGENTS.md の「テーマ・ダークモード」表の設定に従う。

Claude Code では AskUserQuestion で聞く。他のクライアントでは箇条書きで聞いて回答を待つ（推測で進めない）。

Step 3: 生成

• DESIGN.md の原則 + Step 1 で引き当てた契約の exact value で HTML を 1 枚書く。Tailwind class は契約の値を使う（近い値を目分量で選ばない）
• Step 4 が拾えるルールも最初から守って書く（例: [TABLE_TH_SCOPE_REQUIRED] / [A11Y_NO_TABINDEX_POSITIVE] / [BTN_ICON_ONLY_ARIA_REQUIRED]）。修正ループは検算であって、生成の手抜き分を回収する装置ではない
• severity が error でも detector が manual のルールは Step 4 で絶対に捕まらない（例: 実効タップ標的 44px の下限 [A11Y_MIN_TAP_TARGET_44]）。生成時に守るのが唯一の機会なので、使うコンポーネントのカテゴリのルールを design/contracts/rules.json で先に見る

Step 4: 自己検証（検査は最大 3 回 = 初回 + 修正後の再検査 2 回）

1. 生成物を検査する。経路は 2 つあり、返ってくる情報が違う。どちらを使ったかを覚えておく（Step 5 の書き方が変わる）
   • MCP 経路: check_html に生成物を渡す。passed / violations / coverage.automated / coverage.notAutomated が返る
   • CLI 経路（MCP が無い環境）: npm run design:lint-generated -- <生成ファイルのパス>。error があれば exit 1。返るのは違反一覧と件数と PASSED / FAILED だけで、passed フィールドも coverage も返らない
2. severity error を全部直して再検査する。warn は残してよいが Step 5 に列挙する
3. 3 回目の検査でも error が残るなら、残った violations を報告に載せて止まる。ルールを黙って緩めない・生成物を検査対象から外さない
4. 検査そのものが実行できなかったとき（CLI が exit 2 = 対象拡張子でない / パスが解決できない / ruleset を読めない、ツールのエラー、MCP が応答しない）は、修正ループに入らない。生成物は無検査のままなので、エラー出力をそのまま持って Step 5 へ行く。「たぶん通る」で埋めない