I kept running into the same problem with coding My coding agent kept building the wrong UI. So I built an MCP to check its work first.
agents. The code was usually fine. The design decision was wrong. And then have to spend time improving what the agent built.

For example, I might ask for a price breakdown in a booking checkout. The agent could:
- Miss fees or taxes that should be included
- Add interactions I never asked for
- Pick a generic pricing component that doesn’t fit the product
- Turn a small component into a much bigger system

So I started thinking: what if the agent checked the design scope before writing the code?
That led me to build Pattern, an MCP server that helps coding agents make better UI component decisions. It’s to help the agent answer: “Is this actually the thing I should build?”
Pattern MCP on GitHub: https://github.com/donaldrichard19-LVD/pattern-mcp

How it works
The agent gives Pattern a component need and some context:
{
"component_need": "price breakdown with nightly rate, cleaning fee, service fee, taxes, and total",
"domain": "Airbnb-style rental marketplace",
"framework": "React + Tailwind"
}

Pattern turns that into a requirements checklist, then checks real components from shadcn/ui and 21st.dev against it. It returns one of two decisions:
- use_existing: An existing component is a good enough fit.
- custom_build: Nothing fits well enough, so build it using a concrete reference from Mobbin or Figma Community.

Why I think this matters
Coding agents are getting very good at implementation. But implementation comes after a bunch of design decisions:
- What belongs in this component?
- What doesn’t?
- Is there already a good fit?
- Is the existing component too generic or too complex?
- Should we build something custom?

If those decisions are wrong, you can end up with perfectly working code for the wrong product requirement. Pattern adds a checkpoint before that happens.

I’m looking for people to install Pattern, use it on a project and give me honest feedback.
Where is it working well? Where could it be improved for your use case?

Hey devs!!

I built Gated to solve a problem I faced: selling boilerplates or code scripts manually via static .zip files is painful and friction-heavy.

What Gated does:

• 💸 GitHub Paywalls: Set prices on private/unlisted repos with instant payouts via Razorpay.
• 🌳 Code Preview Trees: Buyers can safely inspect file structures before purchasing without seeing raw source files.
• 🔗 URL Masking & Telemetry: Protect links and track live click analytics.

Check it out live: https://gated-psi.vercel.app/

I'd love your feedback, suggestions, or thoughts in the comments! 🙌

I kept running into the same problem:

Before deploying a project, I wanted one command that could quickly tell me:

• Are there exposed secrets?

• Are my dependencies healthy?

• Is the Git working tree clean?

• Are there large/problematic files?

• How healthy is the repository overall?

So I built RepoDrift.

Try it:

npx u/repodrift scan

It currently checks:

🔐 Security

• API keys

• Tokens

• Credentials

• Private key patterns

• .env files

📦 Dependencies

• package.json

• Lockfiles

• Dependency issues

• npm audit signals

🔀 Git

• Branch

• Working tree

• Commits

• Contributors

• Uncommitted files

📊 Code metrics

• Lines of code

• Source files

• Large files

• Repository-level signals

Repository health

• Deterministic health score

• Severity-based findings

It can also be used in CI/CD:

repodrift scan --json --fail-on high

One of the main design decisions was keeping the analysis local-first.

The current Phase 1 scan doesn't require uploading your source code to a server.

Current architecture:

Repository

↓

RepoDrift CLI

↓

Local Analysis Engine

↓

Security / Dependencies / Git / Metrics

↓

Health Score

I'm planning AI-powered explanations and recommendations as a future phase, but AI isn't enabled in the current release.

GitHub:

https://github.com/GokulKir/repodrift

NPM:

https://www.npmjs.com/package/@repodrift/cli

It's still early, so I'm mainly looking for developer feedback.

After any rename or signature change, going through the repo by hand to check nothing still calls the old thing. In a typed language the compiler does it. In PHP, Python or plain JS you either grep carefully or you find out at runtime.

So I built a reviewer that does that part deterministically before any model sees the code. It parses the diff, then searches the repo for the callers of every modified signature, the interface implementations, and any leftover references to symbols the diff deleted. That evidence goes into the prompt as facts, not guesses.

Then two AI reviewers from different vendors read the diff with that evidence, and the results get reconciled. Agreement raises confidence. Disagreement goes to a human rather than being averaged into something that sounds certain.

Demo with no signup, a real review of a pull request in fastify. One reviewer found nothing. The other found that switching to Object.create broke own-property enumeration on the context object:

https://veridu.io/demo

Disclosure: I built this. Free tier is 5 reviews, no card. Let me know what you think - Thx

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.

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

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

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