Common prompting mistakes

# Bad prompt
"Make me a login page"

# Good prompt
"Create a login page in React/TypeScript with Tailwind CSS.
Fields: email (required, format validated) and password (required, min 8 characters).
Include a 'Forgot password' link and a 'Sign in with Google' button.
Handle states: form, loading, error (bad credentials), success.
Use react-hook-form with Zod validation.
Accessible: explicit labels, aria-describedby for errors, focus management."

# Bad prompt
"Create a table component"

# Good prompt
"Create a DataTable component in React/TypeScript for Next.js 14 (App Router).
Stack: Tailwind CSS, @tanstack/react-table v8.
Features: column sorting, pagination (20 items/page), global search.
Data comes from a REST API with the format { data: T[], total: number }.
Strict TypeScript, no any. Named exports only."

# Bad prompt
"Build me a complete project management app with auth, dashboard,
task management, API, database, tests, CI/CD and deployment"

# Good prompt (broken into steps)
"Step 1: Let's create the database schema.
Create the schema.prisma for a task management app with:
- Table User (id uuid, email unique, name, passwordHash, createdAt)
- Table Project (id uuid, name, description, ownerId FK User, createdAt)
- Table Task (id uuid, title, description, status enum, priority enum,
  projectId FK Project, assigneeId FK User nullable, dueDate nullable)
Relations: User 1->N Project, Project 1->N Task, User 1->N Task (assigned)"

# Bad prompt (starting over)
"Actually, that's not what I wanted.
Redo a completely different Button component."

# Good prompt (iterating on the existing work)
"The Button component is a good base. Here are 3 adjustments:
1. Replace the 'info' and 'success' variants with 'ghost' and 'outline'
2. Add 'leftIcon' and 'rightIcon' props of type LucideIcon
3. The loading state should disable the button AND replace the label with a spinner
Keep everything else as is."

# Bad prompt
"Create a function that fetches users from the API"

# Good prompt
"Create a fetchUsers function that retrieves users from GET /api/users.
Handle the following cases:
- Success: return the typed User[] array
- Network error: return an explicit error with automatic retry (3 attempts)
- 401 error: trigger the refresh token then retry the request
- 429 error: wait for the delay specified in Retry-After then retry
- 500 error: log the error and return a user-friendly message
- Timeout: abort after 10 seconds with an explicit message
Return a Result<User[], ApiError> type (no throw)."

# Bad prompt (unadapted template)
"You are an expert developer. Create a complete CRUD for User."

# Good prompt (template adapted to project)
"You are a backend TypeScript/Express developer in our MyApp project.
Create the User CRUD following our conventions (see CLAUDE.md):
- Repository pattern (src/repositories/user.repository.ts)
- Service layer (src/services/user.service.ts)
- Controller (src/controllers/user.controller.ts)
- Zod validation (src/schemas/user.schema.ts)
- Response format: { success, data, error, meta }
- Service tests with repository mocks"

# Bad prompt
"Create a useDebounce hook"

# Good prompt
"Create a useDebounce<T>(value: T, delay: number): T hook.
The hook returns the debounced value after 'delay' ms without change.
Clean up the timeout on unmount and when value/delay change.

Include unit tests (Vitest + Testing Library renderHook):
- Returns the initial value immediately
- Returns the updated value after the delay
- Doesn't update if the value changes before the delay
- Cleans up the timeout on component unmount
- Works with generic types (string, number, object)"

# Bad (repeating in every prompt)
"Use strict TypeScript, no any, Tailwind CSS, functional components,
named exports, files < 400 lines, immutability..."

# Good (using CLAUDE.md)
Put this information in your CLAUDE.md once and for all.
Then your prompt reduces to:
"Create a SearchBar component with autocomplete and 300ms debounce."

# Bad (re-explaining everything)
"For my Next.js 14 TypeScript Tailwind CSS Prisma PostgreSQL project
(the one we were talking about earlier), create a..."

# Good (building on context)
"Now create the rate limiting middleware for the endpoints
we just created. Use the same structure as the auth middleware."

# Bad (accepting without checking)
"Great, thanks!" -> move on

# Good (asking for verification)
"Before moving on, check the code you just generated:
1. Are there security vulnerabilities? (SQL injection, XSS, CSRF)
2. Are edge cases handled? (null, undefined, empty array, empty string)
3. Is the code testable? (no hardcoded dependencies)
4. Is performance acceptable for 10,000 items?
5. Is the TypeScript strict? (no any, no as unknown)"