Competitors Analysis

Competitors Analysis

Evidence-based competitor tracking and analysis. All analysis must be based on actual code, never assumptions.

When to Use

Use this skill when the user wants to:

• analyze a competitor repository with evidence
• create or update a competitor profile
• compare a competing product's technical stack or architecture
• track competitor changes over time using cloned code

Usage

Recommended flow:

clone repo locally
-> inspect source files and metadata
-> cite every factual claim
-> write profile from evidence only
-> run post-analysis verification

CRITICAL: Evidence-Based Analysis Only

在开始分析之前，必须完成以下检查：

Pre-Analysis Checklist

• 仓库已克隆到本地 ~/Workspace/competitors/{product}/
• 可以 ls 查看目录结构
• 可以 cat package.json (或等效配置文件) 读取版本信息
• 可以 git log -1 确认代码是最新的

如果以上任何一项未完成，停止分析，先完成克隆操作。

Forbidden Patterns (禁止的表述)

Required Patterns (必须的表述)

Analysis Workflow

Step 1: Clone Repository (必须)

# 创建产品竞品目录
mkdir -p ~/Workspace/competitors/{product-name}

# 克隆竞品仓库 (SSH，失败则重试)
cd ~/Workspace/competitors/{product-name}
git clone git@github.com:org/repo.git

网络问题处理: 中国网络环境可能需要多次重试。

Step 2: Gather Facts (收集事实)

按顺序读取以下文件，记录关键信息：

2.1 项目元数据

# Node.js 项目
cat package.json | head -20      # name, version, description
cat package.json | grep -A50 dependencies

# Python 项目
cat pyproject.toml               # 或 setup.py, requirements.txt

# Rust 项目
cat Cargo.toml

2.2 项目结构

ls -la                           # 根目录结构
ls src/                          # 源码目录
find . -name "*.md" -maxdepth 2  # 文档文件

2.3 核心模块

# 找到入口文件
cat main.js | head -50           # 或 index.js, app.py, main.rs
# 找到核心 helpers/utils
ls src/helpers/ 2>/dev/null || ls src/utils/ 2>/dev/null

2.4 README 和文档

cat README.md | head -100        # 官方描述
cat CHANGELOG.md | head -50      # 版本历史

Step 3: Deep Dive (深入分析)

针对关键技术点，读取具体实现文件：

# 示例：分析 ASR 实现
cat src/helpers/whisper.js       # 读取完整文件
grep -n "class.*Manager" src/helpers/*.js  # 找到核心类

记录格式:

| 文件 | 行号 | 发现 |
|------|------|------|
| whisper.js | 33-35 | 使用 WhisperServerManager |

Step 4: Write Profile (撰写分析)

使用 references/profile_template.md 模板，确保每个技术细节都有来源标注。

Step 5: Post-Analysis Verification (分析后验证)

自检清单:

• 所有版本号都有来源标注？
• 所有技术栈都来自 package.json/Cargo.toml？
• 架构描述基于实际代码结构？
• 没有"推测"、"可能"等词汇？
• 对比表中的竞品数据都有来源？

Directory Structure

~/Workspace/competitors/
├── flowzero/              # Flowzero 的竞品
│   ├── openwhispr/        # git clone 的仓库
│   └── ...
└── {product-name}/        # 其他产品

{project}/docs/competitors/
├── README.md              # 索引（标注分析状态）
├── profiles/
│   └── {competitor}.md    # 基于代码的分析
├── landscape/
├── insights/
└── updates/2026/

Templates and Checklists

关键要求:

1. 顶部必须标注数据来源路径和 commit hash
2. 每个技术细节必须有 (来源: 文件:行号)
3. 引用 README 内容必须标注行号
4. 无法验证的标记为"待验证"并说明原因
5. 分析完成后运行检查清单中的验证命令

Tech Stack Analysis Guide

Node.js / JavaScript

Python

Rust

Common Mistakes to Avoid

1. 跳过克隆直接分析

❌ 错误: 从 GitHub 网页或 WebFetch 获取信息后直接写分析 ✅ 正确: 必须 git clone 到本地，用 Read 工具读取文件

2. 混合事实和推测

❌ 错误:

## 技术栈
- Electron (推测基于桌面应用特征)
- 可能使用了 React

✅ 正确:

## 技术栈 (来源: package.json)
| 依赖 | 版本 | 来源 |
|------|------|------|
| electron | 36.9.5 | package.json:68 |
| react | 19.1.0 | package.json:96 |

3. 使用过时信息

❌ 错误: 分析时不检查 git log，使用过时的代码 ✅ 正确: 分析前运行 git pull，记录分析时的 commit hash

4. 对比表中竞品数据无来源

❌ 错误:

| 维度 | 竞品 | 我们 |
|------|------|------|
| 支持语言 | 25种 | 58种 |

✅ 正确:

| 维度 | 竞品 | 来源 | 我们 |
|------|------|------|------|
| 支持语言 | 25种 | modelRegistryData.json:9-35 | 58种 (FunASR 官方文档) |

Scripts

See scripts/update-competitors.sh for repository management.

./scripts/update-competitors.sh clone   # 克隆所有竞品
./scripts/update-competitors.sh pull    # 更新所有竞品
./scripts/update-competitors.sh status  # 检查状态