clarify

clarify skill の概要

clarify skill でできること

clarify skill は、わかりにくい UX コピーを改善するためのスキルです。対象はラベル、補足テキスト、空状態、オンボーディングの案内、確認メッセージ、そして特にエラーメッセージです。インターフェースに機能が足りないのではなく、「言葉のせいでプロダクトが理解しづらくなっている」場面に向いています。

UI/UX Design 向け clarify が最も合うケース

clarify for UI/UX Design は、プロダクトデザイナー、UX ライター、フロントエンドチーム、PM、そしてリリース前に画面テキストをレビューする AI エージェントに最適です。すでに画面が存在していて、文言をより明確に、行動につながる形にし、ユーザー文脈に合うよう整えたいときに特に力を発揮します。

実際に解決したい仕事

ユーザーは単に「コピーを書き換える」ために clarify を導入するわけではありません。実際には、もっと実務的な問いに答えるために使います。たとえば、なぜこのメッセージが伝わらないのか、ユーザーはどこを誤解しそうか、どれだけ文脈を足すべきか、この場面に合うトーンは何か、ためらわず行動できる文にどう直すか、といった点です。

汎用プロンプトと clarify が違う点

いちばんの違いはプロセスにあります。このスキルは、単なる「いい感じに書き直して」という自由入力のプロンプトではありません。以下を構造的に見直すよう設計されています。

• 想定読者の技術レベル
• その瞬間のユーザーの心理状態
• ユーザーに次に取ってほしい行動
• 現在のテキストに欠けている文脈
• 専門用語、曖昧さ、思い込み、トーンの不一致など、具体的な明確性の失敗パターン

そのため clarify skill は、スタイル改善よりも「正しく理解してもらえるか」が重要な場面で、ゆるいコピー修正プロンプトより実用的です。

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

最大のボトルネックは、事前のデザイン文脈に依存することです。このスキルは明示的に /frontend-design を必要とし、まだデザイン文脈がない場合は先に /teach-impeccable を実行するよう案内します。つまり clarify install 自体は簡単でも、良い出力が得られるかどうかは、プロダクト、対象ユーザー、UI 文脈を最初に渡せるかにかかっています。

clarify skill の使い方

clarify のインストールと呼び出し方

リポジトリ抜粋を見る限り、clarify は [target] という引数ヒント付きでユーザーが直接呼び出せるスキルです。実運用では、pbakaus/impeccable リポジトリから導入し、プロダクト全体をざっくり対象にするのではなく、特定の画面、フロー、コンポーネント、コピーの塊に対して clarify を使うのが適切です。

実用的な導入パターンは次のとおりです。

• https://github.com/pbakaus/impeccable からスキルを追加する
• モーダル、決済エラー、オンボーディングのステップ、設定ページなど、具体的な対象を指定して clarify を呼び出す

環境が名前付きスキルのインストールコマンドに対応しているなら、repo URL と clarify の skill path を使ってください。対応していない場合は、リポジトリの skill set を取り込み、clarify を直接呼び出します。

最初に読むべきファイル

まず確認したいのは以下です。

• SKILL.md

提供されているツリー上では、このスキルに対応する README.md、metadata.json、rules、resource フォルダは見当たりません。つまり、実際の使い方に関する重要な情報の大半は SKILL.md に集約されており、大規模スキルのような隠れた実装レイヤーは比較的少ないと考えられます。

clarify skill を使う前に必要な文脈

clarify に何かを書き換えさせる前に、少なくとも以下を揃えておくべきです。

• 現在の正確な文言
• UI のどこに表示されるか
• 想定読者は誰か
• その瞬間のユーザーの心理状態
• ユーザーに次に取ってほしい行動
• プロダクト上またはドメイン上の制約

ここが重要なのは、このスキルが文言を単体で評価するのではなく、文脈込みで明確さを判断するからです。文法的・技術的に正しい書き換えでも、緊急性、信頼感、ユーザーの知識レベルを無視すると実用面では失敗します。

frontend-design 依存が重要な理由

clarify usage は明示的に /frontend-design と連動しています。これは、デザイン原則の確認や文脈収集のプロトコルを先に踏む前提で作られている、という強いシグナルです。この手順を飛ばすと、言い回し自体はきれいになっても、フロー、情報の優先順位、ユーザー目標に対しては不適切な出力になるおそれがあります。

まだデザイン文脈がない場合、このスキルは /teach-impeccable を先に実行するよう指示します。これは任意の仕上げではなく、必要なセットアップとして扱うべきです。

最も良い結果が出る入力

強い入力は、具体的で範囲が明確です。たとえば以下のように渡します。

• current text: “Authentication failed”
• surface: login form error under password field
• audience: non-technical SaaS users
• mental state: frustrated, trying to get back into work quickly
• desired action: retry password, reset if needed
• constraint: do not imply the email is wrong for security reasons

これは次のような依頼より、はるかに良い出力につながります。

• “Improve this error message”

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

弱い例:

• “Make our onboarding copy clearer.”

より良い例:

• “Use clarify on step 2 of onboarding. Current copy: ‘Configure your workspace for enhanced collaboration efficiency.’ Audience: first-time small business users with low technical confidence. Mental state: curious but impatient. Goal: get them to invite teammates. Constraint: keep headline under 8 words and body under 20 words.”

後者のように書くことで、clarify skill は専門用語、文脈不足、行動のわかりやすさ、トーンの適合性をきちんと判断できます。

clarify が重点的に見るポイント

SKILL.md から判断すると、このスキルは次の点を系統立ててチェックします。

• ユーザーに伝わらない可能性がある専門用語
• 曖昧さや複数解釈の余地
• 誰が何をするのかをぼかす受け身表現
• 長すぎる、または短すぎるコピー
• ユーザー知識を前提にしすぎた書き方
• 何が起きたのか、次に何をすべきかという文脈不足
• 状況に合っていないトーン

この観点がわかると、スキルがどんな問題の検出に最適化されているか把握しやすくなります。

clarify 活用の推奨ワークフロー

実務で回しやすい流れは次のとおりです。

1. /frontend-design を実行し、必要な文脈を集める。
2. アプリ全体ではなく、対象となる 1 つの UI 面を選ぶ。
3. 現在の文言をそのまま貼る。
4. 想定読者、心理状態、望ましい次の行動を明示する。
5. いきなり書き換えではなく、先に診断を依頼する。
6. 出力を UI の表示幅やプロダクト制約に照らして確認する。
7. 成功、読み込み中、失敗など隣接する状態でも改訂文言を検証する。

診断なしで即リライトを求めるより、この順序のほうが判断の質は上がりやすいです。

最終リライトの前に診断を依頼する

精度の高い clarify guide の使い方としては、まず以下を聞くのが有効です。

• 何がわかりにくいか
• ユーザーがどこを誤解しそうか
• どんな文脈が不足しているか
• その場面にトーンが合っているか

そのうえで代替案を出してもらいます。こうすると早すぎる書き換えを避けられ、本当の問題が文言なのか、情報設計なのか、あるいはシステム側のフィードバック不足なのかを見極めやすくなります。

UI/UX Design 向け clarify が特に強いユースケース

このスキルが特に強いのは、次のような場面です。

• 何が起きたのか、次に何をすべきかが伝わらないエラーメッセージ
• 社内用語や内部用語に依存したラベル
• 事前知識を前提にしたオンボーディング案内
• 方向性が曖昧で役に立たない空状態
• 技術的には正しいが読み解きにくい設定説明
• 安心感につながらない確認・成功メッセージ

clarify が向かないケース

clarify に以下まで期待しないほうがよいです。

• 構造自体がわかりにくい、より深い UX フローの問題
• 実質的な変更ができない法務・コンプライアンス文言
• すでに明確さは十分で、ブランドトーンだけを磨きたいケース
• 翻訳制約を別途確認していない、多言語展開前提のライティング

問題が文言ではなくインタラクション設計にあるなら、まずフロー自体を直し、その後で clarify を使うべきです。

clarify skill FAQ

clarify skill は初心者にも使いやすい？

はい。現在の文言と基本的な文脈を渡せるなら使いやすいです。ただし初心者は、いちばん重要な「対象ユーザー」や「そのときの状態」の説明を省きがちです。そこが抜けると、clarify は言い回し自体は改善できても、使いやすさまで安定して改善するとは限りません。

clarify を使うには impeccable リポジトリ全体が必要？

主に必要なのは clarify スキル本体と、その前提となる文脈依存です。見えているツリーでは、このスキルについて参照できるのは SKILL.md が中心で、先に読み込むべき追加の repo 資料は多くありません。重要なのは /frontend-design と、必要に応じて /teach-impeccable にアクセスできることです。

clarify は AI にコピーを書き換えさせるのと何が違う？

通常のプロンプトは、見た目に整った文章に寄りやすい傾向があります。clarify skill が強いのは、専門用語、思い込み、曖昧さ、次の行動の欠落、実際のユーザー状況におけるトーンの適否といった「理解上のリスク」を点検させたいときです。

clarify はエラーメッセージに強い？

はい。エラー状態は特に相性の良い領域です。このスキルはユーザーの心理状態と次の行動を明示的に求めるため、単に「親切なエラーメッセージにして」と頼むより、実用的なリライトにつながりやすくなります。

clarify はマイクロコピー専用？

いいえ。短い説明文や UI 上のガイダンスにも使えます。ただし最も向いているのは、範囲が明確な UI テキストです。長文のマーケティングページやコンテンツデザインシステム全体には向いていません。

clarify をインストールしないほうがいいのはどんなとき？

主目的がビジュアルデザインの講評、IA の組み替え、長文ドキュメント向けのコンテンツ戦略であれば、clarify install は見送るのが妥当です。導入すべきなのは、プロダクト UI 内の文言のわかりやすさが本当のボトルネックになっているときです。

clarify skill を改善する方法

量より文脈。clarify には長文より良い条件を渡す

clarify の出力を最短で良くする方法は、周辺テキストを増やすことではなく、制約条件を良くすることです。

• 正確な UI 上の位置
• 文字数制限
• 想定読者の習熟度
• 感情状態
• 期待する行動
• 禁止したい表現や法的制限

周辺コピーを追加する価値があるのは、それによって解釈が変わる場合に限られます。

診断とリライトを分ける

最終コピーを頼む前に、まず clarify に短い問題リストを出してもらってください。そうすることで、問題が曖昧さなのか、文脈不足なのか、トーンの不一致なのかが見えます。失敗パターンを先に言語化してからのほうが、修正案の質は上がります。

現在の状況と望ましい次の行動を両方示す

弱い出力の多くは、モデルが「ユーザーに次に何をしてほしいのか」を把握していないことが原因です。少なくとも次の両方を入れてください。

• 何が起きた直後なのか
• ユーザーは今、何をすべきか

たとえば “payment failed” だけでは不十分です。正しい行動が再試行なのか、カード更新なのか、サポート連絡なのか、待機なのかをスキルが知らなければ、適切な文言にはなりません。

心理状態は明示する

このスキルはユーザーの心理状態をかなり重視しており、そこが実務上の大きな効きどころでもあります。たとえば「ストレスが高く、作業が止まっているユーザー」と「気軽に設定を見ているユーザー」では、出すべきコピーは変わります。ここを省くと、役に立つ文ではなく、無難に感じのよいだけの文に寄りがちです。

トレードオフ付きで複数案を出してもらう

次のように優先順位の異なる 2〜4 案を依頼すると有効です。

• 最短版
• 最も安心感を与える版
• 最も行動を促す版
• 非技術ユーザー向けに最も平易な版

こうすると、1 つの案をそのまま正解として受け入れるのではなく、明確さのトレードオフを比較できます。

よくある失敗パターンを監視する

clarify skill でも十分に機能しないことがある典型例は以下です。

• 文脈不足を直さず、言い回しだけ整えてしまう
• 親しみやすくした結果、具体性が落ちる
• 実際には必要な技術用語まで消してしまう
• UI コンポーネントに収まらない長さの文になる
• 単独の文字列だけ直し、周辺状態と不整合になる

多くはモデルの問題というより、入力の設計不足です。

反復時は実際の UI 制約を入れる

最初のパスのあとで、依頼をさらに絞り込みます。

• “Keep label under 24 characters”
• “Do not mention internal system names”
• “Must be understandable at 8th-grade reading level”
• “Should not blame the user”
• “Preserve security ambiguity around account existence”

この段階で、clarify guide の使い方は単なる編集支援から、本番運用に耐えるレビューへ近づきます。

隣接画面とセットで clarify を使う

ユーザーが連続した体験の中でその文言に触れるなら、1 つのメッセージだけを切り出して改善しないでください。発生条件、そのメッセージ自体、次のステップをまとめて見直すべきです。エラー文言だけ明確でも、CTA ラベルや周辺の補足テキストが曖昧なままだと、結局ユーザーは迷います。

再利用できるプロンプトテンプレートを作る

チームで clarify for UI/UX Design を繰り返し使うなら、次を含むテンプレートを作ると効果的です。

• target surface
• current copy
• audience
• mental state
• desired action
• constraints
• ask: diagnose first, then rewrite

これによりレビューごとのばらつきが減り、clarify を適切に呼び出しやすくなります。

ユーザー証拠を入れて clarify の精度を上げる

サポート問い合わせ、ユーザビリティテストのメモ、実際にテキストを誤読した例があるなら、それも一緒に渡してください。clarify は仮説上の混乱に対して書き換えるより、実際に観測された混乱に基づいて修正するときのほうが、はるかに強く機能します。