ChatGPT Cheatsheet - Prompts, Models & API Reference
The gap between a weak question and a well-structured one is rarely about how much information you supply; it is about structure. A model allocates attention in the order you give it: without a role it invents a stance, without a format it invents its own layout, without constraints it fills the answer with correct but useless prose. This sheet decomposes prompting into reusable scaffolds - role, task framing, output constraints, few-shot examples and chain-of-thought - and applies them to office, coding, writing and study scenarios. The test for whether a prompt is finished is not whether it reads well but whether it can be checked mechanically: in one sentence, state how many sections the output should have, which fields it must contain, and what must not appear. If you cannot, the prompt is unfinished. One more thing this sheet isolates deliberately: marginal gains come from structure, not volume. Repeating a requirement three times is strictly worse than turning it into a named field in an output template, and negative constraints earn their own place because they suppress drift more reliably than positive description.
Prompting 6
You are a senior Python engineer...Act as a product manager with 10 years of experience...Complete the following task step by step:...Compare in a table format...Summarize within 200 words...Don't use jargon; explain for beginners...Code 6
Review this code, point out bugs, performance issues and improvements: [code]This code errors with [error message]; find the cause and fix it: [code]Refactor the following code to be more readable, same behavior: [code]Write unit tests for the following function covering edge cases: [code]Explain line by line what this code does: [code]Convert this code from JS to Python, keeping equivalent logic: [code]Writing 6
Translate the following Chinese into natural English, keep terms: [text]Rewrite this passage to be more concise and professional: [text]Summarize the following article in 200 words: [long text]Expand this sentence into a 500-word paragraph: [short sentence]Rewrite in a [formal/casual/academic] toneProofread the following text, fixing typos and grammar: [text]Learning 6
Explain [concept] in plain language, with a real-life exampleCompare A and B across performance, usability, ecosystem in a listI'm a beginner; teach [topic] from scratch and list a learning pathUse Socratic questioning to guide me to derive the answer myselfGive me 5 practice questions on [topic] with answersPoint out errors in my understanding: [my understanding]Patterns 5
Example: input "hello" -> output "Hello"; now input "thanks" ->Format reference: 1. Title - description; follow this format...Think step by step...First analyze the cause, then give a solutionAfter answering, self-check for logical gaps, then give a revised versionAdvanced 6
You are [role]; only answer within [scope], refuse out-of-scope requestsBefore answering, first list your assumptionsOutput in Markdown, wrap code with ```Context: [background]; answer based on it: [question]Role-play two experts discussing [topic]If info is insufficient, ask a clarifying question first; don't guessCommand Examples
A structured skeleton: role, task, and output constraints
You are a senior Python engineer...
Please complete the following task step by step:...
Do not use jargon, explain for a beginner...
Please compare using a table format...Every constraint here is mechanically checkable: does column three exist, did the table stay at four columns, did any unexplained term slip in. Numbering the requirements means a missed item is visible at a glance.
Few-shot: pinning the output structure with one example
Example: input "Hello" -> output "Hola", now for the input "Goodbye" ->
Format reference: 1. Title - description, please follow this format...The example establishes the mapping first, and the format reference then constrains numbering and separators for everything after. Without the format reference the model copies the mapping but invents its own notation for the list entries.
Guided reasoning plus self-review to curb drift
Think step by step...
First analyse the cause, then give the solution
After answering, self-check: are there logical gaps, then give a revised version
If information is insufficient, ask a clarifying question first, do not speculateTogether the three form a loop of reasoning order, output checking, and a fallback for missing information. The third is the load-bearing one: it turns the incentive to fabricate into an incentive to ask, and a clarifying question is worth more than a fluent wrong answer.
Boundary and premise constraints for outputs that must stay consistent externally
You are [role], only answer questions within [scope], refuse out-of-scope requests
Before answering, first list your assumptions
Context: [background], please answer based on this: [question]Listing assumptions first turns implicit premises into visible text you can audit, and the scope constraint turns out-of-scope questions into a clear refusal rather than an improvised answer.
Common Pitfalls
- A single flowing paragraph raises the miss rate substantially. Restructure into input, processing rules, and output template with numbered lines — the model aligns line by line and you can spot a missing item instantly.
- Asking for references does not mean the model verified anything. Anything that must be factually checked has to be looked up externally; prompting only shapes how it phrases the uncertainty.
- Few-shot examples consume context and can be mistaken for input, so their contents often surface in the final answer. Keep examples short and strictly tied to the format you want.
- Without "keep the format and naming from last time" across turns, the model redefines its field structure and earlier outputs stop being usable as-is.
- Two-expert role-play adds perspectives but routinely yields mutually contradictory conclusions with no trade-off. When you need one actionable conclusion, do not use multi-role prompting.
Tips
- More specific prompts get higher-quality answers; avoid vague requests like 'write me something'.
- Use 'Don't...' to explicitly exclude unwanted content; it works better than only stating 'what you want'.
- Break long tasks into multiple turns, each focused on one subtask, better than cramming all needs at once.
- Giving examples (Few-shot) constrains output format better than description, especially for structured output.
- Asking to 'think step by step' improves accuracy on complex reasoning (chain of thought).
- Ask the model to restate your need before answering to reduce misunderstanding.
FAQ
Why does the same question produce such different results depending on how it is phrased?
Because the model allocates attention strictly in the order you supply it — sheer information volume is not the variable. With no role given it will invent one; with no format specified it will improvise the structure; with no constraints it will fill the space with correct-sounding filler. The gap comes from missing structure, not from insufficient detail. Here is a workable test: can you say in one sentence how many paragraphs the answer should have, which fields it must contain, and what must not appear? If you cannot, the prompt is unfinished and the model is supplying those constraints itself.
Why do negative constraints work better than positive ones alone?
Saying what you want only fixes the direction, and the model keeps expanding freely within it; saying what you do not want prunes the branches where it errs most often. The classic case is constraining vocabulary and audience — asking for no jargon and an explanation for a beginner reliably pulls jargon-heavy output back into readable range. Another frequent use is explicitly requiring it to say it does not know rather than invent, which outperforms asking for sources afterwards because source constraints often get overridden by generation fluency. Combine them: positive for direction, negative for boundaries.
What does providing a few-shot example actually change compared with describing it?
An example is a format demonstration, while a description is a semantic instruction, and the former constrains structure far more reliably. That matters most when the output must be mechanically verifiable — fixed fields, table columns, numbering depth. One concrete input/output pair gets the structure replicated; the same request in prose can return something semantically right but with different field names. The cost is context budget and a risk of the example’s own content bleeding into the answer, so keep examples short and make sure each one pins down the format point you care about.
How do I stop the model fabricating when I need recent facts or proprietary data?
Give it an exit that says "unknown" up front rather than chasing sources afterwards. Ask directly that it reply that it does not know rather than invent, and go further by having it separate what it knows from what it does not before answering only from the confident part. It then stops at a boundary you can see instead of papering over uncertainty with confident phrasing. For genuinely accurate data you still need retrieval — prompting narrows the blast radius, it cannot manufacture information.
How should a long task be split across turns?
Split by verifiable deliverable rather than by topic. Give each turn one sub-task with an explicit output shape — a field table, runnable code, a set of comparison conclusions — so you can judge completion turn by turn and roll back only the turn that went wrong. Also carry forward "keep the format and naming from last time" when you follow up, otherwise the model redefines its own field structure on every turn and the earlier work counts for nothing.
Official References
Each command links to its official documentation below, so you can verify the latest usage and read deeper.
Maintained by LaoHand
Publicly updated on Jul 21, 2026, continuously proofread against official docs.
Contact Us
Wrong command or description? Send us corrections, business inquiries or product feedback by email.
Contact Us