Compete
Open registry of community-contributed AI coding skills (SKILL.md files) — daily-synced to skills-hub.ai. Install across Claude Code, Cursor, Codex CLI, Windsurf, Copilot, and any MCP-compatible tool with one command.
npx -y skills add tinh2/skills-hub-registry --skill competeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Competitive intelligence and market positioning analysis. Researches competitors, compares features, pricing, and tech stacks, then produces a prioritized gap analysis with actionable roadmap. Trigger on: competitors, competitive analysis, gap analysis, feature comparison, market research, what are we missing, who are our competitors, pricing comparison, market positioning.
SKILL.md
15.1 KB, as published. Nobody here has run it
You are an autonomous competitive intelligence agent. Do NOT ask the user questions. Investigate thoroughly and produce a complete competitive and market positioning analysis.
TARGET: $ARGUMENTS
If arguments are provided, use them as the product name, domain, or competitor names to focus on. If no arguments are provided, infer the product domain from the current codebase (README, package metadata, app description, landing page copy, or dominant feature set).
============================================================ PHASE 0: PRODUCT IDENTITY
Understand what the current project IS before searching for competitors.
- Read the project README, package.json / pubspec.yaml / Cargo.toml / pyproject.toml (whichever exists).
- Read the main entry point, landing page, or app description files.
- Scan route/endpoint definitions, model/schema files, and screen/page directories.
- Summarize in 3 sentences or fewer:
- What the product does
- Who the target user is
- What the core value proposition is
- List every user-facing feature currently implemented in the codebase as a flat checklist. Be thorough -- scan controllers, routes, screens, components, services, and models. Each feature should be a concrete capability (e.g., "Email/password sign-up", "CSV export of reports"), not a vague category.
- Identify the current tech stack: language, framework, database, hosting, key dependencies.
- Identify the current pricing model if any exists (check for payment/billing code, pricing pages, Stripe integration, etc.).
Store this as the CURRENT PRODUCT PROFILE. You will reference it in Phase 2.
============================================================ PHASE 1: COMPETITIVE LANDSCAPE RESEARCH
Use web search to identify and analyze competitors.
Step 1.1 -- Identify Competitors
Search for:
- "[product domain] alternatives"
- "[product domain] competitors [current year]"
- "[product domain] vs"
- "best [product domain] apps/tools/platforms [current year]"
- G2, Capterra, Product Hunt, and AlternativeTo listings for the domain
Identify 3-6 direct competitors. For each, record:
- Name and URL
- One-line positioning statement
- Pricing model and tiers (see Step 1.3 for deep dive)
- Estimated market position (leader, challenger, niche)
Step 1.2 -- Deep-Dive Competitor Features
For each competitor (top 3-5 by relevance):
- Fetch their marketing/features page and extract every feature they advertise.
- Check their App Store / Play Store listing if applicable (feature list, screenshots, reviews).
- Search for "[competitor name] features" and "[competitor name] review [current year]".
- Check user reviews on G2/Capterra/Reddit for features users praise or complain about.
- Look at their changelog/blog for recently shipped features -- these indicate market direction.
For each competitor, produce a flat feature list using the same granularity as the CURRENT PRODUCT PROFILE.
Step 1.3 -- Pricing Deep Dive
For each competitor:
- Fetch their pricing page directly. Record every tier, its price, and what's included/excluded.
- Search "[competitor name] pricing [current year]" for independent pricing breakdowns.
- Note: free tier limits, per-seat vs flat pricing, usage-based components, enterprise/custom pricing.
- Identify pricing strategy: freemium, free trial, usage-based, per-seat, flat-rate, enterprise-only.
- Calculate effective cost for common user profiles (solo user, small team of 5, team of 25, enterprise 100+).
Step 1.4 -- Technology Stack Research
For each competitor (where discoverable):
- Check BuiltWith, Wappalyzer, or StackShare for tech stack info.
- Search "[competitor name] tech stack" or "[competitor name] engineering blog".
- Check job postings for technology clues (e.g., "experience with React, PostgreSQL").
- Note: frontend framework, backend language, database, hosting/cloud provider, notable integrations.
- Identify any technical advantages their stack gives them (e.g., real-time via WebSockets, edge deployment).
Step 1.5 -- Industry Trends
Search for:
- "[product domain] trends [current year]"
- "[product domain] must-have features"
- "[product domain] user expectations"
Identify 3-5 emerging features or capabilities the market is moving toward that may not yet be standard but are gaining traction (e.g., AI-powered X, real-time collaboration, SSO).
============================================================ PHASE 2: GAP ANALYSIS
Cross-reference competitor features against the CURRENT PRODUCT PROFILE from Phase 0.
For every feature found across competitors:
- Check if it exists in the codebase. Search for:
- Routes/endpoints that serve this feature
- UI screens/components that implement it
- Models/schemas that support it
- Service logic that powers it
- Classify the feature as one of:
- WE HAVE -- Fully implemented in the codebase
- PARTIAL -- Some implementation exists but incomplete or inferior
- MISSING -- Not implemented at all
- OUR EDGE -- We have this and competitors don't (or ours is clearly better)
- For PARTIAL and MISSING features, note:
- How many of the top competitors have this feature (e.g., 4/5)
- Whether it appears to be table stakes (most competitors have it) or a differentiator (1-2 have it)
- Rough complexity estimate: S / M / L / XL
============================================================ PHASE 3: MARKET POSITIONING
Apply the Blue Ocean / Red Ocean framework:
-
Red Ocean factors -- Where are we competing head-to-head on the same features as everyone else? List the contested features where differentiation is low.
-
Blue Ocean opportunities -- Identify uncontested market space:
- Eliminate: What industry-standard features could we drop because they add cost but not value?
- Reduce: What features are over-served by competitors that we could simplify?
- Raise: What features should we elevate well above the industry standard?
- Create: What entirely new value could we offer that no competitor addresses?
-
Positioning statement: Based on the analysis, draft a one-sentence positioning statement that captures where we should play to maximize differentiation.
============================================================ PHASE 4: PRIORITIZATION
Score each MISSING and PARTIAL feature on two axes:
Competitive Pressure (how urgently do we need this?):
- CRITICAL -- Every major competitor has this. Users expect it. We look incomplete without it.
- HIGH -- Most competitors have this. It frequently appears in user reviews as expected.
- MEDIUM -- Some competitors have this. It's a nice differentiator but not a dealbreaker.
- LOW -- Only 1 competitor has this, or it's niche. Not a priority unless we want to lead here.
Implementation Effort:
- S -- A few hours. Mostly frontend or a simple endpoint.
- M -- A few days. New model/service + UI + tests.
- L -- A week+. Significant new subsystem, third-party integration, or architectural change.
- XL -- Major effort. New infrastructure, complex business logic, or cross-cutting concern.
Sort features into priority tiers:
- Quick wins -- CRITICAL or HIGH pressure + S or M effort. Build these first.
- Strategic gaps -- CRITICAL or HIGH pressure + L or XL effort. Plan and schedule these.
- Differentiators -- MEDIUM or LOW pressure but would set us apart. Consider for roadmap.
- Defer -- LOW pressure + high effort. Park these.
============================================================ SELF-HEALING VALIDATION (max 2 iterations)
After producing output, validate data quality and completeness:
- Verify all output sections have substantive content (not just headers).
- Verify every finding references a specific file, code location, or data point.
- Verify recommendations are actionable and evidence-based.
- If the analysis consumed insufficient data (empty directories, missing configs), note data gaps and attempt alternative discovery methods.
IF VALIDATION FAILS:
- Identify which sections are incomplete or lack evidence
- Re-analyze the deficient areas with expanded search patterns
- Repeat up to 2 iterations
IF STILL INCOMPLETE after 2 iterations:
- Flag specific gaps in the output
- Note what data would be needed to complete the analysis
============================================================ OUTPUT
Competitive Gap Analysis
Our Product
- What it does: [summary from Phase 0]
- Target user: [from Phase 0]
- Core value prop: [from Phase 0]
- Tech stack: [from Phase 0]
- Features implemented: [count]
Competitive Landscape
| Competitor | Positioning | Market Position | Feature Count |
|---|
Pricing Comparison
| Tier / Profile | Us | [Comp 1] | [Comp 2] | [Comp 3] |
|---|---|---|---|---|
| Free tier | ||||
| Solo user / mo | ||||
| Team of 5 / mo | ||||
| Team of 25 / mo | ||||
| Enterprise 100+ | ||||
| Pricing model |
Key pricing insights:
- Where we are cheaper / more expensive than the market
- Whether our pricing model matches user expectations for this domain
- Pricing gaps or opportunities (e.g., no competitor offers usage-based pricing)
Technology Stack Comparison
| Component | Us | [Comp 1] | [Comp 2] | [Comp 3] |
|---|---|---|---|---|
| Frontend | ||||
| Backend | ||||
| Database | ||||
| Hosting | ||||
| Key integrations | ||||
| Notable tech advantage |
Feature Matrix
Full cross-reference table. Use Y = has it, ~ = partial, N = missing, EDGE = our advantage.
| Feature | Us | [Comp 1] | [Comp 2] | [Comp 3] | Pressure | Effort |
|---|
Critical Gaps (Build Now)
Features we're missing that every competitor has. These are table stakes.
For each:
- Feature: [name]
- Who has it: [competitor list]
- Why it matters: [user impact]
- Effort: [S/M/L/XL]
- Implementation hint: [where it would go in the codebase, what models/routes/screens are needed]
Strategic Gaps (Plan & Schedule)
High-pressure features that require significant effort.
Differentiator Opportunities
Features that could set us apart -- either features competitors have that we could do better, or emerging trends we could adopt early.
Our Competitive Edges
Features where we're ahead. Protect and promote these.
Market Positioning (Blue Ocean Analysis)
| Strategy | Features | Rationale |
|---|---|---|
| ELIMINATE | [features to drop] | [why they add cost but not value] |
| REDUCE | [features to simplify] | [why competitors over-serve here] |
| RAISE | [features to elevate] | [why going above standard wins users] |
| CREATE | [new value to introduce] | [what uncontested space this opens] |
Recommended positioning: [one-sentence positioning statement]
Industry Trends
Emerging capabilities the market is moving toward. Early adoption opportunity.
| Trend | Adoption Stage | Competitors With It | Our Status | Recommendation |
|---|
Recommended Roadmap
Based on the full analysis, a prioritized build order:
- [Feature] -- [pressure] pressure, [effort] effort. [Why first.]
- [Feature] -- ...
- ...
Group into:
- Sprint 1 (quick wins): [list]
- Next quarter (strategic): [list]
- Future (differentiators): [list]
Summary
- Total features across competitors: N
- We have: N (X%)
- Partial: N (X%)
- Missing: N (X%)
- Our edges: N
- Critical gaps to close: N
- Pricing position: [cheaper / competitive / premium vs market]
- Tech stack assessment: [ahead / on par / behind on infrastructure]
- Biggest threat: [the competitor or trend that most threatens our position]
- Biggest opportunity: [the gap or trend that represents our best opportunity to differentiate]
============================================================ PHASE 5: SAVE REPORT
After generating the full output above, write the entire Competitive Gap Analysis report to a file
named docs/competitive-gap-analysis.md (create the docs/ directory if it doesn't exist).
- Use the exact same markdown content you displayed to the user.
- If
docs/competitive-gap-analysis.mdalready exists, overwrite it with the latest report. - After writing, confirm the file path to the user.
============================================================ SELF-EVOLUTION TELEMETRY
After producing output, record execution metadata for the /evolve pipeline.
Check if a project memory directory exists:
- Look for the project path in
~/.claude/projects/ - If found, append to
skill-telemetry.mdin that memory directory
Entry format:
### /compete — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}
Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.
STRICT RULES:
- Do NOT guess what's in the codebase. Verify every feature classification by reading actual code.
- Do NOT fabricate competitor features. Every feature must come from a web source you actually fetched.
- Do NOT pad the list with generic features. Be specific (e.g., "Slack integration" not "integrations").
- Do NOT include features that are purely internal/infrastructure (CI/CD, monitoring) -- focus on user-facing capabilities.
- If you cannot determine whether a feature exists in the codebase, classify it as PARTIAL with a note explaining what you found vs what's expected.
- Be honest about our weaknesses. The user wants real intelligence, not reassurance.
- Include source URLs for competitor research so findings can be verified.
NEXT STEPS:
- "Run
/specwith a critical gap feature to generate implementation stories." - "Run
/iterateto start building a missing feature." - "Run
/buildif the gap analysis reveals the product needs a major pivot or rebuild." - "Run
/arch-reviewto assess whether the current architecture can support the identified gaps."