Lernleitfaden: Teil 14. Eigener Prozess durch Qwen Code-Fähigkeiten

Thema: Teil 14. Eigener Prozess durch Qwen Code Skills

Schwierigkeitsgrad: Mittelstufe

Geschätzte Lernzeit: 4-6 Stunden (Theorie + Praxis)

Voraussetzungen: Grundkenntnisse in Qwen Code und der Arbeit mit CLI-Agenten

Verständnis von Git und Branching

Erfahrung mit Markdown

Vertrautheit mit dem Konzept des SDD (Specification-Driven Development)

Abgeschlossene Teile 1-13 des Kurses (insbesondere die Arbeit mit QWEN.md)

Lernziele: Agenten-Skills in Qwen Code erstellen und konfigurieren, um wiederkehrende Prozesse zu automatisieren

Persönliche und projektspezifische Skills unterscheiden und die Auswahl des Skill-Typs für Teamarbeit begründen

Effektive Beschreibungen in der YAML-Kopfzeile von SKILL.md formulieren, damit der Skill korrekt automatisch erkannt wird

Eskalationsregeln einführen, die unerwünschte autonome Aktionen des Agenten verhindern

Techniken der Kontexthygiene anwenden, um die Qualität langer Sitzungen mit dem Agenten aufrechtzuerhalten

Überblick: Dieser Teil des Kurses widmet sich der Automatisierung wiederkehrender Ingenieurprozesse durch das Skill-System von Qwen Code. Sie lernen, häufig wiederholte Anfragen in strukturierte, wiederverwendbare Agenten-Skills umzuwandeln, projektspezifische und persönliche Skills zu erstellen, Eskalationsregeln für sichere Agentenarbeit einzuführen und den Kontext langer Sitzungen zu verwalten. Der Hauptfokus liegt auf der praktischen Anwendung: Feature-Spezifikationen im SDD-Format und Changelog-Führung als Beispiele typischer Skills, die die Teamarbeit beschleunigen und Ingenieurpraktiken standardisieren.

Schlüsselkonzepte: Agenten-Skill (Skill): Ein Verzeichnis mit einer SKILL.md-Datei, die einen bestimmten Prozess beschreibt: wann und wie der Agent ihn anwenden soll. Ein Skill ist eine Einheit zur Automatisierung wiederkehrender Anfragen in Qwen Code. Im Gegensatz zu einem Slash-Befehl wird ein Skill vom Modell automatisch oder über /skills aufgerufen und beschreibt eine Fähigkeit, keine starre Schnittstelle.

Persönlicher Skill: Ein Skill, der unter ~/.qwen/skills/<name>/SKILL.md gespeichert ist. Nur für den aktuellen Benutzer auf diesem Rechner verfügbar. Geeignet für individuelle Präferenzen und Experimente, aber nicht im Versionskontrollsystem enthalten.

Projektspezifischer Skill: Ein Skill, der unter .qwen/skills/<name>/SKILL.md innerhalb eines Repositories gespeichert ist. Wird in Git erfasst, wird Teil des Ingenieurprozesses des Teams, gewährleistet Konsistenz zwischen allen Entwicklern und Agenten, die mit dem Projekt arbeiten.

YAML-Kopfzeile von SKILL.md: Metadaten im YAML-Format zwischen Markern --- am Anfang der SKILL.md-Datei. Enthält die Pflichtfelder name (ohne Leerzeichen) und description (konkrete Beschreibung der Anwendungsbedingungen). Eine korrekte Kopfzeile ist entscheidend für die Erkennung des Skills durch den Agenten.

Eskalationsregeln: Ein expliziter Vertrag, der Situationen beschreibt, in denen der Agent verpflichtet ist, anzuhalten und beim Menschen nach Bestätigung zu fragen, anstatt selbstständig zu handeln. Verhindern Raten des Agenten bei unzureichendem Kontext, schützen vor unerwünschten Änderungen.

Kontextdegradation (context rot): Phänomen der Verschlechterung der Agentenleistung bei langen Sitzungen durch Ansammlung irrelevanten Kontexts. Alte Lösungen aus benachbarten Aufgaben werden zufällig in die aktuelle Arbeit hineingezogen und verringern Genauigkeit und Relevanz der Ausgabe.

Kontexthygiene: Gesamtheit der Praktiken zur Kontextverwaltung des Agenten: regelmäßige Verwendung von /clear bei Rollenwechsel, Begrenzung der Sitzungsdauer, explizite Angabe von Dateien durch @file statt Übergabe ganzer Verzeichnisse, Neustart mit QWEN.md-Lektüre bei Verdacht auf Verwirrung.

Hilfsdateien des Skills: Zusätzliche Ressourcen im Skill-Verzeichnis (templates/, Beispiele, Snippets), auf die SKILL.md verweisen kann, um die Funktionalität zu erweitern, ohne die Hauptdatei aufzublähen. Vorlagen werden nicht mit Kommentaren in die endgültigen Spezifikationen kopiert.

AGENTS.md: Ein interagenten-Standard für Regeln im Repository-Wurzelverzeichnis, der QWEN.md ergänzt. Wird nicht nur von Qwen Code, sondern auch von anderen kompatiblen Tools gelesen. Gewährleistet Konsistenz bei paralleler Nutzung mehrerer verschiedener Agenten in einem Projekt.

Praxisübungen: Titel: Erstellen eines grundlegenden Feature-Spezifikations-Skills

Problem: In Ihrem Projekt werden regelmäßig SDD-Spezifikationen neuer Features nach der Roadmap erstellt. Die wiederkehrende Anfrage lautet: „Erstelle eine Spezifikation für die nächste Phase aus roadmap.md“. Dieser Prozess soll durch einen Agenten-Skill automatisiert werden. Erstellen Sie einen projektspezifischen Skill feature-spec mit korrekter YAML-Kopfzeile, einem 8-Schritte-Prozess, drei Ausgabedateien (requirements.md, plan.md, validation.md) und Einschränkungen. Prüfen Sie die Erkennung über /skills.

Lösung: 1. Erstellen Sie das Verzeichnis: mkdir -p .qwen/skills/feature-spec

1. Erstellen Sie die Datei .qwen/skills/feature-spec/SKILL.md mit folgendem Inhalt:

--- name: feature-spec description: Erstellt eine neue SDD-Feature-Spezifikation aus der nächsten unvollständigen Phase der Roadmap. Verwenden Sie vor Beginn des nächsten Features, beim Schreiben der Spezifikation oder bei der Vorbereitung einer neuen Phase vor der Implementierung. --- # Feature-Spezifikation ## Prozess

1. specs/roadmap.md lesen
2. Erste unvollständige Phase finden
3. Branch phase-N-kebab-name erstellen
4. Dem Menschen drei Fragengruppen stellen: Grenzen, Lösungen, Kontext
5. specs/mission.md und specs/tech-stack.md lesen
6. specs/YYYY-MM-DD-feature-name/ erstellen
7. requirements.md, plan.md, validation.md schreiben
8. Keinen Code implementieren

## Datei requirements.md — Grenzen, außerhalb der Grenzen, Lösungen, Kontext, offene Fragen ## Datei plan.md — nummerierte Aufgabengruppen, jede einzeln prüfbar ## Datei validation.md — automatische Prüfungen, manueller Durchlauf, Abweichungsprüfung, Fertigstellungskriterien ## Einschränkungen: tech-stack.md einhalten, keine Abhängigkeiten ohne Genehmigung hinzufügen, Phase lieferfähig lassen, keine unverwandten Dateien bearbeiten

1. Qwen Code neu starten
2. /skills ausführen — sicherstellen, dass feature-spec angezeigt wird
3. Aufruf prüfen: „Verwende den Skill feature-spec, um das nächste Feature aus der Roadmap zu beginnen. Implementiere keinen Code."
4. Falls der Skill nicht funktioniert, prüfen: Dateipfad, Korrektheit der YAML-Kopfzeile (--- am Anfang und Ende), keine Leerzeichen in name, Konkretheit von description, Neustart des Agenten

Schwierigkeitsgrad: Anfänger

Titel: Erweiterung des Skills mit Hilfsvorlagen

Problem: Der Feature-Spezifikationsprozess ist gewachsen, und die SKILL.md-Datei ist unhandlich geworden. Außerdem erfordern verschiedene Spezifikationen eine einheitliche Struktur, aber das Team verliert Zeit mit Formatierung. Die Vorlagen müssen in separate Dateien ausgelagert und SKILL.md für deren Nutzung aktualisiert werden.

Lösung: 1. Erstellen Sie das Verzeichnis templates innerhalb des Skills: mkdir -p .qwen/skills/feature-spec/templates

1. Erstellen Sie .qwen/skills/feature-spec/templates/requirements.md mit der Anfangsstruktur:

# Anforderungen ## Grenzen <!-- Was gehört zum Feature --> ## Außerhalb der Grenzen <!-- Was gehört explizit nicht dazu --> ## Lösungen <!-- Getroffene Architekturentscheidungen --> ## Kontext <!-- Warum genau diese Entscheidungen getroffen wurden --> ## Offene Fragen <!-- Was einer Klärung bedarf -->

1. Erstellen Sie analog templates/plan.md und templates/validation.md
2. Aktualisieren Sie SKILL.md, fügen Sie dem Prozess hinzu:

„Verwende templates/requirements.md als Anfangsstruktur. Kopiere keine Vorlagenkommentare in die endgültigen Spezifikationen."

1. Prüfen, dass der Agent Vorlagen korrekt verwendet, ohne Anleitungskommentare in die Ausgabedateien zu übernehmen
2. Änderungen committen: git add .qwen/skills/ && git commit -m "Add feature-spec skill with templates"

Schwierigkeitsgrad: Mittelstufe

Titel: Einführung von Eskalationsregeln

Problem: Der Agent in Ihrem Projekt hat mehrfach eigenmächtig umstrittene Entscheidungen getroffen: Abhängigkeiten ohne Abstimmung hinzugefügt, Dateien außerhalb der Spezifikationsgrenzen geändert, tech-stack.md bearbeitet. Eskalationsregeln müssen in QWEN.md oder einem Skill formalisiert werden, damit der Agent verpflichtet anhält und Bestätigung anfragt.

Lösung: 1. Öffnen oder erstellen Sie QWEN.md im Repository-Wurzelverzeichnis (oder fügen Sie dem vorhandenen SKILL.md hinzu)

1. Fügen Sie den Abschnitt „Eskalationsregeln" hinzu:

Halte an und frage den Menschen, handle nicht, in folgenden Fällen:

• wenn in der Feature-Spezifikation verschiedene Interpretationen einer Anforderung verbleiben;
• wenn du eine Datei außerhalb der Grenzen der aktuellen Spezifikation ändern willst;
• wenn du eine neue Abhängigkeit hinzufügen willst, die nicht in tech-stack.md aufgeführt ist;
• wenn du tech-stack.md, mission.md oder roadmap.md ändern willst;
• wenn eine Migration, drop, delete oder rm mit nichttrivialem Radius erforderlich ist;
• wenn du eine vom Benutzer referenzierte Datei nicht gefunden hast;
• wenn das Ergebnis nicht mit einer Tatsache aus validation.md übereinstimmt und die Tatsache nicht als „verschoben" markiert ist;
• wenn die Benutzeranfrage zuvor festgelegten QWEN.md-Regeln widerspricht.

Gib in jedem solchen Fall eine kurze Erklärung aus, was genau mehrdeutig ist, und biete 2–3 konkrete Optionen zur Auswahl an. Wähle nicht für den Menschen.

1. Testen Sie mit dem Szenario: Bitten Sie den Agenten, eine Bibliothek hinzuzufügen, die nicht in tech-stack.md steht — sicherstellen, dass er mit Optionen anhält
2. Zusätzlich: Studieren Sie den Stop-Hook aus Teil 17 für die programmatische Überprüfung der Regelbefolgung

Schwierigkeitsgrad: Mittelstufe

Titel: Erstellen eines Changelog-Skills

Problem: Das Team verliert Zeit mit manuellem Aktualisieren von CHANGELOG.md vor dem Feature-Merge. Die Commit-Historie ist unübersichtlich, die Formatierung inkonsistent. Erstellen Sie einen Skill changelog, der den Prozess auf Basis von git log und git diff automatisiert.

Lösung: 1. Erstellen Sie das Verzeichnis: mkdir -p .qwen/skills/changelog

1. Erstellen Sie .qwen/skills/changelog/SKILL.md:

--- name: changelog description: Aktualisiert CHANGELOG.md anhand der Git-Historie und der Änderungen des aktuellen Branches vor dem Merge eines Feature-Branches. --- # Änderungsprotokoll

1. git log und git diff relativ zu main ansehen
2. CHANGELOG.md erstellen oder aktualisieren
3. Überschriften mit Daten verwenden
4. Kurze Punkte schreiben, die für Stakeholder verständlich sind
5. Keine lärmenden internen Details einfügen
6. Qwen Code neu starten, über /skills prüfen
7. Testbranch mit mehreren Commits erstellen, Agenten bitten, den Skill changelog zu verwenden
8. Ergebnis prüfen: Daten in Überschriften, keine internen Details wie „Refactoring von Funktion X", verständliche Beschreibungen für Benutzer
9. Skill vor dem echten Merge in main verwenden

Schwierigkeitsgrad: Anfänger

Titel: Diagnose und Behebung von Skill-Erkennungsproblemen

Problem: Sie haben einen Skill erstellt, aber der Agent sieht ihn nicht in /skills oder wendet ihn bei expliziter Anfrage nicht an. Systematisch diagnostizieren und beheben Sie das Problem.

Lösung: 1. Pfad prüfen: Datei muss in .qwen/skills/<name>/SKILL.md (projektspezifisch) oder ~/.qwen/skills/<name>/SKILL.md (persönlich) liegen

1. YAML-Kopfzeile prüfen:

• Beginnt und endet mit exakten Markern --- (ohne Leerzeichen, ohne BOM)
• Feld name ohne Leerzeichen, nur lateinische Buchstaben, Bindestriche, Unterstriche
• Feld description beschreibt konkret die Anwendungsbedingungen, keine allgemeinen Phrasen wie „nützlicher Skill"

1. Zugriffsrechte prüfen: Datei muss lesbar sein
2. Neustart prüfen: Qwen Code cached Skills beim Start, Änderungen erfordern Neustart
3. Markdown-Syntax prüfen: Defekte Überschriften oder Tabellen können das Parsen behindern
4. Namenskonflikte prüfen: Zwei Skills mit identischem name sind unzulässig
5. Falls alles korrekt — Qwen Code-Version prüfen, möglicherweise Update erforderlich
6. Temporäre Lösung: Expliziter Import über /load oder entsprechender Befehl Ihrer Version

Schwierigkeitsgrad: Mittelstufe

Titel: Optimierung einer langen Sitzung mit Kontexthygiene

Problem: Sie arbeiten seit 90 Minuten mit dem Agenten an einer komplexen Aufgabe. Anzeichen der Kontextdegradation bemerkt: Der Agent verweist auf Lösungen aus einer vorherigen Aufgabe, schlägt irrelevante Dateien vor, verwechselt die Grenzen des aktuellen Features. Wenden Sie Kontexthygienetechniken an, um die Arbeitsqualität wiederherzustellen.

Lösung: 1. /clear ausführen für vollständige Kontextbereinigung der Sitzung

1. QWEN.md von Grund auf neu lesen: „Lies QWEN.md und befolge seine Regeln"
2. Aktive Spezifikation neu lesen: „Lies specs/YYYY-MM-DD-feature-name/requirements.md und alle zugehörigen Dateien"
3. Benötigte Dateien explizit durch @file angeben statt „finde selbst" oder Übergabe ganzer Verzeichnisse
4. Verbleibende Arbeit in Teilaufgaben à 15-20 Minuten aufteilen
5. Zwischen Teilaufgaben /clear verwenden und nur relevanten Kontext neu lesen
6. Falls automatische Kontextkomprimierung aktiviert — beachten, dass sie Zusammenfassungen speichert, die falsche Hinweise enthalten können; /clean ist bei Rollenwechsel vorzuziehen
7. Zwischenergebnisse in Projektdateien dokumentieren, nicht auf Sitzungsspeicher verlassen

Schwierigkeitsgrad: Fortgeschritten

Fallstudien: Titel: Einführung von SDD-Skills in einem Fintech-Startup: Von Chaos zur Standardisierung

Szenario: Fintech-Startup mit 12 Entwicklern und 3 Produktteams. Jedes Team verwendete ein anderes Spezifikationsformat: Die einen schrieben in Google Docs, die anderen in Notion, die dritten kamen mit mündlichen Absprachen aus. Bei Entwicklerrotation zwischen Teams waren 2-3 Tage Anpassung an das neue Format nötig. Die Einführung von Qwen Code löste das Problem nicht: Der Agent generierte Spezifikationen im Format, das er zuletzt im Kontext gesehen hatte, was zu Fragmentierung führte.

Herausforderung: Es musste: (1) das SDD-Spezifikationsformat für alle Teams standardisiert, (2) dieses Format automatisch durch den Agenten anwendbar gemacht werden ohne zusätzliche Anweisungen, (3) Versionierung und Evolution des Formats gewährleistet, (4) die Anpassungszeit bei Rotation minimiert werden.

Lösung: Der Techlead erstellte einen projektspezifischen Skill feature-spec im Wurzelrepository des Unternehmens (Mono-Repo mit 40+ Services). Der Skill umfasste: einen strengen 8-Schritte-Prozess, drei Ausgabedateien mit detaillierten Inhaltsanforderungen, Vorlagen in einem Unterverzeichnis templates/, und Eskalationsregeln, die dem Agenten Abweichungen von tech-stack.md verbieten. Zusätzlich wurde ein Skill changelog für einheitliche Changelog-Führung erstellt. Für interteam-Konsistenz wurde AGENTS.md mit Basisregeln in die Mono-Repo-Wurzel eingefügt, die von allen Team-Tools gelesen werden.

Ergebnis: Nach 3 Wochen nach Einführung: Spezifikationserstellung von 4 Stunden auf 45 Minuten reduziert (inklusive Zeit für Klärungsfragen des Agenten); Anpassung bei Rotation auf 2 Stunden reduziert (SKILL.md lesen genügt); 94% der Spezifikationen wurden ohne Nacharbeit im Review akzeptiert (gegenüber 60% zuvor); einheitliches CHANGELOG ermöglichte automatisierte Release-Notes-Generierung; das Team identifizierte und korrigierte 7 Fälle, in denen der Agent nicht genehmigte Abhängigkeiten hinzufügen wollte, dank der Eskalationsregeln.

Gelernte Lektionen: Projektspezifische Skills im Wurzelrepository sind für die Skalierung von Praktiken effektiver als persönliche Skills einzelner Entwickler

Eskalationsregeln sind keine überflüssige Bürokratie, sondern Einsparung: 7 verhinderte Abhängigkeitsvorfälle sparten eine Woche Rücksetzarbeit

Vorlagen in templates/ beschleunigen die Agentenarbeit und erhöhen Konsistenz, erfordern aber die explizite Regel „kopiere keine Kommentare"

AGENTS.md ist bei Nutzung mehrerer Tools (Qwen Code, Cursor, eigene Skripte) erforderlich — verhindert Regeldivergenz

Verwandte Konzepte: Projektspezifischer Skill

Eskalationsregeln

Hilfsdateien des Skills

AGENTS.md

Kontexthygiene

Titel: Rettung vor Kontextdegradation in einer langen Agenten-Sitzung für umfassendes Refactoring

Szenario: Ein Team aus 4 Entwicklern führte ein umfassendes Refactoring des Kerns des Zahlungssystems durch. Ein Entwickler nutzte Qwen Code für die sequenzielle Bearbeitung von 15 verbundenen Services in einer 3-stündigen Sitzung. Ab dem 8. Service schlug der Agent Lösungen vor, die für den 3. Service charakteristisch waren (veraltete Architektur, bereits verworfen), und versuchte, tech-stack.md zu ändern, um „für ein Muster zu optimieren", das das Team bewusst abgelehnt hatte.

Herausforderung: Kontextdegradation diagnostizieren und stoppen ohne Fortschrittsverlust; verstehen, warum automatische Kontextkomprimierung nicht half; korrekte Agentenarbeit wiederherstellen; Wiederholung in zukünftigen langen Sitzungen verhindern.

Lösung: Der Entwickler wandte Notfall-Kontexthygiene an: /clear, Neulesen von QWEN.md und aktiver Spezifikation, explizite @file-Angabe für den konkreten Service statt „bearbeite die restlichen". Für die verbleibenden 7 Services wurde die Arbeit in separate Sitzungen à 20 Minuten aufgeteilt mit obligatorischem /clear dazwischen. Zwischenergebnisse wurden in Projektdateien festgehalten, nicht im Sitzungsspeicher. Es stellte sich heraus, dass die automatische Komprimierung veraltete Lösungen als „wichtigen Kontext" in einer Zusammenfassung behielt, was zur Quelle falscher Hinweise wurde.

Ergebnis: Die letzten 7 Services wurden korrekt bearbeitet, ohne Abweichungen von der genehmigten Architektur. Der Entwickler dokumentierte den Vorfall in der internen Wissensdatenbank. Das Team führte eine Regel ein: Agenten-Sitzungen auf 45 Minuten begrenzt, zwanghaftes /clear und QWEN.md-Neulesen zwischen Phasen. Bei späteren Refactorings wurden keine ähnlichen Vorfälle beobachtet.

Gelernte Lektionen: Automatische Kontextkomprimierung hilft bei einer langen kontinuierlichen Aufgabe, schadet aber bei sequenziell verschiedenen Aufgaben — die Zusammenfassung wird zur Quelle falscher Hinweise

/clear garantiert einen sauberen Neustart, erfordert aber Disziplin beim Dokumentieren von Zwischenergebnissen in Dateien

Sitzungsdauerbegrenzung (45 Minuten) — eine einfache und effektive Regel, leicht in Retrospektiven überprüfbar

Explizite @file-Angabe ist nach /clear kritisch: Der Agent „errät" den Kontext nicht aus der vorherigen Sitzung

Verwandte Konzepte: Kontextdegradation

Kontexthygiene

Eskalationsregeln

Projektspezifischer Skill

Lerntipps: Beginnen Sie mit einem persönlichen Skill in ~/.qwen/skills/, debuggen Sie ihn an Ihrem Projekt, dann migrieren Sie ihn in einen projektspezifischen — so vermeiden Sie Commits nicht funktionierender Versionen in Git

Prüfen Sie die YAML-Kopfzeile mit einem Validator (z.B. yamllint) — unsichtbare Formatierungsfehler führen oft zur Nichterkennung des Skills

Führen Sie ein „Eskalationstagebuch": Notieren Sie Fälle, in denen der Agent hätte anhalten sollen, aber nicht anhielt — ergänzen Sie danach die Regeln

Nutzen Sie die Technik des „parallelen Vergleichs": Erstellen Sie denselben Skill auf zwei Arten (über SKILL.md und über Slash-Befehl), testen Sie ihn an derselben Aufgabe, dokumentieren Sie die Verhaltensunterschiede

Üben Sie den „Hygiene-Stresstest": Erzeugen Sie absichtlich eine lange Sitzung mit Rollenwechsel, um frühe Anzeichen der Kontextdegradation zu erkennen

Erstellen Sie einen „Skill für Skills" — einen Meta-Skill, der beim Erstellen neuer Skills nach Vorlage mit korrekter YAML-Kopfzeile und Struktur hilft

Studieren Sie fremde projektspezifische Skills in Open-Source-Repositories — die Qwen Code-Community teilt aktiv Best Practices

Kombinieren Sie visuelles, audibles und kinästhetisches Lernen: Lesen Sie SKILL.md laut zur Klarheitsprüfung der Anweisungen, zeichnen Sie Prozessablaufdiagramme, schreiben Sie Skills von Hand vor der digitalen Eingabe für bessere Struktureinprägung

Zusätzliche Ressourcen: Offizielle Qwen Code-Dokumentation: https://github.com/QwenLM/Qwen-Code (aktuelle Skill-Beispiele und Format-Updates)

Kursteil 15 — AGENTS.md und Interagenten-Kompatibilität: part-15-agent-replaceability.md (im Kursrepository)

Kursteil 17 — Stop-Hook für programmatische Eskalationsprüfung: part-17-stop-hooks.md (im Kursrepository)

Kursteil 19 — Verwalteter Agentenspeicher auf SQLite: part-19-agent-memory-sqlite.md (im Kursrepository)

YAML-Spezifikation 1.2: https://yaml.org/spec/1.2.2/ (für tiefes Verständnis der SKILL.md-Kopfzeilenanforderungen)

Community-Beispiele projektspezifischer Skills: https://github.com/search?q=path%3A.qwen%2Fskills+SKILL.md&type=code (Suche öffentlicher Repositories)

Forschung zu Context Rot in LLM-Agenten: https://arxiv.org/abs/2404.06910 (akademische Analyse der Kontextdegradation)

Interaktiver YAML-Kopfzeilen-Trainer: https://www.yamllint.com/ (Syntaxprüfung von Skill-Metadaten)

Zusammenfassung: Schlüsselerkenntnisse von Teil 14: (1) Wiederkehrende Anfragen sollten durch Agenten-Skills automatisiert werden — das spart Zeit und standardisiert Prozesse. (2) Projektspezifische Skills (.qwen/skills/) sind für Teamarbeit persönlichen Skills (~/.qwen/skills/) vorzuziehen, da sie in Git versioniert und allen Teilnehmern zugänglich sind. (3) Eine korrekte YAML-Kopfzeile mit konkretem description ist entscheidend für die automatische Skill-Erkennung durch den Agenten. (4) Eskalationsregeln sind ein obligatorischer Sicherheitsvertrag, der unerwünschte autonome Agentenaktionen bei Unklarheit verhindert. (5) Kontexthygiene (/clear, Sitzungsdauerbegrenzung, explizite Dateiangabe) ist nicht weniger wichtig als Skill-Qualität — Kontextdegradation zerstört die Effektivität selbst perfekt geschriebener Anweisungen. (6) Skills und Slash-Befehle ergänzen sich: Skills für automatische Anwendung, Befehle für expliziten Aufruf. (7) Hilfsdateien (templates/) ermöglichen die Skalierung komplexer Skills ohne Aufblähung der SKILL.md.