/config

description: "Configura Alfred Dev: autonomía, proyecto, agentes opcionales, memoria y personalidad"

/alfred-dev:config

Lee el fichero `.claude/alfred-dev.local.md` si existe. Si no existe, créalo con la configuración canónica actual del plugin.

Escribe siempre la clave canónica `autonomia` en el frontmatter, aunque encuentres variantes legacy como `autonomía`. El runtime las entiende por retrocompatibilidad, pero la escritura nueva debe quedar normalizada.

Paso 0: helper determinista

Antes de razonar o preguntar, ejecuta este Bash inmediatamente para cargar o crear la configuración, detectar stack, construir las 7 secciones y generar el menú canónico:

python3 "${CLAUDE_PLUGIN_ROOT}/core/config_cli.py" "$PWD" --headless

Conserva ese stdout como `CONFIG_SUMMARY`. Si el comando falla porque `CLAUDE_PLUGIN_ROOT` no existe en desarrollo local, reintenta una sola vez con `python3 core/config_cli.py "$PWD" --headless` solo si estás en el repo del plugin. En modo headless, `CONFIG_SUMMARY` debe contener el marcador literal `CONFIG_HEADLESS_MENU`.

Modo no interactivo / `claude -p`

Si esta invocación se está ejecutando en modo no interactivo/headless (`claude -p`, SDK sin callback `canUseTool`, auditoría automatizada o cualquier contexto donde no puedas recibir una selección del usuario en esta misma llamada), **no llames `AskUserQuestion`**. En ese modo:

1. devuelve `CONFIG_SUMMARY` tal cual, sin reescribirlo con otra tabla; 2. no abras submenús; 3. no termines con una pregunta abierta.

No esperes indefinidamente una respuesta humana en modo headless y no abras los submenús de agentes opcionales ni memoria sin una selección real del usuario. Si llamas a `AskUserQuestion` y la herramienta vuelve cancelada, sin selección, sin respuesta utilizable o con cualquier señal de que el usuario no pudo elegir, trátalo igual que modo headless: devuelve `CONFIG_SUMMARY` tal cual. No conviertas esa cancelación en una pregunta abierta tipo "¿sobre qué sección actúo?".

Presenta al usuario la configuración actual organizada en secciones:

1. **Autonomía por fase** (`interactivo` / `semi-autonomo` / `autonomo`): producto, arquitectura, desarrollo, calidad, documentacion, entrega 2. **Proyecto** (detectado o manual): runtime, lenguaje, framework, ORM, test runner, bundler 3. **Agentes opcionales**: data-engineer, ux-reviewer, performance-engineer, github-manager, seo-specialist, copywriter, librarian, i18n-specialist, lucius 4. **Memoria persistente**: enabled, sync_to_native, sync_commits_limit, capture_decisions, capture_commits, retention_days 5. **Compliance**: estilo, lint, format_on_save 6. **Integraciones**: git, ci, deploy 7. **Personalidad**: nivel_sarcasmo (1-5), verbosidad, idioma, celebrar_victorias, insultar_malas_practicas

Usa AskUserQuestion para preguntar qué sección quiere modificar con un **menú principal navegable**. No inventes ese menú a mano si puedes evitarlo: toma como referencia las funciones canónicas de `core/config_loader.py` (`build_config_section_summaries()` y `build_config_section_menu()`) para que las descripciones de cada sección salgan de la configuración efectiva real y no de texto reconstruido en el prompt. Después de cada cambio, actualiza el fichero `.local.md`.

Antes de guardar, construye un **preview antes/después** de la sección tocada. No improvises ese diff en prosa si puedes evitarlo: toma como referencia `build_config_section_change_preview()` para confirmar qué cambia realmente y detectar no-ops antes de reescribir el fichero.

Cuando el usuario confirme, evita recomponer el ciclo “cargar → aplicar → guardar” a mano: usa como referencia `update_config_section()` o `update_project_config_section()` para persistir solo la sección tocada sin perder notas, orden estable ni claves canónicas.

No reescribas el frontmatter “a mano” si puedes evitarlo: toma como referencia las funciones canónicas de `core/config_loader.py` (`render_config_markdown()`, `save_config()`, `save_project_config()` y `apply_config_section_update()`) para mantener orden estable, claves canónicas y round-trip limpio con `load_config()`.

Si el proyecto no tiene configuración y hay ficheros en el directorio actual, ejecuta detección automática de stack y presenta los resultados al usuario para confirmar. Si es la primera sesión del proyecto, puedes encontrar que SessionStart ya haya sembrado `.claude/alfred-dev.local.md` con autonomía por fases en `autonomo` y memoria activada.

Sección de agentes opcionales

Alfred Dev tiene 10 agentes de núcleo (siempre activos) y 9 agentes opcionales que el usuario puede activar según las necesidades de su proyecto. Los agentes opcionales son predefinidos: vienen con el plugin pero no se activan hasta que el usuario lo decide.

Agentes opcionales disponibles

**Grupo A -- Técnicos:**

| Agente | Rol | Cuándo es útil | |--------|-----|----------------| | **data-engineer** | Ingeniero de datos | Esquema, migraciones, queries, índices o persistencia | | **performance-engineer** | Ingeniero de rendimiento | Latencia, bundles, memoria o cuellos de botella medibles | | **github-manager** | Gestor de GitHub | Proyectos con repositorio en GitHub | | **librarian** | Bibliotecario | Proyectos con memoria persistente o historial de decisiones; especialista solo bajo demanda |

**Grupo B -- Contenido y UX:**

| Agente | Rol | Cuándo es útil | |--------|-----|----------------| | **ux-reviewer** | Revisor de UX | Proyectos con frontend (React, Vue, Svelte, etc.) | | **seo-specialist** | Especialista SEO | Proyectos web con contenido público | | **copywriter** | Copywriter | Proyectos con textos públicos: landing, emails, onboarding | | **i18n-specialist** | Especialista i18n | Proyectos multiidioma o que necesitan prepararse para traducción |

**Grupo C -- Auditoría externa:**

| Agente | Rol | Cuándo es útil | |--------|-----|----------------| | **lucius** | Director técnico externo | Cuando el usuario quiere una segunda opinión t