> Good communication with LLMs is the least keywords used to make it deducible for LLM what you exactly want.

I am not sure that is the case, at least with a large number of LLMs. CO-STAR and TIDD-EC are much about structure and explanation than brevity.

Finding what works for an llm and what not is also part of communication skills.

Though I do not have a good idea what is _bad_ communication with an llm. People say that sometimes, but when specific examples arise I do not see really anything more than limitations of llms (and the improvements they often suggest do not do anything either). So it would be good to have some more concrete examples, unless that is about inability to communicate a problem in general, stemming from actual inability to _understand_ the problem. Also a lot change in time, I think in the past one had to really coddle an llm "You are the best expert in python in the world!" but I am not sure that is that important nowadays.

Bad communication => being too ambiguous, expecting LLM to understand you through that ambiguity and then not being satisfied when it didn't.

Bad communication: "My webapp doesn't work"

Good communication: "Nextjs, [pasted error]"

Bad communication is giving irrelevant information, or being too ambiguous, not providing enough or correct detail.

Then another example of good communication and efficiency in my view is for example "ts, fn leftpad, no text, code only".

I myself can understand what it means when someone was to prompt it and LLM can understand such query for all domains.

Although if I was using Copilot I would just write the bare minimum to trigger the auto complete I want so

const leftPad =

is probably enough.