The 4-Question Filter That Killed My GitHub Star Habit

I star a lot of repos. Trending page, a newsletter link, whatever shows up mid-search for something unrelated. Almost all of it looks genuinely good. That was never the problem. The problem is "genuinely good" and "belongs in my stack" are two different questions, and starring something answers neither.

One afternoon I stopped starring and started writing verdicts instead. Sixteen repos, one sitting, one sentence each on whether it belonged in my actual setup. Here's the filter that fell out of it.

The stack this was measured against

This only works if I name what I was checking against: OpenClaw, a local multi-agent framework I run on Ollama on a Mac mini M2 with 8GB of RAM (adopted, not something I built), plus Hiring OS, job-search tooling I keep deliberately separate from it. A repo that didn't make the cut here isn't bad. It didn't fit this pairing, on this hardware, that day.

Question 1: reference or dependency?

Six of the sixteen were curated lists, not software: macOS app roundups, a self-hosting guide, a CTO reading list, a GitHub-profile README gallery, a DeepSeek-wiring guide. None of them have a runtime footprint. git clone doesn't apply. They go in a bookmarks folder, not an evaluation queue.

This filter alone saves the most time, because reference-vs-dependency confusion is exactly what turns a watchlist into forty half-read tabs.

Question 2: do I already have this role covered?

Two verdicts here, and they're the ones worth sitting with:

ego-lite      -> browser automation for AI agents
                 already covered by Claude Code's Chrome MCP integration

holaOS        -> multi-agent workspace, shared memory, MCP support
                 verdict: "this is what OpenClaw already is"

Neither verdict is a knock on the tool. Both are probably well-built. The verdict is about redundancy, not quality: running a second tool that does a first tool's job doesn't add capability, it adds maintenance surface and a second thing that can drift out of sync with the first.

The transferable check: before asking if a repo is good, ask if you can name the thing in your current stack that already does its job. One sentence. If you can, you don't need the new repo, you need to pick which of the two you're keeping, and usually that's whichever one is already running.

Question 3: does it fit my actual hardware?

needle   -> 45MB model built for phones/IoT
            different hardware tier entirely, not a worse one

llmfit   -> Rust TUI, benchmarks local LLMs against your hardware
            set aside: my installed Ollama models already cover
            the 8GB-RAM tier it would be scoring

ragflow  -> self-hosted RAG / document-retrieval platform
            not a rejection, see below

llmfit is the interesting one: it's a genuinely useful tool answering a question I'd already independently answered by using the machine every day. Know your actual ceiling (RAM, compute, deployment target) before scoring anything against it in the abstract.

The move most lists skip: "someday, not now"

ragflow gets its own category because it's the easiest verdict to get wrong in either direction. It's a real capability, self-hosted document retrieval, that could plausibly feed a resume-and-document knowledge base into Hiring OS eventually. Installing it immediately felt tempting. Dismissing it entirely felt wrong too.

What I actually wrote: heavy Docker-plus-Elasticsearch platform, worth using eventually, not worth standing up for a use case that's plausible but not active. That's a third option between install-it and reject-it, and it's the one people skip when a tool looks exciting: write down what it's for and why it's waiting, then actually revisit it, instead of force-installing out of FOMO or letting the tab die from neglect.

Question 4: does it solve a problem I have right now?

ToolJet  -> low-code dashboard builder
unsloth  -> local fine-tuning framework (training, not inference,
            and this stack is inference-only)
OpenCut  -> video editor
macro    -> all-in-one team workspace

Four real, capable tools. None solves a problem this stack has. That's the whole verdict, and it says something about the gap in my current setup, not about the tools.

One repo cleared every filter: a technical interview-prep collection, DSA, CS fundamentals, language-specific tracks. Directly useful for a job search I'm in right now, not hypothetically. That's the one install.

The checklist

1. Reference or dependency? No runtime footprint, no evaluation queue, straight to bookmarks.
2. Already covered? Name the thing in your current stack doing this job, one sentence, before judging the new repo.
3. Fits your actual hardware and scale? Not hardware in general. The machine actually in front of you.
4. Solves a problem you have right now? Not one you might have.

Plus the move that isn't really a question: when something's promising but doesn't clear 3 or 4 yet, write down why it's waiting and what would change that. Don't install it out of excitement, don't let it evaporate in a pile of open tabs.

Sixteen repos, one sitting, one install. Every single one of those sixteen looked like real, useful work. That's exactly why the ratio matters: the filtering was the actual decision, made on purpose, instead of by default every time something looked exciting.