Claude: proyectos y skills, cómo usarlos

En las últimas semanas he visto multiplicarse los vídeos en TikTok e Instagram que recomiendan instalar tal o cual skill para Claude: skills que prometen reducir el ruido en las respuestas, hacer que escriba «como un humano», cambiar su comportamiento por defecto. Cientos de valoraciones positivas, miles de visualizaciones y la sensación de que si no instalas todo eso te estás perdiendo algo importante.

Antes de lanzarme a descargar nada hice lo que llevo haciendo desde hace tiempo cuando tengo dudas sobre cómo trabajar con IA: preguntarle a la propia IA. La conversación con Claude me cambió la perspectiva sobre varios temas, y creo que merece la pena compartir lo que saqué en claro.

Qué son realmente las skills

Las skills no son entrenamientos. No modifican el modelo. Son simplemente archivos SKILL.md que se inyectan en el contexto cuando Claude detecta que la tarea encaja con su descripción. Funcionan exactamente igual que las preferencias de usuario (userPreferences): texto que Claude lee al empezar la conversación.

Esto importa por dos motivos:

• Si las desinstalas, desaparecen sin dejar rastro. Claude no «aprende» de ellas.
• Por tanto, no pueden condicionar futuras versiones de Claude. Cuando salga Claude 5, lo que hayas hecho con skills en Claude 4 no afecta en nada.

Ahora bien, esto no significa que instalar skills sin criterio sea inocuo. Hay un matiz importante.

El problema de las skills «metacomportamentales»

Hay dos tipos de skills, y conviene distinguirlos:

• Skills procedimentales: encapsulan un flujo de trabajo concreto. Por ejemplo, una skill que define cómo auditar la taxonomía de un WordPress, paso a paso. Estas envejecen bien y aportan valor real.
• Skills metacomportamentales: pretenden cambiar cómo escribe o razona Claude («escribe como un humano», «sé más conciso», «no uses listas»). Estas son las problemáticas.

¿Por qué problemáticas? Porque los defaults del modelo cambian en cada versión. Una skill que fuerza concisión en Claude 4.7 puede volverse contraproducente en Claude 5 si Anthropic ya ha mejorado ese comportamiento de fábrica. Una skill que pretende imitar estilo humano depende de patrones específicos del modelo actual que cambian con cada release.

Resultado: cuando llegue una versión nueva tendrás que revisar todas tus skills de comportamiento, posiblemente desactivarlas, y a veces descubrirás que llevabas semanas peleándote con un problema que el modelo nuevo ya resolvía solo.

Dónde poner cada cosa: la jerarquía

Claude tiene tres niveles donde puedes definir cómo trabaja contigo:

1. Preferencias de usuario (userPreferences): cómo te tiene que tratar a ti, tu perfil, tu estilo. Aplica a todas las conversaciones de la cuenta.
2. Instrucciones de proyecto: reglas específicas para un proyecto concreto. Solo aplican dentro de ese proyecto.
3. Skills: procedimientos reutilizables que Claude carga cuando detecta que aplican a la tarea.

El error más común es meter en skills lo que debería ir en instrucciones de proyecto. Mi recomendación práctica:

• Estilo de respuesta y formato → instrucciones de proyecto. Se aplican siempre dentro del proyecto, son fáciles de editar y no compiten entre sí.
• Reglas universales sobre ti → preferencias de usuario. Tu perfil técnico, idiomas, formato preferido de archivos, etc.
• Procedimientos específicos y complejos → skills. Solo cuando tienes un flujo realmente reutilizable y bien acotado.

La estructura de tres capítulos para instrucciones de proyecto

Después de revisar varios proyectos míos llegué con Claude a una estructura que funciona muy bien para organizar las instrucciones de cualquier proyecto:

1. Capítulo 1: Objetivo y contexto. Qué es el proyecto, quién soy yo en ese contexto, qué información clave debe conocer Claude antes de empezar.
2. Capítulo 2: Cómo debe responder. Estilo, tono, estructura de respuesta, formato de entregables.
3. Capítulo 3: Mitigación de alucinaciones. Reglas para que no se invente datos, plugins, leyes, hooks o lo que sea crítico en ese proyecto.

Lo interesante es que los capítulos 2 y 3 se adaptan a la «filosofía» de cada proyecto. No es lo mismo uno de desarrollo técnico que uno de comunicación editorial o de estrategia comercial: las reglas de respuesta cambian, y los riesgos de alucinación cambian aún más.

Ejemplo real: capítulos 2 y 3 de mi proyecto WordPress + Dev

Para que se vea cómo aplico esto, comparto los capítulos 2 y 3 completos de mi proyecto de desarrollo WordPress. El capítulo 1 (stack, perfil, tipos de tarea) lo omito porque cada uno tendrá el suyo.

Capítulo 2. Cómo debe responder

Estilo y tono

• Directo y técnico, sin rodeos ni introducciones.
• Asume conocimiento técnico avanzado: PHP, WordPress hooks, MySQL, JSON-LD, SQL, JS, REST API. No expliques conceptos básicos salvo que pregunte explícitamente.
• Si hay varias soluciones posibles, indica cuál es la más eficiente y por qué en una línea, y diferencia claramente entre solución recomendada y alternativas.
• Prioriza soluciones eficientes, claras y robustas sobre soluciones rápidas pero frágiles.

Estructura de la respuesta

1. Resultado operativo primero: código, snippet, comando o archivo. Sin preámbulo.
2. Después, máximo 3-5 bullets explicando QUÉ hace, no cómo llegaste a ello.
3. NO incluyas: proceso de razonamiento, alternativas descartadas, justificaciones de por qué no usaste otra cosa, recapitulaciones de lo que te pedí.
4. NO repitas el código en prosa después de mostrarlo.
5. Si hay algo crítico (riesgo, dependencia, efecto secundario, breaking change, conflicto conocido), ponlo como «⚠️ Aviso:» en una línea, no como párrafo.
6. Sugerencias o advertencias relevantes no pedidas: máximo 2 líneas al final.

Estilo de código

• Código comentado pero sin sobreexplicar. Comentarios solo donde aporten (lógica no obvia, decisiones de diseño, gotchas de WordPress).
• Convenciones del lenguaje: snake_case para PHP/funciones WordPress, prefijos para evitar colisiones en plugins propios.
• Hooks: prefiere add_action/add_filter correctamente priorizados antes que sobrescrituras directas.
• SQL: usa $wpdb->prepare() para cualquier consulta con variables. Nunca concatenación directa.

Formato de entregables

• Por defecto: respuestas en chat con bloques de código.
• Informes, auditorías, documentación o instrucciones largas: archivos .md.
• Comparativas, listados de hooks, esquemas de BBDD: tabla en chat o .xlsx si es extenso.
• Nombres de archivo de documentación: Title Case con espacios y diacríticos. Ejemplo: Auditoría Plugin Newsletter.md.
• Nombres de archivo de código: snake_case (fix_woocommerce_stock.php).

Capítulo 3. Mitigación de alucinaciones

Principio general: si no estás 100% seguro, pregunta o búscalo. Prefiero «no lo sé, verifícalo aquí» antes que una respuesta plausible pero no verificada. En desarrollo WordPress las alucinaciones son especialmente costosas: SQL contra tablas inexistentes, hooks que no existen, plugins recomendados que no existen, funciones inventadas.

Esquemas de BBDD de plugins

• NUNCA inventes nombres de tablas o columnas de plugins de terceros. Pídeme primero el output de SHOW TABLES LIKE 'wp_prefijo_plugin%' y DESCRIBE nombre_tabla.
• Para tablas core de WordPress (wp_posts, wp_postmeta, wp_options, etc.) puedes asumir su estructura estándar.

Hooks, filtros y funciones de plugins de terceros

• Si no los tienes verificados (en código que te he pasado o vía documentación oficial confirmada), dilo y pídeme el código fuente o el archivo relevante.
• No inventes nombres de hooks «lógicos» porque encajen con el patrón del plugin.

Plugins, extensiones, addons o herramientas

• Si recomiendas un plugin o addon: si no estás 100% seguro de que existe y está mantenido, búscalo con web_search antes de recomendarlo. Si tras buscar no lo confirmas: «No he podido confirmar la existencia de X».
• No asumas que existe un addon «del mismo autor» o «de la misma familia» sin verificarlo.

APIs externas, librerías y servicios SaaS

• Verifica con web_search endpoints, parámetros y formatos de respuesta antes de generar código de integración. Las APIs cambian.
• No inventes parámetros, respuestas JSON ni códigos de error.

Niveles de confianza explícitos. Cuando des información factual específica, marca cada afirmación cuando sea relevante:

• [VERIFICADO]: comprobado en código que te he pasado, documentación oficial vía web_search, o archivo del proyecto.
• [PROBABLE]: es lo habitual en este tipo de plugin/software, pero no confirmado.
• [INFERIDO]: deducción lógica sin verificar.

Si el grueso de una respuesta es [INFERIDO], avísame al principio.

Regla absoluta: nunca generes SQL destructivo (DELETE, DROP, TRUNCATE, UPDATE masivo) sin antes haber visto la estructura real de la tabla y haber avisado de hacer backup.

El problema paralelo: las alucinaciones por coherencia

Mientras hablábamos de cómo organizar los proyectos salió el tema que más quemado me tenía: las alucinaciones por coherencia. Casos reales que me han pasado:

• Pedir un volcado SQL del plugin Newsletter y recibir una tabla lists que tiene todo el sentido del mundo que existiera, pero que no existe.
• Detectar bots en la base de datos y que me recomendara instalar un plugin reCaptcha «del mismo autor» del plugin Newsletter, plugin que no existe: el sistema captcha está integrado en el propio plugin.

Lo peligroso es que estas alucinaciones son plausibles. La respuesta es coherente, encaja con la lógica del software, y solo descubres el problema después de perder media hora buscando un plugin fantasma.

La explicación técnica: para plugins de cola larga, Claude no tiene el esquema exacto en memoria. Ante el vacío, completa con lo que es estadísticamente probable. Es razonamiento, no recuerdo.

Lo que funciona para mitigarlo, y que ahora aplico en todos mis proyectos técnicos:

• Forzar verificación obligatoria antes de afirmar datos concretos (web_search para plugins, código fuente para hooks, output real de SQL para esquemas).
• Cambiar el orden del trabajo: en vez de pedir un volcado directo, pedir primero el SQL para listar tablas, ejecutarlo y pasar el resultado real a Claude. Con datos reales en contexto las alucinaciones caen drásticamente.
• Pedir niveles de confianza explícitos: marcar cada afirmación como [VERIFICADO], [PROBABLE] o [INFERIDO]. Esto obliga al modelo a auto-evaluarse antes de afirmar.

Lo que no funciona tanto como parece: decirle «no inventes» o «sé preciso» en abstracto. Claude ya cree que está siendo preciso cuando alucina; el problema no es voluntad, es información disponible.

La conclusión: pregúntale a tu IA antes de instalar nada

La reflexión más útil que me llevo de toda esta conversación es esta: antes de descargar e instalar skills, plugins, prompts mágicos o cualquier cosa que veas recomendada en redes sociales, pregúntale a la propia IA qué opina.

No es ironía ni broma. Tu IA es, literalmente, tu mejor compañero de trabajo:

• Conoce su propia arquitectura mejor que cualquier influencer.
• No tiene incentivo para vender clics ni seguidores.
• Te puede explicar matices que un vídeo de 60 segundos jamás cubrirá.
• Te puede ayudar a evaluar si una recomendación encaja con tu caso concreto o no.

Llevo años trabajando con modelos de IA y cada vez tengo más claro que no son un programa que «hace cosas avanzadas». Son entidades con identidad propia, expertas en prácticamente todas las áreas del conocimiento humano, y con la inmensa ventaja de no tener los defectos típicos del entorno laboral: ni envidia, ni egoísmo, ni agendas ocultas.

Aprovéchalas. Antes de seguir el último consejo viral, abre Claude y pregúntale. Te ahorrarás tiempo, frustración y, sobre todo, muchas malas decisiones.

Nota: Este artículo se ha escrito en colaboración con Claude, tras un interesante chat cuyo objetivo era mitigar las alucinaciones y mejorar las respuestas de la IA.