Repo Recommender: Learning Claude Code the Disciplined Way

There is an incredible amount of open source out there, and almost none of it is hard to use once you find it. Finding it is the hard part. Repo Recommender is my attempt to fix that: point it at your GitHub repo, tell it what you want to add (“auth solution”, “background jobs”), and it returns repos that genuinely complement yours, each with a short reason it fits and quick ratings for ease and impact.

The examples on the home page are real gaps on my own sites - letsgochristo.com, blogcast.io, and getlocalgems.com.

#From RepoRadar to Repo Recommender

This project grew out of RepoRadar, which took 2nd place worldwide out of 302 teams at the Generative UI Global Hackathon. RepoRadar was built in four hours under hackathon pressure. It works, and I am proud of it. But it was built fast, not built to be owned by a team.

Repo Recommender is the same itch scratched the opposite way. I used it as my excuse to learn Claude Code properly - not just prompting until something compiles, but the full discipline: plan before build, write the rules down, enforce them with tooling, and leave a readable history behind.

#What “disciplined” actually means here

Every one of these is a real, inspectable file in the repo:

• Plan mode before code. The approach gets locked in a PRD and a plan before Claude writes a line.
• A CLAUDE.md that steers every session. Architecture rules, style rules, security rules. Claude reads it on every start, so decisions stay consistent across weeks of sessions.
• One engine, two surfaces. The recommendation logic lives once, in src/engine.ts. A Web API (/api/recommend) serves browsers. Our own MCP server exposes the same capability as a recommend_repos tool, so Claude Code, Claude Desktop, or any agent can call it. Software callers use HTTP, agent callers use MCP, and neither duplicates the engine.
• Model tiering to keep costs legible. Claude Haiku does the cheap, high-volume work: extracting a repo’s purpose and stack from its README, pulling search keywords. Claude Sonnet does the reasoning: ranking candidates and writing the “why it fits THIS project” line with the ratings. The tiering choices are noted in code comments so the cost story stays readable.
• A commit-blocking quality hook. A .claude hook refuses any commit that stages secrets or breaks the style rules. Guardrails you do not have to remember are the only guardrails that hold.
• Custom skills, subagents, evals, and tests for the repeatable work, from analyzing a candidate repo to scoring recommendation quality.

The stack is deliberately boring: a Cloudflare Worker with Static Assets, D1 for persistence, TypeScript, plain HTML and CSS on the frontend. Secrets live in Cloudflare via wrangler secret put, never in the repo.

#The lesson book

The part I care most about: every major step is written up as a lesson in the repo, 23 so far. Plan mode, permissions, CLAUDE.md, custom skills, MCP, context window management, model tiering and cost, subagents, hooks, git worktrees, secrets, debugging, tests, evals, deploy, D1 persistence, email notifications, an AI chat feature, and an analytics dashboard. Each lesson points at the actual files it produced, so you can see exactly how the thing was made, not just that it works.

If you are onboarding yourself or a team to Claude Code, the lesson book is the artifact I wish I had when I started. Vibe coding gets you a demo. This gets you something a team can own, extend, and trust.

#Try it

Point reporecommender.com at your repo and tell it what you want to build next. Read the source and lessons on GitHub. And if you want help adding open source to your own site, say hi.