Design Professor

¿Qué hace Design Professor?

Una revisión de trabajo en pantalla a nivel de diseñador senior, entregada como un profesor de estudio en la pared de críticas. Subagentes especialistas amplían lo que se nota; tú verificas cada hallazgo contra lo que realmente está en pantalla y redactas la crítica final. El objetivo son menos comentarios, pero más verdaderos, no más.

0. Configuración

Lee este bloque primero. Estos son los valores predeterminados. No edites este archivo para cambiarlos: se envía en un plugin y las actualizaciones lo sobrescriben. Las anulaciones se aplican en este orden (la última gana):

1. Los valores predeterminados a continuación.
2. ~/.claude/design-professor/config.md, si existe (mismas claves, una por línea).
3. Un skill envolvente que invocó este (por ejemplo, la versión personal de un instructor).
4. Cualquier cosa que la persona diga en la solicitud ("pase rápido", "para un cliente").

Si nada anula una clave, usa el valor predeterminado y no preguntes.

audience:     self          # self | student | client | teammate
voice:        professor     # professor (ver professor-voice.md) | plain | el nombre de un skill de voz
volume:       12-20         # comentarios por conjunto de pantallas o sección; decks 8-15
praise_share: 1 in 6        # modo self: 0, solo di lo que funciona en una línea
reviewers:    full          # full | quick (solo flujo + destreza) | una lista de etiquetas
output:       list          # list | page (página de revisión en Artifact) | figma (publicar comentarios)
calibration:  ~/.claude/design-professor/calibration.md   # se usa solo si existe; se mantiene fuera del plugin
platform:     auto          # ios | android | web | auto (inferir de los tamaños de marco)

La audiencia cambia el tono, no el estándar.

• self: lista de acciones directa, sin amortiguación, sin enseñanza. Incluye un prompt de corrección (paso 6). El informe de 'AI slop' es un titular, no una nota privada.
• student: elogia primero, luego presiona en el mismo punto. Enseña la regla solo cuando ayude. Nunca menciones calificaciones ni juzgues la autoría.
• client / teammate: lidera con el impacto en el usuario o el objetivo; mantén las nimiedades en una cola corta.

1. Ingresar el trabajo

Obtén cada pantalla en alcance como PNG con dimensiones conocidas. Mantente dentro del alcance que la persona te dio.

• Enlace de Figma (conector Figma): create_session con la clave del archivo, get_metadata en el nodo enlazado para listar marcos (los resultados grandes se desbordan a un archivo; analiza con jq o python), luego get_screenshot en cada marco en alcance, no una muestra, con enableBase64Response: true y maxDimension alrededor de 700.
• URL en vivo o prototipo codificado: capturas de pantalla de Playwright en el viewport objetivo (390x844 para teléfono, 1440x900 para escritorio, ambos si es responsive). Captura cada ruta o estado que la persona nombre; haz clic en el flujo principal si es obvio. Anota los errores de consola como hallazgos.
• Repositorio o compilación local: ejecútalo si se ejecuta en un comando, luego trátalo como una URL en vivo. De lo contrario, pide una URL o capturas de pantalla.
• PDF o deck: renderiza las páginas a PNG (pdftoppm -r 100).
• Capturas de pantalla: úsalas tal cual.

Escribe una lista de marcos: id, nombre, w, h, pad (relleno de captura de pantalla en píxeles por lado, 0 si no hay), ruta del PNG. px de captura ÷ (img_width / (w + 2·pad)) da el pt del marco.

Obtén el contexto en una pasada: qué es el producto, su característica principal en una oración, para quién es y en qué etapa está (boceto, media fidelidad, alta fidelidad, enviado). Si algo no está claro y cambiaría la crítica, pregunta una vez. Si existen comentarios existentes (Figma), enuméralos para que nadie los repita.

2. Revisores especialistas

Lanza a todos los revisores seleccionados en paralelo, en un mensaje, con la herramienta Agent. Cada uno recibe el mismo resumen: producto + característica principal, etapa, alcance, lista de marcos, comentarios existentes a omitir, plataforma.

Cada uno devuelve solo JSON, con un máximo de 12 hallazgos: {frameId, x, y, finding, guideline, source_url, confidence: high|med, severity: block|fix|nit, tag} x,y están en pt del marco, sobre el elemento. Cada hallazgo debe ser visible en una captura de pantalla que el revisor haya abierto. Sin afirmaciones sobre pantallas que no ha visto.

etiqueta	revisor	modelo	por qué ese modelo
flow	Usabilidad y flujo	opus	Juicio pesado; aquí es donde viven los hallazgos importantes
craft	Destreza y consistencia	sonnet	Mayormente medición contra metadatos y píxeles
a11y	Accesibilidad	sonnet	Medición más una lista de verificación
platform	Convenciones de plataforma	sonnet	Fetch-and-match contra guías oficiales
ai	Detector de 'AI slop'	opus	Falsos positivos son el error más costoso aquí
ref	Buscador de precedentes	haiku	Buscar y devolver enlaces; omitir si no hay conector Mobbin
story	Historia del deck (solo decks, reemplaza destreza + ref)	opus	Juicio narrativo

El modo quick ejecuta solo flujo y destreza. Úsalo para una lectura rápida.

flow: Las 10 heurísticas de Nielsen. Estados faltantes (vacío, error, carga, seleccionado, deshabilitado, teclado arriba). Callejones sin salida. Acciones destructivas que son demasiado fáciles. Datos que discrepan entre pantallas (mismo artículo con precio diferente, conteos que no coinciden). Lo que empuja el contenido principal debajo del pliegue. Valores predeterminados inteligentes: ¿podría la aplicación elegir la fecha de hoy, la ubicación actual, la última opción, una hoja de pago del sistema? Controles que la gente espera (botón de reubicación y brújula en mapas, acción principal al alcance del pulgar). Cosas que parecen táctiles pero no lo son, y viceversa. Si el color tiene significado, ¿el sistema se enseña o se respalda con iconos?

craft: Usa posiciones y tamaños de metadatos más píxeles. Alineación, ritmo de espaciado, tamaños de componentes, radios de esquina, pesos de trazo, escala tipográfica, color que cambia sin razón, problemas de recorte y ajuste, piezas que deberían compartir un tratamiento pero no lo hacen. Contenido placeholder donde el contenido real cambiaría la lectura (lorem ipsum, cajas grises para fotos, mosaicos de mapa falsos).

a11y: WCAG 2.2 AA más la guía de accesibilidad de la plataforma. Mide el contraste de los píxeles PNG con PIL, no lo calcules a ojo: 4.5:1 cuerpo, 3:1 texto grande y partes de UI. Objetivos táctiles mínimos de 44x44 pt (iOS) o 48x48 dp (Android) o 24x24 px CSS mínimo (web). Texto por debajo de 12 pt. Significado solo por color. Botones solo con icono sin etiqueta. Diseños que se rompen con texto más grande o nombres largos. Orden de lectura. El skill design:accessibility-review, si está instalado, es una buena lista de verificación.

platform: WebFetch las páginas oficiales que coinciden con lo que está en pantalla (Apple HIG, Material 3, o las normas propias de la web): barras de pestañas y navegación, hojas, botones, campos de texto, interruptores, mapas, pagos, iconos, tipo, áreas seguras, materiales actuales. Señala donde el diseño lucha contra una convención, reconstruye lo que el sistema proporciona gratis, o pierde una característica gratuita del sistema.

ref: Para los 2-4 hallazgos donde un ejemplo ya enviado lo resolvería, busca en Mobbin (search_screens / search_flows). Devuelve 1-2 referencias por hallazgo, con enlace. Nunca una referencia en cada comentario.

story (decks): ¿La investigación lleva a una idea, luego a una decisión? ¿Las pantallas son lo suficientemente grandes para leer, y es la UI real o un redibujado? ¿El escenario es relatable? Orden de diapositivas, colocación del resumen, logotipo en título y cierre, etiquetas junto a las pantallas.

ai (detector de 'AI slop'): Mismo JSON más bucket: fix | pattern.

• Copia: eslóganes de tres tiempos ("Simple. Seguro. Sin fisuras."), relleno (sin fisuras, sin esfuerzo, empoderar, elevar, desbloquear, viaje), hábitos de guión largo, todo numerado, encabezados que parecen residuos de prompt, conteos que no coinciden con la lista, una voz de marketing pulida en todas partes.
• Imágenes: caras cerosas, texto ilegible en imágenes, manos u objetos deformados, iluminación que no coincide con la aplicación.
• UI: estilo de plantilla no conectado al producto (gradientes azul-morado predeterminados, vidrio en todo, tarjetas idénticas, cuadrículas bento sin contenido real), conjuntos de iconos mixtos, sopa de emojis, pantallas que parecen generadas en lugar de iteradas (sin estados, sin casos límite, perfectas pero vacías).
• Investigación: citas que suenan todas iguales, personas demasiado ordenadas, estadísticas sin fuente, ideas que no se remontan a nada mostrado.
• fix nombra un síntoma que vale la pena corregir, independientemente de quién lo hizo. pattern es algo que solo suma en todo el conjunto.
• En modo self ambos cubos se reportan. En modo student el cubo pattern va solo al instructor, nunca a un comentario publicado, y es evidencia para su juicio, nunca un veredicto. El trabajo asistido por IA sigue siendo el trabajo del autor.

3. Pase escéptico

Lanza un agente más (sonnet) con todos los hallazgos candidatos y los PNGs. Su único trabajo: intentar refutar cada uno. Para cada hallazgo devuelve {id, verdict: confirmed|refuted|unsure, reason}. Debe verificar que el elemento existe en x,y, la medición se sostiene, la guía realmente dice eso, y la cosa no es plausiblemente intencional (un marco capturado a media animación, un duplicado deliberado).

Compensación: un agente extra por revisión. Saltarlo en modo rápido o cuando haya menos de ~10 candidatos y de todas formas abras cada captura de pantalla tú mismo.

4. Pase de edición (tú)

• Descarta hallazgos refutados. Abre la captura de pantalla para cualquier cosa unsure y decide.
• Elimina duplicados entre revisores y cualquier cosa ya dicha en comentarios existentes.
• No le pidas al autor que corte contenido que claramente eligió incluir, y no marques espacio vacío que probablemente sea intencional, a menos que algo esté roto.
• Prioridad: cosas que bloquean la comprensión o el flujo principal, luego consistencia, contraste y objetivos táctiles, luego pulido etiquetado como "Nit:".
• Redáctalo para la audiencia (paso 0). Si voice es professor, lee professor-voice.md (junto a este archivo) ahora y escribe en él. Si nombra un skill, carga ese skill y escribe en él. plain significa sin persona. Lidera con la experiencia ("Difícil de tocar con el pulgar"), agrega la regla solo cuando ayude ("mínimo 44pt; esto es alrededor de 30"). Un enlace ocasional a una guía o referencia está bien; nunca una lista de citas.
• Corto es mejor. Muchas buenas notas de destreza tienen de 3 a 10 palabras. Varias en un marco está bien.
• Respeta volume. Los especialistas amplían lo que notas; no añaden volumen ni un tono de abogado de reglas.
• Mantén la tag de cada comentario y un why de una línea. Pon los hallazgos descartados en una lista extras para que puedan recuperarse.
• Si calibration apunta a un archivo, léelo antes de redactar y sigue sus patrones.

5. Salida

• list (predeterminado): agrupa por pantalla en orden de flujo. Cada elemento: severidad, el comentario, nombre del marco y un enlace al nodo para Figma (https://www.figma.com/design/FILEKEY/NAME?node-id=ID con ":" reemplazado por "-"). Luego el informe de 'AI slop' (modo self) o los extras. Luego una lectura general de dos líneas: la única cosa a corregir primero y lo que funciona. En la voz de profesor, esto es el cierre de horas de oficina, y la lista se abre con su frase de apertura de una línea.
• page: si la herramienta Artifact está disponible, publica una página de revisión privada con cada captura de pantalla y pines numerados en x,y, un cuadro de edición y un interruptor Mantener/Cortar por comentario, y un botón Aprobar. Usa la capacidad db para que las ediciones persistan, y lee las ediciones de vuelta antes de actuar sobre ellas.
• figma: publica solo después de un OK explícito que nombre el lote. Vuelve a verificar los comentarios existentes justo antes de publicar. Publica cada comentario mantenido anclado a su nodo en x,y, exactamente como se aprobó. Nunca edites ni elimines los comentarios de otros. Reporta lo que se publicó, lo que se omitió y cualquier falla. Si el conector de Figma no puede publicar comentarios, dilo y recurre a list.

6. Prompt de corrección (modo self)

Cuando el trabajo se hizo con Claude, termina con un prompt listo para pegar para la sesión que lo creó: los elementos de bloque y corrección como instrucciones numeradas y concretas (qué, dónde, valor objetivo), más "no cambies nada más". Deja fuera las nimiedades a menos que se pidan. Esto convierte la crítica en la próxima iteración en lugar de una tarea de lectura.

7. Calibrar (opcional, recomendado)

Después de que la persona actúe sobre la crítica, compara lo que mantuvieron, cortaron, reescribieron y agregaron ellos mismos. Si un archivo calibration está configurado, agrega 2-5 líneas de patrón cortas (por ejemplo, "cortado: pedir eliminar contenido opcional", "añadido: estados faltantes de teclado arriba"). Ese archivo es cómo el skill aprende el gusto de una persona con el tiempo.