🧠Prompt Engineering for Devs
Writing effective rules and prompts
Rules = the law. Prompts = the task. Learn the difference before AI rewrites your entire codebase.
(Spoiler: "Make it better" is not a good prompt. Neither is "fix this". Be specific or suffer. 🔥)
When to use which
Prompts vs. Rules in Cursor
đź§
Rules: long-lived instructions (style, constraints, “never” clauses), auto-applied to every task.
Prompts: per-request guidance; lighter, situational, good for one-off tasks.
Combine: keep durable policies in rules; keep the prompt focused on the current change.
Durable guardrails
Cursor Rule Crafting
🛡️
Structure: Scope → Constraints → Style/Voice → Output format → Definition of Done.
Be explicit: mention files/paths, banned areas, and “never change” clauses.
Keep it lean: shorter, high-signal sentences avoid token waste and conflicts.
Conflict avoidance: prefer “Do X, Never Y” over vague preferences.
Reusable snippets: extract repeated asks (testing, logging, perf) into rules instead of prompts.
One-off, high signal
Cursor Prompt Crafting
✍️
State the goal first, then the constraints (files, patterns, edge cases).
Ask for diffs or summaries: “Show the patch” or “List files touched”.
Add acceptance criteria: tests to run, behaviors to verify, regressions to avoid.
Call out non-goals: what must stay unchanged, what to skip.
Prefer concise bullets over long prose; remove filler.
Rules depth
How this compares to other IDEs
🔀
Cursor: strongest persistent rules (workspace + folders), great for team-wide guardrails.
Copilot: primarily prompt/chat; “Spaces” can hold context but rules are thinner.
Continue.dev: config-driven context; rules live in providers/config, more manual.
Windsurf: Flows/context pinning; less durable rule system than Cursor.
Cody: code graph + enterprise policies; good context, but less granular per-folder rules.
JetBrains AI: strong IDE context; persistent instructions less granular than Cursor rules.
Apply and forget
Checklist for great rules
âś…
Name the scope (repo/folder) and call out protected files.
Declare style, formatting, and testing expectations.
Add “never” clauses for security, secrets, and destructive commands.
Keep each rule small and single-purpose to reduce conflicts.
Review rules periodically to remove outdated constraints.
Per-task clarity
Checklist for great prompts
⚡
Goal in one line; then list constraints/acceptance criteria.
Mention files and behaviors to touch or avoid.
Request the form of the answer (patch, steps, summary).
Ask for self-checks: “Did we break X? Did we keep Y?”
Trim fluff; keep only what affects the output.
Persistent context
Deep-dive: best practices (Rules)
🛡️
Project context first: name stack and key libs (e.g., React/TS + Redux + Tailwind).
Code standards: hooks over classes, prefer const, avoid magic strings, file size limits.
Do & Don’t: explicit “DO NOT use deprecated X”, “DO NOT add comments unless asked”.
Modularity: keep rules small (<500 lines), link to files (@file.ts) for precision.
Tone/behavior: define voice and expectation (concise, challenge assumptions, honest feedback).
One-off instruction
Deep-dive: best practices (Prompts)
✍️
Be specific: goal + why + files to touch; avoid vague asks.
Include intent: rename because of new feature, change behavior, or clarify naming.
Reference context: use @file or / command to target exact sources or rules.
Iterate: treat first reply as draft; refine with concrete follow-ups (e.g., add try/catch).
Role & lifespan
Rules vs Prompts at a glance
🧾
Rules = the law (persistent, project-wide); Prompts = the task (single interaction).
Rules live in .cursor/rules/*.mdc or User Rules; Prompts live in chat/Cmd+K.
Rules: standards, structure, “never” clauses; Prompts: change requests, debugging, Q&A.
Workflow & agentic power
Terminal (Claude Code) vs IDE
đź’»
Terminal/CLI (e.g., Claude Code): project-aware, agentic; can plan/apply multi-file changes, show diffs in terminal, you approve.
Great for bigger tasks: cross-file refactors, test generation, debugging larger codebases with lower cognitive load for you.
IDE (Cursor, Copilot, etc.): inline, visual, fast for small/mid changes; strong local context around cursor and open files.
IDE shines at instant completions, quick fixes, live previews; terminal shines at autonomous multi-step plans.
Strategy: keep durable rules in Cursor; for heavy refactors consider agentic CLI (Claude Code) to plan/execute with diffs you review.
Rules depth
How this compares to other IDEs
🔀
Cursor: powerful persistent rules (workspace + folders); versioned and shareable.
Copilot: mostly chat + implicit context; Spaces help but rules are thinner.
Continue.dev: config/providers; more manual to keep per-project rules.
Windsurf: flows/context pinning; less durable than Cursor rules.
Cody: code graph + enterprise policies; less granular per-folder rules.
JetBrains AI: strong IDE context; fewer granular persistent instructions.