Code-generation Prompt Cheatsheet & Best Practice

Code generation differs from prose because the output has to compile and run, and the characteristic failure is not malformed syntax but plausible-looking code that is semantically wrong. A useful prompt therefore settles four things at once: the task and the minimum real context, pasted as actual snippets rather than adjectives; the constraints that must not bend, covering language, framework version, style and the files that are off limits; the contract, meaning signatures, return types and error semantics; and acceptance criteria written so that a human or a test can decide pass or fail, including boundary and error paths. Asking for a plan before the code catches misunderstandings early. The smallest-change rule is what keeps review feasible and regressions rare. Sections here cover requirement and context, constraints and contracts, boundaries and tests, acceptance and delivery, and the traps worth avoiding. State the acceptance criteria in a form a test could assert, which also tells the model which failure modes matter and which are irrelevant to this change.

AI Prompts·25 commands·Last updated 2026-08-23

Requirement & Context 5

Task: {do X}. Context: {existing structure/deps}.

Task + context in one shot

Relevant code:
```{lang}
{code}
```

Paste snippets to cut ambiguity

Target file/func: {path#func}; change only what is needed

Scope the edit

Do not refactor unrelated code; minimal diff

Limit scope

Explain the approach before code

See the plan first

Constraints & Contract 5

Lang/framework/version: {TS 5 + Nuxt 4}; follow {style guide}

Explicit tech constraints

Signature must be: {in type} → {out type}; no undeclared throws

Signature contract

No new deps; reuse existing utils

Dependency constraint

Naming per {project convention}; no emoji/abbrev

Style consistency

Support {Node 20+ / latest 2 browser versions}

Runtime constraint

Edge & Tests 5

Handle edges: {empty/overlong/invalid type/concurrency}

Edge checklist

Give 3 unit tests (incl. one exception path)

Normal + exception coverage

On invalid input, return {clear error}, not a crash

Error-handling contract

Mind {perf/memory} limits; state complexity

Perf awareness

Flag likely failure points and fallbacks

Robustness hint

Acceptance & Delivery 5

Acceptance: {passes X test / output matches Y}

Checkable acceptance

Give a usage example with expected output

Example is docs

Note integration points with existing code

Integration hint

List uncovered risks or assumptions

Transparent assumptions

If cannot fully satisfy, state the trade-off first

Honest degradation

Pitfalls 5

Full context beats long prose

Paste code over adjectives

Pin signature/contract to stay on track

Clear boundaries

Ask for tests, esp. exception paths

Exceptions get missed

Minimal-diff principle

Don't refactor along the way

Make acceptance checkable

Vague fails acceptance

Command Examples

The full four-part brief: context, contract, edges, acceptance

Task: implement X. The existing code structure and dependencies are as follows.
Target file/function: {path#func}; change only what is necessary and do not refactor unrelated code.
Language/framework/version: {TS 5 + Nuxt 4}, following {styleGuide}.
Required signature: {input type} -> {return type}, with no undeclared exceptions.
Do not introduce new dependencies; reuse the existing helper functions.
Edge cases to handle: {empty / oversized / invalid type / concurrency}; on invalid input return {a defined error} rather than crashing.
Acceptance criteria: {passes test X / output matches Y}, and include a usage example with its expected output.

This delivers in one shot the four things that matter: minimal real context, a decidable contract, an explicit edge-case list, and acceptance criteria you can check. The minimal-change principle keeps the regression surface small.

Test requirement: three unit tests, one on an exception path

Provide three unit tests, one of which must cover an exception path.
On invalid input, return {a defined error} rather than crashing.
Consider the {performance/memory} bound and state the complexity.
Call out the likely failure points and their fallbacks.

Exception paths appear only if you name them; requiring defined error semantics and a complexity statement together is what makes the result mergeable.

Plan first: approach before implementation, with integration points and risks

Explain your approach before writing code.
State how this integrates with the existing code.
List the risks or assumptions that remain uncovered.
If you cannot fully satisfy this, explain the trade-off first.

Together these turn a code drop into a reviewable change description, and the last line stops a partial delivery from being reported as complete.

The usage example is the documentation

Give a usage example together with its expected output.
The relevant existing code is:
{code}
Target file/function: {path#func}; change only what is necessary.

Concrete input-to-output samples cause less rework than format descriptions such as "return JSON", and the real snippet steers the model toward your existing style and helpers.

Common Pitfalls

Describing the current state with adjectives such as the structure is messy and no real snippet: the model guesses, and guesses drift.
Omitting the signature and error-semantics contract, so the generated code invents its own parameter order and exception types and every caller has to change.
Listing no edge cases and never naming an exception path, which leaves the test suite with happy paths only and the riskiest branch uncovered.
Failing to list untouchable files and the minimal-change principle, so unrelated code gets refactored and the pull request balloons.
Writing acceptance as high code quality, which nobody can adjudicate: the gap surfaces at delivery, when rework is most expensive.

Tips

The core of code-gen prompts is handing over task, context, constraints, and acceptance in one shot — pasting relevant code cuts ambiguity better than adjectives.
Explicit language/framework/version constraints + a function-signature contract pull the model from "free improvisation" back to "implement to spec".
Edges and tests (especially exception paths) get missed most — list an edge checklist and demand unit tests to raise usability sharply.
Minimal-diff principle + checkable acceptance make generated code easy to review and merge.

FAQ

Why does pasting real code beat describing it in adjectives?

The model can only work from what you give it: "the existing structure is messy" tells it nothing, while the actual snippet shows the callers, the names of existing helpers, and the house style. Naming the target file and function and asking for changes only where needed concentrates the ambiguity in the one place that genuinely needs a decision instead of scattering it everywhere.

How do I stop generated code that looks right but will not integrate?

Pin the contract. State the signature as input type to return type with no undeclared exceptions; forbid new dependencies and require reuse of existing helpers; give the naming convention; spell out the runtime target (Node 20+, or the last two browser versions); and list the files that must not change together with the signatures callers depend on. Otherwise the model renames a public function or reaches for a library you never approved.

How should I ask for edge cases and tests?

List the edge cases yourself (empty input, oversized input, invalid types, concurrency), require three unit tests with at least one on an exception path, and specify that invalid input returns a defined error rather than crashing. Also ask for a complexity note against a performance or memory bound, and for the failure points plus their fallbacks. Exception paths are the most commonly skipped, and if you do not name them in the prompt they will not appear in the tests.

Why is asking it to restate the requirement before coding worth the extra step?

Ambiguity surfaces at that step, which is far cheaper than discovering it after generation. Asking for the approach before the code works the same way: you can reject a wrong direction before reading an implementation. Adding a clause that it should explain any trade-off if it cannot fully satisfy the ask turns a silent half-delivery into a stated degradation with its cost.

What makes an acceptance criterion actually decidable?

Express it as a specific test that can pass or a specific output to compare against, never as high code quality. Pair it with a usage example and its expected result, ask where the change integrates with the existing code, and require the uncovered risks or assumptions to be listed. Writing the expected output as a concrete sample saves far more rework than describing the format in words.

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 Aug 23, 2026, continuously proofread against official docs.

Contact Us

Wrong command or description? Send us corrections, business inquiries or product feedback by email.