Tag systems fail in predictable ways: too many tags, tags named for aspirational futures, tags that mean three different things depending on the week.

Starcat gives you tags because retrieval needs handles. It does not give you a corporate ontology.

Design for your brain, not for GitHub Topics

GitHub Topics describe the ecosystem. Your tags describe why you care.

Examples that tend to age well:

  • use/now vs learn/later
  • infra/db vs ui/swift
  • security/supply-chain
  • ref/architecture for things you cite, not ship

Depth-two paths are usually enough. Depth-five folders are where libraries go to die.

Rules of thumb

  1. Prefer reuse — if a tag appears once, it may not deserve to exist
  2. Write the disputed reason in notes — tags classify; notes explain
  3. Let AI propose, you accept — models are good at synonyms and bad at your dialect

Batch tagging helps when you import a large star set. It still should not invent fifty new labels in one afternoon.

Untagged is a feature

The Untagged view is not shame. It is a queue.

Process a few each session: tag, note, or archive. The goal is not zero untagged forever. The goal is that when you search next month, the important ones already have a name you recognize.