DEV Community: Komal deep

“I’ll Do It Tomorrow” Is Predictable, So I Built a Model to Predict It

Komal deep — Mon, 26 Oct 2026 06:57:27 +0000

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

What I Built

I have been a procrastinator for as long as I can remember. It's a habit that feels baked into me from the start.

I've tried the standard fixes. The 15-minute rule: just start, and you can stop after fifteen minutes. Timers. Announcing my plans out loud so someone would hold me to them. Honestly, they work. I get started, I stay on task, and I finish things I would once have avoided for weeks.

I still procrastinate, though. What changed is the amount, not the habit. And the habit has cost me real things: missed deadlines, and some opportunities that never came back.

At some point I noticed something strange. Every productivity tool I used tracked what I finished. None of them told me what I was about to postpone. All the effort went into the plan, and none went into asking whether the plan would survive a bad day.

That's how Slothcast 🦥 started. It's a deadline-risk forecast for your own planned work. Each night you log what you plan to do tomorrow, with the duration, how close the deadline is, and how much energy you expect to have. The next day you record whether it happened. Slothcast learns from that history and tells you the chance that tomorrow's plan slips. Then it shrinks the plan, so a bad day still counts for something.

Weather forecasts don't stop the rain, but they tell you to carry an umbrella. A procrastination forecast should do the same for your calendar.

Demo

Live app: https://slothcast.onrender.com

The app opens on synthetic demo data until you have a real log, and it flags that data clearly so a demo number is never mistaken for your real behavior. (It's on a free Render instance, so the first load may take a few seconds to wake up.)

You can also run it locally:

python -m venv .venv && source .venv/bin/activate
make install
make test
make sample        # synthetic demo log, clearly tagged as synthetic
make eval-sample   # chronological evaluation, written to results/
make demo          # opens the dashboard

To use it for real:

slothcast log --task "DSA block" --minutes 120 --deadline-days 3 --energy 3
slothcast done --date 2026-10-22 --done 1
slothcast eval
slothcast forecast --task "DSA block" --minutes 120 --deadline-days 3 --energy 3

Code

GitHub: https://github.com/KomalDeep355/Slothcast

Live app: https://slothcast.onrender.com

MIT licensed, with about 40 tests and a Makefile.

How I Built It

Forecasting, not coaching

Most "AI productivity" apps hand your to-do list to a chatbot and ask it for advice. I wanted the opposite. Slothcast puts a real, testable prediction at the center, and the language model only helps explain it. That one decision shaped everything else, and it's why I wrote the rules below into the code instead of only promising them in a README.

Data, labeled by how much I trust it

The log is a simple CSV: date, planned task, planned minutes, days to deadline, energy (1-5), and whether it was completed. The labels come from three places:

A nightly check-in. I plan tomorrow in the evening and record the outcome the next day. These labels are marked verified.
GitHub commits. An optional ingester counts my commits. If I left a day blank, commits can infer an outcome, but that label is tagged inferred and never mixed up with a verified one.
Backfilled history. I can import old milestones from a CSV. These default to inferred.

Demo data is tagged synthetic. Every label keeps its provenance, and the evaluation also reports results on verified labels alone whenever there are enough of them. I didn't want my model quietly learning from guesses I couldn't trust.

No leakage from the future

For a forecasting project, the easiest way to cheat is to let the future leak into the past. In Slothcast, the features for day i only see outcomes from before day i. Evaluation is rolling-origin: train on the past, test on what comes next, and move forward. Nothing is shuffled. Both rules are unit-tested, because a shuffled split on time-ordered habit data gives you beautiful, meaningless numbers.

The data-sufficiency gate

This is the part I'm proudest of. A model trained on five days of your life isn't a forecaster, it's a coin flip with a confident voice. So Slothcast has a gate:

Under 15 labelled days (or fewer than 4 of either outcome), it shows "Not enough history yet" instead of a probability.
15 to 29 days is labelled preliminary.

Showing nothing is a feature here. A tool that always has an answer isn't being honest.

TabPFN versus honest baselines

The model at the center of the project is TabPFN, a pretrained model built for small tabular datasets, which is exactly what a personal habit log is. A few weeks of check-ins is tiny data. Classic models struggle with that, and a pretrained model might help.

But I didn't want to assume it. Slothcast compares TabPFN against five baselines: the base rate, "same as yesterday", the weekday rate, logistic regression, and a random forest. TabPFN has to beat them. The evaluation reports the Brier score, calibration, a learning curve by history length (how much data does the fancy model need before it's worth it?), and a bootstrap interval for the gain over the base rate. If TabPFN doesn't win, the report says so.

TabPFN runs locally. The first fit downloads the open weights, and after that it works offline.

A local Gemma planner

Once the forecast gives a risk label, a local Gemma model (gemma3:4b through Ollama) turns it into a plan. A risky task becomes a smaller, concrete first step. If Ollama isn't running, Slothcast falls back to a deterministic template plan and tells you it did.

The LLM is never allowed to write a number

This is my favorite guardrail. agent/guardrails.py rejects any percentage, decimal probability, or odds that the model didn't get from the forecasting model. If Gemma invents a "73% chance", the output is thrown away and the template plan is used instead.

A language model that confidently makes up statistics about your behavior is worse than useless, because you'd believe it. The forecast comes from a model that was tested. The words come from a model that was fenced in.

Optional pieces

A hosted habit coach for any OpenAI-compatible provider. It only sends aggregate completion counts, rates, and pattern groups, never task names, and only when you ask for coaching. Without it, the numerical habit forecasts still work.
Temporal to run the nightly job as a durable workflow.
Sentry tracing, where spans carry timings and token counts but never task text.

Stack

Python, Pandas, NumPy, scikit-learn, TabPFN, Gemma via Ollama, Streamlit, Pytest, GitHub Actions, and an MIT license. Temporal and Sentry are optional.

What I Learned

The hard part of a forecasting project isn't the model. It was keeping the future out of the past, keeping guessed labels apart from real ones, and deciding when to say "I don't know". The model was a small part of the work.

Small data needs honesty more than cleverness. With a few dozen data points, a sophisticated model can look great by accident. The learning curve and the bootstrap interval are there to stop me from fooling myself.

Constraining the LLM made the product better. Letting Gemma speak freely was easy. Fencing it in, so it explains evidence but never produces it, is what made the app trustworthy.

It's a mirror, not a judge. I started this to fix my own procrastination. What I ended up with is a way to see my patterns without the shame that usually comes with them.

One thing Slothcast doesn't claim is that its nudges change behavior. Showing that would need an A/B period of nudged versus not-nudged weeks, which only makes sense once the forecast itself works. That's the next step.

Why Does Open Innovation Matter?

A procrastination log is some of the most personal data a person can produce. It records when you avoid things, how tired you were, and what you keep putting off. I wasn't willing to send that to a closed API.

Open models made a local-first design possible:

Gemma runs on my machine through Ollama, so my task history stays there.
TabPFN runs offline after the first download of the open weights, so the forecasting is private too.
It costs nothing to run. No API bill, no usage limit, no account.
I could test it fairly. Because the models are open and local, I could benchmark them against simple baselines and report whatever came out.

One honest note: TabPFN's weights are under Prior Labs' non-commercial license, while the code in my repo is MIT. That's fine for research, evaluation, and a portfolio, but not for a commercial product. I'd rather say that plainly than hide it.

Open innovation also means anyone can fork Slothcast and swap in their own model, their own labels, or their own habits. A procrastination forecaster should be something you can inspect, not something you have to trust.

Prize Categories

Gemma, TabPFN

If you've ever missed something important because you waited "just a little longer", you're not lazy. You're predictable, and predictable can be forecast.

What's the one task you keep postponing? Tell me in the comments. I'm curious whether the forecast would have caught it.

🚨 What breaks when your best engineer leaves? HandoffGraph uses AI and knowledge graphs to uncover hidden dependencies, identify knowledge gaps, and plan smoother handoffs. Because your code should never depend on just one person!

Komal deep — Mon, 19 Oct 2026 14:16:53 +0000

Komal deep

Oct 18

What Breaks When Your Best Engineer Leaves? I Asked a Graph

#ai #webdev #python #opensource

5 min read

What Breaks When Your Best Engineer Leaves? I Asked a Graph

Komal deep — Sun, 18 Oct 2026 18:17:14 +0000

-> TL;DR HandoffGraph loads a repository's Git history into FalkorDB, then an agent walks the graph to answer "what breaks if this person leaves, and who can take over?" Every answer comes with the Cypher it ran and a live subgraph. The agent then acts: it writes a hand-off plan.

💻 Code: [github.com/KomalDeep355/HandoffGraph]

KomalDeep355 / HandoffGraph

HandoffGraph

An agent that finds the files only one person understands, and plans the hand-off before that person leaves.

HandoffGraph loads a repository's Git history into FalkorDB as a knowledge graph of contributors, files and modules. An agent then calls graph tools to answer questions such as which modules depend on one person, what is orphaned if they leave, and who should inherit it. It acts on the answer by writing a hand-off plan. Every answer ships with the Cypher that ran and the subgraph that justified it.

Live demo: https://handoffgraph.onrender.com/

Blog post: https://dev.to/komal_deep_355/what-breaks-when-your-best-engineer-leaves-i-asked-a-graph-4khg

Video link: https://youtu.be/zoFgDCOhXvQ

The problem

Important knowledge in a codebase often sits with one person. A module may have a single recent author, or a file may have no active alternative owner. When that person is unavailable, the team finds out the hard way. Static CODEOWNERS files don't show who has actually worked…

View on GitHub

🌐 Live demo: https://handoffgraph.onrender.com

Where the idea came from

It started with an Instagram reel. I don't remember the names and I can't verify the story, but the gist stuck with me: a company's code depended almost entirely on one developer, because he was the only person who really understood what it was doing. When he left, the team was stuck enough that they had to call him back.

It was told as a joke, and it's funny until it happens to your team. It made me wonder whether you could spot that risk before someone leaves, using the history your repository already has.

The question nobody can answer quickly

Imagine your most experienced maintainer announces a long break, starting Monday.

Which parts of the codebase can nobody else touch?

On most teams the honest answer is a shrug. A CODEOWNERS file tells you who is listed, not who has actually worked on a file recently, and it says nothing about whether anyone else could pick it up. This is key-person risk, better known as the bus factor, and the evidence for it is already sitting in your repository history.

The idea: Git history is already a graph

Every commit says this person changed these files at this time. Add the module each file lives in, and which files tend to change together, and you have a network:

(Contributor) --TOUCHED--> (File) --IN_MODULE--> (Module)
      |                       |
      |                  CO_CHANGED  (files that change together)
      |
  COLLABORATES --> (Contributor)

Asking "what breaks if X leaves?" means following those edges: from a person to their files, from those files to other active people, and from the files up to their modules. That is a traversal. In a relational table, each new follow-up question is more joins and more glue code.

Does the graph really do the work?

The hackathon brief says the graph has to shape what the agent does, not sit on the side. In HandoffGraph, the agent knows nothing about the repository except what FalkorDB returns. Take the database away and every tool has nothing to say.

The agent needs to decide...	FalkorDB feature it uses
Which modules are fragile	`KNOWS` edges aggregated from `TOUCHED`
What is orphaned if X leaves	Multi-hop `OPTIONAL MATCH`, restricted to active peers
Who should take over	`CO_CHANGED` proximity plus direct ownership
Why it reached a conclusion	`shortestPath` from person to module
Who the hubs are	`algo.pageRank` on `COLLABORATES`
Keeping repos separate	One graph per repository (multi-graph)

An honest note on the split: traversals and aggregations run in Cypher. The last bit of ranking arithmetic, like "how many people cover 50% of the knowledge", runs in Python on the rows Cypher returns.

Three queries that carry the project

1. The orphan check. Start at a person, walk to every file they touched, and look for other active contributors on the same files. Files with no real backup are the risk.

MATCH (p:Contributor {id:$id})-[t:TOUCHED]->(f:File)
OPTIONAL MATCH (f)<-[o:TOUCHED]-(q:Contributor)
  WHERE q.id <> $id AND q.active = true
WITH f, t.score AS mine, coalesce(sum(o.score), 0) AS others, count(q) AS active_peers
WHERE mine >= 0.75 AND others <= 0.25 * mine
RETURN f.path, f.module, mine, others, active_peers
ORDER BY mine DESC

2. The explanation. Instead of "trust me", the agent can return the actual chain of evidence:

MATCH (a:Contributor {id:$id}), (m:Module {name:$m})
RETURN shortestPath((a)-[:TOUCHED|IN_MODULE*..3]->(m))

3. The hubs. Graph algorithms as agent tools, not code the agent has to write:

CALL algo.pageRank('Contributor', 'COLLABORATES') YIELD node, score
RETURN node.name, node.active, score
ORDER BY score DESC LIMIT 6

Successor ranking (direct recent work plus CO_CHANGED proximity) and module risk are in the README.

What I found on a real repository

I loaded the public history of fastapi/fastapi (source files under fastapi/ only): 855 commits, 209 contributors, 59 files, 7 modules.

6 of the 7 modules have a bus factor of 1 under my heuristic.
One contributor holds about 80% of the recent-weighted knowledge in the core package.
17 files across modules have no other active contributor with comparable recent history.
The agent explains the link with a path such as Person → fastapi/__init__.py → fastapi/(core).

I want to be careful here. That is a statement about commit history, not about the project's health. FastAPI has many maintainers and reviewers, and review work, triage and design discussion don't show up in commits. I chose a well-known public repo because anyone can verify it, not because I think it is at risk.

From insight to action

Track 01 is about agents that act on what the graph shows. Ask for a hand-off plan and the agent:

runs the leave-impact query for that person,
finds successors for the most affected modules,
writes a Markdown plan, like this:

## fastapi/(core)  (80% of module knowledge, 7/26 files orphaned)
- Suggested mentee: **<top-ranked active contributor>** (backup: <next candidate>)
- Pair-review these files first: `fastapi/routing.py`, `fastapi/params.py`, ...

It can also draft GitHub issues. Those are a dry run unless you set a token, point it at your own sandbox repo, and tick a checkbox, because an agent should never open issues on someone else's project by surprise.

Decisions I'd defend

Recency matters. Each commit-file pair decays with a one-year half-life, so last month's work counts more than work from years ago.
Mass commits are noise. Merge commits, bots and commits touching more than 40 files are dropped. A repo-wide reformat says little about who understands the code.
Privacy by default. Author emails are hashed. Only public Git metadata is used.
Show your work. The UI lists every tool call with its Cypher beside the subgraph it used.
Same tools, three doors. A built-in agent (any OpenAI-compatible LLM, or an offline rule-based planner with no API key), an MCP server exposing the same graph tools, and a small web UI.

What it can't tell you

Commit counts are not expertise. A reviewer who never commits is invisible.
One person with two commit emails shows up twice.
Scores and thresholds are heuristics, not calibrated probabilities.
For a module one person owns completely, successor suggestions fall back to weak co-change links.
I haven't tested it on very large repositories.

Try it

git clone https://github.com/KomalDeep355/HandoffGraph.git
cd HandoffGraph
python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -r requirements.txt
copy .env.example .env
docker compose up -d
.\scripts\run.ps1 ingest
.\scripts\run.ps1 serve

Open http://localhost:8000 and ask: "What happens if the top contributor leaves?"

What's next

Add review and issue data to the graph so reviewers stop being invisible, merge contributor identities, and track how risk changes over time instead of taking one snapshot.

Built Redmargin because I couldn’t tell if my projects matched the roles I’m applying for. Paste a repo + target role, get a blunt verdict against real job postings. Try it on your own repo and tell me where it’s wrong.

Komal deep — Sun, 18 Oct 2026 14:35:07 +0000

Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle Submission 💸

Komal deep

Oct 18

Redmargin: Does Your Project Actually Match the Job?

#devchallenge #hf26challenge

7 min read

Redmargin: Does Your Project Actually Match the Job?

Komal deep — Sun, 18 Oct 2026 06:55:50 +0000

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

What I Built

Here is a problem I lived through as a fresh graduate.

Hiring has changed. Freshers send dozens of applications, recruiters skim for seconds, and rejections come with no feedback. Every fresher I know is stuck on the same questions:

Which project should I put on my resume for this job?
Does this project actually match what the job asks for?
If something is missing, what exactly should I learn, and in what order?

Nobody answers these. Resume advice is vague: "add more projects," "make it stronger." So I built the tool I wished I had.

Redmargin is an honest reviewer for your GitHub projects. You give it a public repo and a target role. It compares your repo with what job postings ask for, shows where it found evidence of each skill and where it didn't, and gives you a ranked fix plan with a day-by-day timetable.

The "How May I Help" Desk

Not everyone has the same time. A student with two free hours a day and a job-seeker with eight need different plans. The How May I Help Desk builds a personalized plan around the hours you can dedicate to a project, so the fixes and timetable fit your real schedule.

Who would pay, and why?

Job seekers and freshers pay to learn which projects fit which job, what is missing, and how to close the gap in the time they have.
Companies and recruiters care about how closely a candidate's projects match the required skill set. That match percentage is something Redmargin could produce from the repo itself. Today the product serves candidates, and recruiter-facing evaluation is the direction I want to take it next.

Built to be trusted

Numbers are deterministic. Skill percentages, repo signals and fix hours are computed in code.
The LLM only writes the critique, and every claim must cite evidence that can be checked.
Unsupported claims are dropped and counted, which gives a real "how often did the model invent things" number.
Missing evidence is never treated as proof of a missing skill. Skills that can't be inferred from source are marked "not assessed".

Demo

Live demo: https://redmargin.onrender.com

Code

KomalDeep355 / Redmargin

An evidence-first GitHub repository reviewer that turns skill gaps into actionable improvement plans.

Repo Reviewer (working name — rename freely)

An honest reviewer for your GitHub projects. You give it a repo and a target role; it compares the repo with what real job postings ask for, shows where repository evidence was not found, and gives a ranked fix plan with a day-by-day timetable. Missing repository evidence is not proof that a candidate lacks a skill.

Design rule: numbers are deterministic (signals, percentages, hours). The LLM only writes the critique, and every claim must cite evidence we can check. Unsupported claims are dropped and counted, which gives you a measurable "how often did the model invent things" number for your write-up.

Run it (Windows PowerShell)

cd D:\Projects\repo-reviewer
py -m venv .venv
.venv\Scripts\Activate.ps1        # if blocked: Set-ExecutionPolicy -Scope Process Bypass
pip install -r requirements.txt
copy .env.example .env             # then edit .env
uvicorn app.main:app --reload

Open http://127.0.0.1:8000. Run tests…

View on GitHub

How I Built It

Stack: FastAPI backend, a plain HTML/CSS/JS frontend, pytest tests, and a Render blueprint for deployment.

Fetch the repo through the GitHub API (file tree plus key files, no cloning), with limits on tree size, file count and concurrency.
Detect signals deterministically: tests, CI, Docker, README quality, committed .env files.
Build the skill matrix. A taxonomy in skills.json defines how each skill appears in job postings and in a repo (dependencies, paths, keywords). The tool compares how many postings ask for a skill with the evidence found in the repo.
Plan the fixes. Gaps become ranked fixes from an editable fix_library.json, then a day-by-day timetable, adjusted by the How May I Help Desk to your available hours.
Write the critique with open-source AI, then validate every claim against readable repo files. Claims without evidence are dropped and counted.
Extras built on the same evidence: repo-grounded interview questions, evidence-checked resume bullets, and a weighted hackathon-score estimate.

How It Works: The Pipeline

Redmargin has two separate parts: a live review pipeline that users run, and an offline machine-learning experiment that is not yet connected to it.

LIVE REVIEW (what users run today)
──────────────────────────────────
 Public repo URL + target role + hours available
                    │
                    ▼
 1. FETCH       GitHub API, bounded file set, no clone, no execution
                    ▼
 2. SIGNALS     tests, CI, deploy files, README quality, hygiene issues
                    ▼
 3. SKILL MATRIX   skills.json taxonomy + repo markers
                    │   compared with real job postings
                    ▼
 4. PLANNER     ranked fixes (fix_library.json) → timetable sized to your hours
                    ▼
 5. LLM (optional)   open-source model writes the explanation
                    ▼
 6. VALIDATOR   unsupported claims are dropped and counted
                    ▼
        Ranked fix plan + day-by-day timetable


OFFLINE EXPERIMENT (not wired into live scoring yet)
────────────────────────────────────────────────────
 3 job-posting CSVs → join → dedupe → clean → role labels
        → split by company → TF-IDF + Logistic Regression
        → validation threshold → held-out test metrics

The key idea: numbers come from code, words come from the model, and a validator checks the words against the repo.

The Data Pipeline and Model Experiment

I wanted Redmargin to be more than an LLM that looks at a GitHub repository and guesses whether it is good enough for a job. So I separated the system into a deterministic review pipeline and an offline machine-learning experiment.

Collecting and preparing the data

My local dataset workflow started with three source CSV files containing job-posting information. It joined the job, summary and skill tables on job_link, removed duplicates, discarded records without usable titles or descriptions, normalized the text, and classified postings into target-role categories.

The initial join produced 12,217 postings, including 12,212 with source-provided skill labels. After filtering and deduplication, 1,223 postings remained:

Role	Postings
Data Scientist	729
NLP/ML Engineer	270
Software Engineer	188
Forward Deployed Engineer	36

I split the records by company, not by random row, so postings from the same company never appear in more than one split. That reduces leakage.

Split	Postings
Training	841
Validation	183
Test	199

The labels came from the source data and are not independently verified ground truth. I treat them as noisy labels, not definitive statements about what every employer requires.

Data transparency: the repository documents this workflow and these counts. The original dataset's source, collection date and redistribution licence still need confirmation before I can present it as a fully documented, redistributable corpus.

Training the skill-extraction baseline

For the offline experiment I built a multi-label skill-extraction baseline using TF-IDF vectorization and Logistic Regression. TF-IDF turns job-description text into numerical features based on the words and phrases it contains, and Logistic Regression learns to predict skill labels from those features.

I limited the experiment to the 50 most frequent training labels. The vectorizer and classifier were fitted on the training split only. I used the validation split to choose a global probability threshold of 0.20, then evaluated on the held-out test split.

Metric	Result
Validation micro-F1	0.5305
Test micro-F1	0.5483
Test macro-F1	0.3335

These are exploratory results, and they have clear limits:

The test data contained 3,670 skill-label occurrences outside the training vocabulary, so the model does not cover the long tail of skills.
The metrics cover only the selected 50-label vocabulary. They are not overall skill-extraction performance and not repository-review accuracy.

The fitted vectorizer, classifier, vocabulary, threshold and training metadata are saved locally as a model artifact. This experiment is not yet integrated into Redmargin's live scoring. It is a starting point for future evaluation, not a claim that the app already uses a trained model to make hiring recommendations.

How the live review works

When a user submits a public GitHub repo and a target role, Redmargin fetches a bounded set of files through the GitHub API without cloning or executing the project. Then it:

Checks repository signals such as tests, CI configuration, deployment files, README quality and hygiene issues.
Builds a skill-evidence matrix from the skill taxonomy and repository markers.
Compares skill mentions in available real job postings with the evidence in the repo.
Ranks fixes and builds a timetable based on the user's available hours.
Optionally asks an OpenAI-compatible LLM to write an explanation grounded in repository evidence.
Validates the generated findings against the evidence and discards unsupported claims.

The numeric scoring and fix estimates are deterministic. Role priorities are human-configured, not learned from the training data. Synthetic sample postings are excluded from market percentages, and the app withholds market-based conclusions when there isn't enough real-posting evidence.

What comes next

The next steps are to confirm the dataset's source and licence, review the noisy skill labels, expand coverage across roles, and build an independently human-labelled benchmark of repository signals. Then I'll compare the offline model against the deterministic baseline before it influences any live decision.

The goal is not to replace evidence with a model prediction. It is to use machine learning where it adds value, while keeping every user-facing finding inspectable and honest about uncertainty.

The Open-Source AI Layer

Redmargin supports OpenAI-compatible endpoints, so it works with local inference through Ollama or a hosted open-weight model. A rule-based mock mode is also available, so anyone can explore the review workflow without configuring an API key.

The project is designed to keep deterministic scoring separate from AI-generated explanations. The model never decides the numbers. It only explains them.

Honest Limitations

The included job postings are synthetic test data, not evidence of current hiring-market demand. They are excluded from market percentages.
Real market comparisons require a sufficient collection of real job postings.
Only public GitHub repositories are supported.
Fix-hour estimates are editable defaults, not guaranteed predictions.
The current product focuses on helping candidates improve their projects. Recruiter-facing evaluation is a potential future direction.

Why Does Open Innovation Matter?

A tool that judges people's work has to earn trust, and a closed black box can't do that.

Privacy and cost for the people who need it most. Freshers can't afford subscriptions, and their code and career plans are personal. With open-weight models and local inference, Redmargin can run on a candidate's own machine without that data leaving it.
Inspectable, not magical. The skill taxonomy is a plain JSON file. Adding a role, skill or fix is a single file edit, so anyone can extend Redmargin to a new job market without asking a vendor.
Measurable honesty. Because I control the model layer, I can measure how often the critique makes unsupported claims. That trust metric is the heart of the project.
Economics that work for a side hustle. Per-call API pricing would eat the margin of a service aimed at students. Open models make a low-cost audit service possible.

My First User

My first user was a friend, and I didn't charge her anything.

She is applying for different kinds of jobs and internships. She was making projects for her resume but had no way to see where the skills were missing in them, or which projects matched which role. That is exactly the problem Redmargin was built for.

Why I Built Redmargin

I built Redmargin because I know how difficult it is to finish a project and still wonder whether it is good enough for the role you're applying for.

I wanted to create something more useful than another score generator: a tool that shows its evidence, admits what it cannot determine, and gives you a practical next step.

Redmargin is built around one principle: don't just tell developers what's wrong with their projects. Show them the evidence, then help them fix it.

In Delhi NCR, "go touch grass" can be bad advice. So I built a tool that checks the air first.

Komal deep — Mon, 12 Oct 2026 05:48:32 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Every October, the advice around me in Delhi NCR quietly changes. "Go for a walk" becomes "check the AQI first." Diwali is less than a month away, and the air is about to get worse.

Checking the AQI is easy. Deciding what to do with the number is harder. Is this a good time for a walk? Would another hour be better? What if a child, or someone with a lung condition, is going out? And if I do go, where is the nearest park?

Roamwise checks the air before you go touch grass. You say who is going and what you plan to do, and it answers in one line: Good to go, Go easy or Stay in. Then it shows the cleanest daylight window in the next 24 hours and the nearest parks. It is for anyone in Delhi NCR (or any city) who wants to be outside and does not want to decode a chart first.

It gives you:

A verdict that changes with the person and the plan. Choose "most adults" or "children, older adults, heart or lung conditions," and "a relaxed walk" or "running or hard exercise." The thresholds shift with each choice. A reading of 70 µg/m³ means Go easy for most adults on an easy walk, but Stay in for a child, an older adult or someone with a heart or lung condition.
Open-Meteo's hourly PM2.5 forecast for the next 24 hours, with the cleanest daylight window highlighted.
A short explanation in English, Hindi or Hinglish.
Parks within 3 km, with walking time and a map, from OpenStreetMap.
Voice input and an assistant, Ask Roamwise. Voice input lets users speak their outdoor-planning questions instead of typing, while Ask Roamwise answers questions about air quality, weather, and suitable times to visit nearby parks.

The challenge says the best builds make the screen the shortest part of the experience. So the page leads with one coloured banner and one sentence. The chart, parks and map are there if you want them, but the answer comes first, and then you go outside.

Taking it outside

In Delhi NCR, deciding when to go for a run isn't always as simple as checking the weather. Some mornings look foggy, evenings can feel hazy too, and by midday the sunlight makes the outdoors look more inviting. But a sunny sky doesn't necessarily mean the air is clean.

That was one of the real-life problems behind Roamwise. I wanted to make it easier to look beyond what the sky looks like and check the air-quality forecast before heading outside. The goal is to help people find a more suitable time for outdoor activities instead of relying on appearance alone.

What my friend said

I asked a friend who goes running every day to try Roamwise. He often finds it difficult to decide when to run because the air can look foggy in the morning and evening, while the daylight and sunshine can make conditions seem better.

The problem isn't just whether to go running; it's figuring out which time of day might be better for it. Roamwise is my attempt to make that decision easier by combining hourly PM2.5 forecasts with activity-specific recommendations.

What matters to me is that the app doesn't simply tell someone what they want to hear. It uses explicit rules to produce the verdict, while the AI explains it in plain language.

Demo

Search a city, check the air-quality verdict for different activity levels, explore the hourly PM2.5 forecast, and find nearby parks and a better window to head outdoors.

Try it: roamwise-4e26.onrender.com.

Code

KomalDeep355 / Roamwise

Roamwise 🌿

Check the air before you go touch grass.

Roamwise helps you decide whether it is a good time to go outdoors by showing current air-quality conditions, the cleanest daylight window in the next 24 hours, and nearby parks.

Built with Delhi NCR in mind, where "go outside" can be bad advice around Diwali, Roamwise is designed to work for other cities too.

Live demo: https://roamwise-4e26.onrender.com

Write-up on DEV:

The one design rule

The go / go easy / stay in verdict is computed using fixed PM2.5 rules, not a language model.

An open-weight language model explains that verdict in plain language in English, Hinglish or Hindi. If the generated explanation contradicts the verdict or makes a medical claim, Roamwise replaces it with a template explanation.

For a health-adjacent application, the language model explains the decision; it does not make the underlying safety decision.

Features

Air-quality forecast: Hour-by-hour PM2.5…

View on GitHub

A Python and FastAPI backend with a plain web frontend. It is open source and runs locally with Ollama.

How I Built It

Air quality and weather come from Open-Meteo. Parks come from OpenStreetMap through the Overpass API. A SQLite cache cuts repeated requests and serves the last good data if a source is down.

The rule I did not give to the model

A language model does not write the verdict. It comes from fixed PM2.5 thresholds in plain Python, and the model only explains the result. This is a health-adjacent decision, and a fluent explanation is not evidence that the recommendation is right.

# (go_max, caution_max) in µg/m³ of PM2.5
THRESHOLDS = {
    ("general", "light"): (60, 90),
    ("general", "vigorous"): (30, 60),
    ("sensitive", "light"): (30, 60),
    ("sensitive", "vigorous"): (15, 30),
}

These are my application's practical heuristics, based on India's CPCB PM2.5 bands. They are not official CPCB activity-specific recommendations and not medical limits. CPCB defines its bands for 24-hour averages, whereas Roamwise applies the thresholds to hourly forecast values. They live in one dictionary so anyone can read them, change them and argue with me.

The model takes the verdict, best window, and nearest park as fixed facts and writes a few plain sentences. If its text contradicts the verdict or makes a medical claim, the app drops it and shows standard wording instead, and says which one you are reading. I tested the core decision logic against different activity levels and user sensitivity settings. The verdict is rule-based, so the AI explanation cannot override a “Stay In” recommendation.

Open-Meteo (air quality + weather) ─┐
OpenStreetMap / Overpass (parks) ───┤
                                    ▼
                  SQLite cache (stale fallback)
                                    ▼
        Fixed rules: PM2.5 thresholds, daylight, rain, heat
              ▼ verdict + windows + ranked parks
        Open-weight LLM explains it (template fallback)
                                    ▼
             FastAPI  ──►  page with chart, parks and map

Where the forecast comes from

Roamwise uses Open-Meteo's hourly PM2.5 air-quality forecast for the next 24 hours. It does not currently use a separately trained forecasting model. Its own contribution is the decision layer: applying configurable thresholds, considering relevant weather conditions, and identifying potentially better outdoor windows from the forecast data.

The open models and deployment

Locally, Roamwise uses Gemma 3 4B through Ollama. The deployed version is configured to use gemma3:4b through an OpenAI-compatible endpoint. In both configurations, the model explains the rule-based verdict rather than deciding it. The app is deployed as a FastAPI service on Render using render.yaml, with a health-check endpoint and environment variables for the model connection.

What went wrong

The forecast-versus-verdict distinction needed care. I had to make sure Roamwise clearly separates the hourly PM2.5 forecast from the rule-based activity recommendation, rather than implying that I had trained a separate forecasting model.
The AI needed boundaries. I wanted the assistant to explain the recommendation, not invent a more reassuring answer when the rules say “Stay In.” Keeping the verdict rule-based helps maintain that separation.
Local and deployed configurations weren't identical. Locally, I use Gemma 3 4B through Ollama, while the Render deployment uses an OpenAI-compatible endpoint. That meant I needed to verify the deployed model and provider separately instead of assuming the local setup carried over.
I had to be careful about what I claimed. It would be easy to describe the activity thresholds as official health guidance or imply that every feature had been thoroughly tested. I kept the distinction between practical heuristics and official guidance explicit and avoided claiming unverified test results.

What it can't do

Air quality is a regional model estimate, not a reading at a particular park.
The thresholds are heuristics, not medical limits.
A park is not automatically cleaner than the street outside it. Parks are ranked by distance only, which does not show air quality.
Forecasts can be wrong or change.
This is a planning aid, not medical advice or a replacement for official alerts. If you have a heart or lung condition, follow your doctor's advice.

Why Does Open Innovation Matter?

1. I can swap the model. The explanation layer works with local Ollama or a hosted endpoint, so I can try different open models without touching the part that decides the verdict.

2. Local mode keeps more on my machine, but not everything. When I run Gemma locally, the choices about who is going (for example, a child or someone with a lung condition) and the explanation request are processed locally. The place searched still goes to Open-Meteo and OpenStreetMap to fetch data. On the hosted demo, the explanation request goes to the configured OpenAI-compatible API provider and is subject to that provider’s data-handling practices.

3. The rules are inspectable. The thresholds are Python code, not instructions hidden in a prompt. Anyone can read them, test them and change them. A closed API would have made that decision invisible.

4. Small and open has a cost. I haven't published a reliable benchmark comparing local Gemma 3 4B with the hosted model, so I won't pretend I have one. Models can differ in response speed and the quality of their explanations. That's why the verdict never depends on the model: the rules determine the recommendation, and the model explains it.

Prize Categories

Best Use of Gemma: Gemma 3 4B, run locally through Ollama, generates plain-language explanations in English, Hindi, or Hinglish from fixed facts. It explains the rule-based verdict; it never decides whether going outdoors is recommended. I haven't recorded a reliable latency benchmark yet, so I won't claim a speed advantage.
Best Use of Render: One FastAPI web service deployed using render.yaml, with a health-check endpoint and environment variables for the hosted model connection. This keeps deployment configuration separate from the application code.
Best Use of ElevenLabs: Integrated ElevenLabs into Roamwise’s AI agent to support a more natural, voice-enabled interaction. This lets users interact with the assistant beyond traditional text-based input.

If you live in Delhi NCR, try Roamwise this week and tell me what is missing. Which city should I test next? Next, I want to rank places by more than distance, for example how close a park is to a major road.

FriendOS: I Built an AI That Tells My Panicking Friend What to Do Next

Komal deep — Mon, 05 Oct 2026 06:54:12 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built FriendOS, a little AI thinking partner that answers one question: "What should I do next?"

I built it for a friend who is always one deadline away from panic.

She isn't lazy, and she isn't unorganized in the way people usually mean it. Her problem is that everything arrives at once. An assignment is due today. A message needs a reply. Something needs buying. Her room needs cleaning. And all of it is in her head at the same time, loud and tangled.

When that happens, she freezes. Not because she doesn't know what the tasks are, but because she doesn't know which one to start, or where to start with it.

Then comes the second problem. To actually do anything, she bounces between five or six places at once: a search tab for one thing, her email for another, a shopping site, a notes app, an AI chat, a study page. Nothing is connected. Every task needs its own hunt for the right resource, and by the time she's found it, she's lost the thread and the panic is worse than before.

A normal to-do app didn't help her. It gave her more information when she needed less thinking. So I built something different.

FriendOS skips the forms. You brain-dump everything, by typing or by speaking:

"I need to submit my assignment today, finish two sections, clean my room this weekend, and buy a charger because mine is damaged."

FriendOS turns that into:

🔥 DO NOW
🌼 DO SOON
🌿 CAN WAIT
⏱️ NEXT 30 MINUTES: one to three small, realistic steps

Then it helps her actually start, so she doesn't have to go hunting. Each task comes with a first move: a shopping task opens a search, an email task builds a prompt and opens Gmail, a study or writing task generates a breakdown prompt and opens an AI assistant. Instead of juggling tabs, she gets one place that says do this, start here.

The most important rule is that FriendOS only works with what you actually tell it. My first version kept adding things like "research potential topics for future assignments" that nobody asked for. For someone who is already overwhelmed, a planner that invents more work is the last thing she needs. So FriendOS never invents tasks or deadlines.

It works in English, Hindi, Punjabi, and Hinglish, because my friend doesn't think in only one language.

Demo

🔗 Live app: https://friendos-rizl.onrender.com/

Try this brain dump:

I need to submit my assignment to my professor today. I still need to finish two sections. I also need to clean my room this weekend. I want to buy a new charger because mine is damaged.

Code

KomalDeep355 / FriendOS

FriendOS 🌼

Your little thinking partner. It answers one question: "What should I do next?"

FriendOS turns a messy brain dump into a calm, realistic priority plan, then tells you exactly what small step to take in the next 30 minutes. It only works with what you actually tell it. It does not invent tasks or deadlines.

Demo: https://friendos-rizl.onrender.com/ Code: https://github.com/KomalDeep355/FriendOS

Why I built it

I built FriendOS for a friend who always has too many things to keep track of: assignments, errands, things to buy, things to clean. They didn't need another productivity dashboard. They already knew what was on their plate. The hard part was deciding which thing to do right now.

The problem isn't a lack of organization. It's decision overload.

Too many things in my head
        ↓
Brain dump instead of forms
        ↓
AI prioritization instead of manual sorting
        ↓
NEXT 30 MINUTES instead of

…

View on GitHub

How I Built It

Text or microphone
      ↓
FastAPI  →  ElevenLabs Scribe v2 (voice only)
      ↓
FastAPI  /api/organize
      ↓
Open-weight Llama
      ↓
Strict JSON → validation → plan
      ↓
DO NOW / DO SOON / CAN WAIT / NEXT 30 → contextual action

Frontend: plain HTML, CSS, and JavaScript, with a calm, cozy, Pinterest-style board look. Task completion is saved in localStorage, so there's no database.
Backend: Python and FastAPI.
AI: an open-weight Llama model, called through an OpenAI-compatible chat endpoint. Locally I ran it with Ollama (llama3.2:3b). For the public demo I point the same code at a hosted Llama endpoint, so anyone can try it without installing anything. Switching is two environment variables.
Voice: the browser records audio with MediaRecorder, FastAPI sends it to ElevenLabs Scribe v2, and the transcript goes straight into the planning pipeline. This is voice input only. FriendOS doesn't speak back.
Hosting: Render.

Making a small model behave. The system prompt tells the model never to invent tasks, deadlines, or events, never to duplicate tasks, not to force tasks into categories, and to keep NEXT 30 realistic. I don't trust the prompt alone, though. A normalization layer in the backend strips markdown fences, fills missing fields, removes empty and duplicate tasks, and drops any NEXT 30 item that points to a task that doesn't exist. That combination is what stopped the made-up tasks.

I deliberately left out auth, a database, React, RAG, and multi-agent setups. I wanted something small enough to actually finish and put in front of my friend.

Why Does Open Innovation Matter?

FriendOS is a very personal tool. People paste their half-formed worries and deadlines into it. An open-weight model made it possible to build around that.

Control over the experience. Because I could shape the model's behavior through prompting and then validate its output, I could fix the exact problem my friend would have noticed: the planner inventing work.
Privacy is a real option. With Ollama, the whole intelligence layer can run on your own machine, so your brain dump doesn't have to go to anyone's server. (The public demo uses a hosted Llama endpoint for convenience, and voice uses ElevenLabs, so I'm not claiming the live demo is fully local.)
No lock-in, and cost stays low. Because the model sits behind a standard API shape, I could develop for free locally and then switch to a hosted open-weight endpoint for deployment without rewriting the app. A solo developer building for one friend shouldn't need a paid proprietary API to get started.

Prize Categories

Best Use of ElevenLabs. FriendOS takes voice input: you tap the mic and speak your brain dump, and ElevenLabs Scribe v2 transcribes it. The transcript goes straight into the Llama planning pipeline, so the plan appears without typing. This fits the category's "transcribe audio for a language model" use. FriendOS uses voice input only, not voice output.

Best Use of Render. The FastAPI backend and the frontend are deployed on Render, which serves the live demo.

Connecting My Agent to SigNoz's MCP Server: A First-Timer's Debugging Diary

Komal deep — Sun, 26 Jul 2026 15:35:24 +0000

I want to start with the number that actually matters: three hours. That's roughly how long I spent just getting a connection to succeed, out of a five-day hackathon window. If you're building something similar and hit the same walls, this post should save you most of that time.

What I was building, and why this angle

This was my first hackathon. My background is data science and NLP — classification, prediction models, the kind of ML work where inputs and outputs are known quantities. Agents, MCP servers, observability — none of that was in my vocabulary two weeks ago. So this post is written from that specific angle: what actually trips someone up coming from ML into agent-plus-observability tooling for the first time.

For Agents of SigNoz (WeMakeDevs x SigNoz), I built an agent that connects to a self-hosted SigNoz instance through its MCP server, answers natural-language questions grounded in live telemetry, and then classifies what it finds — latency, error-rate, resource-exhaustion, dependency-failure, or healthy — with a confidence score traced back into SigNoz itself.

Setting up SigNoz via Foundry

bash
`curl -fsSL https://signoz.io/foundry.sh | bash`

yaml
`apiVersion: v1alpha1
kind: Installation
metadata:
  name: signoz
spec:
  deployment:
    flavor: compose
    mode: docker
  mcp:
    spec:
      enabled: true`

bash
`foundryctl cast -f casting.yaml`

This brought up SigNoz and its bundled MCP server as separate Docker containers — a detail that turned out to matter a lot more than I expected.

Bug #1: 401 Unauthorized

My first connection attempt to http://localhost:8000/mcp returned a flat 401. Self-hosted SigNoz's MCP server needs two specific headers, not the generic Bearer-token pattern I tried first:

python
`async with streamablehttp_client(
    MCP_URL,
    headers={
        "SIGNOZ-API-KEY": os.getenv("SIGNOZ_API_KEY"),
        "X-SigNoz-URL": "http://signoz-signoz-0:8080",
    },
) as (read_stream, write_stream, _):`

Bug #2: 400 Bad Request — the Docker networking trap

Adding the headers got me past the** 401*, straight into a **400*. I initially set X-SigNoz-URL to http://localhost:8080, since that's where SigNoz's UI loaded from my own machine. But the MCP server runs inside its own container — and inside that container, localhost refers to the container itself, not my SigNoz instance. The server's own logs said it plainly:

`"msg":"Invalid X-SigNoz-URL header" ... "error":"host \"localhost\" is not allowed"`

docker ps showed the actual container name — signoz-signoz-0 —, and that's what needed to go in the header instead. This is the single biggest lesson I'd hand to my past self: when a container-to-container request fails, check what hostname the containers actually use to reach each other on the Docker network. It's rarely localhost.

Bug #3: a plain variable-naming mistake

Once I fixed the headers, I hit a NameError: name 'read_stream' is not defined. I'd renamed the tuple unpacking on the async with line but hadn't updated where those names were used two lines later:

python
`) as (read_stream, write_stream, _):
    async with ClientSession(
        read_stream,
        write_stream,
    ) as session:`

Small, but the traceback pointed into the MCP library's internals, not my own line — a good reminder that an error surfacing deep in someone else's stack trace can still be your own typo.

Bug #4: 403 — a permissions gap, not a connection problem

With the connection finally working, calling signoz_list_services returned:

`403: only viewers/editors/admins can access this resource`

The API key itself was valid — the service account behind it just had no role assigned. The fix was in Settings → Service Accounts, assigning Editor or Admin. Worth remembering: a valid key and a valid role are two separate things.

What I actually built on top: reasoning, not just retrieval

SigNoz's MCP server gives you raw retrieval — service lists, traces, metrics, logs. It has no opinion about what any of that data means. Coming from a classification background, my instinct was to add exactly that missing layer:

python
`def classify_incident(user_question: str, telemetry_data: str) -> dict:
    classification_prompt = f"""You are classifying an observability finding.

User question: {user_question}
Telemetry data retrieved: {telemetry_data}`

Classify this into exactly ONE category: latency, error-rate, resource-exhaustion, dependency-failure, healthy, or unknown.

Respond with ONLY valid JSON, nothing else:
`{{"category": "", "confidence": , "reasoning": ""}}"""

response = hf_client.chat_completion(
    model=MODEL_ID,
    messages=[{"role": "user", "content": classification_prompt}],
    max_tokens=150,
    temperature=0,
)
raw = response.choices[0].message.content.strip()
return json.loads(raw)`

The part I actually care about is where the result goes — not just into the chat response, but into SigNoz's own trace:

python
`with tracer.start_as_current_span("incident_classification") as classify_span:
    classification = classify_incident(request.query, telemetry_data)
    classify_span.set_attribute("incident.category", classification["category"])
    classify_span.set_attribute("incident.confidence", classification["confidence"])`

That means my agent's own judgment becomes something you can trace inside SigNoz, the same way you'd trace any other part of the system. SigNoz observes the target service; this makes it also observe the agent's reasoning about that service.

What I'd tell someone starting this from an ML background

Docker networking will very likely be your biggest time sink — not the AI part. Budget for it honestly.
Read the server's logs the moment a request fails for an unclear reason — docker logs_ _ told me more in thirty seconds than an hour of guessing at headers did.
A service account's API key and its assigned role are two separate failure points — check both before assuming the key is broken.
Look for where your actual background transfers, instead of trying to become a full infra person overnight. For me that was "don't just retrieve data, judge it" — that's ML thinking applied to an observability tool, and it's the one piece of this that's genuinely mine.

What's next

With more time, I'd add a small retrieval layer surfacing similar past incidents, and wire a SigNoz alert to trigger the agent automatically instead of waiting on a question.

Conclusion

If you're self-hosting SigNoz's MCP server and hit a 401, 400, or 403 in that order — check your headers, your Docker hostnames, and your service account's role. That covered nearly everything that stood between a working agent and me, and I hope it saves you the three hours it cost me.