MNQ-Catering-y-Evento/docs/agency-agents-recommended.md

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:

@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:

@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:

@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:

@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