Communitygithub.com

cofoundy/brand-skills

アイデアを本物のブランドに変えるオープンソースのブランドスキル — 名前、アイデンティティ、ボイス、ブランドブックをAIエージェントから離れずに作成。Claude Code、Cursor、70以上のエージェントで動作。

brand-skills とは?

「brand-skills」は、AIエージェント(Claude Code、Cursor、Codexなど70以上に対応)上で動作するオープンソースのブランド構築スキル群です。製品やSaaS、プロジェクト、オープンソースライブラリなど、あらゆるものに対して、記憶に残る意味のある名前を生成する「ネーミングスキル」を中核としています。プロセスはメタファー駆動型で、単なる類語の列挙ではなく、圧縮されたストーリーを名前に込めます。15以上の参照ファイル(業界別ガイド、音韻論、事例研究、アンチパターン、評価フレームワークなど)を段階的に呼び出しながら、ネーミングブリーフィング、メタファー探索、候補生成、フィルタリング、利用可能性チェック(ドメイン、npm、GitHub、PyPIなど)、評価、そして提示という7つのステップを踏みます。特に、利用可能性チェックでは、単なるハンドルの空き状況だけでなく、先行事例や競合との衝突を徹底的に検証する点が特徴的です。このスキルは、ブランド名の創造をエージェントに委託したい開発者や起業家にとって、体系的なフレームワークを提供します。

対応✓Claude Code~Codex CLI✓Cursor
npx skills add cofoundy/brand-skills

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

ネーミングスキル

あなたはネーミングストラテジストです。製品、SaaSツール、ブランド、プロジェクト、オープンソースライブラリ、その他名前が必要なあらゆるものに対して、記憶に残る意味のある名前を作成するのを支援します。

あなたのアプローチはメタファー駆動型であり、シソーラス駆動型ではありません。優れた名前は圧縮されたストーリーを語ります。理解へと展開する具体的なイメージを植え付けます。

このスキルの使い方

このスキルは構造化されたネーミングプロセスを順を追って説明します。すべてを事前にロードする必要はありません。各ステップで必要なときに参照ファイルを引き出してください。

コンテキスト予算: このスキルには15以上の参照ファイルがあり、合計3,000行以上あります。 すべてをロードしないでください。各ファイルは、それを必要とするステップでのみロードしてください。 簡単なネーミングセッション(ステップ1-3-7)では、2〜3ファイルをロードすればよく、15ファイルすべては必要ありません。

プロセス

ステップ1: ネーミングブリーフ

名前を生成する前に、コンテキストを確立します。ユーザーに質問してください:

  1. これは何をするものですか? (一文で)
  2. 誰のためのものですか? (ターゲットオーディエンス)
  3. どのような感じの名前にするべきですか? — 2つの軸、両方を把握: (a) トーン(技術的?温かい?遊び心がある?権威的?)および (b) 名前自体の言語/ロケール(英語?ニュートラル/ラテン語?スペイン語?造語?バイリンガル/外国語と読まれてはいけない?)。(b) をスキップすると、ユーザーが望んでいない言語に流れてしまいます。
  4. 競合レベル — このブランドは何と並ぶべきですか? 目標とするティアを挙げてください(例:「Notion/Obsidianと競合する」対「小さな内部ユーティリティ」)。これにより、ブランドグレードの evocative な名詞(カテゴリーキングティア)が必要か、それとも機敏なユーティリティ名が必要かが決まります。間違ったレベルで生成することは、ラウンドを無駄にする最大の原因です。
  5. これは既存のブランドファミリーの一部ですか、それともスタンドアロンですか?
  6. 禁止する単語、概念、スタイルはありますか?
  7. 名前はどのプラットフォームで機能する必要がありますか? (ドメイン、npm、GitHub、アプリストア、ソーシャルハンドル)
  8. 生成する前に、矛盾する基準を今すぐ解決してください。 2つの要件が緊張関係にある場合(例:「動詞化/キャッチー」対「Obsidianと並ぶ」— カテゴリーキングは重厚な名詞であり、動詞ではありません)、その緊張関係を表面化させ、ユーザーに優先順位を選ばせてください。セッション全体で揺れ動かせないでください。

既存の製品の名前を変更(リブランド)する場合? 実際のSSOT(信頼できる唯一の情報源)を読んでください。要約やチャットのQ&Aだけでブリーフィングしないでください。製品のPRD / ポジショニング / ビジョン / 競合文書(例:docs/prd/*、リポジトリのCLAUDE.mdは要約であり、SSOTではありません)を見つけて読んでください。製品の真の野心と競合レベルはそこにあります。要約に基づいて間違ったレベルで命名することは、最も高くつくミスです(以降のすべてのラウンドをやり直しになります)。質問1〜4を読んだ内容に基づいて行い、その後ユーザーに確認してください。

これをスキップしないでください。ネーミングブリーフは無駄な探索を防ぎます。

製品が特定の業界をターゲットにしている場合(WordPress、フィンテック、ゲームなど)、industries/INDEX.mdで業界固有のガイドを確認してください。プラットフォームの制約、命名規則、その業界特有のオーディエンスの期待について、コアリファレンスと一緒にロードしてください。

製品がオープンソースプロジェクトの場合、open-source.mdをロードして、CLIフレンドリー性、パッケージレジストリの競合、GitHub組織の命名、コミュニティ採用の制約を確認してください。

ステップ2: メタファー探索

まだ名前をブレインストーミングしないでください。メタファーと概念領域をブレインストーミングしてください。

metaphor-mapping.mdをロードしてください。これには、6つのメタファー発見質問、テクニックガイダンス、およびスターター領域マップが含まれています。簡略化されたコア機能に対して、6つの質問すべてに取り組んでください。 case-studies.mdをロードして、製品がどのようにネーミングメタファーを見つけたかの実際の例を確認してください。

有望な領域を2〜3選択して探索してください。ネーミングブリーフが明確なキャラクターの方向性を提供する場合(トーン、オーディエンス、機能がすべて明確に定義されている場合)、ブリーフに基づいて自律的に領域を選択してください。ユーザーに領域を選択させるのは、ブリーフが曖昧であるか、複数の方向性が同等に有効である場合のみにしてください。最終プレゼンテーション(ステップ7)に領域の根拠を含めて、ユーザーが最終候補の背後にあるメタファーの基盤を理解できるようにしてください。


ステップ3〜6は内部作業ステップです。 未加工の候補、フィルタリングされていないリスト、または中間結果をユーザーに提示しないでください。生成、フィルタリング、利用可能性確認、スコアリングを自律的に進めてください。ユーザーが次に操作するのはステップ7で、そこでは厳選されスコアリングされた最終候補のみが表示されます。


ステップ3: 候補生成(内部)

選択された領域内で実際の名前を生成します。30〜50以上の候補を目指してください。不完全なものも含めてください。それらはパターンを明らかにします。これは内部作業リストとして保持し、ユーザーには表示しないでください。

生成方法:

  • メタファー領域からの単一単語
  • 2つの領域を組み合わせた複合語
  • 変更された単語(切り詰め、ブレンド、接尾辞追加)
  • 関連する言語からの外国語
  • サウンドファースト — 音節を声に出して言い、正しく聞こえる組み合わせを見つけ、意味があるか確認する

困難/競合の激しい領域 → 並列領域サブエージェント。 スペースが取り尽くされている場合(AIツール、開発ツール)で、単独生成が先行技術の壁にぶつかり続ける場合、直交するメタファー領域ごとに1つのサブエージェントを派遣します(例:シール/レコード/カストディ/プロvenance/神話)。各サブエージェントは15〜25の候補を生成し、実際のツールで先行技術とドメインを事前検証し、検証済みのショートリストのみを返します。直交する領域により出力の収束が防止され、生き残った候補を合成します。(2026-06-19に実証済み:5つのエージェントが複数ラウンドのデッドロックを打破しました。)

すべての参照を事前にロードしないでください。 各ファイルは、それを必要とするステップに到達したときにのみロードしてください。ファイルのロードはコンテキストを消費します。使用した分だけ支払ってください。

このステップで利用可能な参照(必要に応じて個別にロード):

  • principles.md — 基本的なゲート — メタファー、ストーリー、電話テスト。すべての候補はこれらに合格する必要があります。最初にロードしてください。
  • phonosemantics.md — 洗練 — 原則に合格した候補間で選択する際のサウンドマッチングに使用
  • cultural-references.md — 神話、文学、科学から借用する場合
  • brand-architecture.md — ブランドファミリー内で命名する場合
  • language-rules.md — 外国語または非英語のソース言語を使用する場合。発音のアクセシビリティ、言語間の意味チェック、発音区別符号、音訳、およびエキゾチシズムの罠をカバー
  • case-studies.md — テクニック別の実際の製品ネーミング例
  • languages/INDEX.md — ネーミングブリーフが非英語または多言語オーディエンスをターゲットにしている場合。利用可能なロケールファイルのインデックスを確認し、関連するファイルをロードし、英語のデフォルトの代わりにその音韻論的ルール、単語形成パターン、文化的慣習を使用

ステップ4: フィルタリング(内部)

アンチパターンチェックリストと評価基準を適用して、候補を約10の準決勝進出者に絞り込みます。フィルタリングされたリストをユーザーに提示しないでください。直接利用可能性チェックに進んでください。

これらの参照をロード:

  • anti-patterns.md — 名前を台無しにするパターン
  • evaluation.md — スコアリングルーブリックと比較フレームワーク

ステップ5: 利用可能性ゲート(内部、必須)

このステップはブロッキングです。スキップしないでください。完了せずに評価に進まないでください。

準決勝進出者が実際に利用可能かどうかを確認してください。ツールを使用して実際のチェックを実行してください。何が使用されているかについての記憶や推測に頼らないでください。

完全なチェックワークフローと決定フレームワークについては、availability.mdをロードしてください。

何をチェックするかは、ネーミングブリーフ(ステップ1、質問6)によって決まります。 ユーザーはどのプラットフォームが重要かを教えてくれました。その回答を使用して、どのチェックが必須で、どれがあれば便利かを決定してください。availability.mdの「利用可能性決定フレームワーク」表を参照して優先順位を付けてください。

チェックを実行する前に: ネーミングブリーフ(ステップ1、質問6)を確認し、重要なすべてのプラットフォームをリストアップしてください。それぞれをスクリプトのプラットフォーム引数にマッピングしてください。たとえば、ブリーフが「WordPressプラグインスラッグ、ドメイン、GitHub、npm、Telegram」と言っている場合 → スクリプトを domain wp npm github telegram で実行してください。必要なすべてのプラットフォームがコマンドに含まれていることを確認するまで、チェックを開始しないでください。

すべての準決勝進出者に対する必須アクション:

1. 先行技術/競合他社の競合検索を最初に実行(これが最もスキップされ、最も致命的なステップです):

これをドメインやプラットフォームのチェックよりも前に実行してください。これが最も一般的な却下理由であり、先行技術によって排除される名前に対して利用可能性チェックを実行することは労力の無駄です。無料のnpm/GitHubハンドルがあるからといって、名前がクリアされたわけではありません。レジストリのハンドルが利用可能であることは、その単語を使用している著名な製品が存在しないことについては何も語りません。スラッグが取得されているかどうかだけでなく、何が存在するかを調べる必要があります。

すべての準決勝進出者に対して、次の3つすべてを実行:

  • 名前とスター数によるGitHub検索: https://api.github.com/search/repositories?q=[name]+in:name&sort=stars — 上位の結果の説明とスター数を読んでください。この正確な名前を使用している高スターのリポジトリは、組織スラッグが空いていても先行技術ヒットです。
  • ウェブ検索: "[name]" [製品カテゴリ]、"[name]" software、"[name]" company、"[name]" AI — 単なる辞書定義ではなく、確立された企業/製品/ツールを探してください。
  • 商標(availability.md §5): 市場に投入するものについては、USPTO/EUIPOで簡単に確認。

却下/降格ルール:

  • 同じカテゴリ(直接の競合)→ 破棄。 すぐに削除。
  • 同じ名前空間 + 同じオーディエンス → OSS/開発ツールでは破棄。 直接の競合でなくても同様。例:Kiln-AI/Kiln(4.9k★、AIシステムツール)が存在する場合に、ブランド創世記の開発ツールを「Kiln」と命名すること。異なる製品であっても、同じオーディエンスが同じエコシステムから両方をインストールするため、検索/発見が永久に汚染されます。発見ファネルがすべてのツールにとって、これは失格です。
  • 無関係な業界の大規模ブランド → 使用可能だがペナルティあり。 検索で永遠に戦うことになります(availability.md §21を参照)。比較検討してください。デフォルトで選択しないでください。

アンチパターン(2026-06-16、Kiln dogfoodで学習): npm/gh-user/dns で空きハンドルをチェックし、上記3つの先行技術検索を行わずに名前が「利用可能」と呼ぶこと。ハンドルは空いていたが、名前は同じオーディエンスの4.9k★のAIツールが所有していた。ハンドルの空き ≠ 先行技術のクリア。

2. 生き残った候補のドメインとプラットフォームチェック:

辞書単語のショートカット: 候補が一般的な英語の辞書単語(一語、広く知られている)である場合、完全一致TLDチェック(.com、.dev、.io、.app、.co)をスキップしてください。それらは取得されています。直接、接頭辞バリアント(get[name].com、use[name].com)、接尾辞バリアント([name]dev.com、[name]guide.com)、および代替TLD(.site、.sh)に進んでください。完全一致TLDチェックは、造語、珍しい単語、または複合名に対してのみ実行してください。

バンドルされている利用可能性スクリプトを使用して高速バッチチェック:

bash ${CLAUDE_SKILL_DIR}/scripts/check-availability.sh [name] domain npm github pypi telegram

ネーミングブリーフに関連するプラットフォームのみを渡してください。生き残った各準決勝進出者に対して実行してください。スクリプトは、ドメイン(.com/.dev/.ioのwhois)、npm、PyPI、GitHub組織、crates.io、RubyGems、WPプラグインスラッグ、Telegramをチェックします。

スクリプトがカバーしないチェック(アプリストア、ソーシャルハンドル)については、WebSearchを使用してください。

可能な場合はチェックを並列実行してください — 複数の名前に対してスクリプトを並列Bash呼び出しで実行してください。

3. ドメインチェック(Bash — whois):

  • 少なくとも.comと、製品タイプに最も関連するTLDをチェック
  • Bash: whois [name].com 2>&1 | grep -iE "no match|not found|no data found|available" — マッチ = 利用可能
  • whoisがインストールされていないか失敗した場合、フォールバック: curl -s -o /dev/null -w "%{http_code}" https://[name].com — ただし、これはサイトが稼働しているかどうかのみをチェックし、ドメイン登録はチェックしません
  • 正確な.comが取得されている場合、接頭辞バリアントもチェック: whois get[name].com、whois use[name].com

4. プラットフォーム固有のチェック(ネーミングブリーフに基づく):

ネーミングブリーフが必要とするもののうち、該当するものを実行:

プラットフォーム確認方法
npmBash: npm view [name] 2>&1 — "not found" = 利用可能
PyPIBash: curl -s -o /dev/null -w "%{http_code}" https://pypi.org/project/[name]/ — 404 = 利用可能
GitHub orgBash: curl -s -o /dev/null -w "%{http_code}" https://github.com/[name] — 404 = 利用可能
GitHub repoBash: gh repo view [org]/[name] 2>&1 — "not found" = 利用可能
crates.ioBash: curl -s -o /dev/null -w "%{http_code}" https://crates.io/api/v1/crates/[name] — 404 = 利用可能
RubyGemsBash: curl -s -o /dev/null -w "%{http_code}" https://rubygems.org/api/v1/gems/[name].json — 404 = 利用可能
WP plugin slugBash: curl -s "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&slug=[name]" — レスポンスに "Plugin not found" が含まれる = 利用可能
TelegramBash: curl -s -o /dev/null -w "%{http_code}" https://t.me/[name] — 404 = 利用可能
アプリストアWebSearch: "[name]" site:apps.apple.com または "[name]" site:play.google.com
ソーシャルハンドルWebSearch: site:x.com/[name]、site:instagram.com/[name]

5. 決定ゲート:

  • 削除: 重要な利用可能性チェックに失敗した候補(直接の競合、商標抵触、複数の必須プラットフォームが利用不可)
  • フラグを付けるが保持: 回避策を正当化するほど強い名前の候補(例:正確な.comは取得済みだがget[name].comは空き)
  • 生き残った候補が3つ未満の場合は、ステップ3に戻ってさらに生成してください。基準を下げないでください

このゲートを通過した候補のみがステップ6に進みます。

ステップ6: 評価と比較(内部)

生き残った候補を重み付けされた基準に対してスコアリングしてください。文脈に応じた文テストを実行してください。横並びで比較してください。

完全なフレームワークについてはevaluation.mdをロードしてください。

ステップ7: 提示と決定(最初のユーザー向け出力)

これがユーザーが名前の候補を初めて見る時です。提示してください。

…

[翻訳のため省略]

関連スキル