competitive-teardown
Skill0 starsChanged 4 months agoMITView on GitHub
Produce a structured competitive teardown of a SaaS/tech product — pricing model, feature matrix, positioning, ICP, GTM motion, and defensibility gaps. Use whenever the user asks to "research a competitor", "compare us to X", "what's [product]'s pricing", "build a battlecard", "how does [company] position itself", or wants a repeatable framework for evaluating competing products rather than a one-off summary. Also trigger when the user is deciding whether to build a feature that a competitor already ships and needs a build-vs-differentiate read.
10 other projects use a version of this.
Adopted by
Most recently taken up by
- darkweb19/skillstheir own version, first seen Nov 8, 2026
- brittanyslay/marketing-skillstheir own version, first seen Nov 5, 2026
- tderoussel/agent-skillstheir own version, first seen Oct 20, 2026
- Bellistri-Nick/ProductManagerCompetitiveAnalysistheir own version, first seen Oct 13, 2026
- scayver/marketing-skillstheir own version, first seen Oct 13, 2026
- 25andresbernal/claude-skillstheir own version, first seen Sep 24, 2026
Other versions10 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 10
- Hassaan146/claude-skills★ 18same name
- scayver/marketing-skills★ 8same name
- Bellistri-Nick/ProductManagerCompetitiveAnalysis★ 2same name
- Hussain-Elfalah/Agentic-Skills★ 2same name
- mahiunfiltered/claude-code-skills★ 1same name
- tderoussel/agent-skills★ 1same name
- 25andresbernal/claude-skills★ 0same name
- andfrancot-alt/claude-skills★ 0same name
- brittanyslay/marketing-skills★ 0same name
- darkweb19/skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository6 other files it gives its agents.
- changelog-generatorSkill
- frontend-component-auditSkill
- github-readme-generatorSkill
- meeting-action-itemsSkill
- resume-tailorSkill
- sec-filing-analyzerSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 10 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
Before researching, confirm with the user (or infer from context) which of these is the goal — it changes what to prioritize:
- Distinctive: line 44
Don't pad the feature matrix to look thorough — a 6-row matrix of things that matter beats a 30-row matrix of things that don't
- Distinctive: line 45
Don't present competitor marketing copy as fact — a "leading platform" claim on their homepage is a claim, not a finding
- Distinctive: line 46
Don't skip the vulnerability section — a teardown without a wedge is just a book report
“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Competitive Teardown
A repeatable framework for turning scattered competitor research (pricing pages, changelogs, reviews, job postings) into a decision-ready teardown — not just a summary of what a company does.
Why a framework instead of ad-hoc research
Ad-hoc competitor research tends to produce feature lists without a point of view. This skill forces four questions that actually drive decisions: who they're really selling to, how they make money, what's structurally hard to copy, and where they're vulnerable.
Workflow
Step 1: Scope the teardown
Before researching, confirm with the user (or infer from context) which of these is the goal — it changes what to prioritize:
- Battlecard (sales enablement) → weight objection-handling and pricing comparison heavily
- Build-vs-differentiate (product decision) → weight feature depth and technical moat
- Positioning research (marketing/messaging) → weight ICP, messaging, and channel strategy
- Investor/market mapping → weight funding, team size signals, and market share proxies
Step 2: Gather in this order
- Pricing page — tiers, per-seat vs. usage-based, what's gated behind "Contact Sales" (that gate itself is a signal of ICP — enterprise-only features hide there)
- Product docs / changelog — most reliable signal of what they're actually investing in right now, more honest than the marketing site
- Job postings (via web search on "[company] careers") — engineering job posts reveal tech stack and what they're building next; GTM job posts reveal which segment they're expanding into
- Reviews (G2, Capterra) — mine for recurring complaints, not just star ratings; complaints are your differentiation opportunities
- Recent news/funding — runway and strategic pressure shape how aggressively they'll respond to competition
Step 3: Structure the output using the standard teardown template
See references/teardown-template.md for the full section-by-section template. Core sections:
- One-paragraph thesis (what they are, in one sentence a prospect would use)
- Pricing & packaging breakdown
- Feature matrix (only include rows that are actually differentiating — a matrix of 40 checkmarks is noise)
- ICP & positioning read
- Strengths that are structurally defensible vs. strengths that are just "shipped first"
- Vulnerabilities / wedge opportunities
- Recommendation (specific to the scope chosen in Step 1)
Step 4: Separate fact from inference
Explicitly label which claims are sourced (with links) vs. inferred (e.g., "pricing page doesn't list enterprise pricing → likely $50K+ ACV based on comparable gated-pricing SaaS patterns"). Decision-makers need to know which parts of the teardown to trust vs. verify further.
Anti-patterns to avoid
- Don't pad the feature matrix to look thorough — a 6-row matrix of things that matter beats a 30-row matrix of things that don't
- Don't present competitor marketing copy as fact — a "leading platform" claim on their homepage is a claim, not a finding
- Don't skip the vulnerability section — a teardown without a wedge is just a book report
Reference
references/teardown-template.md— full markdown template with section prompts
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.