The "formal letter" framing is right, and spec-driven development takes it further: you are not just writing clearly, you are decomposing the request into named sections that the model can reason about independently.

Role, context, objective, constraints, output format. These map almost directly to how a well-written spec is structured. The difference between a vague prompt and a good one is usually that the good one has all those pieces present, even if implicitly. Making them explicit and separate removes the ambiguity.

Built github.com/Nyrok/flompt around this: a visual canvas to decompose prompts into those blocks and compile to XML. The spec-driven angle validates why structure beats raw text.