Cargando la bóveda…
Cargando la bóveda…
No es cuántas skills tenés, es dónde las tenés. La regla simple para decidir cuáles van global y cuáles por proyecto, más la diferencia entre skill, herramienta y plugin que casi todos confunden.
"Instalá muchas skills y Claude se confunde."
Falso. El problema no es cuántas tenés — es dónde las tenés.
Si TODO está en ~/.claude/skills/ (global), Claude abre cada sesión cargando habilidades que no necesita. Para un proyecto Next.js no necesitás la skill de Django; para coding no necesitás la skill de email triage.
La fix es simple: separá global de proyecto.
Si la skill aplica a TODOS tus proyectos → global. Si la skill aplica a UN proyecto específico → por proyecto.
Sin excepciones. Aplicada bien, resuelve el 90% del problema.
~/.claude/skills/
├── code-reviewer/
├── voice-writer/
├── brief-manana/
└── prd-template/Se cargan en toda sesión, cualquier proyecto.
mi-proyecto/
├── .claude/
│ └── skills/
│ ├── stripe-checkout/
│ ├── deploy-staging/
│ └── i18n-strings/
├── src/
└── ...Se cargan solo cuando trabajás en este proyecto.
Tres conceptos que casi todo el mundo confunde:
Un comportamiento. Conjunto de instrucciones (SKILL.md) que Claude sigue cuando detecta que aplica.
Ejemplo: code-reviewer — Claude revisa código cuando vos decís "review".
Un acceso a algo externo. Función que Claude puede invocar para obtener data o ejecutar acción.
Ejemplo: MCP de Supabase — Claude consulta tu DB.
Un combo empaquetado. Junta skills + tools + comandos para resolver un caso de uso.
Ejemplo: Claude Small Business — junta 15 skills + 15 flujos + 7 conectores para PyMEs.
Detalle en anatomía de Claude.
Antes de instalar una skill, preguntate:
Sí → Global No → Por proyecto
Sí (paths, nombres de archivos del proyecto, etc.) → Por proyecto, sí o sí No → Puede ser global
Sí → Por proyecto (versionado en git, compartida) No → Global (queda en tu compu)
El otro extremo también es problema: todo por proyecto significa:
code-reviewer en cada repo → trabajo duplicadoLo personal y lo genérico va global. Lo específico al proyecto va por proyecto.
Si tu ~/.claude/skills/ tiene 20+ skills:
> Auditá ~/.claude/skills/. Por cada una:
1. ¿Esta skill es específica a algún proyecto? (sí/no)
2. Si es específica, ¿a cuál?
3. ¿Vale moverla a `.claude/skills/` de ese proyecto?
4. Si es genérica, ¿se está activando correctamente o se confunde con otras?
Devolveme lista priorizada de movimientos sugeridos.Después de auditar, hacés los moves. Resultado: global limpio, proyectos con su contexto, Claude más certero.
Lo que termina en cada lado para alguien con uso maduro:
~/.claude/skills/ (global, 5-10 skills)#code-reviewer — para todo proyectovoice-writer — tu voz personalbrief-manana — workflow diarioprd-template — generador de PRDsprompt-clarifier — detecta prompts vagoscommit-message — genera commits formateados.claude/skills/#deploy-<proyecto> — pipeline específico<dominio>-conventions — convenciones del dominio<integraciones>-helpers — Stripe, Auth0, etc. de ESTE proyecto# ❌ Skill genérica con paths específicos
Cuando hagas deploy, ejecutá:
- npm run build
- gsutil cp dist/ gs://mi-bucket-X/ ← ESPECÍFICO A UN PROYECTOMal. Esta skill global se va a activar en otros proyectos donde no aplica. Movela a por proyecto o parametrizala (lee config del proyecto).
20 skills global = Claude carga 20 descriptions al inicio de cada sesión. Tarda más y se confunde. Si tenés >15 globales, considerá mover algunas.
.claude/skills/ de proyecto debe estar en git. Sino tu compañero no las tiene cuando clona el repo.
Tu skill voice-writer con TU voz no debería estar en el repo de la empresa. Esas van a global.
Algunos plugins instalan decenas de skills global. Mirá Agency Agents (144 agentes) o 40 skills Claude.
No los instales todos. Elegí los 5-10 que matchean tu trabajo real, descartá el resto. Sino caés en sobreinstalación.
15 minutos de organización mensual → Claude funciona mejor el resto del mes.