/goal makes Claude Code and Codex keep working until the job is done, so you stop typing "keep going." A plain guide to writing finish lines that finish.
Yes they can be great when used properly. I created my own goal readiness packet skill to ensure the ideal structure for a goal and that way they are always have a standardized and validated structure to ensure they consistently perform as intended. Speeds up the process. Adds one extra ceremonial step but it's worth it.
Dude - these examples don’t make sense. Goals work best for verifiable conditions where the work would take long and require your constant input
In the example with the trip, you’re basically doing the same amount of work and setting the goal actually requires more brainpower than less - you have to write instructions, think about what you want to do, dates, constraints etc. That is MORE work than answering agent’s questions interactively. So you’re not actually saving you any time or brainpower
Fair on the trip. Writing the goal isn't less work. What it saves is the back-and-forth and machine time (3m23s vs 8m2s in that run).
/goal earns its keep on things you can verify, like the research report and the notes-to-FAQ. If you're still shaping what you want, skip it and just talk to it. The bigger win for me is catching the false "done."
In my experience, the goal works best after defining a clear plan with superpowers’ brainstorming (optionally /grill-me skill). Recently I described 10 most useful features to manage Claude sessions (once Claude responds in a satisfying way). Check it out at https://productpeak.substack.com/p/10-claude-code-power-moves-most-product
Yes they can be great when used properly. I created my own goal readiness packet skill to ensure the ideal structure for a goal and that way they are always have a standardized and validated structure to ensure they consistently perform as intended. Speeds up the process. Adds one extra ceremonial step but it's worth it.
Love that. A standard structure is where it pays off. I use the same four parts every time: finish line, prove it, show me, if blocked.
https://github.com/iAAi33iAAi
Dude - these examples don’t make sense. Goals work best for verifiable conditions where the work would take long and require your constant input
In the example with the trip, you’re basically doing the same amount of work and setting the goal actually requires more brainpower than less - you have to write instructions, think about what you want to do, dates, constraints etc. That is MORE work than answering agent’s questions interactively. So you’re not actually saving you any time or brainpower
Fair on the trip. Writing the goal isn't less work. What it saves is the back-and-forth and machine time (3m23s vs 8m2s in that run).
/goal earns its keep on things you can verify, like the research report and the notes-to-FAQ. If you're still shaping what you want, skip it and just talk to it. The bigger win for me is catching the false "done."
In my experience, the goal works best after defining a clear plan with superpowers’ brainstorming (optionally /grill-me skill). Recently I described 10 most useful features to manage Claude sessions (once Claude responds in a satisfying way). Check it out at https://productpeak.substack.com/p/10-claude-code-power-moves-most-product
Same. Have the planning conversation first, then write the finish line. I also let Claude draft the /goal and critique it before it starts.