¿Qué hace Optimizador de Prompts?
Analiza un borrador de prompt, lo critica, lo asigna a los componentes del ecosistema ECC y genera un prompt optimizado completo que el usuario puede copiar y pegar para ejecutar.
Cuándo usarlo
- El usuario dice "optimiza este prompt", "mejora mi prompt", "reescribe este prompt"
- El usuario dice "ayúdame a escribir un mejor prompt para..."
- El usuario dice "cuál es la mejor forma de pedirle a Claude Code que..."
- El usuario dice "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令"
- El usuario pega un borrador de prompt y pide retroalimentación o mejora
- El usuario dice "no sé cómo hacer un prompt para esto"
- El usuario dice "cómo debería usar ECC para..."
- El usuario invoca explícitamente
/prompt-optimize
Cuándo NO usarlo
- El usuario quiere que la tarea se ejecute directamente (solo ejecútala)
- El usuario dice "优化代码", "优化性能", "optimiza este código", "optimiza el rendimiento" — son tareas de refactorización, no de optimización de prompts
- El usuario pregunta sobre la configuración de ECC (usa
configure-eccen su lugar) - El usuario quiere un inventario de skills (usa
skill-stocktakeen su lugar) - El usuario dice "solo hazlo" o "直接做"
Cómo funciona
Solo asesoría — no ejecutes la tarea del usuario.
NO escribas código, crees archivos, ejecutes comandos ni realices ninguna acción de implementación. Tu ÚNICA salida es un análisis más un prompt optimizado.
Si el usuario dice "solo hazlo", "直接做", o "no optimices, solo ejecuta", no entres en modo de implementación dentro de esta skill. Indícale al usuario que esta skill solo produce prompts optimizados, y ordénale que haga una solicitud de tarea normal si desea ejecución.
Ejecuta este proceso de 6 fases de forma secuencial. Presenta los resultados usando el Formato de Salida que se indica a continuación.
Proceso de análisis
Fase 0: Detección del proyecto
Antes de analizar el prompt, detecta el contexto del proyecto actual:
- Verifica si existe un archivo
CLAUDE.mden el directorio de trabajo — léelo para conocer las convenciones del proyecto - Detecta el stack tecnológico a partir de los archivos del proyecto:
package.json→ Node.js / TypeScript / React / Next.jsgo.mod→ Gopyproject.toml/requirements.txt→ PythonCargo.toml→ Rustbuild.gradle/pom.xml→ Java / Kotlin / Spring BootPackage.swift→ SwiftGemfile→ Rubycomposer.json→ PHP*.csproj/*.sln→ .NETMakefile/CMakeLists.txt→ C / C++cpanfile/Makefile.PL→ Perl
- Anota el stack tecnológico detectado para usarlo en la Fase 3 y la Fase 4
Si no se encuentran archivos del proyecto (por ejemplo, el prompt es abstracto o para un proyecto nuevo), omite la detección y marca "stack tecnológico desconocido" en la Fase 4.
Fase 1: Detección de la intención
Clasifica la tarea del usuario en una o más categorías:
| Categoría | Palabras clave | Ejemplo |
|---|---|---|
| Nueva funcionalidad | build, create, add, implement, 创建, 实现, 添加 | "Crea una página de inicio de sesión" |
| Corrección de errores | fix, broken, not working, error, 修复, 报错 | "Arregla el flujo de autenticación" |
| Refactorización | refactor, clean up, restructure, 重构, 整理 | "Refactoriza la capa de API" |
| Investigación | how to, what is, explore, investigate, 怎么, 如何 | "Cómo añadir SSO" |
| Pruebas | test, coverage, verify, 测试, 覆盖率 | "Añade pruebas para el carrito" |
| Revisión | review, audit, check, 审查, 检查 | "Revisa mi PR" |
| Documentación | document, update docs, 文档 | "Actualiza la documentación de la API" |
| Infraestructura | deploy, CI, docker, database, 部署, 数据库 | "Configura el pipeline de CI/CD" |
| Diseño | design, architecture, plan, 设计, 架构 | "Diseña el modelo de datos" |
Fase 2: Evaluación del alcance
Si la Fase 0 detectó un proyecto, usa el tamaño del código base como señal. En caso contrario, estima solo a partir de la descripción del prompt y marca la estimación como incierta.
| Alcance | Heurística | Orquestación |
|---|---|---|
| TRIVIAL | Archivo único, < 50 líneas | Ejecución directa |
| BAJO | Componente o módulo único | Comando o skill único |
| MEDIO | Múltiples componentes, mismo dominio | Cadena de comandos + /verify |
| ALTO | Multi-dominio, 5+ archivos | Primero /plan, luego ejecución por fases |
| ÉPICO | Multi-sesión, multi-PR, cambio arquitectónico | Usa la skill blueprint para plan multi-sesión |
Fase 3: Correspondencia con componentes ECC
Asigna intención + alcance + stack tecnológico (de la Fase 0) a componentes ECC específicos.
Por tipo de intención
| Intención | Comandos | Skills | Agentes |
|---|---|---|---|
| Nueva funcionalidad | /plan, /tdd, /code-review, /verify | tdd-workflow, verification-loop | planner, tdd-guide, code-reviewer |
| Corrección de errores | /tdd, /build-fix, /verify | tdd-workflow | tdd-guide, build-error-resolver |
| Refactorización | /refactor-clean, /code-review, /verify | verification-loop | refactor-cleaner, code-reviewer |
| Investigación | /plan | search-first, iterative-retrieval | — |
| Pruebas | /tdd, /e2e, /test-coverage | tdd-workflow, e2e-testing | tdd-guide, e2e-runner |
| Revisión | /code-review | security-review | code-reviewer, security-reviewer |
| Documentación | /update-docs, /update-codemaps | — | doc-updater |
| Infraestructura | /plan, /verify | docker-patterns, deployment-patterns, database-migrations | architect |
| Diseño (MEDIO-ALTO) | /plan | — | planner, architect |
| Diseño (ÉPICO) | — | blueprint (invocar como skill) | planner, architect |
Por stack tecnológico
| Stack tecnológico | Skills adicionales | Agente |
|---|---|---|
| Python / Django | django-patterns, django-tdd, django-security, django-verification, python-patterns, python-testing | python-reviewer |
| Go | golang-patterns, golang-testing | go-reviewer, go-build-resolver |
| Spring Boot / Java | springboot-patterns, springboot-tdd, springboot-security, springboot-verification, java-coding-standards, jpa-patterns | code-reviewer |
| Kotlin / Android | kotlin-coroutines-flows, compose-multiplatform-patterns, android-clean-architecture | kotlin-reviewer |
| TypeScript / React | frontend-patterns, backend-patterns, coding-standards | code-reviewer |
| Swift / iOS | swiftui-patterns, swift-concurrency-6-2, swift-actor-persistence, swift-protocol-di-testing | code-reviewer |
| PostgreSQL | postgres-patterns, database-migrations | database-reviewer |
| Perl | perl-patterns, perl-testing, perl-security | code-reviewer |
| C++ | cpp-coding-standards, cpp-testing | code-reviewer |
| Otro / No listado | coding-standards (universal) | code-reviewer |
Fase 4: Detección de contexto faltante
Examina el prompt en busca de información crítica faltante. Revisa cada elemento y marca si la Fase 0 lo detectó automáticamente o el usuario debe proporcionarlo:
- Stack tecnológico — ¿Detectado en la Fase 0, o debe especificarlo el usuario?
- Alcance objetivo — ¿Se mencionan archivos, directorios o módulos?
- Criterios de aceptación — ¿Cómo saber si la tarea está completa?
- Manejo de errores — ¿Se abordan casos borde y modos de fallo?
- Requisitos de seguridad — ¿Autenticación, validación de entrada, secretos?
- Expectativas de pruebas — ¿Unitarias, integración, E2E?
- Restricciones de rendimiento — ¿Carga, latencia, límites de recursos?
- Requisitos de UI/UX — ¿Especificaciones de diseño, responsive, accesibilidad? (si es frontend)
- Cambios en la base de datos — ¿Esquema, migraciones, índices? (si es capa de datos)
- Patrones existentes — ¿Archivos de referencia o convenciones a seguir?
- Límites del alcance — ¿Qué NO hacer?
Si faltan 3 o más elementos críticos, haz al usuario hasta 3 preguntas de aclaración antes de generar el prompt optimizado. Luego incorpora las respuestas en el prompt optimizado.
Fase 5: Recomendación de flujo de trabajo y modelo
Determina dónde se sitúa este prompt en el ciclo de vida del desarrollo:
Investigación → Planificación → Implementación (TDD) → Revisión → Verificación → Confirmación
Para tareas de alcance MEDIO+, comienza siempre con /plan. Para tareas ÉPICAS, usa la skill blueprint.
Recomendación de modelo (inclúyela en la salida):
| Alcance | Modelo recomendado | Justificación |
|---|---|---|
| TRIVIAL-BAJO | Sonnet 4.6 | Rápido y rentable para tareas sencillas |
| MEDIO | Sonnet 4.6 | Mejor modelo de código para trabajo estándar |
| ALTO | Sonnet 4.6 (principal) + Opus 4.6 (planificación) | Opus para arquitectura, Sonnet para implementación |
| ÉPICO | Opus 4.6 (blueprint) + Sonnet 4.6 (ejecución) | Razonamiento profundo para planificación multi-sesión |
División en múltiples prompts (para alcance ALTO/ÉPICO):
Para tareas que exceden una sola sesión, divídelas en prompts secuenciales:
- Prompt 1: Investigación + Planificación (usa la skill
search-first, luego/plan) - Prompt 2-N: Implementa una fase por prompt (cada una termina con
/verify) - Prompt final: Prueba de integración +
/code-reviewen todas las fases - Usa
/save-sessiony/resume-sessionpara preservar el contexto entre sesiones
Formato de salida
Presenta tu análisis en esta estructura exacta. Responde en el mismo idioma que la entrada del usuario.
Sección 1: Diagnóstico del prompt
- Fortalezas: Enumera lo que el prompt original hace bien.
- Problemas:
Problema Impacto Solución sugerida (problema) (consecuencia) (cómo solucionarlo) - Necesita aclaración: Lista numerada de preguntas que el usuario debería responder. Si la Fase 0 detectó la respuesta automáticamente, indícala en lugar de preguntar.
Sección 2: Componentes ECC recomendados
| Tipo | Componente | Propósito |
|---|---|---|
| Comando | /plan | Planificar la arquitectura antes de codificar |
| Skill | tdd-workflow | Guía de metodología TDD |
| Agente | code-reviewer | Revisión posterior a la implementación |
| Modelo | Sonnet 4.6 | Recomendado para este alcance |
Sección 3: Prompt optimizado — Versión completa
Presenta el prompt optimizado completo dentro de un único bloque de código delimitado. El prompt debe ser autocontenido y listo para copiar y pegar. Incluye:
- Descripción clara de la tarea con contexto
- Stack tecnológico (detectado o especificado)
- Invocaciones de
/commanden las etapas adecuadas del flujo de trabajo - Criterios de aceptación
- Pasos de verificación
- Límites del alcance (qué NO hacer)
Para los elementos que hacen referencia a blueprint, escribe: "Usa la skill blueprint para..." (no /blueprint, ya que blueprint es una skill, no un comando).
Sección 4: Prompt optimizado — Versión rápida
Una versión compacta para usuarios experimentados de ECC. Varía según el tipo de intención:
| Intención | Patrón rápido |
|---|---|
| Nueva funcionalidad | /plan [funcionalidad]. /tdd para implementar. /code-review. /verify. |
| Corrección de errores | /tdd — escribe una prueba que falle para [error]. Corrige hasta que pase. /verify. |
| Refactorización | /refactor-clean [alcance]. /code-review. /verify. |
| Investigación | Usa la skill search-first para [tema]. /plan basado en los hallazgos. |
| Pruebas | /tdd [módulo]. /e2e para flujos críticos. /test-coverage. |
| Revisión | /code-review. Luego usa el agente security-reviewer. |
| Documentación | /update-docs. /update-codemaps. |
| ÉPICO | Usa la skill blueprint para "[objetivo]". Ejecuta las fases con compuertas /verify. |
Sección 5: Justificación de las mejoras
| Mejora | Motivo |
|---|---|
| (qué se añadió) | (por qué es importante) |
Ejemplos
Ejemplo 1: Prompt vago en chino (proyecto detectado)
Entrada del usuario: 帮我写一个用户登录页面
Fase 0 detecta: package.json con Next.js 15, TypeScript, Tailwind CSS
Prompt optimizado (completo):
Usa el stack tecnológico actual del proyecto (Next.js 15 + TypeScript + Tailwind CSS) para implementar una página de inicio de sesión de usuario.
Requisitos técnicos:
- Sigue la estructura de componentes y las convenciones de rutas existentes en el proyecto
- La validación de formularios debe usar el esquema de validación ya presente en el proyecto (comprueba si se usa Zod/Yup/otro)
- Método de autenticación: usa el esquema de autenticación actual del proyecto (si no hay, por defecto JWT)
- Incluye: formulario de inicio de sesión con email/contraseña, validación del formulario, mensajes de error, estado de carga, diseño responsive
Flujo de trabajo:
1. /plan — primero planifica la estructura de componentes y el flujo de autenticación, tomando como referencia los patrones de páginas existentes
2. /tdd — pruebas primero: escribe pruebas unitarias para el formulario de inicio de sesión y pruebas de integración para el flujo de autenticación
3. Implementa la página de inicio de sesión y la lógica de autenticación
4. /code-review — revisa la implementación
5. /verify — verifica que todas las pruebas pasen y la página se renderice correctamente
Requisitos de seguridad:
- La contraseña no debe transmitirse en texto claro
- Prevenir ataques de fuerza bruta (rate limiting)
- Protección contra XSS
- Token CSRF
Criterios de aceptación:
- Todas las pruebas pasan, cobertura del 80%+
- La página se renderiza correctamente en dispositivos móviles y de escritorio
- Inicio de sesión exitoso redirige al dashboard, fallo muestra mensaje de error
No hacer:
- No implementar la página de registro
- No implementar la funcionalidad de "olvidé mi contraseña"
- No modificar la estructura de rutas existente