Habilidad de Creación de Página de Inicio v2.0
Origen: El producto real fue juzgado como "feo". Por lo tanto, se tomó un sitio creado por otro servicio de IA sobre el mismo tema, se abrió, se midió por sí mismo y se convirtió en un procedimiento con las propias palabras basado en los puntos buenos. No se trata de gustos, sino de valores medidos y de qué se descuidó en ese momento.
Lo que hay que saber primero (esto es la premisa de todo)
Lo que se descubrió al comparar fue que la mayor diferencia estaba en la preparación antes de empezar a crear. Dentro de eso, lo que más efectivo fue el siguiente paso:
Antes de empezar a escribir, verbalizar la filosofía de diseño y fijarla en un archivo con restricciones negativas.
El sitio del oponente comparado tenía una breve directriz de "cómo mostrarlo" y "lo que no se hace" al principio de la hoja de estilo.
(La forma de escribir y los tipos están en reference/DESIGN_THESIS.md. La forma de usarlo en el Paso 0 también está allí).
Mi versión fallida fue exactamente la "repetición de tarjetas iguales centradas" que cae en esa "lo que no se hace". Sabía que sin hacer nada siempre caería allí, y lo prohibí de antemano. Esa fue la única diferencia.
Estos 6 son todo
- Escribir la tesis antes de escribir y fijarla en un archivo. Las declaraciones en la conversación fluyen y desaparecen.
- Incluir al menos 2 restricciones negativas. Si no se prohíbe explícitamente el valor predeterminado, no se puede alejar de él.
- Dos tipos de letra: Mincho + Gothic. Usar un solo tipo de letra hace que todo parezca una pantalla de administración.
- No alinear tarjetas iguales centradas. Dividir asimétricamente. Colocar una banda de color oscuro.
- No se permite 0 imágenes. Si no hay material, generarlo. Si es generado, indicarlo claramente como "imagen".
- No está completo hasta que se renderice y se vea con los propios ojos. "No está roto" no es una evaluación.
⚠ Accidentes reales ocurridos en el pasado (3 casos)
Accidente 1 — Confundir "no está roto" con "es bueno"
Se inspeccionó si no aparecía desplazamiento horizontal o si la tabla cabía, y se envió. Toda la inspección fue de fallos, cero evaluaciones de atractivo. Resultó en un producto sin puntos negativos pero también sin puntos positivos.
Método de detección: Cuando en el registro de verificación solo hay "no aparece ◯◯" o "cabe ◯◯", este accidente está ocurriendo.
Accidente 2 — Aceptar la restricción de no tener material sin considerar alternativas
"No se puede obtener foto real" → se determinó "sin imagen". Se pudo llegar a generar imágenes, pero no se usó. La honestidad no es excusa para renunciar a las imágenes. Asegurarlo con una nota.
Método de detección: Si se omite del producto algún elemento incluido en la solicitud (como "también fotos"), sospechar siempre de este caso.
Accidente 3 — Después de que la inspección mecánica pasara todos los ítems, se encontró un fallo visual
Después de que verify.py se pusiera todo verde, al mirarlo reducido al 25% se encontró que el h1 se rompía a mitad de línea
(por ejemplo, como Recién horneado, entregamos / . donde solo 1-2 caracteres al final caían a la siguiente línea. El texto de ejemplo es ficticio).
Es un tipo de defecto que una inspección numérica nunca puede atrapar.
Contramedida: No omitir la inspección visual de §5.
verify.pygenera automáticamente una imagen para inspección visual. Leerla obligatoriamente.
§1 Procedimiento
Paso 0. Escribir la tesis (antes que HTML, obligatorio)
Leer reference/DESIGN_THESIS.md. Allí están los 6 tipos y un catálogo de restricciones negativas.
Elegir un tipo → Adaptar el nombre al tema → Elegir al menos 2 restricciones negativas →
Reemplazar al menos una con una específica del tema → Escribirla en el comentario al inicio de template.html.
Design: "◯◯◯◯" — {Una frase de afirmación visual}.
Visual rules: {restricción negativa 1}; {restricción negativa 2}; {restricción negativa 3}.
Information rule: {regla de colocación de la información}.
Además, declararlo una sola vez a la persona que hizo la solicitud. Si aquí surge una sensación de extrañeza, se puede detener antes de empezar a escribir.
◆ Política de diseño
Tesis: "◯◯" — {afirmación} / Prohibido: {al menos 2 restricciones negativas}
Colores: Satoyama (verde) / añil / cerámica ← uno de estos, o nuevo
Tamaños: h1=70px a 1280px / h2=51px / Margen: sección arriba y abajo 120px
Imágenes: {foto real / N ilustraciones generadas (con nota de "imagen") / gráfico}
Estructura: hero → {bloque} → banda oscura → tabla de hechos → cierre
Paso 1. Recopilar hechos (si el objetivo existe realmente)
- Priorizar bases de datos públicas. Sitio de publicación de números de identificación fiscal, sistemas de publicación de licencias y autorizaciones por industria (operados por el estado o gobiernos locales). Tienen mayor jerarquía que los portales de la industria y a menudo se puede obtener hasta el número de licencia o designación. Ejemplo (ficticio): El "Taller ◯◯ de la ciudad de Midori" que solo tenía nombre y número de teléfono en el portal de la industria, se pudo verificar su número de designación en la página de publicación del gobierno local ── así se usa.
- Si las fuentes discrepan, escribir honestamente "hay diferencia de notación" y ambas. No inclinarse en silencio hacia una.
- Si hay 0 reseñas, no crear una sección de reseñas. Jamás inventar.
Paso 2. Preparar materiales (no avanzar con 0 imágenes)
Considerar en orden y no determinar "sin imagen" hasta que se pueda escribir la razón por la que no se puede obtener.
- Obtener fotos reales del solicitante
- Generar (si se dispone de herramientas para crear imágenes, usarlas) + adjuntar obligatoriamente una nota de origen
- Sustituir con ilustraciones, diagramas, visualizaciones de datos
- Lograrlo solo con tipografía y superficies de color (＝ indicarlo explícitamente como una elección intencional)
Las especificaciones de estilo y las prohibiciones están en reference/DESIGN_SYSTEM.md §6. No generar rostros humanos.
Después de generar, comprimir para web (historial: 7.4MB → 566KB. No enviar un punto de 1.8MB).
Paso 3. Maquetar
assets/satoyama.css … Enlazar directamente con <link> (los colores se cambian con la clase de body)
assets/template.html … Reemplazar todos los {{ }}
Conservar obligatoriamente el héroe asimétrico y la banda oscura. La disposición de cada bloque está en reference/DESIGN_SYSTEM.md §5.
⚠ h1 con máximo 7 caracteres por línea. Si se supera, se rompe por salto de línea automático (Accidente 3).
Paso 4. Medir
python ~/.claude/skills/homepage/verify.py ruta/a/index.html
Mide la presencia de la tesis, número de restricciones negativas, tamaños, márgenes, número de imágenes, separación de tipos de letra, banda oscura, repetición de estructura,
y desbordamiento horizontal en 3 anchos, y genera una imagen para inspección visual en _review/.
Paso 5. Mirar (no omitible, no reemplazable por máquina)
Leer obligatoriamente _review/review-25percent.png y review-desktop.png generados por verify.py.
- Mirar reducido — ¿Tiene contraste? Si todo parece bandas grises iguales, falta banda oscura o margen.
- Leer solo los títulos — ¿Tienen sentido? Si solo son palabras de tabla de contenido, viola R-11.
- Mirar la primera pantalla sola — Sin desplazar, ¿se entiende "de quién, qué lugar es"?
- Buscar fallos — Saltos de línea en títulos, desbordamiento, imágenes rotas. El Accidente 3 solo se detecta aquí.
- Verbalizar en una línea si es bueno o malo. "No está roto" no es una evaluación. No enviar sin poder verbalizarlo.
§2 Valores de referencia de medición (determinados por comparación con productos de otras IA)
| Elemento | Referencia | Valor fallido pasado |
|---|---|---|
| Tesis en archivo | Obligatorio | Sin |
| Número de restricciones negativas | ≥2 | 0 |
| Renderizado real de h1 (1280px) | ≥56px (recomendado 70px) | 46px ← limitado por el máximo de clamp() |
| Renderizado real de h2 (1280px) | ≥40px (recomendado 51px) | 30px |
| Padding superior e inferior de sección | ≥100px (recomendado 120px) | 76px |
| Número de imágenes | ≥1 (recomendado 4) | 0 |
| Tipo de letra | Distinto para títulos y cuerpo | 1 tipo |
| Banda de color oscuro de ancho completo | ≥1 lugar | 0 |
| Diversidad de estructura | Más de la mitad de bloques principales con estructura diferente | Todos iguales |
⚠ El número de colores no marcó diferencia. La versión fallida tenía 15 tokens de color, más que los 10 de la versión buena. Lo que funciona es tesis, tipo de letra, tamaño, margen, imágenes, copia.
§3 Requisitos (no enviar si no se cumplen)
- R-1 Separar tipo de letra entre títulos y cuerpo. Para títulos en japonés, priorizar Mincho.
- R-2 En renderizado real a 1280px, h1≥56px / h2≥40px. Medir si el máximo de
clamp()está limitando. - R-5 Padding superior e inferior de sección en escritorio ≥100px. La cantidad de información no es excusa para la densidad.
- R-7 No se permiten 0 imágenes (pasar por los 4 pasos del Paso 2).
- R-8 En imágenes generadas, indicar claramente "Imagen (no es el real ◯◯)" en una posición visible.
- R-9 No todas las secciones deben tener el mismo patrón. Colocar al menos una banda de color oscuro de ancho completo.
- R-11 No usar etiquetas funcionales en títulos de sección. Las palabras de tabla de contenido deben ir al lado
.label. - R-13 No omitir accesibilidad (skip-link / foco visible / alt / reduced-motion).
- R-14 Fijar la tesis al inicio del archivo y escribir al menos 2 restricciones negativas.
- R-15 Leer con los propios ojos la imagen renderizada, verbalizar si es buena o mala en una línea y luego enviar.
§4 Prohibiciones de contenido (al tratar con tiendas o instalaciones reales)
- No inventar reseñas o testimonios de usuarios. Si son 0, escribir 0 y solo poner un enlace para recopilar.
- No hacer parecer que hay fotos reales si no las hay. Las imágenes generadas deben ir siempre con nota.
- No reutilizar fotos o textos de otros sitios. Las inserciones (embed oficial de Instagram, etc.) están permitidas.
- No prometer efectos o mejoras (especialmente en medicina, bienestar, educación). Limitarse a hechos publicados.
- Publicar solo después de obtener permiso del solicitante. No publicar sin autorización páginas que se hagan pasar por organizaciones reales. Para práctica o consideración, dejar un comentario al inicio del archivo indicándolo.
- Al tratar materiales con niños, verificar siempre si se puede publicar.
§5 Archivos
~/.claude/skills/homepage/
├── SKILL.md Este manual de procedimiento
├── verify.py Inspección de medición + generación de imagen para inspección visual
├── assets/
│ ├── satoyama.css Sistema de diseño principal, incluye 3 combinaciones de colores
│ ├── template.html Esqueleto (con marco de tesis al inicio)
│ └── placeholder.svg Imagen temporal que funciona incluso sin material definido
└── reference/
├── DESIGN_THESIS.md ★ Lo más importante. Cómo escribir la tesis, 6 tipos, catálogo de restricciones negativas
└── DESIGN_SYSTEM.md Fundamentos de cada valor numérico, 10 tipos de bloques, cómo crear palabras
Orden de lectura al comenzar: DESIGN_THESIS.md → DESIGN_SYSTEM.md → template.
Imitar solo los números no reproduce el tipo. La tesis es primero.
§6 Situaciones en las que no usar este sistema
Pantallas de administración, dashboards, LP centrados en tablas comparativas, avisos de alta urgencia, UI de juegos, contenido con normativa de marca ya establecida. Los títulos grandes en Mincho y los amplios márgenes funcionan en contra.