Prompts are interfaces
Early prompts tend to grow by accretion. Something goes wrong, a sentence is added to prevent it, and a few months later the prompt is a page of rules nobody fully remembers the reasons for. Changing any of it feels risky, so nobody does.
It helps to think of a prompt as an interface between your code and the model, and to give it the same care as any other interface.
Separate instructions from data
Keep the fixed instructions in one place and insert user content into clearly marked sections. This makes it obvious what the model is supposed to do and what it is supposed to work on, and it makes it harder for text inside the data to be mistaken for instructions.
Ask for structured output
If code will read the answer, ask for a format that code can parse, and validate it. A response that fails validation should be treated as an error, not patched up with clever string handling. Clear failures are easier to fix than silent ones.
Explain the reason, not only the rule
"Never mention prices" is a rule. "Prices change daily and are shown elsewhere on the page, so do not quote them" is a rule with a reason. Models follow the second kind more sensibly in situations the rule did not anticipate, and so do the people who maintain the prompt later.
Version it and test it
Prompts belong in version control next to the code that uses them, together with the examples that show they work. When a prompt changes, run the examples. This sounds like ceremony until the first time a harmless-looking edit quietly breaks a case nobody was watching.