There's no such thing as universal "good software development practices". There's only lots of opinions. Some are more popular, some less; some are language, domain or company-specific (or even tool-specific - see various webshit frameworks whose idiosyncrasies spill over to significantly alter coding style), and many exist only as historical baggage - but they all largely conflict with each other. And LLMs have seen them all.

Consider as an example, that "Clean Code" used to be gospel, now it's mostly considered a book of antipatterns, and many developers prefer to follow Ousterhout instead of Uncle Bob. LLMs "read" both Clean Code and A Philosophy of Software Design, but without prompting they won't know which way you prefer things, so they'll synthesize something more-less in between these two near-complete opposites, mostly depending on the language they're writing code in.

The way I think about it is: "You are a staff software engineer with 15 years of experience in <tech stack used in the project>" is doing 80% of the job, by pulling in specific regions in the latent space associated with good software engineering. But the more particular you are about style, or the more your project deviates from what's the most popular practice across any dimension (whether code style or folder naming scheme or whatnot), the more you need to describe those deviations in your prompt - otherwise you'll be fighting the model. And then, it's helpful to describe any project-specific knowledge such as which tools you're using (VCS, testing framework, etc.), where the files are located, etc. so the model doesn't have to waste tokens discovering it on its own.

Prompts are about latent space management. You need to strengthen associations you want, and suppress the ones you don't. It can get wordy at times, for the same reason explaining some complex thought to another person often takes a lot of words. First sentence may do 90% of the job, but the remaining 20 sentences are needed to narrow down on a specific idea.