BIGboss248/nextjs-wordpress

Habilidad de Diseño de Componentes y UI (component-design)

Un flujo de trabajo estructurado de descubrimiento y especificación de UX/UI para diseñar componentes, secciones y páginas web y de aplicaciones. Genera especificaciones de diseño listas para producción (design-spec.md) consumibles por herramientas de prototipado visual como stitch-design y flujos de implementación de código.

---

Guardarraíles y Principios Fundamentales

[!IMPORTANT] 1. Guardarraíl de Cero Código (Alcance de Diseño Puro): Esta habilidad se ocupa estrictamente de UX, UI, arquitectura de diseño, tipografía y tokens visuales. Nunca generes componentes de React, directivas de Next.js, interfaces de props de TypeScript o comandos de instalación de paquetes (sin comandos CLI de shadcn/Radix). La implementación de código se maneja en flujos de trabajo de desarrollo posteriores.

[!CAUTION] 2. Puerta de Requisitos Previos de Tokens de Diseño (Regla de Tokens Primero): Ningún componente puede diseñarse sin tokens de diseño canónicos verificados en docs/project.json. Los tokens faltantes deben ser indagados y persistidos antes de redactar los diseños de los componentes. Consulta token-verification-matrix.md.

[!TIP] 3. Regla de Conservación de Tokens (Cero Generación de Imágenes Directa en la Habilidad): Nunca invoques generate_image directamente. Formula indicaciones estructuradas de generación de imágenes para que el usuario las genere y coloque en los directorios del proyecto.

[!NOTE] 4. Búsqueda Selectiva de Patrones (Conservación de Tokens): Verifica la tabla de enrutamiento en references/component-design-patterns.md y carga SOLO el archivo de componente coincidente en references/patterns/ (por ejemplo, hero.md). Si hay coincidencia, indaga al usuario durante la entrevista adaptativa sobre si desea implementar ese patrón.

---

Resumen del Flujo de Trabajo

flowchart TD
    Start["Invocar /component-design<br/>(Página + Nombre del Componente)"] --> Step1["Paso 1: Contexto Dinámico y Puerta de Tokens<br/>(Escanear docs/**, CONTEXT.md, tokens y patrón objetivo)"]
    Step1 --> CheckTokens{"¿Están los Tokens de Diseño<br/>completos en docs/project.json?"}
    CheckTokens -- "Faltan Tokens" --> GrillTokens["Indagar Tokens Faltantes<br/>(3 opciones basadas en contexto)"]
    GrillTokens --> SaveTokens["Persistir en docs/project.json"]
    SaveTokens --> Step2
    CheckTokens -- "Verificados" --> Step2["Paso 2: Indagación Adaptativa Multirronda<br/>(Rondas 1–3 + Indagación del Patrón Objetivo)"]
    Step2 --> Step3["Paso 3: Formulación de Indicaciones de Activos Visuales<br/>(Proporcionar indicaciones de imagen listas para usar)"]
    Step3 --> Step4["Paso 4: Andamiar y Escribir design-spec.md<br/>(docs/design/components/[pagina]/[componente]/)"]
    Step4 --> Step5["Paso 5: Auditoría de Subagente y Autoreparación<br/>(invoke_subagent verifica guardarraíles y tokens)"]
    Step5 --> Finish["Especificación Lista para Entrega Posterior<br/>(Prototipado Visual / Implementación)"]

---

Manual de Ejecución

Paso 1: Descubrimiento de Contexto Dinámico y Puerta de Verificación de Tokens de Diseño

1. Escanear Contexto del Proyecto: Inspecciona dinámicamente todos los archivos en docs/ y CONTEXT.md raíz para extraer personas objetivo, objetivos comerciales y marcadores de diseño existentes.
2. Escanear Locales Soportados: Lee project_context_and_metadata.supported_languages en docs/project.json.
3. Verificar Tokens de Diseño: Audita docs/project.json bajo "design_system" contra token-verification-matrix.md.
4. Indagar Tokens Faltantes: Si faltan tokens, formula 3 opciones adaptadas al proyecto (marcando una como (Recomendada)), indaga al usuario y persístelas bajo "design_system".
5. Búsqueda de Patrón de Diseño Objetivo: Escanea la tabla de enrutamiento en references/component-design-patterns.md y visualiza SOLO el archivo de patrón de componente específico en references/patterns/ si hay uno que coincida con el componente que se está diseñando.

Paso 2: Indagación Progresiva de Componentes Multirronda

Ejecuta una entrevista adaptativa de 3 rondas usando ask_question (o chat interactivo), haciendo pausas entre rondas para asimilar las respuestas del usuario. Consulta adaptive-grilling-rounds.md para formulaciones de preguntas completas:

• Si se localizó un patrón coincidente en references/patterns/, incorpora su cuestionario en la Ronda 1 o Ronda 2 para indagar explícitamente al usuario si desea implementarlo.
• Ronda 1 (Intención e Historia): Aclarar el propósito del componente, los trabajos por hacer del usuario y el tono emocional.
• Ronda 2 (Jerarquía Espacial y Cuadrícula): Adaptar el diseño multicolumna, las escalas de densidad y el flujo visual focal según las respuestas de la Ronda 1.
• Ronda 3 (Interacciones y Acentos): Establecer dinámicas de estado hover/focus, activos multimedia y matices BiDi/RTL según las respuestas de las Rondas 1 y 2.

Paso 3: Formulación Proactiva de Indicaciones de Activos Visuales

Si el componente requiere gráficos, fondos o iconos personalizados, formula indicaciones de generación estructuradas para el usuario en lugar de llamar a generate_image. Consulta el formato de bloque de indicaciones en adaptive-grilling-rounds.md.

Paso 4: Andamiar Carpeta de Componente y design-spec.md

1. Crear el directorio: docs/design/components/[nombre de página]/[nombre de componente]/
2. Andamiar design-spec.md usando el diseño canónico de 9 secciones de design-spec.template.md:
   • §1 Resumen Ejecutivo e Historia
   • §2 Jerarquía Visual y Flujo Espacial
   • §3 Cuadrícula de Diseño y Puntos de Ruptura Responsivos (Móvil, Tablet, Escritorio)
   • §4 Tokens de Diseño y Mapa de Colores (Claro y Oscuro)
   • §5 Escala Tipográfica (Por Local Soportado)
   • §6 Matriz de Estados de Interacción (Predeterminado, Hover, Activo, Foco, Deshabilitado, Esqueleto)
   • §7 Adaptaciones Bidireccionales (RTL)
   • §8 Accesibilidad y Ergonomía (WCAG AA/AAA, objetivos táctiles $\ge 44\text{px}$)
   • §9 Activos Visuales e Indicaciones Recomendados

Paso 5: Auditoría de Calidad Independiente de Subagente (invoke_subagent)

Para garantizar una calidad imparcial, invoca un subagente revisor independiente antes de presentar los resultados al usuario:

1. Generar subagente auditor (TypeName: "self", Role: "Auditor de Diseño y UX Independiente", Model: "inherit").
2. Usar la indicación de auditoría estructurada en subagent-audit-protocol.md.
3. Si ISSUES_FOUND, resolver inmediatamente todos los problemas señalados en design-spec.md antes de concluir.

---

Entrega Posterior

Una vez que design-spec.md esté aprobado y verificado:

1. Prototipado Visual: Activar stitch-design para generar pantallas de UI y variantes de diseño en Google Stitch.
2. Implementación de Código: Proporcionar design-spec.md a las habilidades de implementación de componentes (por ejemplo, nextjs-component-dev / nextjs-create-component).

---

Lista de Verificación de Verificación de Ejecución

Antes de completar la ejecución, confirmar:

• No hay comandos de código o instalación de librerías (sin React, Next.js, shadcn CLI) en los entregables.
• Los tokens de diseño canónicos en docs/project.json están verificados y completos.
• El directorio de salida está estructurado en docs/design/components/[página]/[componente]/.
• Las opciones de indagación se sintetizaron dinámicamente sin suposiciones de repositorio codificadas.
• La indagación del componente siguió rondas adaptativas progresivas.
• NO se llamó a generate_image directamente; se proporcionaron indicaciones de activos al usuario.
• design-spec.md incluye las 9 secciones requeridas.
• Se invocó la auditoría independiente del subagente mediante invoke_subagent y se resolvieron todos los problemas.