std_slop

yes it does - https://github.com/hsaliak/std_slop/blob/main/system_prompt.... I've added the same thing to the system prompt of the internal agent I wrote for work, which talks to claude models. I have not gone into the details on whether it adheres to the format exactly, but i do see visibly less slop and less marketing nonsense in the Assistant messages.

I have a custom agent that generates patches like you will with kernel development and I review and merge those in. https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode... My agent forces this workflow by disabling modifications outside the coding step. I added looping to this not too long ago. https://github.com/hsaliak/std_slop/blob/main/docs/mail-loop... This gives me the best of both worlds, hand curated reviews and automation. I often get the best quality if I do both, with an agent doing a pass first.

I wrote https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode... to avoid the brain rot from just shooting slop. It has helped me stay sane, review code and make changes step by step. I dont go as fast as with other agents, but this works for me, and I enjoy the process.

I have a coding agent https://github.com/hsaliak/std_slop where the sessions are in SQL ledger. So /session [new, clone, deletes, undo] are supported and all sessions are persistent. Cloning lets you 'fork' the context and undo lets you roll back, basically solving the problem you state above. Sessions are linear though, so you cant do this _while_ an existing session is cooking. That said, I am excited about this update too, I've been playing with ACP support and Zed's UX was bare bones. I want to run my agent with multiple workers now, and see what happens.

Tool output truncation helps a lot and is one of the best ways to reduce context bloat. In my coding agent the context is assembled from SQLite. I suffix the message ID to rehydrate the truncated tool call if it’s needed and it works great. My exploration on context management is mostly documented here https://github.com/hsaliak/std_slop/blob/main/docs/CONTEXT_M...

Agreed on the need, and this space needs more exploration that is not going to come from big-cos as they are incentivised in boosting spend. I've been exploring the same problem statement, but with a different approach https://github.com/hsaliak/std_slop/blob/main/docs/CONTEXT_M.... The comment was more around how to make their approach sticky.. I feel that local SLMs can replicate what this product does.

https://github.com/hsaliak/std_slop a sqlite centric coding agent. it does a few things differently. 1 - context is completely managed in sqlite 2 - it has a "mail model" basically, it uses the git email workflow as the agentic plan => code => review loop. You become "linus" in this mode, and the patches are guaranteed bisect safe. 3 - everything is done in a javascript control plane, no free form tools like read / write / patch. Those are available but within a javascript repl. So the agent works on that. You get other benefits such as being able to persist js functions in the database for future use that's specific to your codebase. Give it a try!

I explored this in std::slop (my clanker) https://github.com/hsaliak/std_slop. One of it's differentiating features of this clanker i that it only has a single tool call, run_js. The LLM produces js scripts to do it's work. Naturally, i tried to teach it to add comments for these scripts and incorporate literate programming elements. This was interesting because, every tool call now 'hydrated' some free form thinking, but it comes at output token cost. Output Tokens are expensive! In GPT-5.4 it's ~180 dollars per Million tokens! I've settled for brief descriptions that communicate 'why' as a result. The code is documentation after all.

I'd like to plug https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode... my coding harness (std::slop)'s mail model (a poor name i admit). I believe this solves a fundamental problem of accummulating errors along with code in your project. This brings the Linux Kernel style patch => discuss => merge by maintainer workflow to agents. You get bisect safe patches you 'review' and provide feedback and approve. While a SKILL could mimic this, being built in allows me to place access control and 'gate' destructive actions so the LLM is forced to follow this workflow. Overall, this works really well for me. I am able to get bisect-safe patches, and then review / re-roll them until I get exactly what I want, then I merge them. Sure this may be the path to software factories, but it scales 'enough' for medium size projects and I've been ab

It takes your query, computes the complexity of the request, and tries to route it to the appropriate model. There is a /manual command i think, to pick the right model. They mask the 429s well in Gemini-Cli - if an endpoint is rate limited, they try another, or route to another model, etc to keep service availability up. Your experience on the 429s is consistent with mine - the 429s is the first thing they need to fix. Fix that and they have a solid model at a good price point. I use my own coding agent (https://github.com/hsaliak/std_slop) and not being able to bring my (now cancelled) AI account with Google to it is a bummer. I'd still use it with the Code Assist Standard license if the google cloud API subscription allows for it but I have no clarification.

I came across a coding harness using Lua as its control plane yesterday: https://github.com/hsaliak/std_slop/blob/main/docs/lua_integ... > std::slop is a persistent, SQLite-driven C++ CLI agent. It remembers your work through per-session ledgers, providing long-term recall, structured state management. std::slop features built-in Git integration. It's goal is to be an agent for which the context and its use fully transparent and configurable.

This is the way. This exact workflow is my sweet spot. In my coding agent std::slop I've optimized for this workflow https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode... basically the idea is that you are the 'maintainer' and you get bisect safe, git patches that you review (or ask a code reviewer skill or another agent to review). Any change re-rolls the whole stack. Git already supports such a flow and I added it to the agent. A simple markdown skill does not work because it 'forgets'. A 'github' based PR flow felt too externally dependent. This workflow is enforced by a 'patcher' skill, and once that's active, tools do not work unless they follow the enforced flow. I think a lot of people are going to feel comfortable using agents this way rather than going full blast. I do all my development this way.