Compete

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.

1. Read the project README, package.json / pubspec.yaml / Cargo.toml / pyproject.toml (whichever exists).
2. Read the main entry point, landing page, or app description files.
3. Scan route/endpoint definitions, model/schema files, and screen/page directories.
4. Summarize in 3 sentences or fewer:
   • What the product does
   • Who the target user is
   • What the core value proposition is
5. 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.
6. Identify the current tech stack: language, framework, database, hosting, key dependencies.
7. 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):

1. Fetch their marketing/features page and extract every feature they advertise.
2. Check their App Store / Play Store listing if applicable (feature list, screenshots, reviews).
3. Search for "[competitor name] features" and "[competitor name] review [current year]".
4. Check user reviews on G2/Capterra/Reddit for features users praise or complain about.
5. 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:

1. Fetch their pricing page directly. Record every tier, its price, and what's included/excluded.
2. Search "[competitor name] pricing [current year]" for independent pricing breakdowns.
3. Note: free tier limits, per-seat vs flat pricing, usage-based components, enterprise/custom pricing.
4. Identify pricing strategy: freemium, free trial, usage-based, per-seat, flat-rate, enterprise-only.
5. 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):

1. Check BuiltWith, Wappalyzer, or StackShare for tech stack info.
2. Search "[competitor name] tech stack" or "[competitor name] engineering blog".
3. Check job postings for technology clues (e.g., "experience with React, PostgreSQL").
4. Note: frontend framework, backend language, database, hosting/cloud provider, notable integrations.
5. 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:

1. 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
2. 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)
3. 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:

1. 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.

2. 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?

3. 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:

1. Quick wins -- CRITICAL or HIGH pressure + S or M effort. Build these first.
2. Strategic gaps -- CRITICAL or HIGH pressure + L or XL effort. Plan and schedule these.
3. Differentiators -- MEDIUM or LOW pressure but would set us apart. Consider for roadmap.
4. Defer -- LOW pressure + high effort. Park these.

============================================================ SELF-HEALING VALIDATION (max 2 iterations)

After producing output, validate data quality and completeness:

1. Verify all output sections have substantive content (not just headers).
2. Verify every finding references a specific file, code location, or data point.
3. Verify recommendations are actionable and evidence-based.
4. 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

Pricing Comparison

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

Feature Matrix

Full cross-reference table. Use Y = has it, ~ = partial, N = missing, EDGE = our advantage.

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)

Recommended positioning: [one-sentence positioning statement]

Industry Trends

Emerging capabilities the market is moving toward. Early adoption opportunity.

Recommended Roadmap

Based on the full analysis, a prioritized build order:

1. [Feature] -- [pressure] pressure, [effort] effort. [Why first.]
2. [Feature] -- ...
3. ...

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.md already 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.md in 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 /spec with a critical gap feature to generate implementation stories."
• "Run /iterate to start building a missing feature."
• "Run /build if the gap analysis reveals the product needs a major pivot or rebuild."
• "Run /arch-review to assess whether the current architecture can support the identified gaps."