The interesting part wasn't the stack. It was realizing how much the interpretation layer matters when you're building for a specific region. Wind descriptions, "feels like" calculations, condition summaries, all tuned for temperate climates by default. I've been reworking them for the Eastern Caribbean audience.
Wrote about what I learned: https://hydn.dev/82-degrees-feels-like/
Every time I wanted to start something new I'd spend the first hour writing CMakeLists.txt, figuring out find_package, copying boilerplate from my last project, and googling why my library isn't linking. By the time the project was actually set up I'd lost all momentum.
So, I built Craft - a lightweight build and workflow tool for C and C++. Instead of writing CMake, your project configuration goes in a simple craft.toml:
[project]
name = "my_app"
version = "0.1.0"
language = "c"
c_standard = 99
[build]
type = "executable"
craft add --git https://github.com/raysan5/raylib --links raylib
craft add --path ../my_library
craft add sfml
Other Craft features: craft init - adopt an existing C/C++ project into Craft or initialize an empty directory. craft template - save any project structure as a template to be initialized later. craft gen - generate header and source files with starter boilerplate code. craft upgrade - keeps itself up to date.
CMakeLists.extra.cmake for anything that Craft does not yet handle.
Cross platform - macOS, Linux, Windows.
It is still early (I just got it to v1.0.0) but I am excited to be able to share it and keep improving it.
Would love feedback. Please also feel free to make pull requests if you want to help with development!
Technically, the way this works is you view your site in dev mode and start editing it. In your agent, you can run /studio which then polls (or uses Claude Channels) an MCP server. Changes are streamed as JSON via the MCP, along with some viewport and URL information, and the skill has some instructions on how best to implement them.
It contains a lot of the tools you'd expect from a visual editing tool, like text editing, styles and an animation timeline editor.
Druids (https://github.com/fulcrumresearch/druids) is an open-source library for structuring and running multi-agent coding workflows. Druids makes it easy to do this by abstracting away all the VM infrastructure, agent provisioning, and communication. You can watch our demo video here (https://www.youtube.com/watch?v=EVJqW-tvSy4) to see what it looks like.
At a high level:
- Users can write Python programs that define what roles the agents take on and how they interact with each other.
- A program is made of events - clear state transitions that the agents or clients can call to modify state. Each event gets exposed as an agent tool.
- Druids provisions full VMs so that the agents can run continuously and communicate effectively.
We made Druids because we were making lots of internal coding tools using agents and found it annoying to have to rearrange the wiring every time.
As we were building Druids, we realized a lot of our internal tools were easier to express as an event-driven architecture – separating deterministic control flow from agent behavior – and this design also made it possible to have many agents work reliably.
We had issues with scaling the number of concurrent agents within a run, so we decided to have each program run in an isolated sandbox program runtime, kind of the same way you run a Modal function. Each agent then calls the runtime with an agent token, which checks who can talk to who or send files across VMs, and then applies the tool call.
Our early users have found the library useful for:
- running many agents to do performance optimization
- building custom automated software pipelines for eg code review, pentesting, large-scale migrations, etc...
We've heard that the frontier labs have the infrastructure to quickly spin up 100 agents and have them coordinate with each other smoothly in various ways. We're hoping that Druids can be a starting point to make that infrastructure more accessible.