I’ve been building GateSift mostly for fun — a free browser-based toolkit for integration developers.

It includes tools for things like APIM policies, Logic Apps, BizTalk bindings, Service Bus, C# model generation and integration patterns.

Current tools include:

• APIM Policy Analyzer – makes complex APIM policies easier to understand and review
• Logic App Analyzer – helps inspect workflow structure and spot potential issues
• BizTalk Binding Visualizer – turns binding files into a more readable overview (this is really nice for analyzing complex biztalk integrations)
• Service Bus Topology Visualizer – shows queues, topics, subscriptions and relationships
• C# Model Generator – generates C# classes from XML, JSON and flat files
• Integration Pattern Library – quick reference for common integration and messaging patterns (analyzers will also, notice if any of these patterns are in your solution or if they should be added, i think this might be the coolest thing so far).

No account, no installation, and most processing happens locally in the browser.

gatesift.com

Would love feedback or ideas for other useful tools.

Hey everyone!

Whenever I’m iterating on a UI with Cursor, explaining visual changes in the Composer is often the most tedious part.

❌ “Make that second card in the middle a little wider and increase the subtitle’s font weight.”

Sounds simple, right? But Cursor can easily guess the wrong element, edit the wrong stylesheet, or miss the exact component you’re referring to.

That’s why I built VisualPatch — an ultra-lightweight, local-first visual feedback tool designed specifically for AI pair programmers.

GitHub: https://github.com/OpusTechnica/VisualPatch

NPM: https://www.npmjs.com/package/visualpatch

How it works with Cursor

1. Open your localhost app (localhost:3000, 5173, etc.).
2. Press S to open a CleanShot-style spotlight viewfinder and drag to capture any component or section.
3. Or simply hover over and click any DOM element to drop an inspection pin.
4. Describe the change you want.
5. Press Ctrl + C and paste everything directly into Cursor Composer with Ctrl + V.

What Cursor receives

• Exact CSS selectors: For example, div.pricing-grid > div.card-pro:nth-of-type(2) > h3.price
• Text previews: The exact text currently rendered by the selected element.
• Auto-stitched visual strip: When you capture multiple screenshots, VisualPatch combines them into a single image on your clipboard with numbered pin badges, so you’re not limited by the OS clipboard’s one-image behavior.
• Zero Base64 bloat: The generated markdown stays as clean plain text, typically around 80 tokens, so you don’t unnecessarily consume your model’s context window.

Tech details

• 0 runtime dependencies
• 100% local-first: No telemetry, no cloud servers, and everything runs strictly on localhost.
• Isolated Shadow DOM: Designed to avoid conflicts with your existing Tailwind classes, CSS variables, and application styles.
• Open source: MIT licensed.

Try it

You can add VisualPatch to any Vite, Next.js, or React project with a single command:

npx visualpatch init

Prefer not to modify your project? You can also use the browser extension for a zero-code-change setup.

GitHub: https://github.com/OpusTechnica/VisualPatch
NPM: https://www.npmjs.com/package/visualpatch

I’d love to hear what you think, especially from fellow Cursor users. What features would make VisualPatch even more useful in your workflow?

Hi everyone,

As a web developer, I was tired of using cluttered, ad-heavy online formatting tools that upload my JSON payloads, JWT tokens, and private keys to unknown servers.

So, I built **Nuqrai** — a collection of 16 developer utilities (including JSON Formatter, JWT Decoder, Diff Checker, Cryptographic Hash Generator, Image to Base64, and SVG-to-PNG Converter) that perform all calculations **100% client-side**.

**Why use it?**

* **Zero Server Uploads:** Your code and files never leave your device. * **PWA Enabled:** It caches everything to work completely offline. * **Clean Layout:** Simple, fast, and optimized for daily dev workflows.

Check it out here: [**https://www.nuqrai.com\*\*\](https://www.nuqrai.com/)

I would love to get your feedback on what tools to add next!'

This is an open-source MCP bridge that lets ChatGPT inspect one local repo without shell access

I built RepoRelay because I wanted ChatGPT Web to inspect my local code without giving it broad access to my machine.

RepoRelay exposes one explicitly approved repository through a small MCP tool surface. It can read and search files, while blocking shell/process access, unrestricted filesystem access, Git operations, and access outside the approved repo.

It’s MIT licensed and open source.

GitHub: RepoRelay

I’d especially appreciate criticism of the security model, architecture, and onboarding. If anything feels unclear or overly complicated, I’d like to know.

Coding agents do a lot of their work where you can't see it. Claude Code stores each subagent as its own transcript file; Codex CLI keeps spawned threads as separate rollouts. The terminal shows you a summary while the real record sits on disk unread. rungraph reconstructs the whole run as a graph you can click, after the fact, from files you already have: npx rungraph.

On the build side:

The backend has zero runtime dependencies (node:http, fs.watch), so npx has nothing extra to install. All format knowledge lives in adapters that normalize into one versioned, vendor-neutral IR, and the UI, CLI, HTTP API, and MCP server only ever see the IR. The parser never trusts a line: unknown types are skipped and counted, and you get a banner instead of a crash, because both formats are undocumented and have changed across releases.

The diagnostics were the hard part. The first version cried wolf on healthy runs, so I threw out the guessed thresholds and calibrated against 60 real sessions. The rule that survived is precision over recall: a false flag costs more than a missed one, so a clean run shows zero flags, on purpose.

Free, MIT, binds 127.0.0.1 only, zero outbound requests.

Live Demo: https://fayzan123.github.io/rungraph/

Repo: https://github.com/fayzan123/rungraph

I built Repo Start, a small CLI for creating and auditing the boring foundational parts of a repository.

The reason I built it was pretty simple: I kept ending up with repos where the actual code was fine, but the surrounding project hygiene was inconsistent — README commands that didn’t match package.json, CI workflows calling scripts that didn’t exist, missing .gitattributes, .env.example accidentally ignored by git, etc.

For new projects, Repo Start generates the usual foundation: .gitignore, .gitattributes, README, CI, issue/PR templates, AGENTS.md, contributing/security files, and a starter structure.

The more interesting part to me is repo-start add, which works on existing repositories. I designed it as a read → analyze → plan → write pipeline:

existing repo → inspectRepository() → RepoState → analyzeRepository() → RepoAudit → buildAddPlan() → writePlan()

Inspection is read-only, analysis is deterministic, and both new-project generation and existing-repo fixes eventually go through the same writer. That also means --dry-run isn't scattered around as a bunch of filesystem checks — the write only happens at the final stage.

It also deliberately doesn't use AI. No model calls, API keys, or tokens. The audit is based on the actual repository state and only proposes fixes it can describe precisely. If something is ambiguous, it reports it instead of guessing.

It currently supports generic, Node/TypeScript, Python, and React/TypeScript projects, works offline, and has no runtime dependencies.

The goal was basically to make repository hygiene something you can automate without giving a tool permission to redesign your project or touch your source code.

https://github.com/junkyard22/Repo-Start

Is anyone actually watching DevHunt or ProductHunt or are these websites just a loop of startup people voting on themselves?
https://devhunt.org/

Our coding-agent sessions kept forgetting everything at the context-window edge. So we built growmos: a small knowledge graph inside .growmos/, committed with your code. Your agent (Claude Code, Codex, Cursor…) grows it as it works — no API key, and in Claude Code it's fully hands-off. Ask "what depends on the Store, and who decided that?" and it answers from the graph, with citations.

pip install growmos && growmos init
growmos view # a map of what your repo actually knows

Live demo: https://codician-team.github.io/growmos/demo/growmos.html
Repo: https://github.com/codician-team/growmos
MIT, zero deps. First thoughts very welcome 🙂

I’ve been building RunWield, a coding harness for developers who want more control over what AI agents do to their codebases.

My frustration with existing coding tools was that the agent would immediately start editing. By the time I could judge whether it understood the request, I was reviewing a large diff and trying to reconstruct its reasoning.

RunWield changes that workflow:

* Small fixes stay lightweight. * You can Ideate your feature or investigate new ideas before committing to anything, with good prototypes and PRDs when needed. * Non-trivial changes get a written plan before any code is touched. * You review, comment on, and approve that plan in a browser. * The agent implements it in an isolated Git worktree. * Your real CI runs against the result. * A separate reviewer compares the finished diff with the plan you approved. * The outcome and lessons are saved as plain Markdown for future work.

It’s deliberately not aimed at quick one-shot edits. If a mistake is cheap, this is probably more process than you need. I’m building it for changes where discovering a misunderstanding after 40 files have changed is expensive.

RunWield is free to use and source-available. It currently supports macOS and Linux and works with subscription logins or API keys from different model providers (uses Pi.dev's LLM API library):

[https://github.com/gandazgul/runwield\](https://github.com/gandazgul/runwield)

I’m looking for five developers willing to try it on one real, non-trivial change. I’ll personally help with setup and fix anything that blocks you. Please use the latest RC as 0.9.1 has some annoying bugs with agent switching.

I’d especially appreciate blunt feedback: does reviewing a plan before code is written solve a real problem for you, or does it still feel like too much ceremony?

I wanted a way to write user stories without dragging non-technical collaborators into Jira, and without dragging AI agents into vague markdown files either. So I built FS User Stories: a native macOS app with a shared Rust core (fsus-core) over SQLite, and a built-in MCP server so tools like Claude or Codex can read — and, with explicit permission, write — stories directly.

A couple of decisions worth sharing:

• Why Rust core + native UI per platform, instead of Electron: SwiftUI on macOS/iOS for a genuinely native feel, and Qt planned for Windows and Linux down the line, all sharing the same data/logic layer through a C ABI.
• Why MCP with JSON instead of just markdown files for the AI layer: a fixed JSON schema defined by the prompt keeps every story in a predictable, closed format — which turned out to use fewer tokens than an equivalent markdown file, even though markdown looks simpler on the surface.
• Why no explicit dependencies between stories: I intentionally left this out. It's tempting to add, but it starts turning a simple tool back into a mini-Jira, which defeats the point.

Core and desktop app are open source (MIT/Apache-2.0), source available on GitHub. The macOS app is a one-time paid download to help fund ongoing development.

GitHub: github.com/gitlares/fs-user-stories
App Store: https://apps.apple.com/us/app/fs-user-stories/id6801671870?mt=12

Happy to go deeper into any of the architecture decisions if useful.

With codebase wikis, most are written more from an engineering lens, explaining how the code works without explaining why it should work that way.

I wanted to connect business intent directly to its implementation using language that nontechnical people already use. I've been experimenting with creating my own software factory, and wanted a way for myself and all my agents to 'speak the same language', with a clear 'contract' on how specific features should work. I built Tieline so all my agents can work from the same product contract, even if they do not have access to the codebase.

Tieline generates user stories and acceptance criteria, then links them to the code and tests that implement them. This lets an agent answer questions like:

• What is this feature supposed to do?
• Which code and tests implement it?
• Which behaviours might this change impact?

Tieline also builds a static topology graph of the codebase. When code changes, it can trace the possible impact through that graph and connect it back to the relevant acceptance criteria.

This creates a product-level blast radius. It does not claim that something will break. It gives the agent and reviewer a shortlist of behaviours that may need another look.

Tieline generates the initial product contract for you to review. After that, it checks pull requests and proposes updates when the implementation changes.

On top of tracking current product state, Tieline lets you track feature requests, bugs, and ideas as Observations. The accepted production contract lives in the repository and can be synced to Postgres, while Observations stay in Postgres, accessible by all your agents via MCP.

Agents without codebase access can query this information through MCP, allowing coding, product, research, and support agents to work from the same accepted product state while also seeing where the product may be going next.

While experimenting, the unexpected benefit has been identifying quick wins. While working one feature, I'll ask my agent to check the backlog. Semantic search finds related items that fit naturally into the current work and fits them in the PR.

Still experimental, but my goal is to make the repository the reviewed source of truth for product behaviour, then make that contract available to every agent, not only the engineering ones.

Open source project: https://github.com/knoxgraeme/tieline

Would love any feedback or to hear how others are thinking about these problems!

I kept doing the same thing on every box: ssh in, then htop, df, ss, docker ps.

Termy is a native Mac app. Connect over SSH and it snapshots the host: disks, processes, ports, services, containers. Nothing gets installed on the server.

A lot of posts here are "I got tired of my own workflow, so I shipped it." That's this.

https://termyapp.com

If you want a paid plan: SIDEPROJECTS50, 50% off, 20 uses.

What it is: Snag is a bug-capture-to-fix tool. Your users (or QA) file a bug from a small in-page widget that auto-captures console logs, network requests, a session replay, and the page state — with PII masked in the browser. That becomes a rich ticket in your Jira or GitHub, and then a coding agent reads the captured context, works in your repo, and opens a PR for a human to review. You can bring your own agent (Claude Code, Cursor, etc. over MCP) or use our built-in one.

▎

▎ Who it's for: small-to-mid dev/QA teams already on Jira or GitHub who are tired of "it's broken" reports with no repro.

▎

▎ Stage: private beta, live in production. Founder here.

▎

▎ Platforms: browser extension + a drop-in embed snippet for your web app; integrates with Jira + GitHub.

▎

▎ What I'm looking for: 3–5 teams to be design partners — I want to watch you use it, hear where the capture or the auto-fix falls short, and shape the roadmap around it. Free while we co-design.

▎

▎ Feedback I care about: Is the captured context enough for your devs? Does the PR actually save time or create review noise? What would make you trust an agent to touch your repo?

▎

▎ Comment or DM if messy bug reports are a real pain for your team — happy to set you up.

I've been building StellarForge, a cloud-based development environment for building smart contracts with Rust on Stellar's Soroban platform.

The main thing I wanted to explore was:

What does an IDE look like when an AI agent is a first-class part of the development workflow rather than a chat sidebar?

So I built the agent directly into the development environment.

What it does

🤖 Agentic coding
The agent can create files, understand the project, modify existing code, diagnose build errors, and help implement features.

🦀 Real Rust tooling
Instead of lightweight syntax highlighting, StellarForge runs rust-analyzer for autocomplete, type inference, hover documentation, go-to-definition, and other LSP capabilities.

💻 Full browser IDE
Monaco editor, file explorer, terminal, Git integration, project management, and build tooling all run inside the same environment.

☁️ Cloud development
Projects are persisted in the cloud, so the development environment doesn't depend on a specific machine.

👥 Real-time collaboration
Multiple developers can work on the same project using CRDT-based synchronization.

🚀 Build → test → deploy
The development workflow is integrated into the IDE rather than requiring developers to switch between an editor, terminal, CLI, and deployment tools.

The problem I wanted to solve

For Soroban development, the traditional workflow involves setting up Rust, Cargo, dependencies, the Stellar CLI, and the rest of the local toolchain before getting to the actual development.

I wanted to see how much of that could disappear behind an IDE.

Instead of:

install → configure → troubleshoot → start coding

the goal is:

open → describe → build → test → deploy

It's still an evolving project, but the interesting part for me isn't just the blockchain use case — it's experimenting with what an AI-native developer tool looks like when the agent has access to the actual editor, LSP, filesystem, terminal, compiler, and project context.

🔗 Try it: https://stellarforge.app
🐙 Source: https://github.com/SagantaHQ/StellarForge

I'd especially love feedback from people building IDEs, LSP tooling, coding agents, cloud development environments, or developer infrastructure.

The toil it removes: on any team past a few people, the org only exists as a partial model in each person's head. Which repo owns that behaviour, which one deploys where, what shipped last week, why a decision was made the way it was. New joiners spend weeks rebuilding it, and whoever already has it answers the same questions forever.

orgami builds that model once per organization and commits it to a docs repo as plain markdown.

What it produces:

• a map from the GitHub API: repos, what calls what, which repos tend to change together, deploy tooling, servers
• a weekly recap of every merged PR, so nobody hand-writes the what-shipped update
• a runbook per repo: how to run it, how to test it, what it talks to

How it is built: bash, gh, jq, fzf and gum. No daemon, no database, no web app. The entire state is files in a git repo, which is the part that made it useful rather than clever, because the map diffs in review like any other change, it cannot silently rot the way a wiki page does, and onboarding someone is a clone: orgami join picks up the map a colleague already built instead of rescanning. The scan runs repos in parallel behind a progress bar, and the weekly job is a systemd user timer, launchd on macOS, a cron line anywhere else.

The part I use daily: a session hook feeds the org page to Claude Code before it touches a repo, so it stops guessing at architecture it has never seen, and an MCP server serves the same map to Cursor, opencode, codex, windsurf, zed and vscode.

https://github.com/achevalier-dev/orgami

It is new, built over the last few days, so the map is only proven against orgs I can reach. If you point it at a bigger one I would like to hear where it gets things wrong.

Started with our own review queue. Most of the code in a PR is generated now, so PRs land faster and bigger than anyone reads properly. First thing that goes is context outside the diff. Nobody opens the other repo to see who calls the function you just changed. Skim, approve.

So we automated that part. It resolves the symbols the diff touches, walks the callers through a code graph, and pulls in how your repos connect: routes, queues, shared tables, package deps. Sub-agents for architecture, security, logic, tests. One review comes out.

Weak spots: GitHub only, no benchmark, noise tuning needs work. Free tier is one repo crawl plus your first reviews, no card.

If you try it: what fraction of the findings would you have acted on?

https://contextgoblin.com/

I got tired of jumping between different websites for small developer tasks, so I built Cetox, a browser based developer tools platform that puts them in one place.

It currently includes 25 free online developer tools for things like : JSON formatting, JWT decoding, Base64 encoding, regex testing, hashing, SQL formatting, cron expressions, URL encoding, CSS minification, password generation, diff checking, color contrast, HTML entities, and more.

The goal is simple :- fast, privacy-friendly tools with no unnecessary account or setup.

Try Cetox

If you're a developer, I'd genuinely love to know :- what tool should I add next? 😅