DEV Community: Egbuta ifeanyi chukwu

# RepoGhost: Investigating GitHub Accounts Without Guessing 👻

Egbuta ifeanyi chukwu — Wed, 28 Oct 2026 13:59:57 +0000

Every GitHub profile leaves a trail. The challenge is knowing what that trail actually tells you.

I’m building RepoGhost, a project that investigates public GitHub accounts and repositories, surfaces useful evidence, and helps you ask questions about what it finds.

The idea is simple: instead of looking at a profile and making assumptions, investigate the projects behind it.

🔗 Live demo: https://repoghost.onrender.com

💻 GitHub repository: https://github.com/egbutaify2-ui/repoghost

Why I started building RepoGhost

A GitHub profile can contain dozens of repositories, different technologies, activity records, and projects with very different purposes.

But repository counts and star numbers alone don't tell the whole story.

I wanted to build something that could help answer practical questions:

What does this GitHub account or organization actually work on?
Which public repositories are relevant to a particular technology or role?
What technologies appear in its projects?
What can recent public activity tell us—and what can't we conclude from it?
Can I ask follow-up questions about an investigated account instead of starting from scratch?

That last question is especially important to me. I want RepoGhost to feel like an investigation you can continue, not a report you read once and abandon.

How RepoGhost works

The current project combines public GitHub data with AI-assisted analysis.

1. Investigate an account

Enter a GitHub username or organization, such as expressjs. RepoGhost retrieves the public profile and repository information.

2. Follow the evidence

Depending on the investigation, it can surface repository descriptions, programming languages, stars, forks, and visible activity. Repository-level investigations can also examine README files, sampled commits, issues, and releases when available.

3. Ask questions

The goal is to let you ask natural-language questions about the account and its projects, with answers grounded in the collected public evidence.

4. Follow the sources

Claims should lead back to the relevant public GitHub records. If the available information doesn't support an answer, RepoGhost should say what remains unknown rather than inventing a story.

The interesting engineering challenge: AI is not the source of truth

One lesson from building this project is that getting an AI model to return an answer is only part of the job.

The answer also needs to be relevant, concise, supported by evidence, and linked to valid sources.

Models can return malformed output, omit citations, or fail to answer the question directly. A fallback that simply dumps technical errors isn't useful to the person asking the question.

That's why I'm working on making RepoGhost more reliable: validating answers, checking citations against the actual evidence, handling model failures gracefully, and keeping verified GitHub data available even when AI inference fails.

I'd rather RepoGhost admit that it doesn't know than confidently tell someone something the evidence cannot support.

What RepoGhost should never pretend to know

Public GitHub data has limits.

Repository ownership doesn't prove that someone personally wrote every line of code. Recent activity doesn't prove code quality. Stars don't establish engineering ability. And public repositories cannot reveal someone's private work or personal motivations.

RepoGhost is intended to help people investigate evidence, not turn incomplete signals into unquestionable judgments.

Built in the open

I'm developing RepoGhost as part of my work around AI-powered developer tools and evidence-based software analysis.

The project is still evolving, and I'm treating the reliability issues as part of the engineering work—not something to hide behind a nice interface.

Try it with a GitHub account or organization you know. Ask what its projects do, inspect the sources, and see where the evidence leads.

👻 Try RepoGhost: https://repoghost.onrender.com

⭐ Explore the source code: https://github.com/egbutaify2-ui/repoghost

I'd particularly value feedback on one question:

What would make you trust an AI tool that investigates GitHub accounts and explains what it finds?

I'm building toward that standard, one investigation at a time.

hacktoberfest #ai #opensource #node

RepoGhost: Every GitHub Profile Leaves a Ghost. Lets find out

Egbuta ifeanyi chukwu — Wed, 28 Oct 2026 12:29:55 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

What I Built

Every developer leaves traces. Every repository holds memories. And nothing on GitHub ever tells the whole story at first glance.

I built RepoGhost, an AI-powered GitHub investigation tool that lets you summon a public developer profile, question it about its work, uncover its projects, and investigate the evidence left behind across its repositories.

Enter a GitHub username, and the investigation begins.

What does this developer build? Which technologies appear in their projects? What has changed recently? Which repositories seem worth investigating? What evidence supports their experience with a particular technology? Which projects might need attention, and where could someone contribute?

Instead of giving you one static summary and leaving you to figure out the rest, RepoGhost lets you continue the interrogation. Ask follow-up questions about the account and its public work. Investigate the answers. Follow the source links. Dig deeper.

It's meant to feel like questioning a ghost that has been watching the developer's public GitHub trail.

But this ghost has rules.

It can only speak from the evidence it can find. It doesn't have access to a person's private life, private repositories, or hidden knowledge. When the public trail doesn't support an answer, RepoGhost should expose that limitation instead of inventing a story.

Beyond account investigations, RepoGhost can compare two public GitHub accounts against a specific goal, assess visible project evidence for a role, investigate repository health, and recommend relevant projects and real contribution opportunities.

I also interpreted Ghost in the Machine through the forgotten corners of open source: repositories that have gone quiet, abandoned-looking projects that may still contain valuable ideas, and software whose original purpose deserves another look.

A quiet repository isn't necessarily dead. Sometimes, the evidence simply hasn't been examined closely enough.

RepoGhost is where you go when you want to ask the codebase questions—and see what answers come back from the darkness.

Demo

The ghost is waiting.

Summon RepoGhost

Enter a public GitHub username or investigate a repository, then explore the evidence and ask follow-up questions about the account's public work.

Code

Every ghost leaves traces. This one leaves its source code in the open.

Examine the RepoGhost source code on GitHub

The repository contains the application code, configuration examples, and automated tests for the investigation and intelligence workflows.

How I Built It

RepoGhost is built with Node.js, HTML, CSS, and JavaScript. It uses the GitHub REST API to collect public evidence and OpenRouter to run Google's open-weight Gemma 4 26B A4B IT model.

The AI isn't just a decorative chatbot. It helps interpret the evidence collected by the application and powers the project's analysis and account-questioning experience.

The investigation works in several stages:

1. The summoning. A visitor supplies a GitHub username, public profile URL, or repository URL. RepoGhost discovers the relevant public account or project.

2. The trail of evidence. The application collects information such as repository metadata, README content, languages, recent commits, open issues, and release information when available. Account investigations can use public repository information and a bounded sample of recent commits.

3. The interrogation. Gemma helps answer questions and interpret the evidence. Users can ask follow-up questions about a public account's projects, technologies, and recorded activity rather than starting a completely new investigation every time.

4. The source check. RepoGhost validates AI-generated source references against the evidence actually collected. Unsupported references are discarded, and missing evidence is treated as a limitation—not an invitation to invent an answer.

5. The investigation continues. Users can assess a developer's public portfolio for a role, compare two accounts against a goal, investigate potential maintenance risks, or discover projects and contribution opportunities.

I also built the application to handle missing information and upstream failures explicitly. A missing release or README shouldn't automatically mean a repository is dead, and a temporary AI-provider failure shouldn't be disguised as a successful investigation.

The result is a tool that combines deterministic data collection, evidence validation, and AI-assisted interpretation. The model helps interpret what the application discovers; the application is responsible for collecting the evidence and enforcing its validation rules.

Why Does Open Innovation Matter?

A ghost story becomes less convincing when you can't inspect what is happening behind the curtain.

That's one reason open innovation matters to RepoGhost.

The application uses Gemma, an open-weight model, rather than building its intelligence exclusively around one proprietary model. Its prompts, evidence-handling logic, validation rules, and surrounding application code are available for people to inspect, adapt, and improve.

Open weights make the model choice more flexible. RepoGhost's inference configuration is separated from its GitHub evidence collector and frontend. This creates room to experiment with compatible models and inference providers without rebuilding the entire application.

Open code makes the investigation easier to examine. Developers can inspect how information is collected, how the model is instructed to answer, and how the application checks its source references. The goal isn't to make an AI sound omniscient; it's to make its findings easier to question.

Open innovation leaves the door open. The hosted version currently uses OpenRouter, so it requires an internet connection and sends the material needed for inference to the configured provider. It is not an offline application today. However, the separated inference layer creates a path for operators to explore compatible self-hosted open-weight models later.

A closed model could also answer GitHub questions. My argument isn't that open-weight AI magically makes every answer better. It's that developers deserve more choice in how they run, inspect, and adapt the systems they build.

And for a project about investigating public evidence, that matters. The ghost may help interpret the trail, but people should be able to examine how the ghost works.

My Agent Session

Optional: Add a DevRelay agent session link here if available.

The Spirit of It

Imagine discovering a GitHub profile belonging to a developer you've never met.

At first, all you have is a username.

You open their repositories. One project catches your attention. You inspect its README, look at the languages, follow a few commits, and begin to wonder what the developer has actually been building.

Then you start asking questions.

What are their most relevant projects? What technologies can you see evidence of? What changed recently? Which repository should I investigate next? What can the public record tell me about this developer's work?

The username becomes a trail. The trail becomes evidence. And the evidence gives you new questions to ask.

That's the feeling I wanted RepoGhost to create: not just looking at a profile, but summoning its public history and questioning what remains.

The ghost isn't magic. It doesn't know someone's secrets, and it cannot answer every question truthfully when the evidence isn't there. But it can help reveal patterns that might otherwise remain buried in a long list of repositories and commits.

And when the evidence ends, the ghost should say so.

Because the scariest thing an AI can do isn't admit that it doesn't know.

It's confidently tell you a story that never happened.

Prize Categories

Best Use of Gemma — Gemma powers RepoGhost's AI-assisted repository analysis and account intelligence.
Best Use of Render — RepoGhost is deployed as a live web application on Render.

devchallenge #hf26challenge

I agree with the core message, especially problem framing, debugging, and knowing when not to trust generated code. But I think “the only skills that pay” is an overstatement.

Egbuta ifeanyi chukwu — Wed, 28 Oct 2026 12:14:06 +0000

Info Inlet

Oct 28

6 Things AI Still Can't Do in 2027 — And Why They're Now the Only Skills That Pay

#ai #career #programming #webdev

3 min read

AI Can Write the Code. Who Owns the Bug?

Egbuta ifeanyi chukwu — Mon, 26 Oct 2026 09:38:49 +0000

AI coding tools can build features surprisingly fast. But there's one thing I keep thinking about:

If AI writes the code and something breaks in production, how well do you understand the code it's written?

A feature can work perfectly during testing and still fail when it meets real users.

Maybe the API times out. Maybe the user submits a form twice. Maybe authentication expires halfway through a request. Or maybe the AI changes one file and unknowingly breaks something in another.

That's why I think AI-assisted development is about more than writing good prompts.

You still need to understand the system, question the generated solution, test edge cases, review changes, and know how to debug what goes wrong.

AI can help you move faster, but speed without understanding can become an expensive problem.

I'm curious about how other developers are working with AI coding tools today.

Three questions for the community:

Do you trust AI-generated code once the feature works, or do you review every change?
Has an AI coding tool ever introduced a bug that took you longer to fix than writing the code yourself?
What do you think matters more in AI-assisted development: writing better prompts or being a better engineer?

I'd love to hear your real experiences, including the mistakes. Let's discuss.

ai #discuss #webdev #programming

I’m excited to share that I joined the Sanity Challenge 2026 — Path One: Ship an Agent That Queries Real Content. https://dev.to/egbutaify2ui/lenslink-an-ai-camera-compatibility-agent-powered-by-structured-sanity-content-415l

Egbuta ifeanyi chukwu — Fri, 02 Oct 2026 14:40:44 +0000

Sanity Challenge Path One Submission

Egbuta ifeanyi chukwu

Oct 2

LensLink: An AI Camera Compatibility Agent Powered by Structured Sanity Content

#devchallenge #sanitychallenge #sanity #ai

2 min read

Sanity Challenge Path One Submission

Egbuta ifeanyi chukwu

Oct 2

LensLink: An AI Camera Compatibility Agent Powered by Structured Sanity Content

#devchallenge #sanitychallenge #sanity #ai

2 min read

LensLink: An AI Camera Compatibility Agent Powered by Structured Sanity Content

Egbuta ifeanyi chukwu — Fri, 02 Oct 2026 14:32:18 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.

What I Built

LensLink is an AI camera and lens compatibility agent that answers whether a lens can be used with a camera using structured Sanity content rather than relying only on generic model knowledge.

The content models relationships between cameras, mounts, lenses, adapters, compatibility rules, and sources.

Demo

Live demo: https://lenslink-civq.onrender.com

Try these:

Is the Canon RF50mm F1.8 STM compatible with the Canon EOS R5?

Can I use the Canon EF50mm f/1.8 STM on the Canon EOS R5?

Is the Canon EF-M 22mm f/2 STM compatible with the Canon EOS R5?

These demonstrate direct compatibility, adapter-required compatibility, and an unsupported/evidence-limited case.

Code

GitHub: https://github.com/egbutaify2-ui/sanity-lenslink-agent

How I Used Sanity

I modeled the camera compatibility knowledge as structured Sanity content, including:

Camera → Mount

Lens → Mount

Adapter → From Mount / To Mount

Compatibility Rule → Camera / Lens / Adapter

Source → supporting evidence

I pointed Sanity Context at the LensLink Knowledge Base built from this structured content.

The agent uses these Context MCP tools:

initial_context

knowledge_base_search

knowledge_base_read

For each compatibility question, LensLink retrieves the relevant structured records before Gemini generates the answer.

For example, for the EF50mm + EOS R5 case, the agent can reason across:

EOS R5 → Canon RF Mount

EF50mm → Canon EF Mount

Canon EF-EOS R Adapter → Canon EF → Canon RF

This lets LensLink determine the documented adapter-required path instead of simply guessing from the product names.

Sanity Project Details

Project ID: kv3pdv23

Dataset: production

Agent Session

Agent session evidence is optional, so I have not included a transcript in this submission.