I am working on speeding up the review-refine loop of LLM generated artefacts between me and the LLM. i run my coding agent (claude code) in auto / full-permission mode, so it doesn’t stop for accept/reject — by the time it’s done i’ve got a pile of generated code, docs, sometimes ui to review. and the slow part for me is to refine it before push it to remote. i would copy-paste snippets to point at what i wanted changed, screenshot the ui, describe where the problem was in prose, one message at a time. its cumbersome.
so i built prereview to speed up that review-fix loop. you run it in your repo (or point it at a file, a dir, or a running dev server), click what’s wrong: a diff line, a markdown/html block, a region of an image, a box on a live site — and leave a comment. the comments go to a csv, your agent reads it and fixes things and tells you what it did via a comment or even posts suggestions which you can accept or reject. it ships with a claude code skill, but the handoff to llm is just an open csv protocol, so any llm cli can drive it.
stuff that might interest people here: single static go binary, fully offline; it reviews docs/images/live ui as well as code; comments re-anchor when the file changes under them.
it’s mit and still early but I use it everyday. Its here: https://github.com/livetemplate/prereview
I am using claude cli/tmux on a hetzner box and connecting to it via claude remote control. I have connected the box and my phone over telnet which allows me to view any UI work. Sometimes I do have to switch to my laptop for UI desktop layouts.
One gap which I kept running into on both mobile and desktop was refining the initial plan and then later refining the generated artifacts which involved lots of imprecise copy-paste. To scratch my own itch I built a review tool to improve the velocity of planning and refining generated artifacts. It has become my daily driver: https://github.com/livetemplate/prereview
Yeah the project is right out of the oven so will add some usage gifs shortly to the repo. Meanwhile here are some screenshots on imgur: https://imgur.com/a/zxZo651
:) We are all converging on the same problems and tooling to fix them.
Built this in the last couple days to review changes done by claude on a hetzner box(over tailscale on my phone) and leave comments before pushing to remote : https://github.com/livetemplate/prereview.
Runs everywhere and can has a claude skill: /prereview which starts a new instance for the current changes. Has a “Hand-off” button to signal claude to process the comments.
UI is responsive. I use it on my iphone with claude mobile app + /remote-control to leave comments before pushing.Still requires polish but core features work.
Recently started using: https://github.com/babonet/Markco (cant find the similar extension i used previously since it got uninstalled). I add inline comments in the markdown and I have a skill which uses the comments to update the plans and remove resolve comments.
That is super cool. Sorry to be nitpicky but would really like to know your mental model: I didn’t understand from the blog why user waiting for a functional UI is a problem ? isn’t the partial streamed UI non-functional ?
I can see the value in early user verification and maybe interrupting the LLM to not proceed on an invalid path but I guess this is customer facing so not as valuable.
"In interactive assistants, that latency makes or breaks the experience." Why ? Because user might just jump off ?
Hey. I have checked out pushup before. Its great. I guess I am taking a niche approach which not many would find useful. To clarify: What is adding more complexity? alpinejs ?
The (claimed) value proposition is leveraging block/template to decompose the html page and bind its computation to browser events over a pubsub channel. Its a toolkit and not a framework so one can still use their favourite framework. The Go library isn’t doing anything earth shattering but re-implementing the aforesaid design would still need to be done in any framework.
Yeah I was afraid of that. Websockets are costly. Thankfully the approach doesn't completely depend on websockets so I have disabled it for now on the site.
It is intended as a longer-term project originating from the previous experiment: https://github.com/adnaan/gomodest. You are right, a better selection criteria for the target audience should be enlisted. I have been working on this for a while so I just got greedy for some early feedback.