SKILL.md Templates¶
Fertige Templates für die häufigsten Skill-Typen – kopieren, anpassen, nutzen.
Template-Übersicht¶
| Template | Use Case | Context |
|---|---|---|
| Review-Skill | Code/Config reviewen | fork |
| Generator-Skill | Dateien/Configs generieren | conversation |
| Audit-Skill | Security/Compliance prüfen | fork |
| Report-Skill | Reports aus Daten generieren | conversation |
| Refactor-Skill | Code umstrukturieren | conversation |
Review-Skill¶
Read-only, analysiert und gibt Feedback.
---
name: [review-name]
description: Reviewt [Was]. Aktiviert bei Review-Anfragen für [Was].
context: fork
allowed-tools:
- Read
- Glob
- Grep
---
# [Name] Review
## Vorgehen
1. Lies alle relevanten Dateien
2. Verstehe den Kontext
3. Analysiere nach den folgenden Kriterien
## Review-Kriterien
### Kritisch (Blocker)
- [Kriterium 1]
- [Kriterium 2]
### Warnung (Sollte gefixt werden)
- [Kriterium 3]
- [Kriterium 4]
### Info (Nice to have)
- [Kriterium 5]
## Output-Format
## Review-Ergebnis: [Datum]
### Zusammenfassung
[2-3 Sätze Gesamteindruck]
### Kritische Findings
- **[Titel]** (`Datei:Zeile`)
Problem: [Beschreibung]
Fix: [Konkrete Empfehlung]
### Warnungen
[...]
### Empfehlungen
[...]
Beispiel: Ansible Playbook Review
---
name: ansible-review
description: Reviewt Ansible Playbooks auf Best Practices, Idempotenz und Sicherheit.
context: fork
allowed-tools:
- Read
- Glob
- Grep
---
# Ansible Playbook Review
## Prüfkriterien
### Kritisch
- Klartext-Credentials im Code
- Fehlende `no_log` bei sensitiven Tasks
- Tasks die nicht idempotent sind
### Warnung
- Fehlende Tags
- `become: yes` ohne Notwendigkeit
- Hardcoded Hostnamen statt Inventory-Variablen
- Kein `--check` Mode Support
### Info
- Fehlende Kommentare bei komplexen Tasks
- Handler-Optimierungspotential
## Output
Strukturierter Report mit YAML-Snippet-Fixes wo möglich.
Generator-Skill¶
Erstellt neue Dateien oder Inhalte nach einem Schema.
---
name: [generator-name]
description: Generiert [Was]. Aktiviert wenn User [Was] erstellen will.
context: conversation
---
# [Name] Generator
## Input
Folgende Informationen werden benötigt:
- [Parameter 1]: [Beschreibung]
- [Parameter 2]: [Beschreibung]
- [Parameter 3]: [Beschreibung]
Wenn Informationen fehlen: Nachfragen, nicht raten.
## Generierungsprozess
1. [Schritt 1]
2. [Schritt 2]
3. [Schritt 3]
## Output-Struktur
Beispiel: FortiGate Firewall Policy Generator
---
name: fg-policy
description: Generiert FortiGate Firewall Policies. Aktiviert bei Policy-Erstellungs-Anfragen.
context: conversation
---
# FortiGate Policy Generator
## Benötigte Informationen
Frage nach falls nicht angegeben:
- Source-Interface und Source-Subnet
- Destination-Interface und Destination-Subnet
- Protokoll(e) und Port(s)
- Zweck der Policy (für den Namen)
- Logging gewünscht? (Empfehlung: Ja)
## Policy-Naming-Konvention
`[SRC-ZONE]_to_[DST-ZONE]_[SERVICE]_[NR]`
Beispiel: `LAN_to_WAN_HTTP_001`
## Output
Vollständige Fortios-Konfiguration:
Audit-Skill¶
Security- oder Compliance-Prüfung mit strukturiertem Report.
---
name: [audit-name]
description: Führt [Security/Compliance]-Audit durch. Aktiviert bei Audit-Anfragen.
context: fork
allowed-tools:
- Read
- Glob
- Grep
- Bash([erlaubte Commands]*)
---
# [Name] Audit
## Scope
Dieser Audit prüft:
- [Bereich 1]
- [Bereich 2]
- [Bereich 3]
## Methodik
### Automatisierte Checks
!`[Command der Informationen sammelt]`
### Manuelle Analyse
[Was wird manuell geprüft]
## Bewertungsschema
| Severity | Kriterium |
|----------|-----------|
| Kritisch | Aktive Ausnutzbarkeit, Datenverlust-Risiko |
| Hoch | Erhöhtes Risiko, einfach ausnutzbar |
| Mittel | Risiko vorhanden, aber mitigierbar |
| Niedrig | Verbesserungspotential |
## Report-Format
# [Name] Audit Report
**Datum:** [Datum]
**Scope:** [Was wurde geprüft]
## Executive Summary
[3 Sätze: Gesamtbewertung]
## Findings
### Kritisch ([Anzahl])
#### [Finding-Titel]
- **Beschreibung:** [Was ist das Problem]
- **Risiko:** [Was kann passieren]
- **Empfehlung:** [Wie fixen]
- **Referenz:** [CVE/Standard wenn applicable]
[...]
## Zusammenfassung
| Severity | Anzahl |
|----------|--------|
| Kritisch | X |
| Hoch | X |
| Mittel | X |
| Niedrig | X |
Report-Skill¶
Aggregiert Informationen und erstellt strukturierte Berichte.
---
name: [report-name]
description: Erstellt [Report-Typ]. Aktiviert bei Report-Anfragen für [Kontext].
context: conversation
---
# [Name] Report Generator
## Datenquellen
Der Report aggregiert:
- !`[Command 1]`
- !`[Command 2]`
## Report-Struktur
1. **Executive Summary** (3-5 Sätze)
2. **Metriken** (Tabelle)
3. **Details** (Aufschlüsselung)
4. **Empfehlungen** (Priorisiert)
## Format-Optionen
Nutze `--format=markdown` (default) oder `--format=table`.
## Beispiel-Output
[Beispiel wie der Report aussehen soll]
Beispiel: Git-Activity Report
---
name: git-report
description: Erstellt Activity-Report aus Git-History. Für Standup oder Sprint-Review.
context: conversation
---
# Git Activity Report
## Daten sammeln
Commits der letzten 7 Tage:
!`git log --since="7 days ago" --pretty=format:"%h %ad %an %s" --date=short`
Geänderte Dateien:
!`git diff --stat HEAD~20`
## Report erstellen
Strukturiere die Aktivitäten nach:
1. Was wurde fertiggestellt?
2. Was ist in Arbeit?
3. Woran wurde am meisten gearbeitet?
## Output
Kompaktes Markdown, max. 1 Seite. Geeignet für Standup oder Team-Update.
Refactor-Skill¶
Strukturiert Code-Änderungen mit Plan-Phase.
---
name: [refactor-name]
description: Refactored [Was]. Analysiert erst, macht Plan, dann Änderungen.
context: conversation
---
# [Name] Refactoring
## Phase 1: Analyse (Read-only)
1. Lies alle relevanten Dateien
2. Verstehe die aktuelle Struktur
3. Identifiziere Probleme und Verbesserungspotenzial
## Phase 2: Plan
Erstelle einen detaillierten Plan:
- Was wird geändert?
- In welcher Reihenfolge?
- Was bleibt unberührt?
**Präsentiere den Plan bevor du Änderungen machst.**
Warte auf Bestätigung.
## Phase 3: Ausführung
Nach Bestätigung:
- Ändere Dateien in der geplanten Reihenfolge
- Teste nach jeder Änderung wenn möglich
- Dokumentiere größere Änderungen
## Qualitätskriterien
- Funktionalität bleibt erhalten
- Tests laufen durch
- Kein totes Code bleibt zurück
Tipps für eigene Templates¶
DO ✅¶
- Frontmatter-`context: fork` für Read-only Skills
- Explizites allowed-tools wenn möglich
- Output-Format im Skill definieren (nicht dem User überlassen)
- Dynamische Daten mit !`command` einbinden
DON'T ❌¶
- Zu allgemeine Descriptions (schlechtes Auto-Triggering)
- Keine Tool-Beschränkung bei read-only Skills
- Output-Format fehlt (dann kommt immer was anderes)
- Mehr als 200 Zeilen (wird unhandlich)