mcpField
L
layout

layout

github.com/shipshitdevデザイン・UI3894 回インストール1 日前に更新
リポジトリ

layout について

Layoutは、許可された範囲内でインターフェース構造を診断・変更するデザインスキルです。階層、グループ化、間隔、情報密度、レスポンシブ動作を評価し、根拠に基づく修正と検証を支援します。

主な機能

  1. 01階層と読み取り順の評価
  2. 02グループ化と間隔のリズム確認
  3. 03情報密度とレスポンシブ動作の確認
  4. 04境界ケースとアクセシビリティ順の点検
  5. 05レイアウトチェックによる変更検証

活用シーン

  1. 01タスクの優先度に沿ったページ再構成
  2. 02画面幅に応じたレイアウト調整
  3. 03はみ出しや間隔の問題の診断
  4. 04描画結果の根拠に基づく構造検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/shipshitdev/skills --skill layout

インストール後、Claude Code で/layoutを入力して読み込まれたか確認します。

同梱ファイルplugin.jsonREADME.md

詳細

レイアウト

構造の変更は、許可された対象と範囲内でのみ行ってください。

レイアウトは、プロダクトの優先順位を読み進める順序、グルーピング、リズム、使いやすい余白へと変換します。ボックスを移動する前に、構造上の問題を診断してください。


ビジターモード

  • 説得 + 体験: 選択した世界観にふさわしい場合、構成は非対称、流動的、あるいは意図的に変化をつけたものにできます。
  • 操作 + 読解: 予測しやすい構造、安定した密度、たどりやすい直線的な流れは、使いやすさにつながります。
  • ネイティブ: ナビゲーション、インセット、適応、タッチターゲットに関するプロジェクトのプラットフォーム規約に従ってください。

確立されたビジュアルの世界観を維持してください。レイアウトの指示で変更するのは、その世界観の中の構造です。アイデンティティの置き換えには、別途承認されたデザイン方針が必要です。

独立した2つの評価

デザイン判断が引きずられないよう、機械的な調査結果を読む前にビジュアル評価を完了してください。許可されている場合にのみ委任し、それ以外の場合は2つ目の評価を始める前に最初の評価を記録してください。

  1. レイアウト評価: 代表的な状態とビューポートを確認します。以下の各質問に、レンダリング結果またはソースの証拠を示して回答してください。
    • 読み進める順序: 目を細めて見てください。細部がぼやけていても、主要要素、副次要素、主要なグループを順番に見分けられますか?
    • グルーピング: 関連項目は近くにまとまり、異なるグループは分かれているでしょうか。それとも、近接性の弱さをコンテナーで補っていますか?
    • リズム: 間隔の詰まった部分とゆったりした部分が意図的なテンポを生み出していますか。それとも、同じ間隔値が繰り返され、すべてが同じ重みに見えますか?
    • 構造: 構造はコンテンツとタスクに合っていますか?繰り返されるカード、列、セクションは本当に同等ですか。それとも、単なるフレームワークのデフォルトですか?
    • 密度: 各領域の情報量は、利用頻度、判断の複雑さ、ビジターモードに適していますか?
    • 適応: 狭い画面、中間サイズ、広い画面、ズーム時、ローカライズ時に、何が並べ替えられ、折りたたまれ、折り返され、スクロールし、固定されたままになりますか?DOMとフォーカスの順序は、ビジュアル上の順序と一致していますか?
    • 極端なケース: 長いコンテンツ、空の状態、オーバーレイ、スティッキー要素、安全領域、小さなタッチターゲットによって、構造上の問題が明らかになりますか?
  2. 機械的な調査: プロジェクトで設定されているレイアウトチェックを読み取り専用モードで実行するか、チェッカーがない場合はソースを確認します。確認できない証拠についても報告してください。

検出器では解決できない、任意の間隔、オーバーフロー、重なり順、コンテナーの挙動も確認してください。最初の評価には機械的な証拠を含めず、編集前に両方の評価を統合してください。スキャン結果が問題なしでも、階層やリズムが適切であることの証明にはなりません。

空間的な設計方針を定める

編集の前に、以下を明確にしてください。

  • 読み進める順序またはタスクの主要な流れ
  • まとめるものと、分けるもの
  • 主役となる要素と、それを支える要素
  • 意図する密度と間隔のリズム
  • コンテナー、ビューポート、入力モード、コンテンツの極端な状態に応じた構造の変化

それらの関係を表現する、最もシンプルな構造モデルを選んでください。制御する関係に応じてレイアウトプリミティブを使い、再利用可能な間隔とコンテナーの役割には、意味が明確な名前を付けてください。

適用

  • 意味ごとにグループ化します。コンテナや装飾を追加する前に、近接性を活用します。
  • 間隔に意図的な強弱をつけ、リズムを生み出します。
  • 場当たり的な値ではなく、文書化されたスペーシングスケールを使います。4単位を基本とすると、8単位のみのスケールでは得られない、実用的な中間ステップを通常は確保できます。
  • 階層はフレームワークのデフォルトではなく、プロダクトの優先度に沿わせます。
  • 個々のグループをすべて独立したコンポーネントにすることなく、異なるコンテンツを視覚的にも区別します。
  • レスポンシブな動作は構造的なものにします。重要な要素に応じて、並べ替え、折りたたみ、再配置、表示を行います。
  • 同じコンポーネントが異なるコンテキストで使われる場合は、コンテナを考慮したコンポーネントを優先します。
  • 子要素のマージンよりも関係性を直接表せる場合は、兄弟要素間のリズムにgapを使います。
  • 見た目の印が小さくても、タッチターゲットは使いやすい大きさに保ちます。
  • 奥行きは、状態や階層を明確にする場合にのみ使います。
  • 光学的な調整は、レンダリング結果を確認してから行います。

変化そのものを目標にしてはいけません。繰り返しは認識を助けるものであり、コンテンツや優先度が変わる場合にのみ崩します。

検証

  • 目を細めて見ても、主要なグループ、二次的なグループ、大きなグループが順番どおりに判別できます。
  • すべての対応サイズで、読み進める経路とタスクの流れが明確です。
  • 関連するコンテンツは自然にまとまり、関連のないコンテンツは混ざり合いません。
  • 詰めた間隔とゆとりのある間隔が、単調な繰り返しではなく、意図的なリズムを生み出します。
  • 密度が、利用頻度とコンテンツの複雑さに合っています。
  • 長文、空の状態、ローカライズ、ズーム、動的コンテンツによって構造が崩れません。
  • キーボード、タッチ、支援技術での順序が、視覚的な順序と一致しています。
  • 最終的な機械的スキャンに、説明のつかない検出結果がありません。

各項目には、レンダリング結果またはソースの証拠を示して回答し、その後、スキャンを再実行します。検証の代わりに、根拠のない「はい」とだけ答えてはいけません。

構造が保たれている場合は、利用可能なpolishスキルを推奨します。

コメント