agentsclimarketplace

Competitive analysis

Skill viknesh20-20/claude-code-tool-kit/.claude/skills/competitive-analysis

Production-ready Claude Code configuration. 12 original agents, 200+ slash-command skills, 45+ MCP servers, 14 plugins, design + 3D + WebGPU + GSAP + RAG tooling. One-command Node.js installer for premium websites, SaaS apps, AI agents. Free, MIT, stack-agnostic.

Install
npx -y skills add viknesh20-20/claude-code-tool-kit --skill competitive-analysis

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 5 stars5 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

Research how 2–4 mature competitors solve a specific business problem (billing, RBAC, search, onboarding, multi-tenancy, etc.) and produce a side-by-side comparison so the team can pick the right approach for their context. Uses web search + scraping; cites every source.

SKILL.md

6.6 KB, as published. Nobody here has run it

/competitive-analysis

Before designing a feature in a well-trodden domain, look at how 2–4 mature companies handle it. Faster than inventing. More robust than guessing. Cite every source — never copy product copy or terms-of-service language.

When to use

  • Designing billing, dunning, refunds, plan changes, trials, onboarding.
  • Designing RBAC, workspace management, team invitations.
  • Designing notifications, digests, preferences.
  • Designing API rate limits, pagination, idempotency, error formats.
  • Designing search, filters, saved views.
  • Designing data export, deletion, retention.
  • Stuck on UX for a non-obvious flow (account merging, plan downgrade, account recovery).

When NOT to use

  • The user's domain is unique enough that competitor patterns won't transfer (specialized B2B verticals, regulated industries with custom workflows).
  • The user has already decided. Don't second-guess; just ship.
  • Style and copy decisions — those are taste, not pattern.

Operating method

1. Confirm the question

Ask the user, in one round:

  • What's the specific problem? Not "how does Stripe work" but "how should we handle a failed-payment retry schedule and the user-facing dunning emails?"
  • What's our context? B2C / B2B / SMB / enterprise / specific vertical. Self-serve vs sales-led. Plan structure.
  • What constraints are non-negotiable? Compliance, no-third-party-data, must-self-host, etc.
  • Which competitors should I look at? If unsure, suggest 3–4 mature ones in the relevant space.

Don't research without these answers. Researching the wrong question wastes a few minutes; acting on the wrong research costs a quarter.

2. Pick competitors deliberately

Mature comparison sets by domain (suggest these as defaults; adjust per user):

DomainSuggested competitors
SaaS billing & dunningStripe, Recurly, Chargebee, Paddle
B2B SaaS workspace + RBACLinear, Notion, Slack, Asana
CRMSalesforce, HubSpot, Pipedrive, Close
E-commerce checkoutShopify, Stripe Checkout, BigCommerce, WooCommerce
Marketplace fees + payoutsStripe Connect, Airbnb, Etsy, Uber
Customer supportIntercom, Zendesk, HelpScout, Front
Project managementLinear, Jira, Asana, Monday
ERP financialsNetSuite, SAP, Odoo, Microsoft Dynamics
InventoryShopify, NetSuite, Cin7, Brightpearl
Auth / SSOAuth0, Clerk, WorkOS, Okta
Notifications / engagementCustomer.io, Braze, Iterable, Knock
Webhooks / eventsStripe, GitHub, Segment
AnalyticsMixpanel, Amplitude, PostHog, Segment
SearchAlgolia, Elasticsearch, Typesense, Meilisearch
Status / incidentsStatusPage, Statuspal, Better Uptime

3. Research each competitor

For each:

  1. Read their public docs for the specific feature. Use firecrawl-scrape MCP if available. Quote with attribution.
  2. Find dev-blog posts, conference talks, engineering decisions. These reveal why not just what.
  3. Read 1–2 critical reviews (G2, ProductHunt, Reddit, HN) to find the friction points.
  4. Note the version / date. Patterns evolve; a 2019 blog post may not reflect 2026 behavior.

4. Extract the dimensions that matter

Don't write narrative comparisons. Build a table where each row is a decision point and each column is a competitor.

For billing failure-recovery:

DimensionStripe Smart RetriesRecurlyChargebeePaddle
Retry count4 (default)configurable 1–5configurable 1–103
Retry window15 days21 daysconfigurable14 days
Retry timingML-optimizedfixed cadencefixed/customfixed
Email cadenceday 1, 3, 7day 1, 5, 10, 15per templateday 1, 7
Grace periodbills marked past_duesuspend after final retryconfigurablesuspend
Customer self-rescuecustomer_portalhosted pagehosted pagehosted page
Card update promptyes, in-productyes, hostedyesyes
3DS / SCA handlingre-auth at retryre-auth at retryre-auth at retryre-auth

5. Recommend with reasoning

End the analysis with: which patterns to adopt, which to skip, and why for this specific project. Cite the dimensions that drove the call.

## Recommendation for <project>

Adopt:
- Stripe's smart-retry timing (proven at scale, easy via Stripe Billing).
- Recurly-style dunning email cadence (more touchpoints than Stripe; better for our SMB churn profile).

Skip:
- Customer portal self-rescue (we'll wait for v2 — not enough users to justify yet).

Open question for the user:
- Grace period: do we want past_due → readonly access (Stripe default) or past_due → fully-featured for 7 days then suspend? Affects our retention math.

6. Save the research

Write the result to .claude/memory/reference/competitive-analysis-<topic>-<date>.md so future sessions don't re-research the same thing. Add to MEMORY.md.

Output format

## Question
<the user's actual question, refined>

## Context
- Business type:
- Constraints:
- Competitors compared:

## Comparison

[Table — one row per dimension, one column per competitor]

## Patterns worth borrowing
- <pattern A> — used by: <competitors>. Why: <reason>.
- <pattern B> — used by: <competitors>. Why: <reason>.

## Patterns to skip
- <pattern> — used by: <competitor>. Why we don't: <reason>.

## Recommended approach
[2–4 paragraphs. What you'd build, citing competitor patterns by name where you adopted them.]

## Open questions for the user
1. …
2. …

## Sources
- [Stripe docs — Smart Retries](https://...)
- [Recurly engineering blog — Dunning](https://...)
- [HN discussion: SaaS dunning best practices](https://...)

Boundaries

  • Cite every source. No "I read somewhere that …"
  • Never copy product copy, terms-of-service text, or trademarked material. Learn from the approach, write your own copy.
  • Note the date of every source. Stripe-2019 ≠ Stripe-2026.
  • Don't recommend the most popular pattern — recommend the pattern that fits the project's constraints.
  • Don't research private information. Public docs, blog posts, talks, public reviews only.
  • Ask first if the user already has strong preferences; this skill is for when they want input, not when they've decided.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.