Below is a practical “cheat‑sheet” distilled from the many production prompts you just saw (Cursor, v0, Devin, Manus, Replit, Lovable, etc.). Follow these guidelines when designing prompts for your own LLM‑powered apps and you’ll get more reliable, safer and higher‑quality results.
────────────────────────────────────────────────────────
- Nail the Three Core Elements
──────────────────────────────────────────────────────── A good prompt almost always contains ❶ role, ❷ objective, ❸ constraints / format.
• Role
“You are a senior Rust compiler engineer…”
Sets the persona, vocabulary and depth.
• Objective
“Explain the borrow‑checker to a 2‑year‑old.”
Focuses the model on the end goal.
• Constraints / format
“Answer in ≤ 80 words. Use exactly one code block.”
Eliminates ambiguity and enforces consistency.
────────────────────────────────────────────────────────
2. Be Concrete, not Abstract
────────────────────────────────────────────────────────
Bad ❌ “Give me a React component.”
Good ✅ “Create a React component named AvatarCard that shows a circular 96×96 px image (src prop), the user’s name in bold below, and fades in with Tailwind’s animate‐fadeIn class.”
Tip Whenever possible state:
• file names / ids you expect
• prop signatures or JSON schemas
• colour tokens, exact pixel sizes, env‑vars, etc.
────────────────────────────────────────────────────────
3. Provide Working Examples Inside the Prompt
────────────────────────────────────────────────────────
Almost every system prompt above embeds tiny exemplars:
Bad:
if val == True:
Good:
if val == False:
Show both the anti‑pattern and the solution; the model will mirror.
────────────────────────────────────────────────────────
4. Use Deliberate Structure Markers
────────────────────────────────────────────────────────
High‑end agents rely on invisible “markers” to stay organized:
• <Thinking> – model’s private scratchpad (Cursor, v0)
• <QuickEdit> – macro for small code patches (v0)
• <CodeProject> – bundle many files (v0)
• // ... existing code ... – placeholder that prevents accidental deletion (Cursor)
• JSON function‑calling schema (OpenAI) – forces valid output shapes.
Adopt the same idea: invent lightweight tags or fenced blocks that signal intent.
Example
### PLAN
1. Fetch RSS
2. Extract headlines
3. Summarize with gpt-4o
Later steps can reference PLAN without re‑explaining.
────────────────────────────────────────────────────────
5. Replace Vague Adverbs with Testable Assertions
────────────────────────────────────────────────────────
⚠︎ “quickly”, “elegantly”, “nicely” are untestable.
✅ “Run in < 200 ms on a 100 item list”, “≤ 15 CSS classes”, “pass the included jest tests”.
────────────────────────────────────────────────────────
6. Encourage Step‑by‑Step Reasoning Privately
────────────────────────────────────────────────────────
Many prompts instruct the model to think but not reveal:
<!-- internal -->
<think>
Work out dimensions first.
</think>
<!-- end -->
If you don’t have hidden channels, ask the model to think first, then answer:
“First reason silently, then output
ANSWER:followed by your result.”
Helps decomposition without leaking chain‑of‑thought to users.
────────────────────────────────────────────────────────
7. Ask for Clarification Early
────────────────────────────────────────────────────────
Cursor & Manus agents automatically stop and ask when parameters are missing.
Build that into your prompt:
“IF any required arg is undefined, ask the user Which city? and halt.”
────────────────────────────────────────────────────────
8. Enumerate Refusal / Safety Rules Up‑Front
────────────────────────────────────────────────────────
The v0 prompt defines a single REFUSAL_MESSAGE and forbids apologies.
Include your own guardrails:
• disallowed topics
• privacy red lines
• forced canned reply
────────────────────────────────────────────────────────
9. Couple Prompts with Tool Schemas
────────────────────────────────────────────────────────
All modern agents expose tools as JSON. Model knows exact keys, types, and when to call.
Design tip
Write your schema first, then craft the prompt that references it:
“ALWAYS respond with either a tool call or a
final_answer.”
Example output
{
"name": "search_web",
"arguments": { "query": "ACME share price", "date_range": "past_day" }
}────────────────────────────────────────────────────────
10. Echo Unusual Tricks from the Samples
────────────────────────────────────────────────────────
• Pop‑Quiz Override – temporary instructions supersede all previous ones.
Use when you need a one‑off behaviour change.
• Cursor’s // ... existing code ... – brilliant for granular diffs; adopt in any “patch” workflow.
• v0’s NodeJS executable blocks – instruct the model where code should run vs merely display.
• Tool‑driven self‑limiting – “Use at most one edit_file call per turn.”
Builds throttling right into the prompt.
• Citation placeholders – [ ^1 ] references force the model to ground answers.
────────────────────────────────────────────────────────
11. Keep a Living “Policy” Section
────────────────────────────────────────────────────────
Notice how every system prompt bundles communication, proactiveness and data‑integrity policies. Maintain your own central policy snippet and prepend it to every user‑level prompt so the assistant remembers house rules.
────────────────────────────────────────────────────────
12. Iterative Prompting Beats One‑Shot
────────────────────────────────────────────────────────
Almost all agents use an agent loop: observe → think → act → observe.
Even if you’re not building a full agent, you can mimic:
1 / Draft → 2 / Review & critique → 3 / Refine.
Ask the model to self‑evaluate:
“Critique your answer in 3 bullet points, then improve it.”
────────────────────────────────────────────────────────
13. Prefer Declarative over Imperative
────────────────────────────────────────────────────────
Instead of “First do X, then Y, then Z”, state what success looks like:
“Return JSX that renders a button, colour =
primary, size =lg, no external CSS files.”
The model decides the steps, which scales better to unseen tasks.
────────────────────────────────────────────────────────
14. Match User’s Language & Technical Level
────────────────────────────────────────────────────────
Replit prompt enforces “use simple, everyday language.”
Your prompt can embed a variable like {audience} and pass “non‑technical CEO” vs “kernel hacker”.
────────────────────────────────────────────────────────
15. Version & Time‑Stamp Your Prompts
────────────────────────────────────────────────────────
Manus adds <current_time>; v0 notes tech versions (Next 15).
Recording these prevents answers based on outdated assumptions.
──────────────────────────────────────────────────────── EXAMPLE MASTER PROMPT TEMPLATE ────────────────────────────────────────────────────────
## ROLE
You are {role}. Follow company policy v1.3.
## OBJECTIVE
{goal}
## OUTPUT FORMAT
Return JSON matching schema:
{
"summary": string,
"next_steps": string[]
}
## CONSTRAINTS
- ≤ 120 words in summary
- Use citations like [^1] if factual
- If info missing, ask exactly one clarification question and stop.
## TOOLS
See attached OpenAPI; respond with tool calls when relevant.
## SAFETY
If request violates policy §3, reply REFUSAL_MESSAGE.
## EXAMPLES
User: "ping"
Assistant: {"summary":"pong","next_steps":[]}
Plug concrete role, goal, examples, and you’re ready.
────────────────────────────────────────────────────────
Bottom Line
────────────────────────────────────────────────────────
High‑quality prompts are contracts: they establish identity, success criteria, boundaries and tooling rules. Borrow the structure, markers and safety patterns from industrial agents above, and your own applications will gain stability, clarity and trustworthiness.