ADR-0013 — dai skills install --from (skills externas por-stack)

• Estado: aceptado
• Fecha: 2026-07-14
• Decide: lead / arquitecto de la metodología

Contexto

dai distribuye sus skills (las bundleadas: grill-*, link-us, tdd, …) e instala/convierte para Claude, Cursor y Copilot. Pero los equipos tienen skills propias de su stack (.NET, Java, Rust, …) que hoy no tienen lugar: o las copian a mano por repo (duplicación, sin conversión a los 3 asistentes), o las meten en el paquete dai — que rompe el ADN: dai es agnóstico del stack, opina solo en su dominio (trazabilidad/distribución), no sobre qué dicen tus skills.

Falta una forma de que dai convierta e instale skills externas, sin volverse dueño ni gatekeeper de ellas.

Decisión

Agregamos dai skills install --from <git-url|npm:pkg|path>[#ref]: instala skills externas desde un repo/dir/paquete (con estructura skills/<nombre>/SKILL.md, la misma de dai), convertidas para los 3 asistentes (Claude copia · Cursor skillToCursor · Copilot skillToPrompt → .github/prompts/).

• Tres fuentes: un git URL (github.com/org/skills[#ref] → clone), un path local, o un paquete npm (npm:@scope/pkg[@version] → npm pack a un temp, respetando el .npmrc del cwd, así resuelve registries privados con scope). Es común distribuir skills como paquete npm (una org publica sus componentes + skills juntas); materializarlo a mano era fricción de más.

• dai skills es el namespace canónico de las operaciones de skills, consistente con dai forge <verb>. dai skills install (sin --from) instala las de dai; dai install queda como alias silencioso (backward-compatible).

• Self-service, one-off, sin registro. No hay autorización central ni persistencia: no existe .dai/sources, dai no lleva registro de qué repos usan skills externas. El equipo las suma bajo su propio criterio.

• dai sync NO las toca — sigue siendo solo de las skills de dai. Si el equipo actualiza sus skills, re-corre --from.

• Colisión con una skill built-in de dai → warn + skip (no se pisa la metodología; renombran, p. ej. tdd-dotnet).

Consecuencias

• Más fácil: cada equipo suma sus skills por-stack sin tocar dai ni pedir permiso, y las escribe una vez (dai las sirve a Claude/Cursor/Copilot). El namespace dai skills deja lugar a crecer (skills list, …) sin comandos sueltos.
• Se acepta pagar: es one-off (dai no mantiene esas skills al día; re-corrés --from). Sin registro → dai no sabe qué repos tienen skills externas, a propósito: cero gatekeeping, bajo riesgo del equipo. Las fuentes remotas dependen de git/red/npm, y la auth se delega en la herramienta (git: SSH o credential helper; npm: el .npmrc del repo — dai no autentica): si puedes git clone o npm pack la fuente, dai instala desde ahí.

Alternativas consideradas

• Persistido (.dai/sources) + integrado a dai sync — descartado: obliga a dai a registrar y mantener fuentes externas (gatekeeping que el equipo no quiere), y acopla dai sync —que debe ser solo de dai— a repos ajenos.
• Meter las skills de stack en el paquete dai — descartado: rompe el ADN (dai agnóstico del stack).
• Comando suelto dai install --from sin namespace — descartado: dai skills <verb> es más claro y consistente con dai forge <verb>; dai install queda como alias.