Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsBlogPro
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Authors
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges
  • Chrome Extension
  • Skill Manager

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

ProTermsPrivacyRefunds
Back to skills

Comparison Tool Design

ASecurity

Designing side-by-side comparison tools (plan-compare, product-compare, alternative-compare) that help users decide rather than just listing features. Axis selection, default-comparison logic, recommendation discipline. Honest about feature-list-dump (every feature in a row, no decision support), hidden-recommendation (biased comparison pretending to be neutral), and honest-comparison-with-guidance (genuine comparison plus opinionated recommendation) patterns. Triggers on comparison tool, pla...

934 stars
0 votes
0 copies
1 views
Added 9/22/2026
ai-agentsrustgoapisecurity

Works with

cliapi

Security Analysis

A100/100

Pro scans all 11 files and shows the line behind each finding

Scanned 9/22/2026

$npx -y skills add rampstackco/claude-skills --skill comparison-tool-design --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Comparison Tool Design?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Comparison Tool Design
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/rampstackco-comparison-tool-design-4c986e63/badge)](https://www.skillsdirectory.com/skills/rampstackco-comparison-tool-design-4c986e63)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
Files
SKILL.md
---
name: comparison-tool-design
description: "Designing side-by-side comparison tools (plan-compare, product-compare, alternative-compare) that help users decide rather than just listing features. Axis selection, default-comparison logic, recommendation discipline. Honest about feature-list-dump (every feature in a row, no decision support), hidden-recommendation (biased comparison pretending to be neutral), and honest-comparison-with-guidance (genuine comparison plus opinionated recommendation) patterns. Triggers on comparison tool, plan compare, product compare, alternative compare, vs page, decision support tool. Also triggers when conversion through comparison stages is poor, when users are abandoning at the comparison step, or when a comparison tool is being scoped for the first time."
---

# Comparison Tool Design

A senior product marketing director's playbook for designing side-by-side comparison tools that help users decide rather than just listing features. Plan-compare, product-compare, alternative-compare. Axis selection, default-comparison logic, recommendation discipline. The discipline of building a comparison tool that earns the user's trust.

Most comparison tools fail in one of two ways. They dump every feature into a giant grid (4 options × 40 features = 160 cells) and ask the user to weigh everything against everything. The user leaves without choosing. Or they pretend to be neutral comparisons but are actually sales pitches with biased defaults and weighted framing; the user catches the bias and trust collapses.

The comparison tools that work do something different. Genuine like-for-like comparison plus an explicit opinionated recommendation. "For X audience, choose Y." The recommendation is visible, defended, and not the only path; users can override. The tool helps the user decide rather than asking them to decide alone.

The voice is the senior product marketing director who has watched comparison tools double conversion when redesigned with honest recommendations and watched them collapse when feature grids grew without decision support. Practical, opinionated about which axes matter, willing to call out when the comparison is decoration.

When to use this skill: scoping a comparison tool for the first time, auditing a feature-grid comparison that produces no conversion lift, designing recommendation logic that is honest about the recommendation, or deciding which axes earn placement in a comparison tool.

---

## What this skill covers

This skill spans side-by-side comparison tools. The growth-tooling distinctions:

- `calculator-design` is calculators that give a number. This skill is comparing known options.
- `quiz-and-assessment-design` is quizzes that give a category. This skill is comparing options the user already knows about.
- **`comparison-tool-design` (this skill)** is axis selection, default-comparison logic, recommendation engine, filter-and-toggle UX.
- `landing-page-copy` is pricing-page copy; one specific application of comparison tools is the pricing page.
- `content-strategy` is upstream; what topics warrant comparison content.

The audience: product marketers, growth marketers, content marketers running vs-pages and decision-support tooling, agencies running comparison work for clients.

Out of scope: calculator design (covered by `calculator-design`); quiz design (covered by `quiz-and-assessment-design`); the engineering implementation; specific Webflow/Framer/CMS configurations (those stay implementation-side).

---

## The comparison-tool decision: when comparison tools earn investment

Before designing the tool, decide whether a comparison tool is the right answer.

**Comparison tools earn investment when:**

- The audience is at a decision moment between known options (vs unknown options where a quiz or recommendation tool fits better).
- The options have meaningful differences that warrant side-by-side analysis.
- The brand can articulate honest distinctions between options without becoming sales pitch.
- The audience benefits from decision support, not just feature listing.

**Comparison tools do NOT earn investment when:**

- Options are too similar to compare meaningfully.
- The brand cannot make honest distinctions without creating sales-pitch dynamics.
- A simple comparison table or written content would serve.
- The audience does not actually face this decision (manufactured comparisons).

The decision is not "should we have a comparison tool"; it is "is the comparison tool the right tool for this decision."

Detail in [`references/comparison-tool-decision-criteria.md`](references/comparison-tool-decision-criteria.md).

---

## Feature-list-dump vs hidden-recommendation vs honest-comparison-with-guidance

The keystone framing.

**Feature-list-dump.** Every option's every feature in a giant grid. No decision support. The user is asked to weigh 40 cells against each other; most leave without choosing. Cost: design effort wasted on a grid that does not produce decisions; the audience perceives the grid as overwhelming.

**Hidden-recommendation.** "Comparison" tool that is actually a sales pitch. Defaults favor one option; framing weights the answer; the recommendation is invisible but baked in. Trust erodes when users notice the bias. Cost: short-term conversion may look fine; long-term brand damage from "manipulative" reputation.

**Honest-comparison-with-guidance.** Genuine like-for-like comparison plus an explicit opinionated recommendation ("For X audience, choose Y"). The recommendation is visible, defended, and not the only path; users can override. Cost: design effort upfront is significant; conversion typically improves because users feel respected and helped.

The litmus test. Does the tool tell the user what to choose for their specific situation, with reasoning? If yes, honest-comparison-with-guidance. If it dumps features without guidance, feature-list-dump. If it says "the right answer is obviously [our preferred option]" without acknowledgment, hidden-recommendation.

---

## Axis selection: which dimensions matter, which are noise

The single most consequential decision in comparison tool design.

**The principle.** Axes (the rows of the comparison) should be the dimensions that genuinely affect the decision, not every feature available.

**Strong axes.**

- **Decision-relevant capabilities.** Features that materially affect the audience's outcome.
- **Cost dimensions.** Price, total cost of ownership, hidden costs.
- **Constraint dimensions.** Capacity, scale, integration support.
- **Service dimensions.** Support quality, onboarding, SLA.
- **Risk dimensions.** Vendor stability, security, compliance.

**Weak axes.**

- **Marketing checkboxes.** Features that exist on every option; checkmarks across the row.
- **Nice-to-haves.** Features the audience does not actually weigh.
- **Vendor-specific terminology.** Features named differently by each vendor; comparison becomes label confusion.
- **Decoration features.** Features added to the grid because the brand has them and competitors do not.

**The 8-12 axis rule.** Most production comparison tools work well with 8-12 axes. Beyond that, decision paralysis sets in.

Detail in [`references/axis-selection-patterns.md`](references/axis-selection-patterns.md).

---

## Default-comparison logic

Which options compare by default, and why.

**The principle.** Defaults shape the user's first impression. Honest defaults reflect the audience's likely starting point; biased defaults shape conclusions.

**Default options.**

- Audience-fit defaults. The options the audience most commonly considers.
- Stage-fit defaults. The options that match the audience's stage of decision.
- Inferred defaults. Based on referral source, query, or prior interaction.

**Default axes.**

- The axes most relevant to the typical audience.
- Audience can expand to additional axes if interested.

**Bias-flattering defaults.**

- Defaults set so brand always wins on visible axes.
- Defaults that hide axes where competitors win.
- Defaults that frame in brand's terminology.

The discipline. Defaults serve the audience, not the brand. When defaults must reflect brand strength, do so honestly with disclosure.

Detail in [`references/default-comparison-logic.md`](references/default-comparison-logic.md).

---

## Recommendation engine design

When to recommend, how to defend the recommendation.

**The principle.** Comparison tools that recommend are more useful than tools that just list. The recommendation must be defensible.

**Recommendation patterns.**

- **Single recommendation.** "For [audience], choose [option] because [reasons]." Clear; opinionated.
- **Multi-segment recommendation.** "If you are [A], choose X. If you are [B], choose Y." Honest about audience-fit.
- **Conditional recommendation.** "If [factor] matters most, X. If [other factor] matters most, Y." Helps the user decide based on priorities.

**Recommendation defense.**

- The reasoning shown.
- The audience for the recommendation explicit.
- The override path visible.

**Anti-pattern: hidden recommendation.** Tool that defaults to one option's victory through axis selection and framing, without explicit recommendation. Users feel manipulated when they catch the pattern.

Detail in [`references/recommendation-engine-design.md`](references/recommendation-engine-design.md) and [`references/honest-recommendation-discipline.md`](references/honest-recommendation-discipline.md).

---

## Filter and toggle UX

What users can adjust, what should stay fixed.

**Filterable elements.**

- Which options to compare (user adds or removes options).
- Which axes to show (user filters to relevant dimensions).
- Audience or use case (user signals their context; tool adapts).

**Fixed elements.**

- Methodology disclosure (always visible).
- Recommendation reasoning (always findable).
- Source citations (always linkable).

**The filter-fatigue trap.** Too many filters; user paralyzed.

**The under-filtered trap.** Tool too rigid; user cannot match their context.

The discipline. Filters that materially help; not filters for the sake of customization.

Detail in [`references/filter-and-toggle-patterns.md`](references/filter-and-toggle-patterns.md).

---

## Comparison-fatigue patterns

Why most comparisons fail to produce decisions.

**Pattern 1: Too many cells.** 40 features × 5 options = 200 cells; cognitive overload.

**Pattern 2: All-checkmarks rows.** Every option has the feature; the row produces no signal.

**Pattern 3: Inconsistent axis terminology.** Each vendor names features differently; user confused.

**Pattern 4: Hidden costs.** Pricing visible; fees, overage, integrations not surfaced.

**Pattern 5: Apples-to-oranges options.** Comparing genuinely different things; no axis applies cleanly.

**Pattern 6: No recommendation.** Tool lists; user must decide; user does not.

The cumulative effect. The tool produces no decision; users default to the brand they already heard of.

Detail in [`references/comparison-fatigue-patterns.md`](references/comparison-fatigue-patterns.md).

---

## Common failure modes

Rapid-fire. Diagnoses in [`references/common-comparison-failures.md`](references/common-comparison-failures.md).

- "Tool gets traffic; conversion is unchanged." Likely feature-list-dump; no decision support.
- "Sales says competitor leads cite our tool as biased." Hidden-recommendation pattern; trust damage.
- "Mobile users do not engage with the tool." Comparison grids do not work well on mobile; design for it.
- "Power users criticize axis selection." Audience knows these features; tool may have used easy axes rather than decision-relevant.
- "Tool was great at launch; conversion declined over time." Features changed; comparison stale.
- "Audience says 'this is helpful' but does not convert." Recommendation absent or weak; users get information without decision support.
- "Comparison shows every option as 'good' for something." Dilution; no clear recommendation.
- "Adding more features to the comparison reduced conversion." Crossed the cell-count threshold; cognitive overload.

---

## The framework: 12 considerations for comparison tool design

When designing or auditing a comparison tool, walk these 12 considerations.

1. **The comparison-tool decision.** Is a tool the right answer, or does written content serve?
2. **Honest-comparison-with-guidance, not feature-list-dump or hidden-recommendation.** Genuine compare plus opinionated rec.
3. **Axis selection.** 8-12 decision-relevant axes; cut decoration features.
4. **Default-comparison logic.** Honest defaults; not bias-flattering.
5. **Recommendation engine designed.** Visible; defended; not the only path.
6. **Filter and toggle UX.** Filters that help; not filters for customization theater.
7. **Methodology disclosed.** Source data, axis weighting, audience definition.
8. **Mobile parity.** Tool works on the devices the audience uses.
9. **Maintenance discipline.** Comparison stays current as options change.
10. **Honest about competitor strengths.** When competitors win on an axis, say so.
11. **Audience-fit measured.** Per-segment conversion through the tool.
12. **Conversion as success metric.** Not just engagement; downstream choice and retention.

The output of the framework is a comparison tool that earns the user's trust by helping them decide, with recommendation that is honest and defensible.

---

## If required data is unavailable

This skill's output depends on data, measurements, or tool results it cannot generate on its own. When a required input, tool, or data source is unavailable or unverifiable, the sanctioned output is the deliverable with the gap stated: what was needed, what was actually obtained or verified, and which parts of the output are affected. Fabricating, estimating, or interpolating a required number to complete the deliverable is never sanctioned. A stated gap is a complete answer.

---

## Reference files

- [`references/comparison-tool-decision-criteria.md`](references/comparison-tool-decision-criteria.md) - When comparison tools earn the build vs when written content serves.
- [`references/axis-selection-patterns.md`](references/axis-selection-patterns.md) - Strong axes, weak axes, the 8-12 rule.
- [`references/default-comparison-logic.md`](references/default-comparison-logic.md) - Honest defaults vs bias-flattering defaults.
- [`references/recommendation-engine-design.md`](references/recommendation-engine-design.md) - When to recommend, how to defend, override path.
- [`references/filter-and-toggle-patterns.md`](references/filter-and-toggle-patterns.md) - Filterable vs fixed elements; filter-fatigue trap.
- [`references/comparison-fatigue-patterns.md`](references/comparison-fatigue-patterns.md) - Why most comparisons fail to produce decisions.
- [`references/honest-recommendation-discipline.md`](references/honest-recommendation-discipline.md) - The discipline that distinguishes hidden from honest recommendations.
- [`references/comparison-anti-patterns.md`](references/comparison-anti-patterns.md) - The patterns that look like comparisons but degrade trust.
- [`references/common-comparison-failures.md`](references/common-comparison-failures.md) - 8+ failure patterns with diagnoses and cures.

---

## Closing: comparison tools earn the choice when they earn the user's trust

The comparison tools that work as compounding assets are the ones the audience trusts to help them decide. Not because the tool flatters the brand. Not because the tool dumps features. Because the tool genuinely helps the user pick the option that fits their situation, and is honest about which option that is.

That is the bar. Below the bar are feature-list-dump (no decision support; user leaves without choosing) and hidden-recommendation (biased pretending to be neutral; trust collapses when caught). Above the bar are honest-comparison-with-guidance tools where axis selection, default logic, recommendation engine, and filter UX work together to produce decisions the audience trusts.

The discipline is in the design choices. The decision to build a comparison at all. The axes that earn placement. The defaults that serve the audience. The recommendation that is visible and defended. The filters that help the user match their context. The methodology that is disclosed. The maintenance that keeps the comparison current.

Attribution

rampstackcorampstackco
View sourceSee grades on GitHubMore from rampstackco →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Caveman

Terse caveman voice: answer first, fluff gone, every technical fact kept. Use for /caveman, "caveman mode", "talk like caveman", "be brief", "less tokens". Stays on until "stop caveman" or "normal mode".

1100021 votes

Hyperplan

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', ...

698431 votes

Writing Skills

Create and manage Claude Code skills in HASH repository following Anthropic best practices. Use when creating new skills, modifying skill-rules.json, understanding trigger patterns, working with hooks, debugging skill activation, or implementing progressive disclosure. Covers skill structure, YAML frontmatter, trigger types (keywords, intent patterns), UserPromptSubmit hook, and the 500-line rule. Includes validation and debugging with SKILL_DEBUG. Examples include rust-error-stack, cargo-dep...

3931 votes

Mcp Code Execution

Routes multi-tool workflows through MCP servers for large datasets and pipelines. Use when Bash tool overhead is limiting throughput on data-heavy tasks.

3421 votes

catchup

Recovers the conversation and failed tool calls of a previous Codex, Amp, Claude Code, Antigravity, Cline, Copilot CLI, Cursor, DeepSeek Harness, Grok Build, Kimi, OpenCode, Pi Agent, or ZCode session. Use when the user says "catch up", "what did the last session do", "get me up to speed", "I switched agents", asks to recover/summarize a previous session before continuing, or asks to diagnose or report a catchup failure. Do NOT use for the current conversation, git history, or any non-agent log.

741 votes
View all in ai-agents →