agentleFS
bedomaxbedomax/webdesigner-agent/.claude/skills/competitive-research/SKILL.md

competitive-research

Skill1 starsChanged 4 months agoMITView on GitHub

Competitor and reference site research. Use when the user shares competitor names, company references, or site URLs to analyze — audits their UX, design, SEO, and conversion strategy, and documents benchmarks in the issue's spec folder.

5 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    All competitive research lives inside the spec folder of the related issue:

    line 12
  2. Distinctive:

    If no issue exists yet, create it first so the folder has its number.

    line 23
  3. Very specific:

    When the user gives only a company name, search for their site first, and also search "<company>" reviews and site:<domain> patterns for …

    line 38
  4. Distinctive:

    If a site can't be fetched, say so and work from search results and cached descriptions — never fabricate observations.

    line 72

“Common” is measured: kept by at least 6 in 10 of the 4 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Competitive Research

Analyze competitor and reference sites to inform design, SEO, and conversion decisions. References are input for judgment — we learn from them, we don't copy them.

Output Location (strict)

All competitive research lives inside the spec folder of the related issue:

/specs/<issue-number>-<slug>/
  spec.md
  research/
    competitive-analysis.md   # full analysis
    references.md             # quick notes on user-provided references
  • Written in English, like all documentation.
  • If no issue exists yet, create it first so the folder has its number.
  • Reference the analysis from spec.md (sections 2–3).

How to Research a Competitor/Reference Site

For each site the user provides (or that you discover), inspect with WebFetch/WebSearch:

  1. Positioning: headline and value proposition on the home page — what do they promise, to whom?
  2. Conversion strategy: primary CTA, form length and placement, lead magnets, pricing transparency, trust signals used (testimonials, logos, numbers, guarantees).
  3. Information architecture: main nav structure, page types they invest in (services, cases, blog, tools), depth of the funnel.
  4. Design language: layout patterns, typography feel, color usage, imagery style, density — what impression does it create?
  5. SEO signals: title/meta patterns, heading structure, structured data (view page source), blog cadence and topics, keywords they target in URLs and H1s.
  6. Performance impression: obviously heavy pages, render-blocking behavior, mobile experience.
  7. Gaps and weaknesses: what they do poorly or ignore — that's our opportunity.

When the user gives only a company name, search for their site first, and also search "<company>" reviews and site:<domain> patterns for extra context.

competitive-analysis.md structure

# Competitive Analysis: <topic>
> Issue: #<number> · Sites analyzed: N · Date: YYYY-MM-DD

## Summary (the 5 takeaways that change our decisions)

## Per-Competitor Breakdown
### <Competitor> — <url>
- Positioning:
- Conversion strategy: (CTA, forms, trust signals)
- IA & content investment:
- Design language:
- SEO approach:
- Strengths / Weaknesses:

## Pattern Table (what everyone does vs what nobody does)
| Pattern | Comp A | Comp B | Comp C | Our decision |
|---|---|---|---|---|

## Opportunities (gaps we can exploit)
## Anti-patterns (what NOT to copy, and why)
## Impact on This Issue (specific decisions this research changes)

Analysis Discipline

  • Evidence over vibes: cite what you actually saw on the page ("hero has a 2-field form above the fold"), not generic claims.
  • Differentiate, don't imitate: identify table-stakes patterns (must have) vs differentiation opportunities (should differ).
  • Tie every takeaway to a decision: research that doesn't change spec.md is noise — the "Impact on This Issue" section is mandatory.
  • Respect the law and ethics: analyze public pages only; never scrape private areas or misrepresent yourself.
  • If a site can't be fetched, say so and work from search results and cached descriptions — never fabricate observations.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.