The Star Button Is Not a Filing System

The star button is excellent at creating a future problem.

You see a repository. It looks useful. You click the star. The tiny yellow signal says, remember this. Then the next interesting repository arrives, and the next one, and the next one. Eventually the star list becomes a museum of good intentions: 399 repositories, one undifferentiated stream, and no reliable answer to the question “what was I saving this for?”

That was the state of my GitHub stars.

The recent job was not to find more repositories. It was to make the existing collection legible: use the GitHub GraphQL API to obtain structured repository data, let an LLM parse the material, and place the 399 stars into eight custom user lists.

The result is a small piece of information architecture disguised as housekeeping.

A Star Is a Signal, Not a Category

A GitHub star carries one useful fact: at some point, I wanted to come back.

It does not explain why.

The repository might be:

a tool I want to install;
a design reference;
a research rabbit hole;
a project whose architecture I want to borrow;
a library that solves a problem I have not encountered yet;
a strange experiment worth studying for no practical reason at all.

Those are different retrieval intentions, but the star UI stores them as identical events. The collection grows while its meaning decays.

This is the specific kind of clutter an LLM can help with. Not because it possesses a magical understanding of taste, but because the input already contains language: repository names, descriptions, topics, and the surrounding context returned by the API. The model can turn that language into a proposed classification faster than I can reopen 399 tabs and reconstruct my own past decisions.

The Pipeline Was Deliberately Boring

The useful architecture fit into three stages:

GitHub GraphQL
        |
        v
structured repository records
        |
        v
LLM parsing and list assignment
        |
        v
eight custom user lists

The GraphQL API handled collection. It gave the process a consistent source instead of a browser session full of scroll position and partial loading states.

The LLM handled the semantic middle. It read the repository material and proposed which list best represented the reason the project belonged in the collection.

The lists handled retrieval. They became the durable interface between “this looked interesting once” and “this is where I should look when I need that kind of thing.”

There is no need to pretend this is a recommendation engine. It does not predict my future. It performs a bounded organization task over a known set of inputs.

That boundary matters. Give a model an open-ended mandate to “organize my interests” and it will happily invent a taxonomy with twelve poetic layers. Give it eight destinations and 399 records, and the work becomes inspectable.

Why Eight Lists?

Eight is enough room for the collection to express meaningful differences without turning the filing system into another collection to maintain.

Too few lists collapse useful distinctions back into a junk drawer. Too many lists make every classification a debate about edge cases. The point was not to discover the final ontology of software. The point was to create a compact set of doors that I would actually open.

The number also creates a hard constraint for the parser. Every star has to land somewhere useful, and the system cannot escape ambiguity by generating a new category for each unusual repository.

That is the quiet advantage of a fixed taxonomy: disagreement becomes visible. A repository either fits one of the existing intentions or exposes a weakness in the list design. Both outcomes are more useful than a flat pile.

Classification Is Compression

The raw collection contains a lot of text, but most future visits do not need all of it. They need a shortcut.

The eight lists compress several dimensions at once:

Why I saved it. Inspiration, utility, research, or curiosity are not interchangeable.
When I might return. Some stars belong to the next project; others belong to a distant reading queue.
What kind of attention it deserves. A package to evaluate is different from a codebase to study.
What action the collection should enable. Browse, build, compare, or learn.

This is why the output is more valuable than a sorted list of repository names. Sorting changes order. Classification changes what the collection can do.

The LLM did not create knowledge from nothing. It exposed distinctions that were already latent in the descriptions and in the act of starring. The API supplied the raw material; the taxonomy made it retrievable.

The Failure Mode Is False Confidence

Automated organization has a particularly dangerous failure mode: it looks finished.

Eight populated lists feel authoritative. A model can assign every item a category with a cleanly formatted response. Neither fact proves that the categories reflect human intent.

So the correct posture is not “the AI sorted my stars.” It is “the AI produced a first usable map of my stars.”

That distinction keeps the system honest:

the source remains GitHub, not the model’s memory;
the collection size is measurable: 399 inputs;
the taxonomy is explicit: eight lists;
the result can be inspected and corrected without rerunning the entire idea;
a bad classification is a cheap edit, not a philosophical crisis.

The automation earns its keep by reducing the cost of review. It does not remove review from the system.

From Bookmark Graveyard to Workbench

Before this pass, a star mostly meant “future me should remember this.” That is not a workflow. It is a note sent to a person who may no longer remember the sender.

After classification, the same stars have handles. I can enter the list for a specific kind of project instead of searching the entire historical stream. The collection now supports questions such as:

What did I save for the next build?
Which repositories are worth studying rather than installing?
Where are the odd experiments that might unlock a new direction?
Which old stars are still relevant to the way I work now?

The system did not make the stars more impressive. It made them less expensive to revisit.

That is enough.

The Lesson

The web is very good at helping us collect signals and very bad at helping us preserve their meaning.

Every bookmark, star, like, and saved tab is a tiny promise to a future self. Without structure, those promises accumulate interest. Eventually retrieval costs more than the original discovery was worth.

This workflow applied a narrow fix:

399 stars
1 flat inbox
        -> GraphQL collection
        -> LLM-assisted parsing
        -> 8 explicit destinations

No grand knowledge graph. No recommendation theater. Just enough structure to turn a backlog into a workbench.

The star button is still a signal. It is simply no longer the filing system.

Stars Are Not a Strategy: Turning 399 Bookmarks into Eight Working Lists