Files
fn_registry/.claude/rules/capability_groups.md
egutierrez 47fac22230 chore: auto-commit (799 archivos)
- .claude/CLAUDE.md
- .claude/commands/subagentes.md
- .claude/rules/INDEX.md
- .mcp.json
- bash/functions/cybersecurity/analyze_dns.md
- bash/functions/cybersecurity/audit_http_headers.md
- bash/functions/cybersecurity/audit_ssh_config.md
- bash/functions/cybersecurity/check_firewall.md
- bash/functions/cybersecurity/detect_suspicious_users.md
- bash/functions/cybersecurity/encrypt_file.md
- ...

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-14 00:28:20 +02:00

3.2 KiB

Capability groups: tags + paginas madre en docs/capabilities/

Un capability group es un cluster de >=3 funciones del registry que comparten un dominio operativo (ej. notebook, metabase, deploy). Cada grupo tiene un tag plano (sin prefijo) y una pagina madre en docs/capabilities/<grupo>.md. La pagina madre desbloquea el conjunto entero en un solo read.

Para que existen

Sin grupos, Claude redescubre funciones via FTS5 una a una cada sesion ("¿como interactuo con Jupyter? ¿como subo deploy?"). Con grupos, Claude lee docs/capabilities/<grupo>.md y carga las 5-10 funciones del cluster con su ejemplo canonico — menos turnos perdidos en discovery.

Convencion de tag

  • Slug del grupo = tag plano. Ej: notebook, metabase, android-emu.
  • No prefijos (cap:, group:). Ya hay namespacing implicito porque convivirian con tags semanticos sueltos.
  • Una funcion puede llevar varios tags de grupo si pertenece a dos clusters (raro pero valido).
  • Filtro MCP: mcp__registry__fn_search query="" tag="notebook" lista el grupo.

Cuando crear grupo nuevo

  • Minimo 3 funciones afines. Con 2 no compensa pagina madre — quedan tags sueltos.
  • Dominio operativo claro: el grupo debe ser describible en 1 frase ("operar Jupyter colaborativo", "deploy via SSH+systemd").
  • Frontera neta con grupos existentes. Si solapa con otro -> reorganizar, no duplicar.

Como crear grupo

  1. Anadir el tag al frontmatter .md de >=3 funciones afines. fn index lo registra.
  2. Crear docs/capabilities/<grupo>.md con plantilla:
    • Lista de funciones: tabla ID | firma corta | que hace.
    • Ejemplo canonico: 1-2 bloques de codigo end-to-end con los IDs reales.
    • Fronteras: que NO cubre el grupo.
    • Prerequisitos y notas si aplica.
  3. Anadir fila al docs/capabilities/INDEX.md.
  4. Correr fn doctor capabilities para auditar drift.

Auto-generacion

fn doctor capabilities --update (TBD) reescribe la tabla de funciones de cada pagina madre preservando bloques curated (Ejemplo canonico, Fronteras, Notas). Las secciones curated nunca se sobrescriben.

Como Claude usa los grupos

Cuando una tarea cae en un dominio conocido:

  1. Read docs/capabilities/INDEX.md para localizar grupo.
  2. Read docs/capabilities/<grupo>.md para cargar funciones + ejemplo.
  3. Solo si el grupo no cubre lo necesario, mcp__registry__fn_search para funciones sueltas.
  4. Si el grupo deberia cubrir pero falta funcion -> fn-constructor + tagear con el grupo en el frontmatter.

Auditoria

fn doctor capabilities                # lista grupos + drift
fn doctor capabilities --json         # para agentes

Comprueba:

  • Tag con N >=3 funciones pero sin pagina madre -> "tag huerfano".
  • Pagina madre sin tag respaldo -> "grupo fantasma".
  • Funcion con tag de grupo pero la pagina madre no la lista (autogen desfasada) -> "drift".

Relacion con dominios

Los dominios del registry (core, infra, finance, datascience, cybersecurity, shell, tui, pipelines, browser) son taxonomia ortogonal — un grupo puede atravesar varios dominios (ej. deploy toca infra y shell). NO renombrar dominio a grupo ni viceversa.