Las convenciones viven en el proyecto

Un proyecto generado lleva una carpeta .prumo/. Por eso Prumo no es un scaffolder: el código llega con las reglas que sigue, escritas, en el repositorio donde se hace el trabajo.

Diecisiete áreas, y solo las que aplican

Solo core se incluye siempre, porque todo lo que contiene vale para cualquier tipo. El resto sigue a las respuestas, ya que un consejo sobre una plataforma que el proyecto no tiene es peor que ningún consejo.

core/Siempre
i18n/Solo cuando las respuestas lo piden
api/Solo cuando las respuestas lo piden
database/Solo cuando las respuestas lo piden
client/Solo cuando las respuestas lo piden
web/Solo cuando las respuestas lo piden
web-vite/Solo cuando las respuestas lo piden
web-next/Solo cuando las respuestas lo piden
web-astro/Solo cuando las respuestas lo piden
mobile/Solo cuando las respuestas lo piden
monorepo/Solo cuando las respuestas lo piden
multi-tenancy/Solo cuando las respuestas lo piden
mcp/Solo cuando las respuestas lo piden
codes/Solo cuando las respuestas lo piden
email/Solo cuando las respuestas lo piden
phone/Solo cuando las respuestas lo piden
social/Solo cuando las respuestas lo piden

Leer los documentos

Sin atarse a un asistente

.prumo/ es la única fuente de verdad de lo que trae Prumo, y .context/ de lo que el proyecto decide por sí mismo, que vale cuando los dos discrepan. Ambos se mantienen neutrales. El scaffolder escribe el archivo de entrada que carga cada herramienta, y nada más: AGENTS.md es el puntero real, que leen Codex, Cursor, Copilot, Gemini CLI y otros, y CLAUDE.md es un import de él. No se generan skills, subagentes ni slash commands, porque eso cambia cada trimestre.

Después, son de ustedes

Una vez escritos, esos documentos pertenecen al equipo. Prumo no vuelve a reescribirlos. Actualizar el .prumo/ de un proyecto en su lugar quedó, a propósito, para después de la 1.0.