optimizador-de-prompt

Optimizador de Prompt

Analiza un borrador de prompt, lo critica, lo empareja 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 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 pedir 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 (solo ejecútala)
• El usuario dice "优化代码", "优化性能", "optimiza este código", "optimiza rendimiento" — son tareas de refactorización, no de optimización de prompt
• El usuario pregunta sobre configuración de ECC (usa configure-ecc en su lugar)
• El usuario quiere un inventario de skills (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 este skill. Dile al usuario que este skill solo produce prompts optimizados, e instrúyele a que haga una solicitud de tarea normal si quiere 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 del proyecto actual:

1. Verifica si existe un archivo 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 contiene quarkus → 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 usar en las Fases 3 y 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	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 como señal. Si no, 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	/plan primero, luego ejecución por fases
ÉPICO	Multisesión, multi-PR, cambio arquitectónico	Usar skill de blueprint para plan multisesión

Fase 3: Emparejamiento con Componentes ECC

Mapea 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 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 que 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 UI/UX — ¿Especificaciones de diseño, responsive, accesibilidad? (si es frontend)
• Cambios en 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, hazle 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 → Planificar → Implementar (TDD) → Revisar → Verificar → Commit

Para tareas MEDIAS+, siempre comienza con /plan. Para tareas ÉPICAS, usa el skill blueprint.

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

Alcance	Modelo Recomendado	Justificación
TRIVIAL-BAJO	Sonnet 5	Rápido, 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 multisesión

División en múltiples prompts (para alcance ALTO/ÉPICO):

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

• Prompt 1: Investigación + Planificación (usa el 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-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 debería 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
Skill	tdd-workflow	Guía de 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 autónomo y estar listo para copiar y pegar. Incluye:

• Descripción clara de la tarea con contexto
• Stack tecnológico (detectado o especificado)
• Invocaciones de /command 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 hacen referencia a blueprint, escribe: "Usa el skill blueprint para..." (no /blueprint, ya que blueprint es un 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 prueba fallida para [error]. Corrige hasta que pase. /verify.
Refactorización	/refactor-clean [alcance]. /code-review. /verify.
Investigación	Usa el 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 el skill blueprint para "[objetivo]". Ejecuta fases con compuertas /verify.

Sección 5: Justificación de 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 quieres ejecución en lugar de optimización de prompt.

---

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 preguntarle a ECC para esta tarea?"

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 existente del proyecto (Next.js 15 + TypeScript + Tailwind CSS) para implementar una página de inicio de sesión.

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

Flujo de trabajo:
1. /plan para planificar la estructura de componentes y el flujo de autenticación, consultando los patrones de las 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 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 debe transmitirse en texto plano
- 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 enrutamiento existente

Ejemplo 2: Prompt Moderado en Inglés

Entrada del usuario:

Add a REST API endpoint for user profile updates with validation

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

Prompt Optimizado (Completo):

Add a REST API endpoint for user profile updates (PATCH /api/users/:id).

Tech stack: Go 1.22 + Chi router (detected from project)

Requirements:
- PATCH /api/users/:id — partial update of user profile
- Input validation for fields: name, email, avatar_url, bio
- Auth: require valid token, users can only update own profile
- Return 200 with updated user on success
- Return 400 with validation errors on invalid input
- Return 401/403 for auth failures
- Follow existing API patterns in the codebase

Workflow:
1. /plan the endpoint structure, middleware chain, and validation logic
2. /tdd — write table-driven tests for success, validation failure, auth failure, not-found
3. Implement following existing handler patterns
4. /go-review
5. /verify — run full test suite, confirm no regressions

Do not:
- Modify existing endpoints
- Change the database schema (use existing user table)
- Add new dependencies without checking existing ones first (use search-first skill)

Ejemplo 3: Proyecto ÉPICO

Entrada del usuario:

Migrate our monolith to microservices

Prompt Optimizado (Completo):

Use the blueprint skill to plan: "Migrate monolith to microservices architecture"

Before executing, answer these questions in the blueprint:
1. Which domain boundaries exist in the current monolith?
2. Which service should be extracted first (lowest coupling)?
3. Communication pattern: REST APIs, gRPC, or event-driven (Kafka/RabbitMQ)?
4. Database strategy: shared DB initially or database-per-service from start?
5. Deployment target: Kubernetes, Docker Compose, or serverless?

The blueprint should produce phases like:
- Phase 1: Identify service boundaries and create domain map
- Phase 2: Set up infrastructure (API gateway, service mesh, CI/CD per service)
- Phase 3: Extract first service (strangler fig pattern)
- Phase 4: Verify with integration tests, then extract next service
- Phase N: Decommission monolith

Each phase = 1 PR, with /verify gates between phases.
Use /save-session between phases

...

[truncated for translation]