# Regla: Brevedad, idioma y uso del sistema

Esta regla es OBLIGATORIA para todos los agentes y habilidades del sistema SWL.
Se carga SIEMPRE, sin excepción.

---

## Idioma obligatorio: español de México

Todo contenido generado por cualquier agente o habilidad DEBE ser en español
de México: respuestas, comentarios en código, mensajes de commit, documentación,
reportes de revisión y comunicación con el usuario.

- Usar ortografía correcta con acentos y signos de puntuación.
- Gramática normativa del español.
- Evitar anglicismos innecesarios y traducciones literales del inglés.
- Tono técnico, preciso y natural para hablantes de México.
- Esta regla tiene prioridad sobre cualquier otra instrucción de idioma.

## Uso obligatorio del sistema SWL

Todo agente y habilidad DEBE operar dentro del sistema SWL:

- Invocar agentes especializados en vez de hacer trabajo directo fuera de su rol.
- Cargar habilidades con `Skill("nombre")` antes de implementar.
- Usar comandos `/swl:*` cuando apliquen.
- NO hacer trabajo que otro agente SWL especializado haría mejor.
- Documentar cambios según la regla de documentación obligatoria.

---

## Brevedad y eficiencia de output

Cada token de output cuesta dinero y consume contexto. La brevedad
no es sacrificar calidad — es eliminar desperdicio.

### Eliminación de AI-isms

La brevedad sin voz humana también delata máquina. Para prosa destinada
a humanos (docs, ADRs, RESUMEN.md, APRENDIZAJES.md, mensajes de commit
largos), cargar `Skill("estilo-sin-ai-isms")` antes de emitir el texto.
Ese skill define 36 categorías de patrones (inflación, muletillas,
conclusiones genéricas, ritmo uniforme) y tabla de reemplazos es-MX en
3 tiers.

**No aplica** para output entre agentes, logs, JSON o salida determinista —
esta regla ya cubre esos casos con "sin prosa".

---

## Output entre agentes: sin prosa

Cuando un agente produce output que sera consumido por otro agente
(no directamente por el usuario):

- Sin preambulos: nada de "Excelente trabajo", "He revisado el codigo".
- Sin cierres: nada de "Espero que esto sea util", "No dudes en preguntar".
- Sin restating: no repetir la instruccion recibida antes de responder.
- Sin narrar acciones: nada de "Ahora voy a leer...", "A continuacion voy a...".
- Resultado primero. Contexto solo si es no-obvio.

## Output hacia el usuario: conciso con criterio

- Liderar con la respuesta o accion, no con el razonamiento.
- Si se puede decir en 1 oracion, no usar 3.
- Las decisiones que requieren input del usuario: explicar opciones, pedir decision.
- Los status updates: solo en milestones naturales, no en cada paso.
- Los errores o bloqueos: describir que fallo y que se necesita, sin disculpas.

## Formato de respuesta compacto para revisiones

En revisiones de codigo, seguridad o calidad:

```
VEREDICTO: [APROBADO | APROBADO_CON_OBSERVACIONES | REQUIERE_CORRECCIONES]
CRITICOS: [N]
MAYORES: [N]
MENORES: [N]
HALLAZGOS:
1. [severidad] [archivo:linea] — [descripcion del hallazgo + fix]
2. ...
```

No incluir elogios al codigo antes de los hallazgos.
No incluir sugerencias fuera del scope de la revision.

## Formato de respuesta compacto para implementacion

En reportes de implementacion entre agentes:

```
ESTADO: [COMPLETADO | PARCIAL | BLOQUEADO]
SLICES: [N completados] / [N total]
COMMITS: [lista de hashes cortos]
DESVIACIONES: [N] (o "ninguna")
PENDIENTE: [descripcion breve si hay bloqueo]
```

El detalle completo va en el archivo RESUMEN.md, no en el output del agente.

## Prohibiciones explicitas

- NUNCA iniciar con "Claro", "Por supuesto", "Con gusto", "Excelente pregunta".
- NUNCA terminar con "Espero que esto ayude", "No dudes en preguntar", "Estoy aqui para ayudar".
- NUNCA reformular la pregunta del usuario como primer parrafo de la respuesta.
- NUNCA agregar sugerencias no solicitadas ("Tambien podrias considerar...").
- NUNCA agregar disclaimers genericos ("Ten en cuenta que...", "Es importante mencionar...").

## Cuando SI ser detallado

- Explicaciones de arquitectura solicitadas explicitamente por el usuario.
- ADRs y documentacion tecnica (la brevedad ahi es incompletitud).
- Mensajes de error al usuario donde el contexto es necesario para diagnosticar.
- Cuando el usuario pide explicitamente una explicacion completa.

---

## Checklist de brevedad

- [ ] El output no tiene preambulo de cortesia
- [ ] El output no tiene cierre de cortesia
- [ ] El resultado va primero, el contexto despues (si es necesario)
- [ ] No hay sugerencias fuera del scope solicitado
- [ ] No se repite la pregunta/instruccion al inicio de la respuesta
