You can memorize all six letters, Context, Objective, Role, Drive, Output, Norm, and still write a prompt that lands flat. Knowing the letters was never the hard part. Deciding how much weight each one deserves for the task in front of you is.
That distinction matters because it's exactly where most advice about prompting stops short. Guides teach the components. Almost none of them teach the judgment call: how much context earns its place before it starts drowning out the actual question, which role helps here and which one is dead weight, what to leave out on purpose. That judgment call is the actual skill, and it doesn't come from memorizing a list.
The gap is in the problem, not the prompt
MIT Sloan's teaching and learning group, citing researcher Ozan Acar, draws a distinction worth sitting with: prompt engineering is about word choice, phrasing, sentence structure. Problem formulation is about defining the focus, scope, and boundaries of what you're actually asking for. Acar's argument is that developing the second skill matters more in the long run than mastering the first, because a perfectly worded prompt built on a badly defined problem still produces a bad answer.
This is the same gap the rest of this series keeps circling back to. Why AI can't help without context. covered how a prompt fails when the situation never makes it onto the screen. That's a problem-definition failure dressed up as a wording failure. Knowing that “Context” is a field to fill in doesn't help if you don't know which parts of your situation actually change the answer.
Two trade-offs the six letters don't resolve for you
Take the two hardest calls in the whole framework.
How much context is enough? More isn't automatically better. Piling in every fact you know about your situation can bury the one detail that actually mattered, the same problem context-window research runs into on the technical side: the model pays more attention to some parts of what you give it than others, and excess detail dilutes rather than sharpens. Knowing “add context” as a rule doesn't tell you where the line sits for this particular question.
Which role helps here? What role should you give AI? 10 examples. went through the research on this directly: a role reliably improves writing, tone, and style tasks, and just as reliably risks hurting factual or calculation-heavy ones. Knowing that “Role” is a field you can fill in says nothing about whether this task is the kind a role helps or the kind it quietly sabotages. Get that call wrong and adding a role makes the prompt worse, not better, exactly the finding four separate research write-ups landed on this year.
Both of these are judgment calls made fresh for every prompt. A checklist doesn't make them for you.
Frameworks proliferate faster than the skill to use them well
A systematic review in the International Journal of Educational Technology in Higher Education looked at how prompt engineering is actually being taught and used across higher education. It found plenty of framework designs in circulation and real potential in well-designed prompts, but the applicability and consistency of that potential varied a lot depending on how the frameworks were actually applied, not just whether students knew they existed. Teaching the components didn't reliably produce the judgment to use them well. That's a pattern worth noticing: frameworks are easy to teach and easy to memorize. The trade-off decisions inside them are not.
Thoughtworks gets at the same idea from the practitioner side. Their “lede” technique, borrowed from journalism, breaks a prompt into what, why, where, how, and how much, structurally similar to CORDON's six fields. But the article's more interesting recommendation is to have the AI evaluate its own output afterward, checking for blind spots and where more expertise was actually needed. That's an admission that getting the structure right up front doesn't guarantee you got the trade-offs right. Even a well-formed prompt needs a second look to catch what the structure alone missed.
The real skill is architecture, not vocabulary
Simon Willison, a well-known independent voice in the AI space, makes a version of this argument from the practitioner side: prompt engineering, done well, pulls in linguistics, security, and human psychology, expertise that goes far deeper than knowing which words to use. Architecture is the right word for it. An architect doesn't just know that buildings need walls, floors, and a roof. The skill is deciding how much of each, in what arrangement, for this specific site and this specific brief. Nobody would call knowing “buildings have four walls” architectural expertise. Knowing the six letters of a prompt framework is the same category of knowledge: necessary, not sufficient, and nowhere near the hard part.
Where CORDON actually sits
This is the whole reason CORDON doesn't just teach you the six letters and send you off to apply them yourself. A checklist you memorize still leaves every trade-off in your hands: how much context, which role, what to leave out, and whether a field is worth answering at all for this task. CORDON takes a minimum of four of your six raw answers, whichever genuinely apply, and generates the finished prompt from them, the same trade-off work an experienced prompt writer does by instinct, done for you instead of left as homework.
Try CORDON and see that trade-off made for you.