jamesonedge/senior-design-review

Revisión de diseño senior

Convierte un vago "hazlo mejor" en una decisión de diseño refutable. El resultado es una crítica estructurada que cita archivos reales, tokens y patrones de referencia, seguida de una especificación que un ingeniero puede implementar.

Cuándo usarlo

Usa esta habilidad cuando el usuario pida:

• revisar, criticar o "evaluar a fondo" una pantalla, flujo o componente existente;
• evaluar una propuesta escrita por otra persona (por ejemplo, un diseñador junior u otro agente);
• decidir qué cortar, añadir, revisar o conservar antes de la implementación;
• corregir un flujo móvil a partir de capturas de pantalla.

Cuándo no usarlo

• Correcciones pequeñas y puntuales como "aumenta el espaciado en esta tarjeta" o "cambia esta etiqueta a 'Guardar'". Haz el cambio directamente; una revisión completa sería ruido.
• Construir un prototipo interactivo. Usa un flujo de maquetación interactiva; esta habilidad puede alimentarlo.
• Revisión de código no relacionado con la interfaz, ajuste de rendimiento o diseño de backend.
• Estrategia de marca o marketing sin una interfaz concreta.

Entradas

Recopila lo que el repositorio o el usuario puedan proporcionar de forma segura. Las entradas faltantes se listan como preguntas abiertas, nunca se inventan.

1. Tokens de diseño (color, tipografía, espaciado, radio, movimiento) — rutas de archivo.
2. El(los) componente(s) canónico(s) existente(s) al que el objetivo debe parecerse.
3. Un ejemplo aprobado previo de trabajo similar, si existe (opcional, útil).
4. La implementación objetivo y/o capturas de pantalla.
5. Restricciones conocidas de la plataforma (modelo de navegación, convenciones del SO, objetivos mínimos).
6. La queja del usuario, citada textualmente cuando sea posible.

Hay un formulario de contexto para completar en templates/context.md.

Flujo de trabajo

1. Redactar una propuesta inicial explícita

Antes de cualquier crítica, escribe la propuesta usando templates/proposal.md: problema, puntos débiles citados, principios de diseño, un esbozo de la arquitectura de la información, acciones y preguntas abiertas. Si el usuario proporcionó una propuesta, usa la suya sin cambios como entrada.

2. Ejecutar la revisión como una pasada nueva

El revisor lee, en este orden: tokens, componente canónico, ejemplo previo, implementación objetivo/capturas de pantalla, restricciones de la plataforma, y solo entonces la propuesta. Leer la evidencia primero evita el anclaje en el encuadre de la propuesta.

• Si tu tiempo de ejecución puede iniciar un contexto genuinamente separado (un subagente o una nueva sesión sin historial compartido), úsalo y dilo.
• Si no, realiza tú mismo una pasada separada y etiquétala honestamente: "Pasada separada de un solo agente — no es una revisión por pares independiente."

La persona del revisor es una lente de calidad (un diseñador de producto senior exigente). Nunca afirmes historial laboral, credenciales ni años de experiencia en nombre de la persona.

3. Escribir la revisión

Usa templates/review.md. Secciones:

• TL;DR — de tres a cinco líneas: veredicto y el cambio más importante.
• A. Crítica estructural — ¿es esta la pantalla/flujo correcta en absoluto?
• B. Arquitectura de la información y jerarquía
• C. Semántica de las acciones — primaria, secundaria, destructiva, deshacer, nomenclatura.
• D. Mecánica y gestos — toques, deslizamientos, arrastre, teclado, capacidad de descubrimiento.
• E. Aspectos visuales y movimiento — tokens, ritmo, densidad, transiciones.
• F. Accesibilidad e internacionalización
• G. Preguntas faltantes — apunta a cinco, pero incluye solo las significativas.
• H. Especificación refinada más el registro Cortar / Añadir / Revisar / Conservar.

Guía detallada para cada lente en references/review-lenses.md. La lista de verificación de accesibilidad e i18n está en references/accessibility-i18n.md.

Reglas que hacen que la revisión valga la pena

• Evalúa a fondo; no selles con un sello de goma. Cada afirmación necesita una referencia específica: una ruta de archivo, nombre de token, nombre de componente, región de captura de pantalla o un patrón de referencia con nombre (por ejemplo, "deslizar para archivar en iOS Mail").
• Sin lugares comunes. "Mejorar la jerarquía visual" no es un hallazgo. "La fecha de 'Vencimiento' usa text.secondary con el mismo tamaño que el título, por lo que la fecha límite es invisible de un vistazo" sí lo es.
• Sin cortes forzados. Si la estructura actual es correcta, dilo y registra un Conservar fundamentado. Cambiar por cambiar es un defecto.
• Sin medidas inventadas. No indiques relaciones de contraste, niveles de aprobación/fallo de WCAG ni cifras de rendimiento a menos que las hayas calculado o medido, y muestra cómo. De lo contrario, escribe "no medido — verificar con una herramienta de contraste".
• Cubre estados. Vacío, cargando, error, sin conexión, contenido largo y contenido muy corto.
• Señales sin color. El estado nunca debe depender únicamente del color.
• Rutas de teclado y lector de pantalla para cada acción, incluyendo gestos personalizados.
• Expansión de texto (permite aproximadamente un 30–40 % más de cadenas para muchos idiomas) y diseño de derecha a izquierda cuando corresponda.
• Alternativa de movimiento reducido para cada animación.

Opcional: comparar con trabajo previo

Si existe un ejemplo aprobado previo, añade una breve nota "Coherencia con trabajo previo" bajo E o H. Es útil, no obligatorio.

Salidas

• proposal.md (si la redactaste)
• review.md que contiene TL;DR, A–H y el registro
• Un resumen breve para el usuario: veredicto, tres cambios principales y las preguntas abiertas que bloquean la implementación

Comprobaciones de aceptación

Ver references/review-lenses.md#acceptance-checks. Una revisión falla si alguna fila del registro carece de motivo y referencia, o si afirma números no medidos como hechos.

Aviso de licencia

El siguiente aviso acompaña a esta habilidad independiente y sus archivos de soporte.

Licencia MIT

Copyright (c) 2026 jamesonedge

Por la presente se concede permiso, libre de cargos, a cualquier persona que obtenga una copia de este software y los archivos de documentación asociados (el "Software"), para tratar el Software sin restricción, incluyendo, sin limitación, los derechos de uso, copia, modificación, fusión, publicación, distribución, sublicencia y/o venta de copias del Software, y para permitir a las personas a quienes se les proporcione el Software hacer lo mismo, sujeto a las siguientes condiciones:

El aviso de copyright anterior y este aviso de permiso se incluirán en todas las copias o partes sustanciales del Software.

EL SOFTWARE SE PROPORCIONA "TAL CUAL", SIN GARANTÍA DE NINGÚN TIPO, EXPRESA O IMPLÍCITA, INCLUYENDO PERO NO LIMITADO A LAS GARANTÍAS DE COMERCIABILIDAD, IDONEIDAD PARA UN PROPÓSITO PARTICULAR Y NO INFRACCIÓN. EN NINGÚN CASO LOS AUTORES O TITULARES DEL COPYRIGHT SERÁN RESPONSABLES DE NINGUNA RECLAMACIÓN, DAÑOS U OTRA RESPONSABILIDAD, YA SEA EN UNA ACCIÓN DE CONTRATO, AGRAVIO O DE OTRA MANERA, DERIVADA DE, O EN CONEXIÓN CON, EL SOFTWARE O EL USO U OTROS TRATOS EN EL SOFTWARE.