distill

distillスキルの概要

distillでできること

distillスキルは、デザインを「本来果たすべき役割」までそぎ落とすためのUI簡素化ワークフローです。画面がごちゃついて見える、ノイズが多い、装飾過多、機能を盛り込みすぎている、ひと目で把握しづらい――そんな場面で使うことを想定しています。UIをさらに足していくのではなく、distillは逆方向に進みます。不要なものを削る、まとめる、隠す、明確にする。その結果、ユーザーの主目的がひと目で分かる状態を目指します。

UI Design向けdistillが特に合うケース

distill for UI Designは、すでに画面・コンポーネント・フローがあり、機能性を損なわずにもっと整理された状態にしたいときに向いています。特に、次のような課題を抱えるデザイナー、フロントエンドエンジニア、プロダクト開発者に適しています。

• 情報や要素が詰め込まれたダッシュボード
• 選択肢が多すぎるフォーム
• 複数のCTAが競合している画面
• 視覚的ヒエラルキーが弱いUI
• 色、スタイル、装飾表現が多すぎるデザイン
• 主タスクを埋もれさせる機能追加の積み重ね

distillスキルの本当の役割

distill skillの実務的な役割は、「もっと見た目を良くする」ことではありません。UIにおける唯一の主目的を見極め、その達成を邪魔する要素を減らしていくことです。実際には、何を完全に削除するか、何を段階的開示の裏に隠すか、何を統合するか、何を強調するかを判断するためのスキルです。

汎用プロンプトとdistillの違い

一般的な「このUIをシンプルにして」というプロンプトでは、抽象的で曖昧な助言に終わりがちです。distillが実用的なのは、簡素化をきちんとした監査プロセスとして扱う点にあります。

1. 複雑さの発生源を見極める
2. 本当に重要なタスクを特定する
3. 不要な要素やバリエーションを削る
4. 使い勝手を維持したまま分かりやすさを上げる

この構造があるからこそ、場当たり的なプロンプト運用ではなく、あえてインストールして使う価値があります。

導入前に知っておきたい注意点

最大の制約は、distillが単体完結ではないことです。スキル自身の指示として、まず /frontend-design を呼び出し、まだデザイン文脈がない場合はその前に /teach-impeccable を実行する必要があります。単独でそのまま使えるスキルを期待している場合、この依存チェーンは導入判断における大きな注意点です。

distillスキルの使い方

distillのインストール文脈

このスキルは pbakaus/impeccable の .agents/skills/distill にあります。よくあるインストール方法は次のとおりです。

npx skills add pbakaus/impeccable --skill distill

今回確認できるリポジトリ断片では SKILL.md しか公開されていないため、使い方の一次情報はこのファイルだと考えるのが適切です。また、同一リポジトリ内の他スキルと連携する前提で設計されていると見ておくべきです。

最初に読むべきファイル

まず読むべきなのは次です。

• SKILL.md

distill usageを把握するうえでは、READMEよりもこのファイルが重要です。実際の呼び出し条件、ワークフロー、事前ステップがここに書かれているためです。

必須の依存チェーンを守る

distillを使う前に、次の順番で進めてください。

1. /frontend-design を呼び出す
2. そのコンテキスト収集プロトコルに従う
3. まだデザイン文脈がなければ /teach-impeccable を実行する
4. そのあとで distill を実行する

これは見栄えを整えるための任意手順ではありません。スキルは明示的に事前のデザイン文脈に依存しています。このステップを飛ばすと、表面的だったり根拠の薄い簡素化提案になりやすくなります。

distillに必要な入力

distill skillは、対象が具体的であり、なおかつ何が本質かを判断できるだけの文脈があると最も効果を発揮します。良い入力には通常、次の情報が含まれます。

• 対象となる具体的な画面、コンポーネント、またはフロー
• ユーザーの主タスク
• 現在の問題点（情報過多、アクション過多、ヒエラルキーの弱さ、視覚ノイズなど）
• 必須フィールド、法務文言、プラットフォーム制約、既存デザインシステムなどの制約

最小限の対象指定例:

• distill checkout sidebar
• distill onboarding modal
• distill analytics dashboard header

ざっくりした依頼を強いdistillプロンプトに変える

弱いプロンプト:

• 「このページをシンプルにして」

より強いdistill guide型のプロンプト:

• “Use distill on the settings screen. The main goal is helping users change notification preferences quickly. Current issues: too many card sections, repeated labels, three competing save actions, and decorative borders everywhere. Keep required compliance copy and email/SMS toggles. Recommend what to remove, combine, hide, or restyle.”

これが機能する理由は次のとおりです。

• 主目的が1つに定義されている
• 複雑さの原因が見えている
• 削れない要素が明示されている
• ふわっとした批評ではなく、実行可能な簡素化判断を求めている

distillが見ているポイント

ソース上、distillは次の観点を積極的に監査します。

• 要素が多すぎないか
• スタイルのばらつきが多すぎないか
• 情報過多になっていないか
• 視覚ノイズが強くないか
• ヒエラルキーが分かりにくくないか
• 機能追加の積み重ねで複雑化していないか

もし該当する項目が分かっているなら、最初から明言したほうがよいです。限られた文脈から全部推測させるよりも、distillの判断がぐっと明確になります。

実務でのおすすめdistillワークフロー

現実的な運用フローとしては、次の形が扱いやすいです。

1. /frontend-design で画面文脈を集める
2. ユーザーの主目的を1つだけ明示する
3. 具体的な対象に対して distill を実行する
4. 削除・統合の提案を確認する
5. 改訂後レイアウトの考え方や実装方針を追加で聞く
6. 簡素化後も必要なエッジケースを支えられているか検証する

この流れが重要なのは、簡素化はやりすぎやすいからです。distillの最も良い使い方は、まずノイズを落とす1回目、その後に必要機能が生き残っているか確かめる2回目、という二段構えで進めることです。

期待できる出力

得られる提案としては、主に次のような内容を想定するとよいです。

• 完全に削除すべきもの
• 段階的開示の裏に隠すべきもの
• 1つの操作やセクションに統合すべきもの
• 抑えるべき視覚表現
• 主アクションを中心にヒエラルキーを強める方法

一方で、こちらから追加で掘り下げない限り、ピクセル単位の実装詳細まで自動で出てくることは期待しないほうがよいです。

出力品質を変える実践的なコツ

distill usageの質を上げるには、次を意識してください。

• 1回につき1画面に絞る
• 主タスクを1文で言い切る
• 必須要素と任意要素を分けて伝える
• ビジネス上重要で、見える状態を維持すべき操作を明記する
• 可能ならスクリーンショット、コンポーネント一覧、コード構造も添える

このスキルの中核ロジックは「主目的を損なわずに何を削れるか」です。必須要素が曖昧なままだと、最も早く出力が弱くなります。

distillが特に効く場面

distill skillが最も強いのは、「ちゃんと動いてはいるが、窮屈で散らかって感じるUI」です。特に次のようなケースで有効です。

• 長年の追加でコントロールが増え続けた社内ツール
• 表示データが多すぎるエンタープライズ画面
• 情報密度が高すぎて視認性が落ちるモバイル画面
• プロダクトの機能範囲は変えないまま、分かりやすさだけ改善したいリデザイン工程

distillスキルFAQ

distillは初心者にも向いていますか？

はい。すでに簡素化したい具体物があるなら有効です。自由度の高いデザイン批評よりも、distillのほうが「どう整理するか」の視点がはっきりしています。初心者にとっての難所は、事前ワークフローです。distillを1行の魔法コマンドとして扱うのではなく、リポジトリが前提としているデザイン文脈のセットアップに従う必要があります。

distillは見た目の整理だけに使うものですか？

いいえ。distill skillが対象にするのは、見た目の整頓だけではありません。アクション数が多すぎる、同時に見せる情報が多すぎる、優先順位が不明瞭、機能過多で重い、といった構造上の複雑さにも踏み込みます。表層スタイルだけでなく、インタラクション設計やヒエラルキーにも関わるスキルです。

distillを使わないほうがいいのはどんなときですか？

主問題が機能不足、要件の不明確さ、タスクフロー定義の甘さにある場合は、distillは向きません。本当のユーザー目的が固まる前にUIだけ簡素化すると、残すべきものではなく別のものを削ってしまう危険があります。また、削ぎ落としではなく広く発想を広げたい段階にも適していません。

distillと普通のプロンプトの違い

通常の「これをもっと見やすくして」プロンプトに対するdistillの強みは、判断モデルが絞られている点です。何が必要か、何があれば望ましい程度か、何を削除・非表示・統合できるかを明示的に問います。そのため、自由なビジュアル探索よりも、散らかったUIを整理する意思決定に向いています。

distillはimpeccableの他スキルなしでも使えますか？

きれいには回りません。ソースを見る限り、distillは事前に /frontend-design、場合によっては /teach-impeccable の実行を前提にしています。もし環境上それらの補助スキルを呼び出せないとしても、手動で同じ流れを再現することは可能です。ただし、本来意図されたコンテキスト準備の一部は失われます。

distillはコード中心のチームにも向いていますか？

はい。distill installを検討する価値は、特にフロントエンド比重の高いチームで大きいです。というのも、何が本当に必要かの判断は、コード上の条件分岐やプロダクトロジックの理解と切り離せないことが多いからです。リリース済みUIに、コントロール数・状態数・視覚表現の多さとしてデザイン負債が現れている場合に特に役立ちます。

distillスキルをより良く使うには

distillに主目的を1つだけ与える

最も効果が大きい改善策は、対象UIの主タスクを1つに絞って伝えることです。ソースでも、主たるユーザー目標は ONE であるべきだと強調されています。複数の目標を同列に置くと、distill skillは大胆に簡素化できません。何もかもが必要に見えてしまうためです。

削れるもの・残すべきもの・未確定を分ける

distill向けの強いプロンプトでは、次を分けて提示します。

• must keep
• safe to remove
• uncertain or negotiable

この整理により、よくある2つの失敗を防げます。何も削れず無難すぎる出力になること、あるいは必要な要素まで削る強引な出力になることです。

複雑さの原因を具体的に書く

「なんとなくごちゃついている」とだけ伝えるのは不十分です。distillには、たとえば次のどれが原因なのかを明示してください。

• ボタンが多すぎる
• 同じ情報が繰り返されている
• 視覚スタイルが多すぎる
• 不要な枠線やシャドウが多い
• グルーピングが悪い
• 常時表示の選択肢が多すぎる

この指定があると提案精度が上がります。もともとスキル側も、こうしたカテゴリで複雑さを捉える設計になっているからです。

総評ではなく、削る判断を求める

より良い依頼は次です。

• “Use distill and list what should be removed, combined, hidden, or visually softened.”

弱い依頼は次です。

• “Thoughts on this design?”

前者はそのまま実装につなげやすい出力を生みます。後者は広い感想戦になりやすく、distill guideワークフローの価値を下げます。

1回目で簡素化し、2回目で妥当性を検証する

最初のパスのあとには、次を追加で聞いてください。

• この簡素化で生じるユーザビリティ上のリスクは何か
• エッジケースが深く隠れすぎていないか
• メインCTAはより明確になったか
• 重要な副次アクションは引き続き見つけやすいか

この2回目があることで、distill usageの質は上がります。簡素化の良し悪しは、単に減らせたかではなく、必要な機能を適切に残せているかで決まるためです。

説明だけでなく成果物を渡す

可能であれば、次のような具体物を添えてください。

• スクリーンショット
• ワイヤーフレーム
• コンポーネント一覧
• 現在の情報ヒエラルキー
• 条件付きUIに関係するコード断片

対象が具体的であるほど、distillは何が装飾的か、何が冗長か、何が構造的に不要かを自信を持って判断できます。

よくある失敗パターンを把握する

結果が弱くなりがちな典型例は次のとおりです。

• 画面の主目的が曖昧
• ステークホルダーの要望をすべて同じ重みで扱っている
• 必須制約が共有されていない
• プロダクト全体を一度に簡素化しようとしている
• /frontend-design による文脈収集を省略している

distillの出力が generic に感じるとき、原因はスキルそのものより、入力の具体性不足であることがほとんどです。

distillにトレードオフの説明も求める

出力への信頼を高める方法として有効なのが、次の観点の説明も求めることです。

• 各削除でユーザーにどんな利点が生まれるか
• 機能を隠すことで発生する発見性のコストは何か
• 分離された操作より統合コントロールのほうが良い理由は何か

こうすることで、distill skillは単なる整理ツールではなく、チーム内で採用しやすい意思決定支援ツールになります。

distillのあとに実装向けフォローを入れる

distillで簡素化の方向性が見えたら、次の内容を別リクエストで続けるのが有効です。

• 改訂後のレイアウト構成
• デザインシステムに沿ったコンポーネント選定
• フロントエンド実装メモ
• 簡素化後画面の acceptance criteria

この引き継ぎまで行ってはじめて、スキルが「考え方として正しい」だけでなく、「実務で使える」状態になりやすくなります。