mcpField
B
brand-guidelines

brand-guidelines

github.com/getsentryマーケティング・グロース1.1k2.5k 回インストール5 日前に更新
リポジトリ

brand-guidelines について

brand-guidelines は、Sentry のブランド指針に沿ったユーザー向けコピーを書くためのスキルです。簡潔で実用的な表現と個性を加えた Sentry Voice を使い分け、UI テキストや文体の規則を示します。

主な機能

  1. 01内容に応じたトーンの選択
  2. 02簡潔で明快な表現ルール
  3. 03適切な場面での Sentry Voice の使用
  4. 04スペルと大文字表記の規則
  5. 05UI テキストやメッセージの指針

活用シーン

  1. 01プロダクト UI のラベルやボタンの作成
  2. 02エラーメッセージやヘルプテキストの起草
  3. 03オンボーディングや空状態のコピー作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/getsentry/skills --skill brand-guidelines

インストール後、Claude Code で/brand-guidelinesを入力して読み込まれたか確認します。

詳細

ブランドガイドライン

ユーザー向けのコピーは、Sentry のブランドガイドラインに従って作成します。

トーンの選択

コンテキストに応じて適切なトーンを選択します。

プレーンな表現を使うSentry の声を使う
プロダクト UI(ボタン、ラベル、フォーム)404 ページ
ドキュメント空の状態
エラーメッセージオンボーディングのフロー
設定ページ読み込み中の状態
トランザクションメール「新着情報」のお知らせ
ヘルプテキストマーケティングコピー

特に個性が求められるコンテキストでない限り、プレーンな表現を使います。

プレーンな表現(デフォルト)

プレーンな表現は明確で、直接的で、機能的です。ほとんどの UI 要素で使用します。

ルール
  1. 簡潔にする - 必要最小限の言葉を使います
  2. 直接的にする - ユーザーができることではなく、すべきことを伝えます
  3. 能動態を使う - 「変更を保存します」ではなく「変更を保存」
  4. 専門用語を避ける - ユーザーが理解できる簡単な言葉を使います
  5. 具体的にする - 「いくつかのエラーが見つかりました」ではなく「3 件のエラーが見つかりました」
例
次の表現ではなくこう書く
「ここをクリックして変更を保存してください」「保存」
「日付で結果を絞り込めます」「日付で絞り込む」
「エラーが発生しました」「問題が発生しました」
「有効なメールアドレスを入力してください」「有効なメールアドレスを入力」
「本当に削除しますか?」「この項目を削除しますか?」

Sentry の声

Sentry の声は、適切な場面で個性を加えます。共感的で、自分をよく理解しており、ときに皮肉を交えます。

原則
  1. 共感のある皮肉 - 不満は状況に向け、決してユーザーに向けません
  2. 自分をよく理解する - ソフトウェアの不条理さを認めます
  3. 楽しく、かつ機能的に - 個性は意味を曖昧にせず、伝わりやすくするために使います
  4. ふさわしい場面で使う - ユーザーが楽しむ余裕のある場面でのみ使います
例

404 ページ:

「このページは存在しません。最初からなかったのかもしれません。夢だったのかもしれません。いずれにしても、元の画面に戻りましょう。」

空の状態:

「まだエラーはありません。この平穏なひとときを楽しみましょう。いつまで続くかはわかりませんが。」

オンボーディング:

「最初のエラーを発生させましょう。聞こえるほど怖くはありません。」

読み込み中の状態:

「数値を計算中…」 「データを取得中…」

Sentry の声を使わない場面
  • エラーメッセージ(ユーザーはいら立っています)
  • 設定ページ(ユーザーは作業に集中しています)
  • ドキュメント(ユーザーは情報を必要としています)
  • 請求・支払いのフロー(ユーザーは信頼を必要としています)

一般的なルール

スペルと文法
  • アメリカ英語のスペルを使います(colour ではなく color)
  • 見出しとページタイトルにはタイトルケースを使います
  • 本文、ボタン、ラベルにはセンテンスケースを使います
句読点
  • UI テキストでは感嘆符を使いません(祝う場面を除く)
  • 短い UI ラベルやボタンテキストには句点を付けません
  • 完全な文やヘルプテキストには句点を付けます
  • 頭字語(API、SDK、URL)以外ではすべて大文字の表記を使いません
語句の選択
避ける表現推奨する表現
Please(省略)
Sorry(問題を具体的に説明する)
エラーが発生しました問題が発生しました
無効です(何が問題なのか説明する)
成功しました!(何が起きたか説明する)
おっと(具体的に説明する)

ダッシュの使い方

種類用途例
ハイフン(-)複合語、範囲「リアルタイム」、「1-10」
エンダッシュ(--)範囲、関係性「2023--2024」、「親--子」
エムダッシュ(---)中断、強調「エラーは---小さなものでも---重要です」

ほとんどの UI コンテキストではハイフンを使います。エンダッシュは日付の範囲に、エムダッシュは長めの文章に使用します。

UI 要素のガイドライン

ボタン
  • 動作を表す動詞を使います:「保存」、「削除」、「作成」
  • 具体的にします:「作成」だけでなく「プロジェクトを作成」
  • 可能であれば最大 2~3 語にします
  • 句点や感嘆符は付けません
エラーメッセージ
  1. 何が起きたかを伝えます
  2. 理由を伝えます(役立つ場合)
  3. 次に何をすべきかを伝えます

良い例:「変更を保存できませんでした。接続を確認して、もう一度お試しください。」 悪い例:「エラー:保存に失敗しました。」

空の状態
  1. 通常ここに何が表示されるかを説明します
  2. 状態を設定するための分かりやすい操作を提示します
  3. ここでは Sentry Voice が適しています

良い例:「プロジェクトがまだありません。最初のプロジェクトを作成して、エラーの追跡を始めましょう。」

確認ダイアログ
  • タイトルで操作内容を明確にします
  • 削除などの操作では、その結果を説明します
  • 具体的なボタンラベルを使います(「OK」ではなく「プロジェクトを削除」)
ツールチップとヘルプテキスト
  • 2 文以内にします
  • 「何を」だけでなく「なぜ」を説明します
  • 複雑な内容については、ドキュメントへのリンクを設けます

避けるべきパターン

よくある次のような間違いを避けます。

  • ロボットのような言い回し:「項目は正常に削除されました」→「削除しました」
  • 受動態:「変更が保存されました」→「変更を保存しました」
  • 不要な言葉:「〜するために」→「〜する」
  • 曖昧な表現:「これにより〜が発生する可能性があります」→「これにより〜が発生します」
  • 二重否定:「〜と似ていないわけではありません」→「〜に似ています」
  • UI でのマーケティング表現:「ワークフローを大幅に強化」→「ワークフローを高速化」

参考資料

コメント