You remember starring a repository that solved a specific problem. You do not remember the name, owner, or programming language. GitHub's starred page now contains a few thousand candidates.

That is not one search problem. It is at least four:

  1. finding exact words in repository metadata
  2. searching concepts that appear only in the README
  3. recovering the private reason you saved something
  4. describing an idea when you no longer remember the original vocabulary

A useful GitHub Stars manager should support each case instead of putting every query through the same AI box.

Start with exact metadata search

Repository name, owner, description, language, and Topics form the cheapest index. They are compact, easy to update, and usually enough for known-item searches.

Examples:

  • sqlite swift
  • owner:pointfreeco
  • language:Rust
  • topic:local-first

Exact search should be the first layer because it is deterministic. You can see why a result matched, and it works without an embedding provider or model call.

Its limitation is equally clear: metadata is written for public discovery, not for your memory. A repository description may say “durable execution engine” while you remember “background job retries.”

Index README content for implementation details

The README contains the vocabulary that repository cards omit:

  • supported databases and platforms
  • configuration keys
  • API and command names
  • architectural terms
  • limitations and migration notes
  • examples of the problem the project solves

Full-text README search is especially useful for questions such as:

  • “Which starred project mentioned sqlite-vec?”
  • “Where did I see an URLProtocol test example?”
  • “Which queue supports cron and retries?”

The index should store enough context to show a relevant snippet. A result that says only “README matched” still forces you to reopen every candidate.

README indexing also needs failure handling. Repositories can rename the default branch, remove documentation, become private, or disappear. Search should distinguish “not indexed” from “indexed with no match.”

Search personal notes for your real intent

Public documentation explains what a project is. Your note explains why it matters to you.

Suppose two repositories both implement feature flags. One note says “works with Cloudflare Workers,” while another says “rejected: requires a hosted control plane.” Those private sentences are often the strongest retrieval evidence in the entire library.

Good note search should include:

  • exact full-text matching
  • snippets around the matching phrase
  • filters for tags and status
  • local storage by default
  • export with the rest of the user-owned metadata

Write notes in your own vocabulary. Do not optimize them for a generic taxonomy. Search works because the words match the problems you will describe later.

Use tags and status as filters, not as a substitute for search

Tags narrow a result set. They rarely identify the final repository by themselves.

A query such as “database migration tool” might return 40 Stars. Combining it with language:Swift, status:Adopted, and a personal infra/database tag can reduce that to three.

This is where structured filters outperform natural language. The result is predictable and debuggable. If the filter returns nothing, you know which constraint to relax.

Status is useful because relevance changes with intent:

  • search Adopted when looking for a tool already trusted
  • search Reading when continuing current research
  • include Deprecated when trying to remember why an option was rejected

How to Organize GitHub Stars describes a minimal tag and status model.

Add semantic search for vocabulary mismatch

Semantic search turns text into vectors and retrieves content with similar meaning. It helps when you remember the problem but not the wording.

For example, the query:

a small local service that retries failed background work

might match READMEs using “durable task queue,” “job orchestration,” or “at-least-once execution.” Exact search sees different words; an embedding model can place them near the same concept.

Semantic retrieval is not automatically better. It has trade-offs:

  • indexing takes time and may cost money
  • results depend on the embedding model
  • similarity thresholds can hide useful results or admit noise
  • model changes can require re-indexing
  • a high score does not explain which phrase matched

Use hybrid retrieval when possible: exact full-text results for precision, semantic candidates for recall, then a documented fusion step. Keep the exact-search path available when embeddings fail.

Ask questions only after retrieval works

A chat interface is not a replacement for a search index. It is a synthesis layer built on top of retrieval.

The safe sequence is:

  1. identify candidate repositories or document chunks
  2. show which evidence was retrieved
  3. ask the model to synthesize an answer
  4. attach citations that open the source evidence

Without those steps, the model may answer from general web knowledge instead of your saved library. A confident explanation of a popular framework is not proof that the right starred repository was consulted.

Repository-grounded Q&A is most useful for comparative questions:

  • “Which saved Swift networking libraries support async/await?”
  • “Compare the deployment assumptions of these self-hosted Star managers.”
  • “Which indexed projects mention both local embeddings and MCP?”

For a deeper explanation, read Asking Questions of Your Starred Library.

A practical search order

When trying to recover a forgotten Star, use this order:

  1. Search exact words across name, owner, description, Topics, notes, and README.
  2. Add one structured filter such as language, status, or personal tag.
  3. Remove the filter if the result set is empty.
  4. Try a semantic query that describes the problem in a complete sentence.
  5. Inspect the matched snippets before asking AI to compare results.
  6. Once you find the repository, add the missing note or status so the next search is easier.

This order is fast because cheap, explainable retrieval handles most searches. AI is reserved for the cases where it adds information rather than ceremony.

How Starcat handles the layers

Starcat keeps repository metadata and personal context in a local SQLite library. FTS5 covers lexical retrieval across names, descriptions, Topics, and notes. README and knowledge-base content can be chunked for deeper retrieval. Semantic search and repository-grounded RAG are optional layers, and cited answers lead back to the supporting repository or chunk.

The product boundary matters: Stars remain the broad collection, while only repositories you intentionally ingest become the default knowledge-base context. That avoids spending embedding time and model budget on every bookmark you have ever made.

You can download Starcat, inspect the open-source implementation, or compare it with other options in Best GitHub Star Managers for macOS.