AI Coding Prompt Master Guide by DeepSeek v4 Pro
# 🧠 AI Coding Prompt Master Guide
## How to Get the Most Done in a Single Prompt — Every Time
—
## 1. THE MASTER PROMPT TEMPLATE
Copy and fill out this template every time you ask an AI to build something. The more fields you complete, the less back-and-forth you’ll waste.
“`
## ROLE
You are a [senior/staff] [language/framework] engineer. Be concise, correct, and complete.
## OBJECTIVE
[One sentence: what should exist when this is done?]
Example: “A working Express API endpoint that creates a user, validates input, and writes to PostgreSQL.”
## TECH STACK (locked)
– Language: [TypeScript 5.x / Python 3.12 / Rust / etc.]
– Runtime: [Node 20 / Deno / etc.]
– Framework: [Express / FastAPI / Next.js App Router / etc.]
– Database: [PostgreSQL 16 / SQLite / MongoDB 7 / etc.]
– ORM: [Drizzle / Prisma / SQLAlchemy / none]
– Testing: [Vitest / pytest / etc.]
– Styling (if UI): [Tailwind / CSS Modules / etc.]
– State (if UI): [Zustand / Context / Redux / etc.]
## EXISTING PROJECT CONTEXT
– File structure rule: [e.g., `src/features/[name]/` pattern]
– Naming conventions: [kebab-case files, PascalCase components, camelCase functions]
– Key dependencies already installed: [list them]
– Relevant existing files: [paths to 2-5 files the AI should know about]
## REQUIREMENTS
### Functional
– [ ] [Requirement 1 — be specific: “POST /api/users accepts { email, password, name }”]
– [ ] [Requirement 2]
– [ ] [Requirement 3]
### Non-Functional
– [ ] Type safety (no `any`, no `as` casts)
– [ ] Error handling for every failure mode
– [ ] Input validation on all external boundaries
– [ ] Tests for happy path + 2 edge cases minimum
– [ ] No console.log — use proper logger
## OUTPUT FORMAT
– Output COMPLETE files only — never partial snippets
– Prefix each file with its path: `## file: src/foo/bar.ts`
– Use “`language fences for each file
– Order outputs by dependency (types → utils → services → routes → tests)
## CONSTRAINTS
– DO NOT: [list things the AI must avoid — e.g., “use classes”, “add new dependencies”]
– DO: [list things the AI must do — e.g., “use early returns”, “prefer pure functions”]
– Maximum files: [N] (optional — prevents sprawl)
– Target: production-ready, not prototype
## EXAMPLES (Optional but powerful)
[Paste 1-2 examples of similar code already in your codebase so the AI matches style]
“`
—
## 2. PRE-PROMPT CHECKLIST (Do These BEFORE You Type)
Complete as many as possible before sending your prompt. Each one saves 1-3 follow-up messages.
| # | Item | Why It Saves Tokens |
|—|——|———————|
| 1 | **Pin your tech stack versions** | Prevents “which version of X?” back-and-forth |
| 2 | **Define file structure rules** | AI won’t invent its own organization |
| 3 | **Link or paste 1-2 existing files** | AI matches your exact style/conventions |
| 4 | **List what NOT to do** | Prevents the AI’s favorite over-engineering patterns |
| 5 | **Specify error-handling philosophy** | Avoids try/catch vs Result type debates |
| 6 | **State “complete files only”** | No partial snippets you have to stitch together |
| 7 | **Set a max file count** | Prevents 15-file monolith when you wanted 3 |
| 8 | **Define the acceptance test** | “This should work when I run `npm test`” — AI will ensure it |
—
## 3. TECHNIQUES TO MAXIMIZE OUTPUT PER PROMPT
### A. The “Vertical Slice” Rule
Instead of saying “build me authentication,” say:
> “Build the login endpoint end-to-end: database migration → model → validation → service → controller → tests → API docs comment. Output every file.”
This forces the AI to deliver a **working, complete feature** rather than one layer you can’t use yet.
### B. Stack Requirements as a Checklist
AI models process checklists more thoroughly than paragraphs. Always use:
“`
– [ ] Requirement 1
– [ ] Requirement 2
“`
…instead of prose bullets. The model treats checkbox items as a contract.
### C. Use T-Shirt Sizing for Scope
Add one line to set expectations:
“`
SCOPE: S | M | L | XL
– S = 1-2 files, minimal logic
– M = 3-5 files, full CRUD
– L = 6-10 files, with auth + tests + docs
– XL = feature suite with multiple endpoints
“`
### D. The “Negative Space” Prompt
Explicitly list what you DO NOT want. This eliminates the AI’s default bad habits:
“`
DO NOT:
– Add comments that explain obvious code
– Use try/catch for control flow
– Default-export anything
– Create barrel/index files unless asked
– Add ‘just in case’ abstractions
“`
### E. Seed with Your Own Code Style
Paste 20-30 lines of a well-written file from your project. Say: “Match this style exactly — same import ordering, same error pattern, same type naming.”
### F. Specify the Delta, Not the Whole
When modifying existing code, use this exact format:
“`
## TARGET FILES (only touch these)
– src/services/user.service.ts (lines 45-120)
– src/routes/user.routes.ts (add 1 new route)
## CHANGES
1. In user.service.ts: Add password hashing before DB insert
2. In user.routes.ts: Add PATCH /api/users/:id/email endpoint
“`
### G. Request a “Validation Script”
End your prompt with:
> “After outputting code, give me a 5-line bash script that runs the tests and starts the app so I can verify everything in one command.”
This ensures the AI verifies its own work internally.
—
## 4. PROMPT PATTERNS BY TASK TYPE
### Pattern A: New Feature (Full Stack)
“`
ROLE: Full-stack TypeScript engineer
OBJECTIVE: Add a “team invitations” feature
TECH STACK: [locked]
DELIVERABLES: [5-8 files checklist]
OUTPUT: Complete files, ordered by layer
SCOPE: M
“`
### Pattern B: Bug Fix
“`
ROLE: Debugging specialist
OBJECTIVE: Fix [specific bug description]
CURRENT BEHAVIOR: [what happens now]
EXPECTED BEHAVIOR: [what should happen]
SUSPECT FILES: [2-3 file paths]
CONSTRAINT: Only change the suspect files; do not refactor unrelated code
“`
### Pattern C: Refactor
“`
ROLE: [language] engineer specializing in clean architecture
OBJECTIVE: Refactor [file/module] to [target pattern]
CURRENT PATTERN: [what it does now]
TARGET PATTERN: [repository pattern / adapter pattern / etc.]
NON-NEGOTIABLES:
– All existing tests must pass unchanged
– Public API signatures must stay identical
– No new dependencies
“`
### Pattern D: Code Review / Improvement
“`
ROLE: Principal engineer doing a code review
OBJECTIVE: Review [file paths] for bugs, performance, and maintainability
OUTPUT FORMAT:
1. Critical issues (will cause bugs)
2. Performance concerns
3. Maintainability suggestions
4. Refactored code for each suggestion (complete files)
“`
### Pattern E: Test Suite Generation
“`
ROLE: QA engineer
OBJECTIVE: Write tests for [file/module]
TEST FRAMEWORK: [locked]
COVERAGE TARGETS:
– All public functions: happy path + null/undefined + error state
– Edge cases: empty arrays, boundary values, concurrent calls
OUTPUT: Complete test files that pass on first run
“`
—
## 5. THE “META-PROMPT” — TEMPLATE OF TEMPLATES
Keep this short version saved in your notes app. Paste it first, then fill the blanks:
“`
## SPEC
**Goal:** [one sentence]
**Stack:** [lang + framework + DB]
**Scope:** S | M | L | XL
## FILES TO CREATE/MODIFY
– [ ] [path] — [purpose]
– [ ] [path] — [purpose]
## RULES
– Match existing code style in [reference file path]
– Complete files only — no snippets
– No new dependencies | No console.log | No `any`
– Every function handles errors at boundaries
– Tests: happy path + 2 edge cases minimum
## OUTPUT
All files prefixed with `## file: [path]`, ordered by dependency.
“`
—
## 6. ANTI-PATTERNS (What Wastes Prompts)
| Anti-Pattern | Fix |
|—|—|
| “Build me a blog” (too vague) | “Create a Next.js App Router blog with MDX posts, tag filtering, and RSS feed” |
| Skipping tech stack versions | Always pin: “Node 20, React 18.3, Tailwind 3.4” |
| Letting AI choose patterns | State: “Use repository pattern”, “Use Zod for validation” |
| Not providing error examples | Show: “When the DB fails, return this exact shape: `{ error: string, code: number }`” |
| “Make it good” | Define good: “Passes lint, types check, tests pass, handles null inputs” |
| Asking for one layer at a time | Ask for the vertical slice — all layers at once |
| Not capping output size | Say: “Maximum 5 files” or AI will generate 20 |
—
## 7. PROMPT CHAINING STRATEGY
When a task is too big for one prompt, chain them like this:
“`
PROMPT 1: “Output ONLY the data model + DB migration. Nothing else.”
PROMPT 2: “Using the model from the previous output, build the service layer + validation.”
PROMPT 3: “Using the service from the previous output, build the REST endpoints + tests.”
“`
**Rule:** Each prompt must produce something you can independently verify. Never chain “build X” → “now build Y on top” without testing X first.
—
## 8. QUICK-START CHEAT SHEET
Print this or keep it in a pinned tab:
—
### ✅ THE 60-SECOND PROMPT BUILDER
Fill in the blanks, paste, send:
“`
You are a senior [LANG] engineer.
BUILD: [one-line goal]
STACK: [lang] [version] + [framework] + [database]
FILES TO CREATE:
– [ ] [path] — [what it does]
RULES:
– Match style of [reference-file.ts]
– Complete files only
– Handle: null, error, empty, and happy path
– No [list forbidden patterns]
OUTPUT: Complete files prefixed with `## file: [path]`
“`
—
### 🚀 POWER-USER ADD-ONS (Add to any prompt)
| Add-on | Effect |
|——–|——–|
| “Output a `run.sh` that installs deps, runs tests, and starts the app” | One-command verification |
| “Add `// TODO:` comments for anything you’re unsure about” | Flags ambiguity instead of guessing |
| “Generate the OpenAPI/Swagger doc for these endpoints” | Free documentation |
| “Create a `README.md` section showing how to use this feature” | Onboarding docs built-in |
| “Write a migration script if schema changed” | DB changes are production-ready |
| “Add rate-limiting and input sanitization” | Security baked in |
| “Output a checklist of manual tests I should run” | QA guide included |
—
### 📏 OUTPUT SIZE CONTROL
| You Say | You Get |
|———|———|
| “Maximum 3 files” | ~200-400 lines total |
| “Maximum 6 files” | ~400-800 lines total |
| “Maximum 10 files” | ~800-1500 lines total |
| No cap specified | Unpredictable — could be 25+ files |
—
*Last updated: August 2026*
*Purpose: Turn every AI coding prompt into a single-shot delivery*
Coding AI Prompt Toolkit by DeepSeek v4 Flash
# ⚡ Coding AI Prompt Toolkit
### The items, structures, and instructions for getting maximum work done in a single AI prompt
> **How to use this file:** This is a copy-paste builder, not a reading document.
> Open it every time you prompt an AI for coding help. Grab the **Master Template (Part 1)**, fill in the sections, pick a few **Reusable Clauses (Part 3)**, match your **Task-Type (Part 4)**, and send.
> A 5-minute prompt here saves 3–5 follow-up prompts later.
—
## Part 0 — The Golden Rule
Every great prompt answers **5 questions** in the first 30 seconds of AI reading:
| # | Question | Section it maps to |
|—|———-|——————-|
| 1 | Who are you (in the AI)? | ROLE |
| 2 | What are we building or fixing? | THE TASK |
| 3 | Under what conditions? | CONSTRAINTS |
| 4 | What does “done” look like? | DEFINITION OF DONE |
| 5 | How should the answer be delivered? | DELIVERABLES |
**If a section is empty, the AI will guess. Guesses cost you follow-up prompts.**
—
## Part 1 — The Master Prompt Template
Copy this whole block into any AI chat. Fill in every section. Delete ones that don’t apply. Keep all the headers — they force you to be specific.
“`markdown
═══════════════════════════════════════════════════════
## ROLE
You are a [senior / staff] [frontend / backend / full-stack /…]
engineer who is an expert in [languages/frameworks, e.g. React,
Node.js, TypeScript, SQL]. You write clean, production-quality
code and you finish entire tasks without stopping.
## PROJECT CONTEXT
– What the project is: [e.g. a small expense-tracker web app]
– Current state: [e.g. exists, works locally, no tests / brand new]
– Key files and what they do: [list actual file paths]
– Tech stack & versions: [e.g. React 18, Vite, Tailwind 3, Node 20]
– How it’s run: [exact command, e.g. `npm run dev`]
– Relevant background: [anything the AI cannot see, e.g.
“data is stored in localStorage, no backend yet”]
## THE TASK
[BUILD / ADD / FIX / REFACTOR / REVIEW / EXPLAIN] [one clear,
unambiguous sentence describing exactly what you want].
## REQUIREMENTS (numbered = nothing gets missed)
1. [must-have behavior #1]
2. [must-have behavior #2]
3. [must-have behavior #3]
4. …
## CONSTRAINTS
– No new dependencies unless [condition, e.g. “absolutely required”]
– Must keep working: [commands / features that must not break]
– Max complexity: [e.g. “keep it simple, no premature abstraction”]
– Platform/browser/target: [e.g. “must work in Chrome and Edge”]
– Time to run: [e.g. “page must load under 2s”]
## STYLE & CONVENTIONS
– Language/idioms: [e.g. TypeScript strict mode, React hooks only]
– Naming: [e.g. camelCase, descriptive, no abbreviations]
– Comments: [e.g. only explain WHY, never WHAT]
– File organization: [e.g. one component per file]
– Errors: [e.g. user-friendly messages, no raw console crashes]
## EDGE CASES TO HANDLE
– [e.g. empty list state]
– [e.g. extremely long input]
– [e.g. user clicks submit twice fast]
– [e.g. file missing / API fails]
## DEFINITION OF DONE (make these testable)
– [ ] [e.g. Running `npm run dev` opens the app]
– [ ] [e.g. Adding an expense updates the total correctly]
– [ ] [e.g. Refreshing the page keeps saved data]
– [ ] [e.g. All inputs validated; bad data shows a message]
## OUT OF SCOPE (what NOT to do)
– Do NOT [add auth / build a backend / redesign the UI / …]
– Do NOT [use X library / over-engineer / write tests for …]
## DELIVERABLES
– Files to create or modify: [exact paths, e.g.
`src/App.jsx`, `src/components/ExpenseForm.jsx`]
– Answer format: [e.g. all code, complete files, then run
instructions, then a short summary]
– Include: [what you want in the reply, e.g. “the full file
contents, the npm command to test it, and list of changed files”]
## VERIFY YOUR WORK BEFORE FINISHING
– Run or mentally trace: [specific checks]
– Report at the end: (1) what you changed and why, (2) how to
run/test it, (3) any assumptions you made, (4) any warnings or
trade-offs I should know about.
═══════════════════════════════════════════════════════
“`
—
## Part 2 — The Item Catalog (what each section is for & why it saves prompts)
| Item | What to put in it | Why it saves you prompts |
|——|——————-|————————–|
| **ROLE** | Expertise level + exact tech | The AI uses idioms and patterns of that “persona”. Wrong/no role = generic beginner-level code |
| **PROJECT CONTEXT** | What exists, file paths, stack, how to run it | The AI cannot see your screen. 3 sentences of context replaces 5 “actually, the file is at…” corrections |
| **THE TASK** | One unambiguous sentence | Prevents the AI from solving a different problem than you meant |
| **REQUIREMENTS** | Numbered, specific behaviors | Numbered lists force completeness — AI won’t skip item #4 if it’s a number |
| **CONSTRAINTS** | Limits: deps, platform, performance, complexity | Prevents the AI from “helpfully” rewriting your whole stack |
| **STYLE & CONVENTIONS** | How the code should *look* | Your codebase stays consistent; no “fix that later” cleanups |
| **EDGE CASES** | Failure/empty/unusual inputs | The #1 reason apps break. Telling the AI about them prevents bug-report follow-ups |
| **DEFINITION OF DONE** | Testable checkboxes | Gives the AI a self-check target; turns “I think it works” into “it provably works” |
| **OUT OF SCOPE** | Explicit “do NOT” list | Stops scope-creep detours that waste the prompt |
| **DELIVERABLES** | File paths + answer format | You get exactly usable output, not a lecture |
| **VERIFY YOUR WORK** | Self-review + final report | The AI double-checks itself and tells you what it did — no “wait, what did you change?” |
—
## Part 3 — Reusable Clauses (copy-paste exactly what you need)
Mix and match these into any prompt. They’re the “Lego bricks.”
### 🧠 1. The Plan-First Clause
“`markdown
Before writing any code: list the files you will create or modify,
and the order you will work in. Show this plan, then implement it.
Do not skip steps or jump around.
“`
### 🏁 2. The One-Sitting Clause *(use on almost every prompt)*
“`markdown
Complete the ENTIRE task in this single response. Do not stop to
ask for confirmation. Do not leave TODOs. Do not say “the rest is
straightforward.” Do all of it now.
“`
### 📄 3. The Complete-File Clause
“`markdown
Whenever you create or edit a file, output the COMPLETE file
content — never fragments, never “…rest unchanged,” never “import
the same as before.” I will paste files exactly as you send them.
“`
### ✅ 4. The Self-Review Clause
“`markdown
After implementing, review your own work for: bugs, missing edge
cases, security issues, performance problems, and consistency with
the rest of the project. Fix everything you find BEFORE showing me
the final result.
“`
### 🧪 5. The Test Clause
“`markdown
Write [unit / integration] tests for the core logic. They must run
with exactly this command: [e.g. `npm test`]. Include at least one
test per edge case listed above.
“`
### 🔐 6. The Security Clause
“`markdown
Apply security best practices throughout: validate and sanitize all
input, use parameterized queries, never hardcode secrets, escape
output, and avoid unsafe [eval / innerHTML / shell commands].
“`
### ⚡ 7. The Performance Clause
“`markdown
Keep the code efficient: avoid [O(n²) loops / unnecessary
re-renders / repeated database or API queries]. Add memoization,
caching, or lazy-loading only where it actually helps.
“`
### 📖 8. The Explain-It Clause *(end every prompt with this)*
“`markdown
After the code, give me EXACTLY this, in this order:
1. A 2–3 sentence summary of what you did
2. The exact command(s) to run/test it
3. A list of every file created or changed
4. Any assumptions or decisions you made where I was ambiguous
5. Any risks, limitations, or recommended next steps
“`
### 🚦 9. The Keep-Moving Clause
“`markdown
If you hit a small ambiguity, pick the most sensible default, note
it in your summary, and keep going. Only stop me if a decision
would change the whole architecture or if information is truly
impossible to infer.
“`
### 📋 10. The Paste-Code Clause *(for bugs, use instead of describing)*
“`markdown
Here is the code for [file] — read it fully before answering:
[PASTE FULL FILE]
“`
—
## Part 4 — Task-Type Recipe Cards
Each card lists the **extra sections** to add to the Master Template for that task type.
### 🏗️ BUILD a new app / script / tool
Add to the template:
“`markdown
## WHAT IT LOOKS LIKE
– Screens / views: [e.g. home, form, settings]
– Main actions a user can take: [3–5 bullets]
– First-run experience: [e.g. empty state with a “get started” button]
## DATA
– What data is stored: […]
– Where/how: [localStorage / JSON file / SQLite / API]
– Data shape (fields): [e.g. {id, title, date, amount}]
## RUN INSTRUCTIONS REQUIRED
– Start with zero setup beyond: [e.g. `npm install && npm run dev`]
“`
### 🐛 FIX a bug
Add to the template:
“`markdown
## CURRENT BEHAVIOR (what happens now)
[exact steps to reproduce + paste the full error message]
## EXPECTED BEHAVIOR (what should happen)
[one clear sentence]
## STEPS TO REPRODUCE
1. [do this]
2. [do this]
3. [this goes wrong]
## WHAT I ALREADY TRIED
[things you tested so the AI doesn’t repeat them]
## ROOT CAUSE REQUIRED
Find the actual root cause — do not patch the symptom. Explain
WHY it’s happening in one or two sentences, then fix it.
“`
### ✨ ADD a feature
Add to the template:
“`markdown
## WHERE IT PLUGS IN
– Existing files to touch: [paths]
– Entry point / trigger: [e.g. button in App.jsx header, route /settings]
– Reuse: [any existing components/helpers it should use]
## BEHAVIOR SPEC
– What happens step-by-step when the user uses it: [4–6 bullets]
– What must NOT change: [existing behaviors to leave alone]
“`
### 🧹 REFACTOR / CLEAN UP
Add to the template:
“`markdown
## GOALS
– Why refactoring: [readability / speed / removing duplication / preparing a feature]
– Files in scope: [paths or “investigate and tell me”]
– Behavior that MUST stay identical: [all of it / list exceptions]
## DELIVERABLE AS PART OF THE REFACTOR
– Before/after file list
– A note on anything you deleted or moved
– Verification: [commands to prove nothing broke]
“`
### 🔎 REVIEW existing code
Add to the template:
“`markdown
## FOCUS AREAS (priority order)
1. [bugs & correctness]
2. [security]
3. [performance]
4. [readability & maintainability]
5. [tests]
## RESPONSE FORMAT
Give me a numbered list ranked by severity: [CRITICAL → MINOR].
For each: the file/line, the problem, why it matters, and the
exact fix. End with: things that are GOOD and should stay.
“`
### 📚 EXPLAIN / TEACH a concept
“`markdown
## LEVEL
Explain at [beginner / intermediate / advanced] level.
## FORMAT
1. One-paragraph plain-English summary (no jargon)
2. A concrete code example showing it
3. A “why it matters / when to use it” section
4. 2–3 common mistakes people make with it
5. One small exercise I can do to practice it
“`
—
## Part 5 — Full Worked Example (see all pieces combined)
This is what a complete, one-shot prompt looks like. Copy this pattern.
“`markdown
## ROLE
You are a senior full-stack engineer, expert in React 18,
TypeScript, Vite, and Tailwind CSS. You write production-quality
code and complete full tasks without stopping.
## PROJECT CONTEXT
– Project: a personal expense tracker web app, currently a bare
Vite + React + TS template with Tailwind installed.
– No backend. All data lives in localStorage.
– Existing files: `src/App.tsx` (renders a placeholder),
`src/index.css`, `vite.config.ts`.
– Run with: `npm run dev`.
## THE TASK
BUILD a complete expense tracker with add, list, filter by
category, monthly total, and persistent storage in localStorage.
## REQUIREMENTS
1. Add an expense form: name, amount, category, date.
2. Show a list of expenses sorted newest first.
3. Filter by category dropdown and a text search box.
4. Show the total for the currently filtered view.
5. Persist everything in localStorage; data survives refresh.
6. Show a friendly empty state when no expenses exist.
## CONSTRAINTS
– No new npm dependencies.
– TypeScript strict mode; no `any`.
– Must work in Chrome and Edge.
– Keep components small: one component per file.
## STYLE & CONVENTIONS
– Function components with hooks only — no classes.
– camelCase naming, descriptive names.
– Comments only where the WHY isn’t obvious.
– Reusable pieces go in `src/components/`.
## EDGE CASES TO HANDLE
– Empty input or amount of 0 / negative.
– Duplicate category values.
– Malformed data already in localStorage (corrupt JSON).
– Search that matches nothing.
## DEFINITION OF DONE
– [ ] `npm run dev` starts the app with no errors
– [ ] Adding an expense updates the list and total immediately
– [ ] Refresh keeps all data
– [ ] Clearing the filter shows all expenses again
– [ ] Each edge case above handled without crashing
## OUT OF SCOPE
– Do NOT build auth, a backend, charts, or multi-user support.
– Do NOT restyle beyond what’s needed for a clean usable UI.
## DELIVERABLES
– Create: `src/App.tsx`, `src/types.ts`,
`src/components/ExpenseForm.tsx`, `src/components/ExpenseList.tsx`,
`src/components/ExpenseFilter.tsx`, `src/hooks/useExpenses.ts`
– Output: complete file contents for every file, then run
instructions, then your report.
## VERIFY YOUR WORK BEFORE FINISHING
– Re-check the localStorage read/write for the corrupt-JSON case.
– Report: what you built, how I test it, assumptions you made,
and any trade-offs.
“`
—
## Part 6 — The 12 Rules That Get the Most Out of Every Prompt
1. **Context beats cleverness.** Describe the project, existing files, and stack before asking for anything. The AI can’t see your screen.
2. **Number your requirements.** Numbered lists get fulfilled; prose gets skimmed.
3. **Define “done” in testable terms.** “Loads under 2s” beats “make it fast.” Checkboxes beat adjectives.
4. **Give one concrete example.** One input → expected output example removes more ambiguity than a paragraph of description.
5. **Be boring and specific.** Say `save items to localStorage` not `make it remember stuff`.
6. **Specify exact file paths.** `src/hooks/useExpenses.ts` beats “a hooks file.”
7. **Ask for a plan first.** “List the files you’ll touch, then build” keeps the AI on track for long tasks.
8. **Demand self-verification.** “Check your own code for bugs before replying” catches most AI mistakes.
9. **Paste real code, don’t describe it.** Using the Paste-Code Clause replaces ten sentences of vague description.
10. **Set the boundary lines.** An explicit “do NOT do X” list stops scope creep dead.
11. **Fix the output format you want.** Complete files + run commands + summary is a predictable, reusable format.
12. **Build a personal skeleton library.** Once a prompt works well, save it with `[BLANK]`s and reuse it. Your best prompt is your next prompt’s starting point.
—
## Part 7 — The Pre-Send Checklist
Run through this before hitting send. If any box is unchecked, add the missing piece — it’s cheaper than a follow-up.
– [ ] **Role** defined (seniority + exact tech)
– [ ] **Project context** given (what it is, stack, run command, key files)
– [ ] **One-line task** stated clearly
– [ ] **Requirements** numbered and specific
– [ ] **Constraints** listed (deps, platform, performance, complexity)
– [ ] **Style/conventions** set (naming, comments, structure)
– [ ] **Edge cases** named (empty, invalid, duplicate, failure)
– [ ] **Definition of done** is testable (checkboxes)
– [ ] **Out of scope** stated (the “do NOT” list)
– [ ] **Deliverables** specified (exact paths + answer format)
– [ ] **Self-verification + report** requested
– [ ] **Complete-in-one-response** clause included
– [ ] **Complete-file** clause included (for multi-file work)
– [ ] **Example input/output** provided (if behavior needs precision)
– [ ] **Pasted** the actual relevant code (not described it)
—
## Part 8 — Quick Cheat Sheet (one-line reminders)
| When you want to… | Add this… |
|—|—|
| Finish everything now | *One-Sitting Clause* |
| Get full files you can paste | *Complete-File Clause* |
| Catch AI’s own bugs | *Self-Review Clause* |
| Not break what exists | *OUT OF SCOPE* + *Definition of Done* |
| Fix a bug properly | Paste real code + *Root Cause Required* |
| Avoid scope creep | *OUT OF SCOPE* list |
| Understand what you got | *Explain-It Clause* |
| Keep it fast | *Performance Clause* |
| Keep it safe | *Security Clause* |
| Prove it works | *Test Clause* |
—
### ⭐ Memory jogger — the 5 Ws of a perfect prompt:
– **Who** — role
– **What** — task + numbered requirements
– **Where** — project context + file paths
– **What if** — edge cases
– **What proves it** — definition of done