¿Qué hace Rediseño Competitivo?
Si hay un archivo LOCAL.md junto a este SKILL.md, léelo primero: contiene los detalles específicos de este espacio de trabajo (rutas, herramientas, ejemplos) y anula los valores genéricos que se indican a continuación.
Investigar → decidir → diseñar. Subagentes en paralelo capturan pantallas de NUESTRA funcionalidad y de 2-3 productos competidores, los hallazgos se convierten en un análisis de brechas con decisiones por lotes para el usuario, y la dirección elegida se convierte en un lienzo de diseño: capturas de la interfaz actual junto a los tableros rediseñados con cada cambio marcado. El resultado es una decisión + un diseño (+ opcionalmente un plan de implementación); este skill no genera código de producto.
La "ejecución de referencia" que se menciona más abajo es la primera ejecución real de este skill (un rediseño de una biblioteca de grabaciones); LOCAL.md, cuando está presente, apunta a ella. Es solo un ejemplo práctico: demuestra la forma y calibra la profundidad; no lo consultes para el contenido de una nueva funcionalidad.
Fase 1: Investigación en paralelo (subagentes de modelo más barato, máximo 3 a la vez)
Lanza hasta 3 subagentes en un solo mensaje (herramienta Agent, general-purpose, model: "sonnet"; un modelo más barato es suficiente para la investigación básica; nunca más de 3 concurrentes: los límites de velocidad aniquilan los picos de creación):
- Nuestra – captura la pantalla de la funcionalidad en NUESTRA aplicación.
-
-
- Competidores – los productos que el usuario MENCIONÓ ocupan primero estas ranuras, un agente cada uno. Las ranuras restantes (si el usuario mencionó cero o uno): un agente de "encuesta" que elige los 2-3 competidores con la documentación pública más rica del área funcional relevante. Si el usuario mencionó 3 o más: asigna a un agente el principal y a otro el resto como lote.
-
Mientras se ejecutan, afiánzate en nuestro código base en el hilo principal: el esquema de la funcionalidad, la capa de lectura/acción y las páginas. Las recomendaciones deben asignarse a campos reales ("la etiqueta project existe, la interfaz nunca la expone") – la investigación de competidores sin fundamento en el código produce una lista de deseos que nadie puede construir.
Instrucciones para subagentes: las partes que fallan cuando se omiten:
- Solo Playwright MCP, nunca el panel del navegador – las capturas del panel del navegador no se pueden guardar en disco y son invisibles para el orquestador. Indica explícitamente al agente:
mcp__playwright__playwright_screenshotconsavePng: true+downloadsDirestablecido en un subdirectorio de borrador por agente (nuestra/,loom/,competidores/), hazmkdir -pprimero y reporta las rutas absolutas verificadas conls. - Los agentes concurrentes comparten un único navegador Playwright y CONTAMINARÁN las sesiones entre sí (un agente captura la pantalla de la página de otro agente – sucedió en la ejecución de referencia). Indica a cada agente: verifica visualmente que cada captura coincida con la URL a la que acaba de navegar antes de conservarla; si la captura está desactualizada o es de otro sitio, cierra el navegador Playwright, vuelve a abrirlo y repite la captura.
- Es posible que falte Chromium en Playwright ("Ejecutable no existe..."):
npx playwright install chromiumdesde el directorio de caché de npx del MCP, luego continúa (problema persistente que sobrevive a los cambios de versión). - Inicio de sesión en nuestra aplicación: proporciona al agente la receta exacta – por ejemplo, un formulario de inicio de sesión solo para desarrollo (correo electrónico + contraseña en
/login) con un correo que EXISTA COMO USUARIO ACTIVO en la base de datos de desarrollo más la contraseña de inicio de sesión de desarrollo del entorno del servidor de desarrollo. Verifícalo tú mismo (lee el valor de la variable de entorno en el servidor de desarrollo, consulta la base de datos de desarrollo en busca de usuarios activos) antes de lanzar el agente. La ejecución de referencia perdió un agente completo por unCredentialsSigninde un correo que no estaba en la base de datos de desarrollo. Encuentra la ruta de autenticación de desarrollo de la aplicación en su AGENTS.md / README. Nunca apuntes a los agentes hacia producción. - Las bibliotecas de los competidores están detrás de un inicio de sesión – indica a los agentes que utilicen artículos del centro de ayuda, páginas de marketing/funcionalidades y documentación (support.loom.com, etc.), que no intenten registrarse. Solicita un inventario estructurado de funcionalidades (organización, descubrimiento/búsqueda, uso compartido, flujo de trabajo, IA, administración) + qué funcionalidades son principales/apreciadas frente a las bloqueadas para empresas + una lista de "ideas distintivas que vale la pena copiar".
Fase 2: Sintetizar + decisiones por lotes
Compila UN mensaje para el usuario:
- Estado actual – qué tiene y qué le falta a nuestra funcionalidad, verificado tanto con las capturas como con el código (cita archivos).
- Qué hacen los competidores – unas líneas por producto, solo las partes transferibles.
- Recomendaciones por fases – lo más barato y de mayor apalancamiento primero: (a) exponer lo que el código ya soporta, (b) funcionalidades de organización con migración pequeña, (c) funcionalidades de flujo de trabajo. Incluye las ideas iniciales del usuario a partir del mensaje. Marca lo que se omite deliberadamente (con forma empresarial, YAGNI).
- Decisiones de opción múltiple por lotes: las 2-4 bifurcaciones que cambian el entregable, opciones con letras + una recomendación cada una. No hagas preguntas de una en una.
Detente y espera las decisiones. No empieces a diseñar un alcance no decidido.
Fase 3: Lienzo de diseño de la dirección elegida
SUB-SKILL REQUERIDO: el skill design (Lienzo de diseño de Claude → Artifact). Es quien controla la mecánica del lienzo; esta fase añade las convenciones de comparación:
- Capturas de la interfaz actual como sus propios tableros ("Actual – X") junto a los tableros rediseñados ("Rediseño – X"). Reduce las capturas a ~70-100 KB JPEG (
sips -Z 900 -s format jpeg -s formatOptions 60 …) antes de insertarlas. - Los tableros de rediseño coinciden con el sistema de diseño real de la aplicación – lee primero los archivos de tokens y componentes, copia los valores exactos (fuentes, tokens de color, radio de tarjeta, forma de botón).
- Marca cada cambio: contorno discontinuo en el color de acento de la aplicación + una pequeña etiqueta "NUEVO" en cada elemento que no exista hoy (variante de etiqueta "CAMBIADO" para los modificados). Las regiones sin cambios no reciben decoración: la ausencia es lo que hace legibles los marcadores.
- Notas adhesivas en el lienzo que resumen los cambios por tablero + una nota general. Los datos de ejemplo en los mockups están bien; indícalo al entregar.
- Los mockups estáticos son el entregable predeterminado; solo construye un prototipo interactivo si el usuario lo solicita.
Fase 4 (solo si el usuario lo pide): Plan de implementación
SUB-SKILL REQUERIDO: superpowers:writing-plans. Fundamenta cada tarea en la lectura de código de la Fase 1; traslada el alcance por fases y las decisiones textualmente; termina con opciones de modo de ejecución (despliegue en paralelo / subagente / en línea), no empieces a construir sin que te lo pidan.
Problemas conocidos (todos afectaron a la ejecución de referencia)
| Síntoma | Solución |
|---|---|
| El agente reporta capturas pero el orquestador no puede verlas | Se usó el panel del navegador – reinstruye: Playwright MCP savePng + downloadsDir |
| La captura muestra un sitio diferente al que navegó el agente | Contaminación de la sesión compartida de Playwright – cierra el navegador, vuelve a abrirlo, repite la captura, verifica visualmente |
CredentialsSignin en inicio de sesión de desarrollo | El correo no es un usuario activo en la base de datos de desarrollo – consulta la base de datos de desarrollo, usa uno que lo sea |
| "Ejecutable no existe... chromium" | npx playwright install chromium (por directorio de caché, vuelve a ejecutar después de cambios de versión de Playwright) |
| El despliegue devuelve vacío / con límite de velocidad | Más de 3 agentes concurrentes – oleadas de ≤3, reintenta los que fallan, reporta los parciales en voz alta |
| Las recomendaciones no coinciden con el código | Se omitió el fundamento en el código del hilo principal de la Fase 1 – hazlo antes de sintetizar |