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.
npx -y skills add viknesh20-20/claude-code-tool-kit --skill competitive-analysisAssembled 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):
| Domain | Suggested competitors |
|---|---|
| SaaS billing & dunning | Stripe, Recurly, Chargebee, Paddle |
| B2B SaaS workspace + RBAC | Linear, Notion, Slack, Asana |
| CRM | Salesforce, HubSpot, Pipedrive, Close |
| E-commerce checkout | Shopify, Stripe Checkout, BigCommerce, WooCommerce |
| Marketplace fees + payouts | Stripe Connect, Airbnb, Etsy, Uber |
| Customer support | Intercom, Zendesk, HelpScout, Front |
| Project management | Linear, Jira, Asana, Monday |
| ERP financials | NetSuite, SAP, Odoo, Microsoft Dynamics |
| Inventory | Shopify, NetSuite, Cin7, Brightpearl |
| Auth / SSO | Auth0, Clerk, WorkOS, Okta |
| Notifications / engagement | Customer.io, Braze, Iterable, Knock |
| Webhooks / events | Stripe, GitHub, Segment |
| Analytics | Mixpanel, Amplitude, PostHog, Segment |
| Search | Algolia, Elasticsearch, Typesense, Meilisearch |
| Status / incidents | StatusPage, Statuspal, Better Uptime |
3. Research each competitor
For each:
- Read their public docs for the specific feature. Use
firecrawl-scrapeMCP if available. Quote with attribution. - Find dev-blog posts, conference talks, engineering decisions. These reveal why not just what.
- Read 1–2 critical reviews (G2, ProductHunt, Reddit, HN) to find the friction points.
- 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:
| Dimension | Stripe Smart Retries | Recurly | Chargebee | Paddle |
|---|---|---|---|---|
| Retry count | 4 (default) | configurable 1–5 | configurable 1–10 | 3 |
| Retry window | 15 days | 21 days | configurable | 14 days |
| Retry timing | ML-optimized | fixed cadence | fixed/custom | fixed |
| Email cadence | day 1, 3, 7 | day 1, 5, 10, 15 | per template | day 1, 7 |
| Grace period | bills marked past_due | suspend after final retry | configurable | suspend |
| Customer self-rescue | customer_portal | hosted page | hosted page | hosted page |
| Card update prompt | yes, in-product | yes, hosted | yes | yes |
| 3DS / SCA handling | re-auth at retry | re-auth at retry | re-auth at retry | re-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.