DEV Community: Souvik Biswas

Ghost Maintainer — An AI Junior Partner for Open Source

Souvik Biswas — Fri, 27 Mar 2026 04:13:12 +0000

This is a submission for the Notion MCP Challenge

What I Built

I maintain a couple of open source projects on my own, and the worst part has never been writing code — it's the stuff around it. Going through new issues, deciding if something's a bug or a feature request, digging into the codebase to figure out what's actually wrong, and then sitting down to fix it. Half the issues end up sitting untouched for weeks because I just don't get to them.

So I built Ghost Maintainer. It turns Notion into an operations center for a GitHub repo, and handles most of the grunt work with AI. Here's what happens when someone opens an issue:

It shows up in a Triage Queue in Notion
Gemini reads the issue and classifies it — bug or feature, priority level, confidence score
Bugs go to the Maintenance Backlog, features go to the Feature Backlog
If auto-fix is on, it reads through the codebase, figures out a fix, and opens a PR

All I have to do is review the PR and merge.

If you've turned off auto-fix (or want to handle features), there's a CLI:

ghost_maintainer fix 3
ghost_maintainer implement 9

Same pipeline — reads the code, writes a fix, opens a PR.

Setting it up is one command from inside your repo:

curl -sL https://raw.githubusercontent.com/sbis04/ghost_maintainer/main/install.sh \
  -o install.sh && \
  bash install.sh && \
  rm install.sh

You plug in your Notion, GitHub, and Gemini tokens, and it handles the rest — creates the databases, sets up GitHub secrets, pushes the workflows.

There's also a Dart MCP server that pairs with Notion MCP (@notionhq/notion-mcp-server). Hook both up to Gemini CLI or Claude, and you can interact with your backlog in plain English — triage stuff, investigate bugs, ship fixes. 5 tools, 2 resources, 2 prompts.

The Notion workspace

Triage Queue — everything starts here, AI sorts it out
Maintenance Backlog — bugs, with AI summaries and PR links
Feature Backlog — feature requests, ready when you are
Archive — done items land here with timestamps
Project Vision Statement — tells the AI what matters to your project

Video Demo

Link to Code on GitHub

sbis04 / ghost_maintainer

AI-powered junior partner for solo open-source maintainers

Ghost Maintainer

Solo maintainers wear too many hats. Ghost Maintainer takes over the repetitive parts — triaging issues, reading code, writing fixes, and opening PRs — so you can focus on the work that actually needs a human.

It uses Notion as an operations center. Bugs get triaged and fixed automatically. Features queue up until you're ready. Everything stays visible in Notion so you never lose track.

Built with Dart, MCP, Google Gemini, and the Notion API.

Getting Started

You'll need Dart (>= 3.7.0) and GitHub CLI installed.

Grab three API keys before you start:

What	Where	Notes
Notion token	notion.so/profile/integrations	See steps below
GitHub PAT	github.com/settings/tokens	Classic token, `repo` + `actions` scopes
Gemini key	aistudio.google.com/apikey	Any project works

You can either follow the steps in the next section, or have a look at the demo video to learn more about the tool and get step-by-step instruction for installing Ghost…

View on GitHub

Three main pieces:

ghost_maintainer_mcp/ — Dart MCP server. 5 tools, 2 resources, 2 prompts.
notion_setup/ — CLI tool + the GitHub Action scripts.
.github/workflows/ — 4 workflows covering ingestion, triage, implementation, and archival.

The CLI installs globally via dart pub global activate straight from the repo — no need to publish to pub.dev.

How I Used Notion MCP

The whole system runs on two MCP servers working together.

Notion MCP (@notionhq/notion-mcp-server) is the foundation. It's what gives the AI access to the Notion workspace — searching databases, reading pages, creating content, appending blocks. Without it, the AI would be blind to what's going on.

Ghost Maintainer MCP sits on top of that. It's a custom Dart server that adds the maintenance-specific stuff — ghost_triage_issue, ghost_investigate_issue, ghost_deploy_fix. The prompts are written to use both servers together. The triage prompt, for instance, tells the AI to search for duplicates through Notion MCP before classifying, and to append its analysis notes to the Notion page afterward.

Ghost Maintainer also exposes a couple of resources that pull from Notion — ghost://vision grabs the Project Vision Statement, and ghost://backlog/summary aggregates stats across all the databases. These save the AI from having to navigate the workspace manually every time.

Everything lives in Notion. The Triage Queue, backlogs, and archive are all databases with properties like Stage, Priority, Labels, AI Summary, and PR URL. The Vision Statement is a regular Notion page — update it and the AI adjusts. If you write "security issues are always P0" in there, that's exactly what happens.

PRs link back to the Notion page. When they get merged, the item auto-archives with a date.

The GitHub Actions pipeline handles the automated side (new issue triggers triage, etc.), but the MCP layer is what makes it interactive. Connect both servers to Gemini CLI and you get conversations like:

You: "What's in the backlog?"
AI: [uses ghost://backlog/summary] "3 bugs, 2 features..."

You: "Any duplicates for the dark mode request?"
AI: [uses Notion MCP search] "Found a similar one from last week."

You: "Triage the login crash"
AI: [uses ghost_triage_issue] "Bug, P1-High."

You: "Fix it"
AI: [uses ghost_investigate_issue + ghost_deploy_fix] "PR #15 created."

The thing I like about this is that Notion ends up being the shared workspace for both me and the AI. I open Notion and see what's going on. The AI checks the same workspace through Notion MCP. Same board, same data, no surprises.

WanderXP — Organize your travel with ease

Souvik Biswas — Mon, 20 Feb 2023 16:09:40 +0000

Overview

It's always a hassle to manage all the necessities while deciding a travel plan. What if you could keep everything organized inside a single app?

WanderXP helps you to keep your travel requirements organized including flight and hotel details, and the notable places that you don't want to miss visiting.

Category Submission:

Integration Innovators

App Link

The app is designed for mobile platforms (small form factor), but as Flutter is used for building so it's a cross-platform app capable of running on Android, iOS, Windows, Linux, and Web.

Web app link: https://wanderxp.flutterflow.app

Please scale the window to mobile form factor while running on web.

Mobile app link (Android): https://appdistribution.firebase.dev/i/a0b42613bd16e37e

Please try this for better experience, as it's optimized for mobile platforms.

You can also follow the steps on the GitHub project page if you want to try out the app on other platforms.

Project Description

The primary features of the app are as follows:

Store multiple trip information (travel start & end dates, flight info, hotel info, places to visit during the trip).
Upload documents in a organized manner (like flight and hotel booking documents).
Secure user management with a robust authentication system.
Discover new suggestions for popular places to travel.

Architecture

Here's an overview of the entire architecture of the cross-platform application along with the backend infrastructure built with Flask and managed on Linode:

The tech stack used for building this project:

FlutterFlow: It's a no-code platform that I have used for designing the app from scratch, connecting with the REST API, and then generating the source code in Flutter.
Flask: Used for building the REST API to manage user authentication, database CRUD operations, and storing files.
Linode: For getting access to the cloud computing infrastructure along with their managed database (SQL) and object storage.

Frontend app

The Flutter application consists of the following screens/pages:

SplashScreen
HomePage
LoginPage
SignUpPage
DiscoverPage
TripViewPage
CreateTripPage
FlightInfoPage
HotelReservationPage
PlacesToVisitPage
TripPage
EditProfile

Backend REST API

The REST API built with Flask mainly consists of the following endpoints:

/register: To create account for a new user.
/login: To log in an already registered user.
/places: Fetching all the top places to discover.
/place: To retrieve a single place with the ID.
/places_to_visit/<trip_id>: Retrieve all the places to visit by the provided trip ID.
/trips/<trip_id>: Retrieve a single trip by its ID.
/trips/<trip_id>/update: Update the details of a trip.
/trips: Retrieve and store trip based on the uid (Unique user identifier) provided.
/store_file: For storing a file to the Object Storage.
/get_file: For retrieving a file from the storage.

Linode

Overview of the Linode Cloud Console:

Managed Database using MySQL v8 for storing user data, trips, places, and more:

Object Storage used for storing user flight and hotel booking files:

Link to Source Code

The entire app is open sourced - try it out and also feel free to contribute to this project 😉 :

sbis04 / wander_xp

Organise your travel with ease

WanderXP

Blog post about this project: https://dev.to/sbis04/wanderxp-organize-your-travel-with-ease-205d

Try out the app (Android): https://appdistribution.firebase.dev/i/a0b42613bd16e37e

Try out the app (Web): https://wanderxp.flutterflow.app

WanderXP helps you to keep your travel requirements organized including flight and hotel details, and the notable places that you don't want to miss visiting.

Architecture

Here's an overview of the entire architecture of the cross-platform application along with the backend infrastructure built with Flask and managed on Linode:

The tech stack used for building this project:

FlutterFlow: It's a no-code platform that I have used for designing the app from scratch, connecting with the REST API, and then generating the source code in Flutter.
Flask: Used for building the REST API to manage user authentication, database CRUD operations, and storing files.
Linode: For getting access to the cloud computing infrastructure along with their managed database (SQL) and object storage.

Screenshots

License

Permission…

View on GitHub

Permissive License

The project is licensed under the MIT License.

Background

To most people the problem with travel management might not seem that hard to solve. But upon searching we found that there's very limited applications available on the market that provides a minimalist UI and also gets the job done.

The second reason behind building a travel management app was that I wanted to learn how to use Linode, and this seemed to me a very good usecase of Managed Database and Object Storage services provided by Linode.

How I built it

I have mainly used three services provided by Linode:

Shared CPU: I used a Ubuntu 22.04 shared compute instance.
Managed Database (with MySQL v8.0.26): For storing user data, location information and the trips planned by each user. I have also designed a robust email-password authentication system
Object storage: For storing the trip documents like flight bookings and hotel reservation files.

This was my first time using Linode for managing the backend of a mobile application. And, the entire integration process was pretty smooth for me (some of the documentation pages helped a lot).

This hackathon helped me to learn how to build a end-to-end product (consisting of a frontend, backend, and cloud server). Thanks to Linode & DEV team for organzing this hackathon! 🙂

One suggestion of improvement: "It would have been a lot faster while working with the Managed Database if there was a SQL viewer/editor inside the Linode Cloud Console (I spent a lot of time authenticating into the database locally and then running the SQL command to view the table data every time while testing the queries from the mobile app)"

Additional Resources/Info

Some resources that helped while working on this project are as follows:

Slibro — a story writing platform

Souvik Biswas — Thu, 12 May 2022 20:19:22 +0000

Overview

Slibro is a story writing platform that supports short and long format stories. Flutter and Appwrite is used to create this amazing cross-platform experience.

Try out the app on Android from here.

The inspiration behind this idea is to simplify the process of story writing, formatting, and publishing to reach a wider audience. Whether you just getting started with your first story or a seasoned writer, Slibro has got you covered!

Submission Category:

Mobile Moguls

Link to Code

The app is completely open sourced, have a look around the code and also feel free to contribute to this project 😉 :

sbis04 / slibro

Platform for story writers and publishing houses

Slibro

Slibro is a story writing platform that supports short and long format stories. Flutter and Appwrite is used to create this amazing cross-platform experience.

Try out the app on Android from here.

Usage

To run this from your system, you should have:

Flutter SDK installed and configured on your system.
Setup Appwrite using Docker.
Host the server locally using ngrok.

Under lib directory, create a secret.dart file, and add the server URL and Appwrite project ID to it. Example:

class Secrets {
  static String hostname = 'https://127b-203-163-244-125.in.ngrok.io/v1';
  static String projectID = '6276341092e81e829ab0';
}

Run using the following command:
```
flutter run
```

App Overview

The app now has full-fledged story editor (rich text - markdown), story reader, and story management system (to manage published/unpublished stories and explore other publisher's stories).

Some glimpses of Slibro's user interface are as follows:

The above four screens cover the authentication…

View on GitHub

How it started

I initially started working on the idea of this app by creating rough UI sketches and notes ...

... also some database structures.

How it's going

Some glimpses of Slibro's user interface are as follows:

The above four screens cover the authentication flow on the app using email/password method. These screens help a user to either create a new account or login using an existing account. Once a user signs up to the app, it navigates to the story creation flow.

These screens help a user to create the first story as a draft in the Slibro app. The user can also publish the story if wanted.

The editor and the reader screens are the most important ones, the editor also has rich text support using Markdown.

The three screens (Home, My Stories, and My Profile) shown above are part of the dashboard of the app, user can navigate to any of these using the Navigation bar accessible from these pages.

Navigation bar has a subtle animation to improve the UX of the app:

Project Description

In this project, three of the major Appwrite APIs are used:

Account API: Used for implementing user authentication and user data management.
Database API: Used for storing app data related to stories and chapters.
Storage API: Used for storing the Rich Text story file in JSON format.

The Flutter plugins used:

The Appwrite console view:

Two databases are used for this project: (1) stories, and (2) chapters.

Stories database documents preview:

Stories database attributes:

Chapters database attributes:

The files storage preview (the chapters are stored as JSON rich text files):

References

Decifer — Generate transcripts from audio using Flutter and Deepgram

Souvik Biswas — Sat, 02 Apr 2022 18:40:59 +0000

Overview

Decifer is a cross-platform mobile app that helps to generate transcripts either from a voice recording or by uploading an audio file.

Try out the app: https://play.google.com/store/apps/details?id=com.souvikbiswas.deepgram_transcribe

Typically, for using Deepgram API you would require to maintain a server but I have made this project totally serverless. To know more continue reading.

Here's a brief demo of the entire app in action:

Submission Category:

Analytics Ambassadors

Link to Code on GitHub

The entire app is open sourced - try it out and also feel free to contribute to this project 😉 :

sbis04 / decifer

Generate your audio transcripts with ease.

Decifer

Blog post about this project: https://dev.to/sbis04/decifer-generate-transcripts-with-ease-5hl3

Try out the app: https://appdistribution.firebase.dev/i/a57e37b2fda28351

A cross-platform mobile app that helps you to generate transcripts either from a voice recording or by uploading an audio file. The project uses a totally serverless architecture.

Architecture

The mobile app is created using Flutter which is integrated with Firebase. Firebase Cloud Functions is used to deploy the backend code required for communicating with the Deepgram API.

App overview

The Flutter application consists of the following pages/screens:

Login Page
Register Page
Dashboard Page
Record Page
Upload Page
Transcription Page

For authenticating the user inside the app -- Login and Register pages are used. Authentication is required to generate unique accounts for users required for storing the generated transcripts to Firestore and facilitate cloud-sync.

The Dashboard Page displays a list of all the transcripts currently present on the user's account. It also has two buttons -…

View on GitHub

Project Description

The primary features of the app are as follows:

Generate transcript from audio recording & audio file using Deepgram API.
Cloud-sync for syncing across multiple devices using the same account.
Transcribe confidence map view.
Export as PDF and share with anyone.

Architecture

I'm using a totally serverless architecture for this project 🤯, let's have a look how it works:

The mobile app is created using Flutter which is integrated with Firebase. I have used Firebase Cloud Functions to deploy the backend code required for communicating with the Deepgram API.

Firebase Cloud Functions lets you run backend code in a severless architecture.

I have deployed the following function to Firebase:



const functions = require("firebase-functions");
const {Deepgram} = require("@deepgram/sdk");

exports.getTranscription = functions.https.onCall(async (data, context) => {
  try {
    const deepgram = new Deepgram(process.env.DEEPGRAM_API_KEY);
    const audioSource = {
      url: data.url,
    };

    const response = await deepgram.transcription.preRecorded(audioSource, {
      punctuate: true,
      utterances: true,
    });

    console.log(response.results.utterances.length);

    const confidenceList = [];
    for (let i =0; i < response.results.utterances.length; i++) {
      confidenceList.push(response.results.utterances[i].confidence);
    }

    const webvttTranscript = response.toWebVTT();

    const finalTranscript = {
      transcript: webvttTranscript,
      confidences: confidenceList,
    };

    const finalTranscriptJSON = JSON.stringify(finalTranscript);
    console.log(finalTranscriptJSON);

    return finalTranscriptJSON;
  } catch (error) {
    console.error(`Unable to transcribe. Error ${error}`);
    throw new functions.https.HttpsError("aborted", "Could not transcribe");
  }
});

The getTranscription function takes an audio URL, generates the transcripts using Deepgram API along with the respective confidences, and returns the data in a particular JSON format (that can be parsed within the app).

App screens

The Flutter application consists of the following pages/screens:

Login Page
Register Page
Dashboard Page
Record Page
Upload Page
Transcription Page

The Dashboard Page displays a list of all the transcripts currently present on the user's account. It also has two buttons - one for navigating to the Record Page and the other for navigating to the Upload Page.

Record Page lets you record your audio using the device microphone and the transcribe it using Deepgram. You always have an option to re-record if you think the last recording wasn't good.

From the Upload Page, you can choose any audio file present on your device and generate the transcript of it.

Transcription Page is where the entire transcript can be viewed. It has an audio-transcript synchronized playback that highlights the text transcript part with respect to the audio that is playing.

You can also see the confidence map of each of the parts of the transcript (it shows how much accurate is that part of transcript generation - darker is higher confidence).

You can also easily print or share the generated transcript in the PDF format.

Deepgram

Overview of my Deepgram dashboard (completed the mission, Get a Transcript via API or SDK):

Usage analytics of the Deepgram API:

Log of one of the API calls for transcribing from audio:

References

Plant Monitor - Using IoT, MongoDB and Flutter

Souvik Biswas — Wed, 12 Jan 2022 17:58:56 +0000

Overview

Plant Monitor is an IoT-based project for monitoring plant health with ease. The projects consists of three parts:

IoT: Sensors (for monitoring plant data)
Database: MongoDB (Atlas, Realm and Chart)
Cross platform mobile app: Flutter (for getting realtime plant data)

Submission Category:

Action Star

Link to Code

The code for both the app and the IoT part is present in the following GitHub repo:

sbis04 / plant-monitor

Plant monitoring system using IoT, MongoDB, and Flutter

Plant Monitor

IoT based plant monitoring system which is connected to MongoDB. This is a Flutter app to display the realtime data from the sensors attached to the plant on a mobile device.

License

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

View on GitHub

Project Description

A detailed description of all the three parts of this project is present below.

IoT: Sensors

ESP32 module is used for collecting data, processing and uploading to the MongoDB database. It is a low powered microcontroller integrated with WiFi and Bluetooth.

DHT11 sensor is used for measuring raw temperate and humidity data from the surroundings of the plant.

LDR is used for calculating the light intensity that the plant is receiving.

Soil Moisture sensor module is used to measure the moisture or the water level of the soil. The sensor includes a potentiometer to set the desired moisture threshold.

Database: MongoDB

MongoDB Atlas provides cloud database service using AWS, Azure, and Google Cloud. It also has various automation tools for performing various backend functionalities and comes with visualization tools. The services that are used in this project are described below.

Atlas is used as the main cloud database for storing the sensor readings along with timestamps.

Realm Function is defined to easily store the sensor data from the ESP32 module. A HTTP Endpoint is created to access the MongoDB database from the ESP32.

The following function is used for storing the sensor data:

exports = function(payload){
    var atlas = context.services.get("mongodb-atlas");
    var coll = atlas.db("plantdata").collection("readings");
    try {
      if (payload.body) 
      {
        body = EJSON.parse(payload.body.text());
      }
      coll.insertOne(body);
      console.log(body);
    } catch (e) {
      console.log("Error inserting doc: " + e);
      return e.message();
    }
};

Charts are used to visualize the sensor readings directly inside the MongoDB web app.

For this project I have created four charts:

Plant Light (%): Amount of light intensity plant is receiving
Plant Humidity (%): Humidity around the plant
Plant Moisture (%): Amount of water present in the soil
Plant Temperature (°C): Current temperature around the plant

Mobile app: Flutter

To use the Realm data inside the Flutter application I have created a modified version of the flutter_mongodb_realm plugin to support Dart null safety and run it on the latest version of the Flutter SDK.

References

Flutter: Custom Painter | PART-1

Souvik Biswas — Thu, 23 Apr 2020 10:30:07 +0000

You might have seen a lot of apps having highly customized designs and amazing animations. It is really time-consuming and painful to achieve that level of customization on a native Android and iOS apps.

Flutter has got your back. With the help of CustomPainter combined with the legendary Hot Reload feature of Flutter you can iterate upon your creations efficiently and fast.

In this series, I will start with the basics of painting using CustomPainter (drawing basic shapes) in the first few parts, and then I will go into the complex designs.

NOTE: The series will involve some basic concepts of mathematics (mainly Trigonometry and Coordinate Geometry).

So, let's get started.

Initial App Structure

The basic structure of the app will just consist of a Scaffold having an AppBar, and a CustomPaint widget in the body.

class MyPainter extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Custom Painter'),
      ),
      body: CustomPaint(
        painter: ShapePainter(),
        child: Container(),
      ),
    );
  }
}

CustomPaint Widget Properties

Some of the most important properties of the CustomPaint widget are:

painter: The painter that paints before the child.
foregroundPainter: The painter that paints after the child.
child: The canvas will by default take the size of the child, if it is defined.
size: If the child is not defined, then the size of the canvas should be specified.

For getting started with the basic shapes, you will just need two of these properties:

painter
child

In the previous code snippet, I have defined a Container as the child. As you might know, Container by default takes up the entire size of the screen when there is no child specified within it.

Intro to CustomPainter

Now, you have to define the ShapePainter widget which should extend the CustomPainter class.

paint: This method is called whenever the object needs to be repainted.
shouldRepaint: This method is called when a new instance of the class is provided.

class ShapePainter extends CustomPainter {
  @override
  void paint(Canvas canvas, Size size) {
    // TODO: implement paint
  }

  @override
  bool shouldRepaint(CustomPainter oldDelegate) {
    // TODO: implement shouldRepaint
    return null;
  }
}

Deep dive into paint method

The paint method has two parameters:

canvas
size

If we have a child specified inside the CustomPaint widget, then the canvas will have the same size as that. In our case, the canvas area will take the size of the entire Container.

The Canvas Area uses a coordinate system in order to located positions and they can be connected in various fashion in order to generate different custom shapes.

By default, the origin (0, 0) is located at the top-left corner of the canvas, and with respect to it all the drawings are done as the painter starts from the origin.

Conclusion

I believe you have enjoyed this first part of the series which should have given you a good insight into the small concepts of CustomPainter and the Canvas.

From the next article onwards, we will start painting on this canvas. And trust me you will love Flutter for this.

I also write articles on Medium and Codemagic Blog. You can follow me on Twitter and find some of my projects on GitHub. Also, don’t forget to check out my website.

Thank you for reading!