competitors-analysis

Original：🇨🇳 Chinese

Translated

1 scripts

Analyze competitor repositories with an evidence-based approach. Use this when tracking competitors, creating competitor profiles, or generating competitive analysis. CRITICAL - all analysis must be based on actual cloned code, never assumptions. Triggers include "analyze competitor", "add competitor", "competitive analysis", or "竞品分析".

1installs

Sourcedaymade/claude-code-skills

Added on2026-05-30

NPX Install

npx skill4agent add daymade/claude-code-skills competitors-analysis

SKILL.md Content (Chinese)

View Translation Comparison →

Competitors Analysis

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

CRITICAL: Evidence-Based Analysis Only

Before starting the analysis, the following checks must be completed:

Pre-Analysis Checklist

Repository has been cloned locally to
```
~/Workspace/competitors/{product}/
```
Can use
```
ls
```
to view the directory structure
Can use
```
cat package.json
```
(or equivalent configuration file) to read version information
Can use
```
git log -1
```
to confirm the code is up-to-date

If any of the above items are not completed, stop the analysis and complete the cloning operation first.

Forbidden Patterns (Prohibited Expressions)

Forbidden	Reason
"Speculate...", "May...", "Should..."	No evidence to support
"Architecture Diagram (Speculated Version)"	Must be based on actual code
"Not disclosed", "Unrevealed"	Do not write if unknown
Technical details without sources	Cannot be verified

Required Patterns (Mandatory Expressions)

Correct Format	Example
Technical details + (Source: File:Line Number)	"Uses better-sqlite3 (Source: package.json:88)"
Direct quote + Source	`> "description text" (README.md:3)`
Version number + Source	"Version 1.3.3 (Source: package.json:2)"

Analysis Workflow

Step 1: Clone Repository (Mandatory)

bash

# Create product competitor directory
mkdir -p ~/Workspace/competitors/{product-name}

# Clone competitor repository (SSH, retry if failed)
cd ~/Workspace/competitors/{product-name}
git clone git@github.com:org/repo.git

Network Issue Handling: Multiple retries may be required in the Chinese network environment.

Step 2: Gather Facts

Read the following files in order and record key information:

2.1 Project Metadata

bash

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

# Python project
cat pyproject.toml               # or setup.py, requirements.txt

# Rust project
cat Cargo.toml

2.2 Project Structure

bash

ls -la                           # Root directory structure
ls src/                          # Source code directory
find . -name "*.md" -maxdepth 2  # Documentation files

2.3 Core Modules

bash

# Find entry file
cat main.js | head -50           # or index.js, app.py, main.rs
# Find core helpers/utils
ls src/helpers/ 2>/dev/null || ls src/utils/ 2>/dev/null

2.4 README and Documentation

bash

cat README.md | head -100        # Official description
cat CHANGELOG.md | head -50      # Version history

Step 3: Deep Dive

For key technical points, read the specific implementation files:

bash

# Example: Analyze ASR implementation
cat src/helpers/whisper.js       # Read full file
grep -n "class.*Manager" src/helpers/*.js  # Find core classes

Recording Format:

| File | Line Number | Finding |
|------|-------------|---------|
| whisper.js | 33-35 | Uses WhisperServerManager |

Step 4: Write Profile

Use the references/profile_template.md template to ensure every technical detail is sourced.

Step 5: Post-Analysis Verification

Self-Check Checklist:

Are all version numbers sourced?
Is all tech stack information from package.json/Cargo.toml?
Is the architecture description based on actual code structure?
Are there no words like "speculate", "may", etc.?
Is all competitor data in comparison tables sourced?

Directory Structure

~/Workspace/competitors/
├── flowzero/              # Competitor for Flowzero
│   ├── openwhispr/        # Repository cloned via git clone
│   └── ...
└── {product-name}/        # Other products

{project}/docs/competitors/
├── README.md              # Index (marks analysis status)
├── profiles/
│   └── {competitor}.md    # Code-based analysis
├── landscape/
├── insights/
└── updates/2026/

Templates and Checklists

Document	Purpose
references/profile_template.md	Competitor analysis report template
references/analysis_checklist.md	Pre-analysis/In-analysis/Post-analysis checklist

Key Requirements:

Must mark the data source path and commit hash at the top
Every technical detail must include (Source: File:Line Number)
Quoted README content must include line numbers
Unverifiable content must be marked as "Pending Verification" with reasons explained
Run the verification commands in the checklist after completing the analysis

Tech Stack Analysis Guide

Node.js / JavaScript

Information	Source File	Key Field
Version	package.json	`version`
Dependencies	package.json	`dependencies` , `devDependencies`
Entry Point	package.json	`main` , `scripts.start`
Framework	package.json	electron, react, vite, etc.

Python

Information	Source File	Key Field
Version	pyproject.toml	`[project].version`
Dependencies	pyproject.toml / requirements.txt	`dependencies`
Entry Point	pyproject.toml	`[project.scripts]`

Rust

Information	Source File	Key Field
Version	Cargo.toml	`[package].version`
Dependencies	Cargo.toml	`[dependencies]`

Common Mistakes to Avoid

1. Skipping Cloning and Analyzing Directly

❌ Wrong: Writing analysis directly after getting information from GitHub webpage or WebFetch ✅ Correct: Must

git clone

to local and use the

Read

tool to read files

2. Mixing Facts and Speculations

❌ Wrong:

markdown

## Tech Stack
- Electron (Speculated based on desktop application features)
- May have used React

✅ Correct:

markdown

## Tech Stack (Source: package.json)
| Dependency | Version | Source |
|------------|---------|--------|
| electron | 36.9.5 | package.json:68 |
| react | 19.1.0 | package.json:96 |

3. Using Outdated Information

❌ Wrong: Not checking git log during analysis and using outdated code ✅ Correct: Run

git pull

before analysis and record the commit hash at the time of analysis

4. Competitor Data in Comparison Tables Without Sources

❌ Wrong:

markdown

| Dimension | Competitor | Us |
|-----------|------------|----|
| Supported Languages | 25 | 58 |

✅ Correct:

markdown

| Dimension | Competitor | Source | Us |
|-----------|------------|--------|----|
| Supported Languages | 25 | modelRegistryData.json:9-35 | 58 (FunASR Official Documentation) |

Scripts

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

bash

./scripts/update-competitors.sh clone   # Clone all competitors
./scripts/update-competitors.sh pull    # Update all competitors
./scripts/update-competitors.sh status  # Check status

competitors-analysis

NPX Install

Tags

SKILL.md Content (Chinese)

Competitors Analysis

CRITICAL: Evidence-Based Analysis Only

Pre-Analysis Checklist

Forbidden Patterns (Prohibited Expressions)

Required Patterns (Mandatory Expressions)

Analysis Workflow

Step 1: Clone Repository (Mandatory)

Step 2: Gather Facts

Step 3: Deep Dive

Step 4: Write Profile

Step 5: Post-Analysis Verification

Directory Structure

Templates and Checklists

Tech Stack Analysis Guide

Node.js / JavaScript

Python

Rust

Common Mistakes to Avoid

1. Skipping Cloning and Analyzing Directly

2. Mixing Facts and Speculations

3. Using Outdated Information

4. Competitor Data in Comparison Tables Without Sources

Scripts