Créer des skills

Les skills prennent la forme de fichiers SKILL.md placés dans un répertoire nommé. Cette page présente tout ce que vous devez savoir pour rédiger des skills efficaces.

Structure des fichiers

Placez les skills dans le répertoire approprié en fonction du périmètre :

# Spécifique au projet (commité dans git)
.devin/skills/
└── my-skill/
    └── SKILL.md

# Global — disponible dans tous les projets (non commité)
# Linux/macOS :
~/.config/devin/skills/
└── my-skill/
    └── SKILL.md

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

Le nom du répertoire sert d’identifiant à la skill (utilisé pour l’appel /my-skill). Le fichier SKILL.md contient un frontmatter YAML facultatif ainsi que le contenu du prompt de la skill.

Sous Windows, %APPDATA% correspond généralement à C:\Users\<YourUser>\AppData\Roaming.

Référence du 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...

Tous les champs du frontmatter

Champ	Type	Par défaut	Description
`name`	string	nom du répertoire	Nom d’affichage de la skill
`description`	string	aucun	Affiché dans les suggestions de commandes slash
`argument-hint`	string	aucun	Indice affiché après le nom de la commande (p. ex., `[filename]`)
`model`	string	modèle actuel	Remplace le modèle utilisé pour exécuter cette skill
`subagent`	boolean	`false`	Exécute la skill comme un sous-agent plutôt qu’en ligne
`agent`	string	aucun	Exécute la skill comme un sous-agent à l’aide d’un profil de sous-agent personnalisé spécifique
`allowed-tools`	list	aucun	Outils approuvés automatiquement (aucun prompt d’autorisation) pendant l’exécution de la skill. Ne restreint pas la disponibilité des outils — voir Outils approuvés automatiquement. Non appliqué lorsque la skill s’exécute comme un sous-agent
`permissions`	object	hériter	Dérogations d’autorisations pour cette skill. Non appliqué lorsque la skill s’exécute comme un sous-agent
`triggers`	list	`[user, model]`	Comment la skill peut être invoquée

Remplacement de modèle

Utilisez le champ model pour exécuter un skill avec un modèle différent de celui utilisé dans la session en cours. C’est utile pour utiliser un modèle plus rapide pour les tâches simples ou un modèle plus performant pour les tâches complexes :

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

Fix the lint errors in the current file.

Le nom du modèle utilise les mêmes valeurs que l’option CLI --model (par ex. opus, sonnet, swe, codex). Voir Modèles pour la liste complète.

Exécuter des skills comme sous-agents

L’exécution de skills comme sous-agents est expérimentale. Les champs de frontmatter subagent et agent peuvent changer dans les prochaines versions.

Par défaut, le prompt d’une skill est injecté dans la conversation en cours — l’agent le traite inline. Vous pouvez aussi exécuter une skill comme sous-agent, ce qui lance un processus indépendant avec sa propre fenêtre de contexte. C’est utile pour les skills qui effectuent des tâches ciblées et autonomes, lorsque vous ne voulez pas que le résultat encombre la conversation principale. Il existe deux façons d’exécuter une skill comme sous-agent :

`subagent: true`

Définissez subagent: true pour exécuter la skill comme sous-agent avec le profil subagent_general par défaut :

---
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.

Lorsqu’il est invoqué, ce skill lance un sous-agent au premier plan qui exécute le prompt du skill comme tâche. L’agent parent attend que le sous-agent ait terminé, puis lit et résume les résultats.

Lorsqu’un skill s’exécute comme sous-agent, ses frontmatter allowed-tools et permissions ne sont pas appliqués. Le sous-agent s’exécute avec l’ensemble d’outils de son profil — subagent_general a accès à tous les outils. Pour limiter les outils qu’un skill exécuté comme sous-agent peut utiliser, définissez un profil de sous-agent personnalisé avec allowed-tools et référencez-le avec agent: plutôt qu’avec subagent: true.

`agent: <profile>`

Utilisez le champ agent pour exécuter la skill comme sous-agent en utilisant un profil personnalisé de sous-agent :

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

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

La valeur agent doit correspondre au nom d’un profil de sous-agent enregistré (intégré, comme subagent_explore / subagent_general, ou d’un profil personnalisé que vous avez défini). Le sous-agent hérite du prompt système, des restrictions sur les outils et du modèle du profil, tandis que le contenu du skill devient la tâche. Le champ allowed-tools d’un profil personnalisé constitue une véritable restriction (les outils non listés sont indisponibles pour le sous-agent) : c’est donc le moyen d’exécuter une skill avec un ensemble d’outils limité.

Si agent et subagent sont tous deux définis, agent prévaut. Le champ model du skill remplace le modèle du profil de sous-agent lorsque les deux sont spécifiés.

Les skills exécutés en tant que sous-agents ne lancent pas de sous-agents imbriqués : si le skill s’exécute déjà dans un sous-agent, il s’exécute en ligne à la place afin d’éviter une récursion infinie.

Orchestrer des sous-agents à l’aide de skills

Comme les skills peuvent s’exécuter comme des sous-agents, vous pouvez les utiliser pour orchestrer un travail en plusieurs étapes. Définissez un ensemble de skills de sous-agent, chacun chargé d’une tâche précise, puis rédigez un skill classique qui les invoque. Le skill externe devient l’orchestrateur : il appelle chaque sous-agent, recueille les résultats et décide de la suite. Par exemple, voici deux skills de sous-agent et un orchestrateur qui les coordonne :

---
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

L’appel à /health-check exécute l’orchestrateur dans l’agent principal. Il appelle /research-changes, qui lance un sous-agent pour explorer le dépôt. Une fois cette étape terminée, il appelle /validate-tests, qui lance un autre sous-agent pour exécuter les tests. L’orchestrateur fusionne ensuite les deux résultats dans un résumé final. Une skill de sous-agent n’utilise jamais de sous-agent lorsqu’elle appelle d’autres skills, même si ces skills ont subagent: true — elles s’exécutent en ligne à la place. Cela signifie que vous n’avez pas à vous soucier d’une imbrication infinie. Le modèle d’orchestration ne comporte toujours qu’un seul niveau : l’orchestrateur lance des sous-agents, et ces sous-agents exécutent tout le reste en ligne.

Contenu du prompt

Le contenu du fichier SKILL.md (après le frontmatter) constitue le prompt injecté lorsque le skill est invoqué.

Autorisations

Les skills peuvent définir leur propre périmètre d’autorisations en utilisant la même syntaxe que la configuration principale des autorisations :

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

Fonctionnement des autorisations des skills :

allow — Ces périmètres sont automatiquement autorisés pendant l’exécution du skill
deny — Ces périmètres sont bloqués pendant l’exécution du skill
ask — Ces périmètres demandent toujours une confirmation à l’utilisateur

deny est le moyen de bloquer complètement un outil pour un skill en ligne. Les entrées correspondant à un nom d’outil, comme exec ou edit, bloquent l’outil dans son intégralité, et les motifs mcp__server__tool bloquent les outils MCP — voir Autorisations basées sur les outils.

Les autorisations des skills s’ajoutent aux autorisations de base de la session (sans les remplacer). Un skill ne peut pas accorder d’autorisations refusées à un niveau supérieur (configuration du projet ou de l’organisation).

Les autorisations des skills s’appliquent uniquement lorsque le skill s’exécute en ligne. Elles ne sont pas appliquées lorsque le skill s’exécute en tant que sous-agent (subagent: true ou agent:).

Outils approuvés automatiquement

allowed-tools répertorie les outils automatiquement approuvés pendant l’exécution du skill, afin que l’agent puisse les utiliser sans prompt d’autorisation :

allowed-tools:
  - read
  - grep
  - glob

Chaque entrée équivaut à une entrée permissions.allow pour le nom d’outil correspondant. Noms d’outils disponibles : read, edit, grep, glob, exec Vous pouvez également approuver automatiquement des outils MCP :

allowed-tools:
  - read
  - mcp__github__list_issues
  - mcp__github__create_issue

allowed-tools n’est pas une restriction. Les outils qui n’y figurent pas restent accessibles au skill et passent par les vérifications d’autorisation habituelles (demande à l’utilisateur, ou exécution sans demande si les autorisations de la session les permettent déjà). Omettre allowed-tools ne change rien aux outils que le skill peut utiliser : cela signifie simplement qu’aucun outil n’est pré-approuvé.Pour réellement empêcher un skill d’utiliser un outil :

Pour les skills en ligne, ajoutez le nom de l’outil à permissions.deny (voir Autorisations).
Pour les skills exécutés en sous-agent, définissez un profil de sous-agent personnalisé avec allowed-tools, puis exécutez le skill avec agent: <profile>. Sur un profil de sous-agent, allowed-tools restreint l’ensemble des outils ; sur un skill, non.

Exemples

skill de revue de code

---
name: review
description: Examiner les modifications en attente pour détecter des problèmes
allowed-tools:
  - read
  - grep
  - glob
  - exec
permissions:
  allow:
    - Exec(git diff)
    - Exec(git log)
---

Exécutez `git diff --staged` et examinez les modifications pour détecter des problèmes de qualité.

Évaluez :
1. **Exactitude** — Des erreurs de logique ou des cas limites ?
2. **Sécurité** — Des vulnérabilités introduites ?
3. **Performance** — Des inefficacités évidentes ?
4. **Style** — Cohérent avec la base de code ?

Fournissez un résumé avec des références de lignes spécifiques.

Générateur de composants

---
name: component
description: Generate a React component from a description
argument-hint: "<ComponentName>"
allowed-tools:
  - read
  - edit
  - grep
  - glob
model: sonnet
permissions:
  allow:
    - Write(src/components/**)
---

Créez un nouveau composant React en utilisant le nom fourni par l'utilisateur :

1. Vérifiez les composants existants dans src/components/ pour les conventions de style
2. Créez le fichier du composant à src/components/<ComponentName>/<ComponentName>.tsx
3. Créez un export barrel à src/components/<ComponentName>/index.ts
4. Ajoutez des tests de base à src/components/<ComponentName>/<ComponentName>.test.tsx
5. Suivez les modèles que vous trouvez dans les composants existants

Checklist de déploiement

---
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.

Expert de la recherche

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

Search the codebase thoroughly for what the user asked about.

Use grep for content search and glob for file discovery.
Provide relevant file paths and code snippets.
Explain how the pieces connect.

Conseils

Gardez les prompts ciblés

Un skill doit faire une seule chose, et bien la faire. Créez plusieurs skills plutôt qu’un méga-skill.

Incluez des exemples

Montrez à l’agent à quoi ressemble un bon résultat dans votre prompt.

Interdisez ce qu'un skill ne doit pas faire

Utilisez permissions.deny (ou un profil de sous-agent personnalisé) pour bloquer des outils. allowed-tools se contente de passer outre les prompts.

Testez avec /skill-name

Exécutez votre skill et ajustez le prompt jusqu’à obtenir le résultat souhaité.

Prise en main

Intégrations d’éditeur

Extensibilité

Entreprise

Référence

Changelog

Structure des fichiers

Référence du frontmatter

Tous les champs du frontmatter

Remplacement de modèle

Exécuter des skills comme sous-agents

`subagent: true`

`agent: <profile>`

Orchestrer des sous-agents à l’aide de skills

Contenu du prompt

Autorisations

Outils approuvés automatiquement

Exemples

skill de revue de code

Générateur de composants

Checklist de déploiement

Expert de la recherche

Conseils

Gardez les prompts ciblés

Incluez des exemples

Interdisez ce qu'un skill ne doit pas faire

Testez avec /skill-name

​Structure des fichiers

​Référence du frontmatter

​Tous les champs du frontmatter

​Remplacement de modèle

​Exécuter des skills comme sous-agents

​subagent: true

​agent: <profile>

​Orchestrer des sous-agents à l’aide de skills

​Contenu du prompt

​Autorisations

​Outils approuvés automatiquement

​Exemples

​skill de revue de code

​Générateur de composants

​Checklist de déploiement

​Expert de la recherche

​Conseils

Gardez les prompts ciblés

Incluez des exemples

Interdisez ce qu'un skill ne doit pas faire

Testez avec /skill-name

Structure des fichiers

Référence du frontmatter

Tous les champs du frontmatter

Remplacement de modèle

Exécuter des skills comme sous-agents

`subagent: true`

`agent: <profile>`

Orchestrer des sous-agents à l’aide de skills

Contenu du prompt

Autorisations

Outils approuvés automatiquement

Exemples

skill de revue de code

Générateur de composants

Checklist de déploiement

Expert de la recherche

Conseils