Use competitors for alternative pages, direct comparisons, or lists of viable options. Unlike competitor research, this task turns verified information into decision guidance. Readers should understand when switching makes sense and when their existing solution may remain the better fit.
Install and invoke
Run this in your project terminal to install only this skill for Claude Code:
npx skills add coreyhaines31/marketingskills --skill competitors -a claude-code
Node.js and npx must be available. For Codex, replace -a claude-code with -a codex. In the agent conversation, explicitly ask it to use competitors and supply your material. The installation command belongs in the terminal, not in your content brief.
Establish the reader’s decision
Supply your product context, current competitor documentation and pricing, and the tasks readers care about. A migration page needs existing pain points, transfer capabilities, and reconfiguration work. An early-stage options page needs selection criteria and several genuine alternatives.
Example brief:
Use competitors to draft a comparison between our product and Tool B.
Read profiles/. The audience is a five-person design team comparing external-client feedback and total cost.
Verify capabilities and billing assumptions first, then explain when each product is the better fit.
Date every price. Leave unknowns visible and do not invent switching testimonials.
Do not require every comparison row to declare your product the winner. Start with a short explanation of the important differences, then organize detail by the reader’s work. Tables support scanning; paragraphs explain why conditions matter, such as whether guests are billed or an integration requires a higher plan.
Make the comparison checkable
Calculate prices for the same team size, billing period, and usage assumptions. State whether additional costs are included and do not guess missing quotes. Keep the original URL and check date for important claims. Present competitor strengths accurately. An individual review supports that reviewer’s reported experience, not a universal conclusion.
In the migration section, distinguish transferable data, settings that must be rebuilt, training requirements, and support your company actually provides. Do not describe switching as effortless when capabilities are missing. Store shared competitor facts centrally so a pricing update can reach every related page.
Before publication, ask whether a reader unfamiliar with your company can identify the best-fit conditions, find supporting evidence, and understand the work involved in the next step. Demand and ranking opportunities require separate investigation. A coherent comparison structure does not by itself justify generating a large collection of similar pages.
Choose the page by search intent, not by swapping a title
“Alternative to X” usually concerns leaving X; “X vs Y” compares two known candidates; a list of alternatives needs actual options and a decision framework. Ask the skill to name the page format and the reader’s stage before drafting. Do not clone one feature table into several URLs with only the competitor name changed.
Begin with a decision scenario, such as a ten-person team moving from its current tool. Which features do they actually use? How much data must move? Which integrations and budget limits are non-negotiable? Build two or three dimensions that change the choice and explain when your product is a better fit and when the other one is. A pricing comparison needs billing units, necessary add-ons, and the date checked. If you have not used a competing product, mark experience claims as based on public documentation.
During review, remove “we win on everything” conclusions and check that prose agrees with the table. Ask a colleague unfamiliar with the product to make a decision from the page. Can they find conditions where your product is not suitable, a migration next step, and the underlying sources? If not, the page needs more research before publication.
Example: write an alternatives page for someone migrating
Suppose readers are leaving a project-management tool and care most about retaining attachments and permissions. You have public documentation for three candidate products and an approved migration-test record. Ask the skill: “Use competitors for an ‘alternatives to X’ page. Begin with three checks a migrating team must make, then compare import scope, permission mapping, and price for three real options, with source dates. Recommend by team situation and give a next test. Do not rank us first under every condition.”
Have a colleague use the draft to answer: Can existing data be imported? What may require manual rebuilding? Is price per seat or per project? If the page cannot answer, obtain documentation or remove unsupported checkmarks. A common failure is a table filled with green ticks that leaves migration risk invisible. Replace it with explanations of boundaries and a practical trial checklist.
Include alternatives beyond competing software
A buyer may compare another product, a spreadsheet, an internal build, or doing nothing. For each real option, record who it suits, its main cost, switching friction, and verifiable feature differences. An independent implementation plan compared AssetShark with asset-management software and spreadsheets rather than claiming universal superiority. It is a page-planning example, not a finished comparison or switching result. Verify current features and prices before publication.