Methodology — Gap Hunter Labs

How an investigation runs

The same method applies to a slow IDE, a vulnerable dependency and a crash in a platform tracker. Each step leaves something that can be checked.

Find the gap. Start from evidence someone can point to: a freeze report, a published advisory, a crash in a tracker, a check that no tool makes. Reproduce it on the exact version where it happens.
Understand the cause. Follow it to the code that causes it: the method that spends the time, the dependency version inside an advisory’s affected range, the iteration that is not synchronized. Keep the reproduction as a test or a check that anyone can run again.
Build the fix. Ship the smallest change that removes the cause, with evidence before and after: a pull request upstream, a report to the maintainers, or a plugin when the fix belongs outside the platform.

Results are published with their source (the ticket, the pull request, the report or the test) and with their real status: an open pull request is shown as open, and a fix that the maintainers made in a different way is described as theirs. See the engineering evidence.

Assurance, confidentiality and limits

For a security or engineering lead deciding whether to rely on this work, the method holds to five commitments on every engagement.

Root cause, not symptoms. Every finding is traced to the exact code, dependency version or configuration that causes it, and reproduced on the version where it happens.
Evidence you can re-run. Each finding ships with a measurement, a stack trace or a test, and a before-and-after for anything that gets a fix.
Ranked by real exposure. Findings are ordered by actual exposure, not by raw CVSS score, and anything exploitable is reported first and privately through your security channel.
No inflated findings. Results carry their real status; the work reports what it finds and does not claim that no other issue exists.
Read-only and confidential. A review is read-only, so nothing is pushed to your code; your code and data stay confidential, and signing your NDA is fine.

How a plugin gets greenlit

A focused plugin moves forward only when each public, evidence-based question has a clear answer.

Catalog figures

Every number on this page (downloads, pricing, rating, first-published date, GitHub ★) comes straight from JetBrains Marketplace and GitHub's own public data. Nothing here is estimated or made up.

Growth compares each plugin's current downloads with the earliest data point recorded for it, not with the last refresh of this page. That's why the baseline date under the % differs from plugin to plugin. A plugin without an earlier data point shows "—" instead of a guess.

A plugin marked Pending was recently submitted to Marketplace and is still in moderation: the listing exists but isn't indexed for search yet. That's the normal review time, not a problem with the plugin.

The Gap / The Fix

The Gap is the cited evidence that the plugin was needed: a documented pattern of complaints about an existing tool (reviews, ratings, recurring bug reports).

The Fix is the plugin's own published description of what it does. Neither side is embellished, and every claim traces back to something you can check in public.

What's Never Stored Here

A competitor's private marketplace identifiers or a vendor's personal contact details (email, phone, address) are never published, even when the public API this catalog reads from exposes them next to the data it uses.

"Visitors today" counts visits with GoatCounter, which uses no cookies, stores no IP address and can't identify individual visitors. It counts sessions, not raw pageviews, so reloading this page or browsing several sections doesn't inflate the number.