polish

polishスキルの概要

polishでできること

polish スキルは、UIを最終チェックするためのレビュー用ワークフローです。作業が「ほぼ完成」に見える状態から、本当に出荷できる品質まで引き上げるうえで見落としやすい問題を拾うことに特化しています。主に、位置合わせ、余白、一貫性、トークンの使い方、視覚的なリズム、インタラクションの細部、そして一般的なプロンプトでは見逃されがちな実装上の小さなズレを確認します。

polishスキルが向いている人

この polish スキルは、すでに動くUIがあり、レビュー前・リリース前・引き継ぎ前に仕上がりの質をもう一段上げたい場合に向いています。対象は、デザイナー、フロントエンドエンジニア、AI支援でUIを作るビルダーです。特に、画面・フロー・コンポーネントが「かなり近いが、どこかしっくりこない」と感じるときや、デザインシステムや既存プロダクトの慣例に沿って仕上げる必要がある場面で相性が良いです。

インストール前に確認すべきこと

導入時に最も重要なのは、polish はゼロからデザインの方向性を作るためのスキルではない、という点です。前提として、すでに何かしらのUIがあり、それを点検・改善する用途を想定しています。さらに、このスキルは $impeccable に依存しています。明示的に、文脈収集・原則整理・アンチパターン確認のために、先にその上位スキルを実行する必要があります。まだデザインの前提が固まっていない場合、ワークフローでは polish の前に $impeccable teach を使うよう案内されています。

なぜ普通のプロンプトでは不十分なのか

単に「見た目をよくして」と頼むだけでは、曖昧な助言になったり、方向性の定まらないリデザイン案が返ってきたりしがちです。polish が有効なのは、実在するシステムに照らして、体系的に確認したいときです。つまり、どのデザイン慣例に従うべきかを特定し、トークン・コンポーネント・パターンからのズレを見つけ、プロダクトを不必要に変えすぎずにピンポイントで修正する用途です。そのため、リリース前の仕上げや、UIデザインの一貫性を整える作業で実用性があります。

polishスキルの使い方

インストール時の前提と最初に読むべきファイル

このスキルは pbakaus/impeccable リポジトリから導入し、まず SKILL.md を確認してください。実際の運用ルールはそのファイルに書かれています。中でも最重要なのは必須指示で、先に $impeccable を呼び出すことです。polish install を検討するうえでは、このスキルは単発のスタンドアロン用途よりも、より広い impeccable ワークフローの一部として使うのが前提だと理解しておくべきです。

polishがうまく機能するために必要な入力

polish スキルは、次の情報があると最も力を発揮します。

• 対象となる画面、フロー、またはコンポーネント
• 現在の実装、またはスクリーンショット
• 利用可能であれば、デザインシステム、コンポーネントライブラリ、またはトークンの運用ルール
• 目指す品質水準: MVP または flagship
• たとえば「余白が不揃いに感じる」「ボタンの見た目が揃っていない」といった既知の課題

弱い依頼例: Polish this settings page.
より強い polish usage プロンプトの例: Use polish on the settings page. Quality bar: flagship. Match our existing design system. Check spacing scale, token usage, component consistency, alignment, and interaction details. Avoid redesigning layout unless needed.

実践的なpolishワークフロー

信頼しやすい進め方は次のとおりです。

1. まず $impeccable を実行し、文脈と原則を集める。
2. デザインシステムを特定する。存在しない場合は、近接するプロダクト領域から慣例を推定する。
3. 現在のUIにズレがないか確認する。たとえば、ハードコードされた値、不揃いな余白、重複した独自パターン、ムラのある階層、視覚的ノイズなど。
4. まずは影響が小さく、確信度の高い変更から適用する。
5. 局所的な修正が新たな不整合を生んでいないか、最後に画面全体を見直す。

これが最も実用的な polish guide の考え方です。いきなり編集に入らないことが重要です。リポジトリでも、細部を変える前に、このプロダクトにおける「polished」とは何かを理解することが重視されています。

UI Design向けpolishのプロンプトのコツ

polish for UI Design では、出力形式を構造化して依頼すると効果的です。たとえば、次のような追加指示が有効です。

• List issues by severity before proposing changes.
• Prefer system alignment over novelty.
• Call out where tokens or shared components should replace custom styling.
• Separate must-fix launch blockers from nice-to-have refinements.

こうした指定で出力品質が上がるのは、このスキルが得意なのは幅広い創造的探索ではなく、体系的な点検だからです。探索や方向性の検討をしたいなら、先にコンセプト作成向け、またはリデザイン向けのスキルを使い、最後の仕上げとして polish を入れるのが適しています。

polishスキルのFAQ

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

はい。すでに改善対象となる具体的なUIがあるなら有効です。polish スキルは、特に余白、一貫性、デザインシステムへの整合といった観点で、一般的なプロンプトよりも初心者にとって実用的なチェックリストになります。ただし、まだ自分のプロダクトの慣例が見えていない段階だと、初心者向けとは言いにくくなります。ワークフロー自体が、文脈がすでに存在するか、もしくは $impeccable を通して教え込まれていることを前提にしているためです。

どんなときはpolishを使うべきではありませんか？

問題の本質が戦略、情報アーキテクチャ、またはUX方針の欠如にあるなら、polish は使わないほうがよいです。白紙の状態からデザインを作る用途にも向きません。画面の根本設計が間違っている場合、polish は適切なリデザインの代わりにはなりません。これは仕上げや品質向上のためのスキルであって、プロダクトの中核を発明するためのものではありません。

polishはコードレビューと何が違いますか？

コードレビューでは、保守性や正しさの問題が見つかることがあります。一方、polish スキルが主に見るのは、実際に出荷される体験の質です。たとえば、見た目の一貫性、システムからのズレ、細部の完成度、そしてインターフェース全体にまとまりがあるかどうかです。重なる部分はありますが、polish usage の主眼はエンジニアリングのアーキテクチャではなく、UI品質にあります。

polishにデザインシステムは必須ですか？

いいえ、必須ではありません。ただし、あるほうがより効果的です。正式なシステムがなくても、このスキルは見えているプロダクト上の慣例に合わせて仕上げることを求めます。そのため、雑多に育ったプロダクトでも役立ちますが、再利用可能なトークン、コンポーネント、確立されたパターンがある場合のほうが、出力の質は明らかに高くなります。

polishスキルを改善する方法

polishの対象をより明確にする

polish の結果を最も手早く改善する方法は、対象を明確に定義することです。たとえば MVP か flagship か、どの画面やUI面を点検するのか、目的が一貫性の改善なのか、高級感の演出なのか、リリース準備なのか、デザインシステム準拠なのかをはっきりさせます。ここが曖昧だと、重要ではない細部を過剰に直したり、品質がそこまで求められていない箇所に労力を使ったりしやすくなります。

意見だけでなく、根拠となる材料を渡す

より良い入力ほど、polish の結果も良くなります。スクリーンショット、コンポーネントコード、隣接する画面、トークンファイル、あるいは「このレベルを目指したい」という具体例を渡してください。そうすることで、実際の不整合と意図的な差異を見分けやすくなります。「もっと良くして」としか伝えない場合、基準を推測するしかなくなります。

よくある失敗パターンに注意する

主な失敗パターンは次のとおりです。

• 微調整ではなく、過剰なリデザインに寄ってしまう
• 局所的な修正を優先した結果、ページ全体のリズムを崩す
• 共通コンポーネントに寄せず、新しい独自スタイルを増やしてしまう
• すべての不一致をバグ扱いし、本来意図された差異まで消してしまう

プロダクトで確立済みのパターンは、品質を明確に損なっている場合を除き、維持するようスキルに指示するとよいです。

初回の出力後にもう一段階回す

実運用で polish スキルの精度を上げる最善策は、最初の出力のあとにフィードバック付きで2回目を回すことです。たとえば too aggressive、keep layout unchanged、focus only on spacing and typography、prioritize design-token cleanup のように具体的に返してください。そうすることで、広めの改善提案から、チームが期待する基準に合った絞り込み済みの仕上げに近づけられます。