feat(skill): distribución agnóstica al proveedor (Claude Code, OpenCode, …) — prioridad 0.11.0

[complexluise]

Por qué (el punto, no un nice-to-have)

b2g skill add (0.10.0, #188 / #192) instala solo para Claude Code (~/.claude/skills/). Eso ata bib2graph a un proveedor y repite la lógica de gatekeeping: solo quien tiene Claude accede a "pedirle al agente que use bib2graph". El valor central del comando skill es democratizar ese acceso, no restringirlo a un cliente. Abordarlo en serio (no trivial).

Qué queremos

Que el usuario (o su agente IA) declare su proveedor/cliente y skill instale en la ruta y el formato correctos para ese proveedor. Sin atar a uno solo.

Dirección (a diseñar)

• b2g skill add --provider claude-code|opencode|… (¿+ auto-detección del cliente?).
• Mapa proveedor → ruta + formato:
  • Claude Code: ~/.claude/skills/<n>/SKILL.md (✅ hecho en 0.10.0).
  • OpenCode: ruta/formato a investigar.
  • otros candidatos (Cursor, Continue, …): a relevar.
• ¿El contenido (SKILL.md) es portable entre proveedores o necesita variantes/adaptadores (frontmatter, convenciones de invocación)?
• ¿b2g skill providers / skill list para descubrir lo soportado?
• El version-lock skill==cli debe preservarse en todos los proveedores.

Open questions

• ¿Qué proveedores entran en el alcance inicial de 0.11.0? (al menos Claude Code + OpenCode).
• Abstracción: ¿un adapter por proveedor, o un formato común + transformación?
• Cambia el contrato CLI (skill add gana --provider) → probable ADR (enmienda al 0039).

Alcance

• 0.10.0: queda solo Claude Code, deliberado (feat(skill): distribuir skill de Claude Code end-user vía b2g skill add (#188) #192, ADR 0039 lo registra como limitación conocida).
• 0.11.0: PRIORIDAD. Puede crecer a epic cuando el diseño cuaje.

Relacionado: #188, #192, ADR 0039.