Los 50 mejores prompts de Claude Code para cada flujo de trabajo de desarrollo

Claude Code se ha convertido en uno de los agentes de programación con IA más potentes disponibles en 2026. Pero como cualquier herramienta, la calidad del resultado depende enteramente de la entrada. Un prompt vago produce código vago. Un prompt preciso y bien estructurado produce soluciones listas para producción.

Tras meses construyendo SuperBuilder, una app de escritorio que envuelve Claude Code con modos de ejecución, herramientas de depuración y gestión de proyectos, hemos visto miles de prompts de desarrolladores reales. Sabemos cuáles producen grandes resultados de forma constante y cuáles desperdician tokens.

Esta guía recopila los 50 mejores prompts de Claude Code en siete categorías de flujo de trabajo, con consejos prácticos sobre cuándo usar cada uno y cómo obtener resultados aún mejores con los modos de ejecución de SuperBuilder.

Tabla de contenidos

• Cómo escribir mejores prompts de Claude Code
• Prompts para corregir bugs (1-10)
• Prompts para crear funciones (11-20)
• Prompts de refactorización (21-30)
• Prompts de testing (31-35)
• Prompts de documentación (36-40)
• Prompts de revisión de código (41-45)
• Prompts de DevOps (46-50)
• Modos de ejecución de SuperBuilder: haciendo los prompts 10x más eficaces
• Prompt en crudo vs. modo Debug de SuperBuilder: una comparación real
• Consejos y trucos de Claude Code
• Preguntas frecuentes

Cómo escribir mejores prompts de Claude Code

Antes de sumergirnos en los prompts, aquí están los principios que separan los prompts mediocres de los excelentes:

1. Sé específico sobre el problema, no sobre la solución. Dile a Claude qué está roto o qué necesitas, no cómo implementarlo. Deja que el agente descubra el enfoque.
2. Incluye contexto sobre tu stack. Claude Code puede leer tus archivos, pero nombrar explícitamente el framework, la versión del lenguaje y las dependencias clave ahorra tiempo.
3. Indica las restricciones. "No añadas nuevas dependencias", "mantén la retrocompatibilidad" o "esto debe funcionar en Node 18" mejoran drásticamente la calidad del resultado.
4. Describe el comportamiento esperado. "Cuando ocurra X, debería suceder Y" le da a Claude un objetivo verificable.
5. Una preocupación por prompt. Los prompts compuestos que piden tres cambios no relacionados producen peores resultados que tres prompts enfocados.

Prompts para corregir bugs (1-10)

La depuración es donde Claude Code realmente brilla. Estos prompts te ayudan a aplastar bugs más rápido dándole a Claude el contexto correcto por adelantado.

1. El depurador de stack trace

Prompt:

I'm getting this error when users submit the login form:

[paste stack trace]

The login form is in src/components/LoginForm.tsx and the auth handler is in src/api/auth.ts. The error only happens when the email contains a + character. Find the root cause and fix it.

Cuándo usarlo: tienes un stack trace y un escenario reproducible. Este es el prompt de depuración de pan y mantequilla.

Consejo pro: incluye siempre las rutas de archivo donde probablemente vive el bug. Claude Code las leerá, pero apuntarlo en la dirección correcta ahorra una ida y vuelta de búsqueda de archivos.

2. El cazador de regresiones

Prompt:

The checkout flow was working yesterday but now throws a 422 error when applying discount codes. Nothing in the discount logic changed. Check recent changes to the cart, pricing, and API validation layers to find what broke it.

Cuándo usarlo: algo que solía funcionar ahora está roto y no estás seguro de qué cambio lo causó.

Consejo pro: combina esto con la salida de git log --oneline -20 pegada en el prompt para que Claude pueda correlacionar los cambios de archivos con la regresión.

3. El investigador de fallos silenciosos

Prompt:

The webhook handler in src/webhooks/stripe.ts processes payment events but sometimes silently drops events without logging. No errors in the console. Check for unhandled promise rejections, missing await keywords, and early returns that skip processing.

Cuándo usarlo: algo falla de forma intermitente sin errores visibles, el peor tipo de bug.

Consejo pro: sugiere explícitamente modos de fallo (await faltante, bloques catch tragados) para guiar a Claude hacia patrones comunes de fallo silencioso.

4. El localizador de cuellos de botella de rendimiento

Prompt:

The /api/dashboard endpoint takes 8-12 seconds to respond. It queries the users, orders, and analytics tables. Profile the query logic in src/api/dashboard.ts and identify N+1 queries, missing indexes, or unnecessary data fetching. Suggest concrete fixes.

Cuándo usarlo: un endpoint o función es inaceptablemente lento y necesitas una auditoría de rendimiento.

Consejo pro: incluye la escala aproximada de datos (p. ej., "la tabla users tiene 500K filas") para que Claude pueda razonar sobre el rendimiento de las consultas de forma realista.

5. El detector de condiciones de carrera

Prompt:

Users occasionally see stale data after updating their profile. The update API returns success but the subsequent GET sometimes returns old values. Check src/api/profile.ts and src/cache/user-cache.ts for race conditions between cache invalidation and database writes.

Cuándo usarlo: bugs de consistencia intermitentes que huelen a problemas de temporización o concurrencia.

Consejo pro: este es un candidato excelente para el modo Debug de SuperBuilder, que genera hipótesis y las prueba sistemáticamente en lugar de adivinar.

6. El bug específico del entorno

Prompt:

This code works locally but fails in production with "ECONNREFUSED" on the Redis connection. The Redis URL is set via environment variable REDIS_URL. Check the connection setup in src/lib/redis.ts for hardcoded localhost references, missing TLS configuration, or connection string parsing issues.

Cuándo usarlo: funciona en mi máquina pero no en producción/staging/CI.

Consejo pro: enumera las diferencias entre entornos (Docker vs bare metal, versiones distintas de Node, requisitos de TLS) para ayudar a Claude a acotar la causa.

7. El desenredador de errores de tipo

Prompt:

TypeScript build fails with 23 errors after upgrading from React 18 to React 19. Most errors are in component props and event handlers. Fix the type errors while maintaining the same runtime behavior. Don't change any business logic.

Cuándo usarlo: una actualización de dependencia o de versión de TypeScript rompe tu build.

Consejo pro: añade "fix one file at a time and explain each change" si quieres revisar con cuidado, o "fix all of them" si confías en el agente y quieres velocidad.

8. El cazador de fugas de memoria

Prompt:

The Node.js process memory grows from 200MB to 2GB over 24 hours. The main suspect is the WebSocket connection manager in src/ws/connection-pool.ts. Check for event listener leaks, unreleased references in Maps/Sets, and missing cleanup in disconnect handlers.

Cuándo usarlo: tu aplicación tiene una fuga de memoria y tienes un área sospechosa.

Consejo pro: si tienes datos de heap snapshot o logs de process.memoryUsage(), pégalos. Los datos cuantitativos ayudan a Claude a priorizar las causas probables.

9. El depurador de layout CSS

Prompt:

The modal component in src/components/Modal.tsx renders behind the sidebar on mobile screens (< 768px). The sidebar has z-index: 100. The modal should always appear on top. Fix the stacking context issue without changing the sidebar's z-index.

Cuándo usarlo: bugs de layout visual, especialmente problemas de z-index y stacking context.

Consejo pro: incluye las dimensiones del viewport y qué navegadores están afectados. Los bugs de CSS suelen ser específicos del navegador.

10. El investigador de corrupción de datos

Prompt:

Some users have null values in the `subscription_tier` column even though the column has a NOT NULL constraint at the application level. Check the user creation flow in src/api/users.ts, the Stripe webhook handler in src/webhooks/billing.ts, and any direct database queries that might bypass the ORM validation.

Cuándo usarlo: tus datos tienen estados imposibles que la lógica de tu aplicación debería prevenir.

Consejo pro: usa aquí el modo Debug de SuperBuilder. Generará hipótesis sobre cómo podrían entrar valores null en la columna y probará cada vía sistemáticamente.

Prompts para crear funciones (11-20)

Construir nuevas funciones es donde la claridad del prompt rinde los mayores dividendos. Estos prompts ayudan a Claude Code a producir implementaciones bien estructuradas y listas para producción.

11. La especificación completa de función

Prompt:

Add a notification preferences page to the settings. Users should be able to toggle email notifications for: new comments, mentions, weekly digest, and marketing. Store preferences in the existing user_settings table (add columns if needed). Create the API endpoint, the React component, and wire them together. Use the same UI patterns as the existing ProfileSettings component.

Cuándo usarlo: tienes una especificación de función clara y quieres que Claude implemente la rebanada vertical completa.

Consejo pro: referenciar un componente existente como guía de estilo ("use the same patterns as X") es uno de los consejos más eficaces de Claude Code. Reduce la ambigüedad drásticamente.

12. El constructor de endpoints de API

Prompt:

Create a REST API endpoint POST /api/v1/teams/:teamId/invitations that sends an email invitation to join a team. Validate that the requesting user is a team admin. Check that the invited email isn't already a team member. Store the invitation with a unique token and 72-hour expiry. Return 201 with the invitation details. Follow the same error handling pattern used in src/api/v1/teams/members.ts.

Cuándo usarlo: necesitas un nuevo endpoint de API con reglas de negocio claras.

Consejo pro: especifica siempre el método HTTP, la ruta, las reglas de validación y la forma de la respuesta. Cuanto más específico sea el contrato, mejor será la implementación.

13. El creador de migraciones de base de datos

Prompt:

Create a database migration that adds a `teams` table with: id (uuid, primary key), name (varchar 255, not null), slug (varchar 100, unique, not null), owner_id (uuid, foreign key to users), created_at, updated_at. Add an index on owner_id. Use the same migration format as existing files in src/db/migrations/.

Cuándo usarlo: necesitas una nueva tabla o un cambio de esquema con definiciones de columna específicas.

Consejo pro: menciona siempre el formato/herramienta de migración (Knex, Prisma, Drizzle, SQL en crudo) y apunta a una migración existente como plantilla.

14. El constructor de componentes de UI

Prompt:

Create a reusable DataTable component that accepts: columns (array of { key, header, render? }), data (array of objects), onSort (callback), sortColumn, sortDirection, and optional emptyState. Support sticky headers, row hover, and column-level custom renderers. Use the existing design tokens in src/styles/tokens.ts. No external table libraries.

Cuándo usarlo: construir un componente reutilizable con una API bien definida.

Consejo pro: enumerar la interfaz de props por adelantado es lo más eficaz que puedes hacer para los prompts de componentes. Claude coincidirá con la interfaz exactamente.

15. El conector de integraciones

Prompt:

Add Slack integration that posts a message to a configured channel when a new support ticket is created. Create a SlackService class in src/services/slack.ts with methods: sendTicketNotification(ticket), verifyWebhook(payload), and configure(webhookUrl). Use the Slack Incoming Webhooks API. Add error handling with retries (max 3, exponential backoff).

Cuándo usarlo: integrar con un servicio de terceros con una API conocida.

Consejo pro: nombra el enfoque específico de la API (Incoming Webhooks vs. Bot Token vs. OAuth) para evitar que Claude elija uno que no se ajuste a tus necesidades.

16. El constructor de formularios

Prompt:

Create a multi-step onboarding form with 3 steps: (1) company info (name, size, industry dropdown), (2) team setup (invite up to 5 emails), (3) preferences (timezone, notification settings). Validate each step before allowing next. Persist progress to localStorage so users can resume. Use React Hook Form with Zod validation. Match the existing form styles in src/components/forms/.

Cuándo usarlo: formularios complejos de varios pasos con validación y gestión de estado.

Consejo pro: usa el modo Plan de SuperBuilder para funciones de varios pasos. Esbozará primero el plan de implementación, dejándote corregir el rumbo antes de que se escriba nada de código.

17. La implementación de búsqueda

Prompt:

Add full-text search to the blog. Index the title, body, and tags fields of posts. Create a GET /api/search?q=query endpoint that returns ranked results with highlighted snippets. Use PostgreSQL's tsvector/tsquery for search. Add debounced search-as-you-type to the existing SearchBar component in src/components/SearchBar.tsx.

Cuándo usarlo: implementar funcionalidad de búsqueda con componentes tanto de backend como de frontend.

Consejo pro: especifica la tecnología de búsqueda (full-text de Postgres, Elasticsearch, Meilisearch) explícitamente. Cada una tiene patrones de implementación muy distintos.

18. El flujo de autenticación

Prompt:

Add Google OAuth login alongside the existing email/password auth. Use the Authorization Code flow with PKCE. Create the OAuth callback handler at /api/auth/google/callback. If the Google email matches an existing account, link them. If not, create a new account. Store the Google ID in a new oauth_providers table. Keep the existing auth middleware unchanged.

Cuándo usarlo: añadir un método de autenticación a un sistema de auth existente.

Consejo pro: especifica el flujo de OAuth exacto (Authorization Code, PKCE, Implicit) y cómo manejar el escenario de vinculación de cuentas existentes. Estas son las dos mayores fuentes de bugs de autenticación.

19. La función en tiempo real

Prompt:

Add real-time presence indicators to the document editor. Show which users are currently viewing or editing the document. Use WebSocket connections (we already have Socket.IO set up in src/ws/server.ts). Broadcast join/leave events. Show colored dots next to user avatars with a tooltip showing "Viewing" or "Editing". Clean up presence on disconnect and on 30-second heartbeat timeout.

Cuándo usarlo: construir funciones colaborativas o en tiempo real sobre una configuración de WebSocket existente.

Consejo pro: especifica siempre el comportamiento de limpieza/timeout para funciones en tiempo real. Sin ello, Claude a menudo se saltará la gestión de desconexiones.

20. El trabajo en segundo plano

Prompt:

Create a background job that generates monthly usage reports for all active organizations. For each org, query the events table for the past month, calculate total API calls, unique users, and peak concurrent sessions. Generate a PDF report using the existing PDFService and email it to org admins. Schedule it to run on the 1st of each month at 6 AM UTC. Use the existing BullMQ setup in src/jobs/.

Cuándo usarlo: trabajo en segundo plano programado o encolado con varios pasos de procesamiento.

Consejo pro: incluye la programación, las fuentes de datos, el formato de salida y el método de entrega. Los trabajos en segundo plano tienen más piezas móviles de lo que parecen.

Prompts de refactorización (21-30)

La refactorización es delicada porque el objetivo es cambiar la estructura sin cambiar el comportamiento. Estos prompts ayudan a Claude Code a refactorizar de forma segura.

21. El extraer-y-reutilizar

Prompt:

The date formatting logic is duplicated in src/components/OrderList.tsx, src/components/InvoiceTable.tsx, and src/components/ActivityFeed.tsx. Extract it into a shared utility in src/utils/dates.ts and update all three components to use the shared version. Keep the exact same formatting behavior.

Cuándo usarlo: has detectado duplicación y quieres aplicar DRY.

Consejo pro: enumerar cada archivo que contiene la duplicación evita que Claude se salte alguno. Usa grep para encontrar todas las apariciones primero.

22. La refactorización de modularización

Prompt:

The file src/api/orders.ts is 1,200 lines and handles creation, validation, payment, fulfillment, and cancellation. Split it into separate modules: order-creation.ts, order-validation.ts, order-payment.ts, order-fulfillment.ts, and order-cancellation.ts. Keep the same public API by re-exporting from an index.ts file. Don't change any behavior.

Cuándo usarlo: un archivo ha crecido demasiado y necesita dividirse en módulos enfocados.

Consejo pro: especificar los nombres exactos de los módulos y la estrategia de re-exportación evita que Claude tome decisiones organizativas distintas a las que pretendías.

23. La migración de patrón

Prompt:

Migrate the user authentication from express-session to JWT tokens. Replace session-based middleware in src/middleware/auth.ts with JWT verification. Update the login endpoint to return access + refresh tokens. Add a token refresh endpoint. Keep the same request.user interface so downstream handlers don't need changes.

Cuándo usarlo: migrar de un patrón o librería a otra preservando el contrato de la API.

Consejo pro: usa el modo Verify de SuperBuilder tras esta refactorización. Comprobará que la migración esté completa y que no queden referencias a sesiones.

24. La revisión del manejo de errores

Prompt:

The API error handling is inconsistent. Some endpoints return { error: string }, others return { message: string, code: number }, and some throw unhandled exceptions. Create a centralized AppError class with status code, error code, and message. Add an Express error middleware that catches AppErrors and formats consistent responses. Refactor the 5 most critical endpoints in src/api/ to use the new pattern.

Cuándo usarlo: tu manejo de errores ha crecido orgánicamente y necesita estandarización.

Consejo pro: pídele a Claude que refactorice unos pocos endpoints primero en lugar de todos. Revisa el patrón y luego haz el resto en un prompt de seguimiento.

25. La conversión a async/await

Prompt:

Convert all callback-based database operations in src/db/queries/ to use async/await with try/catch error handling. There are 12 files using the callback pattern with db.query(sql, params, (err, results) => {}). Preserve the same error messages and return types. Update the calling code as needed.

Cuándo usarlo: modernizar código con muchos callbacks a async/await.

Consejo pro: si tienes tests, menciónalos para que Claude los ejecute tras cada conversión y verifique que nada se rompió.

26. La refactorización de gestión de estado

Prompt:

The dashboard page passes props through 6 levels of components (prop drilling). Refactor to use React Context for the dashboard state. Create a DashboardProvider with the current filters, date range, and selected metrics. Replace prop drilling with useContext hooks. Keep the component rendering behavior identical.

Cuándo usarlo: el prop drilling se ha descontrolado y quieres introducir context o un gestor de estado.

Consejo pro: menciona las props específicas que se están propagando para que Claude sepa exactamente qué elevar al context.

27. La externalización de configuración

Prompt:

There are hardcoded values throughout the codebase: API URLs, timeout durations, retry counts, feature flags, and rate limits. Find all hardcoded configuration values in src/services/ and src/api/ and move them to a centralized config module at src/config/index.ts that reads from environment variables with sensible defaults.

Cuándo usarlo: los valores codificados están dispersos por la base de código y necesitan centralizarse.

Consejo pro: pídele a Claude que enumere todos los valores codificados descubiertos antes de hacer cambios para que puedas revisar cuáles deberían ser realmente configurables.

28. La mejora de seguridad de tipos

Prompt:

The API response types are using `any` in 15+ places across src/hooks/ and src/api/client.ts. Replace every `any` with proper TypeScript types. Infer types from the API schemas in src/api/schemas/ where possible. Create new interface files in src/types/ for any response shapes that don't have types yet.

Cuándo usarlo: tu base de código tiene agujeros de seguridad de tipos que hay que tapar.

Consejo pro: usa el modo Verify de SuperBuilder tras este cambio para confirmar que no quedan tipos any en los archivos objetivo.

29. El reemplazo de dependencias

Prompt:

Replace moment.js with date-fns throughout the project. We use moment for: formatting dates, calculating relative time, parsing ISO strings, and timezone conversions. Find all moment imports, replace with equivalent date-fns functions, and remove moment from package.json. Run the existing tests to verify nothing broke.

Cuándo usarlo: reemplazar una dependencia pesada o en desuso por una alternativa moderna.

Consejo pro: nombra los casos de uso específicos de la librería antigua para que Claude sepa qué funciones de reemplazo usar. "Reemplaza X con Y" por sí solo es demasiado vago.

30. La adición de capa de arquitectura

Prompt:

Add a service layer between the API route handlers and the database queries. Currently, route handlers in src/api/ call database functions directly. Create service files in src/services/ that contain the business logic. Route handlers should only handle HTTP concerns (parsing request, sending response). Services handle validation, business rules, and data access. Start with the users and orders modules.

Cuándo usarlo: añadir una capa arquitectónica (servicio, repositorio, etc.) para mejorar la separación de responsabilidades.

Consejo pro: elige 2-3 módulos para refactorizar primero, revisa el patrón y luego pídele a Claude que lo aplique al resto. Esto evita la deriva arquitectónica.

Prompts de testing (31-35)

Los prompts de testing funcionan mejor cuando especificas el framework de testing, el alcance y los casos límite que te importan.

31. El generador de tests unitarios

Prompt:

Write unit tests for the PricingCalculator class in src/services/pricing.ts. Cover: basic price calculation, percentage discounts, fixed-amount discounts, discount stacking, tax calculation, currency rounding, zero-quantity edge case, and negative price validation. Use Jest. Mock the TaxService dependency.

Cuándo usarlo: necesitas una cobertura exhaustiva de tests unitarios para un módulo específico.

Consejo pro: enumerar los escenarios específicos evita que Claude solo testee el camino feliz. Incluye siempre al menos 3 casos límite en tu prompt.

32. El constructor de tests de integración

Prompt:

Write integration tests for the POST /api/orders endpoint. Test: successful order creation, insufficient inventory, invalid product ID, unauthenticated request, expired discount code, and concurrent order attempts for the last item in stock. Use supertest with a test database. Set up and tear down test data in beforeEach/afterEach.

Cuándo usarlo: testear un endpoint de API con interacciones de base de datos y múltiples escenarios de fallo.

Consejo pro: menciona la estrategia de base de datos de pruebas (SQLite en memoria, Docker Postgres, esquema de pruebas) para que Claude configure las fixtures correctamente.

33. El creador de tests de snapshot

Prompt:

Add React Testing Library snapshot tests for all components in src/components/ui/. For each component, render it with default props and with all prop variants (sizes, colors, disabled state, loading state). Use @testing-library/react with Jest. Group tests by component.

Cuándo usarlo: quieres una cobertura base de regresión visual para una librería de componentes de UI.

Consejo pro: los tests de snapshot son más útiles para componentes estables. Sáltatelos para componentes aún en desarrollo activo.

34. La fábrica de fixtures de test

Prompt:

Create test fixture factories in src/test/factories/ for: User, Team, Project, and Invoice. Each factory should generate realistic fake data using @faker-js/faker. Support overriding any field. Support creating related objects (e.g., createTeamWithMembers(count)). Include TypeScript types for all factory return values.

Cuándo usarlo: necesitas generadores de datos de test reutilizables que produzcan fixtures realistas y tipadas.

Consejo pro: este es un gran prompt para ejecutar con el modo Plan de SuperBuilder: diseñará la API de la fábrica antes de implementarla.

35. La suite de tests de casos límite

Prompt:

The parseUserInput() function in src/utils/input-parser.ts handles free-text search queries. Write tests for: empty string, single character, 10,000 character input, SQL injection attempts, XSS payloads, Unicode characters (emoji, CJK, RTL), strings with only whitespace, and inputs with special regex characters. Use Jest. Each test should verify the function neither throws nor returns unsafe content.

Cuándo usarlo: endurecer un manejador de entrada de cara al público contra entradas maliciosas o inesperadas.

Consejo pro: los tests de casos límite relacionados con la seguridad son los de mayor valor que puedes escribir. Incluye siempre tests de inyección y codificación para los manejadores de entrada de usuario.

Prompts de documentación (36-40)

Los buenos prompts de documentación le dicen a Claude quién es la audiencia y qué formato usar.

36. El generador de documentación de API

Prompt:

Generate OpenAPI 3.0 documentation for all endpoints in src/api/v1/. Include: path, method, description, request body schema (from Zod schemas), response schemas for 200/400/401/404/500, and example request/response pairs. Output as a YAML file at docs/api/openapi.yaml.

Cuándo usarlo: necesitas documentación de API legible por máquina generada a partir de tu código existente.

Consejo pro: apunta a Claude a tus esquemas de validación (Zod, Joi, Yup) para que pueda generar tipos de request/response precisos automáticamente.

37. El redactor de README

Prompt:

Write a README.md for this project. Include: one-paragraph description, tech stack list, prerequisites, local development setup (step by step), environment variables table (from .env.example), available npm scripts, project structure overview (top-level directories only), contributing guidelines, and license. Keep the tone professional and concise.

Cuándo usarlo: empezar un proyecto nuevo o renovar un README descuidado.

Consejo pro: menciona "from .env.example" o archivos fuente similares para que Claude genere documentación de variables de entorno precisa en lugar de adivinar.

38. El registro de decisión de arquitectura

Prompt:

Write an ADR (Architecture Decision Record) for our decision to migrate from REST to GraphQL for the mobile API. Context: mobile app makes 12+ requests per screen, REST over-fetching wastes bandwidth. Decision: GraphQL for mobile, keep REST for third-party integrations. Consequences: need to maintain two API layers, team needs GraphQL training. Use the standard ADR format (Title, Status, Context, Decision, Consequences).

Cuándo usarlo: documentar una decisión arquitectónica para futuros miembros del equipo.

Consejo pro: dale a Claude el contexto, la decisión y las consecuencias; estructurará el ADR correctamente. Estos documentos son invaluables seis meses después.

39. El documentador de comentarios de código

Prompt:

Add JSDoc comments to all exported functions and classes in src/services/billing.ts. Include: description, @param with types and descriptions, @returns with type and description, @throws for known error conditions, and @example with realistic usage. Don't change any code, only add documentation comments.

Cuándo usarlo: necesitas añadir documentación en línea a un módulo crítico.

Consejo pro: "Don't change any code" es una restricción importante. Sin ella, Claude podría refactorizar mientras documenta.

40. El creador de runbooks

Prompt:

Create an incident runbook for "Database connection pool exhaustion" at docs/runbooks/db-pool-exhaustion.md. Include: symptoms (what alerts fire, what users see), diagnosis steps (which metrics to check, what queries to run), mitigation steps (ordered from least to most disruptive), root cause investigation checklist, and post-incident follow-up tasks. Write it for an on-call engineer who may not be familiar with this specific system.

Cuándo usarlo: crear documentación operativa para modos de fallo conocidos.

Consejo pro: especifica la audiencia ("on-call engineer who may not be familiar") para establecer el nivel de detalle correcto. Los runbooks que asumen demasiado conocimiento son inútiles a las 3 de la madrugada.

Prompts de revisión de código (41-45)

Claude Code es un excelente revisor automatizado cuando se le dan las áreas de enfoque correctas.

41. La auditoría de seguridad

Prompt:

Review src/api/ for security vulnerabilities. Check for: SQL injection (even with ORM), XSS in server-rendered content, missing authentication on endpoints, overly permissive CORS, sensitive data in logs, insecure direct object references (IDOR), and missing rate limiting. Report findings with severity (critical/high/medium/low) and specific file:line references.

Cuándo usarlo: quieres una revisión enfocada en la seguridad de tu capa de API.

Consejo pro: usa aquí el modo Ask de SuperBuilder. Analizará y explicará los hallazgos sin modificar nada de código, que es exactamente lo que quieres para una revisión.

42. La revisión de rendimiento

Prompt:

Review the React components in src/components/Dashboard/ for performance issues. Check for: unnecessary re-renders, missing useMemo/useCallback, expensive calculations in render, large component trees that should be split, missing React.lazy for heavy components, and unoptimized list rendering. Suggest fixes for each issue found.

Cuándo usarlo: tu interfaz va lenta y quieres una auditoría sistemática de rendimiento.

Consejo pro: si tienes la salida del profiler de React DevTools, pega el resumen. Los datos cuantitativos ayudan a Claude a priorizar las mayores victorias.

43. La revisión de accesibilidad

Prompt:

Audit the components in src/components/ui/ for WCAG 2.1 AA compliance. Check for: missing aria labels, insufficient color contrast, keyboard navigation support, focus management in modals/dropdowns, screen reader compatibility, missing alt text, and proper heading hierarchy. List violations with WCAG success criterion references.

Cuándo usarlo: necesitas asegurar que tus componentes de UI cumplen con los estándares de accesibilidad.

Consejo pro: pídele a Claude que corrija las violaciones críticas en un prompt de seguimiento. Separar la auditoría de la corrección te da la oportunidad de priorizar.

44. La auditoría de dependencias

Prompt:

Review package.json for: outdated dependencies with known security vulnerabilities, unused dependencies (not imported anywhere in src/), dependencies that should be devDependencies, duplicate packages that serve the same purpose, and excessively heavy packages with lighter alternatives. Output a prioritized action list.

Cuándo usarlo: revisión periódica de higiene de dependencias.

Consejo pro: ejecuta npm audit y pega la salida junto a este prompt para una revisión más completa.

45. La revisión de calidad de código

Prompt:

Review the last 5 commits on this branch for code quality issues. Check for: inconsistent naming conventions, functions longer than 50 lines, deeply nested conditionals (> 3 levels), magic numbers without named constants, error messages that don't help with debugging, and any patterns that deviate from the rest of the codebase. Be specific with file and line references.

Cuándo usarlo: comprobación de calidad de código previa al merge en una rama de función.

Consejo pro: "Patterns that deviate from the rest of the codebase" es una instrucción potente: usa tu base de código existente como referencia de estilo.

Prompts de DevOps (46-50)

Los prompts de DevOps funcionan mejor cuando especificas la plataforma, la configuración existente y el destino de despliegue.

46. El constructor de pipeline de CI

Prompt:

Create a GitHub Actions CI pipeline in .github/workflows/ci.yml. Steps: (1) checkout, (2) setup Node 20, (3) npm ci with cache, (4) TypeScript type check, (5) ESLint, (6) Jest unit tests with coverage, (7) build, (8) upload coverage to Codecov. Run on push to main and on all PRs. Fail fast. Add a matrix for Node 18 and 20.

Cuándo usarlo: configurar un nuevo pipeline de CI o renovar uno existente.

Consejo pro: enumera los pasos exactos en orden. Los pipelines de CI son secuenciales por naturaleza, y el orden importa para un fallo rápido.

47. La optimización de Docker

Prompt:

Optimize the Dockerfile in the project root. Current image is 2.1GB. Use multi-stage build: build stage with full node image, production stage with node:20-alpine. Only copy package files first for layer caching. Prune devDependencies in production. Set NODE_ENV=production. Add .dockerignore for node_modules, .git, tests, and docs. Target final image under 200MB.

Cuándo usarlo: tu imagen de Docker está inflada y necesita adelgazar.

Consejo pro: incluye el tamaño actual de la imagen y el tamaño objetivo. Los números concretos le dan a Claude una meta medible.

48. La infraestructura como código

Prompt:

Create Terraform configuration for deploying this Node.js app to AWS. Resources: ECS Fargate cluster, ALB with HTTPS, RDS PostgreSQL (db.t3.micro), ElastiCache Redis, S3 bucket for uploads, CloudWatch log groups. Use separate files: main.tf, variables.tf, outputs.tf. Parameterize: region, instance sizes, database credentials. Add a terraform.tfvars.example.

Cuándo usarlo: configurar infraestructura en la nube desde cero con IaC.

Consejo pro: especifica siempre el proveedor de nube, el nivel de servicio (Fargate vs EC2, RDS vs Aurora) y si esto es dev/staging/producción. Las implicaciones de coste varían drásticamente.

49. La configuración de monitorización

Prompt:

Add application monitoring to the Express app. Implement: (1) request duration histogram middleware, (2) error rate counter by endpoint, (3) active connection gauge, (4) database query duration tracking, (5) /metrics endpoint in Prometheus exposition format. Use prom-client library. Don't add external services -- just expose the metrics endpoint for scraping.

Cuándo usarlo: añadir observabilidad a tu aplicación.

Consejo pro: especifica "Prometheus format" o "StatsD" u "OpenTelemetry" por adelantado. El patrón de recolección de métricas es fundamentalmente distinto para cada uno.

50. El script de despliegue

Prompt:

Create a deployment script at scripts/deploy.sh that: (1) runs all tests, (2) builds the production bundle, (3) creates a git tag with semantic version from package.json, (4) builds and pushes Docker image to ECR with version tag, (5) updates the ECS service with the new task definition, (6) waits for deployment to stabilize (5 min timeout), (7) rolls back if health check fails. Add --dry-run flag that prints commands without executing.

Cuándo usarlo: crear un pipeline de despliegue automatizado con capacidad de rollback.

Consejo pro: la petición del flag --dry-run es importante. Los scripts de despliegue sin un modo de simulación son peligrosos para iterar.

Modos de ejecución de SuperBuilder: haciendo los prompts 10x más eficaces

Cada prompt de arriba funciona genial en Claude Code estándar. Pero con SuperBuilder, puedes envolver cualquier prompt en un modo de ejecución que cambia fundamentalmente cómo aborda Claude la tarea.

SuperBuilder ofrece cinco modos de ejecución que envuelven tu prompt con instrucciones especializadas:

Modo Plan: piensa antes de programar

Qué hace: envuelve tu prompt con instrucciones para analizar la base de código, esbozar un plan de implementación paso a paso y esperar tu aprobación antes de escribir nada de código.

Mejor para: prompts de creación de funciones (11-20), refactorizaciones arquitectónicas (22, 30) y cualquier tarea en la que quieras revisar el enfoque antes de comprometerte con él.

Ejemplo: enviar el prompt n.º 16 (formulario de varios pasos) en modo Plan produce un plan de implementación numerado que cubre la estructura de componentes, la estrategia de validación, la gestión de estado y la persistencia en localStorage, antes de que se escriba una sola línea de código.

Cuándo usarlo: no estás seguro del enfoque de implementación, o la tarea es lo bastante compleja como para que corregir el rumbo a mitad de la implementación resulte caro.

Modo Debug: depuración guiada por hipótesis

Qué hace: transforma tu informe de bug en una sesión de depuración estructurada. Claude genera hipótesis sobre la causa raíz, las clasifica por probabilidad y prueba cada una sistemáticamente con evidencia.

Mejor para: prompts de corrección de bugs (1-10), especialmente condiciones de carrera (n.º 5), fallos silenciosos (n.º 3) y corrupción de datos (n.º 10).

Ejemplo: enviar el prompt n.º 5 (condición de carrera) en modo Debug produce:

• Hipótesis 1: la invalidación de caché ocurre antes de que se confirme la escritura en la BD (probabilidad: alta)
• Hipótesis 2: el retraso de la réplica de lectura devuelve datos obsoletos (probabilidad: media)
• Hipótesis 3: la caché del navegador sirve una respuesta obsoleta (probabilidad: baja)

Luego Claude prueba cada hipótesis con análisis de código dirigido y recolección de evidencia.

Cuándo usarlo: el bug no es obvio y quieres una investigación sistemática en lugar de un enfoque de prueba y error.

Modo Verify: comprueba tu trabajo

Qué hace: después de hacer cambios, Claude vuelve a leer todos los archivos modificados y verifica que los cambios sean correctos, completos y no introduzcan nuevos problemas.

Mejor para: prompts de refactorización (21-30), reemplazos de dependencias (n.º 29) y migraciones de patrones (n.º 23).

Ejemplo: tras ejecutar el prompt n.º 29 (reemplazar moment.js por date-fns), el modo Verify escanea cada archivo en busca de imports de moment restantes, comprueba que todas las operaciones de fecha produzcan una salida idéntica y valida que los tests sigan pasando.

Cuándo usarlo: acabas de hacer cambios amplios y quieres la confianza de que no se ha pasado nada por alto.

Modo Ask: explica sin cambiar

Qué hace: Claude analiza y explica sin modificar ningún archivo. Análisis y recomendaciones puros.

Mejor para: prompts de revisión de código (41-45), comprensión de arquitectura y aprendizaje de bases de código desconocidas.

Ejemplo: enviar el prompt n.º 41 (auditoría de seguridad) en modo Ask produce un informe detallado de vulnerabilidades con referencias de archivos y valoraciones de severidad, sin tocar nada de código.

Cuándo usarlo: quieres información y análisis, no cambios de código. Revisiones, auditorías y transferencia de conocimiento.

Modo Normal: simplemente hazlo

Qué hace: comportamiento estándar de Claude Code. Lee archivos, hace cambios, ejecuta comandos.

Mejor para: todo lo demás. La mayoría de los 50 prompts funcionan excelentemente en modo Normal cuando el prompt en sí es claro y específico.

Prompt en crudo vs. modo Debug de SuperBuilder: una comparación real

Para ilustrar cómo los modos de ejecución cambian los resultados, aquí está el mismo bug investigado de dos formas distintas.

El bug

Los usuarios reportan que las actualizaciones de perfil a veces "no se guardan". No hay errores en la interfaz. La API devuelve 200. Pero la siguiente carga de página muestra datos antiguos.

Prompt en crudo (modo Normal)

Profile updates aren't saving. The API returns 200 but the data reverts on refresh. Check src/api/profile.ts and src/cache/user-cache.ts.

Qué sucede: Claude lee ambos archivos, detecta que el TTL de la caché es de 5 minutos y sugiere añadir cache.invalidate(userId) tras la actualización de la base de datos. Esto podría arreglar el problema, o podría ser uno de varios factores contribuyentes.

Prompt en modo Debug de SuperBuilder

El mismo prompt, pero enviado en modo Debug. SuperBuilder lo envuelve con instrucciones para generar hipótesis y probarlas:

Qué sucede:

1. Generación de hipótesis:

   • H1: la caché no se invalida tras la escritura (alta probabilidad)
   • H2: la transacción de la base de datos no se confirma antes de la respuesta (media)
   • H3: una CDN/proxy está cacheando la respuesta del GET (media)
   • H4: una actualización optimista de la interfaz enmascara una escritura fallida (baja)

2. Recolección de evidencia para cada hipótesis:

   • H1: lee el código de la caché, no encuentra ninguna llamada de invalidación: confirmada
   • H2: lee el código de la BD, encuentra que la escritura usa una transacción pero la respuesta se envía dentro del callback de la transacción: también confirmada, este es un segundo bug
   • H3: comprueba las cabeceras de respuesta, no hay cabeceras Cache-Control configuradas: problema potencial
   • H4: lee el código del frontend, no hay actualizaciones optimistas: descartada

3. Solución: aborda ambas causas raíz (invalidación de caché Y mover la respuesta fuera del commit de la transacción), además de añadir cabeceras Cache-Control como medida defensiva.

El enfoque de modo Debug encontró un segundo bug que el prompt en crudo se perdió por completo. Esta es la diferencia entre tratar los síntomas y encontrar las causas raíz.

Consejos y trucos de Claude Code

Más allá de los prompts específicos, aquí tienes consejos y trucos generales de Claude Code que mejoran los resultados en todas las categorías:

1. Usa las rutas de archivo como anclas de contexto

En lugar de describir dónde vive el código, da las rutas exactas:

• Mal: "El servicio de usuario maneja la autenticación"
• Bien: "La lógica de auth en src/services/auth/login.ts (líneas 45-80)"

2. Referencia patrones existentes

Claude Code produce código más consistente cuando lo apuntas a un ejemplo existente:

Follow the same patterns used in src/api/users.ts for error handling, validation, and response formatting.

3. Establece restricciones explícitas

Las restricciones evitan que Claude haga cambios no deseados:

Don't add new npm dependencies. Don't modify the database schema. Keep backward compatibility with the v1 API.

4. Encadena prompts para trabajos complejos

Para tareas grandes, usa varios prompts enfocados:

1. Modo Plan: "Diseña la arquitectura para un sistema de notificaciones"
2. Modo Normal: "Implementa el servicio de notificaciones según el plan anterior"
3. Modo Normal: "Añade tests para el servicio de notificaciones"
4. Modo Verify: "Revisa el sistema de notificaciones en busca de casos límite y manejo de errores faltante"

5. Incluye criterios de aceptación

Dile a Claude cómo es "terminado":

This is done when: (1) the migration runs without errors, (2) existing data is preserved, (3) the rollback migration restores the original schema, and (4) all existing tests pass.

6. Aprovecha el contexto de proyecto de SuperBuilder

SuperBuilder mantiene el contexto entre conversaciones dentro de un proyecto. Tu archivo CLAUDE.md, el indexador de archivos y el historial de conversación significan que Claude ya conoce tu base de código. Puedes escribir prompts más cortos porque el contexto ya está cargado.

7. Usa el modo correcto para la tarea correcta

Preguntas frecuentes

¿Qué hace que un prompt de Claude Code sea bueno?

Un buen prompt de Claude Code tiene cuatro elementos: (1) una descripción clara del problema o el objetivo, (2) rutas de archivo y contexto relevantes, (3) restricciones explícitas y (4) una descripción de cómo es el éxito. Los prompts vagos producen resultados vagos.

¿Qué longitud deberían tener mis prompts de Claude Code?

No hay una longitud ideal: la claridad importa más que la brevedad. Un prompt de 3 frases con rutas de archivo exactas y restricciones supera a un prompt de 3 párrafos lleno de contexto de fondo que Claude no necesita. Incluye solo la información que cambia el resultado.

¿Funcionan estos prompts con otras herramientas de programación con IA?

La mayoría de estos prompts funcionan con cualquier agente de programación con IA (Cursor, Copilot, Aider). Sin embargo, las secciones de modos de ejecución (plan, debug, verify, ask) son específicas de SuperBuilder y de cómo envuelve los prompts para Claude Code.

¿Cuál es la diferencia entre el modo Plan y el modo Ask?

El modo Plan produce un plan de implementación que Claude ejecutará tras tu aprobación. El modo Ask solo analiza y explica: no se hacen cambios de código. Usa el modo Plan cuando quieras construir algo. Usa el modo Ask cuando quieras entender algo.

¿Cómo funciona el modo Debug en SuperBuilder?

El modo Debug envuelve tu prompt con instrucciones para generar hipótesis clasificadas sobre la causa raíz, reunir evidencia para cada hipótesis y corregir solo los problemas confirmados. Es significativamente más exhaustivo que un prompt estándar de "arregla este bug" porque elimina sistemáticamente las posibles causas en lugar de saltar a la primera solución plausible.

¿Puedo combinar modos de ejecución?

Sí, y deberías. Un flujo de trabajo común es: modo Debug para investigar un bug, modo Normal para implementar la solución y modo Verify para confirmar que la solución está completa. SuperBuilder hace que cambiar entre modos sea un solo clic.

¿Estos prompts son gratuitos de usar?

Los prompts en sí son gratuitos: úsalos como quieras. Claude Code requiere una suscripción a la API de Anthropic. SuperBuilder ofrece la app de escritorio con modos de ejecución, gestión de proyectos e historial de conversación sobre Claude Code.

Empieza a escribir mejores prompts hoy

La diferencia entre un desarrollador que obtiene resultados mediocres de la IA y uno que obtiene código listo para producción no es el modelo: es el prompt. Estos 50 prompts son patrones probados en batalla que producen resultados de alta calidad de forma constante con Claude Code.

Para la mejor experiencia, pruébalos en SuperBuilder, donde los modos de ejecución, el contexto de proyecto y el historial de conversación hacen cada prompt más eficaz. Solo el modo Debug cambiará para siempre tu forma de abordar la corrección de bugs.

¿Listo para subir de nivel tu flujo de trabajo con Claude Code? Descarga SuperBuilder y empieza con los prompts que coincidan con tu tarea actual. Los resultados hablan por sí solos.