DEV Community: sonu0702

Momentloom: Let the right video find you

sonu0702 — Sat, 24 Oct 2026 08:40:30 +0000

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

Every Short starts with a small question: which video is worth my time?

One long YouTube video can hide a dozen good moments, or none. Finding out means searching, opening tabs, skipping around, and only then starting the edit. After that come the crop, captions, hook, title, and description. Do it once and it is manageable. Do it for every video, every week, and the setup becomes its own job.

I wanted to move that work into the background. Momentloom starts before the editing timeline: it looks for source videos, prepares possible clips, and leaves me with the decision that still needs a person, what is worth sharing.

What I Built

Momentloom is a local-first app that finds promising YouTube videos and turns their strongest moments into Shorts that are ready for review and posting.

The workflow can start with a topic or keyword. Momentloom gathers YouTube candidates, adds trend context where available, and ranks the results with an explainable Hype score. It helps prioritize candidates; it is not a probability estimate of virality. Searches can be saved and scheduled with a cron expression, country, language, and video-length filters. With Auto-shorts enabled, a schedule can send its top eligible result into the clip queue while another video is being processed.

For each source video, Momentloom transcribes the speech, looks for distinct moments that can stand on their own, and makes clips under 60 seconds. The number of clips depends on the moments it finds, rather than a fixed count. It can also choose a framing treatment for one face, two speakers, or a screencast, then burn in word-level captions in one of 17 styles.

Each clip comes with a spoken-word hook, a YouTube title, and descriptions for sharing. Momentloom prepares the package; a person still chooses what to post. It does not publish directly to a channel.

Demo

Watch Momentloom find videos and prepare Shorts

Code

Explore Momentloom on GitHub

sonu0702 / momentloom

Reward your laziness: Momentloom automatically searches YouTube for trending videos by topic or keyword, turns standout moments into ready-to-post Shorts, and repeats on your schedule. Come back to finished clips with captions, hooks, titles, and descriptions ready for your channel.

Momentloom

Reward your laziness: Momentloom automatically searches YouTube for trending videos by topic or keyword, turns standout moments into ready-to-post Shorts, and repeats on your schedule. Come back to finished clips with captions, hooks, titles, and descriptions ready for your channel.

View or edit the Excalidraw source.

Features

Create clips from a public YouTube video or an uploaded video.
Find a variable number of distinct moments, each under 60 seconds.
Reframe automatically for one face, two speakers, or a screencast.
Add a spoken-word hook and choose from 17 caption styles.
Search YouTube, rank Hype results, and schedule searches that can queue videos for clipping.
Keep job history, videos, transcripts, and clips in a persistent local data folder.

Quick Start

Requirements

Docker Desktop
Ollama for Gemma-assisted moment selection and visual framing (optional)

Model setup

Gemma is optional. To use the default model, start Ollama and download it:

ollama pull gemma4:e4b

…

View on GitHub

To run it locally, clone the repository, copy .env.example to .env, and start the Docker Compose app:

git clone https://github.com/sonu0702/momentloom.git
cd momentloom
cp .env.example .env
docker compose up --build -d

Then open http://localhost:8001. The README includes the cmd for creating .env and explains the optional local model setup.

How I Built It

The app is one repository with a React and Vite frontend and a Python FastAPI backend. Docker Compose runs the app alongside OpenSERP, which supplies related web results for discovery. SQLite keeps job state, search snapshots, schedules, and clip metadata. Large source videos and rendered clips stay in files on the user's computer, so rebuilding the Docker image does not erase them.

For discovery, OpenSERP provides trend context and PyYtSearch expands relevant phrases into YouTube candidates. A Python ranker combines the available signals into the Hype score. Search and clip ranking are separate: the Hype score ranks candidate videos; the clip pipeline estimates which moments in a selected video are worth cutting.

For clip creation, yt-dlp obtains a public YouTube source when needed, FFprobe reads its media properties, and faster-whisper transcribes speech locally with word-level timestamps. Gemma can suggest a visual layout, score transcript windows, propose clip boundaries, and draft titles, descriptions, and hooks. Python validates the response, aligns boundaries to words, removes duplicate moments, and enforces the under-60-second limit. OpenCV and MediaPipe handle local face tracking for reframing. FFmpeg renders the clips and libass burns in the timed captions.

Gemma is served through Ollama's OpenAI-compatible API. The endpoint and model are configurable:

LLM_BASE_URL=http://host.docker.internal:11434/v1
LLM_MODEL=gemma4:e4b

If Gemma is unavailable or returns unusable output, Momentloom falls back to local transcript heuristics and safe framing defaults. The app still runs; the model improves the editorial suggestions rather than becoming a single point of failure.

Why Does Open Innovation Matter?

This workflow touches a lot of media, and the judgment calls are personal. I want to be able to choose which model helps make them, where it runs, and what happens when it is unavailable.

Using an open-weight model through Ollama makes local inference a practical option. The model setting can be changed without rebuilding the product around one provider. The pipeline is also inspectable: Gemma suggests moments and copy, while ordinary Python code validates clip boundaries, applies the length limit, and calculates the separate Hype ranking. That division makes it easier to understand what the model decided and what the application enforces.

Open innovation made it possible to build an end-to-end tool around a model I can run and configure myself, while keeping the fallback path usable. The result is not a black box that declares something viral. It is a repeatable assistant that finds candidates, prepares edits, and leaves the final choice with me.

The Lazy Payoff

I do not have measured before-and-after hours to claim, so I will not invent a time-saved number. The payoff is in the repeated steps Momentloom can take off my hands: search on a schedule, keep the results, queue an eligible video, and return to clips with captions and posting copy already prepared.

That is the kind of laziness I wanted to reward. I still make the taste call. I just do not have to begin every time by doing all the same setup work again.

Prize Categories

Best Use of Gemma — Gemma helps analyze transcript windows and propose clip boundaries and publishing copy, with local fallbacks when the model cannot help.

GST Helper: a local-first GSTR-1 preparation assistant

sonu0702 — Sun, 18 Oct 2026 05:04:23 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

I built GST Helper, a local-first AI workspace that helps a small business prepare selected GSTR-1 values from sales invoice PDFs.

The demo company is BharatBiz, a fictional small business based in Bengaluru. The user starts by loading outward-sales invoice PDFs. GST Helper reads the invoices, extracts values, shows page evidence, and turns the documents into a guided GSTR-1 review flow.

The current app prepares these GSTR-1 sections:

Table 4A regular domestic B2B invoices
Table 12 B2B HSN/SAC summary
Table 13 document numbers issued

It shows the invoice value including tax, taxable value, IGST, CGST, SGST or UTGST, cess, total tax, and invoice count for the supported B2B scope. It also creates a reference PDF tied to the saved review revision, so the user can inspect the same values before downloading the file.

The problem is simple: small business owners and bookkeepers often do this first pass manually. They read invoice PDFs, copy values into spreadsheets, check invoice numbers, and then use those figures while working in the GST Portal. That work is slow, error-prone, and full of accounting language that is not friendly to a non-expert.

GST Helper is meant for a small business owner, bookkeeper, or accountant who wants a faster way to prepare and review the numbers before portal entry. The paid version could charge for private local workflows, more GST sections, accountant review packs, and better import and export support.

The app does not file a return, connect to the GST Portal, or claim that the whole GSTR-1 return is complete. Other GSTR-1 sections must be handled separately. That boundary is visible in the product because tax software needs trust more than magic.

Demo

Video demo: https://youtu.be/RFq9whXetRg

The demo shows the full BharatBiz flow:

Load sample sales invoice PDFs.
Confirm the seller GSTIN, tax period, and turnover band.
Review invoice fields with page evidence.
Save the reviewed values.
Inspect the Table 4A totals.
Generate a verified reference PDF.
Use the review chat beside the final PDF.

Code

Repository: https://github.com/sonu0702/pgst

sonu0702 / pgst

GST Helper

GST Helper is a local-first GSTR-1 preparation app for BharatBiz, a fictional small business based in Bengaluru. It turns outward-sales invoice PDFs into reviewed values, a clear summary for the supported GSTR-1 sections, and a reference PDF the user can inspect before downloading.

This release prepares only regular B2B invoices in Table 4A, the B2B HSN/SAC summary in Table 12, and documents issued in Table 13. It does not prepare a complete GSTR-1 return, connect to the GST Portal, submit or file a return, or decide GST treatment. Other applicable GSTR-1 sections must be prepared separately. The GST Portal accepts a JSON workflow through its offline tool, but the portal still validates the account and return when the user uses that file.

What the app does

Starts with outward-sales PDFs, then suggests seller GSTIN and tax period with page evidence before asking for return details.
Shows observed invoice-number…

View on GitHub

How I Built It

The app is a single repository with a React frontend and a FastAPI backend.

Tech stack:

Frontend: React, TypeScript, Vite
Backend: Python, FastAPI
Local AI: Ollama with Gemma 4
PDF processing: Python PDF extraction with optional local OCR support
Export artifacts: reference PDF and supported-section JSON
Storage: no database in this prototype. Reviews live in temporary process memory.

The user flow starts with source documents, not a chatbot. That choice matters. Invoices are the source of truth, so the app first reads the PDFs and creates a review workspace from them.

The backend extracts invoice fields and line items, keeps compact evidence snippets, and builds a temporary GSTR-1 review case. The frontend lets the user inspect and edit each value. When the user saves, the backend runs local checks for the supported sections and returns readiness results.

Gemma 4 is used through Ollama for a narrow review task. It can answer questions about values already in the review or prepare a proposed edit from invoice evidence or from a value the user states. It cannot decide tax treatment, calculate GST, approve filing, or submit anything.

The user stays in control:

The model proposes changes.
The user applies the proposal.
The user reviews the form.
The user saves the revision.
The user regenerates the PDF if anything changed.

The reference PDF is tied to the saved revision. The app renders the PDF back in the browser and verifies the expected content before the user downloads it.

Why Does Open Innovation Matter?

Open innovation matters here because tax preparation needs transparency, local control, and the ability to inspect the workflow.

A closed hosted API can produce a polished answer, but that is not enough for this use case. A small business owner needs to know where a number came from and what the app did with the source document. GST Helper keeps the review path visible: invoice evidence, editable fields, saved revision, local checks, and a reference PDF.

Open-weight local AI also changes the privacy story. In this prototype, Gemma 4 runs locally through Ollama. The app does not need to send invoice details to a hosted model API. That made it possible to build an AI-assisted review flow that still respects sensitive business documents.

Open-source tools also made the project practical for a hackathon:

FastAPI made the backend small and inspectable.
React and Vite made the review UI fast to iterate.
Ollama made local Gemma 4 setup approachable.
Python PDF tooling made extraction and reference PDF generation possible without building a document pipeline from scratch.

The project is not trying to replace a tax professional or the GST Portal. It is trying to make the preparation step clearer, safer, and more reviewable.

My Agent Session

I used Codex as an AI coding agent throughout the build. The agent helped with product scoping, GSTR-1 flow design, FastAPI and React implementation, sample invoice generation, UI polish, PDF review, and the demo walkthrough.

The most useful part was not code generation alone. The agent helped keep the product narrow. Whenever the app started to look like a generic invoice-review demo, I pushed it back toward one clear filing workflow: GSTR-1 preparation from sales invoices.

That made the final project stronger. It has a specific user, a specific filing task, a clear supported scope, and visible review boundaries.

Prize Categories

gemma

Team

This is a team submission. Published by @sonu0702.

Teammates:

Use Copilot CLI to increase developer productivity

sonu0702 — Thu, 12 Feb 2026 12:06:42 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I used Copilot CLI and Copilot SDK to create a CLI application 🖥️ called DevScope.
DevScope is a macOS-first, privacy-focused CLI tool that helps developers understand how they actually spend their time across applications, terminal commands, and browser activity.

Demo

Github code - https://github.com/sonu0702/devscope

My Experience with GitHub Copilot CLI

😌 The Problem

Developers generate a lot of activity data:

App usage
Terminal commands
Browser research
Commits and tooling

But raw metrics do not answer higher-level questions about focus, intent, or progress. Existing tools either:

Focus on generic screen time
Hide logic behind opaque dashboards
Or do not integrate with developer workflows

DevScope is designed to live in the terminal, stay transparent and explainable, and treat Copilot as a thinking partner instead of just autocomplete.

🚀 GitHub Copilot is used in two distinct ways:

During development

Writing macOS automation scripts
Parsing Chrome history
Designing CLI workflows
Refactoring collectors and reports

At runtime (Copilot SDK)

Acting as a reasoning agent
Summarizing and interpreting developer activity
Providing goal-aware insights directly in the terminal

This project demonstrates how Copilot can be both a developer tool and a product feature.

Why an Agent?

Raw metrics like “time spent” or “commands used” do not answer higher-level questions such as:

Was I actually focused today?
Did my work align with my goals?
What kind of development work did I do?

To solve this, DevScope is designed to integrate the GitHub Copilot SDK as a reasoning layer on top of locally collected activity data.

This application is in initial stage everyone is welcome to contribute with Idea or code.

A low maintenance Portfolio

sonu0702 — Sat, 24 Jan 2026 15:05:14 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

Hey guys I am a software engineer. I am a sort of minimalist. I have build my portfolio app several times but it kind of gets lost once I am done with building phase. I have tried to build a portfolio that do not feel like a work to keep it upto date.

Portfolio

How I Built It

I used AI Studio and built it using Google's Gemini models - Gemini 3 to be specific and deployed it on Cloud Run. Google AI tools makes very convenient to do multiple iteration and this is very important since I get bored with UI/UX of portfolio very easily so I think this is best thing that has happened to me, I can keep on updating the portfolio design, UX depending on my mood. And one click deployment is cherry on cake!
Tech stack wise the backend I can say it is github. I am fetching the data from my personal github repo, Since it is easy to maintain the data on github, just press '.' your portfolio data is ready to be updated, just change and update.
I like to write blogs (not frequently) but I wanted a centralised system for all my blogs. So in my portfolio The Articles are dynamic they are fetched from my github repo as well.

What I'm Most Proud Of

Most proud of fact that I have achieved a sense of ease to update UI/UX using AI studio when ever I want since earlier it used feel like a chore a small feature development lifecycle. I have also made sure that this time my portfolio has dynamic content that can be changed from the github repo.