インストール
plan, review against the brief, build, critique誰向けか
新しいインターフェースをつくるとき、または既存のインターフェースを直すときで、意識的で識別できる視覚方向が必要なときに frontend-design を使う。美的方向、フォント、テンプレートの初期値には見えない選択を決める助けになる。
より合う前提は、今回の仕事をデザインスタジオのデザイン責任者として扱うことだ。依頼者はすでに決まり文句やテンプレート感のある案を断り、明確な観点に対して対価を払う意思がある。今回のブリーフの配色、フォント、レイアウトについて立場のある選択をし、理由が十分なときは審美的リスクを引き受けてよい。資料にはエージェント製品の一覧もインストーラもないので、特定ソフトの独占機能だと解釈しないこと。公式の説明ページは
https://raw.githubusercontent.com/anthropics/skills/main/skills/frontend-design/SKILL.md
3分で最初の試みを終える
この説明にはインストールコマンドがない。最初の試みでリポジトリパスやパッケージマネージャの命令を捏造しない。推奨パスは資料にある過程そのものだ。先に plan、次にブリーフと照合して確認し、それから build、最後に critique。
前提：インターフェースの仕事はすでにあり、ブリーフが短くてもよい。低リスクな最初の動作は位置づけだけであり、コードは変えず、ファイルも書かない。ブリーフに製品やテーマが書いていなければ、具体的なテーマ、対象、このデザインの主タスクを自分で定め、提案として書き、依頼した人に確認する。確認前に配色やインターフェースの記述へ進まない。
成功の合図：三文で「誰向けか、何を解くか、テーマは何か」を言い切れ、相手がうなずくか明確に反対してから直す。「まず #F4F1EA に近い暖かいクリーム地を敷き、高コントラストのセリフ見出しとテラコッタのアクセントを足す」ことをしない。資料はそれを、いまの生成デザインが同型に集中する特徴として挙げている。
使用事例
事例一：ブリーフに製品情報がないときは、先に揃えてからデザインする。資料どおり、具体的なテーマ、対象、主タスクを自分で出し、提案として確認する。完了基準はこの三点が確認されたことであり、完成 UI が一版あることではない。確認に使う道具は資料に書かれておらず、口頭でも文書でもよい。未確認のままインターフェースを描くのは、この経路の外になる。
事例二：揃ったブリーフに対してフォントを決める。資料は、見出しと本文がそれぞれまったく別の書体である必要はない、一族を使うか、二族ならはっきり差をつける、と書く。意図して選ぶ。「どの案件でも使う初期フォント」を適当に取らない。要約は行長を 80 文字以内に保つことにも触れるが、抜粋に行長検査の手順はない。したがってこの事例の完了基準は、フォント一族の数と差が決まったことであり、組版検査を走らせ終えたことではない。配色とレイアウトも今回のブリーフ向けに決め、クリーム地にテラコッタ強調のよくある組み合わせを再利用しない。
使用の境界
過程は plan、ブリーフ照合、build、それから critique。テーマ、対象、主タスクが先で、視覚は後。フォントは一族か二族。万能の初期フォントは拒む。資料が名指しする生成デザインの集中を避ける：暖かいクリーム背景（#F4F1EA に近い）、高コントラストのセリフ見出し、テラコッタまたは暖かいクレイの強調。
インストーラやリポジトリ内パスを捏造しない。資料にコンポーネントライブラリ一覧、初期スウォッチファイル、クライアント一覧はない。コードを書く、または既存スタイルを上書きする前に、提案が受け入れられたことを確認する。ここに書いた位置づけ、フォント、落とし穴の外は、この説明の範囲外である。既成テンプレートを当てるだけで、今回のブリーフ向けに選ばないなら、この経路を取るべきではない。先にブリーフを揃え、理由のある審美的リスクを引き受ける。