# Project Mind — Turn Your GitHub History Into Searchable Memory

> Source: <https://dev.to/kadurugved0/project-mind-turn-your-github-history-into-searchable-memory-1591>
> Published: 2026-10-02 12:04:09+00:00

*This is a submission for the [Hacktoberfest Weekend Challenge: Build for a Friend](https://dev.to/challenges/hacktoberfest-weekend-2026-10-01)*

Software projects accumulate more than code.

They accumulate **decisions, bugs, fixes, discussions, constraints, and context**.

But that knowledge is usually scattered across source files, README files, GitHub issues, pull requests, commits, and personal notes.

I built **Project Mind** to bring that knowledge together.

Project Mind is an **AI-powered memory and question-answering system for GitHub repositories**, built for a friend who works on software projects and spends a lot of time trying to remember how and why different parts of a project work.

Instead of asking:

“Where did we document this?”

or:

“Have we already solved this problem?”

they can ask the project directly.

**“Why was this decision made?”**

**“Have we seen this bug before?”**

**“Which pull request introduced this change?”**

**“Where is the documentation for this feature?”**

**“What should I know before modifying this code?”**

A connected repository becomes its own searchable knowledge base.

Project Mind indexes:

The user can then ask questions about the project using natural language.

For example:

**“How does GitHub authentication work from the login page through the Auth.js callback, MongoDB user storage, session creation, and repository loading?”**

Project Mind retrieves the relevant parts of the actual project and explains the flow with source references.

The answer isn't just generated from the model's general knowledge.

It is grounded in the **project's own code and history**.

Most AI coding tools help answer:

**“How can I write this?”**

Project Mind focuses on another question:

**“Why does this project work this way?”**

That distinction is what I wanted to build for my friend.

**Less searching. More building.**

🎥 **Video Demo:**

[https://youtu.be/Tw_DN1UkXAY?si=Hy2EeIaC2e6URv2z](https://youtu.be/Tw_DN1UkXAY?si=Hy2EeIaC2e6URv2z)

The demo shows the complete workflow:

A user authenticates with GitHub and selects the repository they want Project Mind to understand.

Project Mind collects the repository's source files, documentation, issues, pull requests, commits, and approved memories.

The user can see which sources have been indexed and where they came from.

The user can ask questions about implementation details, architecture, authentication, bugs, or project history.

Retrieved sources are displayed alongside the answer so the developer can understand where the explanation came from.

Questions about previous bugs, fixes, decisions, and pull requests can be answered using the project's historical context.

Important project knowledge can be explicitly saved so it remains available in future conversations.

A project can be removed along with its indexed documents, memories, conversations, and synchronization data.

💻 **GitHub Repository:**

[https://github.com/rugvedkadu06/ContextForge](https://github.com/rugvedkadu06/ContextForge)

Project Mind is built around **open-weight AI and local inference**.

When a repository is connected, Project Mind uses GitHub APIs through **Octokit** to collect project knowledge.

The indexer processes:

Each piece of information keeps metadata describing its source.

This matters because an answer shouldn't just say *what* it found.

It should be possible to understand **where that information came from**.

The collected content is divided into searchable chunks.

Project Mind uses **Nomic Embed Text** through Ollama to generate embeddings locally.

These embeddings, together with the source metadata, are stored in MongoDB Atlas.

When a user asks a question, Project Mind doesn't rely on a single retrieval method.

It combines:

**Vector search + keyword search**

to find relevant project context.

This allows semantic questions and exact project terminology to work together.

The retrieved context is passed to **Llama 3.2 3B**, running locally through Ollama.

The model generates an answer based on the retrieved project information.

The result is then presented together with the sources that contributed to the answer.

So instead of:

“The AI says this is how authentication works.”

the user gets:

**“Here is how authentication works, and here are the parts of your project that explain it.”**

One of the main ideas behind Project Mind is that not every important piece of knowledge exists in the source code.

Some knowledge exists only in the developers' heads.

**Title:** Store GitHub tokens server-side

**Type:** Decision

**Content:** GitHub access tokens must remain encrypted in MongoDB and must never be exposed through the browser session.

This can be saved as a long-term project memory.

Later, when someone asks why tokens are handled that way, the decision can be retrieved alongside the relevant implementation.

This allows Project Mind to preserve not only:

**what the code does**

but also:

**why the team decided to build it that way.**

This project deals with something developers don't always want to send to a third-party AI service:

**their project.**

A repository can contain private source code, internal documentation, security decisions, architecture decisions, unfinished features, debugging history, and other information that may not belong on an external AI platform.

That's why local inference is an important part of Project Mind.

Instead of sending the project's context to a closed AI API, Project Mind uses **Ollama and an open-weight model** for local inference.

This gives the developer more control over where the AI processing happens and how the system is built.

Open tools also allowed me to control the entire retrieval pipeline.

I could decide:

The model is therefore only one part of the system.

The rest of the system — **indexing, retrieval, memory, source tracking, and context construction** — is also under my control.

That is what open innovation made possible for this project.

I wasn't limited to building another chatbot around a closed API.

I could build a **project-specific memory system** around an open model.

Building Project Mind changed how I think about AI developer tools.

A repository isn't just a collection of files.

It has a history.

A bug might explain why a strange piece of code exists.

A pull request might explain why an architecture changed.

A commit might reveal when a behaviour was introduced.

A project memory might explain the decision that isn't written anywhere in the code.

Putting these sources together makes the repository much closer to a **living knowledge base**.

That is the direction I wanted to explore with Project Mind.

Project Mind uses **MongoDB Atlas** as its primary data layer.

It uses **MongoDB Atlas Vector Search** for semantic retrieval and stores long-term project memories alongside the indexed project knowledge.

This allows the same system to connect retrieved context with its original source and preserve project-specific memory for future questions.

I built Project Mind for one simple reason:

**My friend shouldn't have to remember an entire software project just to work on it.**

The code already contains part of the answer.

The issues contain another part.

The pull requests contain another.

The commits contain another.

And sometimes the most important answer exists only in a decision someone made months ago.

Project Mind brings those pieces together.

It turns a GitHub repository from something you **search through** into something you can **ask questions about**.

**Project Mind — Give Your GitHub a Memory. 🧠**

*Built for the Hacktoberfest Weekend Challenge: Build for a Friend.*
