Communitygithub.com

Rediseño Competitivo

Úsalo cuando el usuario quiera mejorar o replantear una funcionalidad de una de sus aplicaciones aprendiendo de productos competidores — 'mira cómo lo hace Loom/Notion/Linear', 'lanza agentes para capturar pantallas de la nuestra y las de los competidores', '¿qué podemos aprender de otras apps para X?', 'compara nuestra X con Y', '¿cómo podemos mejorar la organización de X?' — especialmente cuando también quieran VER la propuesta (un diseño antes/después de las mejoras, la interfaz actual junto al rediseño con las novedades resaltadas) antes de construir nada.

¿Qué es Rediseño Competitivo?

Este skill ejecuta un proceso estructurado de investigación competitiva y rediseño para aplicaciones. Primero, lanza hasta tres subagentes en paralelo que capturan pantallas de la funcionalidad propia y de 2-3 productos competidores utilizando Playwright MCP, evitando la contaminación entre sesiones compartidas. Luego, sintetiza los hallazgos en un análisis de brechas con decisiones por lotes para el usuario. A continuación, genera un lienzo de diseño donde se colocan las capturas actuales junto a los tableros rediseñados, marcando cada cambio con un contorno y una etiqueta. Finalmente, si el usuario lo solicita, produce un plan de implementación fundamentado en el código real. Soporta plataformas como Claude Code, Cursor y Codex, y requiere que el agente lea el código base para que las recomendaciones sean viables. Está diseñado para evitar errores comunes como el uso del panel del navegador en lugar de Playwright MCP, la contaminación de sesiones y las credenciales de inicio de sesión incorrectas.

Compatible con✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Pure-Water-Automations/agent-skills/tree/HEAD/competitive-redesign

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

¿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):

  1. Nuestra – captura la pantalla de la funcionalidad en NUESTRA aplicación.
      1. 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_screenshot con savePng: true + downloadsDir establecido en un subdirectorio de borrador por agente (nuestra/, loom/, competidores/), haz mkdir -p primero y reporta las rutas absolutas verificadas con ls.
  • 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 chromium desde 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 un CredentialsSignin de 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:

  1. Estado actual – qué tiene y qué le falta a nuestra funcionalidad, verificado tanto con las capturas como con el código (cita archivos).
  2. Qué hacen los competidores – unas líneas por producto, solo las partes transferibles.
  3. 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).
  4. 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íntomaSolución
El agente reporta capturas pero el orquestador no puede verlasSe usó el panel del navegador – reinstruye: Playwright MCP savePng + downloadsDir
La captura muestra un sitio diferente al que navegó el agenteContaminació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 desarrolloEl 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 velocidadMá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ódigoSe omitió el fundamento en el código del hilo principal de la Fase 1 – hazlo antes de sintetizar

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Pure-Water-Automations/agent-skills

Score any app (the user's own or a competitor's) on a research-backed rubric and produce a reusable, comparable scorecard — 0–5 per dimension with an evidence grade, noncompensatory gates checked first, and one "smallest fix" per weak dimension. Adapts to product stage: a pre-PMF app under ~100 users is scored on 9 dimensions, a growth-stage app on the full 23. Use whenever the user says "score this app", "grade the app", "rate the UI/UX", "how good is [app]", "app scorecard", "run the scorecard on [app]", "how does [app] stack up", "is this ready to launch / promote to prod", or wants a before/after number after a build sprint or a beta round. Reads the codebase + deploy + docs, optionally beta feedback / analytics, and refuses to invent retention, revenue, or PMF from code alone. Outputs a chat table plus a published HTML scorecard artifact. Pairs with ui-usability-audit (UI depth), qa-sweep (functional pass), dev-to-prod-promotion-review (release gate).

Pure-Water-Automations/agent-skills

Use when the user wants a multi-perspective brainstorm on a feature, app, or product area — "spin up agents with different personalities/job titles", "look at it from different angles", "panel of experts", "come up with 30 ideas and a top 5", "how can we make X more useful", "brainstorm what to do next with X" — especially when they also want to DECIDE on the ideas (implement / hold / reject) rather than just read a list. Also use when they ask to re-run or extend a previous panel, or to "make the ideas decidable like dev-to-prod-promotion-review".

Skills relacionados