AIに渡すデザインのスキル

何も渡さなければ、AI は既定の見た目を出します。渡すなら、その工程に要るものだけを渡します。

図を大きく見る

図の中身を文字で読む

• 全部を読ませない。その工程に要るものだけを読ませる
• 決める　手法の選定　taste-skill　手法を選び、AIっぽさを潰す関門を先に置く
• 読み物や管理画面では起動しない
• 詰める　grilling　ui-ux-pro-max　frontend-design　要件を詰め、方針を決め、形にする　曖昧なまま作らせない
• 整える
• baseline-ui　fixing-accessibility　fixing-motion-performance
• 余白と文字組み、キーボードと読み上げ、動きの重さ。作ったあとに通す
• 確かめる　web-design-guidelines　design-review　最後は実ブラウザで開いて撮り、
• 文字組みとコントラストを実測する
• スキルより、自分の決めごとが強い
• 食い違ったら自分の決めごとを採る
• 自分の決めごと（禁止する語・色・書き方）　外部から入れたスキル
• 外部のスキルは原文のまま残し、先頭に自分用の節を足して「ここが上流より強い」と宣言しておく。
• こうしておくと、上流が更新されたときに自分の節を残したまま原文だけ差し替えられる。
• 失敗の見本も持っておく。何も指示しない状態の出力を1つ残し、それに似てきたら失敗と判定する。

ひと目で#

• スキル = AI に渡す専門知識のひとまとまり。案件の中身に応じて、要る分だけ読み込まれる
• ルール = どの案件でも常に効く、自分の決めごと。スキルより優先させる
• 全部を読ませない。その工程に要るものだけを読ませる

スキルは「何をやるか」を与え、ルールは「やってはいけないこと」を縛ります。役割が違うので、両方が要ります。

判断の土台になる2つ#

最初に効くのはこの2つです。ここがないと、以降のスキルは既定値の上で細部を整えるだけになります。

選定カタログは自分で書いて持ちます。要るのは選択肢を並べた表と、そこから毎回1組を選ばせる決まりだけです。デザインスタイル、動きの付け方、写真や映像の使い方、機能のデモ、進め方を、それぞれ数種ずつ書き出しておきます。使わないものも1つ入れておきます。 何も指示しないときの出力を、「これに似てきたら失敗」の照合用に残すためです。

選び方は、この資料のデザインスタイルがそのまま使えます。

• AI Slopを避ける既定の見た目の外し方
• デザインスタイルの選び方位置から決める

作風に特化したもの#

上のカタログで選ばれたときだけ読ませます。常に読ませると、どの案件も同じ作風に寄ります。

いずれも Leonxlnx/taste-skill（MIT）。

工程ごとのもの#

読ませる順#

上から順に、その工程に来たものだけを読ませます。

管理画面、業務システム、データテーブル、多段のフォームでは、作風のスキルを起動しません。 読み物向けの作風が、業務画面を壊すからです。

スキルより自分のルールを強くする#

外部のスキルをそのまま使うと、そのスキルの好みがそのまま出ます。原文は残したまま、先頭に自分用の節を足して「ここが上流より強い」と宣言しておくのが扱いやすい形です。上流が更新されたとき、自分の節を残して原文だけ差し替えられます。

強くする例。

• 使わない語のリストを最優先にする
• 特定の色を禁止する。上流にある「求められたら可」の例外を採らない
• 連番、余計な英語ラベル、二倍ダッシュを使わない
• 見出しに句読点を付けない

緩める例も要ります。 上流のルールがそのまま当てはまらない場面があるからです。

入れ方#

細かい手順を人が調べなくても、たいていはエージェントに頼めば入ります。 置き場所も形式もエージェントごとに違うので、「どこに何を置くか」ではなく「何を入れたいか」を伝えるほうが速いです。

1件だけ入れる#

チャットにこう書きます。

taste-skill（https://github.com/Leonxlnx/taste-skill）をこの環境のスキルとして
インストールして。置き場所と読み込みの設定も、この環境の作法に合わせて。
入ったら、どこに置いたかと、発動する条件を教えて。

名前とリポジトリのURLの2つがあれば足ります。入ったあとに「どこに置いたか」を答えさせるのが要点です。読み込み先を間違えたまま「入りました」と言われることがあります。

まとめて入れる#

一覧を渡して、順番も任せます。

次のスキルをまとめて入れて。
- taste-skill … AIっぽさを消す（最優先）
- design-review … 実ブラウザで見た目を検査
- fixing-accessibility … フォーム・ダイアログの操作性
- fixing-motion-performance … 動きの負荷
入れ終わったら、一覧・置き場所・重複しているものを表で出して。
重複していたら、どちらを残すか案を出して。

まとめて入れると重複が起きます。 同じ役割のスキルが2つ入ると、指示が競合してどちらが効いたか分からなくなります。入れたあとに突き合わせるところまで頼みます。

優先順位をつけて入れる#

読む順番は、そのまま出力の質に効きます。先に読ませたものが土台になります。

次の順で読ませたい。設定ファイルにこの順序を書いて。
1. 自分のルール（NG表現・配色の禁止・版面の決めごと）
2. taste-skill（品質のゲート）
3. 手法の選定カタログ（毎回1組を選ばせる）
4. 工程ごとのスキル（実装・アクセシビリティ・動き）
5. 最後に design-review（実ブラウザで検査）
1 が 2〜5 より必ず優先されるように書いて。

順序を口頭で伝えるだけでは残りません。設定ファイルに書かせて、次のセッションでも効く形にします。

環境ごとの違い#

頼み方は同じです。

この環境（Windows / WSL / Mac のどれか）を確かめて、
その作法に合う場所へ入れて。入れたパスを教えて。

WSL と Windows を行き来する場合は、どちらを正本にするかを先に決めます。片方を正本にして、もう片方からは同じ内容を入れ直すのが確実です。ファイルの共有（/mnt/c/...）は、改行コードと権限で詰まることがあります。

複数のエージェントで使い回す#

スキルの中身（Markdown の指示文）は、たいていエージェントを問わず読めます。違うのは、置き場所と読み込ませ方だけです。

同じスキルを、ほかのエージェントでも使いたい。
中身は1か所（例: C:\dev\skills）に置いて正本にして、
各エージェントの設定からそこを参照する形にして。
参照できない実装があれば、その環境だけコピーを置いて、
正本を直したときに更新する手順もメモして。

正本を1つにするのが肝です。 各エージェントに散らばると、直したつもりの内容が別の環境で古いままになります。

常に効くものと、呼んだときだけ効くもの#

常に効くものを増やしすぎない。 毎回読まれるものが多いほど、1件あたりの効きが薄くなります。常に効かせるのは「やってはいけないこと」だけにして、「何をやるか」は呼んだときに読ませます。

発動条件は、スキル側ではなく自分のルールに書きます。

LP・ブランドサイト・トップページ・ヒーローに触るときだけ、
taste-skill と選定カタログを読む。
管理画面・業務システム・データテーブル・多段フォームでは読まない。
この条件を設定ファイルに書いて。

入ったか確かめる#

入れた直後に、必ず一度だけ確かめます。

いま読み込めるスキルを一覧で出して。
それぞれ、発動する条件と、読み込み元のパスも添えて。

一覧に出ないものは、入っていないか、読み込み先が違っています。 ここで気づかないと、効いていないまま何日も使うことになります。

入れるときに詰まるところ#

• 置き場所がエージェントごとに違う。 共通の標準ディレクトリに入れたつもりで、実は読まれていないことがある。使うエージェントの公式ドキュメントで読み込み先を確かめる
• Windows と WSL は別の環境。 片方に入れても、もう片方からは見えない
• プラグイン形式は同梱物ごと入る。 1つだけ欲しくても、束で入ることがある。要る分だけ個別に入れる選択肢も持っておく
• 発動しない範囲を先に決める。 管理画面、業務システム、文章だけの作業を対象外にしないと、作風が染み出す

出どころ#

関連#

• AIに作らせる指示に何を書くか
• AI Slopを避ける既定の見た目から外す
• 検証と完了どこで人が判定するか
• カンプ画像から組む入口B。画像で先に決める
• AIと制作二つの入口と合流の地図
• 実物のデザインシステム判断の根拠を実物で見る