REFERENCIA
Perfiles y configuración
Cuando ejecutas /kit-init, eliges un perfil — una plantilla de rol que decide qué agentes, skills y reglas aterrizan en tu proyecto. A partir de ahí, todo lo que el kit sabe sobre tu proyecto vive en un único archivo pequeño. Esta página es el mapa.
Los cinco perfiles
Un perfil es un punto de partida, no una jaula. Siempre puedes reformularlo más adelante con /kit-customize.
| Perfil | Ideal para | Lo que obtienes |
|---|---|---|
software | Construir un producto de principio a fin | Un equipo completo: PM, Tech Lead, Designer, DevOps, Backend, Frontend, QA, Security — más el flujo de tareas, el enrutamiento de diseño y skills de construcción conscientes del stack |
content | Escritura, publicación, trabajo de marca | PM, Editor, Designer, Researcher — con una skill de copywriting y el flujo de tareas |
research | Investigación y síntesis | PM, Researcher, Analyst — enfocados en delimitar, recopilar, analizar y reportar |
automation | Automatización con n8n / flujos de trabajo | PM, un especialista en n8n (con las skills n8n-* y las herramientas mcp__n8n__*) y un generalista |
minimal | Una configuración ligera y flexible | Un PM más un generalista que se adapta a cualquier tarea |
¿No sabes cuál elegir? minimal es la entrada más amable, y /kit-update te permite crecer hacia algo más completo después. Previsualiza cualquier elección primero:
/kit-init --dry-run
Qué configura cada perfil
Cada perfil define sus propios agentes, skills, reglas, nombres de rol y nombres de hito. Una comparación rápida del ritmo que asume cada uno:
| Perfil | Hitos |
|---|---|
software | Foundation → MVP → Beta → GA |
content | Outline → Draft → Review → Publish |
research | Scope → Gather → Analyze → Report |
automation | Backlog → Building → Live |
minimal | Backlog → Doing → Done |
El archivo de configuración de tu proyecto
Tras el init, .claude/kit.config.json guarda cada valor específico del proyecto — una única fuente de verdad que el kit lee en tiempo de ejecución. Rara vez lo editas a mano, pero aquí tienes qué significa cada clave.
| Clave | Lo que contiene |
|---|---|
project | El nombre, slug, propietario e idioma de tu proyecto |
profile | Desde qué perfil empezaste |
roles | Los nombres de rol en tu organización (editables) |
github | Repo, propietario y si el tablero de GitHub Projects está activado |
plans | Cómo se escriben los planes — markdown, mdx o none — y dónde viven |
memory | Si la memoria de MemPalace está activada y el "wing" de tu proyecto |
specKit | Si el desarrollo guiado por especificaciones está habilitado |
prePush | Un comando a ejecutar antes de git push (bloquea el push si falla) |
annotate | Si la anotación visual de UI está conectada, más su framework y backend |
kitVersion | La versión del kit con la que este proyecto se sincronizó por última vez — alimenta /kit-update |
skillPrompts | Tus respuestas recordadas a las preguntas sobre brechas de skills, para que el kit no pregunte dos veces |
Este archivo lo confirmas (commit) con tu equipo. Los ajustes que pueden contener secretos quedan fuera de git automáticamente.
Sobrescrituras a nivel de carpeta
Si una carpeta contiene varios proyectos, puedes definir preferencias compartidas una sola vez. Coloca un .claudekit/config.json en una carpeta superior y se propagará en cascada a todo lo que esté por debajo — como .editorconfig. La carpeta más cercana gana y se fusiona sobre la configuración propia de cada proyecto, de modo que los valores por defecto compartidos se aplican sin pisotear las decisiones específicas de un proyecto.
Cómo funciona por dentro
De dónde vienen los ajustes. /kit-init lee el profiles/*.json elegido, sustituye los valores de tu proyecto en las plantillas, resuelve los bloques condicionales (IF:MEMORY, IF:PROJECTS_V2, IF:PLANS, IF:DESIGN) y escribe un .claude/ autocontenido. Las skills leen los valores en vivo desde .claude/kit.config.json en tiempo de ejecución, así que hay una única fuente de verdad por proyecto.
Forma del JSON del perfil. Cada perfil declara agents, skills, rules, roles, milestones y un bloque defaults (p. ej. plans_format, memory, speckit). Ejemplo, de software:
{
"name": "software",
"agents": ["pm", "tech-lead", "designer", "devops", "backend", "frontend", "qa", "security"],
"rules": ["communication-style", "task-management", "plan-output-format", "design-routing", "mempalace", "skill-gaps"],
"milestones": ["Foundation", "MVP", "Beta", "GA"],
"defaults": { "plans_format": "markdown", "memory": "off", "speckit": "off" }
}
Entorno KIT_*. Los scripts del proyecto cargan (source) scripts/lib/kit-config.sh y llaman a load_kit_config, que aplana kit.config.json en variables de entorno:
| Variable | Desde |
|---|---|
KIT_VERSION | .kitVersion |
KIT_PROJECT_NAME · KIT_PROJECT_SLUG · KIT_OWNER_NAME · KIT_LANG | .project.* |
KIT_PROFILE | .profile |
KIT_REPO · KIT_OWNER · KIT_PROJECTS_V2 · KIT_PROJECT_NUMBER · KIT_PROJECT_TITLE | .github.* |
KIT_PLANS_FORMAT · KIT_PLANS_DIR | .plans.* |
KIT_MEMORY · KIT_WING | .memory.* |
KIT_SPECKIT | .specKit.enabled |
KIT_ANNOTATE_ENABLED · KIT_ANNOTATE_BACKEND · KIT_ANNOTATE_FRAMEWORK | .annotate.* |
KIT_ROLES · KIT_MILESTONES | .roles[] · .milestones[] (separados por saltos de línea) |
La carga requiere jq. Si falta .claude/kit.config.json, te indica que ejecutes /kit-init primero.
Superposiciones de .claudekit. Tras la carga, load_kit_config recorre los directorios ancestros buscando archivos .claudekit/config.json y los fusiona en profundidad sobre la configuración del proyecto (de lejano → cercano, gana el más cercano) usando jq '.[0] * .[1]'. Reexporta los campos que tienen sentido a nivel de carpeta — KIT_LANG, KIT_PLANS_FORMAT y el conjunto KIT_ANNOTATE_* — y expone el resultado totalmente fusionado como KIT_EFFECTIVE_CONFIG. Los proyectos sin .claudekit/ se comportan exactamente igual que antes.