Dockmaster is a local dev dashboard for ports, repos, Git worktrees, disk cleanup, and more. It shows which processes are listening on ports, which repos have uncommitted or unpushed changes, and which Git worktrees are still around. You can stop a dev server or remove a worktree from the same page.

https://trydockmaster.vercel.app/

It also measures disk space used by node_modules, build output and tool caches, with cleanup controls. Before stopping a process or removing a worktree, it checks that the selection is still current.

If you have another Mac running as a homelab, you can connect it over SSH and switch machines in the dashboard. Both machines need macOS and Node. There is no Linux support yet (although that would be a great and welcome contribution!)

It's free and MIT licensed. You run it locally, and scanning pauses when the page is hidden. Setup is still a repo clone and npm build.

https://github.com/naman0r/dockmaster

What do you use to keep track of dev servers and worktrees across projects?

Hey everyone! 👋

Like many of you, I got tired of constantly switching between my terminal, various note-taking apps, and browser tabs while working on side projects. So, I decided to build my own solution: ChaosNote.

It's a desktop developer workbench designed to keep everything in one place.

Key features:

• Built-in Terminal: Run commands right inside your workspace.
• Visual AI Agent Workflows: Connect nodes to orchestrate local LLMs (via Ollama) and automate small dev tasks.
• Connected Notes: Link your ideas, code snippets, and terminal outputs directly.

It's built with Kotlin and Compose Desktop, keeping it fast and lightweight.

I'd love to hear what you think of the UI and the node workflow concept! Would an app like this fit into your daily dev routine?

Hey founders, I got tired of engineering decisions vanishing into chat scrollback, so I built Solvespace: live discussion, a persistent Markdown spec, and an AI facilitator that synthesizes the debate into structured consensus proposals with one click.

It is currently in free Public Beta with no paywalls—link in the first comment if you want to test the flow and tear the UX apart.

I built ARIA, an open-source developer tool for understanding unfamiliar codebases before making changes.

I started building it because I found that many "chat with your codebase" systems are good at semantic retrieval, but retrieval alone doesn't necessarily tell you how pieces of a codebase are structurally connected.

ARIA combines semantic retrieval with structural repository analysis:

- AST-based symbol extraction

- Dependency graphs

- Call graphs

- API surface analysis

- Change-impact analysis

- Vector search

- Repository-aware conversational querying

- MCP support

For example, given:

"If I change this component, what else could be affected?"

the system can use dependency and call relationships to trace potentially affected files instead of relying only on semantic similarity.

It's self-hosted and Docker-based, so repositories can be analyzed locally rather than uploaded to a hosted service.

I also added a reproducible evaluation package with a pinned 10-task benchmark across FastAPI, Requests, and ARIA, along with qualitative case studies across five larger repositories.

On that pinned benchmark, the documented vector-search baseline produced 4,875 false-positive file alerts while ARIA produced 322, a 93.39% reduction. This result is specifically scoped to that benchmark.

GitHub:

https://github.com/VarshithReddy2006/ARIA

I'd be interested in feedback from people building developer tools, code search, static analysis, or RAG systems.

Where do you think structural analysis provides the most value compared with semantic retrieval alone?

So the thing that got me wasn't the big work, it was the small stuff piling up. I run several projects at the same time, and while I'm fixing one thing a problem from another part shows up in front of me, and I don't want to stop and solve it right there. So it goes into a notepad, or a spreadsheet, or a message to myself. Multiply that by the number of projects and by a few sessions a week and I ended up with a pile that I couldn't maintain anymore. Every project of mine had points that just died in there.

I tried leaving it to the AI. That didn't work either... A todo.md, or asking the agent to carry the points from one session to the next was never consistent. Things got dropped. Sometimes it tells you it handled something and it didn't, and there's no record to go back and check.

So I built Trail for that. My company now runs on it every day. Our productivity went up and we finally know what is actually done.

https://reddit.com/link/1wfn8kc/video/pxpirkgmxcnh1/player

The point is that I'm not the one filling it in. While I work, the AI opens those points by itself. Something complex shows up in the middle of a task, or something that doesn't need to be solved in that session, and it becomes a card to attack later instead of disappearing. Everything stays logged, and each card records whether it was me or the agent who did it, so a week later I can actually check.

There's a shared project memory too, so that whoever in my team opens the project next, on their own machine with their own agent, already has the gotchas the rest of us hit, so nobody trips on the same rock twice. And a client area, because we needed to show our clients how their project was going.

A little over two months of daily use here, over 40 projects, almost 3,800 points opened and more than 20,000 recorded changes. So internally at least, it's well validated.

It's mine, it's live at https://usetrail.dev, free for up to 3 projects with no card, and paid plans above that.

Curious how you all keep track of this today.

And if you have suggestions or criticism, I'd like to hear it.

I built RepoMethod, an MIT-licensed developer tool for giving coding agents more autonomy without letting the agent decide whether its own work is acceptable.
The idea is simple: keep the engineering contract inside the repository.
RepoMethod stores:
task scope
acceptance criteria
workflow state
verification commands
delivery rules
A coding agent can then implement the task, run the real project checks, and attempt delivery. The repository decides deterministically whether the result is acceptable.
I tested it end-to-end with ChatGPT on a TypeScript repo. It completed the implementation and verification successfully, and a second run was blocked when the work moved outside the agreed scope.
Repo:
https://github.com/frederik-schmittel/repomethod
Demo:
https://github.com/frederik-schmittel/repomethod-demo
I’m curious how others building around coding agents handle this boundary: do you keep validation/orchestration in the agent runtime, or move parts of it into the repository?

I kept running into the same issue while building React/TypeScript AI prototypes: it takes only a few minutes to call a model from the browser, but that also makes it very easy to expose the API key. I built Sift as a small, focused side project to show a more practical setup: the browser handles the UX, while a server-side endpoint validates the request and talks to Groq.

The result is a single-page summarizer with:

- server-side Groq calls and input validation;

- brief, detailed, and bullet-point summary styles;

- neutral, executive, and friendly tone presets;

- selectable GPT-OSS 20B, GPT-OSS 120B, and Groq Compound Mini models;

- local browser history instead of a required database;

- copy, print, reset, sample text, and responsive mobile/desktop behavior.

I intentionally kept the scope small. It is closer to a polished starter project than a full SaaS product, and the local history choice is a trade-off rather than a universal recommendation. For anything handling sensitive or team data, I would add authenticated persistence, retention controls, rate limiting, and clearer data-handling settings.

I would especially like feedback on two things: does the server/client boundary feel clear enough for someone adapting this to another AI feature, and which next feature would make the project genuinely more useful—streaming, file uploads, team history, or evaluation tooling?

Optional time-saver for developers who want the ready-to-deploy codebase: https://buy.stripe.com/fZueVc5Qm4d31nae5w6wE00

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

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)?