DEV Community: Himanshu Kumar

SOLSTICE — The Longest Day: a platformer where light is your only resource

Himanshu Kumar — Mon, 08 Jun 2026 07:03:46 +0000

This is a submission for the June Solstice Game Jam

What I Built

SOLSTICE — The Longest Day is a short, atmospheric platformer built around one idea: your light is your only resource.

It's the eve of the June solstice — the year's hinge between the longest day and the longest night — and the sun is failing. You play a small wanderer carrying the last ember of daylight. That glow does three jobs at once:

It lets you see. The world is dark; you move inside a soft pool of light that shrinks as it drains.
It's your lifeline. Shadow drains it faster — let it gutter out and you're nearly blind.
It's your tool. Spend it in a Sunburst to bloom pale, ghostly platforms into something solid, light distant beacons, and push back the dark.

You carry that light across four hand-built levels — Dusk → Twilight → Deep Night → The Turning — as the darkness deepens, until you reach the altar and rekindle the dawn.

My goal & the theme: the solstice is the exact instant light and dark trade places, so I wanted light to be something you physically negotiate the whole game rather than just a backdrop. Spend too much and you're stranded in the dark; hoard it and the path stays shut. The level arc traces the day itself — a descent into the longest night, a turning point, and a climb into a dawn that floods the screen with gold.

▶ Play it in your browser (desktop & mobile): https://hyperagent.com/s/A_Xul17aTbCIAsAcvG8A-w

Code

The entire game is a single, self-contained index.html — HTML5 Canvas 2D + vanilla JavaScript, no engine, no libraries, no build step. One file you can read top to bottom.

himanshu748 / solstice

SOLSTICE — The Longest Day

A short, atmospheric platformer where your light is your only resource. Built for the DEV June Solstice Game Jam.

▶ Play: https://hyperagent.com/s/A_Xul17aTbCIAsAcvG8A-w

On the eve of the solstice the sun is failing. Carry the last ember of daylight across four levels — Dusk → Twilight → Deep Night → The Turning — and rekindle the dawn. Your light lets you see, slowly drains, and is spent in a Sunburst to bloom platforms, light beacons, and push back the dark.

Controls

Move: ← → or A D
Jump: Space or W
Sunburst: J or Shift
Pause: P · Restart: R · Mute: M
Mobile: on-screen buttons — play in landscape

Tech

One self-contained index.html — HTML5 Canvas 2D + vanilla JavaScript. No engine, no libraries, no build step. Real-time 2D lighting via canvas compositing, fixed-timestep platformer physics (coyote time, jump buffering, variable jump height)…

View on GitHub

How I Built It

Lighting is the heart of it. Each frame I draw the world normally, then build a separate darkness layer: fill it near-black, then punch holes in it with radial gradients at every light source (you, motes, beacons, lit platforms) using globalCompositeOperation = 'destination-out'. Composited over the scene, that gives the soft pool-of-light look; a second additive pass paints warm bloom back in. Platforms that are only solid when lit simply test, each frame, whether their center falls inside a light radius — that one check is the whole core mechanic.

Game feel got real attention: a fixed-timestep loop, coyote time, jump buffering, variable jump height, squash-and-stretch on the character, a little screen shake on landings and Sunbursts, and an eased camera. Small touches, but they're the difference between a canvas platformer feeling crisp vs. stiff.

Audio is fully synthesized with the Web Audio API — no sound files. A warm, consonant sine pad drones under everything, with gentle chimes for motes and a soft whoosh for the Sunburst.

It's responsive & mobile-first: the canvas adapts its aspect ratio to fill any screen, and the touch controls are true multi-touch so you can move and jump at the same moment (with touch-action: none so the browser doesn't hijack the second finger as a zoom).

A few things I wrestled with: keeping a draining-resource game fair (generous minimum light, forgiving beacon checkpoints); a collision bug where a rising platform briefly overlapped the player's feet and flung them sideways; and tuning the dawn so it reads as a warm sunrise payoff instead of a blinding flash.

Thanks for playing, and happy solstice. ☀️

Python Automation Training Toolkit: from abandoned group project to browser-first AI workspace

Himanshu Kumar — Tue, 02 Jun 2026 08:19:26 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I finished Python Automation Training Toolkit, a Python automation project that had useful pieces but never really became a product.

It started as a scattered training toolkit: scripts, automation helpers, experiment-style UI, and a lot of good intent. The project had been treated like something that might someday be cleaned up. For this challenge, I turned it into a browser-first automation workspace that someone can actually open, understand, run, and extend.

The finished product now includes:

Hugging Face model workflows for text summaries and image captioning
AWS S3 and EC2 controls separated by service so actions are clear
Browser-native hand gesture tracking using the user's camera directly in the browser
Location utilities with cleaner formatting and no stale OpenURL-style flow
Readiness and configuration checks with secret redaction
A FastAPI backend and modern web UI instead of desktop-only UI experiments
A monorepo layout with apps/api, apps/web, docs, and tests

Repository: https://github.com/himanshu748/python-automation-training-toolkit

Demo

Public video walkthrough: https://youtu.be/FiWRwTloN_s

The walkthrough shows the actual product flow: the landing page, dashboard, Hugging Face model tools, separate cloud controls, live browser gesture tracking, location utilities, and the polished browser UI.

Why This Project Needed a Finish-Up

This was not a greenfield build. That is what made it interesting.

The hardest part was not writing one new feature. The hard part was taking a project with scattered ideas and making all of it feel intentional.

At the beginning, the toolkit felt like a collection of things that technically worked but did not belong together yet. Some parts pointed toward a desktop app. Some parts were scripts. Some parts were automation demos. Some parts were missing the user-facing polish that would make someone trust the project.

So I treated the finish-up as a product rescue:

What should the first screen communicate?
Which workflows deserve their own pages?
What should be removed because it makes the app feel old or confusing?
How should secrets be handled so the project is safe to share?
How can the original automation spirit stay intact while the experience becomes cleaner?

The answer was to make the browser the main product surface.

The Comeback Story

This was originally a group-style project that got left behind. Instead of letting that be the end of it, I finished it solo and gave it a real product shape.

The original idea was still worth saving: a Python toolkit for useful automation workflows. But the implementation needed a clearer language. It needed to stop feeling like a folder of experiments and start feeling like a workspace.

That meant rebuilding the interface, separating services into proper pages, improving the README, removing old UI references, adding browser-controlled camera interactions, replacing older model assumptions with Hugging Face, and making the backend safer around configuration output.

The final project still feels like Python automation. It just no longer asks the user to imagine the product around it.

What Changed

The biggest upgrades were:

Replaced old desktop-style UI direction with a browser-first web workspace
Organized the project into a clearer monorepo structure
Added service-specific pages instead of cramming everything into one screen
Added Hugging Face model wrappers for text and vision workflows
Added live hand gesture tracking in the browser
Improved cloud actions with separate AWS S3 and EC2 controls
Removed stale flows that made the product feel unfinished
Improved output formatting and redacted sensitive configuration values
Added tests for model wrappers, cloud calls, doctor output, API routes, and secret safety
Updated documentation to explain setup, environment variables, and workflows

What I Am Proud Of

The best part is that the finished app is not just a demo page for a challenge. It is a real product surface for the original toolkit.

A user can land on the app, understand the major workflows, move through separate pages, run model tools, inspect cloud actions, try browser gestures, and see structured output. That is a big jump from a project that previously needed context to make sense.

I also like that the final version keeps the project practical. It does not hide behind a landing page. The interface is there to help people run automation tasks.

My Experience With GitHub Copilot

GitHub Copilot helped most during the messy middle of the finish-up: the part where the project was no longer broken, but not yet polished.

It helped with repetitive UI patterns, test scaffolding, API route cleanup, and checking for old references that should not survive into the final product. It was useful as a second pair of eyes while I turned disconnected pieces into a consistent workspace.

The biggest lesson was that finishing a project is different from starting one. Starting is about possibility. Finishing is about decisions.

This challenge forced those decisions, and the project is much better for it.

Building RepoRank — The Open Source Impact & Funding Readiness Engine

Himanshu Kumar — Thu, 28 May 2026 05:47:51 +0000

A journey into bridging open-source metrics, cross-source SQL joins, and AI-driven grant matching.

The Open Source Funding Crisis

Every day, developers build and maintain critical pieces of open-source software that power global infrastructure. Yet, one of the biggest challenges in the ecosystem remains funding. Maintainers spend hours writing grant proposals, pitch decks, and sponsorship applications.

To prove a project's impact, you have to answer tough questions:

How many developers are using it? (Downloads on PyPI/npm)
Is the community talking about it? (HackerNews mentions)
What is its current financial state? (Open Collective stats)
How healthy is the repository? (GitHub stars, forks, and issues)

Gathering this data means integrating with four or five different APIs, parsing fragmented JSON structures, writing boilerplate auth code, and manually stitching the pieces together.

For the Pirates of the Coral-bean Hackathon, I built RepoRank to solve this exact problem. RepoRank uses Coral SQL and Hugging Face Qwen 2.5 (72B) to aggregate cross-source signals instantly, calculate an overall impact score, generate a professional funding pitch, and match projects with active grant programs.

The Secret Weapon: Coral SQL

Integrating 4+ external APIs usually takes days of reading docs and writing API wrapper code. Coral changes this completely by letting you query APIs using standard SQL.

With Coral, APIs are treated as SQL tables. The star of the show in RepoRank is this single cross-source JOIN query:

SELECT  g.full_name,
        g.stargazers_count,
        g.forks_count,
        g.open_issues_count,
        p.last_month_downloads AS monthly_downloads,
        h.mention_count        AS hn_mentions_6mo,
        h.top_score            AS hn_top_score
FROM    github.repos_get    g
JOIN    pypi.packages       p  ON  p.name = 'fastapi'
JOIN    (
            SELECT COUNT(*) AS mention_count, MAX(score) AS top_score
            FROM   hackernews.stories
            WHERE  query = 'fastapi'
              AND  time  > NOW() - INTERVAL '180 days'
        )                   h  ON  1 = 1
WHERE   g.owner = 'tiangolo' AND g.repo = 'fastapi'

Coral handles the execution under the hood, fetching the package stats, checking HackerNews for stories matching the repository name over the last 180 days, retrieving GitHub details, and returning a unified, flat SQL row.

Building the Sources We Needed

Coral has a great collection of built-in sources, but to capture the full open-source picture, we needed data from PyPI, npm, HackerNews, and Open Collective.

Instead of hardcoding API requests in Python, we extended Coral! We designed and wrote 4 custom YAML source specifications that map external REST and GraphQL endpoints into SQL-queryable tables.

Here is a snippet of the custom GraphQL source spec we wrote for Open Collective:

dsl_version: 3
name: opencollective
backend: http
base_url: https://api.opencollective.com/graphql/v2
tables:
  - name: collectives
    filters:
      - name: slug
        required: true
    request:
      method: POST
      path: /
      body:
        format: text
        content: |
          {
            "query": "query ($slug: String) { collective(slug: $slug) { slug name stats { totalAmountReceived { value } contributorsCount } } }",
            "variables": { "slug": "{{filter.slug}}" }
          }

By mapping the GraphQL variable to the {{filter.slug}} template, we can query Open Collective using a simple SQL WHERE clause:

SELECT total_amount_received FROM opencollective.collectives WHERE slug = 'fastapi'

Upstream Contributions

To help other developers build on this, I opened 3 upstream Pull Requests to the official withcoral/coral repository:

PR #827: Adds the PyPI packages source spec & docs.
PR #828: Adds the npm packages source spec & docs.
PR #829: Adds the Open Collective GraphQL source spec & docs.

From Raw Data to Actionable Insights

Once the Coral engine executes the query and returns a structured record, RepoRank hands the data off to Hugging Face Qwen 2.5 (72B Instruct).

Using structured JSON schema outputs, Qwen acts as an expert open-source analyst, returning:

Impact Score (0-100): Mapped across metrics.
Impact Narrative: A professional, plain-English summary of the project's real-world value.
Funding Pitch: A punchy, one-sentence elevator pitch ready to copy-paste into sponsorship forms.
Targeted Grants: Recommends 3-5 specific programs (e.g., Google Summer of Code, PSF, MOSS, GitHub Sponsors) matching the language, ecosystem, and project scale.

A Premium User Experience

To match the power of the backend, I built a dark-mode dashboard with:

Interactive SVG Radar Charts: Visually represents project balance across 6 key metrics (Stars, Forks, Downloads, Community Buzz, Financial Backing, and Repository Health).
Session-Persistent GitHub Auth: Connect your GitHub account, load up your repositories in a sidebar, and click any repository to trigger an instant analysis.
Clickable Grant Cards: Hardmapped direct links to known grant applications, with dynamic Google search fallbacks for newer programs.
Inspectable Queries: A collapsible SQL details viewer so developers can see the exact query run by the Coral engine.
Keyboard Navigation: Cmd+K to focus the search bar, Cmd+Enter to run the analysis, and Esc to exit modals.

Key Takeaways

SQL as an API Gateway: Treating APIs as SQL tables makes data orchestration significantly simpler. Writing cross-source joins in SQL is cleaner than writing asynchronous API aggregation loops.
Community Expansion: Extending Coral's capabilities by writing YAML specifications shows how powerful declarative source mappings are.
Developer-centric AI: AI models are most effective when fed structured, pre-filtered data. Combining the data-gathering capabilities of Coral with the synthesis capabilities of LLMs creates an excellent pipeline.

🔗 Links & Resources

GitHub Repository: himanshu748/reporank
Upstream Pull Requests: Coral Pull Requests Page

Built for the Pirates of the Coral-bean Hackathon. Happy sailing! 🏴‍☠️

My PR Merged Into a Graveyard: On the Rise of Antigravity and the Fall of Open Source

Himanshu Kumar — Wed, 20 May 2026 16:37:14 +0000

This is a submission for the Google I/O Writing Challenge

Last week, I got the little green banner. Pull request merged. A small contribution to Gemini CLI — a fix I'd been meaning to submit for months — finally made it in. I closed my laptop feeling quietly satisfied.

Twenty-four hours later, Google announced Gemini CLI is being sunsetted.

I'm not going to pretend my PR was significant. It wasn't. But the timing felt like a metaphor so on-the-nose that I almost laughed. And the more I sat with it, the less funny it became.

What Actually Happened at I/O 2026

At Google I/O 2026, Google unveiled Antigravity CLI — a new, Go-built, agent-first terminal tool that replaces Gemini CLI. The pitch is compelling on paper: faster execution, asynchronous multi-agent workflows, a unified architecture shared with the Antigravity 2.0 desktop app. Your complex refactors run in the background. Multiple specialized sub-agents split up the work. It's Gemini CLI, but grown up.

The hard cutoff lands on June 18, 2026. After that date, Gemini CLI stops serving requests for Google AI Pro and Ultra users. Enterprise and paid API key holders get to keep the lights on a little longer, but the message is clear: the community project is done.

Gemini CLI ended its life with 100,000+ GitHub stars, 6,000 merged pull requests, and hundreds of external contributors. A genuinely impressive open-source run for something barely a year old.

Mine was PR number... well, somewhere in those 6,000.

The Bait-and-Switch Pattern We Keep Accepting

Here's what I keep returning to: Gemini CLI was launched as an open-source project. Google invited the world in. Developers (myself included) filed issues, wrote fixes, argued in discussion threads, and built their workflows around it. The community did what communities do — they made it better than Google could have alone.

And then, when it proved the concept and outgrew its usefulness as a scrappy open tool, Google replaced it with a closed, proprietary successor that ships as a standalone desktop application tied to Google Cloud.

This isn't a new story. We've seen it play out before:

Google Reader built a loyal community of RSS power users, then shut down.
Google Stadia courted game developers with open promises, then folded.
Firebase's open-source adjacency slowly drifted toward lock-in.

The pattern is: open source as acquisition funnel, not as philosophy. Launch something generous, gather contributors, validate the idea, close the door.

What stings about Gemini CLI specifically is that Google's own blog post thanks the community. It cites the 6,000 PRs. It acknowledges hundreds of contributors helped shape the product. And then it announces that all of that community investment is being handed off to a closed platform that, crucially, you cannot self-host in the same way.

To Be Fair to Antigravity

I want to be honest here, because I'm genuinely torn.

Antigravity CLI is technically impressive. The argument Google makes — that your terminal tool and your desktop agent need to share a unified backend to handle multi-agent complexity - is a real argument. When you're orchestrating five sub-agents doing parallel refactors, coordinating through a shared, hardened infrastructure matters. A loose open-source repo maintained by community weekends isn't the right home for that.

The Go rewrite is also a genuine quality-of-life improvement. Gemini CLI, for all its strengths, had latency that you felt. A snappier, more responsive tool isn't a marketing claim; it's real.

And for enterprise users — the ones Google is clearly most interested in — the Google Cloud integration, credential masking, and sandboxing are features that actually matter. A Fortune 500 company isn't going to run a community-maintained TypeScript CLI to push production code. Antigravity CLI is built for the people who pay the bills.

I get it. I just don't have to love it.

What We Actually Lost

When Gemini CLI was open source, I could:

Read exactly what it was doing when it touched my codebase
Fork it and add behavior my team needed without filing a feature request
Audit how it handled my code before trusting it with a production repo
Contribute and know that my fix would persist

With Antigravity CLI, I can use it. I can give feedback in a community forum. I can file feature requests and hope someone at Google agrees with me. That's a fundamentally different relationship with a tool.

The dev community spent the better part of a decade learning to be suspicious of black-box AI tools that touch their codebases. Gemini CLI, by being open, offered an answer to that suspicion. Antigravity CLI doesn't.

For a tool that wants to "orchestrate agents across your entire workflow" — touching your files, your Git history, your credentials — the closed-source decision feels like exactly the wrong call.

The Larger Shift I/O 2026 Is Signaling

Step back and look at what Google announced this year as a whole:

Gemini Spark is a "24/7 personal agent" that accesses your Gmail, Calendar, and Tasks
Antigravity 2.0 is a desktop app that steers agents across your projects
Managed Agents in the Gemini API provisions full agent infrastructure for you
Antigravity CLI handles your terminal

There's a coherent vision here, and it's not an open ecosystem. It's Google as the substrate. Every agentic workflow you build runs on infrastructure Google controls, through interfaces Google designs, against models Google hosts. The Antigravity SDK lets you "customize the agent," but you're still hosting it on Google's harness.

This is Google's answer to Microsoft's Copilot+ and Anthropic's Claude Code: a vertically integrated agentic platform. And it's probably going to be very good. That's sort of the problem.

The best agentic tools are becoming the ones most deeply locked into vendor ecosystems. The open alternatives - still worth rooting for, but always a step behind - can't match the integration depth that comes with a single company owning the whole stack.

What This Means for You (And for Me)

If you're a developer, the practical advice is boring: Antigravity CLI will probably be the better tool by August. Learn it. Use it. Enjoy the async workflows.

But keep asking the uncomfortable questions:

What happens to your workflows when Antigravity gets deprecated in 2028 for Supersymmetry CLI?
Where does your code go when it passes through a closed agent harness?
Who owns the institutional knowledge these tools build about how your codebase works?

The Google I/O keynote ended with the line: "We're bringing the models, infrastructure, and platforms together across Google to help you build anything you can imagine."

That sentence is doing a lot of work. Across Google. Building on Google. Anything you can imagine - so long as Google's infrastructure agrees.

My PR #19881 is sitting in a deprecated repo. The fix still works - remove unsafe type assertion suppressions in error utils, if you want to go look. The code is there, archived and frozen.

And somewhere in a Mountain View conference room, someone is presenting a roadmap slide that doesn't have Gemini CLI on it anywhere.

That's fine. That's how this industry moves. I just think it's worth naming it clearly, before we all sign up for the next open-source launch and start filing pull requests again.

Follow me here on dev.to if you want more takes on developer tooling, open-source sustainability, and the occasional misadventure in AI-assisted coding.

Stop Writing API Docs by Hand — Let Notion MCP Do It

Himanshu Kumar — Fri, 27 Mar 2026 17:50:57 +0000

This is a submission for the Notion MCP Challenge

What I Built

APIVault — a local FastAPI app that turns raw route code or plain-English API descriptions into full API documentation, then stores everything in Notion through the Notion MCP.

The idea is simple: you point APIVault at a router file (or just describe an endpoint in plain English), and it generates structured documentation and pushes it directly into a Notion workspace it sets up for you — no copy-pasting, no manual page creation.

The frontend is a vanilla HTML/CSS/JS dashboard with:

Live search across your documented endpoints
Documentation preview pane
Source vs. generated toggle so you can diff your raw code against what was documented

There's also a CLI tool (vault.py) for batch-documenting entire files without opening the UI.

Endpoints

Route	What it does
`POST /api/setup`	Creates (or reuses) the APIVault Notion workspace — an `📖 API Reference` database, a `🏷️ Services` database, and an `📚 API Docs` hub page
`POST /api/document-endpoint`	Documents a single endpoint, writes it to Notion, returns the generated content + the Notion page URL
`POST /api/document-collection`	Splits a router/controller file into individual endpoints and documents them in parallel
`POST /api/generate-readme`	Generates a `📄 [Service] — README` Notion page from endpoints already stored
`GET /api/search?q=`	Powers the dashboard's live search
`GET /api/sidebar`	Feeds the left-side navigation tree

Stack

Backend: FastAPI + Python
AI: HuggingFace Inference API (documentation generation)
MCP: Notion MCP via https://mcp.notion.com/sse (SSE transport)
Frontend: Vanilla HTML/CSS/JS

Video Demo

No video for this submission.

Show us the code

🔗 github.com/himanshu748/dev-challenge-5

Getting started locally

# 1. Clone and set up
git clone https://github.com/himanshu748/dev-challenge-5
cd dev-challenge-5
python -m venv venv && source venv/bin/activate
pip install -r requirements.txt

# 2. Configure environment
cp .env.example .env
# Set NOTION_TOKEN (MCP OAuth token) and HF_TOKEN

# 3. Run
uvicorn app.main:app --reload
# Open http://127.0.0.1:8000

CLI usage for bulk documentation:

python vault.py \
  --file routes/users.py \
  --service UserService \
  --base-url https://api.example.com

How I Used Notion MCP

APIVault uses the Notion MCP exclusively — there are zero calls to the direct Notion REST API anywhere in the codebase. NOTION_TOKEN must be a Notion MCP OAuth access token, not a Notion integration secret. This matches how the hosted MCP is meant to be used: access is granted through the MCP OAuth flow, not the legacy secret model.

On startup, POST /api/setup calls the Notion MCP to provision the entire workspace structure:

An 📖 API Reference database where each endpoint lives as a page with properties like method, path, service, parameters, and response schema
A 🏷️ Services database for grouping endpoints by service name
An 📚 API Docs hub page that ties everything together

When an endpoint is documented (either individually or from a batch file), the generated content is written to a new Notion page via the MCP and the returned Notion URL is surfaced in the dashboard so you can jump straight to it.

The generate-readme flow goes the other way: it queries Notion through the MCP to pull all endpoints for a given service, then synthesizes them into a formatted README page — so Notion stays the source of truth for the whole workflow.

A local JSON cache (data/apivault_state.json) exists purely for UI responsiveness (fast sidebar loads, instant search), but every write and authoritative read goes through the MCP.

What the Notion MCP unlocks here that wouldn't be practical otherwise:

Structured storage without schema management — Notion databases give you typed properties (selects, rich text, URLs) without standing up a real database
Human-readable side effect — every documented endpoint is immediately browsable in Notion by the whole team, not just queryable via API
README generation from live data — because the MCP lets you query what's already stored, the README reflects the actual current state of your docs, not a stale snapshot

Your Team's Code Reviews Are Disappearing — I Built PRReviewIQ to Fix That

Himanshu Kumar — Fri, 27 Mar 2026 17:36:51 +0000

Every code review your team does contains hard-won knowledge: a bug pattern caught, a performance trap avoided, a naming convention enforced. And almost all of it evaporates the moment the PR is merged.

PRReviewIQ is my attempt to fix that. It's an AI code review tool that doesn't just comment on diffs — it remembers. Every insight gets logged into a living Notion knowledge base via Notion MCP, so your team's collective code quality wisdom compounds instead of getting buried in closed PRs.

Video Demo

Show Us the Code

🔗 github.com/himanshu748/dev-challenge-4

The Problem Worth Solving

Code review is one of the highest-leverage activities on any engineering team — but it's almost entirely ephemeral. Comments live on GitHub. Patterns go untracked. New teammates repeat the same mistakes. There's no institutional memory.

I wanted Notion to be that memory. Not as a place to manually paste notes, but as a database that an AI agent actively writes to as part of the review process itself.

How It Works

PRReviewIQ ships as two interfaces over the same core:

Web app — a FastAPI server at http://127.0.0.1:8000 where you can paste diffs and trigger reviews through a browser UI.

CLI — run it directly against a local git repo:

python review.py --repo /path/to/repo

# Or target a single file for pre-commit checks
python review.py --file path/to/file.py --pr-title "Pre-commit review" --repo-name my-repo

Under the hood, every review goes through HuggingFace, and every finding gets written into Notion through MCP.

How I Used Notion MCP

Here's the part I'm most proud of from an architecture standpoint.

Most Notion integrations make direct REST calls. I went a different route: PRReviewIQ runs the official @notionhq/notion-mcp-server locally via npx, and passes NOTION_TOKEN directly to the MCP process. The app itself never touches the Notion REST API — all writes happen through MCP.

This matters because it means the LLM is using Notion as a tool, not just a destination. When it reviews a diff, it decides what's worth logging, how to categorize it, and where it belongs in the knowledge base — the same way a human reviewer would decide what's worth writing down.

What gets built in Notion:

A coding standards database that evolves as the agent identifies recurring patterns. You can query it live via GET /api/standards — it reads directly from Notion and returns JSON, so the app and the team always share the same source of truth.
A reviews log — every PR review stored as a structured Notion entry, searchable and linkable.
Weekly digest pages — POST /api/weekly-digest aggregates trends across recent reviews and writes a summary page your team can async through on Mondays.

The compounding effect is the real value: the knowledge base gets more useful the more you use it.

Technical Note on the MCP Setup

Running @notionhq/notion-mcp-server via npx means Node.js needs to be installed alongside Python. The MCP server process is spawned by the app at runtime — no separate setup step required beyond having npx available.

# Prerequisites
python 3.11+
node + npx

# .env
HF_API_KEY=hf_...
NOTION_TOKEN=...
NOTION_PARENT_PAGE_ID=...

# Run
pip install -e .
uvicorn app.main:app --reload

The first call to POST /api/setup provisions the full Notion workspace structure — databases, log pages, and the standards section — and you're ready to start reviewing.

What I'd Build Next

The CLI is useful but I want to wire it into a git pre-commit hook so reviews happen automatically before every push. The Notion knowledge base is already there — the next step is making the feedback loop tighter.

From Job Post to Offer Letter — Automated with Notion MCP

Himanshu Kumar — Fri, 27 Mar 2026 16:11:42 +0000

How I Used Notion MCP to Build an AI Recruiting Assistant

What I Built

HireIQ is an AI-powered recruiting assistant that uses Notion as its entire operational backbone. Point it at a role you're hiring for and it will:

Spin up a recruiting workspace in Notion automatically
Write polished, structured job descriptions and save them as Notion pages
Screen candidates against the role criteria and log results
Generate offer letters — drafted by AI, stored in Notion

The entire hiring pipeline lives in Notion. HireIQ just drives it.

Video Demo

Show Us the Code

🔗 github.com/himanshu748/dev-challenge-3

How I Used Notion MCP

HireIQ connects to Notion via the remote Notion MCP server at https://mcp.notion.com/sse — attached directly to a HuggingFace MCPClient. This means the AI model doesn't just answer questions about hiring; it actively reads from and writes to Notion as part of every step in the pipeline.

1. Workspace Setup (`POST /api/setup`)

On first run, HireIQ uses Notion MCP to create the full recruiting workspace structure — databases, pages, and sections — ready to receive jobs and candidates. Zero manual Notion configuration needed.

2. Job Description Creation (`POST /api/add-job`)

The AI generates a complete, professionally formatted job description and writes it directly into Notion via MCP. Every role gets its own page, making the workspace a living hiring hub rather than a static document.

3. Candidate Screening (`POST /api/screen-candidate`)

HireIQ reads the job requirements from Notion, evaluates the candidate against them using the LLM, and logs the screening result back into Notion — keeping everything in one place for the hiring team to review.

4. Offer Letter Generation (`POST /api/generate-offer`)

Once a candidate clears screening, HireIQ drafts a tailored offer letter and saves it to Notion via MCP. The whole candidate journey — from application to offer — is tracked in one workspace.

What Notion MCP Unlocks

The remote MCP connection (https://mcp.notion.com/sse) is what makes this work at a different level than a plain Notion API integration. The LLM has Notion MCP as an attached tool — so it can decide when and how to read or write Notion data as part of reasoning through each task. It's not just API calls wrapped in Python; the model is an active agent that uses Notion as its memory and output layer.

Every write endpoint returns a notion_urls field so the frontend can link directly to the pages the agent just created.

Tech Stack

Layer	Technology
Backend	FastAPI + Python
AI / LLM	HuggingFace (`Qwen/Qwen2.5-72B-Instruct`) via MCPClient
Data store	Notion (via remote Notion MCP at `https://mcp.notion.com/sse`)
Frontend	Vanilla HTML/CSS/JS

Getting Started

# 1. Clone the repo
git clone https://github.com/himanshu748/dev-challenge-3

# 2. Create a virtual environment
python3 -m venv .venv
source .venv/bin/activate

# 3. Install dependencies
pip install -r requirements.txt

# 4. Configure environment variables

Create a .env file:

HF_API_KEY=hf_...
NOTION_TOKEN=...          # Must be a current OAuth access token (not an internal integration token)
NOTION_PARENT_PAGE_ID=... # Parent page for the recruiting workspace
HF_MODEL=...              # Optional — defaults to Qwen/Qwen2.5-72B-Instruct

# 5. Start the server
uvicorn app.main:app --reload

Open http://127.0.0.1:8000 in your browser.

Note: NOTION_TOKEN must be a current OAuth access token for the remote Notion MCP server. A plain internal integration token will not work for the https://mcp.notion.com/sse connection.

How I Used Notion MCP to Build an Autonomous Personal Finance Tracker

Himanshu Kumar — Thu, 26 Mar 2026 16:41:46 +0000

FinanceIQ — AI-Powered Finance Tracker Built with Notion MCP

What I Built

FinanceIQ is an AI-powered personal finance tracker that turns Notion into a fully automated financial command center. It ingests your bank's CSV exports, categorizes every transaction using AI, detects suspicious or anomalous spending, generates monthly financial reports, and fires budget alerts — all written directly into Notion via the Notion MCP.

No spreadsheet juggling. No manual tagging. Your finances, organized and analyzed — living right inside Notion.

Video Demo

Show Us the Code

🔗 github.com/himanshu748/dev-challenge-2

How I Used Notion MCP

Notion MCP is the backbone of FinanceIQ. Rather than building a standalone dashboard that lives in isolation, I wanted all financial data to live natively in Notion — so it's searchable, shareable, and editable like any other Notion page.

Here's exactly how Notion MCP powers each part of the workflow:

1. One-Click Workspace Setup

On first run, FinanceIQ uses Notion MCP to automatically create:

An Expenses database with the right properties (date, amount, category, anomaly flag, etc.)
A Reports page where monthly summaries will be written

No manual Notion setup required — the agent handles it entirely through MCP.

2. Transaction Import & AI Categorization

When a user uploads a CSV (from Chase, Bank of America, Wells Fargo, or Mint), FinanceIQ:

Parses each transaction
Sends it to a HuggingFace-hosted Mistral model (via MCPClient) for categorization into 10 spending categories
Flags anomalies: transactions that are 3x the category average, duplicates, or suspiciously round amounts
Writes each transaction as a new row in the Notion Expenses database via MCP

3. Monthly Report Generation

The /report endpoint aggregates data from Notion, runs it through the AI, and writes a structured monthly report page back into Notion including:

Income vs. expenses summary
Category-by-category breakdown
AI-generated spending recommendations

4. Budget Alerts

Users can set monthly budget limits per category. FinanceIQ compares actuals against limits and — when thresholds are exceeded — creates a dedicated Budget Alert page in Notion via MCP with details on which categories overspent and by how much.

What Notion MCP Unlocks

The key insight: Notion MCP lets an AI agent treat Notion as a live, writable database — not just a document viewer. That means FinanceIQ can autonomously create structure, push data, and generate reports without any manual copy-pasting. The financial intelligence stays inside Notion where users already live and work.

Tech Stack

Layer	Technology
Backend	FastAPI + Python
AI / LLM	HuggingFace (Mistral-Small-3.1-24B) via MCPClient
Data store	Notion (via Notion MCP)
Frontend	Vanilla HTML/CSS/JS — newspaper-inspired design

Getting Started

# 1. Clone the repo
git clone https://github.com/himanshu748/dev-challenge-2

# 2. Install dependencies
pip install -r requirements.txt

# 3. Configure environment variables
cp .env.example .env
# Add your HF_API_KEY and NOTION_TOKEN

# 4. Start the server
uvicorn main:app --reload

Then open http://localhost:8000 in your browser.

Required environment variables:

Variable	Description
`HF_API_KEY`	Your HuggingFace API key
`NOTION_TOKEN`	Your Notion integration token
`NOTION_PARENT_PAGE_ID`	(Optional) Parent page ID for the workspace
`HF_MODEL`	(Optional) Defaults to `mistralai/Mistral-Small-3.1-24B-Instruct-2503`

I Built an AI PM That Creates PRDs & Sprint Plans Directly in Notion

Himanshu Kumar — Thu, 26 Mar 2026 15:44:10 +0000

This is a submission for the Notion MCP Challenge

What I Built

AutoPM is an AI-powered product management assistant that turns a single product idea
into a fully structured Notion workspace — PRDs, task breakdowns, daily standups, and
sprint plans — in seconds.

No more context-switching between AI tools and your Notion workspace. Just describe your
product idea, and AutoPM:

Generates a full PRD — problem statement, goals, user personas, user stories, and out-of-scope items
Breaks it into Epics & Tasks — with priorities, story points, and a ready-to-go Sprint 1 plan (~20 story points)
Writes everything directly to Notion via Notion MCP
Reads your workspace via MCP to generate context-aware daily standups and sprint plans from your real backlog

🔗 Live demo: autopm-two.vercel.app

🔗 GitHub: github.com/himanshu748/dev-challenge-1

Video Demo

Show us the code

himanshu748 / dev-challenge-1

AutoPM — AI Product Manager

AI-powered product management assistant that creates PRDs, task breakdowns, standups, and sprint plans directly in Notion — built with HuggingFace Inference API + Notion MCP.

Built for the dev.to Notion MCP Challenge.

Live demo: autopm-two.vercel.app

What It Does

Enter a product idea and AutoPM:

Generates a full PRD via HuggingFace AI (problem, goals, personas, user stories, scope)
Creates an Epics & Tasks breakdown with priorities and story points
Writes everything to Notion via Notion MCP (stdio transport)
Reads your workspace via MCP to generate context-aware standups and sprint plans

How I Used Notion MCP

AutoPM uses @notionhq/notion-mcp-server via stdio transport for ALL Notion operations:

Reads — API-post-search to scan workspace pages, API-get-block-children to read task data
Writes — API-post-page to create PRD pages, task breakdowns, standup reports, sprint plans
Auth check — API-get-self to verify MCP connectivity on health check

The MCP server…

View on GitHub

How I Used Notion MCP

Notion MCP is the backbone of AutoPM — every single Notion interaction goes through it,
zero direct REST calls.

I spin up @notionhq/notion-mcp-server as a stdio child process per request, managed
by the Python mcp SDK's ClientSession:

from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async with stdio_client(StdioServerParameters(
    command="npx",
    args=["-y", "@notionhq/notion-mcp-server"],
    env={"NOTION_TOKEN": token},
)) as (read, write):
    async with ClientSession(read, write) as session:
        await session.initialize()
        await session.call_tool("API-post-page", {...})

MCP tools used

Tool	Purpose
`API-get-self`	Health check — verify MCP connectivity on startup
`API-post-search`	Scan workspace for existing pages before generating standups
`API-get-block-children`	Read task data from Notion for context-aware generation
`API-post-page`	Create PRD pages, task breakdowns, standup reports, sprint plans

What Notion MCP actually unlocks

Without MCP, AutoPM would be a one-way pipe — generate content, dump it somewhere.
With MCP, it becomes bidirectional: it reads your existing workspace state before
generating anything. The standup and sprint planner aren't making things up — they're
grounded in your actual Notion data. That's the real unlock.

Architecture

┌─────────────────┐     ┌──────────────────────┐     ┌──────────────────────┐
│  Browser (UI)   │────▶│  FastAPI Backend      │────▶│  Notion MCP Server   │
│  Vanilla HTML   │     │  (Python)             │     │  (stdio transport)   │
└─────────────────┘     └────────┬─────────────┘     │  npx @notionhq/      │
                                 │                    │  notion-mcp-server   │
                                 ▼                    └──────────┬───────────┘
                        ┌──────────────────┐                    │
                        │  HuggingFace     │                    ▼
                        │  Inference API   │           ┌─────────────────┐
                        │  (Qwen 72B)      │           │  Notion API     │
                        └──────────────────┘           └─────────────────┘

Flow: HuggingFace (Qwen 2.5 72B) generates structured PM content → FastAPI formats
Notion blocks → MCP writes/reads Notion workspace

Tech Stack

Backend: FastAPI (Python)
AI: HuggingFace Inference API — Qwen/Qwen2.5-72B-Instruct (free tier!)
Notion: @notionhq/notion-mcp-server via stdio transport
MCP SDK: Python mcp package — ClientSession + StdioServerParameters
Frontend: Vanilla HTML/CSS/JS, glassmorphism dark theme
Deployed on: Vercel

Just completed AWS AI & ML challenge.

Himanshu Kumar — Mon, 21 Jul 2025 19:21:27 +0000

Hey dev++ community! 🚀

Just completed the AWS AI & ML Scholars Challenge and got certified in Generative AI with AWS!

Learned a ton about AWS Bedrock, SageMaker, prompt engineering, and building real AI applications. The hands-on experience with generative AI was amazing.

Would love to connect with anyone else working on AI/ML projects or interested in AWS AI services!

Check out my full post: (https://www.linkedin.com/posts/himanshu748_aws-artificialintelligence-machinelearning-activity-7353138026996289538-tIXc)

What AI projects are you all working on? Let's share and learn together! 💪

AWS #AI #MachineLearning #DevCommunity[]

Get your startup logo in seconds

Himanshu Kumar — Sat, 05 Jul 2025 18:32:52 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

An imagen powered logo generator for startups.

Demo

https://aistudio.google.com/apps/drive/18tmCeBIzNHseSJjtA4sVC5NHLAFnoAgS?showPreview=true&resourceKey=

My Experience

It was nice working with Google ai studio after 1 and half years it's really upgraded

DEV Community: Himanshu Kumar

SOLSTICE — The Longest Day: a platformer where light is your only resource

What I Built

Code

himanshu748 / solstice

SOLSTICE — The Longest Day

Controls

Tech

How I Built It

Python Automation Training Toolkit: from abandoned group project to browser-first AI workspace

What I Built

Demo

Why This Project Needed a Finish-Up

The Comeback Story

What Changed

What I Am Proud Of

My Experience With GitHub Copilot

Building RepoRank — The Open Source Impact & Funding Readiness Engine

The Open Source Funding Crisis

The Secret Weapon: Coral SQL

Building the Sources We Needed

Upstream Contributions

From Raw Data to Actionable Insights

A Premium User Experience

Key Takeaways

🔗 Links & Resources

My PR Merged Into a Graveyard: On the Rise of Antigravity and the Fall of Open Source

What Actually Happened at I/O 2026

The Bait-and-Switch Pattern We Keep Accepting

To Be Fair to Antigravity

What We Actually Lost

The Larger Shift I/O 2026 Is Signaling

What This Means for You (And for Me)

Stop Writing API Docs by Hand — Let Notion MCP Do It

What I Built

Endpoints

Stack

Video Demo

Show us the code

Getting started locally

How I Used Notion MCP

Your Team's Code Reviews Are Disappearing — I Built PRReviewIQ to Fix That

Video Demo

Show Us the Code

The Problem Worth Solving

How It Works

How I Used Notion MCP

Technical Note on the MCP Setup

What I'd Build Next

From Job Post to Offer Letter — Automated with Notion MCP

How I Used Notion MCP to Build an AI Recruiting Assistant

What I Built

Video Demo

Show Us the Code

How I Used Notion MCP

1. Workspace Setup (POST /api/setup)

2. Job Description Creation (POST /api/add-job)

3. Candidate Screening (POST /api/screen-candidate)

4. Offer Letter Generation (POST /api/generate-offer)

What Notion MCP Unlocks

Tech Stack

Getting Started

How I Used Notion MCP to Build an Autonomous Personal Finance Tracker

FinanceIQ — AI-Powered Finance Tracker Built with Notion MCP

What I Built

Video Demo

Show Us the Code

How I Used Notion MCP

1. One-Click Workspace Setup

2. Transaction Import & AI Categorization

3. Monthly Report Generation

4. Budget Alerts

What Notion MCP Unlocks

Tech Stack

Getting Started

I Built an AI PM That Creates PRDs & Sprint Plans Directly in Notion

What I Built

Video Demo

Show us the code

himanshu748 / dev-challenge-1

1. Workspace Setup (`POST /api/setup`)

2. Job Description Creation (`POST /api/add-job`)

3. Candidate Screening (`POST /api/screen-candidate`)

4. Offer Letter Generation (`POST /api/generate-offer`)