brand-name-checker について
brand-name-checkerは、製品名やブランド名をソーシャルメディア、パッケージレジストリ、ドメイン、商標で確認するスキルです。専門別のチェックを連携し、明示された基準でリスクと推奨事項を判定します。完全一致するソーシャルハンドルが見つかると、残りの確認を省略します。
主な機能
- 016つのソーシャルメディアを確認
- 02npm、PyPI、Homebrew、aptを確認
- 03ドメインと商標を検索
- 04基準に沿ったリスクと推奨事項の判定
- 05ハンドル完全一致時の早期終了
活用シーン
- 01製品名の採用前の確認
- 02対象レジストリとドメインの衝突確認
- 03商標とソーシャルハンドルのリスク評価
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ luongnv89/ skills --skill brand-name-checkerインストール後、Claude Code で/brand-name-checkerを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
agents/domain-checker.mdregistry-checker.mdsocial-checker.mdsynthesizer.mdtrademark-checker.mddocs/README.mdevals/evals.jsonreferences/edge-cases.mdoutput-contract.mdprd-integration.mdrepo-sync.mdsource-checks.mdstep-reports.mdtests/test_risk_policy.py詳細
ブランド名チェッカー
商標、ドメイン、ソーシャルメディア、パッケージレジストリ(npm、PyPI、Homebrew、apt)における競合を調べます。
使用するタイミング
製品名やブランド名を採用する前に使用します。コンテキストの消費を抑えるため、クエリ、エッジケース、テンプレートは references/*.md にあります。
サブエージェントのアーキテクチャ
agents/ のワーカーはそれぞれ JSON を返します:social-checker(6 つのプラットフォーム)、registry-checker(npm、PyPI、Homebrew、apt)、domain-checker(TLD)、trademark-checker(WIPO、EUIPO、INPI)。synthesizer がステップ 5 のリスクポリシーを適用します。
- フロー:ソーシャル →(完全一致のハンドルが使用されていない場合)→ {レジストリ、ドメイン、商標} を並列実行 → Synthesizer。
- 早期終了ルール:social-checker が 6 つのプラットフォームのいずれかで完全一致のハンドルが使用されていることを見つけた場合、ステップ 2~4 をスキップし、「Abandon」の判定を添えて synthesizer に直行します。
- サブエージェントを使わない場合:
references/source-checks.mdに従い、ステップ 1~4 を同じ順序でインライン実行します。
環境チェック
- ステップ 1 の前に、WebSearch と WebFetch のツールが使用可能であることを確認します。
- テストクエリを 1 件実行します。
- いずれかのチェックに失敗した場合は中止し、エラーとともに 出力形式 の
BLOCKEDレポートを返します。
編集前のリポジトリ同期(必須)
このスキルは、デフォルトではファイルを書き込みません。リポジトリ内でファイルを作成、更新、または削除する前に、references/repo-sync.md の stash-first 同期を実行します。
入力
$ARGUMENTS から名前を読み取ります。空の場合はユーザーに確認します。prd.md が存在する場合は、業界、対象レジストリ、対象ドメインを確認するために読み取ります。
分析プロトコル
ステップ 1~4 のクエリ、チェック URL、ステータスルールについては、references/source-checks.md を参照してください。各結果を情報源とともに記録します。
ステップ 1:ソーシャルメディアの確認(最優先)
X/Twitter、Instagram、GitHub、LinkedIn、TikTok、Discord を検索します。完全一致のハンドルが使用されている場合(早期終了ルール)、NEGATIVE: Exact social handle taken (@platform) を返し、ステップ 6 に進みます。
ステップ 2:パッケージレジストリの確認(ステップ 1 で問題がない場合)
npm、PyPI、Homebrew、apt を「Available」、「Taken(所有者、最終公開日)」、「Similar」、「Unknown」のいずれかとして確認します。対象レジストリの利用意図が不明または検証できない場合は、すべてのレジストリに問題がないと見なすのではなく、不明として記録します。
ステップ 3:ドメインの確認(ステップ 1 で問題がない場合)
まず .com を確認し、続いて .io、.app、.co、.eu、.fr を確認します。
- Available:信頼できる利用可否の情報により、ドメインが未登録だと確認できる
- Parked:ドメインは存在するが、売り出し中またはパーキングされている
- Active:使用中(同じ業界の場合は注意を示す)
- Unknown:情報源が利用できない、またはアクティブなサイトが見つからなかったことしか示されていない場合。利用可能だと推測しない
ステップ 4:商標の確認(ステップ 1 で問題がない場合)
Nice分類の第 9 類、第 35 類、第 42 類で WIPO、EUIPO、INPI を検索し、各商標を有効または失効として記録します。
ステップ 5:リスク評価
このセクションが、定性的なリスクポリシーの唯一の判断基準です。synthesizer は独自の評価表を作るのではなく、このセクションを読み、従う必要があります。各情報源の結果を「確認済み」、「問題なし」、「不明/検証不可」に分類します。上流のワーカーによるラベルと重大度フィールドは証拠としてのみ扱います。根拠となる事実を再確認し、数値の重大度を盲目的に信頼しないでください。
定性的なリスクマトリックス
リスクの優先順位は High > Moderate > Low です。該当するトリガーのうち、最も高いものを選択してください。調査結果を平均してはいけません。「複数のハンドル」とは、異なるプラットフォームで確認された、完全一致ではないハンドルの衝突が2件以上あることを意味します。
| リスクレベル | 最も高い該当トリガー |
|---|---|
| High | 6つのプラットフォームのいずれかでソーシャルハンドルが完全一致する(早期終了ルール)。確認された、完全一致ではないソーシャルハンドルの衝突が2件以上ある。いずれかの対象レジストリで衝突が確認された。同じ業界で有効な .com がある。Nice Classes 9、35、42 で有効な商標との競合がある。著名ブランドとの競合またはタイポスクワッティングの競合がある。または、非常に短い名前に既存の高い商標衝突リスクがある。 |
| Moderate | High のトリガーには該当しないが、確認された、完全一致ではないソーシャルハンドルの衝突が1件ある。別の業界で有効な .com がある。類似する商標がある。対象外のレジストリで衝突が確認された。または、確認できない項目や不明な対象意図がある。 |
| Low | 必須の確認事項と対象意図のすべてが明示的に検証され、High または Moderate のトリガーに該当せず、不明な結果もない。.com が利用可能またはパーキング中であることが確認されている。 |
不明な項目の扱い:確認事項または対象意図が不足している、あるいは検証できず、既知の High の調査結果がない場合は、検証が完了するまで暫定的な Moderate + Modifyとします。不明な項目は確認済みの衝突ではなく、Low の承認として扱うこともできません。既存の High の調査結果は引き続き High です。平均化や緩和策によって High を引き下げることはできません。早期終了ルールによって省略された確認事項は、クリアではなく省略として扱います。
完全一致ハンドルに関する早期終了ルールに変更はありません。6つのプラットフォームのいずれかでハンドルの完全一致による衝突があった場合、直ちに Abandon を推奨し、残りの確認事項を省略します。これらの確認事項は、クリアではなく省略として報告してください。
推奨の意味
- Proceed:完全に検証された Low の結果に限ります。根拠と制限事項を示し、不明な確認事項をクリアとして扱ってはいけません。
- Modify:暫定的な Moderate を含む Moderate の場合に使用します。確認された競合に対処するバリエーションを提案し、検証待ちの項目を明記してください。
- Abandon:High の場合に使用します。緩和策や利用可能な代替案によって High の結果を引き下げることはできません。
- 該当する情報源を通じて確認されていない代替案には、未検証と明記してください。利用可能であることや Low の評価を捏造してはいけません。
Step 6: 推奨
上記の推奨の意味と、Final Action に記載された登録順序に従ってください。
出力形式
この簡潔なテキストレポートのみを返してください。1画面に収まるため、HTML やインタラクティブなビューは不要です。角括弧で囲まれたフィールドには、確認できた根拠のみを記入してください。確認できない項目には Unknown を使用し、早期終了ルールによって省略した項目には Skipped (not cleared) を使用してください。RISK 行には、リスクレベルだけでなく、最も高い該当トリガーとその方針上の根拠を記載してください。呼び出し元が読み取るため、RISK と RECOMMEND を最後の2行にしてください。
RESULT: [COMPLETE | PARTIAL | BLOCKED] - [N/M checks verified; unknown and skipped counts]
SOCIAL: [Clear | NEGATIVE: reason | Unknown: reason]
REGISTRY: npm ([status]) | PyPI ([status]) | Homebrew ([status]) | apt ([status])
DOMAIN: .com ([status]) | .io ([status]) | .app ([status])
TM: WIPO ([status]) | EUIPO ([status]) | INPI ([status])
EVIDENCE: [source queried for each status: URL or search query, and check time]
SKIPPED: [sources, if any; skipped is not cleared]
UNKNOWN: [checks not verified, why, and what would verify them | none]
RISK: [Low | Moderate | High] - [highest matching trigger, evidence, and policy rationale]
RECOMMEND: [Proceed | Modify | Abandon] - [reason and checked or unverified alternatives]; next: [the user's decision and remaining actions]
RESULT のステータス:すべての確認事項が検証済み、または早期終了ルールによって省略されている場合は COMPLETE、いずれかの確認事項が Unknown の場合は PARTIAL、名前が指定されていないかウェブツールを利用できない場合は BLOCKED(理由と修正方法を含む RESULT 行のみを返してください)。レポートを作成する前に、フィールドのルールと next: 条項について references/output-contract.md を読んでください。prd.md が存在する場合は、references/prd-integration.md のブロックを追加してください。
ステップ完了レポート
各主要ステップの後に、ステータスレポートを出力してください。共通テンプレートとステップごとの例(Social、Registry、Domain、Trademark、Risk、Recommendation)は references/step-reports.md にあります。ステップで検証する内容に合わせて確認項目名を調整し、合格には √、不合格には × を使用してください。
受け入れ基準
- 6 つすべてのプラットフォームでソーシャルメディアの確認を完了し、利用可能/取得済み/不明のステータスを明示する
- npm、PyPI、Homebrew、apt のパッケージレジストリのステータスを確認する(早期終了ルールが発動した場合を除く)
- .com と少なくとも 2 つの代替 TLD のドメイン利用可否を確認する(早期終了ルールが発動した場合を除く)
- WIPO、EUIPO、INPI を対象に商標検索を完了する(早期終了ルールが発動した場合を除く)
- リスクレベル(低/中/高)を割り当て、該当するトリガーのうち最も高いものを根拠として示す
- 最終的な推奨(進める/変更する/断念する)を提示し、必要に応じて候補を明記する
- 理解度:1 行目に
RESULTのステータスを記載する。確認済みのステータスはEVIDENCEに出典を示し、未確認のステータスはUNKNOWNに記載する。RISKにはトリガーを明記し、RECOMMENDはnext:で終える。人によるレビューへの回答がない場合、理解度は未確認のままとする(references/output-contract.md)
期待される出力
nimbus の早期終了実行例。COMPLETE および PARTIAL の実行例:references/output-contract.md。
RESULT: COMPLETE - 6/16 checks verified; 0 unknown, 10 skipped by the Early-Exit Rule
SOCIAL: NEGATIVE: Exact social handle taken (@github)
REGISTRY: Skipped (not cleared)
DOMAIN: Skipped (not cleared)
TM: Skipped (not cleared)
EVIDENCE: github.com/nimbus resolves to an active organization; checked 2026-01-15T10:31Z
SKIPPED: registries, domains, trademarks; skipped is not cleared
UNKNOWN: none
RISK: High - exact social handle collision on GitHub (Early-Exit Rule)
RECOMMEND: Abandon - nimbus-dev, nimbusly (both unverified); next: pick a candidate and run this check on it
エッジケース
レート制限、情報源の停止、特殊文字、非常に短い名前、タイポスクワッティングについては、references/edge-cases.md を参照してください。レート制限されたレジストリには 5 秒後に 1 回だけ再試行し、その後は不明としてマークします。黙ってスキップしたり、利用可能だと推測したりしないでください。
最終アクション
- 進める:完全に検証済みの低リスク結果の場合のみとします。根拠と制限事項を示したうえで、次の登録順を提案します:
- まずパッケージレジストリ — プレースホルダーパッケージであっても、npm/PyPI/Homebrew で名前をただちに確保します。これらは早い者勝ちであり、名前空間スクワッティングの被害を最も受けやすいためです。
- ドメイン — 主要ドメインを登録します。
- ソーシャルメディアのハンドル — 主要なプラットフォームでハンドルを確保します。
- 変更する:確認済みの競合に対処する代替案を推奨し、未確認の項目を列挙します。確認していない候補は未確認であり、利用可能だと断定してはいけません。
- 断念する:提案された候補の中から最適な代替案を推奨します。確認していない候補には未確認のマークを付け、選択肢が問題ないと主張してはいけません。