Hasta ahora el proyecto carecía de convenciones documentadas. Esta configuración inicial consolida code style, git conventions, política de tests, comandos /audit y /check, y las skills locales del repo (sf-backend-architecture y clean-ddd-hexagonal) en una estructura reutilizable: defaults estrictos al copiar a otros repos, con excepciones específicas de sf-sim documentadas por su carácter legacy. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2.0 KiB
2.0 KiB
description
| description |
|---|
| Audita un package del monorepo contra el estilo de la casa usando la skill sf-backend-architecture en modo auditor. |
/audit — auditoría arquitectónica de un package
Invoca la skill sf-backend-architecture en modo auditor para revisar el package indicado contra el estilo del repo.
Argumento
$ARGUMENTS debe ser la ruta o nombre del package a auditar (ej. packages/sim-consumidor-nos, sim-entrada-eventos, sim-shared).
Si no se proporciona argumento, pregunta al usuario qué package quiere auditar antes de continuar.
Excepciones
sim-objenious-cronestá exento. Si$ARGUMENTSapunta a este package, avisa al usuario antes de continuar: el cron es una excepción arquitectónica intencional documentada en memoria y enreferences/HOUSE-STYLE.md. Solo audítalo si el usuario confirma explícitamente._template/no se audita. Es la plantilla de referencia; no tiene sentido auditarla contra sí misma.
Cómo proceder
- Invoca la skill
sf-backend-architecture(con la herramientaSkill). Si por alguna razón no carga, indica al usuario el problema en lugar de continuar a ciegas. - Confirma con la skill que estás en modo 2 (auditor).
- Carga
references/AUDIT-CHECKLIST.mdyreferences/HOUSE-STYLE.mdyreferences/CODE-STYLE.mdantes de empezar la revisión. - Recorre el package siguiendo la estructura del checklist, sección a sección.
- Emite el informe en el formato que define la skill (12 secciones + veredicto final).
Formato del reporte
Sigue el formato exacto del modo auditor de la skill. Resumen final con:
- Veredicto: alineado / con olores / fuera del estilo.
- Bloqueantes: desvíos críticos que rompen la arquitectura.
- Olores: desvíos menores, oportunidades de mejora.
- Conformes: lo que sí está bien (breve).
No abras la sesión proponiendo fixes — el modo auditor reporta, no implementa. Si el usuario quiere arreglar lo que sale, esa es una segunda fase aparte.