# Agency Agents Recomendados para MNQ Catering y Evento

## Objetivo

Definir qué agentes de `msitarzewski/agency-agents` conviene usar en este proyecto, según la fase de trabajo, para evitar ruido y usar solo los perfiles que realmente aportan valor.

## Agentes instalados en este proyecto

Los agentes quedaron disponibles en:

- `.opencode/agents/`

Instalados:

- `frontend-developer`
- `ui-designer`
- `ux-architect`
- `brand-guardian`
- `accessibility-auditor`
- `reality-checker`
- `seo-specialist`
- `cms-developer`
- `security-engineer`

---

## 1. Etapa actual — cierre fino del sitio

### Agentes recomendados

- **`frontend-developer`**  
  Para implementación en Astro/CSS/componentes.

- **`ui-designer`**  
  Para pulido visual premium y consistencia de interfaz.

- **`ux-architect`**  
  Para mejorar jerarquía, CTAs, estructura y flujo de navegación.

- **`brand-guardian`**  
  Para mantener el tono editorial premium de MNQ.

- **`accessibility-auditor`**  
  Para revisar accesibilidad real: foco, landmarks, semántica, legibilidad.

### Orden recomendado

1. `ux-architect`
2. `ui-designer`
3. `frontend-developer`
4. `accessibility-auditor`
5. `reality-checker`

---

## 2. Pre-SEO / antes de publicar

### Agentes recomendados

- **`seo-specialist`**  
  Para titles, metas, estructura semántica, enlazado y oportunidades de posicionamiento.

- **`brand-guardian`**  
  Para que la optimización SEO no rompa el tono premium/editorial.

- **`reality-checker`**  
  Para validar si el sitio está realmente listo para salir.

### Uso recomendado

- auditoría SEO on-page
- revisión de headings
- revisión de copy transaccional/local
- faltantes de metadata
- oportunidades en páginas de servicio

---

## 3. Fase 2 — CMS con Strapi

### Agente principal

- **`cms-developer`**  
  Para modelado de contenido, relaciones, estructuras editables y estrategia de integración CMS.

### Agente de seguridad recomendado

- **`security-engineer`**  
  Para revisar superficie de ataque, configuración, integraciones, secretos, validaciones y riesgos antes de exponer CMS, formulario real y chatbot.

### Agentes de apoyo

- **`frontend-developer`**  
  Para consumir contenido dinámico desde Astro.

- **`ux-architect`**  
  Para decidir qué contenido debe ser editable y qué conviene dejar fijo en frontend.

### Recomendación clave

No llevar todo al CMS. Priorizar solo contenido que realmente vaya a cambiar:

- textos de páginas
- CTAs
- FAQs
- bloques de servicio
- datos de contacto
- imágenes
- testimonios

Evitar meter al CMS estructura puramente técnica o layout fijo sin necesidad.

---

## 4. QA final antes de merge o publicación

### Agentes recomendados

- **`accessibility-auditor`**
- **`security-engineer`**
- **`reality-checker`**
- **`seo-specialist`** (opcional, pero recomendable)

### Orden recomendado

1. `accessibility-auditor`
2. `security-engineer`
3. `seo-specialist`
4. `reality-checker`

### Criterio

`reality-checker` debe entrar al final para dar el veredicto duro:

- está listo
- no está listo
- qué falta exactamente

---

## Shortlist recomendada para MNQ

Si hubiera que quedarse solo con los agentes más importantes para este proyecto:

1. `frontend-developer`
2. `ux-architect`
3. `brand-guardian`
4. `accessibility-auditor`
5. `security-engineer`
6. `cms-developer`

## Por qué esta shortlist

Porque cubre lo esencial del proyecto:

- implementación real
- criterio UX
- consistencia de marca
- accesibilidad
- revisión de seguridad
- preparación para la fase CMS

---

## Cuándo invocar `security-engineer`

Conviene invocarlo especialmente en estos momentos:

### 1. Antes de conectar el formulario a backend real

Objetivo:
- validar superficie de ataque
- revisar tratamiento de inputs
- revisar rate limiting
- revisar exposición innecesaria

Prompt sugerido:

```text
@security-engineer Revisá la implementación del formulario de contacto para identificar riesgos de validación, abuso, spam, exposición de datos y malas prácticas antes de conectarlo a backend real.
```

### 2. Antes de introducir Strapi en producción

Objetivo:
- revisar configuración inicial
- revisar permisos y roles
- revisar administración de secretos
- revisar exposición pública de endpoints

Prompt sugerido:

```text
@security-engineer Auditá esta propuesta de integración con Strapi para detectar riesgos de permisos, configuración insegura, fuga de datos, exposición administrativa y manejo de secretos.
```

### 3. Antes de incorporar PostgreSQL + pgvector + chatbot

Objetivo:
- revisar vectores de ataque
- revisar sanitización de entradas
- revisar aislamiento entre contenido interno y contenido público
- revisar riesgos de prompt injection y data leakage

Prompt sugerido:

```text
@security-engineer Revisá esta arquitectura con PostgreSQL, pgvector, embeddings y chatbot para detectar riesgos de prompt injection, fuga de información, abuso de endpoints y acceso indebido a contenido sensible.
```

### 4. Antes de merge o publicación

Objetivo:
- hacer una pasada final de endurecimiento
- detectar configuraciones flojas
- revisar headers, metadatos sensibles, formularios, links y exposición innecesaria

Prompt sugerido:

```text
@security-engineer Hacé una revisión final de seguridad sobre este proyecto web antes de merge/publicación y marcá riesgos críticos, warnings y quick wins.
```

---

## Siguiente paso sugerido

Cuando haga falta acelerar el trabajo con estos agentes, conviene preparar prompts reutilizables por fase:

- prompt de revisión visual premium
- prompt de auditoría SEO
- prompt de diseño de modelo Strapi
- prompt de QA final antes de merge
- prompt de revisión de seguridad pre-release