> ## 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 et des options de frontmatter

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
subagent: true
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 [subagent](/fr/cli/subagents) plutôt qu’en inline                                                       |
| `agent`         | string  | aucun             | Exécute la skill comme un subagent à l’aide d’un profil de [subagent personnalisé](/fr/cli/subagents#custom-subagents) spécifique |
| `allowed-tools` | list    | tous les outils   | Restreint les outils que la skill peut utiliser                                                                                   |
| `permissions`   | object  | hériter           | Dérogations d’autorisations pour cette skill                                                                                      |
| `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. Une fois le skill terminé, la session revient au modèle précédemment actif.

***

<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
allowed-tools:
  - read
  - grep
  - glob
---

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.

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

<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 inline à 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
allowed-tools:
  - read
  - grep
  - glob
  - exec
---

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
allowed-tools:
  - read
  - grep
  - glob
  - exec
---

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

***

<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

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

***

<div id="allowed-tools">
  ## Outils autorisés
</div>

Limitez les outils que la skill peut utiliser :

```yaml theme={null}
allowed-tools:
  - read
  - grep
  - glob
```

Noms des outils disponibles : `read`, `edit`, `grep`, `glob`, `exec`

Vous pouvez également autoriser des outils MCP :

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

<Warning>
  Si `allowed-tools` n’est pas spécifié, le skill a accès à tous les outils. Pour les skills pour lesquels la sécurité est critique, limitez toujours l’accès au strict minimum nécessaire.
</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="Utilisez allowed-tools" icon="shield">
    Limiter les outils rend les skills plus sûrs et plus prévisibles.
  </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>