competitors-analysis

竞品分析

构建可共享、可重新运行并供日后审计的竞品情报。此技能分为两个层次：

1. 仓库证据：在持久化的竞品工作区中克隆或更新竞品代码，然后引用实际文件和提交中的事实。
2. 市场格局综合分析：说明证据会如何影响产品选择，包括权衡因素，以及哪些情况会推翻判断。将定位、定价、优势和差距作为辅助证据。

此技能有意涵盖轻量级的“竞品扫描”工作流。扫描适用于市场格局表，但不足以支持技术结论。

确定分析目标（请先阅读）

执行 Agent 需确定两个独立输入：要分析的代码来源和用于对比的我方产品背景。仓库 URL 可确定前者；无需另行提供产品名称来描述该仓库。

1. 优先遵循当前请求中明确指定的产品／市场和排除项。 如果调用方要求单独分析某个产品，不要添加我方产品的对比。
2. 否则，阅读当前项目的 AGENTS.md／CLAUDE.md，并遵循其中的产品契约或研究入口，以确认产品和分析范围。 调用方当前所在的项目可作为本次执行的有效背景。仅凭目录名称不足以确定项目；请记录用于识别项目的权威文件。委派任务的调用方应在可用时传递项目路径和相关入口。
3. 如果提供了仓库 URL，但未确认我方产品背景，则选择单独的产品档案模式。继续分析仓库；省略与我方产品相关的对比和机会。如果缺少客户细分信息，不影响依据代码得出事实，也不影响引用仓库自有文档中的定位。
4. 对于发现或市场格局分析，使用明确请求或已确认的当前项目来确定范围。如果对比背景仍未知，请完成已提供的仓库档案，并向调用方说明确切缺少的背景信息。交互式宿主可以只询问尚未解决的对比输入；非交互式分支则应报告缺失信息，同时不中断独立档案分析。

**仅当既无分析目标，也无可执行的当前项目范围时才停止。**向调用方说明缺少的输入。不要臆造任务，不要浏览 $COMPETITORS_BASE 来选择无关产品，也不要从自行生成的市场开始发现流程。既没有任务请求、也没有调用方指定的项目范围的分支必须停止；无法提问并非拒绝已提供仓库 URL 的理由。

入口路由

选择模式前，先确定上文中的范围。仅提供仓库 URL 时，选择 Profile；如有已确认的当前项目，则用其进行对比。 针对范围明确的 Discover 请求，已知竞品为可选项。

根据用户措辞和历史限定条件选择路径。回顾先前工作的请求应优先走清单路线，而不是基于关键词进行发现：

用户意图	模式	操作
“回顾已研究的竞品”、“回顾已分析的竞品”、历史累计清单	Landscape inventory	遵循历史清单；整理现有记录，无需新增档案或综合分析
“寻找竞品”、“竞品有哪些”、针对新发现的广泛市场查询	Discover	搜索 GitHub 和网络来源，筛选候选项，只克隆相关仓库
“添加竞品 ”	Ingest	克隆仓库，记录远程地址和提交，然后生成首份档案
仓库 URL 或提供的代码包、“分析竞品”、“审查这个仓库”	Profile	绑定来源，阅读代码，撰写有引用依据的技术档案；适用时与已确认的当前产品进行对比
“对比”、“市场格局”、“机会”	Landscape	确保每个竞品都有档案，然后综合分析差距和机会
“最新代码”、“有没有更新”	Update	拉取/获取现有竞品，并在分析前报告变更的提交

保存来源档案前，先确定用户选择的目标位置。如果请求明确指定了团队集合，请阅读集合目标路由，并使用其中现有的撰写/审阅条目。将项目专属的采用判断保留在现有项目研究条目中。若未指定，则沿用当前由项目支撑的学习资料和下方的持久来源目录结构。

持久来源目录结构

使用持久工作区，而不是 /tmp。默认基础目录为：

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

目录约定：

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

GitHub 仓库使用 owner-repo，避免 fork 和名称相似的项目发生冲突。根据明确指定或权威确认的当前产品生成 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'

进行综合分析或继续工作时，重用已验证的资料档案及其固定提交。 在本地确认匹配的远程仓库和所需对象；不要仅因上下文被压缩就执行 fetch 或重复 未变更的检查。仅在请求检查最新状态、输入发生变化、证据缺失或存在未解决疑虑时更新。 记录经过分析的提交，不要将其描述为上游当前版本。

如果仓库不存在，先克隆。条件允许时，GitHub 优先使用 SSH：

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

如果 SSH 连接公开仓库失败，请报告失败情况；只有在这样做有助于继续工作时， 才使用仓库的 HTTPS URL 重试。

发现工作流

使用 gh search repos 搜索 GitHub 仓库。使用多个查询短语；不要只依赖一个关键词。

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、最新提交、发布说明（如有）
Stars／forks／issues 数量	带检索日期的 GitHub API 数据
相关原因	用户的产品范围 + 仓库证据

仅克隆与用户产品或分析目标相关的候选项。 对于广泛的市场，先提供有证据支持的候选清单，再分析 最具代表性的一组。

仓库事实收集

在提出机制层面的主张或判断我方产品的差距之前，先阅读 references/mechanism_evidence.md。阅读已绑定的源时，遵循其中的 入口路径、生命周期和证据深度检查要求；运行竞品代码前，应用其中的执行边界。独立的 Profile 可在没有我方产品基准的情况下继续进行。

按以下顺序阅读文件，并记录确切来源：

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；其结构性结果并不能证明语义覆盖完整。独立的来源画像无需采用情况表。

报告结构

针对单个竞争对手，请使用 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 可能会在比较模式下调用此技能。请将此技能专注于竞品发现、仓库证据和竞争分析综合。不要将其变成通用的产品审计编排器。