craft

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

ui-craft スキルを読み込みます。このコマンドはビルドを行い、レシピの合格基準を満たす動作するコードで完了します。

利用可能なレシピ：dashboard → references/recipe-dashboard.md · landing → references/recipe-landing.md · auth（サインイン／サインアップ）→ references/recipe-auth.md。$ARGUMENTS で指定された画面にまだレシピがない場合（settings、docs、e-commerce）は、その旨を伝え、最も近いリファレンスを使って標準のビルドモードに切り替えてください。架空のレシピを即興で作らないでください。

---

Step 0 — 仕様を読み込む（存在する場合）

何よりも先に、.ui-craft/spec.md が存在し、$ARGUMENTS と名前が一致する ## Surface: <name> セクションが含まれている場合は、そのセクションを読み込みます。そこで選択された構成、コンポーネント一覧、状態の組み合わせ、および合格基準は、以降のすべてのステップでレシピのデフォルト設定より優先されます。仕様由来の項目とレシピのデフォルト由来の項目を区別して記録します。

Step 1 — 入力

Stack Detection + Discovery Step 1（既存のトークン、.ui-craft/brief.md）を実行します。

references/craft-intent.md を読み込みます。

レシピの Step 0 の質問を、ひとつの簡潔なプロンプトにまとめて尋ねます。$ARGUMENTS または brief ですでに回答されている項目は、あらかじめ入力しておきます。ユーザーが回答を断った場合、「お任せ」と言った場合、またはこのセッションですでに回答済みの場合は、レシピのデフォルトを黙って適用し、適用した内容を伝えます。同じ質問を二度してはいけません。作業を止めてはいけません。

この画面タイプについて craft-intent のデフォルトを使い、ユーザーまたは brief で指定されていない限り DESIGN_VARIANCE を設定します。

Step 2 — Craft Read + 計画の確定

コードを書く前に、Craft Read（craft-intent §1）を1行で出力します。画面の種類、対象ユーザー、プロダクト向けかマーケティング向けかの表現、テーマ／アクセント、変化の度合い、特徴づけの要を含めます。

回答をもとに、構成＋テーマプリセット（または既存のトークン）＋密度＋変化の度合い＋特徴づけの要を決めます。ブランドの方向性がない場合は、軸をひとつ変更し（craft-intent §6）、その軸を明示します。

ランディング画面 — 折り返し位置は候補から選ぶのではなく、抽選してください。 fold_candidates MCP ツールを呼び出し、.ui-craft/brief.md の ## Fold classes used にすでに記載されている構成クラスをすべて used として渡します。返された3つの候補からひとつを選び、そのクラスが求める犠牲を明確に宣言してください。その犠牲こそが、このページらしさを生み出します。

候補を平均化してはいけません。また、どんな要素にも当てはまるからという理由で、テキストを左、ビジュアルを右に置く分割レイアウトに戻してはいけません。何にでも当てはまるのは、何にも踏み込んでいないからです。このスキルを使ったブラインドビルド10回すべてで、関連のない2つのプロダクトを対象にしていたにもかかわらず、10回とも同じ折り返し位置になりました。一方、参考にしたランディングページ18件のうち、このレイアウトを使っていたのはわずか3件です。

MCP サーバーが接続されていない場合は、その旨を伝え、scripts/fold/classes.mjs から brief でまだ使われていないクラスをひとつ選びます。重要なのはツールではなく、抽選することです。

短い計画を5〜7行で出力します。Craft Read、構成クラスとその犠牲、テーマ、特徴づけの要、ファーストビューに置くもの、後回しにするものを含めます。ユーザーが異議を唱えない限り、そのまま進めます。

Step 3 — ビルド

レシピに記載されたビルド順序（トークン → シェル → ヒーロー層 → 主要領域 → 残りの層 → 状態 → キーボード操作 → 仕上げ）に正確に従います。各ステップで指定されているリファレンスと、この画面タイプの craft-intent パターンを読み込みます。この工程で特徴づけの要を実装します。後回しにしてはいけません。

状態とキーボード操作はビルド工程であり、仕上げではありません。空、読み込み中、エラーの各状態がない画面は未完成です。

ステップ 4 — 合格基準

構築した画面に対して、レシピの受け入れチェックリストを実行します。報告する前に、未チェックの項目をすべて修正してください。合格基準は完了の定義であり、提案ではありません。

ビジュアルのセルフチェック（スクリーンショットツールを利用できる場合）： Playwright／ブラウザー MCP などが利用できる場合は、デスクトップ幅で構築した画面をキャプチャし、報告前に確認してください。レンダリングすると、コードレビューでは見つけられない余白の衝突、階層の競合、デッドゾーンが明らかになります。スクリーンショットを使って、類似プロンプトのセルフテスト（craft-intent §1）を実施してください。このカテゴリの別ブランド向けでも、このページがそのまま通用するでしょうか。通用するなら、報告前に特徴を強めてください。ツールが利用できない場合は、何も言わずにスキップしてください。決して作業を止めないでください。

ランディング画面 — 実際に構築したファーストビューを確認します。 ページを配信し、URL、描いたクラスを expected_class として、採用したコストのかかるディテールを指定して check_fold を呼び出してください。すでに利用できるブラウザーでレンダリングされ、スクリーンショットと読み取り結果が返されます。対処すべき点は2つです。1つ目はずれです。これは、描いたクラスと構築したクラスが異なることを意味します。通常は分割です。モデルがプロンプトなしで戻るファーストビューだからです。2つ目は、ファーストビューがどこにも際立っていないという母集団の読み取り結果です。これは不備ではなく、スクリーンショットを確認するきっかけです。参照用ランディングページ18件のうち7件にも、この結果が出るためです。

返されるその他の内容は判定を伴わない測定結果なので、そのように受け止めてください。判定対象となる不変条件は2つだけで、どちらも幾何学的なものではありません。

費やした内容を記録する： .ui-craft/brief.md の ## Fold classes used に構築したクラスを追記してください。セクションがない場合は作成します。このリストがあることで、このプロジェクトで次に /craft を実行した際に、別のものが描かれます。記録がなければ、描画は過去を記憶せず、プロジェクトは再び収束してしまいます。

ユーザーへの報告：

1. Craft Read（再掲）
2. 描いた構成クラスと、それに伴う犠牲
3. 構築した特徴的な賭け
4. チェックリストの結果
5. ユーザーが明示的に見送った項目

発見事項を羅列するのではなく、意図から始めてください。この作業で修正した内容に限り、Review Format の表を使用します。

CRAFT_LEVEL ≥ 8 の場合は、レシピの最低限のパスではなく、完全な /finalize ゲートで仕上げてください。

次のステップ： /finalize — 出荷前ゲートを実行します（第3段階）。このプロジェクトにまだブリーフがない場合は、先に /brief を実行します（第2段階）。