RepoLens

• 

  Homepage

• 

  Analysis of a repo

• 

  Interview on a repo

• 

  Summaries of the Session

• 

  Gemini API Usage (Note: graphs are in UTC-8)

• 

  Gemini API Embedding Usage (Note: graphs are in UTC-8)

Inspiration

I didn't start with an interview coach in mind.

At first, RepoLens was a GitHub analyzer that scored README quality, flagged issues, and gave an "interview readiness" score. After thinking it through, that didn't feel right. People don't need another score on their repo. They need help answering a common interview question: "Walk me through your project."

Most prep tools focus on algorithms or generic questions. That helps, but it doesn't prepare you to explain your own code. Every repo is different, so fixed question lists don't work well.

So I changed direction. RepoLens became a tool to practice project-based interviews using a public GitHub repo.

What it does

Paste a public GitHub URL, or pick one of the built-in demo repositories.

RepoLens scans the repo, builds a short summary of what the project is, and runs a simple mock interview: one question at a time, feedback on your answer, and follow-up questions based on what you said. At the end, you get a short summary with a few things to review.

It tries to ask about your project, not random trivia.

How I built it

Frontend: React + TypeScript
Backend: FastAPI (Python)

Basic flow:

GitHub repo → scan → profile → knowledge pack → interview

First, the backend clones the repo and builds a Repository Profile (languages, frameworks, important files, project type). I tried to keep this language-agnostic so it works for different kinds of projects, not just one stack.

Then RepoLens builds a Knowledge Pack. It chunks files, embeds them, and runs semantic search for topics like architecture and testing. The best matching snippets go into the pack along with a few key files picked by simple rules.

During the interview, prompts use that pack. The app doesn't send the whole repo to the model. Retrieval happens mainly when the pack is built, not on every single question.

For AI, I use OpenAI and Gemini through a ProviderRouter. User can choose between OpenAI and Gemini model.

The app is live on Vercel + Render. I also prepared GCP setup (Cloud Run, Firebase, Firestore), but I could not deploy there during the hackathon because Google requires a valid credit or debit card with international transactions enabled to activate billing, even for free-tier usage.

Building with Codex (AGENTS.md + SKILL.md)

Instead of asking Codex to generate the whole project at once, I used it as a guided build partner with two repo-level files:

AGENTS.md defines the mission, MVP boundary, and engineering rules: compact RepositoryProfile, no full-repo prompts, modular FastAPI services, dedicated prompt files, tests on critical paths, and alignment with the hackathon tracks (Gemini API, GCP architecture, Codex process).

SKILL.md defines how to work inside the repo: build in small vertical slices, keep API contracts / services / prompts / UI separated, prioritize demo reliability, and avoid scope creep (no enterprise features before the core interview loop works).

In practice, I used Codex incrementally:

• one module at a time (scanner, retrieval, knowledge pack, interview service, UI views)
• scoped prompts tied to those rules instead of open-ended "build everything" requests
• tests alongside features so changes stayed stable under time pressure

That kept the codebase coherent through the pivot from a scoring tool to an interview coach, and made it easier to preserve the Gemini path and GCP deployment assets while shipping the live MVP.

Challenges I ran into

Changing the idea mid-build
Moving from a scoring tool to an interview coach meant throwing away some early work and focusing on a smaller MVP.

Working with context limits
I couldn't send entire repos to the model. I had to chunk files, retrieve useful parts, and keep prompts short.

Describing retrieval honestly
I do use chunking, embeddings, and semantic search, but it's a simple setup: retrieval mostly happens at analyze time, not as live search on every interview turn. Getting the wording right mattered so I didn't overclaim.

Supporting different repo types
Making the scanner useful across web apps, APIs, libraries, and other project types took extra iteration.

Keeping questions repo-specific
Sometimes the model still asked generic questions or referenced things that weren't in the repo. I improved this with better prompts and tighter context.

Gemini API limits during testing
On the free tier, I hit Gemini rate and quota limits quickly during multi-turn interviews, especially when running analyze, embeddings, question generation, and evaluation back to back. That made live demos unreliable when Gemini was the default, so I added provider fallbacks.

Deployment
I designed RepoLens for Google Cloud (Cloud Run, Firebase Hosting, Firestore) and committed the deployment configs and setup docs. I could not complete a live GCP deploy during the hackathon because Google requires a valid credit or debit card with international transactions enabled to activate billing, even for free-tier usage, and I did not have one available in time. I shipped the working demo on Vercel and Render instead and documented the GCP path for when billing can be enabled.

Keeping Codex useful after the pivot
When the product direction changed, I updated AGENTS.md and SKILL.md so new Codex sessions stayed aligned with the interview MVP instead of drifting back toward the old scoring idea or pulling in unrelated refactors.

Accomplishments that I'm proud of

I got a working demo where you can paste a real public repo and start an interview.

The questions usually connect to the project's files and structure, not a fixed question bank.

I completed the pivot from a scoring tool to something I think is more useful for interview prep.

I also used Codex in a structured way through AGENTS.md and SKILL.md, not as a one-shot code generator. Those files are in the repo and reflect how the project was actually built.

What I learned

A lot of the work happens before the LLM call: scanning the repo, picking useful files, chunking, retrieving snippets, and writing clear prompts.

Simple retrieval at analyze time can already help ground the interview, even without a full vector database or live search every turn.

For a hackathon, scope control matters. I focused on the core loop (analyze → interview → feedback) and left things like Firestore persistence and full GCP deploy for later.

I also learned that demo reliability matters. Fallbacks between providers helped when rate limits showed up.

On the Codex side, the most useful pattern was small scoped tasks + written guardrails. AGENTS.md and SKILL.md worked best when they were specific to RepoLens (modules, constraints, hackathon tracks), not generic AI advice. Updating them after the pivot was as important as writing them at the start.

What's next for RepoLens

• Complete the GCP deploy (Cloud Run backend, Firebase Hosting, Firestore) once billing is enabled
• Save sessions with Firestore
• Improve retrieval during the interview, not just at analyze time
• Better study suggestions based on weak answers
• Support for private repos
• voice-based interviews
• Keep AGENTS.md and SKILL.md updated as the codebase grows

RepoLens started as a scoring idea. I want to keep improving it as a simple tool for practicing project interviews on your own GitHub work.

Note for reviewers

The first repository analysis may take a little longer because it may experience a cold start. Once the service is awake, subsequent requests are much faster.

Codex artifacts: see root-level AGENTS.md and SKILL.md. Gemini Usage: Model usage and Embedding usage.

Built With

• fastapi
• gemini
• openai
• python
• react
• typescript
• vite