🧩 Skill de dominio vs. skill de proceso
Hay dos familias de skills. La de dominio codifica conocimientos sobre una cosa: vercel-react-best-practices, supabase-postgres, stripe-best-practices. La de proceso codifica CÓMO piensa y trabaja el agente — independientemente del tema. Es la diferencia entre "qué saber sobre React" y "cómo depurar cualquier cosa".
📚 Skill de dominio
- ›Responde "qué sé sobre X"
- ›Se activa cuando aparece el tema X
- ›Envejece junto con el dominio (versión del framework)
- ›Ej.:
frontend-design,neon-postgres
🧠 Skill de proceso
- ›Responde "CÓMO trabajar/pensar"
- ›Se activa por tipo de tarea, no por tema
- ›Atemporal: sirve para cualquier lenguaje/proyecto
- ›Ej.:
test-driven-development,systematic-debugging
💡 Por qué el proceso escala mejor
Una skill de dominio sirve a quienes trabajan en ese dominio. Una skill de proceso sirve cualquiera que programe. Por eso test-driven-development llega a 107k instalaciones (obra/superpowers): TDD funciona igual en Python, Go, Rust o TypeScript. El proceso tiene un mercado total más grande — y es lo que le falta al agente por defecto.
🧪 test-driven-development (107k)
La skill de proceso más instalada del nicho de Testing: test-driven-development, 107k installs, del repo obra/superpowers. No enseña una librería de pruebas: impone una orden de trabajo: escribir la prueba que falla ANTES de escribir la implementación. Eso cambia radicalmente el comportamiento del agente.
Qué cambia en el comportamiento del agente
- →Sin la skill, el agente escribe la implementación y tal vez pruebas después, demasiado optimistas.
- →Con la skill: primero escribe una prueba que fallo real, confirma el rojo y solo entonces implementa lo mínimo para que pase.
- →Resultado: cada feature nace con cobertura real, y el "pasa las pruebas" deja de ser una farsa.
Cuándo usar
Siempre que una tarea consista en implementar una feature o corregir un bug con un criterio de aceptación claro. No la uses para un prototipo desechable o una exploración ("solo voy a ver si la API responde"). La ventaja aparece cuando el output debe ser verificable.
🦸 La familia superpowers
El repo obra/superpowers popularizó la idea de empaquetar procesos de ingeniería como skills que se activan. Es una constelación de process skills que se invocan entre sí. Los cuatro pilares:
lluvia de ideas
Cambia: antes de crear nada, el agente explora la intención, los requisitos y el diseño en lugar de empezar por el código. Cuándo: funcionalidades nuevas, componentes, cambios de comportamiento — antes de tocar un archivo.
systematic-debugging
Cambia: en vez de adivinar las correcciones, el agente reproduce el problema, lo aísla, formula una hipótesis y prueba una cosa a la vez. Cuándo: cualquier error, fallo de prueba o comportamiento inesperado, ANTES de proponer la solución.
writing-plans
Cambia: convierte un spec en un plan de pasos verificables antes de la implementación. Cuándo: tarea de varios pasos con requisitos definidos — se convierte en la guía que otra sesión ejecuta.
verification-before-completion
Cambia: prohíbe declarar "listo/funciona" sin ejecutar el comando de verificación y ver el resultado. Cuándo: antes de afirmar una conclusión, hacer commit o abrir un PR: evidencia antes que afirmaciones.
💡 Skills que llaman a otras skills
La gracia de superpowers está en la composición: writing-plans apunta a brainstorming, que apunta a verification-before-completion. Cada una es atómica (una responsabilidad), pero juntas forman un flujo de trabajo disciplinado. Es lo contrario de la skill «todo sobre X» de 800 líneas.
⚖️ Skill de proceso: rígida vs. flexible
No todas las skills de proceso se escriben igual. Existe un espectro entre la rígida (un procedimiento exacto, paso a paso, que no admite desviaciones) y la flexible (principios y heurísticas que el agente adapta al contexto). Elegir mal en el espectro es un antipatrón sutil.
🔒 Estricta (procedimiento)
Secuencia fija que debe seguirse al pie de la letra. Ej.: el ciclo red-green-refactor de TDD o una checklist de deploy.
- ✓Buena cuando saltarse un paso es costoso o peligroso
- ✓Resultado reproducible y auditable
- ✗Malo si el contexto varía mucho
🌊 Flexible (heurística)
Principios que el agente pondera. Por ejemplo, el brainstorming ("explora primero la intención"), pautas de diseño.
- ✓Buena cuando cada caso es diferente
- ✓Generaliza más allá de los ejemplos
- ✗Malo si necesitas garantizar la ejecución
la señal en el texto de la skill:
# RÍGIDA — verbos imperativos secuenciales, el orden importa 1. Escribe la prueba. 2. Confirma que falla. 3. Implementa lo mínimo. # FLEXIBLE — principio + por qué, el agente decide cómo "Antes de crear, explora la intención real: ¿el usuario quiere X o quiere resolver Y? Pregunta qué falta antes de asumir."
💡 La regla práctica
Si equivocarte en un paso causa daños (deploy roto, datos perdidos), elige la opción rígida. Si el valor está en el criterio (diseño, priorización, depuración exploratoria), elige la flexible y explica por qué — recuerda que los MUST en mayúsculas en una skill flexible generan sobreajuste.
❤️ Por qué estas son tan apreciadas
Las skills de proceso aparecen de forma desproporcionada entre las más instaladas porque resuelven un problema que toda persona que usa un agente tiene todos los días y en todos los proyectos. Tres razones concretas:
Corrigen el comportamiento predeterminado perezoso
Sin instrucciones, el agente tiende a saltarse las pruebas, improvisar fixes y declarar "listo" demasiado pronto. Estas skills imponen rigor donde suele faltar por defecto.
Mercado total enorme
Sirven para cualquier lenguaje y cualquier proyecto. Una skill de Postgres solo les interesa a quienes usan Postgres; "cómo depurar" le interesa a todo el mundo.
Efecto compuesto y confiable
Aplicadas en todo el trabajo, las mejoras se acumulan: menos retrabajo, menos «creí que funcionaba». El usuario nota la diferencia en la primera semana.
El contraste con Testing&QA como grupo
Curioso: el grupo Testing&QA tiene 1.339 skills pero solo 0,60M installs en total: un promedio bajo. Aun así test-driven-development por sí sola tiene 107k. La lección: dentro de un grupo tibio, una skill de proceso una skill bien hecha supera la media porque aborda el comportamiento, no solo la herramienta.
🧠 Toma prestados estos patrones para tu skill
No necesitas publicar la próxima superpowers — basta con aplicar sus patrones a tu skill de proceso. La lista de lo que hace que una process skill sea apreciada:
✗ Process skill débil
- ✗Mezcla el proceso con el conocimiento del dominio
- ✗Trigger vinculado a una tecnología específica
- ✗Lista de MUSTs sin explicar el porqué
- ✗Intenta cubrir 5 procesos en una sola skill
✓ Skill de proceso muy apreciada
- ✓Un proceso, una responsabilidad (atómica)
- ✓Se activa por tipo de tarea, sin depender del stack
- ✓Explica el porqué; estricta solo donde hace falta
- ✓Se combina con otras process skills
💡 Puente al siguiente módulo
Ahora ya sabes qué tipo de skill vale la pena crear. En la 5.4 pasamos del concepto a lo concreto: la lista de verificación para decidir antes de crearla, cómo estructurar el repo y los comandos exactos para publicarla y hacer que aparezca en skills.sh.
✅ Resumen del módulo
Próximo:
Módulo 5.4 — 🛠️ Cómo crear: de la decisión al publish. La lista de verificación para decidir, la estructura del repo y los comandos exactos para publicar.