competitors-analysis

競合分析

後から共有、再実行、監査できる競合インテリジェンスを構築します。 このスキルは、次の2つのレイヤーで構成されています。

1. リポジトリのエビデンス：競合のコードを永続的な競合ワークスペースにクローンまたは更新し、実際のファイルやコミットから事実を引用します。
2. 市場全体の統合分析：エビデンスによってどの製品選択が変わるのかを、トレードオフや判断を覆す条件を含めて説明します。ポジショニング、価格、強み、ギャップは補足的なエビデンスとして扱います。

このスキルは、簡易的な「競合スキャン」のワークフローを意図的に包含しています。スキャンは市場全体をまとめた表には役立ちますが、技術的な結論を導くには不十分です。

分析対象を特定する（最初に読む）

実行エージェントは、分析するコードのソースと、比較に使用する自社製品のコンテキストという、2つの別々の入力を特定します。リポジトリの URL があれば前者を特定できるため、製品名を別途入力する必要はありません。

1. まず、現在のリクエストで明示されている製品、市場、除外事項に従います。 単独のプロファイルを求められた場合、自社製品との比較は追加しません。
2. それ以外の場合は、現在のプロジェクトの AGENTS.md / CLAUDE.md を読み、製品の契約または調査エントリに従って、製品と分析範囲を確認します。 呼び出し元の現在のプロジェクトは、この実行における有効なコンテキストです。ディレクトリ名だけでは不十分なため、製品を特定するために使用した正式なファイルを記録します。 呼び出し元が処理を委任する場合、可能であればプロジェクトのパスと関連するエントリを渡す必要があります。
3. 自社製品のコンテキストが確認できていない状態でリポジトリの URL が指定された場合、単独のプロファイルを選択します。リポジトリの分析は続けますが、自社製品固有の比較や機会は省略します。 顧客セグメントが不明でも、コードに関する事実や、リポジトリ内のドキュメントを情報源とするポジショニングの分析は妨げられません。
4. 調査または市場分析では、明示的なリクエスト、または確認済みの現在のプロジェクトを使って範囲を定めます。比較のコンテキストが不明なままの場合は、指定されたリポジトリのプロファイルをすべて完成させ、正確にどのコンテキストが不足しているのかを呼び出し元に報告します。 対話型ホストは未解決の比較入力のみを尋ねてもかまいません。非対話型のフォークは、独立したプロファイルを妨げずに不足情報を報告します。

分析対象も、実行可能な現在のプロジェクトの範囲もない場合に限り、処理を停止します。 不足している入力を呼び出し元に報告します。タスクをでっち上げたり、無関係な製品を選ぶために $COMPETITORS_BASE を調べたり、独自に生成した市場から調査を始めたりしてはいけません。 タスクのリクエストも呼び出し元から指定されたプロジェクトの範囲も受け取っていないフォークは停止する必要があります。質問できないからといって、指定されたリポジトリ URL を拒否する理由にはなりません。

エントリールーター

モードを選択する前に、対象範囲を上記の手順で確定してください。リポジトリ URL だけが指定された場合は、比較対象として確認済みの現行プロジェクトがあればそれを使用して、プロファイルを作成します。対象範囲を指定した Discover リクエストでは、既知の競合製品は任意です。

ユーザーの表現と過去を示す修飾語に基づいて、進め方を選択してください。過去の作業の要約を求めるリクエストでは、キーワードベースの探索に先立って、一覧ルートを選択します。

ユーザーの意図	モード	実施内容
「調査済みの競合製品を振り返る」「回顾已分析的竞品」、過去を含む累積リスト	Landscape inventory	過去の一覧に従い、新たなプロファイルや統合を必須とせず、既存の記録を照合します
「競合製品を探す」「竞品有哪些」、新たな発見を目的とする広範な市場調査	Discover	GitHub とウェブの情報源を検索し、候補を絞り込み、関連するリポジトリのみをクローンします
「競合製品を追加 」	Ingest	リポジトリをクローンし、リモートとコミットを記録してから、初回のプロファイルを作成します
リポジトリ URL または提供されたコードパッケージ、「競合製品を分析」「このリポジトリをレビュー」	Profile	ソースを紐付け、コードを読み、出典を示した技術プロファイルを作成します。該当する場合は、確認済みの現行プロダクトと比較します
「比較」「市場概況」「機会」	Landscape	各競合製品にプロファイルがあることを確認してから、ギャップと機会を統合します
「最新のコード」「有没有更新」	Update	既存の競合製品を pull/fetch し、分析の前に変更されたコミットを報告します

ソースプロファイルを保存する前に、ユーザーが選択した保存先を確認してください。チームコレクションが明示的に指定された場合は、コレクションの保存先ルーティングを読み、既存の producer/review エントリーを使用してください。プロジェクト固有の採用判断は、既存のプロジェクト調査エントリーに記載します。コレクションが指定されていない場合は、以下の現在のプロジェクトに基づく学習内容と、永続的なソースレイアウトを維持してください。

永続的なソースレイアウト

/tmp ではなく、永続的なワークスペースを使用してください。デフォルトのベースは次のとおりです。

COMPETITORS_BASE="${COMPETITORS_BASE:-$HOME/workspace/competitors}"

ディレクトリの規則：

$COMPETITORS_BASE/
└── {product-slug}/
    ├── {owner-repo}/
    └── ...

GitHub リポジトリには owner-repo を使用し、フォークや同名のプロジェクトが衝突しないようにしてください。product-slug は、明示的に指定された現行プロダクト、または権威ある情報で確認された現行プロダクトから導出してください。どちらにも当てはまらない場合、提供されたリポジトリ URL には standalone を使用してください。これは保存用の名前空間であり、実在しない市場を作り出すものではありません。 該当するプロダクトディレクトリを再利用し、リモートを確認してからクローンしてください。 分析対象の範囲を作り出すために、他のプロダクトディレクトリを調べないでください。

事前確認

機能を比較する前に、指定されたエディションを提供されたソースにひも付けます。 Git の場合は、リモートと、分析対象として固定したコミットを記録します。アーカイブまたはアプリのバンドルの場合は、入手元（または unknown）、正確なパッケージ／メンバーのパス、コンテンツダイジェスト、確認できたエディション／バージョン（または unknown）を記録します。別々に配布されているエディションは分けて扱い、指定された各エディションについて、見つかったか未解決かを示します。ダイジェストで識別できるのはバイト列であり、指定されたエディション、最新リリース、コレクションの完全性ではありません。ひも付け済みのローカルパッケージを再利用し、Git の保存規約を満たすためだけに代替リポジトリをクローンしたり、アーカイブをコピーしたりしないでください。過去の分析を参照するのは、履歴の確認または再利用が求められている場合に限ります。

以下のコマンドは、Git ソースにのみ適用してください。 初回の取り込み、または明示的な鮮度確認／更新の依頼では、記憶に頼らずコマンドで以下の事実を確認します。

repo="$COMPETITORS_BASE/{product-slug}/{owner-repo}"
test -d "$repo/.git"
git -C "$repo" remote -v
git -C "$repo" fetch --all --prune
git -C "$repo" log -1 --format='%H%x09%cI%x09%s'

統合または継続の場合は、検証済みのプロファイルと固定されたコミットを再利用します。一致するリモートと必要なオブジェクトがローカルにあることを確認してください。コンテキストが圧縮されたというだけで、フェッチしたり、変更のない確認を繰り返したりしないでください。更新するのは、鮮度の確認が求められている場合、入力が変更された場合、証拠が不足している場合、または未解決の懸念がある場合に限ります。分析対象のコミットを記録し、それを上流の最新コミットであるかのように説明しないでください。

リポジトリがない場合は、まずクローンします。可能であれば、GitHub では SSH を優先してください。

mkdir -p "$COMPETITORS_BASE/{product-slug}"
git clone --depth 1 <git-ssh-url> "$COMPETITORS_BASE/{product-slug}/{owner-repo}"

公開リポジトリで SSH が失敗した場合は、その失敗を報告し、作業を続行できる場合に限り、リポジトリの HTTPS URL で再試行します。

発見ワークフロー

GitHub のリポジトリを探すには gh search repos を使用します。複数の検索語句で検索し、単一のキーワードだけを信頼しないでください。

gh search repos "product keywords" \
  --limit 30 \
  --archived=false \
  --json fullName,url,description,stargazersCount,forksCount,openIssuesCount,language,pushedAt,updatedAt,defaultBranch

候補ごとに、以下を記録します。

項目	情報源
リポジトリ名と URL	gh search repos / gh repo view
説明	クローン後の GitHub API または README の行番号付き引用
アクティビティ	pushedAt、最新コミット、存在する場合はリリースノート
スター数／フォーク数／Issue 数	取得日を添えた GitHub API
関連性の理由	ユーザーの製品スコープ＋リポジトリの証拠

ユーザーの製品または分析目標に関連する候補だけをクローンしてください。幅広い市場を対象とする場合は、まず証拠を添えた候補一覧を提示し、その後、有力な候補群を分析します。

リポジトリの事実確認

仕組みのレベルで主張したり、自社製品とのギャップを判断したりする前に、references/mechanism_evidence.md を読んでください。ひも付け済みのソースを読む際は、同ドキュメントのエントリーパス、ライフサイクル、証拠の深さに関する確認事項に従い、競合製品のコードを実行する前に実行境界を適用してください。単独のプロファイルは、自社製品のベースラインがなくても続行できます。

以下の順序でファイルを読み、正確な情報源を記録します。

1. プロジェクトのメタデータ：package.json、pyproject.toml、Cargo.toml、go.mod、または同等のファイル。
2. README とドキュメント：製品の位置付け、スクリーンショット、インストール方法、料金へのリンク。
3. エントリーポイント：main、bin、scripts、src/、app/、packages/。
4. コア実装：レンダラー、パーサー、ストレージ、エクスポート、同期、認証、API、またはドメイン固有のモジュール。
5. テストとフィクスチャ：対応するデータ構造やエッジケースが明らかになることがよくあります。
6. リリース／変更履歴：現在の方向性と最近の変更。

引用する前に nl -ba <file> または行番号を表示するエディターを使用してください。実装に関する技術的な主張にはすべて、file:line の証拠が必要です。

Landscape ワークフロー

既存のプロファイルを統合する前に、 references/landscape_synthesis.md を読んでください。証拠 → 因果関係の説明 → 製品選択 → 反例／反証条件の連鎖と、プロジェクト文書の継続に関する取り決めに従ってください。機能マトリックスや、取り入れる機能のリストだけでは、Landscape の要件を満たしません。変更が不要であるという裏付けのある結論も有効です。新たな方向性をでっち上げないでください。プロジェクトに基づく比較を終える前に、重要な機会の処理に関する取り決めに従ってください。既存の JSON 判断プロジェクションを確認する場合は、 references/opportunity_disposition.md を読み込み、scripts/reconcile_opportunities.py を使用してください。構造上の結果だけでは、意味上の網羅性は保証されません。単独のソースプロファイルには、採用表は不要です。

レポートの構成

競合が1社の場合は、references/profile_template.md を使用してください。使用した場合は、現行プロジェクトの正式なスコープ情報源を記録してください。自社製品のコンテキストがない場合は、比較セクションを省略し、機会に関する判断はリポジトリ固有のものにしてください。

Landscape の概要には、次の構成を使用してください。Update の場合は、変更表を記入する際に 変更分類の手順 を適用してください。

# {Product} Competitor Landscape

## Decisions Changed By The Evidence
For each material judgment: cited observations, causal explanation (inference),
concrete choice and its cost, alternative explanation/counterexample, and the
observation that would overturn it. State scope and unresolved assumptions.

## Current Understanding And Next Check
Link the existing project research entry; retain accepted/rejected judgments,
their evidence versions and failure conditions, and the next decision-bearing check.

## Source Register
| Competitor / edition | Carrier | Local source / member | Git remote + commit or package origin + digest | Retrieved / freshness |
|---|---|---|---|---|

## Changes Since The Prior Analysis (for Update)
| Competitor / edition | Change type | Earlier and current evidence | Consequence for the judgment |
|---|---|---|---|

## Positioning
| Competitor | User segment | Primary promise | Source |
|---|---|---|---|

## Product And Technical Comparison
| Dimension | Competitor A | Source | Competitor B | Source | Our product | Source |
|---|---|---|---|---|---|---|

## Strengths
| Competitor | Strength | Evidence | Why it matters |
|---|---|---|---|

## Weaknesses And Gaps
| Competitor | Gap | Evidence | Opportunity |
|---|---|---|---|

## Opportunities
| Opportunity | Evidence base | Product implication | Confidence |
|---|---|---|---|

## Risks And Assumptions
| Item | What is known | What still needs verification | Next check |
|---|---|---|---|

証拠に関するルール

必須

主張の種類	必要な証拠
依存関係／フレームワーク／バージョン	設定ファイルの行番号付き引用
機能のサポート	README／ドキュメントの行番号付き引用。技術的な内容の場合はコードの引用も必要
パーサー／エクスポート／ストレージの挙動	コードの行番号付き引用
価格／クラウドホストに関する主張	取得日を記載した公式ページの引用
人気度／活動状況	取得日を記載した GitHub API／ページの引用
機会に関する判断	引用した観察事項、明示的な確信度、ラベル付けされた推論とスコープ、選択／トレードオフ、反例または別の説明、反証するための確認

禁止事項

裏付けのない技術的な主張を、リポジトリの事実として提示しないでください。明示的にラベル付けされ、Landscape の連鎖で裏付けられていれば、戦略的な推論は可能です。「可能性がある／likely」などの言葉だけでは、主張の妥当性は決まりません。言葉を一律に禁止するのではなく、文が何を主張しているかと、その証拠を確認してください。

パターン	理由
推測した実装を、観察済みのコードの挙動として提示する	判断によって、欠落しているコード上の事実を補うことはできません
「未公开」、「未披露」	公開状況を把握しているかのように装います
「UI から推測したアーキテクチャ」	技術アーキテクチャはコードに基づく必要があります
出典のない数値	後から検証できません

実装や市場に関する事実が確認できない場合は、待验证 と記載し、それを検証するための具体的な次の確認事項を明記してください。未解決の仮定を、要件、競争上の優位性に関する主張、または実装の承認へと格上げしないでください。

出力品質の基準

完了前に、references/analysis_checklist.md のチェックを実行してください。

• Git クローンが $COMPETITORS_BASE/{product-slug}/ に存在していること。提供されたパッケージは、指定された場所に保持されていること。
• ソース台帳に、運搬元と要求されたエディションが記載されていること。Git リモート／コミット、またはパッケージ／メンバー／ダイジェストが記録され、鮮度と未解決のエディションが明示されていること。
• 技術的な主張にはすべて、ファイル名と行番号を含む引用があること。
• 市場に関する事実には、情報源と取得日があること。
• Landscape の判断では、具体的な選択、そのトレードオフ、反証条件を説明していること。事実と推論が区別されていること。
• プロジェクトに基づく分析では、ステージの終了またはコンテキストの引き継ぎ前に、新たに得た知見を既存のプロジェクト調査記録に保存すること。継続時には、変更のない証拠を再利用すること。
• チームコレクションが明示的に選択されている場合は、コレクションの保存先ルーティング に従うこと。作成者／レビュー担当者の結果を確認するか、未解決の引き継ぎ事項を正確に報告すること。プロジェクトの判断と安定したソースリンクを保持すること。
• 最終回答では、ギャップ、機会、リスクを示し、コード上の事実であるかのように装わないこと。

スクリプト

継続的な競合リポジトリの管理を始める際は、scripts/update-competitors.sh を使用します。

COMPETITORS_BASE="$HOME/workspace/competitors" \
PRODUCT_NAME="{product-slug}" \
./scripts/update-competitors.sh status

./scripts/update-competitors.sh discover "claude code viewer"
./scripts/update-competitors.sh clone-url https://github.com/org/repo
./scripts/update-competitors.sh pull

このスクリプトはテンプレートです。長期運用するプロダクトの場合は、これをそのプロダクト専用のリポジトリまたは運用ディレクトリにコピーし、競合の永続的なリストを入力してください。

プロダクト分析との関係

product-analysis は比較モードでこのスキルを呼び出すことがあります。このスキルは、競合の発見、リポジトリの根拠、競合分析に焦点を絞ってください。一般的なプロダクト監査のオーケストレーターに変えないでください。