◇ Could this help me?
Yes, and the interview technique is the genuinely good idea here. Most people write a bad instructions file because they are being asked to describe their own working preferences from a blank page, which is hard, while answering specific questions about them is easy, so having the assistant elicit the content produces a far better file for less effort. Splitting writing rules into their own file is also sound, since tone guidance is long and only relevant when something is being written. General practice, with two corrections: an interview produces more than belongs in an always-loaded file so the result needs trimming, and the connector step deserves real thought about scope rather than being the throwaway final beat, because read access to a mailbox and the ability to send from it are very different grants.
Interview me and then write my global instructions file. Ask me questions about how I actually work, what outputs I want and in what form, what you should never do, and what you would otherwise get wrong about me. Do not write anything until you have asked enough to be specific rather than generic. Then produce two separate files: the global instructions, containing only what applies to nearly every conversation, and a writing rules file holding tone and style guidance that should load only when something is being written. Tell me which of my answers you deliberately left out of the always-loaded file and why. Do not set up any connectors as part of this.