Manuel
235 lines
5.6 KiB
Markdown
235 lines
5.6 KiB
Markdown
# 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
|