Gute Prompts
Ein Agent ist nur so gut wie sein Auftrag. Hier lernst du, wie du klar formulierst, Grenzen setzt und das Format vorgibst — die Fähigkeit, auf der Tag 1 und Tag 2 aufbauen.
Neu hier? Lern zuerst Hermes kennen — Hermes-Basics. Dann machen wir hier deine Prompts gut, lassen dich grillen (/grill-me) und am Ende baust du deinen ersten eigenen Skill.
Die 4 Bausteine
Ein starker Prompt beantwortet vier Fragen. Nicht immer brauchst du alle vier — aber je mehr davon klar sind, desto besser das Ergebnis.
Wer bist du, worum geht es? „Für unser Urban-Sports-Festival in Berlin …“
Was genau soll passieren? Ein Verb. „Finde …“, „Vergleiche …“, „Schreibe …“.
Anzahl, Budget, Ausschlüsse, Ton. „Max 3, Budget ≥ 80k, keine Wettanbieter.“
Wie soll die Antwort aussehen? „Als Tabelle“, „in 3 Sätzen“, „mit Pitch-Hook“.
Kontext · Aufgabe · Grenzen · Format. Wenn dein Ergebnis daneben liegt, fehlt fast immer einer dieser vier Bausteine.
Für unser Urban-Sports-Festival von Yellow Bee in Berlin (Zielgruppe 16–25). Aufgabe: Finde passende Sponsoring-Partner. Grenzen: Genau 3, Budget ≥ 80k, keine Wettanbieter. Format: Als Tabelle mit Fit-Score und einem Pitch-Satz je Partner.
Die grünen Punkte zeigen, welche Bausteine schon drin sind. → Genau so startest du an Tag 1.
Klar schlägt vage
Derselbe Wunsch, zwei Prompts. Der zweite spart dir drei Nachfragen — weil er alle vier Bausteine liefert.
/sponsoring-scout Finde 3 Tier-A Partner für Formel-E in der DACH-Region. Budget mindestens 80k, keine Wettanbieter. Als Tabelle mit Fit-Score.Testfrage — Welche Bausteine fehlen dem vagen Prompt?
Grenzen geben Kontrolle
Constraints sind keine Einschränkung — sie sind Steuerung. Vier Typen decken fast alles ab.
Ein guter Agent erfüllt widersprüchliche Grenzen nicht heimlich, sondern meldet es — z. B. wenn es keine 3 Leads über 80k gibt. Das ist gewollt, kein Fehler.
/content-pipeline TikTok-Script für Jonas Meier nach dem Sieg in Berlin. Hook in den ersten 3 Sekunden, max 60 Wörter, keine Gesundheitsversprechen.Sag, wie es aussehen soll
Das Format entscheidet, ob du das Ergebnis direkt weiterverwenden kannst. Nenne es explizit — der Agent liefert genau das.
/reporting-agent Erstelle den Marketing-Weekly für W26. Format: Executive Summary (3 Sätze), KPI-Tabelle, Alerts als Bullets.Testfrage — Warum lohnt sich eine Format-Angabe?
Der erste Prompt ist ein Entwurf
Gute Ergebnisse entstehen selten beim ersten Versuch. Nachschärfen ist normal — und schnell.
Sei konkret bei der Korrektur: nicht „besser“, sondern „kürzer / sachlicher / mit Quelle“. Der Agent hält den Kontext — du musst nicht alles wiederholen.
Häufige Fehler — kurz gecheckt
- Zu vage: „Mach was Gutes“ — es fehlen Aufgabe, Grenzen, Format.
- Zu viel auf einmal: fünf Aufgaben in einem Prompt. Lieber Schritt für Schritt.
- Keine Quelle genannt: dann rät der Agent — sag, welche Datei die Wahrheit ist.
- Kein Format: du bekommst Fließtext statt Tabelle.
Meisterklasse: Gute Skills schreiben
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 ↗
Ein Skill ist gut, wenn der Agent bei jedem Lauf denselben Prozess geht — egal, was am Ende herauskommt. Dieses Prinzip heißt Vorhersagbarkeit.
Jeder Schritt endet an einem Kriterium, an dem der Agent done von nicht-done unterscheiden kann. Vage Kriterien laden zum vorzeitigen Abbruch ein.
Jeder Satz, der das Verhalten des Agenten nicht ändert, fliegt raus. Kürzer heißt hier zuverlässiger.
Was man nur manchmal braucht, wandert aus der SKILL.md in eine eigene Datei (z. B. GLOSSARY.md) — der Kern bleibt lesbar.
Bekannte Begriffe (z. B. „Source of Truth", „Executive Summary") verankern viel Verhalten in einem Wort — statt langer Erklärungen.
Jede Regel steht an genau einer Stelle. Doppelte Definitionen widersprechen sich früher oder später.
Model-invoked = der Agent findet den Skill selbst (kostet Kontext). User-invoked = nur du rufst ihn auf (du musst dran denken). Wähle bewusst.
mkdir -p ~/.hermes/skills/gute-skills-schreibenDie kopierte SKILL.md im neuen Ordner als SKILL.md speichern.
/gute-skills-schreiben Prüfe meinen /reporting-agent Skill auf Vorhersagbarkeit und schlage Kürzungen vor.---
name: gute-skills-schreiben
description: Prüft und verbessert Hermes-Skills auf Vorhersagbarkeit. Nutzen beim Schreiben oder Überarbeiten eines Skills.
disable-model-invocation: true
---
# Gute Skills schreiben
Ziel: Ein Skill ist gut, wenn der Agent bei jedem Lauf denselben PROZESS geht — egal, was am Ende herauskommt (= Vorhersagbarkeit).
## When to Use
Immer wenn du einen neuen Skill anlegst oder einen bestehenden überarbeitest.
## Procedure
1. Beschreibung schärfen: ein Satz, was der Skill tut, plus klare Trigger ("Nutzen, wenn ..."). Fertig, wenn allein an der Beschreibung erkennbar ist, wann der Skill greift.
2. Schritte ordnen: jeder Schritt ist eine Handlung und endet an einem PRÜFBAREN Kriterium (done vs. nicht-done). Fertig, wenn kein Schritt mit "ungefähr" endet.
3. Referenz auslagern: Regeln/Fakten, die man nur manchmal braucht, in eine eigene Datei (progressive disclosure). Fertig, wenn die SKILL.md auch ohne die Referenz lesbar ist.
4. Leitworte nutzen: bekannte Begriffe statt langer Erklärungen (z. B. "Source of Truth"). Fertig, wenn jeder Fachbegriff Text spart.
5. No-ops streichen: jeden Satz löschen, der das Verhalten nicht ändert. Fertig, wenn kein Satz mehr weg kann, ohne das Ergebnis zu ändern.
6. Single Source of Truth: jede Regel steht an genau einer Stelle. Fertig, wenn nichts doppelt definiert ist.
## Verification
- Beschreibung: erkennbar, wann der Skill greift?
- Jeder Schritt: prüfbares Abschluss-Kriterium?
- SKILL.md ohne Referenzdatei lesbar?
- Kein No-op, keine Doppelung?
# Inspiriert von Matt Pococks "writing-great-skills"
# github.com/mattpocock/skills
Die vollständige Original-SKILL.md aus dem Repo — die Definitionen stehen ausgelagert in einer GLOSSARY.md (siehe Glossar unten). Faithful eingebaut, kopierbar für Hermes.
---
name: writing-great-skills
description: Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.
disable-model-invocation: true
---
A skill exists to wrangle determinism out of a stochastic system. **Predictability** — the agent taking the same _process_ every run, not producing the same output — is the root virtue; every lever below serves it.
**Bold terms** are defined in `GLOSSARY.md`; look them up there for the full meaning.
## Invocation
Two choices, trading different costs:
- A **model-invoked** skill keeps a **description**, so the agent can fire it autonomously _and_ other skills can reach it (you can still type its name too). It contributes to **context load** — the description sits in the window every turn. Mechanics: omit `disable-model-invocation`, and write a model-facing description with rich trigger phrasing ("Use when the user wants…, mentions…").
- A **user-invoked** skill strips the description from the agent's reach: only you, typing its name, can invoke it — and no other skill can. Zero context load, but it spends **cognitive load**: _you_ are the index that must remember it exists. Mechanics: set `disable-model-invocation: true`; the `description` becomes human-facing — a one-line summary, trigger lists stripped.
Pick model-invocation only when the agent must reach the skill on its own, or another skill must. If it only ever fires by hand, make it user-invoked and pay no context load.
When user-invoked skills multiply past what you can remember, that piled-up cognitive load is cured by a **router skill**: one user-invoked skill that names the others and when to reach for each.
## Writing the description
A model-invoked **description** does two jobs — state what the skill is, and list the **branches** that should trigger it. Every word increases **context load**, so a description earns even harder pruning than the body:
- **Front-load the skill's leading word** — the description is where it does its invocation work.
- **One trigger per branch.** Synonyms that rename a single branch are **duplication**. Collapse them; keep only genuinely distinct branches.
- **Cut identity that's already in the body.** Keep the description to triggers, plus any "when another skill needs…" reach clause.
## Information hierarchy
A skill is built from two content types — **steps** and **reference** — that mix freely. The core decision is which to use and where each sits on the **information hierarchy**, a ladder ranked by how immediately the agent needs the material:
1. **In-skill step** — an ordered action in `SKILL.md`, the primary tier. Each step ends on a **completion criterion**. Make it _checkable_ and, where it matters, _exhaustive_ ("every modified model accounted for", not "produce a change list") — a vague criterion invites **premature completion**.
2. **In-skill reference** — a definition, rule, or fact in `SKILL.md`, consulted on demand. Often a legitimately flat peer-set — a fine arrangement, not a smell. _This skill is all reference._
3. **External reference** — reference pushed out of `SKILL.md` into a separate file, reached by a **context pointer**, loaded only when the pointer fires.
A demanding completion criterion drives thorough **legwork** — the digging the agent does within the work — whether the skill has steps or not.
Push too little down and the top bloats; push too much and you hide material the agent actually needs. That tension is the whole decision.
**Progressive disclosure** is the move down the ladder — out of `SKILL.md` into a linked file — so the top stays legible. Some skills are used in more than one way, and each distinct way is a **branch**. Branching is the cleanest disclosure test: inline what every branch needs, and push behind a pointer what only some branches reach. A **context pointer**'s _wording_, not its target, decides when and how reliably the agent reaches the material.
Where the ladder decides _how far down_ a piece sits, **co-location** decides _what sits beside it_ once there: keep a concept's definition, rules, and caveats under one heading.
## When to split
**Granularity** is how finely you divide skills, and each cut spends one of the two loads, so split only when the cut earns it. Two cuts:
- **By invocation** — split off a **model-invoked** skill when you have a distinct **leading word** that should trigger it on its own. You pay **context load** for the new always-loaded **description**.
- **By sequence** — split a run of **steps** when the steps still ahead (a step's **post-completion steps**) tempt the agent to rush the one in front of it (**premature completion**).
## Pruning
Keep each meaning in a **single source of truth**: one authoritative place, so changing the behaviour is a one-place edit.
Check every line for **relevance**: does it still bear on what the skill does?
Then hunt **no-ops** sentence by sentence: run the no-op test on each sentence in isolation, and when one fails, delete the whole sentence rather than trim words from it. Be aggressive.
## Leading words
A **leading word** is a compact concept already living in the model's pretraining that the agent thinks with while running the skill (e.g. _lesson_, _fog of war_, _tracer bullets_). Repeated throughout the text, it accumulates a distributed definition and anchors a whole region of behaviour in the fewest tokens.
It serves predictability twice. In the body it anchors _execution_. In the description it anchors _invocation_: when the same word lives in your prompts, docs, and code, the agent links that shared language to the skill and fires it more reliably.
## Failure modes
- **Premature completion** — ending a step before it's genuinely done. Defence, in order: sharpen the completion criterion first; only if it is irreducibly fuzzy _and_ you observe the rush, hide the post-completion steps by splitting.
- **Duplication** — the same meaning in more than one place. Costs maintenance and tokens.
- **Sediment** — stale layers that settle because adding feels safe and removing feels risky.
- **Sprawl** — a skill simply too long. The cure is the ladder: disclose reference behind pointers, split by branch or sequence.
- **No-op** — a line the model already obeys by default. The test: does it change behaviour versus the default?
Testfrage — Warum macht „Fertig, wenn ..." einen Schritt besser?
Die wichtigsten Skills für Einsteiger — ohne Code
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.
Ein gnadenloses Interview, das deinen Plan schärft, bevor gebaut wird.
Schließt die Lücke zwischen dir und dem Agenten — das häufigste Fehlerbild #1: „hat nicht gemacht, was ich wollte".
Vor jeder Änderung. Ruft die wiederverwendbare grilling-Schleife auf.
---
name: grill-me
description: A relentless interview to sharpen a plan or design.
disable-model-invocation: true
---
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
If a question can be answered by exploring the codebase, explore the codebase instead.
Bringt dir ein Thema über mehrere Sitzungen bei — der aktuelle Ordner wird zum Lern-Workspace (Mission, Lektionen, Referenzen).
Ideen und Wissen entwickeln statt Code — grounded in vertrauenswürdigen Quellen, nicht im Bauchgefühl des Modells.
Wenn du etwas Neues lernen oder ein Konzept wirklich durchdringen willst.
---
name: teach
description: Teach the user a new skill or concept, within this workspace.
disable-model-invocation: true
argument-hint: "What would you like to learn about?"
---
The user has asked you to teach them something. This is a stateful request — they intend to learn the topic over multiple sessions.
## Teaching Workspace
Treat the current directory as a teaching workspace. Learning state lives in:
- MISSION.md — the _reason_ the user wants the topic; grounds all teaching.
- ./reference/*.html — compressed learnings (cheat sheets, glossaries), beautiful and print-friendly.
- RESOURCES.md — trusted resources to ground teaching in real knowledge.
- ./learning-records/*.md — key insights (like ADRs); drive future sessions and the zone of proximal development.
- ./lessons/*.html — the primary unit: one self-contained, beautiful lesson per file (0001-name.html).
- ./assets/* — reusable components shared across lessons.
- NOTES.md — user preferences and working notes.
## Philosophy
Deep learning needs three things: **Knowledge** (from high-trust resources — never trust parametric knowledge), **Skills** (acquired through interactive lessons), **Wisdom** (from real-world practice and community).
Split fluency (in-the-moment recall) from storage strength (long-term retention). Build retention with desirable difficulty: retrieval practice, spacing, interleaving.
## Lessons
A lesson is short, completable quickly, tied to the mission, and in the user's zone of proximal development — one tangible win to build on. Make it beautiful (think Tufte); link to other lessons and references; recommend one primary source; remind the user they can ask the agent (their teacher) follow-ups.
## The Mission
Every lesson ties to the mission — the reason the user is learning. If MISSION.md is empty, your first job is to question the user on why they want to learn this. Missions may change; update MISSION.md and add a learning record (confirm with the user first).
## Knowledge vs Skills
For knowledge, difficulty is the enemy — teach only what the skill needs. For skills, difficulty is the tool — effortful retrieval builds durability, via tight interactive feedback loops.
## Reference & Glossaries
Create reference documents alongside lessons — the compressed essence, for quick review. A glossary, once created, is adhered to in every lesson.
Verdichtet das aktuelle Gespräch in ein Übergabe-Dokument, das ein frischer Agent aufgreifen kann.
Wissen zwischen Sessions und Agenten weiterreichen, ohne dass Kontext verloren geht.
Am Ende einer langen Session oder wenn ein anderer Agent weitermachen soll.
---
name: handoff
description: Compact the current conversation into a handoff document for another agent to pick up.
argument-hint: "What will the next session be used for?"
disable-model-invocation: true
---
Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS — not the current workspace.
Include a "suggested skills" section in the document, which suggests skills that the agent should invoke.
Do not duplicate content already captured in other artifacts (PRDs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.
Redact any sensitive information, such as API keys, passwords, or personally identifiable information.
If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.
Ein Router über deine anderen Skills — du nennst dein Ziel, er verweist auf den passenden.
Löst die Einsteigerfrage schlechthin: „Ich weiß nicht, welchen Skill ich brauche." Einer zum Merken statt vieler.
Immer, wenn du unsicher bist, wo du anfangen sollst.
---
name: wegweiser
description: Welcher Skill passt zu meiner Aufgabe? Ein Router über die user-invoked Skills.
disable-model-invocation: true
---
# Wegweiser
Du merkst dir nicht jeden Skill — also frag. Nenne dein Ziel, ich verweise auf den passenden Skill und sage, warum.
## Der Hauptweg: Idee -> Ergebnis
1. **/grill-me** — schärfe die Idee im Interview. Immer hier starten, wenn noch etwas unklar ist.
2. **/teach** — wenn dir Wissen fehlt, um zu entscheiden: lass dir das Thema erst beibringen.
3. **Umsetzen** — bau den Prompt nach den 4 Bausteinen (Kontext · Aufgabe · Grenzen · Format) und ruf den passenden Yellow-Bee-Skill auf (z. B. /sponsoring-scout, /content-pipeline, /reporting-agent).
## Sitzungen verbinden
- **/handoff** — Gespräch zu voll oder Wechsel nötig? Verdichte es in ein Übergabe-Dokument und mach in einer frischen Session weiter.
## Eigene Skills bauen
- **/writing-great-skills** — Referenz zum Schreiben und Überarbeiten eigener Skills (Vorhersagbarkeit).
## Standalone
- **/teach** — ein Konzept über mehrere Sessions lernen, im aktuellen Ordner als Workspace.
# Prinzip von Matt Pococks "ask-matt" — auf die code-freien Skills zugeschnitten.
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.
Glossar · Gute Skills
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.