As it stands, if I type /summarize mid-stream, it doesn’t queue up the prompt like any normal prompt would, it immediately trainwrecks the stream and that’s not okay.
If you want to derail mid-stream, fine, but do it with a new, different command like /summarize-now. This intentionally distinguishes the difference between the regular prompt behavior and improves affordance. Users KNOW that /summarize will fire when the current stream is complete, and /summarize-now will immediately fire, trainwrecking any ongoing process.
I still have no idea what use case the derailment behavior of the current /summarize command is serving, but something needs to be done to bring this command back inline with the rest of the built in Cursor commands. I’m sick of burning tokens on this stupid behavior - granted, you’d think I’d learn by now, but the reality is that this is an affordance issue, not a user problem.
TL;DNR:
- Make it so that the current /summarize command fires off after the current running process/stream is complete.
- Create a new /summarize-now command that derails the current stream and allows you to trainwreck if you want it to.
- Alternatively, just make it so /summarize doesn’t trainwreck you and instead treat it like literally any other command. The command queues like normal, users can hit enter again to fire it immediately and derail the stream.