brand-guidelines について
Sentry のブランドボイスに沿ったユーザー向け文章を作成するスキルです。場面に応じた平易な表現と個性的なトーンの選び方を、UI やドキュメントなどの指針とともに示します。
主な機能
- 01Plain Speech と Sentry Voice の指針
- 02コンテンツ別のトーン選択
- 03UI テキストとエラーメッセージのルール
- 04スペルと句読点の規則
- 05文章パターンの例
活用シーン
- 01製品 UI のラベルの書き換え
- 02オンボーディングや空状態の作成
- 03ドキュメントやヘルプテキストの編集
- 04ブランド告知の作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/brand-guidelinesを入力して読み込まれたか確認します。
詳細
ブランドガイドライン
Sentry のブランドガイドラインに従って、ユーザー向けの文章を作成してください。
使用する場面
- Sentry のトーンでユーザー向けの文章を作成または書き直す必要がある場合。
- タスクに UI テキスト、オンボーディング、空の状態、ドキュメント、マーケティングコピー、その他のブランドコンテンツが含まれる場合。
- Plain Speech と Sentry Voice を使い分ける方法を知りたい場合。
トーンの選択
状況に応じて適切なトーンを選んでください。
| Plain Speech を使う場面 | Sentry Voice を使う場面 |
|---|---|
| プロダクト UI（ボタン、ラベル、フォーム） | 404 ページ |
| ドキュメント | 空の状態 |
| エラーメッセージ | オンボーディングフロー |
| 設定ページ | 読み込み中の状態 |
| 取引関連のメール | 「新機能」告知 |
| ヘルプテキスト | マーケティングコピー |
特別な個性が求められる場合を除き、Plain Speech を基本にしてください。
Plain Speech（デフォルト）
Plain Speech は、明快で直接的かつ機能的な表現です。ほとんどの UI 要素で使用してください。
ルール
- 簡潔にする - 必要最小限の語数にします
- 直接的にする - ユーザーができることではなく、すべきことを伝えます
- 能動態を使う - 「変更を保存します」ではなく「変更を保存」
- 専門用語を避ける - ユーザーが理解できる簡単な言葉を使います
- 具体的にする - 「エラーがいくつか見つかりました」ではなく「3 件のエラーが見つかりました」
例
| 次の表現ではなく | 次のように書く |
|---|---|
| 「ここをクリックして変更を保存してください」 | 「保存」 |
| 「日付で結果を絞り込むことができます」 | 「日付で絞り込む」 |
| 「エラーが発生しました」 | 「問題が発生しました」 |
| 「有効なメールアドレスを入力してください」 | 「有効なメールアドレスを入力」 |
| 「本当に削除しますか？」 | 「この項目を削除しますか？」 |
Sentry Voice
Sentry Voice は、適切な場面で個性を加えます。共感があり、自分を客観視し、ときには皮肉を交えます。
原則
- 共感のある皮肉 - 苛立ちを向けるのは状況であり、ユーザーではありません
- 自分を客観視する - ソフトウェアの不条理さを認めます
- 楽しく、かつ機能的に - 個性は意味を分かりにくくするのではなく、伝わりやすくします
- ふさわしい場面で使う - ユーザーが楽しむ余裕のある場面に限って使います
例
404 ページ：
「このページは存在しません。最初からなかったのかもしれません。夢だったのかもしれません。いずれにしても、元の場所に戻りましょう。」
空の状態：
「エラーはまだありません。この平穏なひとときを楽しみましょう。いつまで続くかは分かりませんが。」
オンボーディング：
「最初のエラーを発生させましょう。ご安心ください。聞こえるほど怖くはありません。」
読み込み中の状態：
「数値を計算しています……」 「データを取得しています……」
Sentry Voice を使わない場面
- エラーメッセージ（ユーザーが苛立っているため）
- 設定ページ（ユーザーが作業に集中しているため）
- ドキュメント（ユーザーが情報を必要としているため）
- 請求／支払いのフロー（ユーザーに信頼してもらう必要があるため）
全般的なルール
スペルと文法
- アメリカ英語のスペルを使います（colour ではなく color）
- 見出しとページタイトルにはタイトルケースを使います
- 本文、ボタン、ラベルにはセンテンスケースを使います
句読点
- UI テキストに感嘆符を使わない（祝賀の場面を除く）
- 短い UI ラベルやボタンテキストに句点を使わない
- 完全な文やヘルプテキストには句点を使う
- 略語（API、SDK、URL）を除き、すべて大文字の表記は使わない
単語の選び方
| 避ける | 推奨 |
|---|---|
| Please | （省略） |
| Sorry | （問題を具体的に説明する） |
| Error occurred | Something went wrong |
| Invalid | （何が問題なのかを説明する） |
| Success! | （何が起きたかを説明する） |
| Oops | （具体的に説明する） |
ダッシュの使い方
| 種類 | 用途 | 例 |
|---|---|---|
| ハイフン (-) | 複合語、範囲 | 「real-time」、「1-10」 |
| エンダッシュ (–) | 範囲、関係性 | 「2023–2024」、「parent–child」 |
| エムダッシュ (—) | 文章の中断、強調 | 「エラーは——たとえ小さなものでも——重要です」 |
ほとんどの UI ではハイフンを使います。日付範囲にはエンダッシュを、長めの文章にはエムダッシュを使います。
UI 要素のガイドライン
ボタン
- 動作を表す動詞を使います：「保存」、「削除」、「作成」
- 具体的にします：「作成」だけではなく「プロジェクトを作成」
- 可能であれば 2～3 語以内にします
- 句点や感嘆符は使いません
エラーメッセージ
- 何が起きたかを伝えます
- 理由を伝えます（役立つ場合）
- 次に何をすべきかを伝えます
良い例：「変更を保存できませんでした。接続を確認して、もう一度お試しください。」 悪い例：「エラー：保存に失敗しました。」
空の状態
- 通常ここに何が表示されるかを説明します
- 状態を解消するための明確な操作を提示します
- ここでは Sentry Voice が適切です
良い例：「プロジェクトはまだありません。最初のプロジェクトを作成して、エラーの追跡を始めましょう。」
確認ダイアログ
- タイトルで操作を明確にします
- 破壊的な操作の場合は、その結果を説明します
- 具体的なボタンラベルを使います（「OK」ではなく「プロジェクトを削除」）
ツールチップとヘルプテキスト
- 2 文以内にします
- 「何を」だけでなく「なぜ」も説明します
- 複雑なトピックにはドキュメントへのリンクを付けます
アンチパターン
よくある次のような間違いを避けてください。
- ロボットのような表現：「項目は正常に削除されました」→「削除しました」
- 受動態：「変更は保存されました」→「変更を保存しました」
- 不要な語句：「するために」→「する」
- **根拠のない曖昧な表現：**確実だと裏付けられる場合に限り、埋め草の表現を削除します。結果が不確かな場合は「可能性があります」を残し、可能性を保証に変えてはいけません。
- 二重否定：「似ていないわけではない……」→「似ています……」
- UI でのマーケティング表現：「ワークフローを強化」→「ワークフローを高速化」
参考資料
制限事項
- このスキルは、タスクが上記の範囲に明確に合致する場合にのみ使用してください。
- 環境固有の検証、テスト、専門家によるレビューの代わりとして、出力を扱わないでください。
- 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。