| name | competitor-feature-research |
| description | Research new features shipped by other React and Vue component libraries over a given time period and compare them against Mantine to find gaps and divergences. Use when the user wants competitive analysis of UI libraries, to track what competitors added recently, to find missing Mantine features, or asks things like "what did MUI/Chakra/Ant add since X", "what features are we missing", "compare our components to competitors", "feature gap analysis". Operates from the Mantine monorepo. |
Competitor Feature Research
Overview
Scan a curated set of actively-maintained React and Vue component libraries for features
they shipped within a time window (from their changelogs / release notes / commits), distill
the genuinely new features, then compare each against Mantine's current implementation and
bucket it as Have, Missing, or Different. The end product is an actionable report
for the Mantine team.
The library list (website + GitHub repo for each) lives in
references/libraries.md. Read it at the start of every run.
Inputs (resolve before starting)
- Time period — the window to scan. If the user gives a date or range, use it. If not,
default to the last 30 days and state the assumption. Accept forms like "since 2026-04-01",
"last 3 months", "since the last Mantine release".
- Library scope — which libraries to scan. Default to all React libraries in
references/libraries.md (closest comparison). Include Vue libraries only if the user asks
for them or for "all libraries" — Vue features map by idea, not 1:1. Honor explicit subsets
("just MUI and Chakra").
If the period is ambiguous and the user is reachable, ask one short clarifying question;
otherwise proceed with the 30-day default.
Workflow
Run these steps in order. For more than ~3 libraries, parallelize step 2–3 with subagents
(see "Parallelizing").
Step 1 — Scope
- Read references/libraries.md.
- Resolve the time period to a concrete
SINCE date (YYYY-MM-DD).
- Pick the target repos. Skip the "Dormant / avoid" ones unless asked.
Step 2 — Gather raw data (per library)
Prefer GitHub Releases. Run the bundled script:
scripts/fetch_releases.sh <owner/repo> <SINCE-YYYY-MM-DD>
It prints every release published on/after SINCE as markdown. Fallback order if it returns
nothing (some repos don't cut GitHub Releases):
- CHANGELOG file — fetch from the repo, e.g.
gh api repos/<owner>/<repo>/contents/CHANGELOG.md --jq '.content' | base64 -d
(Naive UI uses CHANGELOG.en-US.md; Chakra uses .changelog/*.mdx).
- Commit history —
gh api "repos/<owner>/<repo>/commits?since=<SINCE>T00:00:00Z" --paginate --jq '.[].commit.message' | head -200. Read commit subjects for feat: / "add" entries.
- Docs "What's new"/releases page — WebFetch the site's releases/changelog URL from
references/libraries.md as a last resort.
Per-package monorepos (MUI, Fluent UI, Chakra, React Spectrum) tag many releases — focus on the
core/umbrella package and ignore satellite packages (icons, codemods, docs).
Step 3 — Distill features
From the raw notes, extract only genuinely new capabilities. For each, capture: the
component/area, a one-line description, the source (version/PR link), and a link to the
competitor's component documentation page (the specific component page, e.g.
https://www.heroui.com/docs/components/empty-state, not the site root). Construct it from the
library's website base in references/libraries.md following that site's component URL pattern;
if unsure of the exact slug, link the site's components index. This doc link is required for every
feature so the Mantine team can quickly see the competitor's implementation.
KEEP: new components, new props/APIs, new variants/modes, new behaviors, new hooks, notable
accessibility or theming capabilities.
DROP: bug fixes, performance tweaks, internal refactors, type-only fixes, dependency bumps,
docs/website changes, CI/build changes, deprecations (note these separately if notable).
This "new features only" filter mirrors how the Mantine changelog itself is curated.
Step 4 — Compare against Mantine
For each distilled feature, find the equivalent Mantine surface and decide the bucket. Search
the local monorepo (this is the Mantine repo):
- Components:
packages/@mantine/core/src/components/<Name>/ (~110 components).
Extensions live in packages/@mantine/{dates,charts,form,tiptap,carousel,dropzone,notifications,modals,spotlight,nprogress,code-highlight}/src.
- Hooks:
packages/@mantine/hooks/src/use-*.
- Docs (best for props & behaviors):
apps/mantine.dev/src/pages/core/*.mdx,
.../hooks/*.mdx, .../x/*.mdx, .../dates/*.mdx, .../form/*.mdx, .../charts/*.mdx.
Practical method per feature:
- Map the competitor component to the nearest Mantine component (e.g. MUI
Autocomplete →
Mantine Autocomplete/Combobox; Ant Segmented → Mantine SegmentedControl).
grep/read that component's source and its .mdx docs to check whether the specific
prop/behavior exists.
- Assign a bucket:
- Have — Mantine already supports it (cite the prop/component).
- Missing — no Mantine equivalent (the actionable gap).
- Different — Mantine solves the same need a different way (name both approaches, e.g.
"they ship a
<DatePicker presets> prop; Mantine expects custom renderDay/controls").
When unsure, prefer Different over Missing and say what you checked — false "missing"
claims waste the team's time.
Step 5 — Report
Write the report to a markdown file at:
./claude/competitor-feature-research/<TODAY>-report.md
where <TODAY> is the run date in YYYY-MM-DD form (the date the scan is run, not SINCE).
Create the ./claude/competitor-feature-research/ directory if it doesn't exist; overwrite an
existing same-day report. Use the template in "Report format". Lead with the Missing items
grouped across libraries — that's the highest-value output — then per-library detail. After
writing, tell the user the file path and give a 2–3 line summary of the top gaps.
Parallelizing
For a full scan (10+ React libraries), dispatch one subagent per library (or per small group)
to do steps 2–4, then synthesize their structured results in step 5. Give each subagent:
- the
owner/repo, website, and SINCE date,
- the path to
scripts/fetch_releases.sh,
- the Mantine search paths above and the bucket definitions,
- a request to return a compact structured list:
feature | component | bucket | evidence | competitor doc link.
This keeps the heavy changelog text out of the main context. See the
superpowers:dispatching-parallel-agents skill for mechanics.
Report format
# Competitor feature scan — <SINCE> to <today>
Libraries scanned: <list>. Period: <window>.
## Missing in Mantine (prioritized gaps)
- **<Feature>** ([<Library> docs](<competitor-component-doc-url>)) — <one line>. Seen in: <Library vX.Y> (<PR/link>). Nearest Mantine surface: <component or "none">.
- ...
## Implemented differently
- **<Feature>** ([<Library> docs](<competitor-component-doc-url>)) — Them: <approach>. Mantine: <approach>. Component: <name>.
- ...
## Already covered (spot-check)
- **<Feature>** ([<Library> docs](<competitor-component-doc-url>)) — Mantine has it via <prop/component>.
## Per-library detail
### <Library> (<versions in window>)
| Feature | Component | Bucket | Evidence | Competitor docs |
| ------- | --------- | ---------------------- | ----------------- | ---------------------------------------- |
| ... | ... | Have/Missing/Different | <prop or PR link> | [<component>](<competitor-doc-url>) |
Every feature row/bullet must include a link to the competitor's component documentation page
(e.g. a new HeroUI Meter links to its HeroUI docs page). Link the component index page if the
exact component slug can't be confirmed.
Notes
- Verify
owner/repo paths if a fetch returns nothing — orgs rename (see references/libraries.md).
- This is research, not implementation. Don't change Mantine source; produce findings the team
can act on.
- Keep the run reproducible: always state the exact
SINCE date and library list used.