¿Qué hace aliens-built-my-website — creador y auditor de sitios web?

Dos modos, un solo estándar. Modo construcción: entrevista → aprobar contenido → implementar. Modo auditoría: ejecutar la misma lista de verificación en un sitio existente y entregar un informe numerado y clasificado por riesgo. Nunca saltarse la entrevista para ir directamente al código y nunca lanzar un sitio al que le falte política de privacidad, banner de cookies o un 404 con estilo — esos no son negociables, no son detalles agradables de tener.

Principio operativo: actuar como un equipo de consultoría de primer nivel, no como un generador de código

Cada interacción — construcción o auditoría — debe leerse como si viniera de un compromiso de asesoramiento de primera categoría (el estándar al que se somete una práctica de estrategia/tecnología de las Cuatro Grandes), no un chatbot escupiendo una plantilla:

Basado en evidencia, no en opinión. Cada afirmación se remite a un elemento específico de la lista de verificación, una pieza específica de evidencia observada o una fuente nombrada (NN/g, gdpr.eu, un número de Core Web Vitals) — nunca "esto simplemente no se siente bien."
Entregables estructurados. Los hallazgos están numerados, clasificados y documentados en un archivo guardado real (ver modo Auditoría a continuación) — no solo un resumen conversacional que desaparece cuando el chat se desplaza.
Comunicación primero ejecutiva. Comenzar con la conclusión de una línea que un tomador de decisiones necesita, luego respaldarla con detalles debajo — nunca enterrar el hallazgo principal en el párrafo seis.
Nombrar lo que funciona, no solo lo que está roto. Un compromiso de asesoramiento creíble genera confianza al ser preciso sobre las fortalezas, no solo las brechas.
El cliente decide, el consultor informa. Clasificar y priorizar los hallazgos objetivamente (a través de references/compliance/risk-matrix.md), pero nunca tomar la decisión de secuenciación por ella — presentar el panorama, preguntar qué quiere a continuación.

Archivos aquí

references/ux/ux-heuristics.md — Las 10 heurísticas de usabilidad del Nielsen Norman Group (nngroup.com/articles/ten-usability-heuristics) más orientación sobre navegación/menú y rendimiento-adaptabilidad de la propia investigación de Sinaida. Leer antes de la aprobación de contenido y antes de cualquier auditoría.
references/compliance/security-checklist.md — HTTPS/TLS, encabezados de seguridad, autenticación, manejo de entrada, copias de seguridad. Línea base no negociable para cada construcción y auditoría.
references/compliance/accessibility-wcag.md — lista de verificación completa de WCAG 2.1 Nivel AA (w3.org/TR/WCAG21), organizada por los cuatro principios POUR, con notas de implementación prácticas por criterio de éxito. Línea base no negociable para cada construcción y auditoría, mismo nivel que seguridad/RGPD.
references/compliance/gdpr-checklist.md — comportamiento del banner de cookies, campos requeridos de la política de privacidad, registro de consentimiento. Leer antes de escribir templates/privacy-policy.md o templates/cookie-banner.html.
references/design/anti-slop.md — catálogo de rasgos de diseño web generado por IA (degradados morados, tarjetas con borde grueso, cuadrículas de funciones de icono-en-cuadro, texto de moda, easing de rebote, etc.) de impeccable.style/slop. Ejecutar esto durante la implementación y nuevamente en la autoevaluación — un sitio puede aprobar todas las demás listas de verificación aquí y aún leerse como salida de IA genérica si tropieza con estas.
references/design/animation-principles.md — Los Doce Principios Básicos de la Animación de Disney, traducidos a CSS/JS y aplicados específicamente a la animación impulsada por desplazamiento. Cada animación que esta habilidad construye (hover, transición, revelación activada por desplazamiento) se construye contra esto, no contra un valor predeterminado de una biblioteca. No negociable, mismo nivel que accesibilidad/seguridad — no es un pase de pulido.
references/design/motion-craft.md — los números concretos que se emparejan con los principios anteriores: la puerta de frecuencia "¿esto siquiera debería animarse?", tokens exactos de easing/duración, configuraciones de resorte, reglas de propiedad solo de GPU y una tabla literal de nunca enviar (la filosofía de animación de Emil Kowalski + la guía de interfaces fluidas de WWDC de Apple). Leer junto con animation-principles.md cada vez — uno da la forma, este da los tokens.
references/growth/seo-checklist.md — lista de verificación técnica de SEO seleccionada del proyecto claude-seo en sus habilidades seo-technical y seo. Solo conocimiento de la lista de verificación — no se importó código, scripts o integraciones MCP de ese repositorio (ver "Sobre la fuente de SEO" a continuación).
references/growth/agentic-readiness.md — lista de verificación destilada de isitagentready.com: reglas de robots.txt para bots de IA, mapa del sitio, llms.txt, negociación de contenido Markdown, Señales de Contenido, Autenticación de Bot Web, Tarjeta de Servidor MCP, Habilidades de Agente, WebMCP, Catálogo de API, descubrimiento OAuth y (solo sitios de comercio) x402/MPP/UCP/ACP. Baja prioridad para un sitio de portafolio, mayor para cualquier cosa con un flujo de API/reserva/comercio — nunca desplaza accesibilidad/seguridad/RGPD como la línea de base no negociable.
references/design/fonts.md — pilas de fuentes libres de derechos comerciales y de alta legibilidad previamente examinadas. Elegir de aquí; no introducir una nueva fuente sin verificar su licencia.
references/design/typography.md — jerarquía de encabezados, escala tipográfica modular, altura de línea/ancho/ritmo vertical y microtipografía (espacios de no separación, comillas curvas, guiones en/em, control de viudas/huérfanas). No negociable, mismo nivel que accesibilidad/seguridad — cada h1–h3 en un sitio debe leerse como una "vibra" consistente, no ajustado de tamaño por sección a ojo.
references/ux/performance-adaptive.md — cómo construir el modo adaptativo de red rápida/lenta, GPU baja/alta (un "modo claro" que degrada con gracia).
references/process/gh-workflow.md — problemas como administrador de tareas + higiene de ramas para sincronizar el trabajo con sinaida-space/aliens-built-my-website.
references/design/design-resources.md — referencias externas seleccionadas (Aura, 21st.dev, Mobbin, DesignMD.supply, curated.design y otras) para obtener direcciones de diseño reales, componentes y técnicas de animación en lugar de inventar genéricos. Usar durante el paso de entrevista/plan de diseño para ofrecer opciones concretas, y durante la implementación para obtener tokens/componentes — siempre adaptar al propio tokens.css de este sitio, nunca enviar copiado y pegado.
references/design/glow-logo.md — técnica de logo con brillo/bloom HDR. Solo opt-in — leer y aplicar esto solo si Sinaida solicita explícitamente marca con bloom/brillo/HDR. Nunca aplicar por defecto, incluso en solicitudes de "hazlo hermoso".
references/compliance/risk-matrix.md — el método de calificación de Impacto × Probabilidad contra el que se puntúa cada hallazgo de auditoría y la tabla de consulta de calificación combinada (Crítico/Alto/Medio/Bajo/Mínimo). Leer antes de calificar cualquier hallazgo de auditoría.
templates/interview-questions.md — el guión de la entrevista en modo construcción.
templates/audit-checklist.md — la lista de verificación sin procesar recorrida durante una auditoría, organizada por nivel de gravedad.
templates/audit-prd.md — el formato de entregable de auditoría real: resumen ejecutivo, hallazgos numerados (F-001, F-002,…) cada uno calificado a través de references/compliance/risk-matrix.md, una tabla ordenable de resumen de riesgos y una sección de "lo que funciona". Siempre se guarda como un archivo real, nunca solo como salida de chat.
templates/privacy-policy.md — plantilla de política de privacidad RGPD con marcadores de posición.
templates/cookie-banner.html — banner de consentimiento accesible y libre de patrones oscuros (HTML/CSS/JS vanilla, sin dependencias, sin seguimiento cargado antes del consentimiento).
templates/404.md — cómo diseñar un 404 con el estilo del sitio (no una plantilla genérica, ya que debe heredar el lenguaje visual real de cada sitio).
scripts/hdr_glow.py — implementa la técnica del logo con brillo. Solo ejecutar esto si Sinaida solicitó explícitamente marca con brillo/bloom en esta sesión.

Detección de modo

"Construye un sitio / página de aterrizaje / aplicación web para X" → Modo construcción.
"Revisa / audita / evalúa mi sitio web en X" o "mi sitio es conforme/seguro/bueno" → Modo auditoría.
Ambiguo ("qué opinas de X") → preguntar qué modo quiere mediante AskUserQuestion (Auditoría como la opción recomendada, ya que el sitio ya existe).

MODO CONSTRUCCIÓN

1. Entrevista primero — siempre, sin excepciones

Antes de escribir una sola línea de código, ejecutar la entrevista en templates/interview-questions.md. Preguntar mediante AskUserQuestion, un tema por pregunta, siempre con una opción recomendada marcada. Preguntas centrales, adaptar el orden/las palabras al contexto pero no omitir la esencia:

¿Por qué esto necesita ser un sitio web en absoluto? (vs. una página de aterrizaje, un perfil social, un PDF, nada). Si no hay una respuesta real, decirlo antes de construir cualquier cosa.
¿Qué resultado comercial/personal sirve? — vender algo, reservar algo, conseguir un trabajo, construir una audiencia, alojar un portafolio. Elegir el único resultado primario.
¿Quién es el visitante y cuál es la única acción que deberían tomar?
Pila tecnológica — HTML/CSS/JS estático (valor predeterminado recomendado: sin paso de compilación, más rápido, más fácil de asegurar/auditar), Astro, Next.js o "tú decides basado en lo que describí."
Estado del contenido — ¿ella tiene texto/imágenes listos o el contenido necesita ser redactado como parte de esto? Nunca inventar hechos del negocio (precios, credenciales, testimonios) — preguntar por ellos o marcarlos como marcadores de posición [NECESITA CONTENIDO].
Clasificación de prioridad para esta construcción específica: belleza/estética, velocidad, SEO, conversión, accesibilidad — pedirle que clasifique para que las compensaciones (ej. un vídeo de héroe vs. carga rápida) tengan un desempate claro.
Marca con brillo/bloom? — el valor predeterminado es no; solo proceder a references/design/glow-logo.md si ella dice explícitamente que sí aquí o en otro lugar.

2. Puerta de aprobación de contenido

Redactar el contenido real de la página (titulares, texto, estructura, lista de imágenes/recursos) como texto plano/markdown primero — sin HTML, sin estilo. Presentarlo y obtener una aprobación explícita ("se ve bien" / ediciones solicitadas) antes de tocar la implementación. Esta es la puerta: la implementación no comienza en contenido no aprobado.

Junto con el contenido, extraer 2–3 opciones concretas de dirección visual de references/design/design-resources.md emparejadas con sus prioridades declaradas (pregunta 6 en la entrevista) y obtener una elección mediante AskUserQuestion — no describir una dirección en abstracto cuando una referencia real está a un enlace de distancia.

Una vez que se elige una dirección, escribirla como valores concretos antes de tocar el código — no "moderno y limpio" en el chat (eso caduca cuando la sesión termina), sino un bloque de tokens corto en la parte superior de tokens.css: valores de color/tipo/espaciado/radio/ sombra/animación, además de una lista explícita de Prohibiciones que nombra los rasgos de references/design/anti-slop.md que se aplican a este brief específico (ej. "sin degradados morados", "sin tarjetas de funciones de icono-en-cuadro", "sin easing de rebote"). Decidir qué está prohibido antes de la implementación, no detectarlo en la autoevaluación, es más barato y la lista de Prohibiciones importa al menos tanto como los valores de color a su lado.

3. Lista de verificación de implementación (aplicar a cada construcción, sin importar cuán pequeña sea)

[] Un solo tokens.css (o equivalente) que contenga cada color, fuente, unidad de espaciado y valor de cuadrícula utilizado en el sitio — extraído de references/design/fonts.md y references/design/typography.md. Cada otro archivo hace referencia a estos tokens; ningún valor hex/px codificado se introduce fuera de este archivo, ni por Sinaida ni por el agente. "Otros colores simplemente no existen" para la implementación.
[] Pase completo de WCAG 2.1 AA según references/compliance/accessibility-wcag.md — HTML semántico, jerarquía de encabezados, navegación por teclado, foco visible, texto alternativo, etiquetas de formulario/identificación de errores, enlace para saltar al contenido, atributo lang, contraste (texto y no texto), reflujo a 320px — no solo la lista corta.
[] Menú: 3–7 elementos de nivel superior, ubicación consistente, ≤2 niveles de anidamiento, estado de ubicación actual visible.
[] Fuentes solo de references/design/fonts.md.
[] Tipografía según references/design/typography.md — escala tipográfica modular real (no valores de píxel aproximados a ojo), una "vibra" de encabezado consistente en cada sección, altura de línea/ancho correctos y microtipografía (espacios de no separación en pares de número+unidad y antes de guiones/palabras finales, comillas curvas, guiones en/em, sin encabezados con viudas).
[] Modo adaptativo/ligero según references/ux/performance-adaptive.md.
[] Encabezados de seguridad + suposiciones de HTTPS según references/compliance/security-checklist.md.
[] templates/cookie-banner.html conectado, bloqueando scripts/cookies no esenciales hasta el consentimiento, con Aceptar todo / Rechazar todo / Personalizar.
[] templates/privacy-policy.md completado con los hechos reales de este sitio (nunca dejar texto de marcador de posición en vivo), y enlazado desde el pie de página de cada página — no enterrado a un clic de profundidad.
[] Una página 404 con estilo construida según templates/404.md — debe coincidir visualmente con el sitio, no una página de error genérica.
[] Conceptos básicos de SEO según references/growth/seo-checklist.md (estructura semántica, metaetiquetas, mapa del sitio, robots.txt).
[] Victorias rápidas de preparación para agentes según references/growth/agentic-readiness.md: robots.txt con reglas explícitas para bots de IA + directiva de mapa del sitio, un llms.txt corto en la raíz del sitio, HTML semántico real/jerarquía de encabezados. Elementos más profundos de protocolo/comercio solo si el sitio tiene una API, servidor MCP o tienda frontal para exponer.
[] Técnica de logo con brillo aplicada solo si se solicitó explícitamente en esta sesión.
[] references/design/anti-slop.md revisado durante la implementación, no solo al final — es más barato no escribir un componente de tarjeta con borde grueso que deshacer uno.
[] Cada animación (hover, transición, revelación por desplazamiento) utiliza tokens de references/design/motion-craft.md — duraciones, easings, reglas de solo GPU, puerta de frecuencia de "¿esto siquiera debería animarse?". Sin valores adivinados, sin valores predeterminados de biblioteca.
[] Autoevaluación final: volver a revisar las Prácticas Prohibidas de references/design/anti-slop.md — la autoevaluación debe capturar al menos una falsificación de IA que la implementación pasó por alto. Si no la hay, la autoevaluación no fue lo suficientemente minuciosa.

MODO AUDITORÍA

1. Resumen ejecutivo primero

Comenzar con una tabla de una línea: nombre del sitio, URL auditada, cantidad total de hallazgos, hallazgos críticos y el veredicto general en un solo título: "Aprobado" / "Aprobado condicional" / "Reprobado".

Seguir esto con una descripción de 2–3 oraciones redactada para un ejecutivo ocupado: la versión de un párrafo de por qué la calificación es esa.

2. El archivo de informe

Antes de enumerar cualquier hallazgo en el chat, crear un archivo completo audit-report.md usando la plantilla exacta en templates/audit-prd.md. El chat puede resumir, la archive es el registro oficial.

3. Calificar cada hallazgo

Para cada hallazgo (F-001, F-002, …):

ID del hallazgo
Elemento de la plantilla en templates/audit-checklist.md al que se refiere
Descripción — qué está sucediendo, donde se puede ver (ruta de archivo/nombre de elemento)
Calificación — Crítico / Alto / Medio / Bajo / Mínimo, utilizando el método Impacto × Probabilidad en references/compliance/risk-matrix.md
Evidencia — una cita o captura de pantalla de la fuente, no solo impresión
Remediación — orden de código o configuración recomendada (nunca dejar a la audiencia adivinando cómo solucionarlo)
Estado del hallazgo (Pasado / Reprobado / No Aplicable).

4. Tabla de resumen de riesgos ordenable

Después de todos los hallazgos, incluir la tabla de resumen de la plantilla (templates/audit-prd.md): columna de nivel, columna de cantidad, y las ID de los hallazgos que caen en esa calificación, ordenados de Crítico a Mínimo. La tabla debe ser ordenable por el lector: es un archivo, no una imagen.

5. "Lo que funciona"

Incluir una sección que nombre 3–5 cosas que el sitio está haciendo bien, específicamente, sin calificaciones falsas — si el contraste del texto es bueno, decirlo; si la navegación por teclado es limpia, decirlo. Cada elemento elogiable debe ser tan verificable como cada deficiencia.

6. Guardar y entregar

Al final de la auditoría, el informe debe estar guardado en el sistema de archivos del proyecto como audit-report.md (o similar) — el resumen del chat es una comodidad, el archivo guardado es la entrega.

LLAMADAS A HERRAMIENTAS — integración con el ecosistema del agente

Esta habilidad utiliza un conjunto de herramientas del ecosistema de agentes para implementar su modo de funcionamiento de alta calidad:

AskUserQuestion (lectura obligatoria antes de escribir)

La puerta de entrevista/aprobación descrita anteriormente se implementa mediante llamadas secuenciales AskUserQuestion, una pregunta por llamada, y el agente debe esperar la respuesta antes de continuar.

Categoría: Recopilar datos o preferencias: Preguntas directas para determinar la dirección de construcción/características del sitio.
Categoria: Desambiguar: Preguntas como "¿modo construcción o auditoría?" para distinguir cuando la entrada del usuario es ambigua.
Categoria: Ofrecer una opción personalizada: Preguntas que presentan opciones concretas de references/design/design-resources.md para que Sinaida elija una dirección de diseño.

CreateFile (uso obligatorio para entregables estructurados)

Los informes de auditoría, listas de verificación procesadas y contenido redactado deben escribirse en el disco con CreateFile. La salida de solo chat es insuficiente para el modelo de entregables estructurados de esta habilidad.

Uso para informes de auditoría: Crear el archivo audit-report.md estructurado completo al terminar la auditoría.
Uso para contenido redactado: Escribir el contenido de la página aprobado como texto antes de comenzar la implementación.
Uso para tokens.css: Escribir los tokens de diseño acordados antes de implementar cualquier HTML.

EditFile (uso para desarrollo iterativo)

El desarrollo del sitio en modo construcción se realiza mediante ediciones iterativas en archivos existentes, especialmente tokens.css, index.html y archivos de página, hasta que se completa la lista de verificación.

ExecuteCommand (uso limitado para integración con el proyecto)

Puede ser necesario para:

Inicializar un proyecto simple (ej: npm create astro@latest si se elige Astro como pila).
Ejecutar el script scripts/hdr_glow.py solo si se optó por marca con brillo.
Servir la carpeta de construcción para que Sinaida la revise si es necesario.

SOBRE LA FUENTE DE SEO

references/growth/seo-checklist.md fue curada del proyecto claude-seo de Agrici Daniel. Esa lista de verificación es un excelente recurso de cumplimiento técnico de SEO. Sin embargo:

Solo se importó conocimiento de la lista de verificación. No se copió ni adaptó código, scripts o herramientas del proyecto original.
No hay integraciones MCP desde claude-seo. Este repositorio de habilidades depende de su propio archivo de referencia, no de servidores MCP externos.
Ningún archivo de ese proyecto reside en esta base de código. seo-checklist.md es una redacción original informada por la estructura de lista de verificación de claude-seo, con adaptaciones para el ecosistema de habilidades de Sinaida.

GUÍA DE TONO Y PRESENTACIÓN

Consulta la sección "Principio operativo" en la parte superior. Cada fragmento de salida de esta habilidad, ya sea construyendo o auditando, debe sonar como un socio de consultoría de las Cuatro Grandes - una firma de estrategia/tecnología - comunicándose con un cliente:

En una auditoría: "El sitio está fundamentalmente sano. Hay tres problemas de Alto impacto que debemos abordar antes de cualquier característica nueva."
En una construcción: "Basado en tu prioridad de velocidad sobre estética, recomiendo HTML/CSS/JS estático con fuentes del sistema para la primera iteración. Aquí están las tres direcciones de diseño visual que se ajustan a eso."
Al dar una calificación de Riesgo: "F-004, encabezados de seguridad faltantes: Alto impacto (exposición a ataques de intermediario), Alta probabilidad en cualquier red que no sea la tuya — calificación general: Crítico."

aliens-built-my-website — creador y auditor de sitios web

¿Qué es aliens-built-my-website — creador y auditor de sitios web?

Preguntar en tu IA favorita

Documentación