egutierrez
47fac22230
- .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>
61 lines
3.2 KiB
Markdown
61 lines
3.2 KiB
Markdown
## 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
|
|
|
|
```bash
|
|
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.
|