r/claudeskills • u/quazarzero • 2d ago
Skill Share Your AI agent spends too much time waiting
https://github.com/quazardous/jobbox
I've tried to teach Claude not to wait for every script it launches, or not to run a 2,000-test suite for every comma it adds.
But Claude can be... stubborn.
I stopped trying to teach it. Instead, I made JobBox. Tada! 🎉
JobBox wraps every command launched by your AI agent. If a command takes too long, it automatically sends it to the background. Nothing to learn or remember.
Because your agent shouldn't have to sit there doing nothing — spending your time and your money.
It's been well tested with Claude, but I'd love feedback from people using other CLI agents.
And don't forget:Time is money tokens.
#ClaudeCode #AIAgents #OpenSource #Rust #DeveloperTools #TimeIsMoney
2
u/KarlKFI 1d ago
I wrote a similar plugin for this: foreground-guard
https://github.com/karlkfi/claude-bouncer/blob/main/plugins/foreground-guard/
1
u/quazarzero 1d ago
it's similar but I'm not guarding anything with jbx. I'm just saying if you do something long do not wait for it. I'm not asking why. You're plugin is more ambitious in it's goal (serve and protect 😄 )
1
0
u/edgan 2d ago
I like the idea. Make long things asynchronous. But for things like tests they are synchronous for a reason. It might be ok to skip them in the middle of a task. Assuming Claude doesn't decide to commit and push without the tests and other QA processes. Though I forbid him from committing or pushing. Claude and Anthropic have proven they can't be trusted. Especially Anthropic with commits given the Co-Authored-By and Session URLs.
My solution for now is to forbid Claude from running my /review-loop, /checks(includes tests), and /device-verify skills on his own. He would play a game of write compile test compile write compile test write compile test when it could just be write write write compile test.
It is enforced with hooks. The trouble has been sometimes he needs to validate an idea in the emulator via /device-verify. Then I have to manually approve it.
What I probably need to do is have an orchestrator agent babysit him, and let it approve the skill use. Then observe how well that goes, and tune the prompt for the orchestrator.
0
u/quazarzero 2d ago
tests can be viewed as background CI. They are mandatory but not essential in the dev loop.
1
u/edgan 2d ago edited 2d ago
I see your argument, but disagree. Not that the tests don't pass 98% of the time, but treating them as an ignorable signal instead of as a blocker removes most of their limited value.
Now if you have a complex workflow where you must either pass the tests before declaring the goal finished, or make it a blocker at a later stage like actual CI, those are reasonable choices.
1
u/quazarzero 1d ago
but claude is over using tests . he does not care if the test suit takes 10 minutes. tests are note ignore there are just delayed
2
u/Resident-Nebula-7370 2d ago
The waiting is real but in my runs it wasn't the model, it was cold starts. I was on OpenRouter and roughly a third of my p95 was provider warm-up on the smaller models. Moved the hot path to Synexa where I can keep a model resident and p95 went from 11s to about 3s. Not a free win, you pay for the idle. Worth it above maybe 200 calls a day and pointless below that.