There is no rule, but in addition to the executive summary you will normally submit a more technical report with your findings.
The executives usually don't have a clue about tech, but there is usually an IT team, who will look at your report too, and assess the results. Quite probably they will take part in remediation of the flaws, possibly with assistance of the pentesters. So they deserve some insight. In fact there may even be a fully-fledged network security team on site. If you defeat their defenses, they will want to know the details, and they should get them.
I personally like to provide technical appendices, that includes not only the tools used, but sometimes, the exact commands that were typed. You can easily record the output of a terminal session (for example using GNU screen) and then do copy-paste into your report.
What's the point? The point is to provide commands or attack scenarios that can be reproduced by the technical team later, in order to verify that the flaws have indeed been patched. And it's something they could run anytime, for example after making configuration changes or adding infrastructure components.
Even a simple
nmap command is useful and worth quoting, if it's been instrumental in locating a vulnerable endpoint. No need to quote every tool you know or you've used, but rather quote the tools that actually helped you during that assignment.
If you find a flaw, you've done a good job, congratulations. But if you explain the methodology this is even better because the readers are going to learn a thing or two, and perhaps they will be able to incorporate the methodology in their own business process.
As the saying goes, don't just give a man fish - teach him how to fish (or phish).