distill

distillスキルの概要

distillができること

distill は、画面を「本来果たすべき役割」まで研ぎ澄ますための、UIデザイン簡素化ワークフローです。インターフェースがごちゃついて見える、情報ノイズが多い、装飾過多、選択肢を詰め込みすぎている――そんな場面で、機能追加ではなく、よりクリーンで芯のある方向性を出したいときに向いています。

UI Design向けdistillが最適なケース

distill for UI Design は、すでに画面・フロー・コンポーネントが存在していて、それをもっと落ち着かせ、わかりやすくしたいときに適しています。相性がいいのは、次のような作業を行うデザイナー、frontend engineer、プロダクトチーム、AI agentです。

• ダッシュボード、フォーム、設定画面、詳細ページの情報整理
• 競合するアクションの削減
• ビジュアル階層の単純化
• 装飾ノイズの除去
• “feature-rich” なレイアウトを、タスク優先のレイアウトへ変えること

本当に解くべき仕事

ユーザーが distill skill を導入する理由は、単に「デザインをシンプルにしたい」からではありません。実際には、もっと難しい問いに答えるために使います。

• 何を残すべきか
• 何を削るべきか
• 何を隠す、統合する、後回しにするべきか
• この画面における最重要のユーザーゴールは何か

そのため、distill は単なる「これをきれいにして」という汎用プロンプトより実用的です。価値があるのは、リデザインの前に優先順位づけを強制してくれる点です。

主な差別化ポイント

最大の特徴は、distill が単独完結のスタイル指示ではないことです。このスキルは明示的に、上流のデザイン文脈を前提にしています。

• まず /frontend-design を実行する
• まだデザイン文脈がない場合は、先に /teach-impeccable を実行する
• 主要ゴールや制約が曖昧なら、先に止まって確認質問をする

この依存関係は、導入判断でも重要です。distill は、単発の孤立したプロンプトとして使うより、impeccable デザインシステム全体の中で使うほうが強みを発揮します。

インストール前に知っておくべきこと

これは軽量なスキルで、主なファイルは SKILL.md のみです。スクリプト、サンプル、参照アセットは同梱されていません。中身を確認しやすい反面、出力品質は与える文脈に強く依存します。自己完結型で、手厚く足場が組まれた distill guide を期待しているなら、このリポジトリ配下の内容はツール主導というより、原則主導と考えたほうが近いです。

distillスキルの使い方

distillのインストール文脈

上流の SKILL.md にはインストールコマンドが書かれていないため、リポジトリに対する通常の Claude Skills インストール手順を使い、pbakaus/impeccable 内の distill スキルを対象にしてください。リポジトリから確認する場合、該当パスは次のとおりです。

https://github.com/pbakaus/impeccable/tree/main/.claude/skills/distill

このスキルはユーザーから直接呼び出せ、引数ヒントとして [target] を取るため、実運用では distill を曖昧なプロダクト全体依頼に使うのではなく、特定の画面・フロー・コンポーネントに対して適用するのが基本です。

最初に読むべきファイル

まず確認すべきなのは以下です。

• SKILL.md

このスキルフォルダには、README.md、metadata.json、rules/、references/ といった補助ファイルがありません。つまり、有用な挙動のほぼすべてがこの1ファイルに定義されています。導入可否を評価するうえでは好都合で、distill skill 全体を短時間で把握できます。

多くの人が見落とす必須依存

distill を使う前に、スキル側は /frontend-design を呼ぶよう明記しています。この上流ステップには、デザイン原則、アンチパターン、“Context Gathering Protocol” が含まれています。まだデザイン文脈がないなら、先に /teach-impeccable を実行する前提です。

ここは重要です。結果が弱くなる原因の多くは、この準備を飛ばすことにあります。スクリーンショットや曖昧な不満だけを渡して distill を直接呼ぶと、モデルが削ってはいけないものを削る可能性があります。

distillに必要な入力

質の高い distill usage は、具体的な対象と、そのUIの主目的を見極めるために十分な文脈から始まります。良い入力には、たとえば次のような情報が含まれます。

• 対象となる画面やコンポーネントを特定する情報
• ユーザーの主要タスク
• アクションが多すぎる、階層が弱いなど、現在の問題点
• コンプライアンス、必須コントロール、実装上の制約などのハード制約
• 単純化の方法として、削除・統合・非表示・段階表示のどれを想定するか

弱い入力の例:

• “Simplify this page.”

より強い入力の例:

• “Use distill on our analytics dashboard. The primary user goal is to spot traffic changes in under 10 seconds. Keep the date range picker and export action. We can remove secondary filters from the default view if needed. Current issues: too many cards, repeated metrics, heavy borders, and three competing CTAs.”

粗い要件を完成度の高いプロンプトにする方法

実践的な distill guide のプロンプト構成は次のとおりです。

1. 対象を明示する。
2. たった一つの主要ユーザーゴールを述べる。
3. 必ず残す要素を列挙する。
4. 削除や非表示の候補を挙げる。
5. 何が雑然として見えるのかを具体化する。
6. 最終的なリデザインの前に、まず簡素化プランを求める。

例:

“Apply distill to the onboarding modal for first-time team admins. The one goal is helping them invite teammates. Must keep: email entry, role selector, skip option. Nice-to-have elements that can be deferred: tips carousel, template preview, feature badges. The current design feels crowded because it mixes setup, education, and marketing. First identify complexity sources, then propose what to remove, combine, or hide.”

推奨ワークフロー

信号の強い distill usage の進め方は次のとおりです。

1. /frontend-design で文脈を集める。
2. 主要なユーザーゴールが単一であることを確認する。
3. distill はプロダクト全体ではなく、1画面に対して実行する。
4. 削除・統合・非表示の提案内容を確認する。
5. 「削除候補」が、実はポリシー・サポート・業務ロジック上必須ではないかをチェックする。
6. 制約をより明確にして反復する。
7. その後で初めて、ビジュアル調整や実装に進む。

この順番が大切です。distill は主に優先順位づけのツールであり、最後の磨き込み専用ではありません。

distillが分析しそうなポイント

スキル本文から見る限り、distill は次のような点を見にいきます。

• 要素が多すぎる
• 視覚表現のバリエーションが過剰
• 情報過多
• 視覚ノイズ
• わかりにくい階層
• feature creep

また、「価値の80%を生む20%」を特定する方向へ明確に寄せています。チームがスコープを削るのに苦戦しているなら、この考え方自体が distill を使う大きな理由になります。

先に進まず確認に切り替えるべき場面

元のガイダンスでは、コードベースやプロンプトから次の点が明確でない場合、いったん止まって質問すべきだとされています。

• 主要なユーザーゴール
• 必須なものと、あれば望ましいものの区別
• 何を削除・非表示・統合できるか

これは意味のある境界線です。チーム内でその画面のコアタスクに合意できていないなら、distill はそのプロダクト上の曖昧さをあぶり出します。魔法のように解決してくれるわけではありません。

distill初回利用に向く対象

最初の対象として適しているもの:

• 要素が詰め込まれた設定ページ
• カードが多すぎるダッシュボード
• 任意項目が最初から大量表示されるフォーム
• 複数の役割を同時に担っているモーダル
• 複数のCTAが競合しているランディングセクション

最初の対象として不向きなもの:

• 削除の自由度が低い、高度に規制されたワークフロー
• 具体的な画面を伴わないデザインシステム作業
• すでにミニマルだが、問題が主にインタラクションにある画面

出力に期待すべきこと

distill skill が特に役立つのは、次のような出力を返すときです。

• 複雑さの原因の診断
• より明確なコンテンツ階層とアクション階層
• 削除、統合、段階表示の提案
• もっと焦点の定まったユーザーパス

一方で、このスキル単体に、コード変換、自動監査、実装直結のコンポーネント差分まで期待しないほうがいいです。

distillスキルFAQ

distillは普通の簡素化プロンプトより優れているか

多くの場合は yes です。特に、漠然としたお掃除ではなく、構造化された簡素化が必要なときに向いています。このスキルは、複雑さの原因を見つける再現性のある視点を与え、主要ゴールを一つに絞ることを求めます。普通のプロンプトでも「もっときれいにして」とは言えますが、distill のほうが「実際に何を消すべきか」まで踏み込みやすいです。

distillは初心者向けか

はい。ただし注意点があります。文言自体はわかりやすく、リポジトリもほぼ1ファイルなので確認しやすいです。難しいのはインストールではなく、スキルをうまく使うためのUI文脈を十分に持っていることです。初心者なら、単一画面と明示的な制約から始めるのが安全です。

impeccableリポジトリ全体が必要か

distill install を試す前にリポジトリ全体を読み込む必要はありません。ただし、/frontend-design、必要に応じて /teach-impeccable への依存は、記載どおり守るべきです。このスキルは、そのエコシステムの中で機能するよう設計されており、それ自体ですべてを置き換える前提ではありません。

distillを使わないほうがいいのはいつか

主な問題が次のいずれかなら、distill は見送ったほうがいいです。

• ごちゃつきではなく、インタラクションロジックの破綻
• 不足しているユーザーリサーチ
• 多数の画面にまたがる、曖昧なプロダクト戦略
• 引き算ではなく追加対応が必要なアクセシビリティやコンプライアンスの問題

こうしたケースでは、単純化だけ進めると誤った方向に導かれることがあります。

distillはUI以外のタスクにも使えるか

リポジトリ上の根拠を見る限り、用途はUIとfrontend designが中心です。文言、/frontend-design への依存、分析カテゴリのいずれも、インターフェースの簡素化に軸足があります。コピー、システム、アーキテクチャの整理に使いたい場合は、確実に適合するスキルというより、発想源として扱うのが適切です。

distillスキルを改善する方法

distillには1画面・1ゴールで渡す

distill の出力を最も手早く改善する方法は、スコープを絞ることです。“Simplify our app” では広すぎます。“Distill the billing settings page so users can update payment method faster” なら実行可能です。このスキルは、対象に支配的なタスクが1つあるときに最も力を発揮します。

必須要素と交渉可能な要素を分ける

強いプロンプトでは、次を区別しておくべきです。

• 必須のコンテンツやアクション
• 非表示や削除が可能な任意項目
• 最初に削ぎ落とせる装飾要素

ここが曖昧だと、distill は政治的にも機能的にも削れないものを削減候補にしてしまい、レビューの1サイクルを無駄にしがちです。

どんな簡素化を望むのかをdistillに伝える

簡素化は、削除だけではありません。次のどの手段を重視したいかを指定すると、結果が良くなります。

• remove
• combine
• hide behind progressive disclosure
• downgrade visual emphasis
• sequence across steps instead of showing everything at once

これにより、distill usage は単なる「もっとシンプルにして」から、より鋭いデザイン操作に変わります。

実際の複雑さの症状を入れる

「画面がごちゃついている」とだけ言わないでください。何がごちゃついているのかを示します。

• ファーストビュー内にボタンが5つある
• 指標が重複している
• 意味のない3種類のテキストスタイルがある
• カードにシャドウ、ボーダー、色付き背景が同時に使われている
• 主要タスク完了前に二次設定が見えている

具体的な症状があると、モデルがスキル内の複雑性カテゴリに対応づけやすくなります。

典型的な失敗パターンに注意する

distill for UI Design の最大の失敗パターンは、間違った対象を過剰に単純化してしまうことです。重要な文脈、信頼シグナル、エッジケース用コントロールが消えると、見た目はすっきりしても使い勝手は悪化します。最初の提案が出たら、削除案をすべて実際のユーザータスクに照らして見直してください。

段階的な出力を依頼する

より良いプロンプトは、出力を段階で求めます。

1. 複雑さの原因を特定する
2. 本質的なタスクを定義する
3. 削除・統合・非表示の候補を列挙する
4. 簡素化後の構造を提案する

この段階的な進め方なら、distill guide は即時リデザインを一度に求めるより、監査しやすく、改善もしやすくなります。

1回目の出力後に制約を足して磨く

最初の出力が攻めすぎている、あるいは慎重すぎるなら、具体的な制約を追加して調整します。

• “Keep all legal disclosures visible.”
• “Do not add more steps.”
• “We can hide advanced filters behind an accordion.”
• “The primary CTA must remain above the fold.”

ブリーフ全体を書き直さずに distill skill の結果を改善する、もっとも実務的な方法です。

distillの後に実装レビューを組み合わせる

distill が何を削るか、何の優先度を下げるかを示したら、その結果を通常の frontend とプロダクトのレビューに通してください。このスキルが得意なのは、意思決定の枠組みを整えることです。実際にリリースする前には、state handling、accessibility、コンテンツの明瞭さ、エッジケースをチームで検証する必要があります。