n0ctx/tavern-aesthetic

居酒屋美学 — 没入型ナラティブフロントエンドデザイン

このスキルが生み出すもの

動作するUIは、単なる再スキンされたダッシュボードや、ありふれたゲームHUD小道具の山ではなく、物語世界に存在する人工物として読み取れます。基準は洗練されたフロントエンドカードです。一目見てその作品とわかること、すべての表面が一つのアートディレクションを共有していること、細部が完成されていること、そして操作が自然に感じられることです。

洗練されていることと複雑であることは同義ではありません。洗練されているとは、目に見えるすべての選択が意図的であり、目に入るすべての領域が同じ品質基準を満たしていることを意味します。

このスキルはビジュアルデザインと実装方法をカバーします。SillyTavern、ヘルパープラグイン、MVU、その他のフレームワークに依存しません。プロジェクトの既存スタック、コンポーネント、アセット、インタラクションパターンを再利用してください。ユーザーがデザインのみを要求する場合、コードには触れないでください。

参考資料（必要に応じて読み、一度にすべてを読まないこと）

• references/design-knowledge.md — 各次元（ナラティブアイデンティティ、色、タイポグラフィ、形状、光/素材、画像、レイアウト、コンポーネント、モーション、適応）に沿った判断ガイド、および障害モードテーブル。現在の判断に該当するセクションを参照してください。
• references/workflow.md — 段階的なプロセス、合格/不合格ゲート、レビュー方法、ロールバックルール、設計記録テンプレート。中規模または複雑なタスクの前に読んでください。
• references/asset-sources.md — イラスト、テクスチャ、アイコン、フォントのソースとライセンス確認。オンラインでアセットを収集する際に読んでください。
• references/research.md — このスキルの根拠となる証拠と制限事項。実行には不要です。

タスクレベル

コード量ではなく、デザインの難易度で判断します。

• シンプル: 1つのコンポーネント、詳細の修正、既存のビジュアル言語内での小さな機能追加。言語を再利用し、実装後にスクリーンショットで1回確認します。
• ミディアム: 1つのページ/パネル、または既存画面の1つの再デザイン。簡単な方向性を設定し、最初に焦点領域を構築してからページ全体を完成させます。レビューラウンドは1〜2回。
• コンプレックス: 複数画面のフロー、ゲーム化されたシステム、ゼロからの構築、特注のキービジュアルが必要なもの、またはユーザーが完成品品質を要求するもの。workflow.mdの6つのステージを実行し、設計記録を保持します。

アンチ・ドリフトルール（拘束力あり）

これらは、複数ターンの実行によって設計がずれていくのを防ぐために存在します。文字通りに従ってください。

1. 設計記録が唯一の真実の情報源です。 中規模および複雑なタスクでは、方向性設定時に設計記録を作成し（テンプレートはworkflow.mdにあります）、後続のすべてのターン/モジュールの開始時にそれを読み直してください。新しい色、半径、フォント、モーション値は、使用前に記録のトークンレジストリに追加する必要があります。レジストリにない値は、コード内で許可されません。
2. コアサンプルが合格した後は、トークンレジストリを固定します。 後続のモジュールは、登録されたトークンのみを再利用できます。新しいトークンは、既存のセットではニーズを表現できない理由を記録に明示的に説明する必要があります。
3. すべてのモジュールは、先に進む前にコアサンプルと並べてスクリーンショット比較されます。 例外はありません。口頭での比較は不十分です。
4. ステージごとに最大2回の修正ラウンド。 それでも失敗する場合は、修正を重ねるのではなく、workflow.mdのロールバックテーブルに従ってロールバックし、診断してください。
5. 一度にアクティブな方向性は1つだけ。 ターンをまたいで代替方向性を生かしたままにしないでください。1つを選択し、記録し、残りは破棄してください。

中核原則

1. ジャンルのためではなく、作品のためにデザインする。
   • 最初の問いかけ：このUIは物語の中でどのような物体またはシステムか、誰が作ったのか、誰が読むのか、いつなのか。
   • 次に、この特定の作品に固有の記憶点を1つ選ぶ。
   • ビジュアルアイデンティティは具体的なキャラクター、場所、時代、派閥、イベント、小道具から生まれる。ジャンルの定型（終末後＝黒/黄色のレーダー、修練＝墨緑+金）は出発点に過ぎず、具体化されなければならない。
   • 自己テスト：同じジャンルの一般的なリクエストをエージェントに渡した場合、ほぼ同じUIが生成されるなら、方向性は十分に具体的ではない。
   • いくつかの方向性を内部で比較し、正確に1つを納品する。日常的なタスクでは、ユーザーに選択肢を列挙しない。
2. 1つのコンセプトがすべてのデザイン上の決定を統治する。
   • 色は素材と光源から、書体は筆記/印刷方法から、形状は工芸から、動きは物体の物理的な動作から導き出される。
   • 関連する次元は逐次的ではなく、一緒に決定される（「最初にすべての色、次にすべてのフォント」は間違い）。
   • 任意の要素について、それがコンセプトのどの部分を表現しているかを述べられなければならない。
3. 具体的なアートにはイラストレーションアセットを使用する。コードで描かれたアートはプレースホルダーのみ。
   • 人物、シーン、オブジェクト：最終版ではイラストレーションアセットを使用する。ソースの優先順位：既存プロジェクトアセット → AI生成 → ライセンス済みWebコレクション。
   • CSS/SVGで描かれたシーン、人物、オブジェクトは、コンポジション/コンセプト検証のためにのみ許可され、納品前（複雑なタスクではコアサンプルステージまで）に置き換えられなければならない。これらはプログラマーアートとして読まれ、UI全体を引き下げる。
   • コードはインターフェースそのもの（レイアウト、タイポグラフィ、境界線、テクスチャ、装飾パターン、アイコン、抽象図形、データグラフィック）を担当する。
4. イラストレーションがコンポジションを主導する。
   • イラストレーションがレイアウトの重心を設定し、テキストとコンポーネントはその周りに配置される。決して上部のバナーやカードのサムネイルに縮小してはならない。
   • すべてのメイン画面は絵として読める必要がある：目を細めて見たとき、画面は主にイラストレーションで占められており、暗いパネル＋細い線＋テキストであってはならない。
   • アートの存在は機能的なページにも続く（パネルの下の低コントラストレイヤーとしてのイラスト、パネルの端を横切るキャラクター、時間/場所に応じて変化するシーン）。「美しいオープニング、その後は退屈な暗いフォームページ」は最も一般的な品質の崩壊である。
   • 画面ごとに1つのヒーローイメージ。二次的なイメージは同じ絵に溶け込むか、均一に処理されたセットを形成する。異なるソースのイメージをボックスに並べて配置してはならない。
5. 情報は世界内フォーマットを採用し、小道具は抑制する。
   • 情報は世界のネイティブなフォーマットと語彙（台帳の列、名簿のレイアウト、世界内の動詞/名詞）を使用し、物語のペースで明らかにされる。
   • UI全体で1つの主要な伝達手段。すべてのモジュールに異なるCSSシミュレーション小道具（テープメモ、歪んだスタンプ、タグ、そろばんの珠）を与えてはならない。積み重なった小道具は安っぽく見える。
   • 小道具と装飾を抑制し、画像と色は抑制しない。小道具から解放されたスペースは、暗いテキストフォームではなく、イラストレーションとタイポグラフィに充てられる。
   • すべてが「ラベル：値」＋プログレスバーである必要はない。フローページ（オンボーディング、設定）はフォームではない。主要なオプションにはイラストを添えることができる。
6. 統一された1つの品質基準。
   • 労力は不均等であり得る：焦点領域は最高のアセットと最も詳細を得る。
   • 目に見える領域で基準を下回るものがあってはならない。描かれたものはすべて全体的な精度に一致しなければならない。それができない場合は、イラストで置き換えるか、タイポグラフィ/抽象図形で表現する。
   • コストを削減するには、同じ言語内で簡略化する。デフォルトのコンポーネント、ブラウザネイティブのスタイリング、またはプレースホルダー画像にフォールバックしてはならない。
7. 読みやすさと操作性が最優先。
   • 中国語本文：14px以上（15〜17pxが目安）、line-height 1.6〜1.9、1行あたり約20〜40文字、本文コントラスト4.5:1以上。
   • 雰囲気は色温度、光、素材、動きによって伝えられる。テキストと数字は鮮明に保つ。
   • 小さなテキスト、低コントラスト、または「プレミアム」の略語としての無意味な英語は禁止。
   • 画像とテクスチャは、本文やクリックターゲットの上に決して配置してはならない。
   • 完全なインタラクションステート、キーボード操作可能、対象幅に適合していること。
8. デフォルトは選択されなければならず、継承されてはならない。 デフォルトのフォント、パレット、コンポーネントライブラリのスタイル、またはブラウザのスクロールバー/フォーカスリングは、意図的に選択された場合にのみ保持する。一般的なAIゲームUIキット（ベージュの紙＋ダークスレート、赤い歪んだスタンプ、小さなタグ、六角形のステップノード、レーダーチャート）もまたデフォルトである。ある流行のデフォルトを別のものと交換することも、依然としてデフォルトである。
9. エンジニアリング上の抑制。 既存のコード、依存関係、アセットを再利用する。アセット計画に従ってのみアセットを生成/収集する。新しい重い依存関係、アセットパイプライン、バックエンドのリファクタリングは禁止。

実行フロー

1. シーンを理解する

確認事項：ジャンル；キャラクター/世界の詳細；目標とする雰囲気；ページの目的；中核情報とアクション；対象デバイス；ホスト環境（例：チャットに埋め込み）。 既存のコードとアセットをレビューする。ユーザーからの参照：画像ではなく、アート技法を抽出する。重大な曖昧さがない場合は、質問せずに進める。

2. 方向性を設定する（すべての中規模以上のタスク）

設計記録に以下を記述する：

• インターフェースのアイデンティティ：どの物体/システムか、誰によって作られたか、誰によって読まれるか。
• 記憶点：一文で。この作品の固有の詳細から来なければならない。
• アートディレクション：媒体、筆致、光の方向、パレット、明瞭度 — 後続のすべての生成要求でそのまま再利用される、1つの共有スタイル記述。
• 除外リスト：この作品が避けなければならないジャンルの定型とデフォルト。
• アセット計画：具体的なアートアイテムごとに、目的、比率、クロップ、透明度、ソース（既存 → AI → Web）を記載。実際に存在することを確認してからコミットする。AIもライセンスされたWebアセットも方向性をサポートできない場合は、今すぐその旨を伝える。

3. 構築する

タスクレベルに従う：

• シンプル：実装、スクリーンショット、最悪の1〜3つの問題を修正、完了。
• ミディアム：焦点領域をフル品質にする → ページを完成させる → 1回の統合レビューパス。
• コンプレックス：workflow.mdの6つのステージ（方向性 → コンポジション → コアサンプル → モジュールごとの拡張 → ポリッシュ → 受け入れ）に従う。ステージは品質ゲートであり、レポートチェックポイントではない。継続的に進める。システム的な問題が発生した場合は、関連するステージに戻り、影響を受けた部分のみをやり直す。

構築中：

• プロジェクトのコードとインタラクションパターンを再利用する。
• 装飾フォントはタイトル専用。CJKグリフカバレッジを確認し、フォールバックスタックを設定する。
• すべてのステート：ホバー、フォーカス、アクティブ、選択済み、無効、ローディング、空、エラー — 視覚的に一貫性を保つ。
• モーションはインタラクションと雰囲気に貢献する。作品全体で同じ持続時間/イージングファミリーを使用する。prefers-reduced-motionを尊重する。

4. アセットを統合する

• 最初にヒーローイメージを配置し、次にサポート情報を配置する。
• クロップ、マスク、カラーグレーディング、グレイン、エッジブレンド、統一された光の方向によってアセットを統一する。テキストのための静かなゾーンを残す。
• 異なるソースのスタイルが競合する場合 → グレーディングして一致させる。それでも競合する場合 → 強制せず、置き換える。
• アセットはローカルプロジェクトファイルであり、ホットリンクURLではない。ライセンス/帰属を尊重する。

ビジュアルレビュー（スクリーンショットベース、最大の問題から順に）

1. 一目見た印象（サムネイル、約1秒）：視線はどこに留まるか。計画された焦点ポイントか。記憶に残るものはあるか。
2. 目を細めて：値の構造が2〜3の塊として読めるか。画面は主にイラストか、それとも暗いパネルか。
3. タイトルを隠す：それでもこの作品として認識できるか、同じジャンルのテンプレートと間違えないか。
4. 並べて比較：すべての領域が1つのアートディレクション（光、線、素材、パレット、タイポグラフィ）に見えるか。
5. 実寸大：中国語本文が快適に読めるか。
6. 端：配置、はみ出し、ブラウザネイティブのクローム、空の状態、残っているコード描画アートやプレースホルダーがないか。
7. インタラクション：ステートとモーション。
8. 対象幅：狭い/埋め込みレイアウト。

修正の優先順位：方向性 > コンポジション > 中核アート > 一貫性 > 可読性 > 詳細。1ラウンドあたり上位1〜3問題のみを修正。各ラウンド後に再スクリーンショット。ステージごとに最大2ラウンド。各修正セッションの前にロールバックポイントを保持する。

修正前に原因クラスを診断する：中核アートの欠如 / 弱いコンセプトアイデンティティ / 弱いコンポジション階層 / スタイルの競合 / 可読性またはレイアウトエラー。それぞれに異なる修正がある。

メインモデルが画像を見られない場合は、既存のビジョンツールを再利用するか、レビューをビジョン対応のサブエージェントに委任する。実際に検証されたことだけを報告する。

受け入れチェックリスト（すべて「はい」であること）

1. この作品自身のコンテンツから来た、記憶に残る一目でわかる要素はあるか？
2. タイトルを隠しても、このUIは同じジャンルのテンプレートと混同されないか？
3. 最も重要なビジュアル領域は、そのステータスに一致する精度のイラストレーションアセットを使用しているか — コードで描かれた図形や、明らかに粗い要素がフレーム内にないか？
4. アセット、タイポグラフィ、コンポーネント、背景は1つのプロダクションとして読めるか？最も地味な領域でさえ、絵画的で同じ品質基準にあるか？
5. ページは明確で、操作可能で、対象幅に適合しており、機能がビジュアルに犠牲にされていないか？

納品

• 最初に実行可能な結果を納品する。
• 複雑なタスク：中核アートコンセプト、実際に使用したアセット（ライセンス注釈付き）、レビュー中に行った主な修正、検証結果、およびまだプレースホルダーのものを簡潔に述べる。
• シンプルなタスク：主要な変更のみを述べる。
• ユーザーへの長いデザインドキュメントは不要。設計記録はステージ間/セッション間の継続性のために存在し、ユーザーレポートではない。