> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Créer des skills

> Référence complète du format SKILL.md du Devin CLI : options de frontmatter, approbation automatique via allowed-tools, autorisations et skills de sous-agents.

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.

***

<div id="file-structure">
  ## Structure des fichiers
</div>

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.

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

***

<div id="frontmatter-reference">
  ## Référence du frontmatter
</div>

```yaml theme={null}
---
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...
```

<div id="all-frontmatter-fields">
  ### Tous les champs du frontmatter
</div>

| 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](/fr/cli/subagents) 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é](/fr/cli/subagents#custom-subagents) 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](#auto-approved-tools). 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 |

***

<div id="model-override">
  ## Remplacement de modèle
</div>

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 :

```yaml theme={null}
---
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](/fr/cli/models) pour la liste complète.

***

<div id="running-skills-as-subagents">
  ## Exécuter des skills comme sous-agents
</div>

<Warning>
  L'exécution de skills comme sous-agents est **expérimentale**. Les champs de frontmatter `subagent` et `agent` peuvent changer dans les prochaines versions.
</Warning>

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 :

<div id="subagent-true">
  ### `subagent: true`
</div>

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

```yaml theme={null}
---
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.

<Warning>
  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é](/fr/cli/subagents#custom-subagents) avec `allowed-tools` et référencez-le avec `agent:` plutôt qu'avec `subagent: true`.
</Warning>

<div id="agent-profile">
  ### `agent: <profile>`
</div>

Utilisez le champ `agent` pour exécuter la skill comme sous-agent en utilisant un [profil personnalisé de sous-agent](/fr/cli/subagents#custom-subagents) :

```yaml theme={null}
---
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é.

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

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

<div id="orchestrating-subagents-using-skills">
  ### Orchestrer des sous-agents à l’aide de skills
</div>

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 :

```markdown theme={null}
---
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.
```

```markdown theme={null}
---
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.
```

```markdown theme={null}
---
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.

***

<div id="prompt-content">
  ## Contenu du prompt
</div>

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

***

<div id="permissions">
  ## Autorisations
</div>

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

```yaml theme={null}
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](/fr/cli/reference/permissions#tool-based-permissions).

<Note>
  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).
</Note>

<Note>
  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:`).
</Note>

***

<div id="auto-approved-tools">
  ## Outils approuvés automatiquement
</div>

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

```yaml theme={null}
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 :

```yaml theme={null}
allowed-tools:
  - read
  - mcp__github__list_issues
  - mcp__github__create_issue
```

<Warning>
  `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](#permissions)).
  * Pour les skills exécutés en sous-agent, définissez un [profil de sous-agent personnalisé](/fr/cli/subagents#custom-subagents) 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.
</Warning>

***

<div id="examples">
  ## Exemples
</div>

<div id="code-review-skill">
  ### skill de revue de code
</div>

```markdown theme={null}
---
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.
```

<div id="component-generator">
  ### Générateur de composants
</div>

```markdown theme={null}
---
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
```

<div id="deployment-checklist">
  ### Checklist de déploiement
</div>

```markdown theme={null}
---
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.
```

<div id="search-expert">
  ### Expert de la recherche
</div>

```markdown theme={null}
---
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.
```

***

<div id="tips">
  ## Conseils
</div>

<CardGroup cols={2}>
  <Card title="Gardez les prompts ciblés" icon="bullseye">
    Un skill doit faire une seule chose, et bien la faire. Créez plusieurs skills plutôt qu'un méga-skill.
  </Card>

  <Card title="Incluez des exemples" icon="lightbulb">
    Montrez à l'agent à quoi ressemble un bon résultat dans votre prompt.
  </Card>

  <Card title="Interdisez ce qu'un skill ne doit pas faire" icon="shield">
    Utilisez `permissions.deny` (ou un profil de sous-agent personnalisé) pour bloquer des outils. `allowed-tools` se contente de passer outre les prompts.
  </Card>

  <Card title="Testez avec /skill-name" icon="play">
    Exécutez votre skill et ajustez le prompt jusqu'à obtenir le résultat souhaité.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.