mcpField
B
brand-voice

brand-voice

github.com/sshelegマーケティング・グロース6257 回インストール3 日前に更新
リポジトリ

brand-voice について

super-ux に含まれる、プロダクトの言語表現を定義・維持するスキルで、`docs/brand/` を管理します。UXの基盤情報をもとにトーンや用語などを整え、検証手順で網羅性と一貫性を確認します。

主な機能

  1. 01ブランド文書とボイスガイドの初期化
  2. 02用語、事実、チャネルルールの調整
  3. 03ポジショニング変更に伴うテキスト更新
  4. 04網羅性、一貫性、古さの確認
  5. 05ブランド文書の契約とステータスの遵守

活用シーン

  1. 01新規プロダクトの表現規範を策定
  2. 02ポジショニング変更後のブランド情報更新
  3. 03ローンチ前に各チャネルのコピーを確認

インストール

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

$npx skills add https://github.com/ssheleg/super-ux --skill brand-voice

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
ai-tells.md
brand-contract.md
channel-playbooks.md
hooks.md
localization.md
marketing-copy.md
research-outliers.md
seo-aeo-safety.md
store-copy.md
surface-registers.md
system-map.md
video-script.md
voice-packs.md
templates/brand/
channels.md
copy-brief.md
facts.md
locale.md
README.md
strings.md
terminology.md
voice.md

詳細

brand-voice — ブランドの言語的アイデンティティを定義し、維持する

super-ux の一部です。パイプライン全体については、system-map.md を参照してください。 変更後は python3 docs/brand/lint.py を実行してください。

docs/ux/ はプロダクトが何をするかを決めます。このスキルはプロダクトがどう語るかを決め、対象プロジェクトの docs/brand/ を管理します。

形式の契約: brand-contract.md (brand-contract v1)。docs/brand/ 以下のファイルを作成または編集する前に読んでください。ファイル名、フィールド名、ステータスから逸脱しないでください。リンターと監査はこれらを基準に動作します。

パックライブラリ: voice-packs.md — それぞれに明示された失敗モードを持つ6つのアーキタイプ。レジスターモデル: surface-registers.md。ロケール: localization.md。

トリガー

このスキルに誘導する英語とロシア語のフレーズです。スキル一覧が予算内に収まるよう、説明には最も強いものだけを残しています(2026-10-20)。ファミリールーティングフックはこのリストに一致します。

"tone of voice" / "тон оф войс", "brand voice" / "голос бренда", "brandbook" / "брендбук", "our terminology" / "наша терминология", "how should this sound" / "как это должно звучать", "the copy is inconsistent" / "текстовка разная везде", マーケティング用のあらゆるサーフェスの開始、またはプロダクトの docs/brand/ への登録。

タスクなしで呼び出された場合 → 状態を報告し、次のアクションを1つ提案する

  1. 状態を報告します。パックが記録されているか、voice.md に記載された Status、⚠ TBD または出典なしの事実の数、ロケール間の整合性、リンターのエラー数と警告数を示します。
  2. 未解決の事実をすべて挙げます。空白を埋めるために事実を捏造してはいけません。不明な点は報告し、補完しません。
  3. 次のアクションを1つだけ提案します。通常は、最も優先度の高い未解決の事実、またはユーザーが実際に必要としているサーフェスを対象にします。

ボイスの由来

パックは docs/ux/foundation.md — ペルソナ、ジョブ、そして判断を左右する入力、つまりプロダクトが失敗したときにユーザーが失うものから導き出されます。賭け金がプレイリストなら魅力的なボイスも、給与計算がかかっている状況では受け入れられません。

依存関係は一方向です。トーンが魅力的だからといって、ペルソナが変わることはありません。基盤がない場合は、機能を制限したモードで作業します。Derived-from: inferred と記し、WHY レイヤーを構築すべきことを明示してから、作業を止めずに続行します。

このルートには口頭でのオプトアウトもあります。 オペレーターが "no brand" / «без бренда» と言った場合は、ブランド設定を拒否しています。パックなしで進め、そのことを伝えてください。黙って省略してはいけません。

ワークフローの選択

状況ワークフロー
docs/brand/ がない初期化
パックは選択済みだが、プロダクト固有の情報が不足している調整
ポジショニング、ペルソナ、または事実が変更された更新
一貫性に疑問がある、またはローンチ前検証

実行するワークフローを宣言してください。

初期設定

  1. 基盤を読みます。 ペルソナ、JTBD、ジャーニー、利害です。情報がない場合は、誰のためのものか、どのような責任を負っているか、失敗するとどのような損失が生じるかを聞き取ります。
  2. 既存のものを読みます。 インターフェースの文言、ランディングページのコピー、README、ストア掲載情報、最近の投稿です。現在の文体は、誰も意図して選んでいなくてもデータです。
  3. 理由を添えてパックを1つ提案し、代替案も1つ示します。 次点の案が劣る理由を説明します。どちらにするかはユーザーに選んでもらいます。
  4. このスキル自身の templates/brand/ を使って docs/brand/ を用意し、まず Sources: ブロックを埋めます。リンターがプロジェクト内のテキストの場所を把握するまで、ほかの項目はチェックできません。
  5. strings.md 用に全体を洗い出します。ルート、画面、ボタン、状態、エラー、空の状態を確認します。すべての文字列について、file:line と対象となるシナリオを記載した行を作成します。大規模なコードベースでは、利用可能な読み取り専用サブエージェントを並列で使い、各エリアを1つずつ担当させます。委任できない場合は、同じエリアを順番に調べ、同じ証拠要件を満たします。
  6. このプロジェクトがどのヒューマナイズ処理を希望するかを尋ね、回答を voice.md の Humanization pass: フィールドに記入します。既定値は own で、このパックのレジスターと事実を読み取る唯一の処理です。npx sshlg-skills humanizers で、ほかにインストールされているものと、未インストールのもののインストール方法を確認できます。質問は一度だけにします。このフィールドがあるのは、誰も二度聞かれないようにするためであり、処理を選択するものであって、判定を下すものではありません。
  7. すべて Status: draft から始めます。

調整

パックは出発点です。ここで製品独自のものにしていきます。

  • 用語。 この製品では一般的な語をどのような語に置き換えますか。弱い動詞、曖昧な表現の連鎖、ai-tells.md をもとに禁止語の表を作り、ここに固有の語も追加します。
  • 事実。 製品が引用する数値すべてについて、出典、確認日、見直し日を記載します。社内の数値には Public: no と記します。
  • チャネル。 製品が実際に持つ画面ごとに1つの記録を作成します。差分として登録します。Forbidden: には、仕様上の制約とブランド上の制約の両方を必ず記載します。
  • 定型文。 この製品向けに6〜10個作成し、パックからコピーしないでください。
  • 失敗モード。 パックの失敗モードを voice.md にコピーし、監査でその名前を使って確認できるようにします。
  • エムダッシュの不変条件。 voice.md の不変条件に、「新しいテキストでは、どの言語でもエムダッシュ(U+2014)を使わない」と追加します(オーナーの決定、2026-10-18)。これはパックが緩和できる文体上の選択ではありません。すべてのパックがこれを引き継ぎます。自然な言い換えができない場合のロシア語の文法上のダッシュだけが例外として認められます(ai-tells.md AT-06、B062、B067)。

セクションごとに提示して承認を得ます。承認されると draft から validated に移行します。

更新

  1. 変更内容(ポジショニング、ペルソナ、価格、ティア名、新しい画面など)を特定します。
  2. 編集を適用します。エンティティ名を変更した場合は、同じ変更内で terminology.md、strings.md、すべてのロケールに反映します。
  3. 変更したファイルは、再承認されるまで Status: draft に戻します。
  4. Last calibrated の日付を更新します。

検証

  1. 整合性 — 契約で必須とされるすべてのフィールドが存在すること、ステータスが有効であること、Derived-from が基盤の内容と一致することを確認します。
  2. 網羅性 — 製品が提供するすべての画面に記録があること、宣言されたすべてのロケールにファイルがあること、引用された数値すべてに事実の記録があることを確認します。
  3. 一貫性 — python3 docs/brand/lint.py を実行し、検出結果を反映します。機械的に確認できる部分はこれで検証できます。確認できない点は /ux-audit copy への質問として報告します。
  4. 古さ — 最終調整日より新しい基盤、見直し期限を過ぎた事実、確認日を過ぎた仕様上の制約を確認します。

完了の定義

  • 契約が守られ、すべてのファイルにマーカーが付いていること。
  • ユーザーが新規または変更されたセクションを確認し、承認していること。
  • python3 docs/brand/lint.py が終了コード 0 で終了するか、残るすべての指摘について理由が報告されていること。
  • 不明な点は不明として明示されていること。表を埋めるために何も作り上げないこと。

references/ にあるその他のもの。 このスキルは契約を 6 件直接指定していますが、references/ には 13 件あります。これは、このスキルが指定する契約がほかの契約へのリンクを含み、その依存関係一式がスキル内に収められているためです。skills CLI は 1 つのディレクトリをインストールするので、隣接するディレクトリにあるファイルは参照切れになります。ここで指定されているものを開いてください。残りは、それらの中から契約名を指定して参照されています。

コメント