Claude Skill

suede-competitors

Suede-owned comparison-page discipline for honest alternative, versus, and competitor-comparison content that serves evaluators and search intent. Use when planning or writing a public page that positions products against named alternatives from verified evidence. NOT FOR: gather

LLM Mart · 0 points · 18 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download JasonColapietro-suede-creator-skills-skills_suede-competitors-f192517.zip · 14 KB
Part of jasoncolapietro/suede-creator-skills — 70 skills

Install

skills CLI npx skills add https://github.com/JasonColapietro/suede-creator-skills/tree/main/skills/suede-competitors
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install jasoncolapietro-suede-creator-skills@llmmart
Git git clone https://github.com/JasonColapietro/suede-creator-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole jasoncolapietro/suede-creator-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Suede Competitor and Alternative Pages

Use this Suede comparison-page playbook to serve competitive search intent while keeping every product claim current, sourced, and fair.

Initial Assessment

Check for .agents/product-marketing.md (or .claude/product-marketing.md, or the legacy product-marketing-context.md) and read it if present — your value proposition, ICP, pricing model, and honest weaknesses decide which comparisons are even defensible, and they are usually already written down there.

Then work the intake list under Task-Specific Questions below; ask only what the context file did not already answer. Current competitor evidence — pricing, features, ratings — comes from suede-competitor-profiling, not from memory.


Page Formats

Format 1: [Competitor] Alternative (Singular)

Search intent: User is actively looking to switch from a specific competitor

URL pattern: /alternatives/[competitor] or /[competitor]-alternative

Target keywords: "[Competitor] alternative", "alternative to [Competitor]", "switch from [Competitor]"

Page structure:

  1. Why people look for alternatives (validate their pain)
  2. Summary: You as the alternative (quick positioning)
  3. Detailed comparison (features, service, pricing)
  4. Who should switch (and who shouldn't)
  5. Migration path
  6. Social proof from switchers
  7. CTA

Format 2: [Competitor] Alternatives (Plural)

Search intent: User is researching options, earlier in journey

URL pattern: /alternatives/[competitor]-alternatives

Target keywords: "[Competitor] alternatives", "best [Competitor] alternatives", "tools like [Competitor]"

Page structure:

  1. Why people look for alternatives (common pain points)
  2. What to look for in an alternative (criteria framework)
  3. List of alternatives (you first, but include real options)
  4. Comparison table (summary)
  5. Detailed breakdown of each alternative
  6. Recommendation by use case
  7. CTA

Important: Include 4-7 real alternatives. Being genuinely helpful builds trust and ranks better.

AI-answer expectations by stage: these pages can earn citations in AI answers, but whether AI recommends your brand from them also depends on offsite consensus (reviews, forums, analysts). For emerging brands, a self-ranked list may surface competitors while the brand receives only a citation. Treat that as a hypothesis and route current visibility evidence and claim validation to suede-seo-audit.


Format 3: You vs [Competitor]

Search intent: User is directly comparing you to a specific competitor

URL pattern: /vs/[competitor] or /compare/[you]-vs-[competitor]

Target keywords: "[You] vs [Competitor]", "[Competitor] vs [You]"

Page structure:

  1. TL;DR summary (key differences in 2-3 sentences)
  2. At-a-glance comparison table
  3. Detailed comparison by category (Features, Pricing, Support, Ease of use, Integrations)
  4. Who [You] is best for
  5. Who [Competitor] is best for (be honest)
  6. What customers say (testimonials from switchers)
  7. Migration support
  8. CTA

Format 4: [Competitor A] vs [Competitor B]

Search intent: User comparing two competitors (not you directly)

URL pattern: /compare/[competitor-a]-vs-[competitor-b]

Page structure:

  1. Overview of both products
  2. Comparison by category
  3. Who each is best for
  4. The third option (introduce yourself)
  5. Comparison table (all three)
  6. CTA

Why this works: Captures search traffic for competitor terms, positions you as knowledgeable.


Cliches to Refuse

A comparison page written on autopilot arrives with these already in it. Each one tells an evaluator the page is marketing, not research — refuse them by name:

  • The strawman competitor. A weakness stated as caricature ("clunky", "built for 2015") rather than a specific, sourced limitation a user would actually hit.
  • A "Winner" row. No verdict row, no trophy, no score-out-of-10 that resolves to you. The reader decides; the page supplies evidence.
  • Fake balance. "They're great for enterprise, we're great for everyone else" concedes nothing. A real concession names a case where the competitor is the better buy for a reader you want.
  • A table where every row favors you. If the dimensions were chosen honestly, some rows go the other way. If none do, the dimensions were chosen to win, not to inform.

For the two remaining defaults — the ✓/✗ feature table and a migration section with no real friction — use the concrete before/after in references/templates.md: "Comparison Table Best Practices" and "Migration Section".


Essential Sections

TL;DR Summary

Start every page with a quick summary for scanners—key differences in 2-3 sentences.

Paragraph Comparisons

Go beyond tables. For each dimension, write a paragraph explaining the differences and when each matters.

Feature Comparison

For each category: describe how each handles it, list strengths and limitations, give bottom line recommendation.

Pricing Comparison

Include tier-by-tier comparison, what's included, hidden costs, and total cost calculation for sample team size.

Who It's For

Be explicit about ideal customer for each option. Honest recommendations build trust.

Every page names at least one dimension where the competitor genuinely wins and the reader should not switch — sourced like any other claim, with a URL and a checked date. Not a hedge ("some teams prefer..."), a concession: the specific reader, the specific reason. A page with no such dimension is not finished; it means the comparison was scoped to guarantee the answer.

Migration Section

Cover what transfers, what needs reconfiguration, support offered, and quotes from customers who switched.

For detailed templates: See references/templates.md


Content Architecture

Centralized Competitor Data

Create a single source of truth for each competitor with:

  • Positioning and target audience
  • Pricing (all tiers)
  • Feature ratings
  • Strengths and weaknesses
  • Best for / not ideal for
  • Common complaints (from reviews)
  • Migration notes

For data structure and examples: See references/content-architecture.md


Research Process

Deep Competitor Research

For each competitor, gather:

  1. Product research: Sign up, use it, document features/UX/limitations
  2. Pricing research: Current pricing, what's included, hidden costs
  3. Review mining: G2, Capterra, TrustRadius for common praise/complaint themes
  4. Customer feedback: Talk to customers who switched (both directions)
  5. Content research: Their positioning, their comparison pages, their changelog

Ongoing Updates

  • Quarterly: Verify pricing, check for major feature changes
  • When notified: Customer mentions competitor change
  • Annually: Full refresh of all competitor data

SEO Considerations

Keyword Targeting

Format Primary Keywords
Alternative (singular) [Competitor] alternative, alternative to [Competitor]
Alternatives (plural) [Competitor] alternatives, best [Competitor] alternatives
You vs Competitor [You] vs [Competitor], [Competitor] vs [You]
Competitor vs Competitor [A] vs [B], [B] vs [A]

Internal Linking

  • Link between related competitor pages
  • Link from feature pages to relevant comparisons
  • Create hub page linking to all competitor content

Schema Markup

Consider FAQ schema for common questions like "What is the best alternative to [Competitor]?"


Before You Hand It Over

Boundaries below requires a final claim review before any comparison page ships. This is that review — run it as a second pass over the finished draft, not while drafting:

  1. Re-read every claim about a competitor: pricing, tier contents, feature availability, ratings, review counts, testimonials, headcount, funding.
  2. Each one carries a source URL and the date you checked it. A claim without both is cut, or explicitly marked unverified in the page — never softened into hedged prose ("reportedly", "many users find", "known for"). Hedging an unsourced claim keeps the claim and loses the accountability.
  3. Anything sourced more than a quarter ago gets re-checked before publication, not carried forward. Pricing pages move.
  4. Claims about your own live visibility or how AI answers cite the page are not verifiable from here — route those to suede-seo-audit.

Output Format

Three deliverables, all with their schemas in the references — do not invent a shape for them:

  • Competitor data file — the centralized per-competitor record; structure in references/content-architecture.md.
  • Page content — URL, meta tags, full copy by section, tables, CTAs; section templates in references/templates.md.
  • Page set plan — which pages to create, in priority order by search volume and evidence readiness.

Task-Specific Questions

  1. What are common reasons people switch to you?
  2. Do you have customer quotes about switching?
  3. What's your pricing vs. competitors?
  4. Do you offer migration support?

Boundaries

  • Do not invent, cherry-pick, or present stale competitor claims, prices, features, testimonials, or rankings as current fact.
  • Do not publish, deploy, index, or update comparison pages without explicit authorization and a final claim review.
  • Do not use competitor trademarks in a way that implies affiliation or reuse protected creative assets without rights.
  • Do not decide that an option is universally best; state audience, criteria, tradeoffs, sources, and checked dates.

Routing

  • Need current competitor evidence -> use suede-competitor-profiling.
  • Need review-mining or forum synthesis for the "common complaints" and switching-reason sections -> use suede-customer-research.
  • Need scaled comparison-page architecture -> use suede-programmatic-seo.
  • Need final page copy or organic QA -> use suede-copy or suede-seo-audit.
  • Need internal battle cards -> use suede-sales-enablement.
  • From those skills, route honest public alternative and versus-page composition back to suede-competitors.
Files (suede-creator-skills)
  • agents
    • openai.yaml 521 B
      interface:
        display_name: "Suede Competitor Pages"
        short_description: "Write comparison and alternative pages that rank and convert"
        default_prompt: "Use $suede-competitors on [target]. The user wants a versus page, alternative page, or competitor comparison for search and sales. Work through page formats, claim discipline, and honest framing, ground every recommendation in evidence the user can check, and return the decisions, the reasoning, and what to measure next."
      policy:
        allow_implicit_invocation: true
      
  • evals
    • evals.json 6.5 KB
      {
        "skill_name": "suede-competitors",
        "evals": [
          {
            "id": 1,
            "prompt": "Create a 'Best Asana Alternatives' page for our project management tool. We compete mainly on price (we're $8/user vs their $24/user) and simplicity (they've become bloated). Target audience is small teams (5-20 people).",
            "expected_output": "Should check for product-marketing.md first. Should identify this as the plural alternatives format ([Competitor] Alternatives). Should include the essential sections: TL;DR comparison, brief paragraphs on each alternative (including the user's product positioned first or prominently), feature comparison table, pricing comparison, who each alternative is best for. Should use the modular content architecture approach. Should address SEO considerations for the target keyword 'Asana alternatives.' Should position the user's product with the stated differentiators (price, simplicity).",
            "assertions": [
              "Checks for product-marketing.md",
              "Identifies as plural alternatives format",
              "Includes TL;DR comparison section",
              "Includes feature comparison table",
              "Includes pricing comparison",
              "Includes 'who it's best for' per alternative",
              "Positions user's product prominently with differentiators",
              "Addresses SEO for target keyword"
            ],
            "files": []
          },
          {
            "id": 2,
            "prompt": "Write a 'HubSpot vs Salesforce' comparison page. We're HubSpot and want to show why we're the better choice for SMBs.",
            "expected_output": "Should identify this as the 'you vs competitor' format. Should include structured comparison sections: overview of both, feature-by-feature comparison, pricing comparison, pros/cons of each, who each is best for, and migration path. Should be factually accurate about the competitor while strategically positioning the user's product. Should include a TL;DR at the top. Should address the SMB angle throughout. Should use the centralized competitor data architecture pattern.",
            "assertions": [
              "Identifies as 'you vs competitor' format",
              "Includes structured comparison sections",
              "Includes feature-by-feature comparison",
              "Includes pricing comparison",
              "Includes TL;DR at the top",
              "Factually accurate about competitor",
              "Strategically positions user's product for SMBs",
              "Includes migration path or switching section"
            ],
            "files": []
          },
          {
            "id": 3,
            "prompt": "we need a page targeting 'mailchimp alternative' (singular). we're an email marketing platform focused on e-commerce brands.",
            "expected_output": "Should trigger on casual phrasing. Should identify this as the singular alternative format ([Competitor] Alternative — positioning your product as THE alternative). Should focus the entire page on why the user's product is the best Mailchimp alternative for e-commerce. Should include: why people switch from Mailchimp, what the user's product does better (e-commerce specific features), feature comparison, pricing comparison, migration guide, customer testimonials. Should optimize for the singular keyword 'Mailchimp alternative.'",
            "assertions": [
              "Triggers on casual phrasing",
              "Identifies as singular alternative format",
              "Focuses on user's product as THE alternative",
              "Includes why people switch from Mailchimp",
              "Highlights e-commerce-specific advantages",
              "Includes feature and pricing comparison",
              "Includes migration guide",
              "Optimizes for singular keyword"
            ],
            "files": []
          },
          {
            "id": 4,
            "prompt": "Can you create a comparison page for 'Notion vs Coda'? We're a third-party review site, not affiliated with either product.",
            "expected_output": "Should identify this as the 'competitor vs competitor' format (third-party perspective). Should maintain objectivity since the user isn't either product. Should include balanced comparison: overview of both, feature comparison, pricing, pros/cons, use case recommendations. Should use the essential page sections from the skill. Should suggest how to monetize the page (affiliate links, CTA to the user's own product if relevant). Should address SEO for the 'Notion vs Coda' keyword.",
            "assertions": [
              "Identifies as 'competitor vs competitor' format",
              "Maintains objectivity (third-party perspective)",
              "Includes balanced feature comparison",
              "Includes pricing comparison",
              "Includes use case recommendations",
              "Addresses SEO considerations",
              "Suggests monetization approach"
            ],
            "files": []
          },
          {
            "id": 5,
            "prompt": "We want to build a whole competitor comparison hub. We have 5 main competitors and want to create alternative pages for each, plus head-to-head comparisons. How should we structure this?",
            "expected_output": "Should apply the centralized competitor data architecture. Should recommend a hub structure with: individual alternative pages for each competitor (5 singular pages), a 'best alternatives' roundup page, head-to-head comparison pages for key matchups. Should address internal linking strategy between these pages. Should recommend the research process for gathering competitive data. Should address URL structure and site architecture for the hub.",
            "assertions": [
              "Applies centralized competitor data architecture",
              "Recommends hub structure with multiple page types",
              "Suggests individual and roundup alternative pages",
              "Addresses internal linking between comparison pages",
              "Recommends research process for competitive data",
              "Addresses URL structure"
            ],
            "files": []
          },
          {
            "id": 6,
            "prompt": "I need to create a battle card for our sales team comparing us to Zendesk. It should help reps handle competitive objections during sales calls.",
            "expected_output": "Should recognize this as internal sales enablement material, not a public comparison page. Should defer to or cross-reference suede-sales-enablement, which handles battle cards, objection handling docs, and internal competitive collateral. May provide some competitive positioning advice but should make clear that suede-sales-enablement is the right skill for internal sales materials.",
            "assertions": [
              "Recognizes this as internal sales enablement material",
              "References or defers to suede-sales-enablement",
              "Does not attempt to create internal battle card using public comparison page patterns"
            ],
            "files": []
          }
        ]
      }
      
  • references
    • content-architecture.md 7.4 KB
      # Content Architecture for Competitor Pages
      
      How to structure and maintain competitor data for scalable comparison pages.
      
      ## Contents
      - Centralized Competitor Data
      - Competitor Data Template
      - Your Product Data
      - Page Generation
      - Index Page Structure (alternatives index, vs comparisons index, index page best practices)
      - Footer Navigation
      
      ## Centralized Competitor Data
      
      Create a single source of truth for each competitor:
      
      ```
      competitor_data/
      ├── notion.md
      ├── airtable.md
      ├── monday.md
      └── ...
      ```
      
      ---
      
      ## Competitor Data Template
      
      Per competitor, document:
      
      ```yaml
      name: Notion
      website: notion.so
      tagline: "The all-in-one workspace"
      founded: 2016
      headquarters: San Francisco
      
      # Positioning
      primary_use_case: "docs + light databases"
      target_audience: "teams wanting flexible workspace"
      market_position: "premium, feature-rich"
      
      # Pricing
      pricing_model: per-seat
      free_tier: true
      free_tier_limits: "limited blocks, 1 user"
      starter_price: $8/user/month
      business_price: $15/user/month
      enterprise: custom
      
      # Features (rate 1-5 or describe)
      features:
        documents: 5
        databases: 4
        project_management: 3
        collaboration: 4
        integrations: 3
        mobile_app: 3
        offline_mode: 2
        api: 4
      
      # Strengths (be honest)
      strengths:
        - Extremely flexible and customizable
        - Beautiful, modern interface
        - Strong template ecosystem
        - Active community
      
      # Weaknesses (be fair)
      weaknesses:
        - Can be slow with large databases
        - Learning curve for advanced features
        - Limited automations compared to dedicated tools
        - Offline mode is limited
      
      # Best for
      best_for:
        - Teams wanting all-in-one workspace
        - Content-heavy workflows
        - Documentation-first teams
        - Startups and small teams
      
      # Not ideal for
      not_ideal_for:
        - Complex project management needs
        - Large databases (1000s of rows)
        - Teams needing robust offline
        - Enterprise with strict compliance
      
      # Common complaints (from reviews)
      common_complaints:
        - "Gets slow with lots of content"
        - "Hard to find things as workspace grows"
        - "Mobile app is clunky"
      
      # Migration notes
      migration_from:
        difficulty: medium
        data_export: "Markdown, CSV, HTML"
        what_transfers: "Pages, databases"
        what_doesnt: "Automations, integrations setup"
        time_estimate: "1-3 days for small team"
      ```
      
      ---
      
      ## Your Product Data
      
      Same structure for yourself—be honest:
      
      ```yaml
      name: [Your Product]
      # ... same fields
      
      strengths:
        - [Your real strengths]
      
      weaknesses:
        - [Your honest weaknesses]
      
      best_for:
        - [Your ideal customers]
      
      not_ideal_for:
        - [Who should use something else]
      ```
      
      ---
      
      ## Page Generation
      
      Each page pulls from centralized data:
      
      - **[Competitor] Alternative page**: Pulls competitor data + your data
      - **[Competitor] Alternatives page**: Pulls competitor data + your data + other alternatives
      - **You vs [Competitor] page**: Pulls your data + competitor data
      - **[A] vs [B] page**: Pulls both competitor data + your data
      
      **Benefits**:
      - Update competitor pricing once, updates everywhere
      - Add new feature comparison once, appears on all pages
      - Consistent accuracy across pages
      - Easier to maintain at scale
      
      ---
      
      ## Index Page Structure
      
      ### Alternatives Index
      
      **URL**: `/alternatives` or `/alternatives/index`
      
      **Purpose**: Lists all "[Competitor] Alternative" pages
      
      **Page structure**:
      1. Headline: "[Your Product] as an Alternative"
      2. Brief intro on why people switch to you
      3. List of all alternative pages with:
         - Competitor name/logo
         - One-line summary of key differentiator vs. that competitor
         - Link to full comparison
      4. Common reasons people switch (aggregated)
      5. CTA
      
      **Example**:
      ```markdown
      ## Explore [Your Product] as an Alternative
      
      Looking to switch? See how [Your Product] compares to the tools you're evaluating:
      
      - **[Notion Alternative](/alternatives/notion)** — Better for teams who need [X]
      - **[Airtable Alternative](/alternatives/airtable)** — Better for teams who need [Y]
      - **[Monday Alternative](/alternatives/monday)** — Better for teams who need [Z]
      ```
      
      ---
      
      ### Vs Comparisons Index
      
      **URL**: `/vs` or `/compare`
      
      **Purpose**: Lists all "You vs [Competitor]" and "[A] vs [B]" pages
      
      **Page structure**:
      1. Headline: "Compare [Your Product]"
      2. Section: "[Your Product] vs Competitors" — list of direct comparisons
      3. Section: "Head-to-Head Comparisons" — list of [A] vs [B] pages
      4. Brief methodology note
      5. CTA
      
      ---
      
      ### Index Page Best Practices
      
      **Keep them updated**: When you add a new comparison page, add it to the relevant index.
      
      **Internal linking**:
      - Link from index → individual pages
      - Link from individual pages → back to index
      - Cross-link between related comparisons
      
      **SEO value**:
      - Index pages can rank for broad terms like "project management tool comparisons"
      - Pass link equity to individual comparison pages
      - Help search engines discover all comparison content
      
      **Sorting options**:
      - By popularity (search volume)
      - Alphabetically
      - By category/use case
      - By date added (show freshness)
      
      **Include on index pages**:
      - Last updated date for credibility
      - Number of pages/comparisons available
      - Quick filters if you have many comparisons
      
      ---
      
      ## Footer Navigation
      
      The site footer appears on all marketing pages, making it a powerful internal linking opportunity for competitor pages.
      
      ### Option 1: Link to Index Pages (Minimum)
      
      At minimum, add links to your comparison index pages in the footer:
      
      ```
      Footer
      ├── Compare
      │   ├── Alternatives →  /alternatives
      │   └── Comparisons →  /vs
      ```
      
      This ensures every marketing page passes link equity to your comparison content hub.
      
      ### Option 2: Footer Columns by Format (Recommended for SEO)
      
      For stronger internal linking, create dedicated footer columns for each format you've built, linking directly to your top competitors:
      
      ```
      Footer
      ├── [Product] vs               ├── Alternatives to            ├── Compare
      │   ├── vs Notion              │   ├── Notion Alternative     │   ├── Notion vs Airtable
      │   ├── vs Airtable            │   ├── Airtable Alternative   │   ├── Monday vs Asana
      │   ├── vs Monday              │   ├── Monday Alternative     │   ├── Notion vs Monday
      │   ├── vs Asana               │   ├── Asana Alternative      │   ├── ...
      │   ├── vs Clickup             │   ├── Clickup Alternative    │   └── View all →
      │   ├── ...                    │   ├── ...                    │
      │   └── View all →             │   └── View all →             │
      ```
      
      **Guidelines**:
      - Include up to 8 links per column (top competitors by search volume)
      - Add "View all" link to the full index page
      - Only create columns for formats you've actually built pages for
      - Prioritize competitors with highest search volume
      
      ### Why Footer Links Matter
      
      1. **Sitewide distribution**: Footer links appear on every marketing page, passing link equity from your entire site to comparison content
      2. **Crawl efficiency**: Search engines discover all comparison pages quickly
      3. **User discovery**: Visitors evaluating your product can easily find comparisons
      4. **Competitive positioning**: Signals to search engines that you're a key player in the space
      
      ### Implementation Notes
      
      - Update footer when adding new high-priority comparison pages
      - Keep footer clean—don't list every comparison, just the top ones
      - Match column headers to your URL structure (e.g., "vs" column → `/vs/` URLs)
      - Consider mobile: columns may stack, so order by priority
      
    • templates.md 5.3 KB
      # Section Templates for Competitor Pages
      
      Ready-to-use templates for each section of competitor comparison pages.
      
      ## Contents
      - TL;DR Summary
      - Paragraph Comparison (Not Just Tables)
      - Feature Comparison Section
      - Pricing Comparison Section
      - Service & Support Comparison
      - Who It's For Section
      - Migration Section
      - Social Proof Section
      - Comparison Table Best Practices (beyond checkmarks, organize by category, include ratings where useful)
      
      ## TL;DR Summary
      
      Start every page with a quick summary for scanners:
      
      ```markdown
      **TL;DR**: [Competitor] excels at [strength] but struggles with [weakness].
      [Your product] is built for [your focus], offering [key differentiator].
      Choose [Competitor] if [their ideal use case]. Choose [You] if [your ideal use case].
      ```
      
      ---
      
      ## Paragraph Comparison (Not Just Tables)
      
      For each major dimension, write a paragraph:
      
      ```markdown
      ## Features
      
      [Competitor] offers [description of their feature approach].
      Their strength is [specific strength], which works well for [use case].
      However, [limitation] can be challenging for [user type].
      
      [Your product] takes a different approach with [your approach].
      This means [benefit], though [honest tradeoff].
      Teams who [specific need] often find this more effective.
      ```
      
      ---
      
      ## Feature Comparison Section
      
      Go beyond checkmarks:
      
      ```markdown
      ## Feature Comparison
      
      ### [Feature Category]
      
      **[Competitor]**: [2-3 sentence description of how they handle this]
      - Strengths: [specific]
      - Limitations: [specific]
      
      **[Your product]**: [2-3 sentence description]
      - Strengths: [specific]
      - Limitations: [specific]
      
      **Bottom line**: Choose [Competitor] if [scenario]. Choose [You] if [scenario].
      ```
      
      ---
      
      ## Pricing Comparison Section
      
      ```markdown
      ## Pricing
      
      | | [Competitor] | [Your Product] |
      |---|---|---|
      | Free tier | [Details] | [Details] |
      | Starting price | $X/user/mo | $X/user/mo |
      | Business tier | $X/user/mo | $X/user/mo |
      | Enterprise | Custom | Custom |
      
      **What's included**: [Competitor]'s $X plan includes [features], while
      [Your product]'s $X plan includes [features].
      
      **Total cost consideration**: Beyond per-seat pricing, consider [hidden costs,
      add-ons, implementation]. [Competitor] charges extra for [X], while
      [Your product] includes [Y] in base pricing.
      
      **Value comparison**: For a 10-person team, [Competitor] costs approximately
      $X/year while [Your product] costs $Y/year, with [key differences in what you get].
      ```
      
      ---
      
      ## Service & Support Comparison
      
      ```markdown
      ## Service & Support
      
      | | [Competitor] | [Your Product] |
      |---|---|---|
      | Documentation | [Quality assessment] | [Quality assessment] |
      | Response time | [SLA if known] | [Your SLA] |
      | Support channels | [List] | [List] |
      | Onboarding | [What they offer] | [What you offer] |
      | CSM included | [At what tier] | [At what tier] |
      
      **Support quality**: Based on [G2/Capterra reviews, your research],
      [Competitor] support is described as [assessment]. Common feedback includes
      [quotes or themes].
      
      [Your product] offers [your support approach]. [Specific differentiator like
      response time, dedicated CSM, implementation help].
      ```
      
      ---
      
      ## Who It's For Section
      
      ```markdown
      ## Who Should Choose [Competitor]
      
      [Competitor] is the right choice if:
      - [Specific use case or need]
      - [Team type or size]
      - [Workflow or requirement]
      - [Budget or priority]
      
      **Ideal [Competitor] customer**: [Persona description in 1-2 sentences]
      
      ## Who Should Choose [Your Product]
      
      [Your product] is built for teams who:
      - [Specific use case or need]
      - [Team type or size]
      - [Workflow or requirement]
      - [Priority or value]
      
      **Ideal [Your product] customer**: [Persona description in 1-2 sentences]
      ```
      
      ---
      
      ## Migration Section
      
      ```markdown
      ## Switching from [Competitor]
      
      ### What transfers
      - [Data type]: [How easily, any caveats]
      - [Data type]: [How easily, any caveats]
      
      ### What needs reconfiguration
      - [Thing]: [Why and effort level]
      - [Thing]: [Why and effort level]
      
      ### Migration support
      
      We offer [migration support details]:
      - [Free data import tool / white-glove migration]
      - [Documentation / migration guide]
      - [Timeline expectation]
      - [Support during transition]
      
      ### What customers say about switching
      
      > "[Quote from customer who switched]"
      > — [Name], [Role] at [Company]
      ```
      
      ---
      
      ## Social Proof Section
      
      Focus on switchers:
      
      ```markdown
      ## What Customers Say
      
      ### Switched from [Competitor]
      
      > "[Specific quote about why they switched and outcome]"
      > — [Name], [Role] at [Company]
      
      > "[Another quote]"
      > — [Name], [Role] at [Company]
      
      ### Results after switching
      - [Company] saw [specific result]
      - [Company] reduced [metric] by [amount]
      ```
      
      ---
      
      ## Comparison Table Best Practices
      
      ### Beyond Checkmarks
      
      Instead of:
      | Feature | You | Competitor |
      |---------|-----|-----------|
      | Feature A | ✓ | ✓ |
      | Feature B | ✓ | ✗ |
      
      Do this:
      | Feature | You | Competitor |
      |---------|-----|-----------|
      | Feature A | Full support with [detail] | Basic support, [limitation] |
      | Feature B | [Specific capability] | Not available |
      
      ### Organize by Category
      
      Group features into meaningful categories:
      - Core functionality
      - Collaboration
      - Integrations
      - Security & compliance
      - Support & service
      
      ### Include Ratings Where Useful
      
      | Category | You | Competitor | Notes |
      |----------|-----|-----------|-------|
      | Ease of use | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | [Brief note] |
      | Feature depth | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | [Brief note] |
      
  • CARD.md 4.4 KB
    # Skill Card — Suede Competitor and Alternative Pages
    
    <!-- Generated by scripts/build-skill-cards.mjs — do not hand-edit. -->
    <!-- Regenerate with: npm run build:cards -->
    
    Release record for the `suede-competitors` skill, following the NVIDIA skill-card template (<https://docs.nvidia.com/skills/skill-cards>). It tells a reviewer what the skill does, who owns it, what it needs, what could go wrong, and what evidence backs the release — without requiring them to open the source first.
    
    ## Description
    
    Suede-owned comparison-page discipline for honest alternative, versus, and competitor-comparison content that serves evaluators and search intent.
    
    Status: production. Ships in the `suede-skills` plugin (the full pack) at release 0.19.0; loads as a Claude Code / Codex agent skill from this directory's [SKILL.md](./SKILL.md).
    
    ## Owner
    
    Jason Colapietro, Suede Labs AI (<https://github.com/JasonColapietro>). Security contact: `info@suedeai.ai` per [SECURITY.md](../../SECURITY.md).
    
    ## License / Terms of Use
    
    MIT ([LICENSE](../../LICENSE)). The pack's combined license expression is `MIT AND BSD-3-Clause`; this skill bundles no third-party licensed material of its own.
    
    ## Use Case
    
    Target users: developers and creators running the skill inside a Claude Code or Codex CLI session.
    
    Use when planning or writing a public page that positions products against named alternatives from verified evidence.
    
    Out of scope — gathering the underlying competitor evidence (use suede-competitor-profiling), internal battle cards (use suede-sales-enablement), or scaled page generation (use suede-programmatic-seo).
    
    ## Deployment Geography
    
    Global. The skill is a prompt-and-script package that runs locally inside the invoking agent session; it pins no region-specific service of its own.
    
    ## Requirements / Dependencies
    
    - A Claude Code or Codex CLI session with the `suede-skills` plugin installed (install options: <https://skills.suedeai.ai/>).
    - Bundled files loaded relative to this directory: `agents/` (1 file), `references/` (2 files).
    - Credentials: none are bundled or required by the skill files. Any tool or API credentials come from the host session; never paste credentials into skill files, prompts, or outputs.
    
    ## Known Risks and Mitigations
    
    - Risk: an agent treats a quality gate as autonomous authority. Mitigation: every gate in the pack is advisory — it changes what is reported, never what the user decided; only extreme-risk findings (data loss, credential exposure, legal/rights violations, payment mistakes, irreversible public damage) pause for the user's explicit choice.
    - Risk: a skill instruction is used to act outside its mandate. Mitigation: the hard limits in the skill body's "Boundaries" section, quoted below.
    
    From "Boundaries":
    
    - Do not invent, cherry-pick, or present stale competitor claims, prices, features, testimonials, or rankings as current fact.
    - Do not publish, deploy, index, or update comparison pages without explicit authorization and a final claim review.
    - Do not use competitor trademarks in a way that implies affiliation or reuse protected creative assets without rights.
    - Do not decide that an option is universally best; state audience, criteria, tradeoffs, sources, and checked dates.
    
    ## References
    
    - Skill source: [`skills/suede-competitors/SKILL.md`](./SKILL.md)
    - Rendered reference page: <https://skills.suedeai.ai/skills/suede-competitors.html>
    - Security policy and reviewed scanner exceptions: [SECURITY.md](../../SECURITY.md) and [`.plugin-scanner.toml`](../../.plugin-scanner.toml) at the repo root
    
    ## Skill Output
    
    Structured Markdown returned in the agent's response, shaped by the output contract defined in the skill body: "Output Format". The skill publishes, posts, and sends nothing without the user's explicit authorization; delivery decisions stay with the user.
    
    ## Skill Version
    
    0.19.0 — the pack is single-versioned, so every skill releases together; see [VERSION](../../VERSION) and [CITATION.cff](../../CITATION.cff) for the release identifier this card describes.
    
    ## Ethical Considerations
    
    - The skill produces recommendations for a human decision-maker. Publishing, sending, payment, and rights decisions stay with the user.
    - Its gates require verifiable claims and honest reporting; do not use the skill to fabricate claims, evidence, metrics, or attribution.
    - Report suspected misuse or a security concern privately per [SECURITY.md](../../SECURITY.md); do not open a public issue for it.
    
  • SKILL.md 10.7 KB
    ---
    name: suede-competitors
    description: "Suede-owned comparison-page discipline for honest alternative, versus, and competitor-comparison content that serves evaluators and search intent. Use when planning or writing a public page that positions products against named alternatives from verified evidence. NOT FOR: gathering the underlying competitor evidence (use suede-competitor-profiling), internal battle cards (use suede-sales-enablement), or scaled page generation (use suede-programmatic-seo)."
    metadata:
      version: 2.0.1
    ---
    
    # Suede Competitor and Alternative Pages
    
    Use this Suede comparison-page playbook to serve competitive search intent while keeping every product claim current, sourced, and fair.
    
    ## Initial Assessment
    
    Check for `.agents/product-marketing.md` (or `.claude/product-marketing.md`, or the legacy `product-marketing-context.md`) and read it if present — your value proposition, ICP, pricing model, and honest weaknesses decide which comparisons are even defensible, and they are usually already written down there.
    
    Then work the intake list under Task-Specific Questions below; ask only what the context file did not already answer. Current competitor evidence — pricing, features, ratings — comes from `suede-competitor-profiling`, not from memory.
    
    ---
    
    ## Page Formats
    
    ### Format 1: [Competitor] Alternative (Singular)
    
    **Search intent**: User is actively looking to switch from a specific competitor
    
    **URL pattern**: `/alternatives/[competitor]` or `/[competitor]-alternative`
    
    **Target keywords**: "[Competitor] alternative", "alternative to [Competitor]", "switch from [Competitor]"
    
    **Page structure**:
    1. Why people look for alternatives (validate their pain)
    2. Summary: You as the alternative (quick positioning)
    3. Detailed comparison (features, service, pricing)
    4. Who should switch (and who shouldn't)
    5. Migration path
    6. Social proof from switchers
    7. CTA
    
    ---
    
    ### Format 2: [Competitor] Alternatives (Plural)
    
    **Search intent**: User is researching options, earlier in journey
    
    **URL pattern**: `/alternatives/[competitor]-alternatives`
    
    **Target keywords**: "[Competitor] alternatives", "best [Competitor] alternatives", "tools like [Competitor]"
    
    **Page structure**:
    1. Why people look for alternatives (common pain points)
    2. What to look for in an alternative (criteria framework)
    3. List of alternatives (you first, but include real options)
    4. Comparison table (summary)
    5. Detailed breakdown of each alternative
    6. Recommendation by use case
    7. CTA
    
    **Important**: Include 4-7 real alternatives. Being genuinely helpful builds trust and ranks better.
    
    **AI-answer expectations by stage**: these pages can earn *citations* in AI answers, but whether AI *recommends* your brand from them also depends on offsite consensus (reviews, forums, analysts). For emerging brands, a self-ranked list may surface competitors while the brand receives only a citation. Treat that as a hypothesis and route current visibility evidence and claim validation to `suede-seo-audit`.
    
    ---
    
    ### Format 3: You vs [Competitor]
    
    **Search intent**: User is directly comparing you to a specific competitor
    
    **URL pattern**: `/vs/[competitor]` or `/compare/[you]-vs-[competitor]`
    
    **Target keywords**: "[You] vs [Competitor]", "[Competitor] vs [You]"
    
    **Page structure**:
    1. TL;DR summary (key differences in 2-3 sentences)
    2. At-a-glance comparison table
    3. Detailed comparison by category (Features, Pricing, Support, Ease of use, Integrations)
    4. Who [You] is best for
    5. Who [Competitor] is best for (be honest)
    6. What customers say (testimonials from switchers)
    7. Migration support
    8. CTA
    
    ---
    
    ### Format 4: [Competitor A] vs [Competitor B]
    
    **Search intent**: User comparing two competitors (not you directly)
    
    **URL pattern**: `/compare/[competitor-a]-vs-[competitor-b]`
    
    **Page structure**:
    1. Overview of both products
    2. Comparison by category
    3. Who each is best for
    4. The third option (introduce yourself)
    5. Comparison table (all three)
    6. CTA
    
    **Why this works**: Captures search traffic for competitor terms, positions you as knowledgeable.
    
    ---
    
    ## Cliches to Refuse
    
    A comparison page written on autopilot arrives with these already in it. Each one
    tells an evaluator the page is marketing, not research — refuse them by name:
    
    - **The strawman competitor.** A weakness stated as caricature ("clunky", "built for 2015") rather than a specific, sourced limitation a user would actually hit.
    - **A "Winner" row.** No verdict row, no trophy, no score-out-of-10 that resolves to you. The reader decides; the page supplies evidence.
    - **Fake balance.** "They're great for enterprise, we're great for everyone else" concedes nothing. A real concession names a case where the competitor is the better buy for a reader you want.
    - **A table where every row favors you.** If the dimensions were chosen honestly, some rows go the other way. If none do, the dimensions were chosen to win, not to inform.
    
    For the two remaining defaults — the ✓/✗ feature table and a migration section with no real friction — use the concrete before/after in [references/templates.md](references/templates.md): "Comparison Table Best Practices" and "Migration Section".
    
    ---
    
    ## Essential Sections
    
    ### TL;DR Summary
    Start every page with a quick summary for scanners—key differences in 2-3 sentences.
    
    ### Paragraph Comparisons
    Go beyond tables. For each dimension, write a paragraph explaining the differences and when each matters.
    
    ### Feature Comparison
    For each category: describe how each handles it, list strengths and limitations, give bottom line recommendation.
    
    ### Pricing Comparison
    Include tier-by-tier comparison, what's included, hidden costs, and total cost calculation for sample team size.
    
    ### Who It's For
    Be explicit about ideal customer for each option. Honest recommendations build trust.
    
    Every page names at least one dimension where the competitor genuinely wins and
    the reader should not switch — sourced like any other claim, with a URL and a
    checked date. Not a hedge ("some teams prefer..."), a concession: the specific
    reader, the specific reason. A page with no such dimension is not finished; it
    means the comparison was scoped to guarantee the answer.
    
    ### Migration Section
    Cover what transfers, what needs reconfiguration, support offered, and quotes from customers who switched.
    
    **For detailed templates**: See [references/templates.md](references/templates.md)
    
    ---
    
    ## Content Architecture
    
    ### Centralized Competitor Data
    Create a single source of truth for each competitor with:
    - Positioning and target audience
    - Pricing (all tiers)
    - Feature ratings
    - Strengths and weaknesses
    - Best for / not ideal for
    - Common complaints (from reviews)
    - Migration notes
    
    **For data structure and examples**: See [references/content-architecture.md](references/content-architecture.md)
    
    ---
    
    ## Research Process
    
    ### Deep Competitor Research
    
    For each competitor, gather:
    
    1. **Product research**: Sign up, use it, document features/UX/limitations
    2. **Pricing research**: Current pricing, what's included, hidden costs
    3. **Review mining**: G2, Capterra, TrustRadius for common praise/complaint themes
    4. **Customer feedback**: Talk to customers who switched (both directions)
    5. **Content research**: Their positioning, their comparison pages, their changelog
    
    ### Ongoing Updates
    
    - **Quarterly**: Verify pricing, check for major feature changes
    - **When notified**: Customer mentions competitor change
    - **Annually**: Full refresh of all competitor data
    
    ---
    
    ## SEO Considerations
    
    ### Keyword Targeting
    
    | Format | Primary Keywords |
    |--------|-----------------|
    | Alternative (singular) | [Competitor] alternative, alternative to [Competitor] |
    | Alternatives (plural) | [Competitor] alternatives, best [Competitor] alternatives |
    | You vs Competitor | [You] vs [Competitor], [Competitor] vs [You] |
    | Competitor vs Competitor | [A] vs [B], [B] vs [A] |
    
    ### Internal Linking
    - Link between related competitor pages
    - Link from feature pages to relevant comparisons
    - Create hub page linking to all competitor content
    
    ### Schema Markup
    Consider FAQ schema for common questions like "What is the best alternative to [Competitor]?"
    
    ---
    
    ## Before You Hand It Over
    
    Boundaries below requires a final claim review before any comparison page ships.
    This is that review — run it as a second pass over the finished draft, not while
    drafting:
    
    1. Re-read every claim about a competitor: pricing, tier contents, feature
       availability, ratings, review counts, testimonials, headcount, funding.
    2. Each one carries a source URL and the date you checked it. A claim without
       both is **cut, or explicitly marked unverified in the page** — never softened
       into hedged prose ("reportedly", "many users find", "known for"). Hedging an
       unsourced claim keeps the claim and loses the accountability.
    3. Anything sourced more than a quarter ago gets re-checked before publication,
       not carried forward. Pricing pages move.
    4. Claims about your own live visibility or how AI answers cite the page are not
       verifiable from here — route those to `suede-seo-audit`.
    
    ---
    
    ## Output Format
    
    Three deliverables, all with their schemas in the references — do not invent a
    shape for them:
    
    - **Competitor data file** — the centralized per-competitor record; structure in [references/content-architecture.md](references/content-architecture.md).
    - **Page content** — URL, meta tags, full copy by section, tables, CTAs; section templates in [references/templates.md](references/templates.md).
    - **Page set plan** — which pages to create, in priority order by search volume and evidence readiness.
    
    ---
    
    ## Task-Specific Questions
    
    1. What are common reasons people switch to you?
    2. Do you have customer quotes about switching?
    3. What's your pricing vs. competitors?
    4. Do you offer migration support?
    
    ---
    
    ## Boundaries
    
    - Do not invent, cherry-pick, or present stale competitor claims, prices, features, testimonials, or rankings as current fact.
    - Do not publish, deploy, index, or update comparison pages without explicit authorization and a final claim review.
    - Do not use competitor trademarks in a way that implies affiliation or reuse protected creative assets without rights.
    - Do not decide that an option is universally best; state audience, criteria, tradeoffs, sources, and checked dates.
    
    ## Routing
    
    - Need current competitor evidence -> use `suede-competitor-profiling`.
    - Need review-mining or forum synthesis for the "common complaints" and switching-reason sections -> use `suede-customer-research`.
    - Need scaled comparison-page architecture -> use `suede-programmatic-seo`.
    - Need final page copy or organic QA -> use `suede-copy` or `suede-seo-audit`.
    - Need internal battle cards -> use `suede-sales-enablement`.
    - From those skills, route honest public alternative and versus-page composition back to `suede-competitors`.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related