Communitygithub.com

n0ctx/tavern-aesthetic

Utilizado para el diseño de páginas y frontend con estilo de taberna.

¿Qué es tavern-aesthetic?

Esta habilidad permite a un agente de IA diseñar y construir interfaces de usuario que se sientan como artefactos pertenecientes al mundo narrativo de una historia, en lugar de simples paneles de control re-skinneados o elementos genéricos de juego. Se centra en la estética de una taberna: cada superficie comparte una dirección artística unificada, los detalles están acabados y la interacción se siente natural y fluida. La habilidad cubre el diseño visual y el método de implementación, pero no depende de frameworks específicos como SillyTavern; puede reutilizar la pila, componentes y patrones de interacción del proyecto existente. El agente debe seguir reglas estrictas contra la deriva en ejecuciones de múltiples turnos, como mantener un registro de diseño como fuente única de verdad, congelar el registro de tokens visuales después de la muestra principal, y comparar visualmente cada módulo antes de continuar. Está diseñada para tareas de diferentes niveles de dificultad (simple, media o compleja), guiando al agente a través de un flujo de ejecución que incluye entender la escena, fijar la dirección, construir la interfaz usando assets de ilustración concretos, integrarlos y realizar una revisión visual basada en capturas de pantalla, priorizando la corrección de los problemas más grandes primero.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/n0ctx/skills/tree/HEAD/skills/tavern-aesthetic

Preguntar en tu IA favorita

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

Documentación

Estética de Taberna — Diseño de Frontend Narrativo Inmersivo

Lo que produce esta habilidad

Una interfaz de usuario funcional que se lee como un artefacto del mundo de la historia — no un panel de control re-skinneado ni un montón de accesorios genéricos de HUD de juego. El estándar es la tarjeta de frontend pulida: de un vistazo se identifica la obra, cada superficie comparte una dirección artística, los detalles están acabados y la interacción se siente natural.

Pulido ≠ complejidad. Pulido significa que cada elección visible es intencional y cada región visible cumple con el mismo nivel de calidad.

Esta habilidad cubre el diseño visual y el método de implementación. No depende de SillyTavern, ningún plugin auxiliar, MVU, ni ningún framework. Reutiliza la pila, componentes, activos y patrones de interacción existentes del proyecto. Si el usuario solicita solo un diseño, no toques el código.

Referencias (leer bajo demanda, nunca todas de una vez)

  • references/design-knowledge.md — guía de decisiones por dimensión (identidad narrativa, color, tipo, forma, luz/material, imagen, diseño, componentes, movimiento, adaptación) más tablas de modos de fallo. Consulta la sección que coincida con la decisión en cuestión.
  • references/workflow.md — proceso por etapas, compuertas de aprobación/rechazo, método de revisión, reglas de reversión, plantilla de registro de diseño. Léelo antes de cualquier tarea mediana o compleja.
  • references/asset-sources.md — fuentes y verificación de licencias para ilustraciones, texturas, iconos, fuentes. Léelo al recolectar activos en línea.
  • references/research.md — evidencia y limitaciones detrás de esta habilidad. No es necesario para la ejecución.

Niveles de tarea

Juzga por la dificultad del diseño, no por el volumen de código:

  • Simple: un componente, un arreglo de detalle, una funcionalidad pequeña dentro de un lenguaje visual existente. Reutiliza el lenguaje; verifica con captura de pantalla una vez después de implementar.
  • Media: una sola página/panel o un rediseño de una pantalla existente. Haz un breve establecimiento de dirección, construye primero el área focal, luego completa la página; de 1 a 2 rondas de revisión.
  • Compleja: flujo de múltiples pantallas, sistema gamificado, construir desde cero, necesita un visual clave personalizado, o el usuario solicita calidad de producto terminado. Ejecuta las seis etapas en workflow.md y mantén un registro de diseño.

Reglas anti-deriva (vinculantes)

Estas existen porque la ejecución de múltiples turnos tiende a desviarse. Síguelas al pie de la letra:

  1. El registro de diseño es la única fuente de verdad. Para tareas medias y complejas, créalo (plantilla en workflow.md) en el momento de establecer la dirección y reléelo al inicio de cada turno/módulo subsiguiente. Cualquier nuevo color, radio, fuente o valor de movimiento debe añadirse al registro de tokens del registro antes de usarse. Si un valor no está en el registro, no está permitido en el código.
  2. Congela el registro de tokens después de que la muestra principal pase. Los módulos posteriores solo pueden reutilizar tokens registrados. Los nuevos tokens requieren una nota explícita en el registro explicando por qué el conjunto existente no puede expresar la necesidad.
  3. Cada módulo se compara visualmente lado a lado con la muestra principal antes de continuar. Sin excepciones; la comparación verbal no es suficiente.
  4. Máximo dos rondas de arreglos por etapa. Si aún falla, revierte y diagnostica según la tabla de reversión en workflow.md en lugar de añadir más arreglos.
  5. Una dirección activa a la vez. No mantengas direcciones alternativas vivas entre turnos. Elige una, regístrala, descarta el resto.

Principios fundamentales

  1. Diseña para la obra, no para el género.
    • Primero responde: ¿qué objeto o sistema es esta UI dentro de la historia, quién la hizo, quién la lee, cuándo.
    • Luego elige un punto de memoria que pertenezca a esta obra específica.
    • La identidad visual proviene de personajes, lugares, época, facciones, eventos, accesorios concretos. Las fórmulas de género (post-apocalíptico = radar negro/amarillo; cultivación = tinta verde + dorado) son solo puntos de partida y deben hacerse específicas.
    • Autocomprobación: entrega la misma solicitud genérica de género a un agente — si produjera casi la misma UI, la dirección no es lo suficientemente específica.
    • Compara unas pocas direcciones internamente, entrega exactamente una. No enumeres opciones al usuario para tareas rutinarias.
  2. Un concepto rige cada decisión de diseño.
    • El color proviene de materiales y fuentes de luz; el tipo de métodos de escritura/impresión; la forma de la artesanía; el movimiento de las acciones físicas del objeto.
    • Las dimensiones relacionadas se deciden juntas, no secuencialmente ("todos los colores primero, luego todas las fuentes" está mal).
    • Para cualquier elemento debes poder declarar qué parte del concepto expresa.
  3. El arte concreto utiliza activos de ilustración; el arte dibujado con código es solo un marcador de posición.
    • Personas, escenas, objetos: la versión final utiliza activos de ilustración. Orden de fuentes: activos de proyecto existentes → generación por IA → colección web con licencia.
    • Las escenas, personas, objetos dibujados con CSS/SVG solo están permitidos para validación de composición/concepto y deben reemplazarse antes de la entrega (a más tardar en la etapa de muestra principal para tareas complejas). Se leen como arte de programador y arrastran toda la UI hacia abajo.
    • El código posee la interfaz en sí misma: diseño, tipografía, bordes, texturas, patrones ornamentales, iconos, gráficos abstractos y de datos.
  4. La ilustración lidera la composición.
    • La ilustración establece el centro de gravedad del diseño; el texto y los componentes se organizan a su alrededor. Nunca la reduzcas a un banner superior o una miniatura de tarjeta.
    • Cada pantalla principal debe leerse como una imagen: entrecerrando los ojos, la pantalla debe ser mayoritariamente ilustración, no paneles oscuros + líneas finas + texto.
    • La presencia artística continúa en páginas funcionales (ilustración como capa de bajo contraste debajo de paneles, personajes cruzando bordes de panel, escena cambiando con el tiempo/ubicación). "Apertura impresionante, luego páginas de formularios oscuros y sencillos" es el colapso de calidad más común.
    • Una imagen heroica por pantalla. Las imágenes secundarias se fusionan en la misma imagen o forman un conjunto tratado uniformemente; nunca alinees imágenes de diferentes fuentes en cajas lado a lado.
  5. La información adopta formatos del mundo, con moderación de accesorios.
    • La información utiliza los formatos y vocabulario nativos del mundo (columnas de libro mayor, diseño de lista, verbos/sustantivos del mundo) y se revela a un ritmo narrativo.
    • Un portador principal para toda la UI. No le des a cada módulo un accesorio simulado con CSS diferente (notas adhesivas, sellos torcidos, etiquetas, cuentas de ábaco) — los accesorios apilados se ven baratos.
    • Modera accesorios y ornamentos, no imágenes y color. El espacio liberado de accesorios se destina a ilustración y tipografía, no a formularios de texto oscuro.
    • No todo es "etiqueta: valor" + barra de progreso. Las páginas de flujo (registro, configuración) no son formularios; las opciones clave pueden llevar ilustraciones.
  6. Un nivel de calidad uniforme.
    • El esfuerzo puede ser desigual: el área focal recibe los mejores activos y más detalle.
    • Ninguna región visible puede estar por debajo del nivel. Cualquier cosa dibujada debe coincidir con la precisión general; si no puede, reemplázala con ilustración o exprímela mediante tipografía/gráficos abstractos.
    • Para reducir costos, simplifica dentro del mismo lenguaje — nunca recurras a componentes predeterminados, estilos nativos del navegador o imágenes de marcador de posición.
  7. Leer y operar son lo primero.
    • Texto del cuerpo en chino: ≥14px (15–17px típico), altura de línea 1.6–1.9, longitud de línea ~20–40 caracteres, contraste del cuerpo ≥4.5:1.
    • El ambiente se transmite por temperatura de color, luz, material, movimiento; el texto y los números se mantienen nítidos.
    • Sin texto pequeño, bajo contraste o inglés sin sentido como abreviatura "premium".
    • Las imágenes y texturas nunca se superponen al texto del cuerpo o a los objetivos de clic.
    • Estados de interacción completos, operable con teclado, adaptado al ancho objetivo.
  8. Los valores predeterminados deben ser elegidos, no heredados. Mantén una fuente, paleta, estilo de biblioteca de componentes o barra de desplazamiento/anillo de enfoque del navegador solo si se selecciona deliberadamente. El kit común de UI de juego de IA (papel beige + pizarra oscura, sello rojo torcido, etiquetas pequeñas, nodos de paso hexagonales, gráfico de radar) también es un valor predeterminado. Cambiar un valor predeterminado de moda por otro sigue siendo un valor predeterminado.
  9. Moderación en ingeniería. Reutiliza código, dependencias y activos existentes. Genera/recopila activos según el plan de activos solamente. Sin nuevas dependencias pesadas, sin canalización de activos, sin refactorización del backend.

Flujo de ejecución

1. Comprende la escena

Confirma: género; detalles específicos del personaje/mundo; ambiente objetivo; propósito de la página; información y acciones principales; dispositivo objetivo; entorno anfitrión (ej. incrustado en un chat). Revisa el código y activos existentes. Referencias del usuario: extrae la técnica artística, no la imagen. Procede sin preguntar cuando no haya ambigüedad crítica.

2. Establece la dirección (todas las tareas medias+)

Escribe en el registro de diseño:

  • Identidad de la interfaz: qué objeto/sistema, hecho por quién, leído por quién.
  • Punto de memoria: una oración, debe provenir de los detalles específicos de esta obra.
  • Dirección artística: medio, pincelada, dirección de luz, paleta, claridad — una descripción de estilo compartida que se reutiliza textualmente en cada solicitud de generación posterior.
  • Lista de exclusión: las fórmulas de género y valores predeterminados que esta obra debe evitar.
  • Plan de activos: cada elemento de arte concreto con propósito, proporción, recorte, transparencia, fuente (existente → IA → web). Verifica que las fuentes realmente existan antes de comprometerte; si ni los activos de IA ni los web con licencia pueden respaldar la dirección, dímelo ahora.

3. Construye

Por nivel de tarea:

  • Simple: implementa, captura de pantalla, corrige los 1–3 peores problemas, listo.
  • Media: área focal a toda calidad → completa la página → una ronda de revisión combinada.
  • Compleja: sigue las seis etapas en workflow.md (dirección → composición → muestra principal → extensión módulo por módulo → pulido → aceptación). Las etapas son compuertas de calidad, no puntos de control de informes; procede continuamente. En problemas sistémicos, vuelve a la etapa relevante y rehaz solo la parte afectada.

Durante la construcción:

  • Reutiliza el código y los patrones de interacción del proyecto.
  • Fuentes decorativas solo para títulos; verifica la cobertura de glifos CJK y establece pilas de respaldo.
  • Todos los estados: hover, focus, active, selected, disabled, loading, empty, error — visualmente consistentes.
  • El movimiento sirve a la interacción y al ambiente; misma familia de duración/suavizado en toda la obra; respeta prefers-reduced-motion.

4. Integra activos

  • Coloca la imagen heroica primero, luego organiza la información de apoyo.
  • Unifica los activos mediante recorte, máscara, gradación de color, grano, fusión de bordes, dirección de luz unificada; deja zonas tranquilas para el texto.
  • Los estilos de fuentes mixtas entran en conflicto → gradúa para que coincidan; aún así conflictivos → reemplaza, no fuerces.
  • Los activos son archivos de proyecto locales, no URL enlazadas en caliente. Respeta las licencias/atribuciones.

Revisión visual (basada en capturas de pantalla, problemas más grandes primero)

  1. Primer vistazo (miniatura, ~1s): ¿dónde aterriza el ojo; es el punto focal planificado; hay algo que valga la pena recordar?
  2. Entrecerrar los ojos: la estructura de valor se lee en 2–3 masas; ¿la pantalla es mayoritariamente ilustración o mayoritariamente paneles oscuros?
  3. Cubrir el título: todavía reconocible como esta obra, no como cualquier plantilla del mismo género.
  4. Lado a lado: todas las regiones parecen una dirección artística (luz, línea, material, paleta, tipo).
  5. Tamaño real: texto del cuerpo en chino cómodo.
  6. Bordes: alineación, desbordamiento, cromo nativo del navegador, estados vacíos, sin arte dibujado con código residual ni marcadores de posición.
  7. Interacción: estados y movimiento.
  8. Ancho objetivo: diseño estrecho/incrustado.

Prioridad de corrección: dirección > composición > arte principal > consistencia > legibilidad > detalle. Corrige solo los 1–3 problemas principales por ronda; vuelve a capturar pantalla después de cada ronda. Máximo dos rondas por etapa; mantén un punto de reversión antes de cada sesión de corrección.

Diagnostica la clase de causa antes de corregir: falta de arte principal / identidad de concepto débil / jerarquía de composición débil / conflicto de estilo / error de legibilidad o diseño. Cada uno tiene una corrección diferente.

Si el modelo principal no puede ver imágenes, reutiliza una herramienta de visión existente o delega la revisión a un subagente con capacidad de visión. Informa solo lo que se verificó realmente.

Lista de verificación de aceptación (todos deben ser sí)

  1. ¿Hay un elemento memorable de primer vistazo que provenga del contenido propio de esta obra?
  2. Con el título cubierto, ¿esta UI no sería confundible con una plantilla del mismo género?
  3. ¿El área visual más importante utiliza activos de ilustración con una precisión que coincida con su estatus — sin figuras dibujadas con código, sin elementos obviamente más toscos en el encuadre?
  4. ¿Los activos, el tipo, los componentes y el fondo se leen como una sola producción? ¿La región más simple sigue siendo pictórica y con el mismo nivel de calidad?
  5. ¿La página es clara, operable, adaptada al ancho objetivo, con la función nunca sacrificada a lo visual?

Entrega

  • Entrega resultados ejecutables primero.
  • Tareas complejas: declara brevemente el concepto de arte principal, los activos realmente utilizados (con notas de licencia), las principales correcciones realizadas durante la revisión, los resultados de la verificación y cualquier cosa que aún sea marcador de posición.
  • Tareas simples: declara solo los cambios clave.
  • Sin documentos de diseño largos para el usuario. El registro de diseño existe para la continuidad entre etapas/sesiones, no como un informe para el usuario.

Individual skills in this repo

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

n0ctx/dag-engineering

Use for large software engineering work that needs dependency-aware planning and coordinated subagents: implementing a PRD or roadmap, multi-module features, substantial refactors or migrations, or resuming a plan saved under .dag/. Investigates the relevant code, decomposes the work into independently verifiable DAG tasks, runs independent tasks in parallel in isolated git worktrees, and continuously integrates and verifies the results. Also use when only a plan of this scope is requested. Do not use for small or self-contained changes (quick fixes, routine or single-file edits, anything a few tool calls can finish) or non-code tasks.

n0ctx/reader-first-writing

Use when writing or revising any text a human will read (articles, emails, notices, explanations, reports, marketing copy, social posts, chat replies) or when reviewing such text. Covers sentence-level readability in any language; not layout, and not "humanizing" text to get past AI detectors.

n0ctx/writing-for-agents

Writes or improves prompts and other text an AI agent will read and act on: system prompts, subagent delegation briefs, SKILL.md files, MCP or tool descriptions, handoff documents, GitHub issues and plan files for coding agents, AGENTS.md or CLAUDE.md rules. Use when asked to write a prompt, optimize or rewrite an existing prompt, turn a rough idea into instructions for an agent, or before drafting a substantial brief for another agent. Not for testing, A/B comparison, or eval loops, and not for text only humans will read.

Skills relacionados