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
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:
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 | |
| Dependencies | package.json | , |
| Entry Point | package.json | , |
| Framework | package.json | electron, react, vite, etc. |
Python
| Information | Source File | Key Field |
|---|
| Version | pyproject.toml | |
| Dependencies | pyproject.toml / requirements.txt | |
| Entry Point | pyproject.toml | |
Rust
| Information | Source File | Key Field |
|---|
| Version | Cargo.toml | |
| Dependencies | Cargo.toml | |
Common Mistakes to Avoid
1. Skipping Cloning and Analyzing Directly
❌ Wrong: Writing analysis directly after getting information from GitHub webpage or WebFetch
✅ Correct: Must
to local and use the
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)
|------------|---------|--------|
| 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
before analysis and record the commit hash at the time of analysis
4. Competitor Data in Comparison Tables Without Sources
❌ Wrong:
markdown
|-----------|------------|----|
| Supported Languages | 25 | 58 |
✅ Correct:
markdown
|-----------|------------|--------|----|
| 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