Repo research

Repo Research

Help the user decide whether to use a code repository or package. Deliver a decision, not an essay: be thorough in the investigation, tight in the report.

This is desk research — no cloning, no code execution, just a chat report answering "should I use it?". For the narrower "is it safe to install?" question (sandboxed clone, supply-chain audit, claim verification, install/avoid verdict), hand off to the companion repo-security-check skill if it's installed; otherwise tell the user that deeper pre-install vetting is a separate exercise.

---

Research workflow

Process

1. Identify the target. Accept a GitHub/GitLab URL, an npm/PyPI/crates package name, or a local path, and resolve it to the canonical source repo. If it's a package, find the repo behind it.

2. Gather signals. Fetch the repo page and README, search the web for outside opinions and recent sentiment, and use the gh CLI (gh repo view, gh api) for accurate repo stats — or, if gh is unavailable, the unauthenticated GitHub REST API (https://api.github.com/repos/<owner>/<repo>). If a page is blocked or JS-rendered, use a web-scraping skill if you have one; otherwise note the gap. Collect:

   • What it is — the problem it solves and, briefly, how it works under the hood.
   • Benefits — read past the marketing; separate genuine wins from vendor copy.
   • Maintenance health — version/maturity, stars, release cadence, last commit, open-vs-closed issues, contributor count, single-maintainer vs organization-backed, and license.
   • Alternatives — the 2-3 main competitors and how this one stacks up against them.

3. Tailor the recommendation to this user. A generic answer helps nobody. Pull whatever real context is available before recommending: the current project's manifest and lockfile, any CLAUDE.md/AGENTS.md or docs describing what they're building, and anything they've told you about their stack. If the tool is irrelevant to what they actually do, or their use case is ambiguous, say so and ask one question — don't silently assume a use case.

4. Report using the structure below.

Report structure

## What it is
Plain-language: what it is, the problem it solves, how it works under the hood.

## Real benefits
The genuine wins. Where the marketing oversells, say where the hype softens.

## Honest downsides
Caveats, compatibility limits, maturity gaps, lock-in.

## Maintenance & health
Accurate stats: version, stars, release cadence, last activity, open issues,
who backs it, license.

## Alternatives
2-3 competitors, one line each on the tradeoff vs this repo.

## Recommendation
A clear "use it / use it for X / avoid" call, tailored to the user's context.
Then ONE follow-up question if their use case is genuinely ambiguous.

Principles

• Don't launder claims. If a benefit is marketing-only or you couldn't verify it, label it as such rather than restating it as fact. Weakly-supported or contradicted claims get flagged, not smoothed over.
• Accurate numbers only. Pull stats from gh or the GitHub API, never from memory. Round with ~ when you must (~93k stars); never invent a figure.
• Decision-first. Lead with what matters for the choice. Cut filler.

---

Pre-install security check → use repo-security-check

When the user wants to vet something for safety before installing it — "do a security check", "is this safe to install?", "audit this dependency" — that's a different job: a sandboxed clone, supply-chain audit, and claim verification ending in an install/avoid verdict. Hand off to the companion repo-security-check skill (if installed) rather than doing it here.

---

Optional add-on: community sentiment

If the user wants to know what real users are saying (not just the README), search recent Reddit/HN/X discussion — via a social-research skill if you have one, or plain web search scoped to the last few months. This is an on-request extra, not part of the default report.

---

The report lives in the chat. If the user asks to keep it, save it to a file they choose — never write files unprompted.