THE GHOST CONTRIBUTOR

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

A missing docstring is easy to leave for later. The next person reading that function still has to work out what it does.

I built The Ghost Contributor, a local AI assistant that turns small documentation gaps into changes a developer can review and approve.

You register a Git repository and choose an installed Ollama model. Ghost finds a supported documentation gap, drafts a focused suggestion, and presents the exact diff alongside quotations from the source. Approval creates a commit on a separate ghost/… branch while your current branch stays in place.

The current MVP handles missing docstrings in supported Python functions and explicitly marked, empty Markdown sections. It also supports scheduled runs and pause/resume controls. Remote publishing is a separate, explicit action.

It is designed for developers and open-source maintainers who want help with recurring documentation chores while keeping the final decision.

Demo

45-second video:

https://youtu.be/HI0cluBc5Eg?si=of-yp4syhWQU_eNj

The video uses screenshots from a real local qwen2.5-coder:7b run: source analysis, a generated proposal, evidence review, approval, and a successful Git commit. Motion graphics explain the workflow; the inference wait is compressed and labelled in the video.

Ghost runs on the developer’s computer, with a browser dashboard connected to the local application and Ollama.

Code

Source repository:

https://github.com/Rohi56u/Ghost-contributer

The application is released under the MIT license. The source includes the Python backend, dashboard, tests, Windows setup launchers, architecture notes, and verification records.

Start with README.md, or START-HERE-WINDOWS.md for the Windows walkthrough. The recorded run is documented in docs/REAL-RUN.md.

How I Built It

The stack is Python, Ollama, the open-weight Qwen2.5-Coder model, LibCST, SQLite, Git worktrees, and a local HTML/CSS/JavaScript dashboard. I developed the project with AI coding assistance.

Each component has a specific job:

• Ollama and Qwen2.5-Coder generate a documentation suggestion from selected source context. -Python validation checks the structured response, allowed target, and exact source quotations. -LibCST and syntax checks apply the supported Python insertion and check that executable code outside the docstring remains unchanged. -SQLite records proposals, decisions, and run history. -Git worktrees isolate the proposed change and its eventual commit. -The dashboard puts the diff, rationale, and evidence together for human review.

One useful failure shaped version 0.2.1. Early model responses copied display line numbers into their evidence quotes, so the validator rejected them. I changed the prompt to send line numbers and source text as separate JSON fields. The exact-quote checks stayed strict, and the subsequent real-model run produced valid citations.

Verification includes 93 passing automated tests and a real Linux run through dashboard approval and Git commit. Windows setup instructions are included; execution on Windows and macOS still needs verification. Exact quotations establish where a suggestion came from; a person still needs to judge whether the prose is correct.

Why Does Open Innovation Matter?

Documentation assistance needs source-code context. Running an open-weight model through local Ollama lets the inference happen on a machine the developer controls, with cloud features disabled.

After dependencies and model weights are installed, the inference path uses the local server. There is no hosted-model API key or per-request API bill, although local hardware and electricity still have a cost.

Developers can select another compatible installed model, inspect the prompts and validators, and change the automation’s behavior. That makes the project adaptable to different machines and repositories.

Compared with sending source context to a hosted model API, this gives the maintainer direct control over where generation happens. Releasing the application under MIT also lets others inspect, improve, and reuse the maintenance workflow.

The Lazy Payoff

In this week’s sample run, Ghost found the missing documentation for retry_delay, generated a paragraph with four exact source quotations, and prepared a reviewable diff. After approval, it created the separate branch commit and left main unchanged.

The dashboard run action took 47.633 seconds, including generation and validation. That is an observed runtime for one example—not a measurement of time saved, and it excludes the later review and approval.

The intended payoff is fewer repetitive steps: finding the gap, drafting the first paragraph, and preparing the proposed change. The maintainer can focus on the review. I have not yet measured savings against a manual baseline or tested sustained use across multiple repositories.