I really appreciate you mentioning Murasaki - thank you. I've been looking for something like this for a long time, because every single EPUB "reader" out there does so much more than just read EPUBs. This one does just that, I love it.
This is basically the setup I ended up using after trying to check the following boxes:
- using GPT‑5.6‑sol via OAuth instead of an API key, with Claude Code as the harness
- sandboxing the reviewer agent completely (GPT‑5.6‑sol seems to be a model that believes "the end justifies the means", I read tons of horror stories on X and Reddit)
- using herdr to view and control the current process of the review agent (can jump in at any time)
- the main agent can refute certain points made by the reviewing agent
While I love both Go and Alex, my experience with HTMX has always ended up being disappointing.
I think the best way to put it, when I'm working with HTMX it feels like the complexity of the codebase is growing at a 2:1 rate compared to the app itself. I always end up with some weird edge case that I can not come out of without some weird hack.
I get why people dislike Node packages, HTMX feels like it's an overcompensating response to that. But the time you save by not having to wrestle with JSON is tripled when you try to make the app actually look or feel good. It takes me 2 minutes to slap together a Mantine template [1] and tap into some of the best UI components, then I can embed the built static assets and end up with the same single Go binary.
I understand the sentiment. Rails was my introduction to hypermedia and it was convenient and easy, so experiencing friction when building with Go/HTMX came as a surprise.
After a few attempts I learned that abstractions are important :D
Without a component builder and reversible router is indeed pretty painful (and Rails just ships with these things so you didn't have to worry about it).
The biggest benefit for me personally is that computation and data live in one place, which carries you very far. Also, machines like hypermedia: LLMs are great at using and testing hypermedia apps because they are self-contained and the cycle time is lower because you don't need to wait for JS.
And yes, no easy off the shelf component library makes starting harder.
It's relatively easy to generate your own nowadays, I mostly go through the Ruby on Rails guides and mix and match the pieces I want for go and turn them into libraries :)
I've found that my whole design philosophy has to change to work with HTMX. That's not a dig, it may even be a good thing, but it's a significant shift. The designs become much more native to the web and much less inspired by mobile apps.
Basically any data grid that implements multiple AND/OR filters at column level, sorting, reordering, infinite scrolling, virtualization for handling large amounts of data, etc. Also handling basic pending / error / retry states (things that I take for granted with React Query).
Yeah, a data grid is a good example of a complex hyper-interactive component. There are people out there who have made them with Web Components, which can be dropped in and used in htmx projects when used correctly.
Re: request states, handled very nicely out of the box by htmx with a little knowledge of attributes like hx-indicator and JS event handlers to handle htmx error events.
I use lazyvim for all my neovim config. Does it fly in the face of the configurability or minimalism of vim? I'd argue no, but rather it is an expected outcome of a highly configurable system. Some people don't want to think about this kind of thing, they just want something that works.
I'd have to say at least a bit? Which is totally fine if it works for you, but there's gotta be some amount of extra features added after which "minimal" stops being a good description.
Edit: Although, we should also acknowledge that minimalism is a sliding scale. Compared to plain vi, vim is bloated. Compared to a full blown traditional IDE, lazyvim probably is minimal.
How does Superpowers compare with Matt Pocock's skills[1]? I only tried the latter, and to be honest, I had positive results without burning a quadrillion tokens.
I heckin love his /grill-me skill. Terse, to the point, and delivers outsized results.
Gonna take a moment to share my own generic "retro" prompt, which has found many areas of improvement IME.
> Let's conclude with a retro. Did you run into any issues during this session that you think could be improved? Any failed tool calls, confusing docs/prompts, or tricky wording that took you effort to figure out, etc? Any final thoughts that you want to raise? Anything minor you didn't mention? Help make this codebase easier for the next agent to work in.
It's somewhat doc-focused since I'm currently working on fairly dense design docs... but you can easily customize it for your own needs.
This prompt reveals how absolutely _ass_ the Claude Code harness is (so many stupid tool call failures), but not much I can do about that.
> This prompt reveals how absolutely _ass_ the Claude Code harness is (so many stupid tool call failures)
I've just started using Claude Code this month after months of Claude in VSCode + GitHub Copilot (and a bit of dabbling with AWS Kiro), and I'm actually impressed by how seemingly polished Claude Code is.
I think Copilot in VSCode broke far more in my months of (ab)using it.
Side note: Matt has a new skill /grill-with-docs, which he recommends as the one to use for coding. Regular /grill-me he doesn't recommend for coding anymore.
As another happy Enpass user I don't think it is significantly different. The exception being that the KeePass frontends are really just as expensive as Enpass is now.
I also got a good deal on the lifetime pro membership before they moved to more of an annual model, which factors into my decision.
Which Keepass frontend do you use (if you use one on mobile)? Keepassium and Strongbox seem to be the ones that people talk about, but they are pricey too. I don't know anything about AuthPass, but I'm reluctant to use a free product; I'd rather use an inexpensive one, just to hopefully thwart supply chain attacks on that front.
reply