I Built a Grounded RAG Assistant That Answers From Any GitHub README

Love Yadav — Sat, 03 Oct 2026 17:10:43 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Repo Chatter lets you paste any public GitHub repository URL and ask questions about its README in plain English. The app fetches the README, indexes it, and answers using only what the documentation says. Every answer shows the exact README chunks it was based on, so you can verify the source yourself. If the README doesn't cover your question, the app says so instead of guessing.

The app also tracks commit activity for each added repo through an hourly background job, and the interface uses a custom black-and-white design with a cursor-following glow and a scroll-driven landing page.

I built this for my teammate @prakhar_410, who regularly digs through unfamiliar open-source projects to find a single install command or environment variable. Reading a long README for one detail is slow. With Repo Chatter, it's one question away.

Demo

🔗 Live app: https://repo-chatter.netlify.app/

Code

The full source is on GitHub:

loveyadav1015 / RepoChatter

Repo Chatter is an AI-powered RAG application that allows users to chat with public GitHub repository READMEs through a cinematic, monochrome interface, providing grounded answers with source citations and tracking commit activity.

Repo Chatter 🚀

Chat with any GitHub repository's README using AI-powered RAG — wrapped in a cinematic, monochrome interface.

Repo Chatter lets developers paste a public GitHub repository URL and instantly ask natural-language questions about its README — grounded strictly in the actual documentation, with source citations. It tracks repository commit activity in the background via a scheduled job, and presents it all through a custom black-and-white interface with a cursor-reactive glow and an illustrated scroll-triggered landing hero.

Built as a submission for OverEngineered — the Web Development Wing selection process.

🎯 Features

📚 Add Any Public Repo — paste a GitHub URL, README is fetched and indexed automatically
💬 Grounded Q&A — ask questions in plain English, get answers based strictly on the README (no hallucination — the model explicitly refuses to answer outside the provided context)
📍 Source Citations — every answer shows exactly which README chunks were…

View on GitHub

How I Built It

Frontend

React with Vite
shadcn/ui components
GSAP with ScrollTrigger for the scroll-driven hero
Tailwind CSS and Axios

Backend

Node.js and Express (ESM), organized into routes, controllers, and services
Raw PostgreSQL driver (pg) with parameterized queries throughout
node-cron for scheduled jobs

Database

PostgreSQL 16 with the pgvector extension
Exact k-NN similarity search, which is correct and fast enough at this scale

AI models

Embeddings: sentence-transformers/all-MiniLM-L6-v2, an open-weight model that produces 384-dimension vectors, served through the HuggingFace Inference API
Generation: Mixtral 8x7B, an open-weight mixture-of-experts model, served through Groq for fast inference

Both models are open-weight, but the current deployment calls them through hosted APIs rather than running them on my own servers. Each model call sits behind a service adapter, so moving to a self-hosted model is a change to one module.

Infrastructure

Docker Compose for the local stack (database, backend, frontend)
Netlify for the static frontend
Render for the backend and the managed PostgreSQL database

How the RAG Pipeline Works

Repo Chatter has two flows. Ingestion runs when a repo is added. Retrieval and generation run when a question is asked.

Ingestion: when a repo is added

flowchart LR
    A[GitHub URL] --> B[Fetch README<br/>GitHub REST API]
    B --> C[Chunk<br/>~500 chars each]
    C --> D[Embed each chunk<br/>384-dim vectors]
    D --> E[(repo_chunks<br/>pgvector column)]

Retrieval and generation: when a question is asked

flowchart LR
    Q[User question] --> EQ[Embed question<br/>same model]
    EQ --> R[Retrieve top 5 chunks<br/>cosine distance]
    E[(repo_chunks)] --> R
    R --> G[Generate grounded answer<br/>Groq, Mixtral 8x7B]
    G --> A[Answer + source chunks]
    A --> H[(chat_history)]

Step by step

Fetch: the backend retrieves the README through the authenticated GitHub API. Authentication raises the rate limit well above the 60 requests per hour allowed for anonymous calls.
Chunk: the README is split into fixed-size chunks of about 500 characters.
Embed: each chunk is converted into a 384-dimension vector.
Store: chunks and vectors are saved to the repo_chunks table.
Embed the question: the question goes through the same model, so it lives in the same vector space as the chunks.
Retrieve: pgvector returns the five chunks with the smallest cosine distance to the question.
Generate: the model receives the question and those chunks, with instructions to answer only from that context.
Respond and log: the answer and its source chunks are returned to the frontend and saved to chat_history.

When the README doesn't cover the question, the response looks like this:

{
  "answer": "I don't know, this isn't covered in the README.",
  "sourceChunkIds": ["..."],
  "sourceChunkTexts": ["..."]
}

Commit Tracking

An hourly node-cron job keeps commit data current for every tracked repository:

flowchart LR
    T[Hourly tick] --> L[Load tracked repos]
    L --> F[Fetch commits since last_fetched<br/>GitHub API, paginated]
    F --> I[Insert into commit_logs<br/>ON CONFLICT DO NOTHING]
    I --> U[Update commit_count<br/>and last_fetched]

First run: fetches up to 100 recent commits, with pagination handled explicitly.
Later runs: fetches only commits newer than last_fetched.
Deduplication: a unique constraint on (repo_id, commit_hash) means reruns never create duplicate rows.

Database Design

Table	Purpose
`tracked_repos`	Repo URL, owner, cached README, fetch and embed timestamps, commit count
`repo_chunks`	README chunks with 384-dim pgvector embeddings
`commit_logs`	Commits fetched by the cron job, unique on `(repo_id, commit_hash)`
`chat_history`	Each question, its answer, and the source chunks it cited

Why Does Open Innovation Matter?

Open models are what made this project practical.

Cost: the embedding model is open-weight, so re-indexing a repo doesn't add a per-chunk charge on someone else's bill.
Reproducibility: because I can pin a specific model version, retrieval behavior stays consistent over time. A closed API can change under you without notice.
Flexibility: the service adapters let me swap in a different open model, or self-host one, without rewriting the retrieval or generation logic.
Inspectability: with open weights, I can test how the model behaves and read exactly what the retrieval step sends to it.

Prize Categories

Best Use of Render ($200 USD) : The Express backend (RAG ingestion, retrieval, generation, and the hourly commit job) and the managed PostgreSQL database both run on Render.

Introduction

Love Yadav — Fri, 02 Oct 2026 10:41:52 +0000

Hi , I am new to the community. Happy to be part of it.

DEV Community: Love Yadav