Competitors Analysis
- 417 installs
- 1.3k repo stars
- Updated August 4, 2026
- daymade/claude-code-skills
competitors-analysis is an AI coding skill that maps rival products, positioning, pricing tiers, feature gaps, and go-to-market motions for developers who need evidence-based differentiation inputs before committing to e
About
competitors-analysis is a competitor research and positioning skill that helps developers and product engineers turn messy market signals into an actionable competitive map. competitors-analysis structures rival analysis around positioning, pricing tiers, feature gaps, and go-to-market motions, so teams can make clearer decisions about what to build and how to package it. Developers typically reach for competitors-analysis when requirements feel ambiguous, pricing or packaging is unsettled, or a roadmap needs sharper differentiation to reduce wasted engineering effort. competitors-analysis is also useful when preparing a narrative for product strategy docs, planning experiments, or aligning stakeholders around a defensible scope based on competitor coverage and GTM patterns.
- Competitor discovery and segmentation
- Feature matrix and parity gap analysis
- Pricing and packaging comparisons
- Positioning and messaging teardown
- Actionable differentiation recommendations
Competitors Analysis by the numbers
- 417 all-time installs (skills.sh)
- Ranked #800 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/daymade/claude-code-skills --skill competitors-analysisAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 417 |
|---|---|
| repo stars | ★ 1.3k |
| Last updated | August 4, 2026 |
| Repository | daymade/claude-code-skills ↗ |
How do I compare competitors pricing and features?
Map rival products, positioning, pricing tiers, feature gaps, and GTM motions to inform differentiation before committing engineering scope or fundraising narratives.
Who is it for?
competitors-analysis is best for developers shaping scope and packaging decisions using competitor feature and pricing comparisons.
Skip if: competitors-analysis is not for teams that already have validated differentiation and only need implementation execution.
When should I use this skill?
Invoke competitors-analysis when a developer asks for competitor mapping, positioning comparison, pricing tier analysis, feature gap analysis, or GTM motion research before finalizing scope.
What you get
A competitor matrix, positioning notes, pricing tier breakdown, feature gap list, and GTM motion summary.
- competitor matrix
- pricing tier breakdown
- feature gap analysis
Files
Competitors Analysis
Evidence-based competitor tracking and analysis. All analysis must be based on actual code, never assumptions.
CRITICAL: Evidence-Based Analysis Only
在开始分析之前，必须完成以下检查：
Pre-Analysis Checklist
- [ ] 仓库已克隆到本地
~/Workspace/competitors/{product}/ - [ ] 可以
ls查看目录结构 - [ ] 可以
cat package.json(或等效配置文件) 读取版本信息 - [ ] 可以
git log -1确认代码是最新的
如果以上任何一项未完成，停止分析，先完成克隆操作。
Forbidden Patterns (禁止的表述)
| 禁止 | 原因 |
|---|---|
| "推测..."、"可能..."、"应该..." | 没有证据支持 |
| "架构图（推测版）" | 必须基于实际代码 |
| "未公开"、"未披露" | 如果不知道就不要写 |
| 不带来源的技术细节 | 无法验证 |
Required Patterns (必须的表述)
| 正确格式 | 示例 |
|---|---|
| 技术细节 + (来源: 文件:行号) | "使用 better-sqlite3 (来源: package.json:88)" |
| 直接引用 + 来源 | > "description text" (README.md:3) |
| 版本号 + 来源 | "版本 1.3.3 (package.json:2)" |
---
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.toml2.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/null2.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
| 文档 | 用途 |
|---|---|
| references/profile_template.md | 竞品分析报告模板 |
| references/analysis_checklist.md | 分析前/中/后检查清单 |
关键要求: 1. 顶部必须标注数据来源路径和 commit hash 2. 每个技术细节必须有 (来源: 文件:行号) 3. 引用 README 内容必须标注行号 4. 无法验证的标记为"待验证"并说明原因 5. 分析完成后运行检查清单中的验证命令
---
Tech Stack Analysis Guide
Node.js / JavaScript
| 信息 | 来源文件 | 关键字段 |
|---|---|---|
| 版本 | package.json | version |
| 依赖 | package.json | dependencies, devDependencies |
| 入口 | package.json | main, scripts.start |
| 框架 | package.json | electron, react, vite 等 |
Python
| 信息 | 来源文件 | 关键字段 |
|---|---|---|
| 版本 | pyproject.toml | [project].version |
| 依赖 | pyproject.toml / requirements.txt | dependencies |
| 入口 | pyproject.toml | [project.scripts] |
Rust
| 信息 | 来源文件 | 关键字段 |
|---|---|---|
| 版本 | Cargo.toml | [package].version |
| 依赖 | Cargo.toml | [dependencies] |
---
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 # 检查状态Security scan passed
Scanned at: 2026-01-29T23:52:21.174078
Tool: gitleaks + pattern-based validation
Content hash: 2f057ff46a0c9553f5183e7140adbc009f02793b958f49708d792de09815f258
竞品分析检查清单
分析前检查 (Pre-Analysis)
1. 仓库准备
- [ ] 仓库 URL 是否正确？
- [ ] 已创建产品竞品目录
~/Workspace/competitors/{product}/ - [ ] 已成功克隆仓库到本地
- [ ] 运行
git pull确保代码最新 - [ ] 记录当前 commit:
git log -1 --format="%h %s"
2. 基础文件确认
- [ ] README.md 存在且可读
- [ ] 配置文件存在 (package.json / Cargo.toml / pyproject.toml)
- [ ] LICENSE 文件存在
- [ ] 源码目录结构清晰 (src/ 或等效目录)
---
分析中检查 (During Analysis)
3. 技术栈验证
- [ ] 框架版本来自配置文件，已标注行号
- [ ] 依赖列表来自配置文件，已标注行号
- [ ] 入口文件已确认并读取
4. 核心模块分析
- [ ] 已识别核心模块/helper 文件
- [ ] 已读取关键实现代码
- [ ] 代码片段标注了文件路径和行号
5. 来源标注
- [ ] 每个版本号都有 (来源: file:行号)
- [ ] 每个技术细节都有来源
- [ ] 引用 README 内容标注了行号
- [ ] 对比表中竞品数据都有来源列
---
分析后检查 (Post-Analysis)
6. 禁止词汇检查
在分析文档中搜索以下词汇，如果存在必须修改或删除：
grep -E "(推测|可能|应该|大概|似乎|或许|未知|未披露|未公开)" profile.md- [ ] 无"推测"
- [ ] 无"可能"
- [ ] 无"应该"
- [ ] 无"大概"/"似乎"/"或许"
- [ ] 无"未知"/"未披露"/"未公开" (改为"待验证"并说明原因)
7. 来源完整性检查
# 检查是否有未标注来源的技术细节
grep -E "^- |^\| " profile.md | grep -v "(来源:|待验证)"- [ ] 所有列表项都有来源或标记为待验证
- [ ] 所有表格数据都有来源列
8. 文件引用验证
确认分析中引用的文件确实存在：
# 提取所有引用的文件路径
grep -oE "[a-zA-Z0-9_/]+\.(js|ts|py|rs|json|toml|md):[0-9]+" profile.md- [ ] 所有引用的文件都存在于仓库中
- [ ] 行号在文件范围内
---
常见错误修复
错误 1: 使用了推测性语言
修复前:
## 架构设计（推测版）
可能使用了微服务架构...修复后:
## 架构设计 (来源: 代码结构分析)
基于 src/ 目录结构，项目采用模块化设计：
- helpers/ 包含 30 个工具模块 (来源: `ls src/helpers/ | wc -l`)
- services/ 包含业务逻辑 (来源: 目录结构)错误 2: 对比表无来源
修复前:
| 维度 | 竞品 | 我们 |
|------|------|------|
| Stars | 920 | 100 |修复后:
| 维度 | 竞品 | 来源 | 我们 | 来源 |
|------|------|------|------|------|
| Stars | 920 | GitHub 2026-01-29 | 100 | GitHub 2026-01-29 |错误 3: 版本号无来源
修复前:
使用 React 19 和 Electron 36修复后:
使用 React 19.1.0 (package.json:96) 和 Electron 36.9.5 (package.json:68)---
质量评分
完成分析后，按以下标准自评：
| 维度 | 权重 | 评分标准 |
|---|---|---|
| 数据来源 | 40% | 100% 技术细节有来源 = 满分 |
| 无推测语言 | 30% | 0 个禁止词汇 = 满分 |
| 代码分析深度 | 20% | 读取 5+ 核心文件 = 满分 |
| 对比完整性 | 10% | 对比表 5+ 维度 = 满分 |
目标: 总分 >= 90%
{Competitor Name} 深度分析
仓库: {GitHub URL} 版本: {version} (来源: package.json:2) License: {license} (来源: LICENSE) 分析日期: {YYYY-MM-DD} 分析 Commit: {git log -1 --format="%h %s"} 数据来源: ~/Workspace/competitors/{product}/{competitor}/
---
分析声明
本分析基于本地克隆的代码仓库，所有技术细节均标注来源文件和行号。
未标注来源的内容为"待验证"状态。
---
核心定位
"{从 README.md 直接引用的描述}"
>
— README.md:{行号}
---
技术栈 (来源: package.json / Cargo.toml / pyproject.toml)
| 依赖 | 版本 | 用途 | 来源 |
|---|---|---|---|
| {dep1} | {ver} | {用途} | package.json:{行号} |
| {dep2} | {ver} | {用途} | package.json:{行号} |
---
项目结构 (来源: ls -la)
{competitor}/
├── {file1} # {说明} ({大小})
├── {dir1}/
│ ├── {file2} # {说明}
│ └── ...
└── ...---
核心模块分析
{模块名} (来源: {文件路径})
文件: {path/to/file.js} 行数: {wc -l 结果}
关键代码:
// {文件}:{起始行}-{结束行}
{代码片段}发现:
- {发现1} (行 {X})
- {发现2} (行 {Y})
---
与 {你的产品} 对比
| 维度 | {竞品} | 来源 | {你的产品} | 来源 |
|---|---|---|---|---|
| 框架 | {value} | package.json:{行} | {value} | package.json:{行} |
| ASR 引擎 | {value} | {file}:{行} | {value} | {file}:{行} |
| 数据库 | {value} | package.json:{行} | {value} | package.json:{行} |
---
可借鉴点
| 特性 | 实现位置 | 代码示例 | 借鉴价值 |
|---|---|---|---|
| {特性1} | {file}:{行号} | {简短代码} | {价值说明} |
| {特性2} | {file}:{行号} | {简短代码} | {价值说明} |
---
差异化机会
| {你的产品}优势 | 原因 | 竞品对应实现 |
|---|---|---|
| {优势1} | {原因} | {竞品如何实现或缺失} |
| {优势2} | {原因} | {竞品如何实现或缺失} |
---
源码阅读记录
| 文件 | 行数 | 核心发现 | 来源行号 |
|---|---|---|---|
{file1} | {lines} | {发现} | L{start}-L{end} |
{file2} | {lines} | {发现} | L{start}-L{end} |
---
待验证项
以下信息未能从代码中直接确认，需要进一步调查：
- [ ] {待验证项1} - 原因: {为什么无法确认}
- [ ] {待验证项2} - 原因: {为什么无法确认}
---
社区数据 (来源: GitHub API / 页面)
| 指标 | 数值 | 获取日期 |
|---|---|---|
| Stars | {count} | {date} |
| Forks | {count} | {date} |
| Open Issues | {count} | {date} |
| Last Commit | {date} | {date} |
---
返回 [README.md](../README.md)
#!/bin/bash
# 竞品仓库管理脚本模板
# 复制此文件到你的项目: scripts/update-competitors.sh
# 用法: ./scripts/update-competitors.sh [clone|pull|status]
set -e
# ============================================================
# 配置区域 - 根据你的产品修改
# ============================================================
# 竞品仓库基础目录（按产品区分）
COMPETITORS_BASE="${COMPETITORS_BASE:-$HOME/Workspace/competitors}"
# 你的产品名称（用于子目录）
PRODUCT_NAME="your-product-name" # TODO: 修改为你的产品名
# 竞品目录
COMPETITORS_DIR="$COMPETITORS_BASE/$PRODUCT_NAME"
# 竞品仓库列表（SSH 方式，网络问题时会自动重试）
declare -A COMPETITORS=(
# TODO: 添加你的竞品
# ["competitor-name"]="git@github.com:org/repo.git"
# 示例:
# ["openwhispr"]="git@github.com:OpenWhispr/openwhispr.git"
)
# ============================================================
# 以下代码无需修改
# ============================================================
# 颜色
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
RED='\033[0;31m'
NC='\033[0m'
# 函数：克隆仓库
clone_repos() {
echo -e "${GREEN}=== 克隆竞品仓库 ($PRODUCT_NAME) ===${NC}"
mkdir -p "$COMPETITORS_DIR"
for name in "${!COMPETITORS[@]}"; do
repo="${COMPETITORS[$name]}"
target="$COMPETITORS_DIR/$name"
if [ -d "$target" ]; then
echo -e "${YELLOW}[跳过] $name 已存在${NC}"
else
echo -e "${GREEN}[克隆] $name${NC}"
# 网络问题自动重试
for i in 1 2 3; do
if git clone "$repo" "$target" 2>/dev/null; then
break
fi
echo " 重试 $i/3..."
sleep 2
done
fi
done
echo ""
echo -e "${GREEN}完成！竞品仓库位于: $COMPETITORS_DIR${NC}"
}
# 函数：更新仓库
pull_repos() {
echo -e "${GREEN}=== 更新竞品仓库 ($PRODUCT_NAME) ===${NC}"
for name in "${!COMPETITORS[@]}"; do
target="$COMPETITORS_DIR/$name"
if [ -d "$target" ]; then
echo -e "${GREEN}[更新] $name${NC}"
cd "$target"
git fetch --all 2>/dev/null || echo -e "${RED} fetch 失败${NC}"
git pull --rebase 2>/dev/null || echo -e "${YELLOW} 可能有冲突${NC}"
cd - > /dev/null
else
echo -e "${RED}[缺失] $name - 请先运行 clone${NC}"
fi
done
}
# 函数：检查状态
check_status() {
echo -e "${GREEN}=== 竞品仓库状态 ($PRODUCT_NAME) ===${NC}"
echo ""
for name in "${!COMPETITORS[@]}"; do
target="$COMPETITORS_DIR/$name"
if [ -d "$target" ]; then
cd "$target"
branch=$(git branch --show-current 2>/dev/null || echo "unknown")
commit=$(git log -1 --format="%h %s" 2>/dev/null | head -c 60)
behind=$(git rev-list --count HEAD..origin/main 2>/dev/null || echo "?")
echo -e "${GREEN}$name${NC} ($branch)"
echo " 最新: $commit"
echo " 落后: $behind 个提交"
cd - > /dev/null
else
echo -e "${RED}$name${NC}: 未克隆"
fi
echo ""
done
}
# 函数：显示帮助
show_help() {
echo "竞品仓库管理脚本 - $PRODUCT_NAME"
echo ""
echo "用法: $0 [命令]"
echo ""
echo "命令:"
echo " clone 克隆所有竞品仓库到 $COMPETITORS_DIR"
echo " pull 更新所有竞品仓库"
echo " status 检查仓库状态（分支、最新提交、落后数）"
echo " help 显示此帮助"
echo ""
echo "环境变量:"
echo " COMPETITORS_BASE 竞品仓库基础目录 (默认: ~/Workspace/competitors)"
echo ""
echo "目录结构:"
echo " $COMPETITORS_BASE/"
echo " └── $PRODUCT_NAME/"
echo " ├── competitor1/"
echo " └── competitor2/"
}
# 主逻辑
case "${1:-help}" in
clone)
clone_repos
;;
pull)
pull_repos
;;
status)
check_status
;;
help|--help|-h)
show_help
;;
*)
echo -e "${RED}未知命令: $1${NC}"
show_help
exit 1
;;
esac
Related skills
Grill MeHave an agent relentlessly pressure-test their plan or design until every decision branch is resolved and shared understanding is reached.691k196kGrill With DocsPressure-test architecture decisions against their live codebase and living documentation before writing production code.585k196k
Lark CalendarLet their coding agents read, create, and manage events inside Lark (Feishu) Calendar directly from natural language instructions.493kLark ImLet their coding agent send instant notifications, post updates, and receive commands directly inside Lark (Feishu) workspaces.493kLark ContactLet their AI coding agents read and write contacts, send messages, and manage user data inside Lark (Feishu).493kLark AttendanceAutomatically fetch and report daily attendance data from Lark (Feishu) into their own tools or agents.493kHow it compares
Pick this when you need a structured competitor-to-scope output (positioning + pricing tiers + feature gaps) rather than unstructured brainstorming notes.
FAQ
What does competitors-analysis produce?
competitors-analysis produces a structured competitor map that typically includes positioning notes, a pricing tier breakdown, a list of feature gaps and parity items, and a summary of observed go-to-market motions, which can be used directly in product strategy docs and roadmap
When should I run competitors-analysis in a project?
competitors-analysis should be run early when scope and differentiation are still fluid, especially before committing engineering effort to an MVP, pricing plan, or packaging model, because competitor pricing tiers and feature gaps can materially change what the first release sho
Is competitors-analysis only for marketing teams?
competitors-analysis is useful for engineers and product owners because it translates competitor positioning and pricing tiers into buildable implications like feature-to-tier mapping and scope boundaries, which helps prevent building undifferentiated functionality or misaligned