TL;DR: A Reddit user shared a system prompt that makes an LLM plan in tiers, from rough to detailed, using compressed shorthand before it writes the final answer. The goal is fewer hallucinations and less drift on long tasks. It is a small project with early reactions, so treat it as something to test, not something proven.
What this prompt does
u/tkdeng posted a system prompt on r/PromptEngineering called NCM Simulation. NCM stands for Next-Concept Modeling. The idea is to plan at the level of concepts first and fill in the words later. Think of it as deciding what each part of the answer needs to say before deciding how to say it.
In practice, the prompt tells the model to run a multi-tier planning phase before it writes anything you will read. The first tier is very rough, just the big moves of the answer. Each later tier adds detail to the one before it. The plan uses compressed semantic tokens, which is a kind of shorthand, so the model is not spending a lot of output on full sentences while it plans. Only after that does the model produce the real output.
The repo is at github.com/tkdeng/ncm-simulation if you want to read the prompt yourself. Read it before you run it. You will get more out of testing if you understand what the model is being asked to do at each tier, and you can adjust the wording to fit your own tasks.
Why coarse-to-fine planning makes sense
The author’s claim is that the plan gets written first, so it anchors the model’s logic. The final answer then has to fit inside that structure instead of wandering off. Models generate one token at a time, and every token they write becomes context for the next one. A plan that sits earlier in that context gives later tokens something solid to lean on.
That targets three common problems:
- Hallucinations, because the model commits to a logical skeleton before it starts improvising
- Structural drift, where a long answer slowly loses the thread of the original task
- Multi-step reasoning that falls apart somewhere in the middle of a long output
Here is a simple example of drift. You ask for a six-part guide with a consistent set of terms, and by part five the model has renamed two concepts and quietly dropped a constraint you gave at the start. A plan that fixed those terms and constraints up front gives the model something to check against as it writes.
The author also says the final output style stays the same. You get the planning benefit without the answer suddenly sounding like a robot reading notes.
One commenter compared it to sketching thumbnails before committing to a full illustration. That is a good mental model. You lock down the shape of the thing before you spend effort on polish, and changing a thumbnail is far cheaper than redrawing a finished piece.
The question worth asking
The sharpest comment in the thread came from u/Muted-Vermicelli-180. They asked whether anyone has compared the shorthand plan against a plain-language outline at the same token budget. Their suggested test was to check how often each version misses an exception that changes the answer.
That is the right test. Planning before answering is not new, and plain outlines already help. What matters is whether compressed shorthand gives you something a normal outline does not. A fair comparison needs the same task, the same model, and a similar amount of planning text in both cases. Otherwise you are only measuring which version thought longer. The post does not show that comparison yet, so I would not take the hallucination claims as settled.
Use cases
- Long structured documents where section 6 should still agree with section 1
- Multi-step analysis, like a migration plan or a research summary
- Code generation across several files, where the structure matters as much as the syntax
- Any task where you have watched the model start strong and end somewhere odd
How to test it yourself
Pick one task where your current prompts drift. A good candidate is something long with a few hard rules, such as a report that must follow a fixed format and mention specific constraints. Run it three ways with similar token budgets: no plan, a plain-language outline, and the NCM prompt. Then check the outputs for contradictions and missed edge cases.
Keep a short checklist before you start, so you are not judging by feel. Count things you can verify: how many of your stated rules each output followed, whether terms stayed consistent from start to finish, and whether any exceptions you planted in the task were handled. Run each version two or three times if you can, since a single lucky or unlucky run proves little. Ten minutes of this will tell you more than any claim in a post.
Call to action
Grab the prompt from the repo and run the three-way test on a task you actually care about. If the shorthand plan beats a plain outline, you have a useful tool. If it ties, you have still learned that a simple outline is enough. Either way, post what you find back in the thread, because the author and the commenters are clearly looking for exactly that data.
Frequently Asked Questions
Q: Does a shorthand planning phase beat a plain-language outline?
The post doesn’t include that comparison, so we don’t know yet. One commenter suggested testing both at the same token budget and counting how often each one misses an exception that changes the final answer. That’s a fair test, and it’s the best way to see whether the compressed format earns its keep.
Q: Why plan the logic before writing the final answer?
One reader compared it to sketching thumbnails before a full illustration: lock down the skeleton first, then add the flourish. The idea is that the model commits to the logical structure before the prose pulls it off track. Most prompts skip this step and go straight to the finished text, which is where drift and missed steps tend to creep in.
Q: How do I test it on my own tasks?
Pick a task where you already know the tricky exception, the one that flips the answer. Run it once with the planning phase and once with a plain outline of similar length, then check each output for that exception. Repeat across ten or so tasks before you decide, because a single run tells you very little.
NCM Simulation: Coarse-to-fine planning prompt for LLMs
by u/tkdeng in PromptEngineering