説明
できること
- 新商品やサービスをブランド名で展開すべきか、別ブランドで立ち上げるべきかを「拡張の法則」で判定でき、ブランド価値の毀損を防げます。
- ブランド拡張や多角化のリスクを「22の不変の法則」という体系的フレームワークで評価し、経営判断の根拠を明確にできます。
- ネーミングやポジショニング戦略を決める際に、成功事例と失敗事例を参照して、同じ過ちを避けられます。
- PRと広告の役割分担や市場リーダーとしての立ち振る舞いを「22法則」に照らして最適化でき、ブランドの一貫性を保てます。
- 業界別・企業規模別にブランド戦略の優先度をスコアリングし、経営会議で迷わず意思決定できます。
こんな人におすすめ
- ブランド拡張や新規事業参入の是非を判断したいCMO・経営企画責任者
- プロダクト名やサービス名の戦略的ポジショニングを決めたいプロダクトマネージャー
- 企業のビジュアルアイデンティティやメッセージング戦略を一貫性を持たせたいマーケティング責任者
- 経営会議で戦略的判断の根拠を数値・フレームワークで示したい経営者
## Triggers 以下の状況で使用： - ライン拡張/多角化の是非を判断したいとき - ブランドが所有すべきキーワードやカテゴリー軸を再定義したいとき - PRと広告の役割分担や市場リーダーとしての振る舞いを決めたいとき 1. 拡張の法則（ブランド拡大の落とし穴） 内容（要約）: ブランドの力を弱める一番簡単な方法は、何にでもそのブランド名を付けて範囲を拡げすぎることです[1]。本来、ブランドは特定の商品カテゴリーやコンセプトに焦点を当ててこそ強みを発揮します。しかし成功したブランドほど「この名前を他の商品にも付ければ売れるのでは？」という誘惑に駆られがちです。その結果、ブランドの意味する範囲がぼやけてしまい、顧客の心にあった明確なイメージが希薄化します[2]。つまり、ブランドはゴムのように引き伸ばせば伸ばすほど張力（影響力）が弱まるのです[3]。 該当実例: - 海外・失敗例：Yahoo!（ヤフー） – 1990年代、ヤフーは検索エンジンとして人気を博しましたが、その後ポータルサイト、メール、ニュース、ゲーム、買い物など「あらゆるサービスの何でも屋」へと拡張しました[4][5]。結果、「Yahoo!」というブランドから連想されるものが定まらなくなり、検索分野では焦点を絞ったGoogleにトップの座を奪われてしまいました[5]。- 海外・失敗例：Colgate（コルゲート） – 歯磨き粉ブランドであるコルゲートが、かつて冷凍食品市場にまで手を広げ「コルゲートキッチン」という冷凍食品を発売しました。しかし消費者にとって「コルゲート＝歯磨き」のイメージが強すぎて食品には違和感が大きく、この試みは失敗に終わりました[6]。ブランド拡張が既存イメージと乖離しすぎた典型例です。- 国内・事例：ユニクロ – ユニクロはカジュアル衣料に特化し、高級ブランド路線や他業種には安易に手を出しませんでした。その結果、「手頃で高品質なベーシック服＝ユニクロ」という明確なブランドポジションを築いています[7]。もしユニクロがブランド名を使って家電や食品などまで手広く展開していたら、ここまでのブランド力は維持できなかったでしょう。
Skill.md 情報
- バージョン
- v1.0.0
- カテゴリ
- code-quality
- 作成日
インストール
ワンコマンドで導入下の「Skill.mdをダウンロード」ボタンを押す
お使いのAIツール（Claude Code・Cursor・Copilot など）にファイルをアップロードして「このスキルを追加して」と入力する
$ mkdir -p ~/.claude/skills/ && curl -sL "https://github.com/Unson-LLC/brainbase" -o ~/.claude/skills/SKILL.mdタグ
関連 Skill.md
コード変更を別視点から客観的に検証
by K9i-0
大きなコード変更を、別の独立したAIコンテキストから客観的にレビューして問題がないか確認できます 変更規模に応じて自動判定（小規模なら自己レビュー、大規模ならサブエージェント活用）して効率的にレビューします 重大な問題・軽微な問題・問題なしを判定して、修正が必要か完了可能かを明確にします 問題が見つかった場合は自動で修正→再レビューループを回し、LGTM判定になるまで繰り返します コミット前に変更内容を客観的に確認したい開発者 コードレビュー品質を高めたいチームリード 重大な不具合をコミット前に防ぎたいプロジェクト このスキルは、タスク完了前に実行するセルフレビュー手順です。トリガーは /self-review コマンドまたは大きな変更をコミットする前です。4つのフェーズで構成されています。Phase 1 で変更差分を収集（git diff で変更ファイルと内容を取得）、Phase 2 でサブエージェント（code-reviewer）によるレビューを実行（ただし変更規模が30行以下の場合はサブエージェント不要）、Phase 3 で判定（LGTM=PASS、軽微な問題=MINOR、重大な問題=FAIL）、Phase 4 で FAIL の場合は修正→Phase 1-3 再実行を繰り返します。変更規模別に調整可能で、30行以下は自己レビューのみ、31-100行は code-reviewer サブエージェント、100行以上は詳細分析を加えます。
TypeScriptコード品質を自動検証・テスト
by K9i-0
Bridge Server（TypeScript）のユニットテスト実行、TypeScript型チェック、カバレッジ測定を順番に実行し、全てのテストがパスすることを自動確認できます。 テストファイルのみを指定したり、ウォッチモード（開発中は自動再実行）で効率的にテストを回すことができます。テストファイルと型チェック対象の関係を正確に管理します。 vitest規約に基づいたテスト記述方法（ファイル配置・命名・import・テスト構造）の標準を適用し、チーム全体で一貫性のあるテストコードを保証します。 parser.ts、claude-process.ts、image-store.tsなど、現在テスト対象のモジュールを管理し、新しく純粋関数が追加される際のテスト追加ガイダンスを提供します。 外部依存（プロセスspawn・ファイルシステム・WebSocket）を除いた、ROIの高い純粋ロジックのテストに集中できます。 Bridge Server開発でコード品質を保ちながら継続的にテストを実行したい開発チーム TypeScriptの型チェックとテスト自動化で本番バグを事前に防ぎたい品質管理者 テスト記述規約を統一して、チーム内の開発効率と保守性を向上させたい技術リード 新機能追加時に既存機能の回帰テストを確保したいCI/CD環境構築者 Bridge Server（TypeScript）のテスト実行・型チェック・テスト記述ガイド。実行手順①ユニットテスト（npm run test:bridge、特定ファイル指定可、ウォッチモード対応）②TypeScript型チェック（npx tsc --noEmit、テストファイルと vitest.config.ts は tsconfig.json の exclude に含まれ型チェック対象外）③カバレッジ測定（任意）。テスト記述規約：ファイルはソースと同ディレクトリに .test.ts 配置、vitest のみ import（jest互換は不可）、テスト対象モジュールは .js 拡張子で import（NodeNext moduleResolution）、describe でグルーピング・it は英語三人称現在形・1つの it は1振る舞い検証。テスト対象は純粋関数・ロジック中心（高ROI）。現在テスト対象モジュール：parseClaudeEvent、claudeEventToServerMessage、parseClientMessage（parser.ts）、parseRule、matchesSessionRule、buildSessionRule、toolNeedsApproval（claude-process.ts）、ImageStore.extractImagePaths（image-store.ts）。新テスト追加時は純粋関数があれば追加検討、internal関数テストは export に変更OK。
AWSアーキテクチャをベストプラクティスで徹底検証
by YoshiiRyo1
設計書・ヒアリングシート・アーキテクチャ説明を多角的にレビュー：AWS Well-Architected フレームワークの6つの視点（信頼性、セキュリティ、コスト最適化、運用上の優秀性、パフォーマンス効率、持続可能性）から包括的に分析し、改善案をレポート化します。 AWSベストプラクティスとの整合性を自動検証：最新のAWSドキュメントやサービス仕様と照合し、推測ではなく公式情報に基づいた指摘を提供します。 平易な説明とエンジニア向け詳細の両立：技術レベルに依存しない図解と、実装根拠となる詳細なドキュメントリンクを同時に提示します。 リージョン可用性やサービス最新機能を自動確認：新機能やリージョン対応状況を都度確認し、古い情報に基づく指摘を排除します。 非機能要件IPA分類とW-Aの柱の対応を自動マッピング：設計の品質要件を構造化し、どの柱でカバーされているか明確にします。 クラウドアーキテクト・ソリューションアーキテクト：新規プロジェクトの設計レビュー、既存システム改善の根拠提示に 開発チームリード・PMO：AWSベストプラクティス準拠をスケーラブルに検証したい セキュリティ・コンプライアンス担当：セキュリティ要件、コスト削減余地、リスク評価を構造化したい クラウド移行プロジェクト推進者：移行後の設計が大規模採用に耐えられるか定量的に判定したい AWS Well-Architected フレームワークの6本の柱に基づいてレビューを実施。対象は本リポジトリの設計テンプレート（design/doc_source/）、ヒアリングシート（survey/doc_source/）、ワークショップ資料（workshop/doc_source/）。ワークフローは①入力理解（ファイルパスまたはトピック名から対象を特定）、②ドキュメント読み込み（Glob・Read・Grep ツール活用）、③AWS最新ベストプラクティス確認（aws-knowledge MCPで Well-Architected・サービス固有・最新アップデート・リージョン可用性を検索）、④6本の柱による分析（非機能要件カテゴリ定義を参照して対応関係を確認）。出力は日本語で統一、AWS サービス名は英語表記のまま。AWS ドキュメントリンクは英語版URLを使用。