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

# Skills erstellen

> Vollständige Referenz für das SKILL.md-Format und Frontmatter-Optionen

Skills werden als `SKILL.md`-Dateien in einem entsprechend benannten Verzeichnis definiert. Auf dieser Seite finden Sie alles, was Sie wissen müssen, um wirkungsvolle Skills zu schreiben.

***

<div id="file-structure">
  ## Dateistruktur
</div>

Lege Skills je nach Geltungsbereich im entsprechenden Verzeichnis ab:

```
# Projektspezifisch (per Commit in Git eingecheckt)
.devin/skills/
└── my-skill/
    └── SKILL.md

# Global — in allen Projekten verfügbar (kein Commit)
# Linux/macOS:
~/.config/devin/skills/
└── my-skill/
    └── SKILL.md

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

Der Verzeichnisname ist die Kennung des Skills (wird für den Aufruf von `/my-skill` verwendet). Die Datei `SKILL.md` enthält optionales YAML-Frontmatter und den Prompt-Inhalt des Skills.

<Note>
  Unter Windows bezieht sich `%APPDATA%` typischerweise auf `C:\Users\<YourUser>\AppData\Roaming`.
</Note>

***

<div id="frontmatter-reference">
  ## Frontmatter-Referenz
</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">
  ### Alle Frontmatter-Felder
</div>

| Feld            | Typ     | Standard         | Beschreibung                                                                                                                           |
| --------------- | ------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| `name`          | string  | Verzeichnisname  | Anzeigename des Skills                                                                                                                 |
| `description`   | string  | none             | Wird in den Vervollständigungen von Slash-Commands angezeigt                                                                           |
| `argument-hint` | string  | none             | Hinweis, der nach dem Befehlsnamen angezeigt wird (z. B. `[filename]`)                                                                 |
| `model`         | string  | aktuelles Modell | Überschreibt das Modell, das beim Ausführen dieses Skills verwendet wird                                                               |
| `subagent`      | boolean | `false`          | Führt den Skill als [Subagent](/de/cli/subagents) statt inline aus                                                                     |
| `agent`         | string  | none             | Führt den Skill als Subagent mit einem bestimmten Profil eines [benutzerdefinierten Subagents](/de/cli/subagents#custom-subagents) aus |
| `allowed-tools` | list    | alle Tools       | Beschränkt, welche Tools der Skill verwenden kann                                                                                      |
| `permissions`   | object  | inherit          | Berechtigungsüberschreibungen für diesen Skill                                                                                         |
| `triggers`      | list    | `[user, model]`  | Wie der Skill aufgerufen werden kann                                                                                                   |

***

<div id="model-override">
  ## Modell-Override
</div>

Verwenden Sie das Feld `model`, um ein Skill mit einem anderen Modell auszuführen als dem aktiven Modell der aktuellen Sitzung. Das ist nützlich, wenn Sie für einfache Aufgaben ein schnelleres Modell oder für komplexe Aufgaben ein leistungsfähigeres Modell verwenden möchten:

```yaml theme={null}
---
name: quick-fix
description: Fast lint fix using a lightweight model
model: swe
---

Fix the lint errors in the current file.
```

Der Modellname verwendet dieselben Werte wie das CLI-Flag `--model` (z. B. `opus`, `sonnet`, `swe`, `codex`). Die vollständige Liste finden Sie unter [Models](/de/cli/models). Nach Abschluss des Skills kehrt die Sitzung zum zuvor aktiven Modell zurück.

***

<div id="running-skills-as-subagents">
  ## Skills als Subagents ausführen
</div>

<Warning>
  Das Ausführen von Skills als Subagents ist **experimentell**. Die Frontmatter-Felder `subagent` und `agent` können sich in zukünftigen Releases ändern.
</Warning>

Standardmäßig wird der Prompt eines Skills in die aktuelle Unterhaltung eingefügt — der Agent verarbeitet ihn inline. Alternativ können Sie einen Skill als **Subagent** ausführen. Dabei wird ein unabhängiger Worker mit eigenem Kontextfenster gestartet. Das ist nützlich für Skills, die fokussierte, in sich abgeschlossene Aufgaben ausführen und deren Ausgabe die Hauptunterhaltung nicht überladen soll.

Es gibt zwei Möglichkeiten, einen Skill als Subagent auszuführen:

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

Setze `subagent: true`, um den Skill mit dem Standardprofil `subagent_general` als Subagent auszuführen:

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

Wenn dieses Skill aufgerufen wird, startet es einen Subagenten im Vordergrund, der den Prompt des Skills als Aufgabe ausführt. Der übergeordnete Agent wartet, bis der Subagent seine Arbeit abgeschlossen hat, liest anschließend die Ergebnisse und fasst sie zusammen.

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

Verwende das Feld `agent`, um den Skill als Subagent mit einem bestimmten [benutzerdefinierten Subagent-Profil](/de/cli/subagents#custom-subagents) auszuführen:

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

Der Wert `agent` muss dem Namen eines registrierten Subagent-Profils entsprechen (entweder eines integrierten Profils wie `subagent_explore` / `subagent_general` oder eines benutzerdefinierten Profils, das Sie definiert haben). Der Subagent übernimmt den System-Prompt, die Tool-Einschränkungen und das Modell des Profils — der Inhalt des Skills wird dabei zur Aufgabe.

<Note>
  Wenn sowohl `agent` als auch `subagent` gesetzt sind, hat `agent` Vorrang. Das Feld `model` im Skill überschreibt das Modell des Subagent-Profils, wenn beide angegeben sind.
</Note>

<Note>
  Skills, die als Subagenten ausgeführt werden, erzeugen keine verschachtelten Subagenten — wenn ein Skill bereits innerhalb eines Subagenten ausgeführt wird, wird er stattdessen inline ausgeführt, um eine unendliche Rekursion zu verhindern.
</Note>

<div id="orchestrating-subagents-using-skills">
  ### Subagents mithilfe von Skills orchestrieren
</div>

Da Skills als Subagenten ausgeführt werden können, lassen sie sich zum Orchestrieren mehrstufiger Abläufe verwenden. Definieren Sie eine Reihe von Subagent-Skills, die jeweils eine klar abgegrenzte Aufgabe übernehmen, und schreiben Sie dann einen regulären Skill, der sie aufruft. Der übergeordnete Skill fungiert als Orchestrator — er ruft jeden Subagenten auf, sammelt die Ergebnisse und entscheidet, was als Nächstes zu tun ist.

Zum Beispiel finden Sie hier zwei Subagent-Skills und einen Orchestrator, der sie koordiniert:

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

Das Aufrufen von `/health-check` führt den Orchestrator im Haupt-Agenten aus. Dabei wird `/research-changes` aufgerufen, das einen Subagenten startet, um das Repo zu untersuchen. Sobald das abgeschlossen ist, wird `/validate-tests` aufgerufen, das einen weiteren Subagenten startet, um die Tests auszuführen. Der Orchestrator führt anschließend beide Ergebnisse in einer abschließenden Zusammenfassung zusammen.

Ein Subagenten-Skill setzt beim Aufrufen anderer Skills **niemals** einen Subagenten ein, selbst wenn diese Skills `subagent: true` haben — sie werden stattdessen inline ausgeführt. Das bedeutet, dass du dir keine Gedanken über unbegrenzte Verschachtelung machen musst. Das Orchestrierungsmuster geht immer nur eine Ebene tief: Der Orchestrator startet Subagenten, und diese Subagenten führen alles andere inline aus.

***

<div id="prompt-content">
  ## Prompt-Inhalt
</div>

Der Inhalt der Datei SKILL.md (nach dem frontmatter) ist der Prompt, der beim Aufrufen des Skills eingefügt wird.

***

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

Skills können ihren eigenen Geltungsbereich mit derselben Syntax wie die Hauptkonfiguration der Berechtigungen definieren:

```yaml theme={null}
permissions:
  allow:
    - Read(src/**)
    - Exec(npm run test)
  deny:
    - Write(/etc/**)
    - exec
  ask:
    - Write(src/**)
```

**So funktionieren Skill-Berechtigungen:**

* `allow` — Diese Geltungsbereiche werden bei der Skill-Ausführung automatisch freigegeben
* `deny` — Diese Geltungsbereiche werden bei der Skill-Ausführung blockiert
* `ask` — Bei diesen Geltungsbereichen wird der Nutzer immer zur Bestätigung aufgefordert

<Note>
  Skill-Berechtigungen sind additiv zu den Basisberechtigungen der Sitzung (sie ersetzen sie nicht). Ein Skill kann keine Berechtigungen gewähren, die auf einer höheren Ebene verweigert werden (in der Projekt- oder Organisationskonfiguration).
</Note>

***

<div id="allowed-tools">
  ## Zulässige Tools
</div>

Lege fest, welche Tools der Skill verwenden darf:

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

Verfügbare Toolnamen: `read`, `edit`, `grep`, `glob`, `exec`

Sie können auch MCP-Tools zulassen:

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

<Warning>
  Wenn `allowed-tools` nicht angegeben ist, hat das Skill Zugriff auf alle Tools. Beschränken Sie den Zugriff bei sicherheitskritischen Skills immer auf das notwendige Minimum.
</Warning>

***

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

<div id="code-review-skill">
  ### Code-Review-Skill
</div>

```markdown theme={null}
---
name: review
description: Review staged changes for issues
allowed-tools:
  - read
  - grep
  - glob
  - exec
permissions:
  allow:
    - Exec(git diff)
    - Exec(git log)
---

Run `git diff --staged` and review the changes for quality issues.

Evaluate:
1. **Correctness** — Any logic errors or edge cases?
2. **Security** — Any vulnerabilities introduced?
3. **Performance** — Any obvious inefficiencies?
4. **Style** — Consistent with the codebase?

Provide a summary with specific line references.
```

<div id="component-generator">
  ### Komponentengenerator
</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/**)
---

Create a new React component using the name the user provides:

1. Check existing components in src/components/ for style conventions
2. Create the component file at src/components/<ComponentName>/<ComponentName>.tsx
3. Create a barrel export at src/components/<ComponentName>/index.ts
4. Add basic tests at src/components/<ComponentName>/<ComponentName>.test.tsx
5. Follow the patterns you find in existing components
```

<div id="deployment-checklist">
  ### Bereitstellungs-Checkliste
</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">
  ### Suchprofi
</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">
  ## Tipps
</div>

<CardGroup cols={2}>
  <Card title="Prompts fokussiert halten" icon="bullseye">
    Ein Skill sollte eine Sache gut machen. Erstelle mehrere Skills statt eines Mega-Skills.
  </Card>

  <Card title="Beispiele hinzufügen" icon="lightbulb">
    Zeige dem Agenten in deinem Prompt, wie eine gute Ausgabe aussieht.
  </Card>

  <Card title="allowed-tools verwenden" icon="shield">
    Wenn du Tools einschränkst, werden Skills sicherer und vorhersehbarer.
  </Card>

  <Card title="Mit /skill-name testen" icon="play">
    Führe deinen Skill aus und passe den Prompt iterativ an, bis die Ausgabe deinen Vorstellungen entspricht.
  </Card>
</CardGroup>