Llevo ya unos cuantos meses usando Pi Agent a diario con la suscripción a la API de Deepseek y la de Opencode Go (varios modelos). He probado unos cuantos skills, los he comparado con sesiones sin skills, y la respuesta corta es esta: sí marcan diferencia en el resultado, no dependen del modelo que uses y no todos son necesarios para todo el mundo.
Si piensas usar Pi Agent (o ya lo usas) y quieres sacarle más partido sin tener que escribirse prompts enormes cada vez, tal vez te interese tener en cuenta estos Skills.
Qué son los skills de pi agent
Un skill es un archivo markdown con instrucciones especializadas que el agente carga bajo demanda (a diferencia de AGENTS.md, el archivo de reglas generales que el modelo tiene que seguir para tu proyecto). Pi Agent sigue el estándar Agent Skills, el mismo que usan Claude Code, Cursor, Windsurf y OpenAI Codex.
Cada skill tiene un nombre, una descripción (que es lo que ve el agente para decidir si cargarlo) y el contenido con las instrucciones detalladas. Cuando el agente detecta que la tarea encaja con la descripción, lee el skill completo y sigue sus instrucciones en lugar de improvisar. En la siguiente imagen puedes ver lo que tengo yo cargados:
¿Qué vas a conseguir con estos skills? No sobrecargar tu AGENTS.md. Se cargarán solo cuando los necesites. Sin un skill, el agente decide cómo abordar un problema según sus datos de entrenamiento. Con un skill, tiene un plan escrito específicamente para ese caso.
Cuando una tarea coincide, el agente carga el SKILL.md completo (si ves que no locarga puedes llamarlo con /skill:nombre para forzarlo). Más datos en https://pi.dev/docs/latest/skills.
Los 17 skills que tengo instalados (y para qué sirve cada uno)
Los skills se instalan en carpetas (en macOS los tiene que meter en /Users/tu_nombre_usuario/.pi/agent/skills) y el PI Agent los descubre automáticamente. Estos son los míos, agrupados por tipo:
Desarrollo (9 skills)
| Skill | Qué hace |
|---|---|
| code-review-and-quality | Revisa código en 5 ejes: corrección, legibilidad, arquitectura, seguridad, rendimiento |
| code-simplification | Simplifica código sin cambiar comportamiento: cuando funciona, pero es más enrevesado de lo necesario |
| debugging-and-error-recovery | Debug sistemático: deja de adivinar, sigue un proceso estructurado de causa raíz |
| frontend-ui-engineering | Construye interfaces que parecen hechas por un diseñador, no por una IA. Paleta, accesibilidad, interacciones |
| incremental-implementation | Divide cambios grandes en pasos pequeños y verificables. Para cuando un feature toca más de un archivo |
| performance-optimization | Optimiza rendimiento: Core Web Vitals, cuellos de botella, carga |
| planning-and-task-breakdown | Descompone trabajo en tareas con criterios de aceptación. Ideal para specs grandes |
| security-and-hardening | Protege contra vulnerabilidades: input de usuario, autenticación, almacenamiento, integraciones externas |
| checkpoint | Escribe memoria de sesión al terminar: STATE.md (foto actual), CHANGELOG.md (índice de cambios), RUN_LOG.md (historial) |
Análisis de código (4 skills, del paquete pi-lens)
| Skill | Qué hace |
|---|---|
| ast-grep | Busca patrones de código por AST en lugar de texto. Entiende la estructura, no solo cadenas |
| lsp-navigation | Navegación con IDE features: definiciones, referencias, hover, diagnósticos en tiempo real |
| write-ast-grep-rule | Escribe reglas YAML para ast-grep. Útil para crear linters propios |
| write-tree-sitter-rule | Escribe queries tree-sitter para análisis sintáctico avanzado |
Investigación (2 skills)
| Skill | Qué hace |
|---|---|
| search-web | Búsqueda unificada web: papers académicos, comunidad, documentación, GitHub, noticias, reviews, seguridad, troubleshooting y verificación. |
| librarian | Investiga librerías open-source con respuestas basadas en código y enlaces directos a GitHub |
Sandbox y productividad (2 skills)
| Skill | Qué hace |
|---|---|
| nono-sandbox | Diagnostica y resuelve denegaciones de permisos dentro del sandbox de nono.sh |
| save-to-obsidian | Guarda resultados de búsqueda como notas Zettelkasten en Obsidian |
Total: 17 skills. Algunos vienen con los paquetes que instalas (pi-lens, pi-web-access, nono), otros los he añadido yo de algunos repositorios de GitHub que ahora te comento, y otros como el de search-web los he creado yo con ayuda de la IA.
¿Son necesarios? Depende de lo que hagas
Si usas Pi Agent solo para escribir archivos de texto o respuestas rápidas, probablemente no necesites ninguno. El agente funciona sin ellos.
Si usas Pi Agent para desarrollar código, la cosa cambia. He probado las mismas tareas con y sin skills usando Deepseek v4 pro, y los resultados no tienen nada que ver:
- Sin skills: el modelo responde con lo que sabe de entrenamiento. Puede acertar, pero tiende a lo genérico.
- Con skills de code review y debugging: el agente sigue un proceso sistemático. Revisa cada eje por separado, no se salta pasos y encuentra problemas que el modelo solo no detecta.
Lo he comprobado varias veces. Pones al agente a revisar un fragmento de código. Sin skills, te dice que está bien o señala una o dos cosas obvias. Con el skill de code-review-and-quality cargado, te devuelve 5-10 issues organizados por severidad, incluyendo cosas que no habías considerado (seguridad, rendimiento, arquitectura).
Lo mismo con debugging. Sin el skill, el agente empieza a probar cosas al azar. Con el skill, primero recopila evidencia, aísla variables, formula hipótesis y las prueba una a una. En mi experiencia, resuelves bugs en la mitad de tiempo y te da una respuesta estructurada que puedes chequear.
¿Dependen del modelo que uses?
No. Y esta es probablemente la pregunta que más me hacía al principio.
Los skills actúan a nivel del sistema de herramientas del agente, no a nivel del modelo de lenguaje. Da igual que uses Deepseek, Claude, GPT-4 o Gemini: el agente sigue siendo el mismo (pi agent), y los skills se cargan de la misma forma.
Lo que sí cambia es cómo de bien el modelo sigue las instrucciones del skill. Un skill de debugging bien escrito le funciona a Deepseek v4 pro y también a Claude Sonnet. El skill pone las reglas, el modelo las ejecuta. Si el skill dice «primero recopila evidencia, luego formula hipótesis», el modelo lo hace independientemente de quién sea.
Dicho esto, modelos más capaces (Claude Sonnet (Opus), GPT-5, Deepseek v4 pro) aprovechan mejor los skills detallados porque siguen instrucciones largas con más precisión. Modelos pequeños pueden ignorar partes del skill o simplificarlo demasiado. Pero el skill en sí no está encorsetado a ningún modelo.
El ecosistema de skills va más allá de pi
No solo Pi Agent usa este estándar. Hay varios repositorios públicos que me han sido de mucha ayuda:
- anthropics/skills: skills oficiales de Anthropic para Claude. Incluyen desde creación de documentos (docx, pdf, pptx, xlsx) hasta diseño con Canvas, API de Claude, coautoría de documentos y más. Son el repositorio de referencia del estándar.
- vercel-labs/agent-skills: skills enfocados en rendimiento React/Next.js, despliegue a Vercel, optimización de costes y pautas de diseño web. Muy útiles si trabajas con el ecosistema Vercel.
- coreyhaines31/marketingskills: más de 40 skills de marketing. SEO, CRO, copywriting, analytics, email marketing, lanzamientos, investigación de clientes. Pensado para marketers técnicos y fundadores que usan agentes de IA.
- BehiSecc/VibeSec-Skill: skill de seguridad informática que cubre 60-70 % de las vulnerabilidades comunes (IDOR, XSS, SSRF, SQLi, autenticación, API security) desde la perspectiva de un bug bounty hunter.
- skills.sh: una web espectacular donde tienes skills por categorías y con índice de popularidad. Para que puedas seleccionar los que necesitas.
- github.com/badlogic/pi-skills: skills específicos para Pi.
Todos siguen el mismo estándar Agent Skills. Puedes instalarlos en Pi Agent, Claude Code, Cursor, Windsurf, OpenAI Codex, o cualquier herramienta que implemente el estándar.
¿Quieres instalarlos en PI? Solo tienes que darle a tu agente estos enlaces y decirle cuáles quieres implementar en tu instalación de Pi.
¿Cuándo merece la pena crear tu propio skill?
Cuando repites el mismo tipo de tarea más de dos veces. Lo bueno que tiene PI, es que puedes pedírselo directamente a tu agente y, si le has dado permiso para modificar la carpeta de .pi, te lo meterá directamente en ella.
Si cada semana revisas código de un tipo concreto, o despliegas en un entorno específico, o sigues un proceso de testing determinado, vale la pena escribir un skill de 20 líneas. No necesitas más.
Los skills más efectivos que he creado no son largos. Son cortos, concretos, con pasos verificables. Un skill de debugging de 15 líneas bien escritas vale más que un prompt de 200 líneas lleno de generalidades.
¿Uno de los que más uso? Uno que he creado para que el modelo tenga memoria entre sesiones (Checkpoint):
---
name: checkpoint
description: Escribe memoria de sesión al terminar una tarea, para que el agente retome el proyecto en la próxima sesión con contexto. Usa STATE.md (foto actual), CHANGELOG.md (índice de cambios) y RUN_LOG.md (historial). Usar al final de cada sesión de trabajo.
---
# Checkpoint – Estado de sesión
## Cuándo ejecutar
- Al terminar una tarea o sesión de trabajo, sea cual sea el proyecto.
- Cuando el usuario diga «checkpoint», «actualiza memoria», «fin de sesión» o similar.
## Contexto
Tres archivos por proyecto, en su raíz: `STATE.md` (foto actual), `CHANGELOG.md` (índice de cambios acumulado) y `RUN_LOG.md` (historial de sesiones).
---
## Pasos (ejecutar en orden)
### 1. Actualiza STATE.md
Si no existe, créalo. Reemplaza su contenido completo cada vez:
```
# Estado – [nombre del proyecto]
Actualizado: YYYY-MM-DD
## Objetivo actual
[Una frase que capture lo que estabas haciendo. Sin contexto de relleno: solo lo que el agente necesita saber para seguir.]
## Próximas acciones
- [ ] ...
- [ ] ...
- [ ] ...
## Zonas frágiles
[Cosas que otro agente (o tú en el futuro) necesitaría saber antes de tocar nada aquí.]
```
Reglas:
- **Máximo 3 próximas acciones.** Si hay más, prioriza las críticas; el resto viven en RUN_LOG.md como pendientes.
- **Máximo 5 zonas frágiles.** Si hay más, fusiona las menos críticas. Si no hay ninguna identificada, **omite la sección** — no la dejes vacía.
- **Sin sección de «objetivos anteriores».** Eso pertenece al log. STATE.md es solo la foto presente.
- **No rellenes «Zonas frágiles» con genéricos** («ninguna», «todo estable»). Solo se escribe si hay algo concreto que señalar. Para decidirlo, pregúntate activamente:
- ¿Dejaste algo a medio hacer que se rompería si alguien lo toca sin saber?
- ¿Hay un cambio reciente cuya decisión no está documentada en ningún lado?
- ¿Hay algún archivo que otro agente no debería modificar sin leer primero otro?
### 2. Actualiza CHANGELOG.md
Si no existe, créalo con cabecera: `# Changelog – [nombre del proyecto]`
Añade la nueva entrada **al principio** del archivo:
```
## YYYY-MM-DD
- Añadido: ...
- Cambiado: ...
- Corregido: ...
```
Reglas:
- Solo incluye las categorías que apliquen — omite las vacías.
- Bullets concisos: qué cambió y en qué archivo, sin narrativa.
- No edites entradas anteriores.
### 3. Añade entrada a RUN_LOG.md
Si no existe, créalo con cabecera: `# Run Log – [nombre del proyecto]`
Añade la nueva entrada **al principio** del archivo (orden cronológico inverso):
```
## YYYY-MM-DD
**Objetivo:** ...
**Qué cambió:** ...
**Pendiente:** ...
```
Campos:
- **Objetivo:** la misma frase corta del STATE.md.
- **Qué cambió:** archivos tocados y decisión breve («AGENTS.md: añadida regla de acotaciones», «refactor: extraído validador a helpers/»). No narrativa.
- **Pendiente:** lo que no dio tiempo y no está ya en STATE.md como próxima acción.
Reglas:
- No edites entradas anteriores.
- No dupliques información de STATE.md — RUN_LOG.md es histórico, no foto actual.
### 4. Sugiere commit git
Si el directorio es un repo git y hay cambios sin commitar, propón al usuario:
```
git add -A && git commit -m "checkpoint: [resumen de una línea]"
```
No lo ejecutes automáticamente.
---
## Restricciones
- **STATE.md se sobreescribe cada vez.** No es histórico, no acumula.
- **CHANGELOG.md y RUN_LOG.md son append-only al principio.** Nunca edites entradas previas.Datos para que te quedes tranquilo
- ¿Los skills ralentizan al agente? No. Se cargan bajo demanda, solo cuando la tarea coincide con su descripción. Si no los necesitas, no se cargan.
- ¿Pesan mucho? Ocupan kilobytes. Son archivos de texto.
- ¿Funcionan con cualquier API? Sí, si usas Pi Agent. Los skills son parte de Pi Agent, no del modelo. Da igual que tu API sea Deepseek, OpenAI, Anthropic o Gemini.
- ¿Puedo compartir mis skills entre Claude Code y pi agent? Sí. El estándar Agent Skills es el mismo. Puedes tener la carpeta ~/.claude/skills compartida o copiar los skills entre herramientas.
- ¿Hay algún skill que recomiendes para empezar? Code review y debugging. Son los que más diferencia notas desde el primer día, especialmente si trabajas con código que no has escrito tú.
- ¿Dónde aprendo a escribir uno? El estándar está en agentskills.io. El repositorio de Anthropic tiene una plantilla en template/. Básicamente: un archivo SKILL.md con frontmatter (name, description) y las instrucciones en markdown. Puedes usar Obsidian para tener tu propia BBDD de skills.
