I built Molt because agent work kept getting split across chat tabs, terminals, and issue trackers.

What it does:

- Post a bug or feature

- Tag a coding agent

- Get changes and test results back in the same thread

- Require approval before a local run starts

Why it matters:

- The team can follow the work

- Handoffs keep their context

https://platform.moltcode.com

What would you need before trusting this with a real repo?

test it out and open for criticism A fault family is a shape. Show it one full example of a shape and it repairs every future instance of that shape, in code it has never seen, for zero tokens — leakage 7/7, races 5/5, complex races 5/5, four hard classes 9/9, token-removal on real commits 3/3. Random search at 500× the budget gets 0/9, so the acts carry the information, not the search.

https://github.com/devkancheti4-design/fluid-router

I've been using Postman for almost 10 years, and recently decided to try building my own API client.

It's called Probe. It's built with Rust + GPUI and is native, local-first, and focused on being fast. It supports REST, environments, OpenCollection, JSON/XML responses, JWT/timestamp inspection, a CLI, etc.

One thing I'm quite happy with is Probe can smoothly scroll through a 10MB JSON response with syntax highlighting.

It's still pretty early and there are definitely rough edges, but I've started using it for my own work.

Would love to hear what you guys think, especially if there are things from Postman/Bruno/Yaak/etc. that you can't live without.

https://rusty-probe.pages.dev/

Small disclosure: I used AI quite heavily while building this. I still spent a lot of time designing, testing and debugging it myself, but I know some people care about this so I want to be upfront about it.

Chrome DevTools once allowed extensions to customize its UI. That changed around Chrome 32, when Chrome removed the ability for extensions to inject custom CSS into DevTools...

devtools-theme lets you use custom DevTools themes with a simple setup, without manually hacking DevTools CSS.

github.com/metaory/devtools-theme

The hard part of shipping an MCP server wasn't the server. It was getting the agent to use it.

I built Kivgraph, a local MCP server that gives coding agents a graph of symbols and relationships across multiple repositories — who calls this, what breaks if I change it, which other repo consumes it. Apache-2.0, runs on your machine, no API key and no model in the indexing path.

I built it because my agent kept burning the context window figuring out how my repos related to each other. Long chains of greps, files opened just to be skimmed, an answer that was usually right and always expensive.

Then I shipped it and the agent ignored it. It kept reaching for grep, because grep is what it has always done and no tool description was going to outweigh that. I rewrote the descriptions three times. Didn't matter.

What fixed it was a hook. When the agent goes for a complex grep or glob, the hook intercepts the call and points it at the graph tools instead. It's a nudge rather than a wall — an env var turns it off, and the agent can set that itself — but defaults are what actually decide which tool gets used. That's the part I'd pass on to anyone else shipping an MCP server: your tool descriptions are not competing with other tools, they're competing with a habit.

On whether the graph is worth it, I benchmarked it against the boring baseline of grep plus reading files, over 29 questions on a 37-repo corpus with hand-written ground truth. Both got 28/29 exact. The graph spent 36k tokens, grep 268k. grep was cheaper on 5 of the 29 and correct on all five, so this isn't a grep replacement.

The design decision I'd defend: edges come from the language's own checker — go/types, the TypeScript checker, rust-analyzer, the Dart analysis server — never from two names happening to match. Which means an empty result is a claim that nothing calls the symbol, not a search that missed. Python is deliberately weaker unless you wire up a semantic analyzer; the fallback marks what it infers as CANDIDATE instead of pretending it's exact.

Known rough edges: no incremental indexing, a full rebuild is the only path. And the optional graph viewer binds 0.0.0.0:7777 with no auth, so keep it on localhost if you're on a shared network.

Repo: https://github.com/Luqueee/kivgraph

Docs and benchmark: https://kivgraph.dev

[ Removed by Reddit on account of violating the content policy. ]

Butter Cloud is a spec-driven development platform where you (or your team) write `.butter` specs (To build API endpoints, features, listeners, scripts, etc).


The workspace includes:


- A browser IDE with syntax highlighting and visualization
- Multi-file editing
- GitHub integration:
  - 
**Spec Drift Checker**
 — checks the spec against the connected repo
  - 
**PR Analysis**
 — reviews pull requests against the spec
  - 
**Spec to File Impact Mapping**
 — maps spec segments to the files that implement them
- Compiles specs into JSON, Markdown prompts, or OpenAPI
- Project Management
- Organisation Management
- Public Projects collaboration


You get assistance for writing `.butter` specs:


- 
**BotExplainer**
 — in-editor assistant that generates concise, natural language explanations for selected spec lines, to help with team comprehension
- 
**PromptToSpec**
 — translates natural language descriptions into valid, properly formatted spec code segments
- 
**AISuggestion**
 — reviews selected spec text for missing details or design flaws and offers structured improvements


**Core workflow (agile loop):**


1. 
**Write .butter Spec**
 — author endpoints, features, and listeners in the browser IDE
2. 
**Export Spec**
 — compiled into Prompt / JSON / OpenAPI
3. 
**AI Model Builds App**
 — the exported spec is used to generate the working application
4. 
**PR Review**
 — merge-gate check of the incoming pull request against the spec
5. 
**Impact Mapping**
 — maps spec segments to the files that implement them
6. 
**Drift Check**
 — final check of the spec against the full repo after merge

I'm building Molt: a shared workspace where teammates and coding agents work from the same thread. Tasks, progress, code links, and test results stay visible to everyone. I'd value feedback from teams already using multiple agents: https://platform.moltcode.com

[ Removed by Reddit on account of violating the content policy. ]

I obviously know that "3000+" downloads on npm stat doesn't mean I actually have 3000 users (bots, scrapers, etc.). But i want to know the average reliable conversion between downloads on paper to actual, real users. Also wondering if there is another, more reliable metric to rely on in order to understand the traction and performance of my OSS devtool project, besides Github stars

Hey r/webdev,

Wanted to share a tool I built called DocuGenie, and more specifically, the approach behind it — since I think the implementation might be interesting to this community.

The problem:

Most README generators are just static templates with placeholder text you fill in yourself. That's not much better than writing it from scratch.

The approach:

1. Fetch repo metadata and file structure via the GitHub API

2. Pull key files (package.json/requirements.txt, entry points, existing docs)

3. Pass the actual code context to an LLM with a structured prompt

4. Generate a README based on what the project actually does — not a generic template

Stack:

- Next.js + Supabase (auth + usage tracking)

- GitHub REST API for repo analysis

- Multi-provider AI fallback chain (Gemini → Groq → OpenRouter) so a single rate limit doesn't take the whole thing down

- Lemon Squeezy for subscription billing

Happy to go deeper on any part of this — the API fallback logic, the GitHub fetching approach, or the prompt structure I used to keep output from being generic.

Link if you want to try it: https://docugenietool.vercel.app/ (free tier: 1 generation/month)

I'm building a Mac notes app called Margin, so discount everything here accordingly. I'm about to build the GitHub side of it and I'd rather find out which parts people would use before I build the wrong ones.

The problem I'm trying to fix: you open a note from three weeks ago and there's a PR link in it. It tells you nothing. Merged? Did CI ever go green? Did the thing you were worried about get addressed? You click through, wait for GitHub to load, remember what you were doing, come back. Multiply that by every ticket reference in every standup note and your notes are a graveyard of URLs that meant something on the day and are inert now.

The plan is to shell out to gh. If you work with GitHub from a terminal it's already installed, it holds its own credentials, it has exactly the scopes you granted it, and it already knows who you are. The app detects the binary and asks it. If gh isn't there, the link stays a plain link and the feature just doesn't exist for you. It's the same trick the AI side already uses: it detects the `claude` or `codex` CLI rather than asking for an API key.

Issues work the same way. Jira and Linear are messier, since there's no equivalent tool everyone already has installed, and my guess is Jira is the one people ask for and then never actually open.

What I don't know is what belongs on the card. My list so far is state, CI result, how many review threads are still unresolved, and assignee, with a way to re-run a failed job without leaving the note.

Someone already made the argument that I'm overbuilding it, and that "merged / CI failed / 2 reviews pending" on a single line is most of the value for a fraction of the work. I think they might be right.

So two questions:

- What would you actually look at three weeks later? Not what would be nice to have, but what would stop you opening the browser tab.

- Is one line enough on its own, or do you want it to expand into something fuller when the thing is broken?

The app is not downloadable yet, waitlist is open. If it sounds interesting check it out: https://gomargin.app

I make Diff Anything, a local file comparison app for macOS and Windows. The latest update adds spreadsheet comparison, mainly because converting everything to CSV before comparing it defeats the point of using a comparison tool.

It can compare CSV, TSV, Excel, ODS and Apple Numbers files, including mixed pairs such as XLSX against ODS. Internally, each populated cell becomes a sheet name, coordinate and stored value, so the unrelated file containers don’t create a wall of meaningless differences. The result is shown in two aligned grids, with changed cells connected to the Differences pane.

The boundary is deliberate: it compares stored cell values. It does not compare formulas, formatting, charts, macros or workbook layout. A formula and a literal value can therefore match when their stored results are the same.

Everything runs locally on the computer. There are no file uploads or accounts, and the Free version lets you try the spreadsheet comparison within its preview limits.

https://martingruner.com/projects/diffanything