Skill: Anchor Prior Test

Ein Anker bringt nur dann Hebelwirkung, wenn der Begriff bereits ein dichter, vorberechneter Prior in den Trainingsdaten ist. Diese Dichte ist nicht dasselbe wie Qualität.

Eine junge, sorgfältig ausgearbeitete Methode kann ein schwacher Anker sein, weil wenige darüber geschrieben haben. Schlimmer noch: Das Modell räumt die Lücke selten ein. Es schiebt stillschweigend das nächstgelegene Konzept unter, das es kennt, und antwortet mit voller Überzeugung. Stille Substitution unter einer selbstsicheren Überschrift ist die Signatur eines fehlenden Priors — und sie bleibt unsichtbar, solange man nicht gezielt danach sucht.

Der Skill misst deshalb Dichte, nicht Verdienst. Ein schwaches Ergebnis ist kein Urteil über die Methode; es leitet den Begriff zu einem Semantic Contract um, der seine Bedeutung im Text selbst mitliefert und nicht darauf angewiesen ist, dass das Modell etwas weiß.

Die Proben müssen in einem Prozess laufen, der nichts vom Kontext dieses Projekts enthält. Sonst macht das projekteigene CLAUDE.md — das die geprüften Begriffe bereits definiert — die Antwort zirkulär.

--setting-sources "" verwirft Benutzer- und Projektkonfiguration einschließlich Memory, das neutrale Arbeitsverzeichnis verhindert, dass ein CLAUDE.md den Verzeichnisbaum hinauf gefunden wird, und --strict-mcp-config schaltet Werkzeuge ab, damit das Modell allein aus dem Training antwortet.

Sub-Agents können das nicht leisten. Ein Sub-Agent erbt den Kontext der Elternsitzung, eingefroren beim Start, und zitiert bereitwillig die projekteigenen Contracts zurück, als wären sie Allgemeinwissen. Dateien mitten in der Sitzung zu verschieben hilft nicht, weil der Schnappschuss längst genommen ist. Nur ein frisch gestarteter Prozess liest die — nun abwesenden — Dateien von der Platte. Den Reinraum einmal je Sitzung prüfen, indem man das Modell fragt, ob es Custom Instructions geladen hat; die Antwort muss „none" lauten.

Vier Probentypen, jeder endet auf einer maschinenlesbaren SELF:-Zeile, damit sich Ergebnisse tabellieren lassen, ohne die Prosa erneut zu lesen. Die entscheidenden Proben laufen mindestens zweimal je Stufe, denn ein einzelner auffälliger Lauf ist eine Anekdote.

Die schwache Stufe ist die aussagekräftigste. Ein starker Anker trägt auch dort.

Eine Probe allein zeigt, dass das Modell die Aufgabe lösen kann. Sie zeigt nicht, dass der Begriff etwas dazu beigetragen hat. Dieselbe Aufgabe muss deshalb einmal ohne Anker laufen, und beide Ausgaben werden verglichen.

Das geht leicht schief. Im Lauf unten nannte die erste Baseline die erwarteten Merkmale in ihrer eigenen SELF:-Zeile — und verriet dem Modell damit, was es produzieren sollte. Der ankerlose Lauf lieferte die Struktur pflichtschuldig, und der gemessene Hebel war null. Die Baseline muss neutral bleiben, sonst misst sie den Prompt statt den Prior.

Zwei Kandidaten, getestet am 14.08.2026 gegen claude-haiku-4-5-20251001, claude-sonnet-5 und claude-opus-5.

Premortem besteht glatt. Sechs von sechs Läufen erkennen den Begriff, sechs von sechs erzeugen die charakteristische Bewegung — das Scheitern als eingetreten annehmen und rückwärts zu den Ursachen arbeiten:

Die neutrale Baseline lieferte bei identischer Aufgabe eine vorwärtsgerichtete Machbarkeitseinschätzung mit Risikoliste und imaginierte nie ein Scheitern. Dieser Unterschied ist der Beitrag des Ankers, sichtbar in einem Satz.

Second-Order Thinking ist der interessantere Fall, weil die Belege der Bibliografie widersprechen.

Die Primärquellen verwenden den Begriff nicht. Howard Marks stellt in The Most Important Thing (2011) „first-level" und „second-level thinking" gegenüber. Ray Dalio schreibt von „second- and third-order consequences". Keiner sagt „second-order thinking"; diese Fassung ist der Sammelbegriff der Popularisierer. Der bibliografisch treue Name wäre Second-Level Thinking.

Beide Namen zu testen hat es entschieden:

Der Action-Test trennt die beiden nicht. Die Trennung liegt auf der schwachen Stufe, und sie reproduziert sich: Bei „second-level thinking" erkennt das schwache Modell die Wortfolge, rekonstruiert sie aber generisch und erwähnt weder Marks noch das Investment-Umfeld ein einziges Mal. Bei „second-order thinking" greift es nicht ins Ungefähre.

Der Katalog nimmt deshalb den Namen, der stärker misst, führt den anderen als Alias und belegt die Linie im Text. Das Verfahren misst Dichte, nicht Verdienst — und hier zeigen beide in verschiedene Richtungen.

Eine Kriterienmatrix (vier Kriterien × Modellstufe), eine Einschätzung der Prior-Dichte, eine Tier-Bewertung und eine Route.

Testergebnisse werden je Anker festgehalten, nicht stillschweigend ins Tier eingerechnet. Ein Anker trägt ein :prior-test:-Datum; das Prior-Test-Register hält den Lauf hinter diesem Datum — aufgelöste Modell-IDs, Verfahrensversion, Anzahl der Läufe, die Kriterienmatrix und wörtliche Belegzitate.

Der Grund: Modell-Aliase sind bewegliche Ziele. „Getestet auf haiku" sagt ein Jahr später nichts mehr, und selbst aufgelöste IDs sind nur teilweise gepinnt — claude-haiku-4-5-20251001 trägt ein Datum, claude-opus-5 nicht. Erst Datum plus aufgelöste IDs machen die Aussage prüfbar, und eine Aussage, die sich nicht prüfen lässt, gehört nicht in die Dokumentation.

Der Skill liegt im Plugin semantic-anchors neben den übrigen Skills. Die AgentSkill-Seite beschreibt die Installation für Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI und kompatible Agenten.