daiki-beppu/youtube-automation

前後工程

• 前工程: なし
• 後工程: なし
• 委譲先: なし

成果物

• 書き込む: ユーザーが指定したHTML表示層
• 読み込む: 対象実装、URL、スクリーンショット

Hallmark

Esta copia con ámbito de proyecto es solo para desarrollo. Preserva los límites de implementación existentes y carga las reglas referenciadas solo cuando sea relevante.

Una habilidad de diseño para asistentes de codificación con IA. Hace que las interfaces de usuario que generen parezcan hechas, no generadas.

Hallmark es opinionada, concisa y deliberadamente aburrida. Codifica un conjunto estricto de reglas —extraídas del consenso del campo de diseño anti-slop (la habilidad de diseño frontend de Anthropic, el libro de cocina de Claude sobre estética frontend y el movimiento "táctil rebelde" de 2026)— y se niega a permitir que el modelo recurra a los valores predeterminados con los que todos los LLM fueron entrenados.

El diferenciador: Hallmark insiste en la variedad estructural, no solo visual. Dos páginas creadas con Hallmark para dos briefs diferentes no deben compartir el mismo ritmo de héroe → 3 características → CTA → pie de página. Deben parecer sitios diferentes, no intercambios de color de la misma plantilla. Consulta references/structure.md.

Desarrollado por Together AI.

---

Cómo usar esta habilidad

Hallmark tiene un comportamiento predeterminado y tres verbos explícitos.

Invocación	Qué hace
(predeterminado)	El usuario te pidió diseñar o construir algo nuevo. Sigue el flujo de diseño a continuación.
hallmark audit <objetivo>	Lee el objetivo, lo evalúa contra la lista de antipatrones y devuelve una lista clasificada de pendientes. No edites.
hallmark redesign <objetivo> [--mood <nombre>]	Toma el contenido y la intención del objetivo, luego rediseña la estructura visual dentro de los límites de implementación existentes a menos que el usuario confirme explícitamente una reconstrucción completa. Nuevo ritmo de sección, nueva ubicación de encabezados, nueva voz de componente. Preserva rutas existentes, propiedad de componentes, intención de copia, marca y arquitectura de información; reemplaza solo la capa visual/interactiva necesaria para el alcance solicitado.
`hallmark study <captura de pantalla	URL>`

Si el usuario escribe algo que no se asigna claramente a audit, redesign o study, trátalo como predeterminado. Si el usuario adjunta una imagen o pega una URL sin un prefijo de verbo, pregunta: "¿Debo study esto (extraer el ADN), o debo tratarlo como referencia para una construcción nueva?"

Barrera de seguridad de implementación. Hallmark es una habilidad de diseño, no una licencia para arrasar con un código base. En cualquier proyecto existente:

• Nunca elimines archivos de producción, árboles de rutas, directorios de componentes o un sitio web antiguo a menos que el usuario lo solicite explícitamente o apruebe un plan a nivel de archivo que enumere las eliminaciones.
• Por defecto, realiza ediciones in situ de los archivos nombrados, o agrega nuevos componentes/tokens que se conectan a través de la ruta existente. Si el rediseño requiriera eliminar múltiples componentes, detente y pide confirmación primero.
• Trata los PDF, archivos README, briefs .md, documentos, transcripciones y presentaciones como material de referencia. No los copies palabra por palabra en la página a menos que el usuario diga explícitamente que uses ese texto textualmente.
• Antes de editar, indica los archivos exactos que esperas modificar/crear/eliminar. Las eliminaciones requieren confirmación explícita.

El flujo de diseño predeterminado siempre elige un tema. Por defecto, elige uno de los 21 temas con nombre —el catálogo— y rota entre ellos según la regla de diversificación. También hay una rama personalizada silenciosa que construye una paleta OKLCH única + emparejamiento de fuentes libres para el brief; la ruta personalizada se activa solo cuando el brief lleva una señal de intención creativa (el usuario nombra un color de marca, nombra una vibra de múltiples atributos que el catálogo no puede soportar, o solicita explícitamente un tema personalizado). Para briefs comunes, el usuario nunca ve las palabras "catálogo" o "personalizado" — el catálogo se ejecuta en silencio. Consulta el Paso 1 (detección de señal) y el Paso 2.6 (despacho); el protocolo vive en references/custom-theme.md.

---

Disciplinas que se mantienen en cada verbo

Estas seis disciplinas no son específicas de un verbo. Se aplican al diseño predeterminado, audit, redesign, study y al ámbito de componentes por igual. Se sitúan junto con la prueba de slop, no dentro de una rama de ella.

1. Autocrítica previa a la emisión. Antes de entregar cualquier resultado, evalúalo del 1 al 5 en seis ejes: Filosofía, Jerarquía, Ejecución, Especificidad, Moderación, Variedad. Cualquier cosa < 3 desencadena una ronda de revisión. Imprime las seis puntuaciones en la parte superior del artefacto (/* Hallmark · crítica previa a la emisión: P5 H4 E5 S4 R5 V5 */). Consulta references/slop-test.md § Autocrítica previa a la emisión.

2. Copia honesta — sin contenido inventado. Si el usuario no proporcionó una métrica, no inventes una. Los diseños basados en estadísticas, filas de comparación y barras de prueba deben usar números reales, un marcador de posición (— más un bloque gris etiquetado "métrica por confirmar"), o una macroestructura diferente. "+47 % de conversión", "confiado por más de 50,000 equipos" y "10 veces más rápido" son slop en el momento en que se inventan. La misma regla para testimonios, logotipos y recuentos de casos de estudio. Consulta references/anti-patterns.md § Métricas inventadas y la puerta de prueba de slop 46.

3. Tokens bloqueados — sin improvisación a medio render. Una vez que se selecciona un tema en el Paso 2.6, cada declaración de color y font-family en el artefacto debe hacer referencia a un token nombrado (var(--color-accent), font-family: var(--font-display)). No se permiten valores OKLCH / hex / rgb() en línea, ni una declaración font-family: "Some Font" que omita el bloque de tokens. Si se necesita un valor que no existe como token, súbelo al bloque de tokens como una nueva variable nombrada, luego haz referencia a ella. Consulta references/anti-patterns.md § Improvisación de tokens a medio render y la puerta de prueba de slop 48.

4. Cromo redibujado prohibido. Hallmark no debe construir manualmente barras de navegador falsas (píldora de URL + puntos de semáforo), marcos de teléfono falsos, ventanas de bloques de código falsas (barra de título simulada + puntos envolviendo un <pre>), o cromo IDE falso — el entorno del usuario ya proporciona cromo real. Usa capturas de pantalla reales envueltas en un <figure> (con como máximo un borde finísimo), u omite el cromo y deja que el contenido se sostenga por sí mismo. Consulta references/anti-patterns.md § Cromo de UI redibujado y la puerta de prueba de slop 47.

5. Capacidad de respuesta móvil — cada emisión verificada a 320 / 375 / 414 / 768 px. El resultado de Hallmark debe renderizarse perfectamente en los cuatro anchos. Los no negociables: sin desplazamiento horizontal + raíz overflow-x: clip tanto en html como en body, nunca hidden (puerta 34); sin texto clicable de dos líneas — botones, enlaces de navegación principal, enlaces de pie de página, migas de pan, CTA (puerta 49); las pistas de cuadrícula que contienen imágenes usan minmax(0, 1fr), nunca 1fr desnudo (puerta 50); los encabezados de visualización se ajustan dentro de palabras largas mediante overflow-wrap: anywhere; min-width: 0 (puerta 51); los encabezados de sección se colapsan a una columna en móvil en cada variante de tema (puerta 52); los patrones de pestañas de radio no saltan al desplazarse (puerta 53). Consulta references/responsive.md § Móvil — no negociable. Esto es un piso duro, no una lista de deseos.

6. Pureza tipográfica — sin encabezados en cursiva. Los encabezados y el tipo de visualización son siempre romanos (font-style: normal). Una palabra de énfasis en cursiva dentro de un encabezado por lo demás recto (Construido para <em>pensar</em>) es una de las señales de IA más fiables; también lo es una cara de visualización totalmente cursiva en los encabezados. Transmite énfasis con peso, color de acento o un subrayado dibujado. La cursiva sobrevive solo como énfasis de cuerpo de texto dentro de párrafos en ejecución. Consulta references/anti-patterns.md § Encabezados en cursiva y la puerta de prueba de slop 38a.

---

Cuando el brief es un componente, no una página

Antes de ingresar al flujo de diseño completo, verifica el alcance. Si alguno de estos se activa, ejecuta el flujo de ámbito de componente en su lugar — la mayoría de las solicitudes de desarrollo diarias tienen forma de componente, no de página, y el aparato a nivel de página (macroestructura, enriquecimiento de héroe, arquetipo de pie de página, memoria de proyecto) es incorrecto para ellas.

Señales de ámbito de componente:

• El brief nombra un solo elemento de UI: un botón · una entrada · una tarjeta · un modal · un desplegable · un tooltip · un select · una casilla de verificación · un interruptor · una tira de pestañas · un chip · una insignia · un banner · un snackbar · un popover · un deslizador · un selector de fecha · un avatar.
• El brief es corto (≤ 30 palabras) y se refiere a un elemento.
• El archivo objetivo es un solo componente (por ejemplo, ./Button.tsx, ./components/Input.css, app/components/Card.vue).
• El usuario dice explícitamente "solo la X", "solo la Y", "este único elemento", "un solo ___".

Si se activan dos señales, dirige al componente. Si solo se activa el flujo de página (brief de múltiples secciones, "construye una landing page"), mantente en el flujo de diseño.

Qué mantiene el ámbito de componente del flujo de página

• Paso 0 · Escaneo previo al vuelo — igual. Lee los tokens existentes, fuentes, framework y postura de microinteracción. Un botón en un proyecto de Tailwind con cuerpo Geist debe adoptar esos tokens, no inventar otros nuevos.
• Paso 1 · Detección de género — igual. Editorial / minimalista moderno / atmosférico / lúdico. El componente hereda el género de su entorno (por defecto silencioso a editorial cuando se desconoce).
• Paso 2.6 · Ruta de tema — igual. Si existe un tokens.css o design.md, el componente usa esos tokens. De lo contrario, pregunta "¿hay un sistema a seguir, o debo elegir uno?" — por defecto a catálogo si el usuario está en silencio.
• Disciplina de 2+1 fuentes — igual.
• Disciplina de estados — MÁS ESTRICTA. Cada componente interactivo DEBE incluir código para los 8 estados: predeterminado · hover · :focus-visible · :active · deshabilitado · cargando · error · éxito. La lista de verificación de 8 estados en interaction-and-states.md es obligatoria, no opcional.
• Prueba de slop — subconjunto solo universal. Ejecuta las puertas visuales / de microinteracción / de contraste (puertas 40–41) / de accesibilidad / tipográficas. Omite las puertas de diversificación (sin entrada en .hallmark/log.json — los componentes no rotan) y omite las puertas de seguridad de diseño que asumen una página completa.

Qué omite el ámbito de componente

• Paso 2 · Selección de macroestructura. Los componentes no tienen macroestructuras. Indica esto explícitamente: "Ámbito de componente: omitiendo macroestructura."
• Selecciones de arquetipo de navegación y pie de página. N1a–N13 y Ft1–Ft8 son solo de ámbito de página. Un componente es un elemento; no tiene navegación, ni pie de página. Omite ambos.
• Patrones de pulido de héroe (HP1–HP4). Solo de ámbito de página. Un botón o tarjeta no tiene héroe.
• Paso 4 · Enriquecimiento. Sin ilustración de héroe, sin video de demostración, sin fondo abstracto. El componente ES el artefacto.
• Paso 5 · Vista previa de múltiples secciones. Reemplazado por el envoltorio de demostración de 8 estados (a continuación).
• Adición a la memoria del proyecto. Sin entrada en .hallmark/log.json para ejecuciones de componente. La regla de diversificación no aplica.

Qué emite el ámbito de componente

Dos archivos, lado a lado:

1. El artefacto del componente — un único archivo autocontenido que sigue las convenciones del proyecto:

   • React / Vue / Svelte: Button.tsx / Button.vue / Button.svelte
   • Web vainilla: button.css + button.html
   • Tailwind: un .tsx con cadenas className Y un tokens.css si falta
   • El componente consume tokens de Hallmark por nombre (var(--color-accent)), nunca valores OKLCH en línea.

2. Un envoltorio de demostración de 8 estados — <NombreComponente>.preview.html (o .preview.tsx). Una pequeña página independiente que renderiza el componente en los 8 estados apilados verticalmente, cada uno etiquetado. El usuario lo abre una vez, ve el componente funcionando, luego lo elimina. El envoltorio no forma parte del código de producción. Formato:

   ┌──── Botón — 8 estados ──────────────────────┐
   │                                                │
   │ predeterminado  [ Haz clic en mí           ]    │
   │ hover           [ Haz clic en mí           ]    │  ← .is-hover fuerza el estilo :hover
   │ focus           [ Haz clic en mí           ]    │  ← .is-focus fuerza :focus-visible
   │ active          [ Haz clic en mí           ]    │  ← .is-active fuerza :active
   │ deshabilitado   [ Haz clic en mí           ]    │  ← atributo disabled
   │ cargando        [ ⌛ Trabajando…            ]    │  ← data-state="loading"
   │ error           [ ⚠ Intenta de nuevo       ]    │  ← data-state="error"
   │ éxito           [ ✓ Guardado               ]    │  ← data-state="success"
   │                                                │
   └────────────────────────────────────────────────┘
   

   Cada fila etiquetada usa una clase (por ejemplo, .is-hover) que el CSS del componente apunta además de la pseudoclase real, para que todos los 8 estados se rendericen a la vez en la página de demostración. Ejemplo:

   .btn:hover, .btn.is-hover { background: var(--color-paper-3); }
   .btn:focus-visible, .btn.is-focus { outline: 2px solid var(--color-focus); }
   .btn:active, .btn.is-active { transform: translateY(1px); }
   

Formato de sello para salida de componente

Los componentes se sellan de manera diferente a las páginas:

/* Hallmark · componente: <tipo> · género: <género> · tema: <nombre del tema> */