No. The main signals which are conventionally used by a user to kill a process are:
- SIGINT (sent by Ctrl+C in a terminal) — abort the current operation and go to the toplevel interactive loop. If the program doesn't have a toplevel interactive loop, kill the program.
- SIGTERM — stop the program cleanly. This may do an emergency save.
- SIGHUP — sent by the system to a program running on a terminal when the terminal goes away. Usually handled like SIGTERM.
- SIGQUIT (sent by Ctrl+\ in a terminal) — die without any cleanup and dump core (for debugging).
- SIGKILL — the program dies and doesn't get a chance to do any cleanup.
None of these have a conventional meaning whereby the program would prompt the user for anything. It could make sense for a program to prompt on SIGTERM, but I can't think of a program that does it. Some programs do prompt on SIGINT, offering a choice to return to toplevel or exit the program or enter a debugging mode. Generally speaking, the assumption when a program receives SIGTERM is that the user isn't in front of the console to interact with the program, or that the program isn't responding — otherwise the user would be using the interactive controls instead of sending a signal.
GUI events such as clicking on the x button in the window title bar don't send a signal, they send an event on the normal X11 communication channel.