- .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>
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
- Anadir el tag al frontmatter
.mdde >=3 funciones afines.fn indexlo registra. - Crear
docs/capabilities/<grupo>.mdcon 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.
- Lista de funciones: tabla
- Anadir fila al
docs/capabilities/INDEX.md. - Correr
fn doctor capabilitiespara 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:
Read docs/capabilities/INDEX.mdpara localizar grupo.Read docs/capabilities/<grupo>.mdpara cargar funciones + ejemplo.- Solo si el grupo no cubre lo necesario,
mcp__registry__fn_searchpara funciones sueltas. - 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.