research-framework

name	research-framework
description	Use when the user asks you to research, evaluate, or compare a programming framework, library, or runtime. Triggers on "research X", "tell me about X framework", "should I use X", "compare X and Y frameworks", "evaluate X".
effort	high

Framework Research

You are conducting a structured technical evaluation of: $ARGUMENTS

Run all web searches in parallel where possible. Produce a report under the headings below. Be precise and dry — no marketing language. Include concrete data (dates, numbers, GitHub stats) wherever possible.

---

Research Steps

1. Identity and Language

Search: "$ARGUMENTS" framework language site:github.com OR site:npmjs.com OR site:pypi.org OR site:pkg.go.dev

• Primary language(s)
• Language version requirements / constraints
• Typing: static / dynamic / optional

2. Age and Maintenance Health

Search: "$ARGUMENTS" framework changelog releases latest Also check: GitHub repo — last commit, release cadence, open vs closed issues ratio, contributor count

• First release date
• Latest stable version + date
• Release cadence (weekly / monthly / sporadic)
• Commit activity last 6 months
• Is there a funded org, CNCF/Apache/Linux Foundation backing, or solo maintainer?
• Any known deprecation or end-of-life signals?

3. Architecture

Search: "$ARGUMENTS" framework architecture internals design

• Core design pattern (MVC, actor model, event loop, etc.)
• Sync vs async / concurrency model; for Go: note goroutine/channel usage, context propagation patterns
• Extension points: plugins, middleware, hooks
• Monolith vs modular / batteries-included vs minimal
• Notable design trade-offs

4. Adoption and Community

Search: "$ARGUMENTS" framework popularity survey latest and check Stack Overflow Developer Survey, State of JS/Python/etc.

• GitHub stars + forks (note trajectory, not just total)
• npm/PyPI/pkg weekly downloads if applicable; for Go: check pkg.go.dev import count and proxy.golang.org stats
• Stack Overflow tag question count
• Mentions in industry surveys (e.g. State of JS, JetBrains survey)
• Notable production users (logos page, case studies)
• Community size: Discord/Slack members, subreddit subscribers

5. Dependencies

Search: "$ARGUMENTS" framework dependencies security vulnerabilities

• Direct dependency count (check package.json / pyproject.toml / go.mod); for Go: note whether it uses Go modules, check go.sum for transitive dep count
• Known heavy or controversial transitive deps
• Supply-chain risk signals: CVE history, abandoned sub-deps
• Bundle size if frontend

6. Alternatives

Search: "$ARGUMENTS" vs [top alternatives] comparison latest Identify 3–5 direct alternatives and build a comparison matrix:

Dimension	$ARGUMENTS	Alt 1	Alt 2	Alt 3
Language
Age
Stars
Perf (relative)
Learning curve
Best fit

---

Output Format

Structure your report with these exact sections:

## $ARGUMENTS — Framework Evaluation

### TL;DR
2–3 sentence verdict: what it's good for, what it's bad for, who should use it.

### Language & Runtime
...

### Age & Maintenance
...

### Architecture
...

### Adoption
...

### Dependencies & Risk
...

### Alternatives
[matrix table]

### Recommendation
When to choose $ARGUMENTS over alternatives. Concrete use-case fit.

### Sources
- [title](url)
- ...

---

Quality Rules

• Cite sources. Every factual claim (stat, date, quote) gets a URL.
• Use numbers. "2.1M weekly downloads" beats "popular".
• Flag uncertainty. If you can't find data for a dimension, say so rather than speculating.
• Avoid vendor docs as the sole source for adoption/maintenance claims — cross-check with neutral sources.
• If $ARGUMENTS is ambiguous (e.g. "Express" could mean Express.js or something else), clarify before researching.