# Mori UI > Design, implement, redesign, and review web interfaces in Mori's subject-driven, operational UI style while preventing generic AI-generated aesthetics. Use for UI/UX, frontend, dashboards, admin panels, forms, data visualizations, landing pages, design systems, or visual audits, especially when the user asks for MoriらしいUI, AIっぽさを消す, AI slopを避ける, 紫グラデを使わない, 影付き角丸カードを減らす, or ポエミーな文章をやめる. - Skill: `novelsavage/mori-ui` (Agent Skill, multi-file: 6 files) - Install (CLI): `npx skillmds@latest add novelsavage/mori-ui` - Raw SKILL.md: https://api.skillmd.com/api/skills/novelsavage/mori-ui/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: novelsavage (https://skillmd.com/u/novelsavage) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/novelsavage/mori-ui --- # Mori UI 題材・操作目的・情報構造から、その画面固有の視覚言語を作る。流行の見た目を自動適用せず、ユーザーが嫌う「AIが考えなしに作ったUI」を防ぐ。 このスキルは固定テーマではない。黒地、蛍光色、ドットフォントなど、過去作品の表層を毎回コピーしない。プロジェクトごとの必然性を優先する。 ## 参照する 作業前に次を読む。 - `references/style-principles.md`: Moriらしさを画面へ翻訳する原則 - `references/anti-slop.md`: AI既定表現の禁止・例外・コピー規範 - `references/verification.md`: 実装後の表示・操作・回帰確認 ## 1. 現状を読む 変更前に、リポジトリ、実行中の画面、既存コンポーネント、ロゴ、フォント、主要フローを確認する。スクリーンショットだけで判断できる場合も、可能なら実装と実画面の両方を見る。 次を一文ずつ答えられる状態にする。 1. この画面で利用者が完了したい仕事は何か。 2. その仕事の主役となる対象は何か。 3. どこで、どの頻度で、どの端末から使うか。 4. 残すべき既存の操作・ブランド要素は何か。操作名、配置、確認手順、実行可能条件も記録する。 5. 現在のUIで「汎用AIテンプレ」に見える箇所はどこか。 明示された現在の要望を最優先する。既存コードや過去作品は参考資料であり、現在の指示より上位ではない。 ## 2. Design Readを決める 実装前に短い設計判断を置く。 ```text 画面の仕事: 主役: 利用状況: 情報密度: 既存データと比較に必要な項目: 固有の視覚モチーフ: 残す操作: 避ける既定表現: ``` 「モダン」「洗練」「未来的」だけでは不十分。たとえば地図なら座標・方位・レイヤー、OCRなら紙・付箋・処理キュー、グラフならノード・接続・ターミナルログのように、題材から部品と関係性を引き出す。 ## 3. 視覚契約を作る コードを書く前に、最低限のトークンと役割を決める。 - 色: 背景、前景、境界、主アクセント、警告、成功を4〜6色程度で定義する - 文字: 本文、見出し、数値・識別子の役割を分ける - 境界: 線、面、余白のどれで区切るか決める - 角丸: 対象の意味に合わせ、全要素へ同じ大きな半径を配らない - 輪郭アクセント: 状態や分類を符号化しない限り、角丸カードの一辺だけを着色して飾らない - 密度: 一覧・操作画面は情報量を保ち、鑑賞画面は主役へ空間を渡す - 動き: 状態変化や因果を伝える用途に限定する デザイントークンはCSS変数など一箇所で管理し、場当たり的な色・影・半径を増やさない。 ## 4. 構造から実装する 主役を先に配置し、操作と説明をその周囲へ置く。 - 地図、グラフ、映像、文書などが主役なら、画面の大部分を主役へ渡す - ナビゲーション、ツール、ステータスは仕事の流れに沿って置く - 余白、罫線、背景差、見出し階層で区切り、カードを最初の選択肢にしない - カードは、独立して選択・移動・比較できる対象、意味的に自己完結したフォームや要約、開閉可能な詳細など、境界が理解を助ける単位に使う - 紙や付箋などのモチーフも、注釈や確認待ちなど意味のある箇所へ限定する - 操作状態、空状態、読込中、エラー、成功、無効状態を実装する - 削除などの危険操作は視覚的に分離し、確認と処理中の二重実行防止を保つ - モバイルでは縮小版にせず、重要度に沿って並びと露出を変える。表を安易にカード化せず、優先列、詳細展開、横スクロールを比較して選ぶ 既存のロゴ、ファビコン、ナビゲーション、主要アクション、キーボード操作を、依頼なく削除しない。 ## 5. コピーを業務言語にする 何ができ、次に何が起き、失敗時にどう戻れるかを直接書く。 - 見出しは画面や処理の名前にする - ボタンは動詞で書く - 説明文は条件、入力、出力、制約を伝える - 状態文は対象、現在地、次の操作を示す 「体験を再定義する」「可能性を解き放つ」など、製品固有の情報を持たない詩的コピーは使わない。実データがないのに、架空のKPI、受賞歴、顧客ロゴ、推薦文を作らない。 見出しの前後に、意味を持たない英語キッカー、連番付きの章ラベル、同内容の副題を装飾目的で足さない。各テキストについて「利用者の判断・操作・現在地の理解に必要か」を問い、見出しを読めば分かる文言は削る。ブランド名、対象の識別子、実際の手順番号、状態、単位など機能を持つ短い表記は残す。 ## 6. Slop監査をかける 実装対象に対して、同梱スクリプトを補助的に使う。 ```powershell uv run --no-project python \scripts\audit_ui_slop.py ``` CIなどで高重大度だけ失敗させる場合: ```powershell uv run --no-project python \scripts\audit_ui_slop.py --fail-on high ``` 機械判定は候補抽出であり、最終判断ではない。題材上の必然性がある表現は残し、理由を説明する。違反を消すためだけに別の装飾へ置換しない。 ## 7. 実画面で検証する `references/verification.md` に沿い、可能なら実際の開発サーバーを起動してデスクトップとモバイルを確認する。 最低限、次を行う。 1. lint、型検査、ビルド、関連テスト 2. 主要画面のスクリーンショット確認 3. 主要操作と状態遷移の確認 4. キーボードフォーカス、コントラスト、モーション抑制の確認 5. 変更前に存在した主要機能の回帰確認 スクリーンショットを見て「この題材を知らないテンプレ生成器でも同じ画面を作れるか」を問う。答えが「はい」なら、装飾を増やすのではなく、主役・構造・用語・操作順を題材へ寄せ直す。 ## 完了条件 - 画面の主役と主操作が一目で分かる - 視覚表現に題材または操作上の理由がある - 紫グラデ、巨大角丸、影付きカード、ピル、ガラス表現が惰性で反復されていない - コピーが具体的で、架空の権威付けを含まない - 既存の重要な操作を保っている - デスクトップとモバイルで実画面を確認している - 機械監査とプロジェクト固有の検証結果を説明できる