Ah sorry about that. I have weird tastes in design. The README.md is less detailed but covers the basics: https://github.com/rjcorwin/cook/

Two types of people eh, I thought it was quite enjoyable! Reminded me of a SNES game

On asking for user input during implementation, it's best to use this when you have a plan sufficiently written up that you can point it to. To prep that plan, you can also use cook to iterate on the plan for you. Having Claude Code use `/cook` directly is nice because it watches what the subagents are up to and can speak for them, although Claude can't speak to the subagents running through cook.

On permissions, by default, when it runs instances of Claude they will inherit your Claude's permissions. So if there is no permission to `rm -rf /`, Claude will just get denied and move on. Using the docker sandbox option (see bottom of page), then it runs inside that `--dangerously-skip-permissions` and get more stuff done (my preferred option). The hard part about that is it means you need to set up the Docker sandbox with any dependencies your project needs. Run `cook init` and edit the `.cook/Dockerfile` to set those up.

If you impl this as a backend and connect to Telegram bots, agents can just do `$ ask "Should I do this?"` for agent→human and `$ alert "this thing blocked me"` for coder→planner. That's what I'm actually doing — I have 1 manager + 3 designers + 1 researcher + 2 debugger + 1 communicator + any number of temporal coders/reviewers in my setup, all connected to taskwarrior for task-driven-dev

It seems to be in the spirit of automated vibecoding. I assume it skips all permission checks.