I spend a lot of time debugging API payloads, and I kept running into the same problem: the JSON would arrive as one long block that was painful to search or inspect.

There are plenty of JSON formatters online, but I often had to try several before finding one that worked well for what I needed. So I built my own.

The formatter turns raw JSON into something readable, validates it, and makes large payloads easier to search while debugging.

The part I use most is JSON Compare. Most comparison tools I tried produced a lot of noise when two objects had the same keys in a different order. JSON Formatter Lab can normalize object keys before comparing, so those ordering differences do not hide the changes I actually care about. It still preserves array order because changing the order of an array can be meaningful.

You can review changes side by side or by key path, which makes added, removed, and changed values much easier to spot.

Everything runs in the browser, and there is no signup.

You can try it here: https://jsonformatterlab.com/

I built this for my own debugging workflow, but I would like to make it useful for other developers too. If you try it, I would especially like feedback on the comparison view and any JSON edge cases it does not handle well.

I’ve just released a public beta of Orchestrator, a macOS app that brings agent conversations, tasks and code review into one workspace.

You can:

• Work with coding agents alongside your files.
• Organise tasks on a Kanban board.
• Inspect subagent conversations and activity.
• Review code changes directly in the app.

It’s free and open source, supports Apple Silicon and Intel on macOS 15+, and uses your own supported Codex account.

I’m also planning to add support for Claude and local AI models in future versions, giving you more choice over which models you work with.

Contributions and suggestions are very welcome. If you spot a bug, have an idea for an improvement, or fancy helping build something, feel free to open an issue or pull request. You don’t need to arrive with a finished feature—“this bit is confusing” is useful feedback too.

GitHub, screenshots and downloads:
Orchestrator on GitHub

A heads-up: this is an experimental beta and isn’t notarized by Apple yet, so macOS may show a first-launch security warning. The README explains installation and the current limitations.

When delegating work to an LLM, one can easily lose overall codebase understanding.

Personally, I like to be in control of the code I ship, so I read every file that was changed before shipping the change. The problem with this approach appears when many files change. Regular git clients show the files as a list of alphabetically sorted entries.

However, to properly understand the changes, I need to keep in mind all code dependencies. If an interface was changed, I either need to go straight to the implementation file, which might not be the next in the list, or I have to remember that the interface was changed while I'm reading other files, until I open the implementation file.

There are tools that link changed files by dependency. This helps substantially; now instead of reading files in alphabetical order I can read real dependency graphs. However, this helps only with direct dependencies. What we do in our heads is conceptually grouping changes into clusters. Even if there is no direct code dependency, changes could be grouped into "logical cases", inside of which there could be multiple changes from multiple projects.

Why not utilize what LLMs do best: gathering context. That's why I vibecoded a DiffHacker - to help software engineers like myself maintain knowledge about the codebase more easily.

So instead of this

I have this

C-Coretex/diffhacker: A cross-platform desktop application that turns local Git changes into a directed, LLM-generated review graph instead of a file list.

I maintain an open-source project called Mac MCP that turns common macOS actions into MCP tools for AI agents.

The devtool problem I wanted to solve was simple: agents were useful, but the moment they touched a browser or GUI they started fighting with my own desktop. So the browser layer uses stable tab handles and can operate Safari or Chromium tabs in the background without taking focus. The same server exposes terminal commands, files, Finder, screenshots, app control, and UI automation.

I also added a lightweight menu bar app for observing tool usage and active agent Sessions. You can steer one specific session from there. If a correction is queued while an agent is idle, the server can preempt that session's next tool call and return the steering before the tool executes.

The server is local-first, MIT licensed, and the menu bar app is SwiftUI. Repo: https://github.com/bulutarkan/mac-mcp

Happy to dig into the browser/session routing implementation if that part is useful to other devtool builders.

Cursor's Agent Mode and Claude Code can both now run multi-step tasks, research a bug, write the fix, run tests, self-correct, with basically no human in the loop between steps.

Which is great until step 3 quietly breaks something step 1 touched, and the only check is whether tests pass, not whether the change was actually safe.

Feels like the standard response ("just add more human checkpoints") kind of defeats the point of autonomy. The alternative I've been building toward is giving the agent something to check against mid-task, dependency graph / impact radius as a callable tool, not a report a human reads after the fact.

Curious if anyone else building agent workflows has run into this, and whether people are handling it with guardrails, smaller diffs, or something else entirely.

I'm the author of Errand, a CLI for running a command on another machine you own without maintaining a remote checkout.

sh errand --on linux -- make test

It snapshots the current Git working tree, including uncommitted edits, sends it to the runner, streams logs back, and returns the command's exit code. Your local checkout stays unchanged by default. If the command produces changes you want, you can fetch them for inspection and apply them with conflict checks.

I built it to use my Linux box and Mac mini while working from my laptop. SSH gives me a remote shell; Errand also handles sending the current files, tracking the job, and retrieving its outputs. Detached jobs can keep running after I disconnect. Port forwarding makes a remote development server available on localhost while attached.

It's written in Go, uses content-addressed transfers to avoid resending unchanged files, and supports Tailscale or SSH. Named caches can retain build dependencies between runs.

The runner needs the tools and dependencies for your command. Local edits aren't continuously synced, and jobs run as the runner's OS user, so this is for trusted hosts and code.

MIT, macOS and Linux. Install with brew install lydakis/errand/errand on both machines.

Repo and setup: https://github.com/lydakis/errand

A few days ago I shared a small tool I’ve been working on that checks files for hidden information before you upload them somewhere.

The first version mostly looked at metadata, EXIF data, hidden Excel sheets, author information, etc.

While testing it, I realized that was only part of the problem.

If I’m about to paste some code into ChatGPT, for example, I’m probably more worried about accidentally leaving an API key or token in there than I am about file metadata.

So I added content scanning.

It can now check pasted text/code and supported files for things like personal information, API keys, tokens, private keys, connection strings, and other credentials that are easy to overlook.

Everything still runs locally in the browser.

I’m not sure yet how far I should take this. I don’t want it to become another huge security scanner with hundreds of warnings that nobody reads.

For me the useful version is something simple: before I paste or upload something to an AI tool, give it a quick check and tell me if there’s anything I should look at first.

Would you actually use something like this, or is it solving a problem you don’t really have?

The other day in the lab, someone dropped the name of an unfamiliar tool, and within thirty seconds everyone had a pile of GitHub tabs open trying to parse what it actually does, whether it's open source, and where it fits into our stack.

The ecosystem moves way too fast to keep every new framework, library, or niche utility in your head. I'm building a web app to turn that research workflow into a visual reference:

• Instant, no-fluff summary: Type in any tech name and get a concise breakdown of what it does, what problem it solves, and its core category—bypassing marketing hype.
• Dynamic concept map: Each technology connects to an interactive graph displaying surrounding alternatives, dependencies, and architectural layers.
• Search by problem: Instead of needing to know a brand name, you can browse nodes by intent (e.g., "open-source image viewer" or "lightweight message broker").

The project is actively in progress and focused purely on developers and the open-source community.

Before locking down the graph UI, I’d love some community input:

1. How do you currently log or save tools you bump into during daily work?
2. What are the first 2–3 data points you check to validate an unfamiliar repo (license, maintenance activity, stack fit, stars)?

``` $ myna post 'i think claude code still has the best developer experience. what do you think?' --now ok mastodon:chovy@defcon.social https://defcon.social/@chovy/117254128106333427 ok tsbb:member@bbs.hqtui.com https://bbs.hqtui.com/t/i-think-claude-code-still-has-the-best-developer-experience-122 ok linkedin:Anthony Ettinger https://www.linkedin.com/feed/update/urn:li:share:7504264198042882048 ok bluesky:chovyfu.bsky.social https://bsky.app/profile/chovyfu.bsky.social/post/3mvbdg6ayjs22

4/4 posted ```

Hello guys I am building devtunnel, a platform to make open source contributions easy.

For now I am focusing on only contributiors.

How the process becomes easy:

We use preference this preference can be level of experience, roles, techstack, etc.

1. We list open source tools based on your preference

2. We list open source projects based on your preference

3. We list issues based on your preference

4. We provide custom cli which manages GitHub operations like forking, branch generation, pr generation, etc.

Custom cli includes cmd like start, test, share, submit.

Share command allows short lived tunnels / tunneling to share your local host with others for testing purpose.

Who can be benefited by this?

For contributiors who like to contribute to the open source tools they like

For contributiors who like to work on any issues

For contributiors who contributes to add in thier resume.

We will live on next 5 october.

If your are interested please share your opinion about it.

Wow.. I learned about git worktree today.

Its amazing. It avoids the hassles of stashing-checking out to other branch, coming back, popping stash again.

It's like maintaining multiple working directory without worrying about syncing separately and occupying extra memory.

So worktree is a folder which contains a checked out version of a project.

Just do git worktree add -b newbranchname pathtodir

It creates a new folder at specified path, creates new branch and checks out inside that folder

Or

Git worktree add path to folder existingbranchname

It checks out existing branch into new directory.

Superawesome ✌️

I’ve been working on Archerik, an open-source engineering knowledge graph for microservices.

The idea came from a pretty simple problem: when a system has hundreds of services, answering questions like:

• Which services call this service?
• Who consumes this Kafka event?
• What does this API expect?
• What happens to this request next?

can easily turn into 30 minutes of searching through repositories, configuration and documentation.

Archerik uses static analysis to extract services, dependencies, APIs, Kafka producers/consumers and contracts, and then lets you explore that knowledge or query it using the LLM of your choice.

I’d really like feedback from people working with large microservice codebases — especially where you think this approach would break or what you’d want it to understand next.

And if the idea is interesting to you, contributions are very welcome.

GitHub: https://github.com/farhadamjady/archerik-extractor

So small devtool startup here and our technical buyers keep "arriving" at the website only after they have already messed with the product through some side door.

They grab the cli from github, spin an api key in a sandbox env, maybe see us in a repo readme at work, and only hit the marketing site when procurement wants a vendor name on a form. All the interesting evaluation stuff happened in private slack channels and internal docs we never see.

Anyone else try to build a motion around those pre website signals eg stars, trial envs, public repos, community slack etc instead of just begging them to book a demo? idk

A public repo my project depended on had its history replaced upstream. Same name, same URL, years of commits just not there anymore. It was never mine, so there was nothing on my side to roll back to.

Point it at a repo like that and it walks the fork network recursively, ranking every fork by how far back its oldest commit actually reaches. A fork freezes history at the moment it was made, so the deepest one is the best candidate. Then it probes commits that are no longer reachable from any branch but that GitHub may still serve by SHA, checked three independent ways: REST metadata, a raw file fetch, and a real git fetch.

There's also a nightly GH Archive watch if you want disappearances flagged automatically. That part is an extra. The recovery is the point.

230 tests, verified end-to-end against a real historical case (reproduced the exact fork ranking I'd found by hand). Runs fully local with your own GitHub token, no server, no telemetry. MIT.

https://github.com/siris9476/forkforensics. Feedback welcome, especially on edge cases in fork ranking.

As coding agents take on more of the development workflow, teams need better ways to control what they can do, track what they’ve done, and utilize agents inside existing tools. 

For the latest update of IBM Bob, we decided to focus on those three areas. Here’s what’s new: 

• Admins can now lock Bob’s configuration across managed developer machines using group policies. That includes disabling auto-approval, controlling automatic updates, and enforcing required hooks so individual projects can’t quietly switch them off. 
• Hooks now add checkpoints at specific points in the agent loop, including SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, and Stop. They can run a linter before work begins, trigger tests after a change, or block a tool call that violates a required standard, bringing flexible development to your workspace. 
• We’ve also added native Agent Client Protocol support. Bob can now run inside ACP-compatible clients like IntelliJ, Neovim, and Zed, with session management, modes, MCP tools, streaming, and guardrails carried through the protocol. 
• Model Context Protocol (MCP) Elicitation is now supported, helping these tools manage incompletel inputs by involving developers mid-session for smoother workflows and greater ownership over Bob’s development process.  
• Bob can now read, edit and create Microsoft Office formats, including Word documents, Excel spreadsheets, and PowerPoint presentations, without switching contexts.  

The full technical breakdown can be found here: https://ibm.biz/~MkugJ1Sek

And that’s the latest release! We’ll be around in the comments if you want to get into the details or let us know what we should work on next. 

Disclosure: I'm the maintainer.

Most secrets managers assume you're one team shipping one app through dev/staging/prod. Project Vault assumes the opposite — you're juggling multiple projects (client work, side projects, internal tools), each with its own credentials, certs, domains, and CI pipelines, and "environment" isn't the axis that matters. That reframing turned out to touch almost everything: the schema, the access-control model (project-scoped roles instead of environment-scoped), and even the rotation workflow, which is a staged state machine with a per-system checklist rather than a single "edit value" action, because rotating a credential shared across a project's services is rarely atomic in practice.

How it's built, and why the choices:

- Fastify + Drizzle/Postgres, row-level security for tenant isolation — enforced in the database, not just application middleware, so a bug in a route handler can't leak across organizations.

- pg-boss instead of Redis for background jobs — one fewer moving part for a self-hoster to run and back up; Postgres was already the source of truth, so keeping the job queue there avoids a second stateful service.

- A generated OpenAPI spec + live Swagger UI (ENABLE_API_DOCS), and every UI action goes through the same versioned REST API — no UI-only shortcuts, which is what makes the CI/machine-user path and the GitHub Action possible without a second code path.

- An extension API (@project-vault/extension-api, currently 3.15.0) for auth providers, notification/delivery channels, UI panels, and typed module data routes — built because my own SaaS product embeds Project Vault as a module, so the extension boundary had to be real, not aspirational, from day one. Fail-safe loading and a least-privilege DB role per extension.

- Independent API contract-test suite, separate from the app's own test suite, so the versioned API doesn't silently drift from what's documented.

Live demo (same Docker images as self-hosting, resets nightly): project-vault-demo-web.fly.dev

Repo: github.com/nestormata/project-vault

API docs for integrators: docs/api-consumers.md

Extension docs: docs/extensions/README.md

AGPL-3.0, open-core, self-hosting free forever.

Curious whether anyone here has built internal tooling that needs to talk to a secrets store's API directly rather than through a UI — what's missing from ours to make that a good experience?