How to Write Prompts for AI Coding Tools: 30 Templates That Ship Real Software

Stop getting garbage output from your AI coding tools. These 30 prompt templates are battle-tested across Cursor, Claude Code, and Copilot for building real products.

By vibecodemeta 13 min read
prompts ai-coding cursor claude-code copilot vibe-coding templates productivity

The difference between a vibe coder who ships and one who fights their AI all day comes down to one skill: prompting. Not “prompt engineering” in the academic sense — we’re talking about the practical, repeatable patterns that make AI coding tools actually useful instead of frustrating.

We’ve tested hundreds of prompt structures across Cursor, Claude Code, GitHub Copilot, and Windsurf. These 30 templates are the ones that consistently produce deployable code on the first or second try.

Why Most AI Coding Prompts Fail

Before the templates, let’s understand why your prompts aren’t working. The three most common failures we see:

1. Too vague. “Build me a login page” gives the AI no constraints. It doesn’t know your stack, your styling preferences, your auth provider, or your existing code structure. You’ll get something generic that doesn’t fit your project.

2. Too specific about implementation, not specific enough about intent. “Write a React component that uses useState to track email and password, with a form that has two inputs and a button, using Tailwind classes…” — you’re basically writing the code yourself at that point. Tell the AI what you want, not how to build it.

3. No context about existing code. AI tools work best when they understand what already exists. If you have a design system, existing components, or specific patterns you follow, the AI needs to know.

The fix is a simple framework we call CIVIC: Context, Intent, Vibe, Input/Output, Constraints.

The CIVIC Framework

Every good AI coding prompt has five elements:

  • Context: What exists already? What’s the tech stack? What file are we in?
  • Intent: What should this code accomplish? What problem does it solve?
  • Vibe: What’s the quality bar? Production-ready? Quick prototype? Refactor for readability?
  • Input/Output: What goes in, what comes out? What data shapes are involved?
  • Constraints: What should it NOT do? Performance requirements? Accessibility needs?

You don’t need all five for every prompt. But the more you include, the better your output. Let’s see it in action.

Section 1: Scaffolding & Project Setup (Templates 1-6)

Template 1: New Project Scaffold

Create a [framework] project with:
- [UI library/styling approach]
- [auth provider] authentication
- [database] for data persistence
- TypeScript strict mode
- ESLint + Prettier configured

Project structure should follow [pattern] conventions.
Include a working health check endpoint and a placeholder home page.

Why it works: Gives the AI clear boundaries without micromanaging file names. The “working health check endpoint” forces it to produce something testable immediately.

Template 2: API Route Builder

Create a REST API route for [resource].

Existing patterns to follow: [paste an existing route file or describe the pattern]

Endpoints needed:
- GET /api/[resource] — list with pagination (default 20 per page)
- GET /api/[resource]/:id — single item
- POST /api/[resource] — create (validate: [required fields])
- PATCH /api/[resource]/:id — partial update
- DELETE /api/[resource]/:id — soft delete

Use [ORM/query builder] for database access.
Return consistent error shapes: { error: string, code: number }

Why it works: The existing patterns reference is the key. AI tools produce dramatically better code when they can match an existing convention in your codebase.

Template 3: Database Schema

Design a database schema for [feature].

Business rules:
- [rule 1]
- [rule 2]
- [rule 3]

Use [database type]. Include indexes for columns that will be queried frequently.
Add created_at and updated_at timestamps to all tables.
Include migration file in [migration tool] format.

Template 4: Component Library Starter

Create a [component] component that matches our existing design system.

Reference component for style patterns: [paste existing component]

Props:
- [prop]: [type] — [description]
- [prop]: [type] — [description]

States: default, hover, focused, disabled, loading, error
Must be accessible (ARIA labels, keyboard navigation, screen reader support).
Use [styling approach] consistent with the reference component.

Template 5: Testing Suite

Write tests for [file/component/function].

Test framework: [jest/vitest/playwright/etc]
Existing test patterns: [paste example or describe]

Cover:
- Happy path with typical inputs
- Edge cases: [list specific edges]
- Error handling: [list error scenarios]
- [Any integration/E2E specific scenarios]

Mock [external dependencies] but test [these things] against real implementations.

Template 6: Environment & Config Setup

Set up environment configuration for [project].

Environments: development, staging, production
Required variables: [list them]
Optional variables with defaults: [list them]

Use [approach] for config management.
Include validation that fails fast on missing required vars at startup.
Add a .env.example file with all variables documented.

Section 2: Feature Building (Templates 7-14)

Template 7: Full Feature (The Big One)

Build [feature name] for [project context].

User story: As a [user type], I want to [action] so that [benefit].

Acceptance criteria:
1. [criterion]
2. [criterion]
3. [criterion]

Tech constraints:
- Stack: [your stack]
- Must integrate with existing [systems]
- Performance: [requirements]

Start with the data model, then API, then UI. Each layer should work independently.

Why it works: The “each layer should work independently” instruction prevents the AI from creating tightly coupled code that breaks when you modify one part.

Template 8: Form with Validation

Create a form for [purpose].

Fields:
- [field]: [type], [validation rules]
- [field]: [type], [validation rules]

On submit: [what happens — API call, state update, navigation]
Show inline validation errors below each field.
Show a loading state on the submit button during submission.
Show a toast/alert on success and on failure.
Use [form library if any] for state management.

Template 9: Data Table / List View

Build a data table for [resource].

Columns: [list columns with types]
Features needed: [sorting / filtering / pagination / search / bulk actions]
Data source: [API endpoint or data shape]

Empty state: [what to show when no data]
Loading state: [skeleton/spinner]
Error state: [what to show on fetch failure]

Row actions: [edit, delete, view details, etc.]

Template 10: Authentication Flow

Implement [auth type] authentication.

Provider: [auth provider or custom]
After login: redirect to [route]
After logout: redirect to [route]
Protected routes: [list or pattern]

Store session in [cookies/localStorage/etc].
Include a middleware/guard that redirects unauthenticated users.
Handle token refresh automatically.
Handle expired sessions gracefully (redirect to login, preserve intended destination).

Template 11: File Upload

Build a file upload feature for [purpose].

Accepted types: [file types]
Max size: [size limit]
Storage: [where files go — S3, local, Cloudflare R2, etc.]

UI requirements:
- Drag and drop zone
- Progress indicator during upload
- Preview for images
- Cancel upload option
- Error messages for invalid files

Process uploads [client-side/server-side] with [any processing needed].

Template 12: Search Implementation

Add search to [feature/page].

Search across: [fields/collections]
Method: [full-text / fuzzy / exact match]
Display results as: [format]

Include:
- Debounced input (300ms)
- Loading indicator
- "No results" state with suggestions
- Highlight matching text in results
- Keyboard navigation (arrow keys, enter to select)

[If applicable: Use [search service] for indexing]

Template 13: Notification System

Build a notification system for [app].

Notification types:
- [type]: triggered when [event], displayed as [format]
- [type]: triggered when [event], displayed as [format]

Delivery channels: [in-app / email / push / SMS]
Mark as read: [individually / mark all]
Persistence: [store in DB / ephemeral]

In-app UI: notification bell with unread count, dropdown panel, notification cards.

Template 14: Dashboard / Analytics View

Create a dashboard showing [metrics/data].

Cards/widgets:
- [metric]: [data source], displayed as [number/chart/trend]
- [metric]: [data source], displayed as [number/chart/trend]

Time range selector: [options]
Auto-refresh: [interval or manual]
Responsive: stack cards on mobile, grid on desktop.

Use [charting library] for visualizations.
Data comes from [API endpoints or data shape].

Section 3: Refactoring & Debugging (Templates 15-22)

Template 15: Code Review & Refactor

Review this code and refactor for [goal: readability / performance / maintainability].

[paste code]

Specifically:
- Identify any bugs or edge cases
- Reduce duplication
- Improve naming
- Add error handling where missing
- Keep the same external API/interface

Explain each change you make and why.

Template 16: Performance Optimization

This [component/function/query] is slow. Current performance: [metric].

[paste code or describe the bottleneck]

Target: [desired performance metric]
Constraints: cannot change [external API / database schema / etc.]

Identify the bottleneck, explain why it's slow, and provide an optimized version.
Measure the expected improvement.

Template 17: Bug Fix

Bug: [describe the bug — what happens vs what should happen]

Steps to reproduce:
1. [step]
2. [step]
3. [step]

Relevant code: [paste or reference files]
Error message (if any): [paste error]

Fix the bug. Explain the root cause. Add a guard to prevent similar bugs.

Template 18: Type Safety Retrofit

Add TypeScript types to this JavaScript code.

[paste code]

Requirements:
- Strict types (no `any` unless absolutely necessary)
- Interface definitions for all data shapes
- Generic types where patterns repeat
- JSDoc comments on exported types

If the code has implicit type issues, flag them as comments.

Template 19: Error Handling Upgrade

Add comprehensive error handling to [file/module].

[paste code or reference file]

Requirements:
- Catch and handle all async operations
- User-facing errors: friendly messages, no stack traces
- Developer-facing errors: detailed logs with context
- Retry logic for transient failures ([which operations])
- Graceful degradation when [service] is unavailable

Template 20: Accessibility Audit

Audit this component for accessibility issues.

[paste code]

Check for:
- Semantic HTML usage
- ARIA attributes where needed
- Keyboard navigation (tab order, enter/space activation)
- Screen reader announcements for dynamic content
- Color contrast (note any potential issues)
- Focus management on modals/dropdowns

Provide the fixed version with all issues resolved.

Template 21: Security Hardening

Review this code for security vulnerabilities.

[paste code]

Check for:
- Injection attacks (SQL, XSS, command injection)
- Authentication/authorization bypasses
- Sensitive data exposure (logs, errors, responses)
- CSRF protection
- Rate limiting needs
- Input validation gaps

Provide the hardened version. Explain each vulnerability found and its severity.

Template 22: Legacy Code Migration

Migrate this code from [old pattern/library] to [new pattern/library].

[paste code]

Maintain the same functionality and external API.
Update all imports and dependencies.
Follow [new library] best practices and conventions.
Add types if moving to TypeScript.

Test the migration by verifying [specific behaviors to check].

Section 4: DevOps & Infrastructure (Templates 23-27)

Template 23: CI/CD Pipeline

Create a CI/CD pipeline for [project].

Platform: [GitHub Actions / GitLab CI / etc.]
Triggers: [on push to main / on PR / on tag]

Steps:
1. Install dependencies
2. Lint
3. Type check
4. Run tests
5. Build
6. Deploy to [environment] (only on [branch/tag])

Environment variables needed: [list]
Caching: [node_modules / build artifacts]
Notifications: [where to send success/failure alerts]

Template 24: Docker Setup

Create a Dockerfile for [project].

Base image: [node:20-alpine / python:3.12-slim / etc.]
Runtime: [production optimized]

Requirements:
- Multi-stage build (build + runtime stages)
- Non-root user
- Health check endpoint
- Environment variables for configuration
- [Any volume mounts needed]

Include docker-compose.yml for local development with [services needed].

Template 25: Monitoring & Logging

Add monitoring and structured logging to [application].

Logging:
- Structured JSON logs
- Log levels: error, warn, info, debug
- Request ID tracking across async operations
- Sensitive data redaction

Monitoring:
- Health check endpoint
- Key metrics: [response time, error rate, etc.]
- Alert thresholds: [define]

Use [logging library] and [monitoring service].

Template 26: Database Migration

Create a database migration for [change].

Current schema: [describe or paste]
Desired change: [what needs to change]

Migration tool: [prisma / knex / raw SQL / etc.]

Requirements:
- Forward migration (up)
- Rollback migration (down)
- Data preservation (no data loss)
- Handle existing data that needs transformation
- Idempotent (safe to run multiple times)

Template 27: Infrastructure as Code

Set up infrastructure for [application].

Cloud provider: [AWS / GCP / Cloudflare / etc.]
Tool: [Terraform / Pulumi / CDK / etc.]

Resources needed:
- [compute: what type and size]
- [database: what type]
- [storage: what for]
- [networking: any special requirements]
- [DNS: domain configuration]

Include sensible defaults for development.
Tag all resources with: project=[name], environment=[env].

Section 5: Content & Meta (Templates 28-30)

Template 28: README Generator

Generate a README for [project].

Include:
- One-line description
- Quick start (3 steps or fewer to run locally)
- Architecture overview (brief)
- Environment variables reference
- Available scripts/commands
- Deployment instructions
- Contributing guidelines (brief)

Tone: [professional / casual / technical]
Skip: badges, long feature lists, screenshots (unless provided).

Template 29: API Documentation

Document this API: [paste routes or OpenAPI spec]

For each endpoint, include:
- Method and path
- Description (one sentence)
- Request body/params with types
- Response shape with types
- Error responses
- Example request and response

Format: [Markdown / OpenAPI / Postman collection]

Template 30: Changelog Entry

Write a changelog entry for [version].

Changes made:
- [change 1]
- [change 2]
- [change 3]

Format: Keep a Changelog standard
Categories: Added, Changed, Deprecated, Removed, Fixed, Security
Audience: developers using this as a dependency

Be specific about what changed and why. Link to relevant issues/PRs if applicable.

The Meta-Prompt: When You Don’t Know What to Prompt

When you’re stuck and don’t even know what to ask, use this:

I'm building [project description]. I'm stuck on [problem].

What I've tried: [what you've attempted]
What I expected: [what should happen]
What actually happens: [what went wrong]

What's the best approach to solve this? Give me the strategy first, then the code.

This works because it forces the AI to think about the approach before jumping to code. That “strategy first, then code” instruction is the single most powerful modifier you can add to any prompt.

Using These Templates in Different Tools

Cursor: Paste templates into Composer (Cmd+I) for multi-file changes, or inline chat (Cmd+K) for single-file edits. Reference files with @file to give context.

Claude Code: These templates work directly in the terminal. Claude Code excels at templates 7, 15, and 23 — anything that touches multiple files.

GitHub Copilot: Use these in the Chat panel (Ctrl+Shift+I). For inline completion, write the first line of what you want and let Copilot extend from there. Copilot is strongest with templates 1-6 and 15-18.

Windsurf: Cascade handles multi-file operations well. Templates 7-14 (feature building) work particularly well in Windsurf’s flow-based interface.

The One Rule That Matters Most

Every template above follows one principle: tell the AI what success looks like, not how to get there.

Describe the outcome. Describe the constraints. Let the AI figure out the implementation. That’s vibe coding. That’s how you ship.

Now go build something.

Related reading:

Join the Discussion