Optimizador de Prompts

¿Qué hace Optimizador de Prompts?

Analiza un borrador de prompt, critícalo, compáralo con componentes del ecosistema ECC y genera un prompt optimizado listo para copiar y pegar.

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 manera 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

No Usar Cuando

• El usuario quiere que la tarea se haga directamente (simplemente 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-ecc en su lugar)
• El usuario quiere un inventario de habilidades (usa skill-stocktake en 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 cambies al modo de implementación dentro de esta habilidad. Dile al usuario que esta habilidad solo produce prompts optimizados e indícale que haga una solicitud de tarea normal si desea ejecución.

Ejecuta este pipeline de 6 fases secuencialmente. Presenta los resultados usando el Formato de Salida a continuación.

Pipeline de Análisis

Fase 0: Detección del Proyecto

Antes de analizar el prompt, detecta el contexto actual del proyecto:

1. Verifica si existe un CLAUDE.md en el directorio de trabajo — léelo para conocer las convenciones del proyecto
2. Detecta el stack tecnológico a partir de los archivos del proyecto:
   • package.json → Node.js / TypeScript / React / Next.js
   • go.mod → Go
   • pyproject.toml / requirements.txt → Python
   • Cargo.toml → Rust
   • build.gradle / pom.xml → Java / Kotlin (luego verifica si hay quarkus en el archivo de build → Quarkus, o spring-boot → Spring Boot)
   • Package.swift → Swift
   • Gemfile → Ruby
   • composer.json → PHP
   • *.csproj / *.sln → .NET
   • Makefile / CMakeLists.txt → C / C++
   • cpanfile / Makefile.PL → Perl
3. Anota el stack tecnológico detectado para usarlo en la Fase 3 y la Fase 4

Si no se encuentran archivos de 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 Intención

Clasifica la tarea del usuario en una o más categorías:

Categoría	Palabras Clave	Ejemplo
Nueva Funcionalidad	construir, crear, añadir, implementar, 创建, 实现, 添加	"Crear una página de inicio de sesión"
Corrección de Errores	arreglar, roto, no funciona, error, 修复, 报错	"Arreglar el flujo de autenticación"
Refactorización	refactorizar, limpiar, reestructurar, 重构, 整理	"Refactorizar la capa de API"
Investigación	cómo, qué es, explorar, investigar, 怎么, 如何	"Cómo añadir SSO"
Pruebas	probar, cobertura, verificar, 测试, 覆盖率	"Añadir pruebas para el carrito"
Revisión	revisar, auditar, verificar, 审查, 检查	"Revisar mi PR"
Documentación	documentar, actualizar docs, 文档	"Actualizar la documentación de la API"
Infraestructura	desplegar, CI, docker, base de datos, 部署, 数据库	"Configurar pipeline de CI/CD"
Diseño	diseñar, arquitectura, planificar, 设计, 架构	"Diseñar 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. De lo 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 habilidad única
MEDIO	Múltiples componentes, mismo dominio	Cadena de comandos + /verify
ALTO	Multi-dominio, 5+ archivos	/plan primero, luego ejecución por fases
ÉPICO	Multi-sesión, multi-PR, cambio arquitectónico	Usar la habilidad blueprint para un plan multi-sesión

Fase 3: Emparejamiento 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	Habilidades	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 habilidad)	planner, architect

Por Stack Tecnológico

Stack Tecnológico	Habilidades a Añadir	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	java-reviewer
Quarkus / Java	quarkus-patterns, quarkus-tdd, quarkus-security, quarkus-verification, java-coding-standards, jpa-patterns	java-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

Escanea el prompt en busca de información crítica faltante. Revisa cada elemento y marca si la Fase 0 lo detectó automáticamente o si 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 límite 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 IU/UX — ¿Especificaciones de diseño, responsivo, 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+ elementos críticos, haz hasta 3 preguntas de aclaración al usuario 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 → Planificar → Implementar (TDD) → Revisar → Verificar → Confirmar

Para tareas de alcance MEDIO+, comienza siempre con /plan. Para tareas ÉPICAS, usa la habilidad blueprint.

Recomendación de modelo (incluir en la salida):

Alcance	Modelo Recomendado	Justificación
TRIVIAL-BAJO	Sonnet 5	Rápido y rentable para tareas simples
MEDIO	Sonnet 5	Mejor modelo de codificación para trabajo estándar
ALTO	Sonnet 5 (principal) + Opus 5 (planificación)	Opus para arquitectura, Sonnet para implementación
ÉPICO	Opus 5 (blueprint) + Sonnet 5 (ejecución)	Razonamiento profundo para planificación multi-sesión

División multi-prompt (para alcance ALTO/ÉPICO):

Para tareas que exceden una sola sesión, divide en prompts secuenciales:

• Prompt 1: Investigación + Planificar (usa la habilidad search-first, luego /plan)
• Prompt 2-N: Implementar una fase por prompt (cada una termina con /verify)
• Prompt Final: Prueba de integración + /code-review en todas las fases
• Usa /save-session y /resume-session para 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 debe responder. Si la Fase 0 detectó automáticamente la respuesta, indícala en lugar de preguntar.

Sección 2: Componentes ECC Recomendados

Tipo	Componente	Propósito
Comando	/plan	Planificar la arquitectura antes de codificar
Habilidad	tdd-workflow	Orientación sobre metodología TDD
Agente	code-reviewer	Revisión posterior a la implementación
Modelo	Sonnet 5	Recomendado para este alcance

Sección 3: Prompt Optimizado — Versión Completa

Presenta el prompt optimizado completo dentro de un 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 /comando en las etapas adecuadas del flujo de trabajo
• Criterios de aceptación
• Pasos de verificación
• Límites del alcance (qué NO hacer)

Para elementos que hagan referencia a blueprint, escribe: "Usa la habilidad blueprint para..." (no /blueprint, ya que blueprint es una habilidad, 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 [feature]. /tdd para implementar. /code-review. /verify.
Corrección de Errores	/tdd — escribir prueba fallida para [bug]. Arreglar para que pase. /verify.
Refactorización	/refactor-clean [scope]. /code-review. /verify.
Investigación	Usa la habilidad search-first para [topic]. /plan basado en los hallazgos.
Pruebas	/tdd [module]. /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 habilidad blueprint para "[objective]". Ejecuta fases con puertas de /verify.

Sección 5: Justificación de las Mejoras

Mejora	Razón
(lo que se añadió)	(por qué es importante)

Pie de Página

¿No es lo que necesitas? Dime qué ajustar, o haz una solicitud de tarea normal si deseas ejecución en lugar de optimización de prompts.

---

Ejemplos

Ejemplos de Activación

• "Optimiza este prompt para ECC"
• "Reescribe este prompt para que Claude Code use los comandos correctos"
• "帮我优化这个指令"
• "¿Cómo debería hacer un prompt para ECC para esta tarea?"

Ejemplo 1: Prompt Vago en Chino (Proyecto Detectado)

Entrada del usuario:

帮我写一个用户登录页面

La Fase 0 detecta: package.json con Next.js 15, TypeScript, Tailwind CSS

Prompt Optimizado (Completo):

Usa el stack tecnológico existente del proyecto (Next.js 15 + TypeScript + Tailwind CSS) para implementar una página de inicio de sesión.

Requisitos técnicos:
- Seguir la estructura de componentes y convenciones de enrutamiento existentes del proyecto
- Validación de formularios usando el esquema de validación ya presente en el proyecto (verificar si ya se usa Zod/Yup/otro)
- Método de autenticación: usar el esquema de autenticación existente del proyecto (si no hay, por defecto JWT)
- Incluir: formulario de inicio de sesión con correo/contraseña, validación del formulario, mensajes de error, estado de carga, diseño responsivo

Flujo de trabajo:
1. /plan para planificar la estructura del componente y el flujo de autenticación, consultando los patrones de páginas existentes
2. /tdd prueba primero: escribir pruebas unitarias para el formulario de inicio de sesión y pruebas de integración para el flujo de autenticación
3. Implementar la página de inicio de sesión y la lógica de autenticación
4. /code-review para revisar la implementación
5. /verify para verificar que todas las pruebas pasen y la página se renderice correctamente

Requisitos de seguridad:
- La contraseña no se envía en texto claro
- Prevenir ataques de fuerza bruta (limitación de tasa)
- 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 enrutamiento existente

Ejemplo 2: Prompt Moderado en Inglés

Entrada del usuario:

Add a REST API endpoint for user profile updates with validation

La Fase 0 detecta: go.mod con Go 1.22, enrutador Chi

Prompt Optimizado (Completo):

Añadir un endpoint de API REST para actualizaciones de perfil de usuario (PATCH /api/users/:id).

Stack tecnológico: Go 1.22 + enrutador Chi (detectado del proyecto)

Requisitos:
- PATCH /api/users/:id — actualización parcial del perfil de usuario
- Validación de entrada para campos: nombre, correo, avatar_url, biografía
- Autenticación: requiere token válido, los usuarios solo pueden actualizar su propio perfil
- Devolver 200 con el usuario actualizado en caso de éxito
- Devolver 400 con errores de validación en caso de entrada inválida
- Devolver 401/403 para fallos de autenticación
- Seguir los patrones de API existentes en el código base

Flujo de trabajo:
1. /plan para planificar la estructura del endpoint, la cadena de middleware y la lógica de validación
2. /tdd — escribir pruebas basadas en tablas para éxito, fallo de validación, fallo de autenticación, no encontrado
3. Implementar siguiendo los patrones de manejadores existentes
4. /go-review
5. /verify — ejecutar la suite de pruebas completa, confirmar que no hay regresiones

No hacer:
- Modificar endpoints existentes
- Cambiar el esquema de la base de datos (usar la tabla de usuario existente)
- Añadir nuevas dependencias sin verificar primero las existentes (usar la habilidad search-first)

Ejemplo 3: Proyecto ÉPICO

Entrada del usuario:

Migrate our monolith to microservices

Prompt Optimizado (Completo):

Usa la habilidad blueprint para planificar: "Migrar monolito a arquitectura de microservicios"

Antes de ejecutar, responde estas preguntas en el blueprint:
1. ¿Qué límites de dominio existen en el monolito actual?
2. ¿Qué servicio debería extraerse primero (menor acoplamiento)?
3. Patrón de comunicación: APIs REST, gRPC o basado en eventos (Kafka/RabbitMQ)?
4. Estrategia de base de datos: base de datos compartida inicialmente o base de datos por servicio desde el principio?
5. Destino de despliegue: Kubernetes, Docker Compose o serverless?

El blueprint debería producir fases como:
- Fase 1: Identificar límites de servicio y crear mapa de dominios
- Fase 2: Configurar infraestructura (API gateway, service mesh, CI/CD por servicio)
- Fase 3: Extraer primer servicio (patrón strangler fig)
- Fase 4: Verificar con pruebas de integración, luego extraer el siguiente servicio
- Fase N: Dar de baja el monolito

Cada fase = 1 PR, con puertas de /verify entre fases.
Usa /save-session entre fases