alt Hacker News> Maybe I'm fighting the model here > And no, telling it not to do this does not stick.
You're fighting the model, don't argue with city hall. Set the standards and let it figure out how to execute, stop getting bogged down in the minutia. I try, as much as I can, to treat the session as a black box - only the inputs and outputs matter, internal prompting of subagents is way out of scope.
You can't change it via prompt, and you can't control the guardrails, so something else has to give - either your perspective or the system you're managing. If you really believe that the internal prompting is bad, turn off subagents and workflows and only let it execute in thread.
But if you're going to do that, you'd better benchmark it against not doing that, because historically fighting the harness and model globally makes everything worse. I would bet you that the subagent prompting is excellent, and anything you do to change it will make it worse, but I wouldn't make it a large bet.
Replies
I think he has a point. I noticed the same with skills that invoke another agent harness.
I just have a skill to review the changes in the current worktree.
By default, it will put lots of instructions about locating the changes into the prompt, like explaining how to use git diff.
These instructions are obviously unnecessary. I can believe that the same issue of needlessly verbose prompts might exist with subagent spawning.
I would not go to customize that one however. With skills, it is a more natural fix.
If I ask a model to do a change involving editing a file, and it starts investigating internals of my build system, then sure it might not be counterproductive or break the task, and might have taken only extra 30 seconds; but for all I know, my quick rejection of a shell invocation (with a simple "irrelevant to the task" comment) might have just saved me half of today's Opus tokens, which already makes it worth it.