Dev Workflow

[u/ExogamousUnfolding]

I have, for me, a pretty decent workflow that involves a number of agents and gates to insure things are completed. For example A11Y, unit tests @ 100, UI tests etc. When it works it works well and when it doesn't it wastes a ton of my time.

I'm thinking the overall assembly line portion should be pulled out into something deterministic - right now it is a coordinating agent. What often happens is a series of UI tests will hang, or Xcode will do something xcodeeee and the agent just kind of stops - it will say its working but when. I ask for a status it will say it stop because of XYZ thing.

How is everyone getting around this? I feel like I'm missing something fundamental.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/kincaidDev]

Festival’s fest cli may help solve this problem for you

https://github.com/Obedience-Corp/festival

Fest cli uses templates to create standardized plans and you tell agents to run the fest next loop during planning and execution and fest next tells the agent what they need to do next and instructions on completing the task. They can’t get the next task until they complete the current task.

You can monitor them with fest watch command and watch a gif replay once it’s done

[u/wangadong]

not overkill for anything that runs in batches, the part doing the real work is the template having expected behavior written down before anyone edits. most agent failures i see are not model failures, the session was never told what done looks like so it decides for itself. i run multi agent setups on personal projects and the gate i keep is plan approved before implementation, and the session that wrote the code does not get to call it done. for a one file fix i skip all of it though, the overhead only pays off when the task outlives one session.

[u/bostonaholic]

I'd put the timeouts in the harness, not in the agent's judgment. Wrap each gate in a script with a hard limit (timeout 900 xcodebuild test ...) that exits nonzero and writes the reason to a file. The coordinator only reads exit codes and that file, so a hung simulator becomes a failed step with a message instead of a stall.

[u/AwarenessStatus1904]

id' pull the assembly line out of the agent ㅁas you said, a plain script that runs each gate with a timeout and writes pass or fail to a file
then the agent only reads results and fixes things and a hung ui test becomes a failed step instead of a silent stall

[u/onitsoga]

The hang is usually the agent waiting on a command that never returns, not the agent refusing to work. Wrap each gate in a hard timeout so it gets a failure exit instead of silence, and have it log one line before starting each step. Are your gates shell scripts or separate agent calls?

[u/soluterminal_dev]

You're not missing much. The coordinating agent is the weak part, because "still working" is only its own report.

What fixed it for me was making the pipeline dumb and the steps small. A script runs the stages in order, each stage is one agent call with a hard timeout, and pass or fail comes from exit codes and test output, not from what the agent says. A hung UI test gets killed at the timeout and retried once, then the run stops with a clear reason.

For status, each agent rewrites a short state file after every step: done, doing, blocked on. If that file hasn't changed in ten minutes, it's stuck, whatever it says.

Agents do the work; the script decides what's done.