Cómo crear skills

Las skills se definen como archivos SKILL.md dentro de un directorio con un nombre específico. Esta página explica todo lo que necesitas saber para escribir skills eficaces.

Estructura de archivos

Coloca las skills en el directorio correspondiente según el ámbito:

# Específico del proyecto (confirmado en git)
.devin/skills/
└── my-skill/
    └── SKILL.md

# Global — disponible en todos los proyectos (no confirmado)
# Linux/macOS:
~/.config/devin/skills/
└── my-skill/
    └── SKILL.md

# Windows:
%APPDATA%\devin\skills\
└── my-skill\
    └── SKILL.md

El nombre del directorio es el identificador de la skill (se usa para la invocación de /my-skill). El archivo SKILL.md contiene frontmatter YAML opcional y el contenido del prompt de la skill.

En Windows, %APPDATA% normalmente se resuelve a C:\Users\<YourUser>\AppData\Roaming.

Referencia de frontmatter

---
name: my-skill
description: What this skill does (shown in completions)
argument-hint: "[file] [options]"
model: sonnet
allowed-tools:
  - read
  - grep
  - glob
  - exec
permissions:
  allow:
    - Read(src/**)
  deny:
    - exec
  ask:
    - Write(**)
triggers:
  - user
  - model
---

Your prompt content goes here...

Todos los campos del frontmatter

Campo	Tipo	Predeterminado	Descripción
`name`	string	nombre del directorio	Nombre visible de la skill
`description`	string	ninguno	Se muestra en las sugerencias de autocompletado del comando de barra diagonal
`argument-hint`	string	ninguno	Sugerencia que se muestra después del nombre del comando (p. ej., `[filename]`)
`model`	string	modelo actual	Anula el modelo usado al ejecutar esta skill
`subagent`	boolean	`false`	Ejecuta la skill como un subagente en lugar de inline
`agent`	string	ninguno	Ejecuta la skill como un subagente con un perfil específico de subagente personalizado
`allowed-tools`	list	ninguno	Herramientas que se aprueban automáticamente (sin permission prompt) mientras se ejecuta la skill. No restringe la disponibilidad de herramientas; consulta Herramientas aprobadas automáticamente. No se aplica cuando la skill se ejecuta como subagente
`permissions`	object	heredar	Anulaciones de permisos para esta skill. No se aplica cuando la skill se ejecuta como subagente
`triggers`	list	`[user, model]`	Cómo se puede invocar la skill

Anulación del modelo

Usa el campo model para ejecutar una skill con un modelo distinto del que está activo en la sesión actual. Esto es útil para usar un modelo más rápido en tareas simples o uno más potente en tareas complejas:

---
name: quick-fix
description: Fast lint fix using a lightweight model
model: swe
---

Fix the lint errors in the current file.

El nombre del modelo usa los mismos valores que la marca --model de la CLI (p. ej., opus, sonnet, swe, codex). Consulta Models para ver la lista completa.

Ejecutar skills como subagentes

Ejecutar skills como subagentes es experimental. Los campos de frontmatter subagent y agent pueden cambiar en futuras versiones.

De forma predeterminada, el prompt de una skill se inserta en la conversación actual; el agente lo procesa en línea. Como alternativa, puedes ejecutar una skill como subagente, lo que crea un proceso independiente con su propia ventana de contexto. Esto resulta útil para skills que realizan tareas específicas y autocontenidas, cuando no quieres que la salida llene la conversación principal. Hay dos formas de ejecutar una skill como subagente:

`subagent: true`

Establece subagent: true para ejecutar la skill como un subagente con el perfil subagent_general predeterminado:

---
name: deep-research
description: Thorough codebase research on a topic
subagent: true
model: sonnet
---

Research the topic the user asked about thoroughly.

Search broadly, follow references, and trace call chains.
Report all findings with specific file paths and line numbers.

Cuando se invoca, esta skill crea un subagente en primer plano que ejecuta el prompt de la skill como tarea. El agente principal espera a que el subagente finalice; luego lee y resume los resultados.

Cuando una skill se ejecuta como subagente, sus campos de frontmatter allowed-tools y permissions no se aplican. El subagente se ejecuta con el conjunto de herramientas de su perfil: subagent_general tiene acceso a todas las herramientas. Para limitar qué herramientas puede usar una skill ejecutada como subagente, define un perfil de subagente personalizado con allowed-tools y haz referencia a él con agent: en lugar de subagent: true.

`agent: <profile>`

Usa el campo agent para ejecutar la skill como un subagente con un perfil de subagente personalizado:

---
name: review-pr
description: Review the current PR using the reviewer subagent
agent: reviewer
---

Review the staged changes for correctness, security, and style issues.

El valor de agent debe coincidir con el nombre de un perfil de subagente registrado (ya sea uno integrado, como subagent_explore / subagent_general, o un perfil personalizado que hayas definido). El subagente hereda el prompt del sistema, las restricciones de herramientas y el modelo del perfil, mientras que el contenido de la skill pasa a ser la tarea. El campo allowed-tools de un perfil personalizado es una restricción real (las herramientas no listadas no están disponibles para el subagente), así que esta es la forma de ejecutar una skill con un conjunto limitado de herramientas.

Si se establecen tanto agent como subagent, agent tiene prioridad. El campo model de la skill anula el modelo del perfil del subagente cuando se especifican ambos.

Las skills que se ejecutan como subagentes no crean subagentes anidados: si la skill ya se está ejecutando dentro de un subagente, se ejecuta inline para evitar la recursión infinita.

Orquestación de subagentes con skills

Como las skills pueden ejecutarse como subagentes, puedes usarlas para orquestar flujos de trabajo de varios pasos. Define un conjunto de skills de subagentes, cada una encargada de una tarea concreta, y luego escribe una skill normal que las invoque. La skill externa se convierte en el orquestador: llama a cada subagente, recopila los resultados y decide qué hacer a continuación. Por ejemplo, aquí tienes dos skills de subagentes y un orquestador que las coordina:

---
name: research-changes
description: Research recent code changes and their impact
subagent: true
---

Analyze the recent changes in this repository:

1. Run `git log --oneline -20` to see recent commits
2. For each significant commit, examine what changed and why
3. Identify any patterns, risks, or areas that need attention

Report your findings with specific file paths and commit references.

---
name: validate-tests
description: Run tests and validate coverage for recent changes
subagent: true
---

Validate the test suite for the project:

1. Identify the test framework and run command
2. Run the full test suite
3. Check for any failing tests
4. Review test coverage for recently changed files

Report which tests pass, which fail, and any coverage gaps.

---
name: health-check
description: Full project health check — research changes then validate tests
---

Perform a full health check on this project:

1. First, use the /research-changes skill to understand recent changes
2. Then, use the /validate-tests skill to verify the test suite
3. Finally, synthesize the findings from both into a summary:
   - What changed recently and why
   - Whether tests are passing
   - Any risks or recommended actions

Al invocar /health-check, se ejecuta el orquestador en el agente principal. Este llama a /research-changes, que crea un subagente para explorar el repo. Cuando termina, llama a /validate-tests, que crea otro subagente para ejecutar las pruebas. Luego, el orquestador sintetiza ambos resultados en un resumen final. Una skill de subagente nunca usará un subagente al llamar a otras skills, incluso si esas skills tienen subagent: true; en esos casos, se ejecutan inline. Esto significa que no tienes que preocuparte por un anidamiento ilimitado. El patrón de orquestación siempre tiene un solo nivel de profundidad: el orquestador crea subagentes, y esos subagentes ejecutan todo lo demás inline.

Contenido del prompt

El contenido del archivo SKILL.md (después del frontmatter) es el prompt que se inserta cuando se invoca la skill.

Permisos

Las skills pueden definir su propio ámbito de permisos con la misma sintaxis que la configuración principal de permisos:

permissions:
  allow:
    - Read(src/**)
    - Exec(npm run test)
  deny:
    - Write(/etc/**)
    - exec
  ask:
    - Write(src/**)

Cómo funcionan los permisos de skill:

allow — Estos ámbitos se aprueban automáticamente durante la ejecución de la skill
deny — Estos ámbitos se bloquean durante la ejecución de la skill
ask — Estos ámbitos siempre requieren la aprobación del usuario

deny es la forma de bloquear por completo una herramienta en una skill inline. Las entradas con nombre de herramienta como exec o edit bloquean la herramienta completa, y los patrones mcp__server__tool bloquean herramientas MCP — consulta Permisos basados en herramientas.

Los permisos de la skill son aditivos respecto a los permisos base de la sesión (no los reemplazan). Una skill no puede otorgar permisos que estén denegados en un nivel superior (configuración del proyecto o de la organización).

Los permisos de la skill solo se aplican cuando la skill se ejecuta inline. No se aplican cuando la skill se ejecuta como subagente (subagent: true o agent:).

Herramientas aprobadas automáticamente

allowed-tools lista las herramientas que se aprueban automáticamente mientras se ejecuta la skill, de modo que el agente pueda usarlas sin solicitar permiso:

allowed-tools:
  - read
  - grep
  - glob

Cada entrada equivale a una entrada de permissions.allow para ese nombre de herramienta. Nombres de herramienta disponibles: read, edit, grep, glob, exec También puedes aprobar automáticamente herramientas MCP:

allowed-tools:
  - read
  - mcp__github__list_issues
  - mcp__github__create_issue

allowed-tools no es una restricción. Las herramientas que no aparezcan en la lista siguen estando disponibles para el skill y pasan por las verificaciones de permisos normales (se le pide confirmación al usuario, o se ejecutan sin pedirla si los permisos de la sesión ya las permiten). Omitir allowed-tools no cambia en nada qué herramientas puede usar el skill: solo significa que ninguna herramienta queda preaprobada.Para impedir realmente que un skill use una herramienta:

En los skills inline, agrega el nombre de la herramienta a permissions.deny (consulta Permisos).
En los skills de tipo subagent, define un perfil de subagente personalizado con allowed-tools y ejecuta el skill con agent: <profile>. En un perfil de subagent, allowed-tools sí restringe el conjunto de herramientas; en un skill, no.

Ejemplos

Skill para revisar código

---
name: review
description: Revisar los cambios preparados en busca de problemas
allowed-tools:
  - read
  - grep
  - glob
  - exec
permissions:
  allow:
    - Exec(git diff)
    - Exec(git log)
---

Ejecuta `git diff --staged` y revisa los cambios en busca de problemas de calidad.

Evalúa:
1. **Corrección** — ¿Algún error lógico o casos límite?
2. **Seguridad** — ¿Se introdujo alguna vulnerabilidad?
3. **Rendimiento** — ¿Alguna ineficiencia obvia?
4. **Estilo** — ¿Consistente con el código base?

Proporciona un resumen con referencias específicas a las líneas.

Generador de componentes

---
name: component
description: Generar un componente de React a partir de una descripción
argument-hint: "<ComponentName>"
allowed-tools:
  - read
  - edit
  - grep
  - glob
model: sonnet
permissions:
  allow:
    - Write(src/components/**)
---

Crear un nuevo componente de React usando el nombre que proporciona el usuario:

1. Revisar los componentes existentes en src/components/ para conocer las convenciones de estilo
2. Crear el archivo del componente en src/components/<ComponentName>/<ComponentName>.tsx
3. Crear una exportación barrel en src/components/<ComponentName>/index.ts
4. Agregar pruebas básicas en src/components/<ComponentName>/<ComponentName>.test.tsx
5. Seguir los patrones que encuentres en los componentes existentes

Lista de verificación de despliegue

---
name: deploy
description: Run through the deployment checklist
triggers:
  - user
allowed-tools:
  - read
  - exec
  - grep
permissions:
  allow:
    - Exec(npm run)
    - Exec(git)
---

Run through the deployment checklist:

1. Run the test suite: `npm run test`
2. Run the linter: `npm run lint`
3. Check for uncommitted changes: `git status`
4. Verify the build: `npm run build`
5. Show the current branch and last commit

Report the status of each step. If anything fails, stop and explain the issue.

Experto en búsquedas

---
name: find
description: Find relevant code across the project
argument-hint: "<what to find>"
allowed-tools:
  - read
  - grep
  - glob
triggers:
  - user
  - model
---

Busca exhaustivamente en el código base lo que el usuario preguntó.

Usa grep para buscar contenido y glob para descubrir archivos.
Proporciona rutas de archivos relevantes y fragmentos de código.
Explica cómo se conectan las piezas.

Consejos

Mantén los prompts enfocados

Una skill debe hacer una sola cosa bien. Crea múltiples skills en lugar de una mega-skill.

Incluye ejemplos

Muestra al agente en tu prompt cómo es una buena salida.

Deniega lo que una skill no debe hacer

Usa permissions.deny (o un perfil de subagente personalizado) para bloquear herramientas. allowed-tools solo omite los prompts.

Prueba con /skill-name

Invoca tu skill y ajusta el prompt hasta obtener la salida que quieres.

Primeros pasos

Integraciones del Editor

Extensibilidad

Enterprise

Referencia

Registro de cambios

Estructura de archivos

Referencia de frontmatter

Todos los campos del frontmatter

Anulación del modelo

Ejecutar skills como subagentes

`subagent: true`

`agent: <profile>`

Orquestación de subagentes con skills

Contenido del prompt

Permisos

Herramientas aprobadas automáticamente

Ejemplos

Skill para revisar código

Generador de componentes

Lista de verificación de despliegue

Experto en búsquedas

Consejos

Mantén los prompts enfocados

Incluye ejemplos

Deniega lo que una skill no debe hacer

Prueba con /skill-name

​Estructura de archivos

​Referencia de frontmatter

​Todos los campos del frontmatter

​Anulación del modelo

​Ejecutar skills como subagentes

​subagent: true

​agent: <profile>

​Orquestación de subagentes con skills

​Contenido del prompt

​Permisos

​Herramientas aprobadas automáticamente

​Ejemplos

​Skill para revisar código

​Generador de componentes

​Lista de verificación de despliegue

​Experto en búsquedas

​Consejos

Mantén los prompts enfocados

Incluye ejemplos

Deniega lo que una skill no debe hacer

Prueba con /skill-name

Estructura de archivos

Referencia de frontmatter

Todos los campos del frontmatter

Anulación del modelo

Ejecutar skills como subagentes

`subagent: true`

`agent: <profile>`

Orquestación de subagentes con skills

Contenido del prompt

Permisos

Herramientas aprobadas automáticamente

Ejemplos

Skill para revisar código

Generador de componentes

Lista de verificación de despliegue

Experto en búsquedas

Consejos