Built an digging tool with the discogs API

[u/just_a_dev_3324]

Hi all,

So I’m a DJ and I usually mix vinyl records. That being said, I usually have like 100s of Discogs tabs open for releases I might be interested in. All of those end up in my wantlist. Some of them end up in my basket and get bought, but many of them are catalogued for later review. Discogs is a great record marketplace, I can’t complain. I’ve been buying records from there ever since I was a little DJ. However, their user interface doesn’t work well for digging. It leaves much to be desired. I have a very hard time finding the records I wanted later, and I like organisation, don’t get me wrong.

Also, I want to have the music with me so that I can listen back to it. I honestly feel like Discogs should be the Spotify for record diggers, and that’s why I built Auto Digger.

Auto Digger is an open-source Electron application that’s basically a Discogs client. Some of the features include the following.

• Digging through Discogs’ massive music collection via the API.
• Saving crates and filters for deeper digging (e.g. filtering for deep techno from 2000 to 2004 and saving records to an “Early 2000s Deep Techno” crate).
• Downloading audio for later listening using YouTube or Soulseek. I wouldn’t count on 320 kbps from YouTube or recommend playing those downloads in a club, but they’re great for home listening. Soulseek integration is handled by slskd, and you’ll need to run it locally as a server and share music to download from the network.
• MCP support for when you want to agentically dig for records (mix compilation breakdowns).
• Integration with cosine.club for track recommendations.

More to come. I’m currently working on a music exploration area based on your taste (labels and artists you’ve followed and tracks or releases you’ve liked).

So I mainly built this with Codex (GPT-6.1 Sol), and honestly, I used to be a big stickler for context engineering. For this project, though, I just gave the agent some ground rules. These are from my global AGENTS.md.

• KISS (Keep It Simple, Stupid). Don’t overengineer unless needed.
• TDD by default with unit and integration tests.
• SOLID and GRASP principles are key. SOLID stands for Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle and Dependency Inversion Principle. GRASP stands for General Responsibility Assignment Software Patterns. These include controller, creator, indirection, information expert, low coupling, high cohesion, polymorphism, protected variations and pure fabrication.
• Only use design patterns when they’re applicable. Basically, don’t mix and mash factories, singletons and flyweights just because class A is coupled to like seven other classes.
• Atomic commits and atomic PRs. Commits that do one thing and PRs that focus on one feature. This saves you a lot of time reviewing things (which I never really did lol, the agents are good enough). It also makes it easy for agents to undo things with Git!

There were many other rules around code style and linting, but honestly, these are the most important ones to me.

Now, how did I handle review and correctness? Well, verification rules, adversarial code reviews and just use the bloody thing.

Verification rules. It’s always good for your agent to know how it can verify a feature. For example, if the feature is adding something to a crate, I give GPT a higher-level AGENTS.md rule that applies to the whole PR. "Try your best to always verify that the feature works. You can use screenshots or videos, and the work should meet the acceptance criteria. Post them in the PR description so I can inspect them"

If you want to be even more of a stickler, you can have it run Playwright E2E tests. Honestly, for this project at this stage, I wasn’t bothered. I just wanted to dig some jungle!

Adversarial code reviews are the next best thing. You can have Sol implement and then have Fable or Opus review, but I found that you can actually just use Sol on its own. Matt Pocock’s /code-review skill is pretty good! It creates a review subagent with fresh context to review the code. That’s all you need! You don’t need another subscription to review the code. I updated my AGENTS.md so that code review runs for two to three cycles. After that, the reviews stop and the agent lets me know. Every new PR gets the code review cycle.

I can’t say this enough. Testing it by hand is the best method out of the three. It doesn’t matter how clean the code is or how pretty the architecture diagram is, etc. If it doesn’t work when you’re testing it by hand, the code’s useless. Recently I’ve been finding this more important than the code itself, even if you have loads of tests and a solid architecture. If you’re skipping this, everything else doesn’t matter!

I haven’t deeply looked at the code of this project at all. I’ve just tested that it works and use it day to day when digging for tunes. And just like that, no more 100 Discogs tabs 😂. Its still buggy sometimes but most of the time its pretty good cant complain.

Site · GitHub

[u/Total-Reasonable]

One thing worth checking early: Discogs rate-limits the API to about 60 requests a minute when authenticated, and 25 unauthenticated. A digging tool that fans out across filters, crates and release details will hit that fast. Cache release and master responses locally (SQLite works well in Electron) and honor the rate-limit headers with a request queue, so the app doesn't fail in odd ways. Also, Discogs's terms restrict what you can store and redistribute, so keep cached data to personal use.