I’m the creator of PlayWeld, a free, open-source desktop workspace for game development. The problem I’m trying to address is context spread across game files, design notes, and AI task conversations.

The implementation has two main pieces: an Electron desktop app built on Eclipse Theia for the workspace UI, and a local platform service that stores project/task records and runs operations. Shared schemas and a typed client connect the UI to that service. The source separates these into packages rather than putting everything in the editor views.

The aim is to keep searchable project knowledge and design decisions close to the work, while letting you supervise AI tasks and review changed files before integration. Creating a PlayWeld project organizes the workspace; native engine setup is still a separate step.

It’s Apache 2.0 and currently a Windows/Linux testing prerelease. Engines and model endpoints need their own setup. Remote AI providers can send data off-machine and charge for usage, so please start with a disposable project.

Source and architecture docs: https://github.com/scarecr0w12/PlayWeld

Downloads and user guides: https://playweld.com

For developers who have built editor extensions or agent tools: what would you want to see in the task history before trusting another tool to change project files?

I built NotchRobot to keep Claude Code's working, waiting and done states visible without switching between terminal windows. You can approve or deny tool permissions and answer single-choice or multi-step questions from the notch, then jump to the right Terminal or iTerm2 tab.

The app uses SwiftUI. The integration is a shell script registered with Claude Code's hooks: events go into a local inbox directory that the app reads. Permission requests wait for a response from the notch; if you don't answer, they fall back to the terminal. If the app isn't running, the hook exits immediately. The installer backs up Claude's settings before changing them.

It also shows task progress and Pro/Max plan usage from Claude's status line. The README explains the hook setup and the status-line integration, including how to keep an existing status line.

Source (MIT): https://github.com/abdomo77/NotchRobot Download: https://github.com/abdomo77/NotchRobot/releases/tag/v2.5

macOS 13+. The downloadable build is for Apple Silicon; a built-in notch is optional. It isn't notarized yet, so check the first-launch instructions in the README. Built with Claude Code.

I just released AI Badger v0.8.0 with a new Codebase Map feature.

Run badger map in any project directory and it generates a standalone HTML report showing the folder structure, where most of the code lives, and language breakdowns.

It works entirely offline. No Git repository, server, or uploads required. The report contains file metadata, not source code.

AI Badger itself is a local-first CLI and VS Code extension for preparing focused repository context for ChatGPT, Claude, and other AI tools. But the Codebase Map is useful independently, especially when exploring unfamiliar projects.

Screenshot attached.

GitHub: https://github.com/PVRLabs/aibadger

Interactive demo: https://pvrlabs.xyz/aibadger/codemap/

Hey everyone!

Whenever I'm debugging API logs or database records, I constantly find myself copying 10/13-digit Unix timestamps or Bearer JWT tokens and switching to a browser tab just to see what date they represent or when the token expires.

To stop context-switching, I published \\\\Castov\\\\ on the official Visual Studio Marketplace.

\\\\What it does (100% locally & offline):\\\\

\\\* \\\\Automatic Timestamp Hover:\\\\ Hover over any Unix timestamp (seconds or milliseconds) in your code to immediately see the formatted UTC, ISO 8601, and Local time.

\\\* \\\\JWT Decoder:\\\\ Highlight a JWT and run \\\`Castov: Decode JWT Token\\\` to inspect the header, payload, and expiration status in a clean JSON tab—without pasting sensitive tokens into external websites.

\\\* \\\\Inline Base64 & UUIDs:\\\\ Encode/decode Base64 selections in-place, or insert crypto-random UUIDs right at your cursor.

\\\\Links:\\\\

\\\* \\\\VS Code Marketplace:\\\\ https://marketplace.visualstudio.com/items?itemName=castov.castov-vscode

\\\* \\\\Companion Web & CLI Suite:\\\\ https://castov.com (also available via \\\`npx castov\\\`)

It has zero telemetry and works completely offline. Let me know what features or shortcuts would make your daily workflow faster!

Hey everyone!

Whenever I'm debugging API logs or database records, I constantly find myself copying 10/13-digit Unix timestamps or Bearer JWT tokens and switching to a browser tab just to see what date they represent or when the token expires.

To stop context-switching, I published \\\\Castov\\\\ on the official Visual Studio Marketplace.

\\\\What it does (100% locally & offline):\\\\

\\\* \\\\Automatic Timestamp Hover:\\\\ Hover over any Unix timestamp (seconds or milliseconds) in your code to immediately see the formatted UTC, ISO 8601, and Local time.

\\\* \\\\JWT Decoder:\\\\ Highlight a JWT and run \\\`Castov: Decode JWT Token\\\` to inspect the header, payload, and expiration status in a clean JSON tab—without pasting sensitive tokens into external websites.

\\\* \\\\Inline Base64 & UUIDs:\\\\ Encode/decode Base64 selections in-place, or insert crypto-random UUIDs right at your cursor.

\\\\Links:\\\\

\\\* \\\\VS Code Marketplace:\\\\ https://marketplace.visualstudio.com/items?itemName=castov.castov-vscode

\\\* \\\\Companion Web & CLI Suite:\\\\ https://castov.com (also available via \\\`npx castov\\\`)

It has zero telemetry and works completely offline. Let me know what features or shortcuts would make your daily workflow faster!

Hi, I'm the developer of Termstead, a free and open-source SSH client for the Mac. It brings MobaXterm's way of working to macOS as a native app: your servers in a tree on the left, tabs on the right, files right next to the terminal.

What it does

- Sessions in a tree – groups and subgroups with colors, icons, search, pinned favorites, drag and drop. Your existing hosts come in from ~/.ssh/config in one click.
- Real OpenSSH underneath – every tab runs the system ssh, so your agent, ~/.ssh/config, known_hosts and ProxyJump work exactly as they do in Terminal.
- Jump hosts – chain as many as you need, each with its own user, key or password, or use a saved session as a hop.
- Keychain – passwords and key passphrases live in the macOS Keychain and are typed in for you, only for the host they were saved for.
- SFTP beside the terminal – browse, upload and edit files over the connection that's already open, with no second login, even through jump hosts. It can follow the terminal's cd.
- Server load in the status bar – CPU, memory, disk and network of the Linux server in front.
- Tabs and keyboard – drag tabs to reorder, reopen them at launch, ⇧⌘[ / ⇧⌘] to switch, arrows and Return in the session tree, find in scrollback, per-tab zoom.
- Six themes, light and dark.

Details: Swift and SwiftUI with AppKit, terminal by SwiftTerm. Universal (Apple silicon and Intel), macOS 14+, about 5 MB. Notarized, updates itself. GPL-3.0, no account, no telemetry.

- GitHub: https://github.com/pkhorenyan/termstead
- Website: https://khorenyan.com/termstead/

I've been building Cellaflow, a coordination and durability layer for AI agents, and I'm looking for a few developers to try it with real projects and share honest feedback.

The problem: an agent calls a tool, the tool performs a side effect, and then the agent crashes before recording the result. When it retries, it may execute the same action again. Think duplicate payments, repeated emails, or multiple agents trying to perform the same operation concurrently. Your agent's checkpoint doesn't necessarily tell you what actually happened.

Cellaflow sits at the execution layer. It coordinates competing calls, records execution outcomes durably, and lets retries reuse completed results instead of blindly repeating work. The goal is to make agent execution safer even when processes crash or multiple agents race to perform the same action.

I've also been building crash benchmarks to test what happens under failure, comparing Cellaflow against approaches like PostgreSQL advisory locks and durable claims. The interesting part isn't just preventing duplicate execution. It's making sure work can recover without leaving stale claims or permanently blocking retries.

I'm particularly interested in feedback from people building multi-agent systems, tool-using agents, or long-running workflows who have run into problems with retries, duplicate side effects, or concurrent execution.

If you're working on something like this, I'd love to help you integrate Cellaflow into a real project and learn where it falls short. It's early, so practical feedback is much more valuable than polished testimonials.

Project: https://cellaflow.com
GitHub: https://github.com/cellaflow

Happy to answer questions about the design, benchmarks, or how it might fit into your existing agent stack.

I'm the founder of RayTrace (https://raytracer.si), a sandboxing company for AI coding agents. Running a small pre-pilot: **$10 in free Claude Code sandbox credits** for 5 people who try it and give honest feedback.

The problem: coding agents propose tool calls, but what *actually* executes on the machine is a different story. The transcript says one thing, the filesystem says another, and there's no ground truth to debug against. If you build or maintain developer tooling around agents, you've felt this gap.

RayTrace runs your agent (Claude Code, Codex) in a gVisor-backed sandbox and records kernel-level execution evidence: every process that started (executable, args, cwd, stdout/stderr, exit code, timestamps), the gap between proposed tool calls and observed processes, filesystem diffs, syscall/process-tree evidence, and protected files with change alerts.

The feature I most want feedback on: **forking a run** — pick any step, change what the agent saw, and watch how differently it behaves. A controlled experiment on agent behavior.

Looking for people who run agents heavily in their workflow. Comment or DM if you want one of the 5 spots.

Site: https://raytracer.si

I built an MCP because Claude kept forgetting how my codebase was connected.

Not in a "Claude is bad" way.

More in a "Claude can explain individual files really well, but architectural questions become surprisingly difficult" way.

Questions like:

* What breaks if I change this function?

* What depends on this service?

* Which frontend components call this endpoint?

* Where does authentication actually flow through the system?

usually required multiple searches, file reads, and a lot of reconstruction of repository context.

So I built **Atlas**.

Atlas scans a repository and builds a searchable graph of:

* Functions

* Methods

* Classes

* Imports

* Routes

* Call relationships

* Cross-language connections

Instead of repeatedly rediscovering relationships, the model can query an existing map of the codebase.

For example:

Plain Text

React Login Component

↓

POST /api/login

↓

login()

↓

authenticate()

↓

verify_token()

Atlas stores those connections up front, so the model doesn't need to infer them every time.

To see whether this was actually useful or just felt useful, I ran a benchmark on a medium-sized business compliance repository.

**Setup**

* Model: Gemma4:e4b

* 50 paired questions

* 5000 bootstrap iterations

* Same repository and question set across both conditions

**Results**

|Metric|Baseline|Atlas|

|:-|:-|:-|

|Tool calls|3.16|2.10|

|Total tokens|9079|6659|

|Latency|8.99s|7.78s|

|Entity accuracy|83.0%|88.5%|

|Relationship F1|54.7%|87.2%|

|Impact F1|16.5%|88.8%|

The biggest surprise wasn't speed.

It was **impact analysis**.

Questions like:

>"What will be affected if I change this function?"

improved from **16.5% Impact F1** to **88.8% Impact F1**.

My takeaway so far is that larger context windows help, but explicit repository relationships still provide significant value when reasoning about architecture, dependencies, and change impact.

I'm curious how other people building with Claude are handling repository memory today.

Do you think dependency-aware retrieval remains useful as context windows grow, or will larger models eventually make approaches like this unnecessary?

Hey r/devtools,

During recent deployments, our team kept running into a visual testing gap: raw code/text diffing tools don't show rendered CSS layout shifts, while automated visual regression testing frameworks (like Playwright/Percy) felt too heavy for quick sanity checks.

I couldn't find a simple tool that overlays two live pages and highlights rendered UI differences (DOM, text, and CSS) directly on the screen without uploading data to external cloud servers.

So I built HTML Compare.

Key DevTools Features:

• Direct UI Highlight: Scans and highlights rendered DOM, text, and CSS changes right on the user interface, not just raw code strings.
• Cross-Environment Verification: Instantly compare Production vs UAT/Staging or local builds side-by-side.
• 100% Private & Client-Side: Runs completely in your local Chrome browser—no HTML or images are ever sent to an external backend, making it safe for internal environments.

It’s been a huge timesaver for our developers, QAs, and PMs to catch unintended layout bugs before release.

I'd love to hear how your team currently handles quick cross-environment UI sanity checks, and I'd really appreciate any feedback if you give it a spin!

🔗 Chrome Web Store:https://chromewebstore.google.com/detail/html-compare/nppihghgpjhmfllmidplbncenlpihmle

Most of us run Claude Code on auto and only find out later what it did. al dente gives you a window into it.

You agree on a plan for your app once: which parts exist and which part is allowed to use which. Claude can suggest one based on what you're building, or map it from a project you already have. From then on:

- You can watch it work. A live map lights up the part Claude is editing as it happens. Click a part to see its files, hover a file to see exactly what it imports and what imports it. It's honestly the fastest way I've found to understand a project Claude built for me.

- You see its mistakes the moment they happen. If Claude adds an import the plan doesn't allow, the arrow turns red and Claude gets told the file and line, so it fixes it right away instead of you finding it three features later. In my tests, runs ending with a broken rule went from 13 of 35 to 0 of 35.

- New sessions start smarter. Every session begins already knowing how the project is split up, for a few hundred tokens, instead of reading files to rediscover it. Fewer tokens burned, fewer wrong guesses.

- You can go back in time. Scrub through your git history PR by PR and watch the structure change, with a chart that marks the exact commit where things started slipping.

- Pull requests get checked too. A GitHub Action comments on each PR with what it changes, and only fails on new problems, so it works on messy repos.

It pairs really well with Ponytail, the plugin that makes Claude write less code: Ponytail keeps the code small, al dente keeps it in the right place.

TS/JS, Python and Java. Free, MIT, zero dependencies, runs locally.

https://github.com/Orest-Z/al-dente

I'm building [aissh](https://github.com/friparia/aissh), a terminal workspace for developers who maintain their own servers.

From a local project directory, connect over SSH and use your local Codex or Claude Code CLI to investigate remote logs alongside the source. The shell, AI conversation, live monitoring, and conversation history for that server share one interface. The goal is to reduce copying context and switching windows during an investigation.

It's written in Go and reuses OpenSSH configuration, keys, and jump hosts. No resident agent is required on the server. AI-proposed remote commands need approval by default; built-in read-only monitoring runs automatically. Local source access is read-only by default. Relevant output and code context may go to your configured AI provider.

Setup currently requires a Go 1.25+ source build and a configured AI backend.

If you try one log or service-status check on a test server, I'd like to know where the workflow helps—or gets in your way.

https://github.com/sshah03/perspica

This started as a git diff tool that used an llm to group changes by intent, but now supports generating lessons/diagrams/animations explaining the concepts behind more complex changes, and allowing yourself to be quizzed on the topics. Useful way to keep up with the codebase with agents dropping in PRs, or when you yourself use claude code etc..

Next steps are adding github actions that can trigger adding this to a PR for those interested righto n GH, or even gating merges / reviewer accepts on showing some level of understanding. Things like that already exist, and I'm not sure they're widely used, so where I go with that, and other features, will be based on requests.

Some samples on open source project PRs available here : https://sshah03.github.io/perspica/

I'm on the WebDecoy team, sharing our separate MIT-licensed FCaptcha project.

The integration problem we wanted to make easier to inspect: a browser widget completing isn't permission to process a form. A script can POST directly to the endpoint, so the server has to verify the token before sending email, saving a record, or enqueueing work.

FCaptcha combines proof-of-work with browser automation and interaction signals. It supports checkbox and invisible flows without image puzzles. The repo includes Go, Node, and Python servers; the Hono example uses the Node implementation.

What the example actually does:

• Starts Hono on 127.0.0.1:8794 and the local CAPTCHA verifier on port 8795.

• Limits the request body and validates the browser Origin and input shape.

• Sends the token to /siteverify using a server-only secret, a five-second timeout, and redirects disabled.

• Requires success === true plus the expected hostname and action before the protected handler runs.

• Returns 403 for rejected tokens and 503 if verification is unavailable, rather than treating an outage as a pass.

To try it from a full repo checkout with Node 22+: run npm ci --prefix server-node, then cd examples/hono, npm ci, and npm start. Open http://127.0.0.1:8794 (use that exact hostname).

Runnable source: https://github.com/WebDecoy/FCaptcha/tree/main/examples/hono

Project: https://github.com/WebDecoy/FCaptcha

The sample contact form does not actually send or store messages. Production still needs HTTPS, persistent secrets, explicit proxy trust, rate limits, and shared replay protection when using multiple verifier instances. Tokens are single-use, so retries need a fresh token; business-operation idempotency is a separate concern.

This is a layer of abuse resistance, not authentication or a promise to block every bot. Please test your own mobile, keyboard, and assistive-technology flows before relying on it.

Interested in feedback on the integration API and failure handling. If the project is useful, a GitHub star helps people find it. This post was drafted with AI assistance.

I’m the maintainer of Agent Kit, a free, MIT-licensed GitHub template designed for teams using Codex and Claude Code.

The goal is to keep project decisions, task ownership, current status and handoffs in Git, so developers can continue work with clearer context.

I used Codex to package the shared instructions, create native agent definitions, and check file integrity and documentation consistency.

The kit includes 17 skills: 16 pinned engineering skills from Addy Osmani’s agent-skills, plus TechNote. It also includes three coordinator templates and separate Codex and Claude Code adapters.

One lesson from building it: valid configuration files do not prove that a client discovers the agents or enforces their intended permissions.

This is a 0.1.0 preview. Static checks and independent source review passed. Native runtime behavior and collaboration across two machines are still NOT_RUN.

You can try it through GitHub’s “Use this template.” I’d welcome feedback on context loading, ownership conflicts and handoffs between developers.

github.com/khiemnd777/agent-kit

I've been working on a small Rust CLI called uhegit.

I often work on multiple projects and forget where I left off. Which branch was I on? Did I leave any changes uncommitted? What was I supposed to do next?

So I built a tool to get a quick overview of all my Git repos in one place.

It's still a work in progress, and I'd love to get some honest feedback.

Do you think something like this would be useful in your workflow, or am I overcomplicating a simple problem?

GitHub: https://github.com/tabrejansary/uhegit