brand-guidelines について
brand-guidelines は、Sentry のブランド指針に沿ったユーザー向けコピーを書くためのスキルです。簡潔で実用的な表現と個性を加えた Sentry Voice を使い分け、UI テキストや文体の規則を示します。
主な機能
- 01内容に応じたトーンの選択
- 02簡潔で明快な表現ルール
- 03適切な場面での Sentry Voice の使用
- 04スペルと大文字表記の規則
- 05UI テキストやメッセージの指針
活用シーン
- 01プロダクト UI のラベルやボタンの作成
- 02エラーメッセージやヘルプテキストの起草
- 03オンボーディングや空状態のコピー作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ getsentry/ skills --skill brand-guidelinesインストール後、Claude Code で/brand-guidelinesを入力して読み込まれたか確認します。
詳細
ブランドガイドライン
ユーザー向けのコピーは、Sentry のブランドガイドラインに従って作成します。
トーンの選択
コンテキストに応じて適切なトーンを選択します。
| プレーンな表現を使う | Sentry の声を使う |
|---|---|
| プロダクト UI(ボタン、ラベル、フォーム) | 404 ページ |
| ドキュメント | 空の状態 |
| エラーメッセージ | オンボーディングのフロー |
| 設定ページ | 読み込み中の状態 |
| トランザクションメール | 「新着情報」のお知らせ |
| ヘルプテキスト | マーケティングコピー |
特に個性が求められるコンテキストでない限り、プレーンな表現を使います。
プレーンな表現(デフォルト)
プレーンな表現は明確で、直接的で、機能的です。ほとんどの UI 要素で使用します。
ルール
- 簡潔にする - 必要最小限の言葉を使います
- 直接的にする - ユーザーができることではなく、すべきことを伝えます
- 能動態を使う - 「変更を保存します」ではなく「変更を保存」
- 専門用語を避ける - ユーザーが理解できる簡単な言葉を使います
- 具体的にする - 「いくつかのエラーが見つかりました」ではなく「3 件のエラーが見つかりました」
例
| 次の表現ではなく | こう書く |
|---|---|
| 「ここをクリックして変更を保存してください」 | 「保存」 |
| 「日付で結果を絞り込めます」 | 「日付で絞り込む」 |
| 「エラーが発生しました」 | 「問題が発生しました」 |
| 「有効なメールアドレスを入力してください」 | 「有効なメールアドレスを入力」 |
| 「本当に削除しますか?」 | 「この項目を削除しますか?」 |
Sentry の声
Sentry の声は、適切な場面で個性を加えます。共感的で、自分をよく理解しており、ときに皮肉を交えます。
原則
- 共感のある皮肉 - 不満は状況に向け、決してユーザーに向けません
- 自分をよく理解する - ソフトウェアの不条理さを認めます
- 楽しく、かつ機能的に - 個性は意味を曖昧にせず、伝わりやすくするために使います
- ふさわしい場面で使う - ユーザーが楽しむ余裕のある場面でのみ使います
例
404 ページ:
「このページは存在しません。最初からなかったのかもしれません。夢だったのかもしれません。いずれにしても、元の画面に戻りましょう。」
空の状態:
「まだエラーはありません。この平穏なひとときを楽しみましょう。いつまで続くかはわかりませんが。」
オンボーディング:
「最初のエラーを発生させましょう。聞こえるほど怖くはありません。」
読み込み中の状態:
「数値を計算中…」 「データを取得中…」
Sentry の声を使わない場面
- エラーメッセージ(ユーザーはいら立っています)
- 設定ページ(ユーザーは作業に集中しています)
- ドキュメント(ユーザーは情報を必要としています)
- 請求・支払いのフロー(ユーザーは信頼を必要としています)
一般的なルール
スペルと文法
- アメリカ英語のスペルを使います(colour ではなく color)
- 見出しとページタイトルにはタイトルケースを使います
- 本文、ボタン、ラベルにはセンテンスケースを使います
句読点
- UI テキストでは感嘆符を使いません(祝う場面を除く)
- 短い UI ラベルやボタンテキストには句点を付けません
- 完全な文やヘルプテキストには句点を付けます
- 頭字語(API、SDK、URL)以外ではすべて大文字の表記を使いません
語句の選択
| 避ける表現 | 推奨する表現 |
|---|---|
| Please | (省略) |
| Sorry | (問題を具体的に説明する) |
| エラーが発生しました | 問題が発生しました |
| 無効です | (何が問題なのか説明する) |
| 成功しました! | (何が起きたか説明する) |
| おっと | (具体的に説明する) |
ダッシュの使い方
| 種類 | 用途 | 例 |
|---|---|---|
| ハイフン(-) | 複合語、範囲 | 「リアルタイム」、「1-10」 |
| エンダッシュ(--) | 範囲、関係性 | 「2023--2024」、「親--子」 |
| エムダッシュ(---) | 中断、強調 | 「エラーは---小さなものでも---重要です」 |
ほとんどの UI コンテキストではハイフンを使います。エンダッシュは日付の範囲に、エムダッシュは長めの文章に使用します。
UI 要素のガイドライン
ボタン
- 動作を表す動詞を使います:「保存」、「削除」、「作成」
- 具体的にします:「作成」だけでなく「プロジェクトを作成」
- 可能であれば最大 2~3 語にします
- 句点や感嘆符は付けません
エラーメッセージ
- 何が起きたかを伝えます
- 理由を伝えます(役立つ場合)
- 次に何をすべきかを伝えます
良い例:「変更を保存できませんでした。接続を確認して、もう一度お試しください。」 悪い例:「エラー:保存に失敗しました。」
空の状態
- 通常ここに何が表示されるかを説明します
- 状態を設定するための分かりやすい操作を提示します
- ここでは Sentry Voice が適しています
良い例:「プロジェクトがまだありません。最初のプロジェクトを作成して、エラーの追跡を始めましょう。」
確認ダイアログ
- タイトルで操作内容を明確にします
- 削除などの操作では、その結果を説明します
- 具体的なボタンラベルを使います(「OK」ではなく「プロジェクトを削除」)
ツールチップとヘルプテキスト
- 2 文以内にします
- 「何を」だけでなく「なぜ」を説明します
- 複雑な内容については、ドキュメントへのリンクを設けます
避けるべきパターン
よくある次のような間違いを避けます。
- ロボットのような言い回し:「項目は正常に削除されました」→「削除しました」
- 受動態:「変更が保存されました」→「変更を保存しました」
- 不要な言葉:「〜するために」→「〜する」
- 曖昧な表現:「これにより〜が発生する可能性があります」→「これにより〜が発生します」
- 二重否定:「〜と似ていないわけではありません」→「〜に似ています」
- UI でのマーケティング表現:「ワークフローを大幅に強化」→「ワークフローを高速化」