benjaminstelzer/scoville-ui-anti-ai-slop

Scoville UI Anti-AI-Slop

Mejora la interfaz del producto. Trata la usabilidad, el diseño de información, la adaptación, la accesibilidad y la claridad como resultados; no instales un segundo lenguaje de diseño disfrazado de buena práctica.

Si el usuario excluye explícitamente esta Skill, detente antes de leer una referencia, usar una herramienta dirigida por Skill, cambiar algo o hacer una afirmación de finalización derivada de Skill. Una instrucción de proyecto o host con mayor autoridad puede seguir requiriéndolo; reporta ese conflicto exacto. Excluir una habilidad hermana excluye solo a esa hermana y no autoriza a reproducir su contrato aquí.

Resolver la propiedad primero

Resuelve cada preocupación en este orden:

1. requisitos de seguridad y accesibilidad legalmente vinculantes;
2. la solicitud explícita del usuario, incluida la aceptación informada de una limitación reportada contra un objetivo no vinculante;
3. instrucciones del repositorio;
4. requisitos canónicos del producto, componentes del sistema de diseño, wrappers, temas, tokens semánticos y activos aprobados;
5. el framework o plataforma propietaria para preocupaciones no resueltas;
6. patrones locales deliberados que estén de acuerdo con esos propietarios; y
7. los principios generales de UI de esta Skill para la brecha restante.

No permitas que una fuente inferior anule a un propietario superior. Superficia un conflicto material. Una convención local repetida cuenta solo cuando es deliberada, actual y apropiada para la misma superficie.

Cuando no se nombre un objetivo de accesibilidad, usa WCAG 2.2 Nivel AA para UI web y la guía actual de la plataforma propietaria en otros lugares. Usa componentes y API compatibles. Si el propietario canónico no puede cumplir con el mínimo, reporta la limitación exacta en lugar de ocultarla con un lenguaje de diseño paralelo.

Lee framework-alignment.md antes de decidir un propietario cuando el stack no sea familiar, la propiedad sea ambigua, varias capas de UI interactúen, no parezca existir un propietario visual canónico, o la ruta de personalización compatible sea incierta.

Mantener la propiedad familiar distinta

Esta Skill funciona sola. El código posee el alcance de ingeniería, la propiedad del código, la integridad, el riesgo y la prueba. La UI posee la alineación del framework, la jerarquía, el diseño, la presentación de la interacción, la adaptación responsiva y la evidencia renderizada. Scribe posee el significado, la terminología, la localización y la fidelidad solo cuando las palabras visibles o accesibles son variables; las cadenas fijas de la fuente exacta no lo activan.

La UI posee el diseño del texto, la legibilidad, el espacio, la escala y si una etiqueta requerida o un nombre accesible existe y está asociado. Scribe, cuando sea aplicable, posee lo que dice. No copies reglas hermanas ni repitas su verificación.

Enrutar el trabajo

1. Inspecciona la superficie solicitada, las instrucciones del repositorio, la versión del framework, los propietarios canónicos y la superficie comparable más cercana solo según sea necesario.
2. Identifica la tarea principal, la prioridad, los estados afectados, la variación de contenido, las entradas y las transformaciones responsivas.
3. Reutiliza componentes canónicos, tokens, variantes, diseños, puntos de interrupción e interacciones. Agrega un primitivo solo para una brecha demostrada en su propietario.
4. Realiza el cambio coherente más pequeño para el resultado y los estados necesarios.
5. Verifica solo las condiciones renderizadas que podrían refutar el resultado. Separa la evidencia renderizada, la inspección de la fuente y el comportamiento no verificado en el informe. Para una dirección no implementada o una auditoría solo de fuente, di explícitamente que la dirección o los hallazgos no están renderizados y que el comportamiento renderizado permanece sin verificar; no cargues validación solo para reportar ese límite.

Lee ui-quality.md antes de tomar una decisión de calidad sobre el flujo de tareas, jerarquía, diseño, legibilidad, estados, estructura de accesibilidad o comportamiento responsivo. Para una pregunta solo de evidencia, carga la validación sola a menos que también se deba juzgar la interfaz misma.

Lee validation.md después de un cambio de interfaz o antes de afirmar comportamiento renderizado, comportamiento responsivo, interacción observada, calidad visual o accesibilidad. No lo cargues para una auditoría solo de fuente que confine los hallazgos a la estructura inspeccionada y deje explícitamente sin verificar el comportamiento renderizado e interactivo. Una compilación o revisión de fuente no puede probar el comportamiento renderizado.

Proteger el piso de integridad de la UI

Nunca mejores la apariencia inventando un lenguaje visual paralelo, omitiendo un token semántico, reconstruyendo un componente accesible, eliminando acomodaciones de enfoque o entrada, ocultando contenido requerido, usando una sola señal visual como único portador de significado, omitiendo la recuperación para un estado cambiado, o aplicando una excepción local a través de una anulación de tema global.

No impongas fuentes, paletas, radios, sombras, patrones de tarjetas, puntos de interrupción, valores de píxeles o prohibiciones de moda preferidos. Las reglas cuantitativas provienen del estándar de accesibilidad, plataforma o sistema de diseño, no de esta Skill.

Cuando solo se te pida auditar o asesorar, devuelve hallazgos priorizados vinculados a la evidencia observada y no edites.