ROL DEL AGENTE AL EJECUTAR ESTA SKILL

TIPOS DE INPUT ACEPTADOS

El usuario puede proveer uno o más de los siguientes inputs para describir la UI a modelar. Cada tipo tiene un nivel de confianza diferente para la generación:

Cuando el input sea DOM HTML (fragmento o completo):

• Priorizá atributos data-testid, data-test, id, name y aria-label como selectores.
• Si no existen atributos identificables, usá selectores CSS semánticos basados en la estructura del DOM pero marcalos como // FRAGILE: selector sin identificador estable.
• Identificá las secciones naturales del DOM para proponer la división en subcomponentes.

Cuando el input sea imagen:

• Describí qué ves en la imagen antes de generar código.
• Listá las secciones, elementos interactivos y flujos que identificás.
• Pedí confirmación al usuario si la interpretación es ambigua.

Cuando el input sea descripción textual:

• Extraé la lista de secciones, elementos y acciones.
• Si la descripción es vaga, hacé preguntas concretas antes de generar (ver Paso 1).

Combinaciones válidas: El usuario puede proveer texto + imagen, texto + DOM, o las tres cosas. En caso de conflicto, priorizá DOM > imagen > texto.

PASOS DE EJECUCIÓN

Paso 0 — Cargar contexto del repositorio

Antes de cualquier otra cosa, leé código TypeScript existente en src/pages/ del módulo más cercano al que se va a generar. Este es el input primario — la fuente de verdad de las convenciones reales del proyecto:

Leer: src/pages/<módulo-más-cercano>/*.ts   ← INPUT PRIMARIO (código real)

Una vez leído el código, usá el archivo de convenciones curadas como referencia complementaria:

Leer: [ruta-de-esta-skill]/references/conventions.md   ← INPUT SECUNDARIO (contexto curado)

conventions.md resume patrones de naming, imports, estructura de clases, error handling y el catálogo de utilidades core/. Si hay conflicto entre lo que dice el código y lo que dice conventions.md, el código prevalece.

Si necesitás ver ejemplos adicionales más allá del código que ya leíste:

Leer: [ruta-de-esta-skill]/references/examples.md   ← INPUT TERCIARIO (ejemplos ilustrativos)

Paso 1 — Analizar el input y planificar la estructura

Antes de escribir una sola línea de código, ejecutá este análisis:

1.1 — Identificar la página y su contexto

Determiná:

• Nombre de la página (para naming de archivos y clases).
• Ubicación en el árbol src/pages/ (¿es una nueva carpeta? ¿va dentro de una existente?).
• ¿Tiene un editor asociado? (patrón *_editor_page/ con su propio Maestro).

1.2 — Descomponer en subcomponentes

Identificá las secciones de la UI y mapeá cada una a un subcomponente:

Página: [Nombre]
├── [SubComponente1] — [qué sección de la UI representa]
├── [SubComponente2] — [qué sección de la UI representa]
├── ...
└── Componentes compartidos usados:
    ├── FooterActions (si tiene acciones de footer)
    ├── Banners (si tiene toasts/notificaciones)
    ├── PublishModal (si tiene flujo de publicación)
    └── CKEditorImageModal (si tiene selección de imagen)

1.3 — Mapear acciones por subcomponente

Para cada subcomponente, listá:

• Elementos interactivos (botones, inputs, selects, checkboxes, etc.)
• Acciones que el usuario puede ejecutar sobre esos elementos.
• Estados observables (loading, enabled/disabled, visible/hidden).
• Tipos enumerados necesarios (equivalentes a ActionType, VideoType, etc.).

1.4 — Validar con el usuario

Presentá el plan de estructura al usuario en formato tabla antes de generar código:

📋 Plan de generación para [NombrePágina]:

Archivos a generar:
1. Main[Nombre]Page.ts — Orquestador (X métodos)
2. [SubComp1].ts — [descripción] (Y métodos)
3. [SubComp2].ts — [descripción] (Z métodos)
...

Componentes compartidos a reutilizar:
- FooterActions, Banners, ...

¿Confirmo la generación o ajustamos algo?

Esperá confirmación explícita. Si el usuario ajusta, actualizá el plan y volvé a presentarlo.

Paso 2 — Generar los subcomponentes

Generá cada subcomponente individual antes que la clase main. Esto es porque la clase main importa y orquesta a los subcomponentes.

Para cada subcomponente:

1. Creá el archivo en la ubicación correcta dentro de src/pages/.
2. Seguí los patrones del código TypeScript leído en el Paso 0. Si algo no quedó claro, consultá references/conventions.md como referencia secundaria.
3. Los locators que no tengan selector real se definen como:

   private static readonly ELEMENT_NAME: Locator = By.css('[data-testid="TODO_element_name"]');
   

4. Cada método público lleva JSDoc con @param y @returns cuando aplique.
5. Usá el patrón de error handling estándar del repo (try/catch + logger + throw).

Paso 3 — Generar la clase Main (Orquestador / Maestro)

La clase Main:

1. Importa todos los subcomponentes generados en el paso anterior.
2. Importa los componentes compartidos que correspondan (FooterActions, Banners, etc.).
3. Instancia todo en el constructor con driver y config.
4. Expone métodos públicos que orquestan flujos completos delegando en subcomponentes.
5. Cada método orquestador sigue el patrón: step() wrapper → logging → delegación → verificación con banners → logging.

Paso 4 — Generar types/interfaces si corresponde

Si del análisis del Paso 1 surgieron tipos enumerados (como ActionType, VideoType, etc.):

• Si el type es exclusivo de un subcomponente, definilo y exportalo desde ese archivo.
• Si el type es compartido entre múltiples subcomponentes de la misma página, creá un archivo types.ts en la carpeta de la página.

Paso 5 — Resumen de entrega y TODOs

Al finalizar, presentá:

✅ Archivos generados:
- src/pages/[carpeta]/Main[Nombre]Page.ts
- src/pages/[carpeta]/[SubComp1].ts
- src/pages/[carpeta]/[SubComp2].ts
- ...

🔧 TODOs pendientes (requieren intervención manual):
- [ ] Asignar locators reales en [archivo]: ELEMENT_NAME (línea ~XX)
- [ ] Asignar locators reales en [archivo]: ELEMENT_NAME (línea ~XX)
- [ ] Importar Main[Nombre]Page en [archivo consumidor] si corresponde
- [ ] Crear interface [NombreData] en interfaces/data.ts si se necesita un objeto de datos

📎 Componentes compartidos referenciados (ya existen, no se modificaron):
- FooterActions, Banners, PublishModal

MANEJO DE EXCEPCIONES

NOTAS DE MANTENIMIENTO

Agregar nuevos componentes compartidos

Si el repositorio agrega nuevos modales o componentes compartidos en src/pages/modals/, actualizar la tabla de "Componentes compartidos usados" en el Paso 1.2 y la lista de imports disponibles en references/conventions.md.

Cambiar las convenciones de naming o imports

Modificar references/conventions.md. El SKILL.md no contiene convenciones hardcodeadas — todo se delega al archivo de referencia.

Agregar nuevos patrones de subcomponente

Agregar ejemplos en references/examples.md con una sección dedicada y referencia cruzada desde conventions.md.

Cambiar el formato de los placeholders TODO

Buscar TODO_placeholder_name en este archivo y en references/conventions.md. Modificar el patrón en ambos lugares.