Prompt-Vorlagen, die Code liefern

Ein wegwerfbarer Prompt bringt wegwerfbaren Code. Ein präziser bringt etwas, das du wirklich mergen kannst. Die Lücke zwischen den beiden ist fast immer Spezifizität. Vage Anweisungen erzeugen vage Ausgaben.

Die zehn Rezepte unten bringen die Details ein, die Claude Code braucht, um Arbeit zu liefern, die du zum Review weiterreichen würdest. Jedes kommt mit dem Prompt, dem Grund warum er hält, ein paar Austauschmöglichkeiten für andere Stacks und den Fehlermodi, die Leute treffen, die etwas Ähnliches ohne Struktur versuchen.

Projekt-Scaffolding

Full-Stack-Web-App

claude "Create a React app with TypeScript and Tailwind CSS. It's a todo app with localStorage persistence. Include: add, edit, delete, mark complete, and filter by status (all/active/completed). Use a single TodoContext for state management. Make it mobile-responsive with min-width 320px support."

Warum er hält: Tech-Stack, Speicherwahl, jedes CRUD-Verb, das State-Modell und die kleinste unterstützte Bildschirmgröße sind alle aufgeschrieben. Claude hört auf zu raten, sodass nichts zurückkommt, das du herausreißen müsstest.

Austauschmöglichkeiten:

• Next.js: Ersetze "React app" durch "Next.js 15 app using App Router and Server Components where possible"
• Vue: Ersetze den React/TypeScript-Stack durch "Vue 3 with Composition API and TypeScript"
• Reichhaltigerer Starter: Füge "Include dark mode toggle, keyboard shortcuts (Ctrl+N for new, Delete to remove), and export/import as JSON" an

Wo Leute falsch liegen: Ein nacktes "create a todo app" lässt Claude auf das zurückfallen, was ihm richtig erscheint, was selten zu deinem Repo passt. "Make it look good" ist schlimmer als Tailwind zu nennen, denn Geschmack ist keine Spezifikation.

Was du zurückbekommst: drei bis fünf Dateien. Ein React-Komponentenbaum, ein Kontext-Provider, TypeScript-Interfaces für das Todo-Modell und ein Tailwind-Layout, das sich anpasst. npm run dev startet es beim ersten Versuch.

API-Backend mit Auth

claude "Build an Express.js REST API with JWT authentication. Include: user registration (POST /auth/register), login (POST /auth/login), and a protected endpoint (GET /auth/me). Hash passwords with bcrypt (12 rounds). Use middleware for token verification. Add Zod validation for request bodies. Return consistent JSON error responses with status codes. Include a health check endpoint at GET /health."

Warum er hält: Die Routen aufzuschreiben verhindert, dass Claude eigene erfindet. Den bcrypt-Rundenanzahl, die Validierungsbibliothek und die Fehlerform zu nennen bedeutet, dass die Ausgabe bereits wie Code aus deinem Projekt aussieht. Kein Nachbearbeitungsdurchlauf.

Austauschmöglichkeiten:

• Fastify: Ersetze "Express.js" durch "Fastify with @fastify/jwt plugin"
• Prisma: Füge "Use Prisma with PostgreSQL. Include a User model with id, email, passwordHash, createdAt fields" hinzu
• Sessions: Tausche "JWT authentication" gegen "express-session with Redis store for session management"

Wo Leute falsch liegen: Lass die Fehlerbehandlungszeile weg und Claude schreibt nur den Happy Path. Registrierung und Login funktionieren mit sauberen Eingaben und brechen bei allem Fehlerhaften zusammen.

Datenbank und Datenschicht

Schema-Generierung

claude "Create a PostgreSQL schema for a multi-tenant SaaS app. Tables needed: organizations, users (belongs to organization), projects (belongs to organization), and tasks (belongs to project, assigned to user). Include: UUID primary keys, created_at/updated_at timestamps on all tables, proper foreign keys with ON DELETE CASCADE, a unique constraint on user email per organization, and indexes on all foreign key columns. Add 5 sample INSERT statements per table for testing."

Warum er hält: Das Wort "multi-tenant" trägt das Isolierungsmuster. UUID-Keys, Timestamps, Cascade-Regeln und den Gültigkeitsbereich der eindeutigen E-Mail-Einschränkung aufzurufen tötet die häufigsten Review-Anmerkungen. Beispielzeilen zu verlangen zwingt das Schema, tatsächlich ohne Fehler zu laden.

Austauschmöglichkeiten:

• MySQL: Ersetze "PostgreSQL" durch "MySQL 8.0 using InnoDB engine"
• Prisma-Migrationen: Füge "Format as Prisma schema instead of raw SQL, and generate the initial migration" hinzu
• Audit-Log: Füge "Include an events table with a JSONB payload column, indexed with GIN, for audit logging" hinzu

Testing

Vollständiges Test-Setup

claude "Set up Vitest with React Testing Library for this TypeScript React project. Create: a test for the Button component that checks rendering, click handling, disabled state, and loading state. An integration test for the LoginForm that mocks the auth API call, fills the form, submits, and verifies redirect on success and error message on failure. Add a test utility file with a renderWithProviders function that wraps components in the app's context providers. Add test and test:coverage scripts to package.json."

Warum er hält: Test-Prompts kippen um, wenn sie sich lesen wie "write tests for this component." Hier bekommst du vier benannte Fälle für den Unit-Test und zwei End-to-End-Flows für den Integrationstest. Die gemeinsame Helper-Datei ist das Stück, das die meisten überspringen, und es ist das Stück, das zukünftige Tests konsistent hält.

Austauschmöglichkeiten:

• Playwright E2E: Ersetze das Framework durch "Set up Playwright for end-to-end testing. Include a test that navigates to the login page, fills credentials, submits, and verifies the dashboard loads"
• API-Testing: "Set up Supertest with Vitest for the Express API. Test the /auth/register endpoint with valid data, duplicate email, and missing required fields"

Was du zurückbekommst: Eine Konfigurationsdatei, zwei oder drei Testdateien, die bestehen, eine gemeinsame Utilities-Datei und frische package.json-Skripte. npm test wird gleich grün.

Refactoring

Komponentenzerlegung

claude "This UserDashboard component is 400 lines long. Refactor it by: extracting the stats cards into a StatsGrid component, the activity feed into an ActivityFeed component, and the sidebar navigation into a DashboardNav component. Keep the data fetching in UserDashboard and pass data down as props. Create TypeScript interfaces for all props. Preserve all existing functionality and don't change any CSS class names."

Warum er hält: Refactoring-Prompts brauchen Leitplanken. "Refactor this component" lässt Claude alles verschieben, was es will, und Verhalten ändert sich still. Aufzuschreiben, welche Kinder herausgezogen werden, wo Fetching bleibt und welche CSS-Klassen bleiben, bedeutet, dass der neue Code in deine App fällt, ohne die UI oder die Tests zu brechen.

Austauschmöglichkeiten:

• Custom Hook: "Extract the data fetching logic into a useUserDashboard custom hook. Return the loading state, error state, and all data objects. Keep the component purely presentational"
• Zustand-Migration: "Move the local useState calls into a Zustand store. Export typed selectors for each piece of state. Keep the component renders identical"

Debugging

Strukturierte Bug-Suche

claude "Users report that the checkout form submits twice on slow connections. Investigate: check the form's onSubmit handler for missing event.preventDefault() or missing disabled state during submission. Check if the submit button lacks a loading/disabled state. Check for React StrictMode double-render issues. Check if the API call has retry logic that could cause duplicates. Propose a fix and add an idempotency safeguard."

Warum er hält: Die meisten Debugging-Prompts lauten "fix this bug." Das lässt Claude in einem Zug raten, suchen und patchen, und meistens hängt es sich an die erste plausible Geschichte. Diese Version übergibt die vier wahrscheinlichsten Grundursachen für ein doppeltes Submit und bittet Claude, sie der Reihe nach durchzugehen.

Austauschmöglichkeiten:

• Langsame Seite: "The dashboard takes 8 seconds to load. Investigate: check for N+1 queries in the API, unnecessary re-renders in React components, unoptimized images, and missing database indexes. Measure the time each fix saves"
• Auth-Abfall: "Users are getting logged out randomly. Check: JWT expiration handling, refresh token rotation, cookie settings (SameSite, Secure, HttpOnly), and whether concurrent requests race on token refresh"

Code-Review und Qualität

Pre-PR-Review

claude "Review the changes in this branch for a PR. Check for: security issues (SQL injection, XSS, exposed secrets), missing error handling on async operations, TypeScript type safety (no 'any' types, proper null checks), accessibility on any new UI components (ARIA labels, keyboard navigation), and performance concerns (unnecessary re-renders, missing useMemo/useCallback). Format findings as a list with severity (critical/warning/info) and file location."

Warum er hält: "Review this code" bringt oberflächliche Anmerkungen. Die fünf Review-Achsen und die Ausgabeform aufzuschreiben liefert einen Bericht, den du direkt abarbeiten kannst.

Austauschmöglichkeiten:

• Nur Backend: Tausche Barrierefreiheit und Re-Renders gegen "N+1 queries, missing rate limiting, and improper error propagation"
• Sicherheitsdurchlauf: "Focus exclusively on security: check all user inputs, authentication boundaries, authorization checks, sensitive data handling, and dependency vulnerabilities"

Feature-Entwicklung

Vertikaler Slice-Build

claude "Add a comment system to blog posts. Requirements: comments stored in a PostgreSQL comments table with id, post_id, author_name, content, created_at. API endpoints: GET /posts/:id/comments and POST /posts/:id/comments with Zod validation. React component showing threaded comments with a reply form. Optimistic UI update on new comment submission. Rate limit to 5 comments per minute per IP. Include the database migration."

Warum er hält: Der Prompt umspannt den gesamten Slice. Tabelle, API und UI in einer einzigen Anfrage. Optimistisches Rendering, das Rate-Limit und die Migrationsdatei zu nennen bedeutet, dass Claude das Feature als eine fertige Einheit schreibt, nicht als drei lose zusammenhängende Fragmente, die beim Testen Lücken zeigen.

Austauschmöglichkeiten:

• Echtzeit: "Add WebSocket support so new comments appear for all viewers without refreshing"
• Moderation: "Include an isApproved boolean field and an admin endpoint to approve/reject comments"

Infrastruktur und DevOps

CI/CD-Pipeline

claude "Create a GitHub Actions workflow for this TypeScript monorepo. On push to main: run TypeScript type checking, run Vitest tests, build the Next.js app, and deploy to Vercel. On pull request: run type checking and tests only, post a preview deployment link as a PR comment. Cache node_modules between runs using pnpm lockfile hash. Fail fast if any step errors."

Warum er hält: Pipeline-Prompts brauchen Branch-Regeln, die von vorne aufgeschrieben sind. Zu trennen, was auf main läuft und was auf PRs, den Cache-Key zu nennen und das Preview-Verhalten zu benennen, lässt den Workflow beim ersten Push korrekt landen. Keine drei Runden "ach, füge das auch noch hinzu."

Austauschmöglichkeiten:

• Docker: "Build and push a Docker image to GitHub Container Registry on main, tagged with the git SHA and 'latest'"
• Migrationen: "Add a step that runs Prisma migrations against the staging database before deployment, with a rollback step if deployment fails"

Konfiguration und Umgebung

Config-Audit

claude "Audit this project's configuration. Check: tsconfig.json has strict mode enabled and proper path aliases. ESLint config catches unused imports, consistent formatting, and React hook dependency warnings. Package.json has correct scripts for dev, build, test, and lint. Environment variables are validated at startup (not just process.env access scattered through code). Flag any configuration that could cause silent failures in production."

Warum er hält: Konfig-Bugs sind die schlimmste Art. Sie scheitern still oder nur an bestimmten Tagen. Dieser Prompt lenkt Claude auf die vier relevanten Oberflächen und fragt direkt nach Produktionsfehlermodi.

Nutzungsprinzipien

Die zehn Rezepte halten aus drei Gründen, die es wert sind, zu übernehmen.

Liefere die Form, nicht nur das Ziel. "Create an API" ist ein Ziel. "Create Express endpoints at these routes with Zod validation and consistent error responses" ist eine Form. Claude arbeitet von der Form her rückwärts und baut, um zu passen.

Nenne die Einschränkungen am Anfang. Jede Einschränkung, die du ungesagt lässt, wird zu einem Münzwurf. Stack, Fehlerbehandlung, Styling, Browser-Unterstützung, Datenbank-Engine. Wenn es wichtig ist, schreib es auf. Wenn nicht, wählt Claude, was gut aussieht.

Schreib die langweiligen Anforderungen auf. Rate-Limiting. Idempotenz. Ladezustände. Error-Boundaries. Zugängliche Labels. Das sind die Zeilen, die ein Demo von echtem Code unterscheiden, und die, die die meisten Prompts auslassen. Ein paar extra Wörter dafür aufzuwenden spart Stunden Nacharbeit später.

Baue deine eigene Bibliothek

Die zehn Rezepte decken Muster ab, die in fast jedem Projekt auftauchen. Deine Codebase hat aber ihre eigene Form und ihre eigenen scharfen Kanten. Der Gewinn kommt davon, eine eigene Vorlagen-Bibliothek zu pflegen. Wenn ein Claude Code-Lauf etwas Sauberes produziert, speichere den Prompt. Wenn nicht, finde heraus, welches Stück der Spezifikation fehlte und schraube es fest.