Use this file to discover all available pages before exploring further.
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.
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.
Unter Windows bezieht sich %APPDATA% typischerweise auf C:\Users\<YourUser>\AppData\Roaming.
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:
---name: quick-fixdescription: Fast lint fix using a lightweight modelmodel: 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. Nach Abschluss des Skills kehrt die Sitzung zum zuvor aktiven Modell zurück.
Das Ausführen von Skills als Subagents ist experimentell. Die Frontmatter-Felder subagent und agent können sich in zukünftigen Releases ändern.
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:
Setze subagent: true, um den Skill mit dem Standardprofil subagent_general als Subagent auszuführen:
---name: deep-researchdescription: Thorough codebase research on a topicsubagent: truemodel: sonnetallowed-tools: - read - grep - glob---Research the following topic thoroughly: $ARGUMENTSSearch 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.
---name: review-prdescription: Review the current PR using the reviewer subagentagent: 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.
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.
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.
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:
---name: research-changesdescription: Research recent code changes and their impactsubagent: trueallowed-tools: - read - grep - glob - exec---Analyze the recent changes in this repository:1. Run `git log --oneline -20` to see recent commits2. For each significant commit, examine what changed and why3. Identify any patterns, risks, or areas that need attentionReport your findings with specific file paths and commit references.
---name: validate-testsdescription: Run tests and validate coverage for recent changessubagent: trueallowed-tools: - read - grep - glob - exec---Validate the test suite for the project:1. Identify the test framework and run command2. Run the full test suite3. Check for any failing tests4. Review test coverage for recently changed filesReport which tests pass, which fail, and any coverage gaps.
---name: health-checkdescription: 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 changes2. Then, use the /validate-tests skill to verify the test suite3. 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.
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
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).
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.
---name: reviewdescription: Review staged changes for issuesallowed-tools: - read - grep - glob - execpermissions: allow: - Exec(git diff) - Exec(git log)---Review the current changes for quality issues:!`git diff --staged`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.
---name: componentdescription: Generate a React component from a descriptionargument-hint: "<ComponentName>"allowed-tools: - read - edit - grep - globmodel: sonnetpermissions: allow: - Write(src/components/**)---Create a new React component named `$1`:1. Check existing components in src/components/ for style conventions2. Create the component file at src/components/$1/$1.tsx3. Create a barrel export at src/components/$1/index.ts4. Add basic tests at src/components/$1/$1.test.tsx5. Follow the patterns you find in existing components
---name: deploydescription: Run through the deployment checklisttriggers: - userallowed-tools: - read - exec - greppermissions: 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 commitReport the status of each step. If anything fails, stop and explain the issue.
---name: finddescription: Find relevant code across the projectargument-hint: "<what to find>"allowed-tools: - read - grep - globtriggers: - user - model---Search the codebase thoroughly for: $ARGUMENTSUse grep for content search and glob for file discovery.Provide relevant file paths and code snippets.Explain how the pieces connect.