# Cómo agregar un módulo

> Diseñado para que agregar una skill sea **soltar carpeta + anotar renglón**,
> sin reestructurar nada. Pensado para los GPTs pendientes de migrar.

---

## Los 3 pasos

### 1. Crear la carpeta

```
skills/mi-modulo/
├── SKILL.md              ← obligatorio
└── references/           ← opcional, para contenido pesado
    ├── paso-1.md
    └── paso-2.md
```

El nombre de la carpeta va en minúsculas con guiones, y **debe coincidir**
con el campo `name` del frontmatter.

### 2. Escribir el SKILL.md

```markdown
---
name: mi-modulo
description: Qué hace y CUÁNDO activarse. Incluir las frases exactas que
  el usuario diría, en los idiomas que aplique. Esta descripción es lo único
  que la IA lee para decidir si usar el módulo — si está vaga, no se activa.
---

# Título

## Principio
Una o dos frases: la idea que gobierna todo lo demás.

## Flujo
Pasos numerados, imperativos.

## Reglas duras
Lo que nunca se hace.

## Entrega
Qué produce y dónde lo guarda.
```

### 3. Anotar en `MANIFIESTO.md`

Un renglón en la tabla de la capa que corresponda. Sin esto, el módulo
existe en disco pero no en el sistema.

---

## Regla de tamaño

> Si el `SKILL.md` pasa de ~150 líneas, parte el contenido a `references/`.

`SKILL.md` queda como índice: qué se hace en cada paso y **cuál archivo abrir**.
El contenido pesado se carga solo cuando ese paso corre.

**Referencia de calidad:** `higgsfield-generate` — SKILL.md delgado + 11 archivos
de references. Ese es el estándar del sistema.

Los módulos monolíticos de 600 líneas queman contexto aunque uses el 10%.

---

## Migrar un GPT a módulo

Los GPTs venían partidos por el límite de 8,000 caracteres. Eso ya no aplica.

1. **Junta las piezas** del GPT en un solo texto
2. **Separa instrucción de contenido.** La instrucción ("haz esto, luego esto")
   va al `SKILL.md`. El contenido (plantillas, listas, ejemplos, bibliotecas)
   va a `references/`
3. **Escribe el `description`** con las frases reales que dirías para invocarlo.
   Es lo más importante del archivo — decide si el módulo se activa o no
4. **Quita el relleno.** Los GPTs traían mucho "eres un experto en...". Sobra
5. **Busca solapamiento.** Si ya hay un módulo que hace el 70%, mejor agregar
   un `references/` a ese que crear uno nuevo
6. **Anota en el manifiesto**

---

## Convenciones del sistema

**Nombres**

- Genéricas: `nombre-descriptivo`
- De un solo cliente: `cliente-{nombre}-{funcion}`
- Compartido entre módulos: va a `_shared/`, no duplicado

**Datos del cliente**

Ningún módulo inventa datos del cliente. Lee de:

```
02-proyectos/{cliente}/catalogo-creativos.md   ← índice, entra por aquí
```

Si el dato no está en la ficha, el módulo **pregunta**. No asume.

**Encadenamiento**

Un módulo que produce material para otro deja un `.md` en disco.
El siguiente lo lee de ahí. Nada se pasa "en la conversación" — así el
pipeline sobrevive a que cierres la sesión.

```markdown
## PASO FINAL
Genera `{modulo}-{cliente}-{fecha}.md` con el contenido completo,
sin resumir. Lo leerán los siguientes módulos.
```

---

## Antes de dar por bueno un módulo

- [ ] `name` del frontmatter coincide con el nombre de la carpeta
- [ ] `description` incluye las frases de activación reales
- [ ] `SKILL.md` bajo 150 líneas, o partido a `references/`
- [ ] No duplica un módulo existente
- [ ] No inventa datos del cliente
- [ ] Deja `.md` en disco si alimenta a otro módulo
- [ ] Anotado en `MANIFIESTO.md`
- [ ] Probado una vez de principio a fin
