Bevor wir die Regeln durchgehen: Das ist der Unterschied, den du gleich selbst machst. Derselbe Wunsch, zwei Prompts — der klare spart dir drei Nachfragen.
Aus dem klaren Prompt kommt eine fertige Tabelle mit 3 Partnern, Fit-Score und Pitch-Satz — ohne eine einzige Rückfrage. Wie du dahin kommst, lernst du auf dieser Seite.
Ein starker Prompt beantwortet vier Fragen. Nicht immer brauchst du alle vier — aber je mehr davon klar sind, desto besser das Ergebnis.
Die grünen Punkte zeigen, welche Bausteine schon drin sind. → Genau so startest du an Tag 1.
Derselbe Wunsch, zwei Prompts. Der zweite spart dir drei Nachfragen — weil er alle vier Bausteine liefert.
Constraints sind keine Einschränkung — sie sind Steuerung. Vier Typen decken fast alles ab.
Das Format entscheidet, ob du das Ergebnis direkt weiterverwenden kannst. Nenne es explizit — der Agent liefert genau das.
Gute Ergebnisse entstehen selten beim ersten Versuch. Nachschärfen ist normal — und schnell.
Wenn du an Tag 2 eigene Skills baust, entscheidet die Qualität der SKILL.md über alles. Der offene Referenz-Skill writing-great-skills von Matt Pocock fasst die Prinzipien dafür zusammen. Hier die Kernidee — und darunter kannst du ihn dir als Skill in Hermes kopieren.
Quelle: github.com/mattpocock/skills · writing-great-skills ↗
Ihr wollt Skills, Ideen, Prompts und Agenten bauen — nicht programmieren. Deshalb hier die drei produktiven, code-freien Skills aus Matt Pococks Repo, die Einsteiger zuerst brauchen: schärfen, was du bauen willst · dir ein Thema beibringen lassen · Wissen sauber an die nächste Session übergeben. Jeder ist als komplette SKILL.md kopierbar.
Quelle: github.com/mattpocock/skills ↗ · MIT-Lizenz · faithful eingebaut. Verlinkte Format-Dateien (z. B. MISSION-FORMAT.md) sind nicht enthalten.
Je Skill einen Ordner unter ~/.hermes/skills/<name>/ anlegen, den kopierten Text als SKILL.md speichern, Hermes neu starten. Alle sind user-invoked — du rufst sie per Schrägstrich auf: /grill-me, /teach, /handoff, /wegweiser.
Das Vokabular hinter writing-great-skills. Ein Skill zähmt einen stochastischen Agenten — die Wurzel-Tugend ist Predictability, jeder Begriff darunter ist ein Hebel darauf. Sortiert nach vier Achsen; Fehlerbilder stehen neben dem Hebel, der sie kuriert.
Quelle: Matt Pocock · writing-great-skills / GLOSSARY.md ↗ · deutsche Kurzfassung
Wie stark ein Skill den Agenten bei jedem Lauf denselben Weg gehen lässt — denselben Prozess, nicht denselben Output. Ein Brainstorming-Skill soll verlässlich divergieren: seine Tokens variieren, sein Verhalten nicht. Kosten und Wartbarkeit sind Symptome davon, keine Gegenspieler.
Behält sein description-Feld — der Agent findet und startet den Skill selbst, der Mensch kann ihn zusätzlich per Name aufrufen. Kostet dauerhaft Context Load. Nur wählen, wenn der Agent den Skill autonom erreichen muss.
Description entfernt — für den Agenten unsichtbar, nur der Mensch ruft ihn per Name auf. Tauscht Auffindbarkeit gegen null Context Load. Kein anderer Skill kann ihn starten.
Der maschinenlesbare Trigger. Ihre bloße Existenz ist die Invocation-Achse: behalten → model-invoked; löschen → user-invoked. Quelle der Context Load.
Ein Verweis im Kontext, der auf Material außerhalb zeigt und die Bedingung zum Erreichen kodiert. Seine Formulierung entscheidet, wann und wie zuverlässig der Agent hingeht — nicht das Ziel.
Die Last, die ein model-invoked Skill dem Kontextfenster aufbürdet — die stets geladene Description kostet Tokens und Aufmerksamkeit. Die Bremse gegen zu viele model-invoked Skills.
Die Last beim Menschen: welche Skills existieren und wann man welchen greift. Kein Kostenfaktor zum Minimieren, sondern der Preis menschlicher Handlungsmacht — dort ausgeben, wo Urteil zählt.
Ein user-invoked Skill, der auf deine anderen user-invoked Skills zeigt — einer zum Merken statt vieler. Kann nur hinweisen, nie starten. Die Kur gegen wachsende Cognitive Load.
Wie fein du Skills teilst. Mehr model-invoked → mehr Context Load; mehr user-invoked → mehr Cognitive Load. Teile per Leitwort (Trigger) oder per Sequenz (wenn Folge-Schritte verborgen werden müssen).
Der Inhalt nach Dringlichkeit geordnet — eine Leiter: Steps (in-file, primär) → Reference in-file (sekundär) → Reference ausgelagert (hinter Pointer). Oben lesbar halten, alles Mögliche nach unten schieben.
Die geordneten Handlungen des Agenten — wenn vorhanden, der primäre Inhalt. Nicht jeder Skill hat Steps (ein Review ist reine Reference). Jeder Step endet an einem Completion Criterion.
Material zum Nachschlagen — Definitionen, Fakten, Parameter, Beispiele. Bei Skills mit Steps sekundär, sonst der ganze Inhalt. Erster Kandidat für Progressive Disclosure.
Reference außerhalb des Skill-Systems — eine reine Datei, nicht aufrufbar, auf die jeder Skill zeigen kann. Das einzige gemeinsame Zuhause, das zwei user-invoked Skills teilen können.
Reference die Leiter hinunter schieben — raus aus SKILL.md, hinter einen Pointer — damit oben lesbar bleibt. Kein Token-Trick, sondern Schutz der Hierarchie. Feuert ein Pointer unzuverlässig, erst die Formulierung schärfen.
Was zusammen gebraucht wird, steht zusammen — Definition, Regeln, Vorbehalte unter einer Überschrift. Ein Skill soll sich wie Doku lesen, die für den Agenten geschrieben ist.
Ein Skill, der schlicht zu lang ist — unabhängig von veraltet oder doppelt. Kur: Reference nach unten schieben, nach Branch/Sequenz splitten. Unterscheidet sich von Sediment (alt) und Duplication (doppelt).
Eine eigene Art, wie ein Skill aufgerufen werden kann — ein Fall, den er behandelt, sodass Läufe verschiedene Pfade nehmen. Ein linearer Skill hat keine.
Ein kompakter Begriff aus dem Vortraining, mit dem der Agent denkt (z. B. lesson, tracer bullets). Als Token wiederholt, nie als Satz, verankert er Verhalten in wenigen Tokens. Erst ein bekanntes Wort suchen, bevor du eins erfindest.
Die Bedingung, die dem Agenten sagt: fertig. Ihre Klarheit (done vs. nicht-done) bremst Premature Completion; ihre Forderung (wie viel) setzt die Legwork. Die stärksten sind prüfbar und erschöpfend.
Die Arbeit hinter den Kulissen innerhalb eines Steps — Dateien lesen, Codebase erkunden, selbst graben statt an den Nutzer abzugeben. Steht nie als eigener Step, liegt latent in der Formulierung. Angehoben durch ein Leitwort (gründlich) oder ein forderndes Kriterium.
Die Steps, die auf den aktuellen folgen. Sichtbar, ziehen sie den Agenten vorwärts in Premature Completion — je mehr er sieht, desto stärker der Sog. Abwehr: Sequenz teilen und sie verbergen.
Einen Step beenden, bevor er wirklich fertig ist — die Aufmerksamkeit rutscht zum „Fertigsein". Tauziehen zwischen sichtbaren Folge-Steps (Sog) und der Klarheit des Kriteriums (Widerstand). Erst das Kriterium schärfen, dann ggf. Folge-Steps verbergen.
Der Sollzustand: jede Bedeutung lebt an genau einer maßgeblichen Stelle — eine Verhaltensänderung ist eine Änderung an einem Ort. Duplication ist ihr Verstoß.
Dieselbe Bedeutung mit mehr als einer Source of Truth. Kostet Wartung, Tokens und bläht die Prominenz auf. Das versehentliche Gegenteil eines Leitworts.
Ob eine Zeile noch etwas zum Skill beiträgt — die Linse fürs Behalten. Verloren, wenn sie nie zur Aufgabe beiträgt oder veraltet. Kürzere Skills bleiben leichter relevant.
Schichten alten Inhalts, die sich absetzen und nie geräumt werden — weil Hinzufügen sicher, Entfernen riskant wirkt. Das Standard-Schicksal jedes Skills ohne Pruning-Disziplin.
Eine Anweisung, die nichts ändert, weil das Modell es ohnehin tut — du zahlst Load, um dem Agenten zu sagen, was er sowieso täte. Der Test: ändert die Zeile das Verhalten gegenüber dem Default? Auch der Gradmesser für ein Leitwort.
Alles dient Predictability. Invocation entscheidet, wer welche Last trägt; Hierarchy, wo Inhalt sitzt; Steering, wie der Agent handelt; Pruning hält alles schlank.
Sieh dir diese drei Punkte morgen 2 Minuten noch einmal an — einmal aus dem Kopf abrufen bringt mehr als dreimal nachlesen. Als Merkzettel: den Prompt-Spickzettel ausdrucken ↓.