Preamble

In agent development or product iteration, requirement validation before feature construction is a critical step. Marketing pages often only state intent, while user reviews document real outcomes. A user complaint with a traceable source is often more valuable than an entire page of feature copy. When three independent users complain about the same issue, it represents a clear unmet need.

competitor-recon is a DSH plugin for automated competitor research. It scrapes competitors’ reviews, forum posts, and Issue Trackers, extracts features, pricing, positioning, and user complaints, clusters the findings, and outputs a comparison table and a build list.

Core Capabilities

  1. Competitor Enumeration: Automatically identifies 3–6 competitors, covering English and Chinese sources.
  2. Information Extraction: Extracts competitor features, specific pricing, market positioning, and user complaints with source links.
  3. Complaint Clustering: Clusters complaints by potential need and ranks them by frequency.
  4. Output Delivery: Generates a comparison table, a reusable list, and a skip list. Only feature points with concrete complaint evidence enter the build list.
  5. Frequency Statistics: Leverages Issue Trackers (e.g., 👍 upvotes) as a free frequency-stats tool.

Installation and Enablement

Clone the repository into DSH’s skills directory to use it.

git clone https://github.com/ChenneyZhuang/competitor-recon ~/.claude/skills/competitor-recon

This plugin is a single SKILL.md file and relies on basic web search and scraping capabilities. The version is v0.2.0, released under the MIT License.

Usage

Before writing feature code, run competitor recon once. The comment sections of existing products are the lowest-cost source for requirements discovery.

  1. Enumerate Competitors: Search English and Chinese sources and identify 3–6 key competitors.
  2. Extract Data: For each competitor, list its features, pricing (specific numbers), positioning, and user complaints, and record source links.
  3. Cluster Analysis: Group complaints under specific potential needs and count their frequency.
  4. Decision Output: Output a comparison table. Any feature you want to build must be supported by specific user-complaint evidence.

Limitations and Notes

  • Comments First: Comments carry more weight than marketing pages. When they conflict, comments take precedence.
  • Data Source Limitations: Review sites and forums may throttle crawlers; some evidence may come from search snippets rather than full posts, and such citations are explicitly labeled.
  • Statistical Meaning: Reaction counts in issue trackers (e.g., 👍) measure engagement, not market size. A quiet competitor may simply lack a community.
  • Tool Failure Handling: If a tool is blocked, switch scraping clients (e.g., curl, public APIs) instead of changing data sources. The evidence chain must remain intact.
  • Market Coverage: The current plugin only covers English- and Chinese-speaking ecosystems and does not sample Japan, Korea, Europe, or other markets.

Repository and Source Code

For more details and source code, visit GitHub.