Survival toolbox: building your own skill system for working with virtual colleagues#

For anyone starting to hand real work to an AI agent — a virtual colleague — who wants the same thing to come out twice. Written for product owners, sales, business analysts, HR, people new to the field, and anyone who started with vibe-coding. You do not need to be able to program.

The examples come from different roles, one per layer. Where there are figures and studies, they have moved into their own section at the end — the whole series can be applied without reading it.

In three minutes#

The problem. With an AI agent a result arrives in minutes and looks good. But the second time something different comes out, and afterwards nobody can say why. For a demo that is fine. For something that carries everyday work it is not.

The cause. The agent has no memory of what you are building and no idea what counts as "right" where you work. Both have to be written down somewhere — otherwise it guesses again every time.

The answer is not a tool. It is a small stack of files. Five kinds, built in this order:

Only number 2 holds by itself. Everything else is an agreement — valuable, and voluntary.

What you do today. Open an empty file, call it AGENTS.md, and write three sentences in it that apply to every job. Ideally three prohibitions — things you have already watched go wrong. That is layer 1, and it takes ten minutes.

If you want to carry on after that: layer 2 is the only one that really holds, which is why it comes second.

The series#

Each layer page reads in four minutes and has the same shape: in one sentence · an example · what you do today · what it is made of · what it cannot do · what goes wrong · done when.

Why you need this at all#

Producing output has become easy. A paragraph of text, a piece of code, a draft campaign — minutes, and it looks good. That is enough to get attention. For everything after that, it is not enough.

Because a product or a process that carries everyday value asks for something other than a good result. It asks for the same good result again — next week, started by somebody else, in a state nobody holds in their head any more. Vibe-coding puts a pretty, running prototype in front of you in an hour; the distance from there to something you hand a customer is the actual work. Outside software it is the same: a presentation takes an hour, a quoting process three people can run without asking anyone does not.

The effort did not disappear. It moved — from producing to checking, to a place nobody had staffed. That is measured; the figures are further down under What is actually evidenced.

Three things stand in the way#

Against the first two there is little to build; they are properties of the tools and will improve or not. The third is different. That is exactly where a written way of working changes the outcome — and it is the only thing this series is about.

"Consistent" here means nothing grand: that a recurring job runs the same way twice, that what was supposed to happen stays reconstructable, and that somebody who was not there can hold the result against it.

The destination — and the measured distance to it#

It is built for a way of working in which virtual and real colleagues work on the same product — with product owners who decide and providers who deliver. That is a destination, not a description of something finished, and this series does not treat the role model.

What it can do is hold the destination against actual experience. Of the ten topics such a way of working has to cover, exactly two sit only in the weakest layer — who may hand over what, and who may decide without asking (the completeness test). The two that would have to carry the collaboration stand on nothing but goodwill. And in the collection this series comes from, 36 of 60 written procedures had never once been used (the measurement).

The destination stays the destination; the distance to it is measured rather than asserted.

The order#

Build 1 and 2 first. Most people start at 3, because writing a procedure down is the enjoyable part, and arrive at 2 only after something escapes. If you build only two, build 1 and 2: one prohibition plus one check that fires is a working toolbox. Three procedures and no check are a folder.

From layer to artefact#

The five layers are categories, not files. Here is what they become when they land — in three pictures rather than one, because eleven artefacts drawn side by side come out too small to read.

Layers 1 and 2 — the two you build first.

Both pairs are deliberate. The check appears twice, because a check in exactly one place is not a check: one runs on your machine, the other centrally — and only the central one cannot be skipped. The rule file appears twice for a different reason: the file in the project and the one covering all projects can say different things, and the nearer one wins.

Layers 3 and 4 — what the work runs on, and what it leaves behind.

The record has three artefacts rather than one, because "what was supposed to happen" accrues on three timescales: per job, per working session, per decision.

Layer 5 — what keeps the other four findable.

Those three exist for the other four: the one command that searches everything, the list it produces, and an archive you can come back out of.

What an artefact is made of#

The procedure file's seven building blocks are only named here. They are explained exactly once, in layer 3 — the same rule layer 5 states, applied here to the series itself. A second explanation would be a copy, and copies drift apart.

Where a layer has no file name, you do not have that layer. It is the cheapest self-test in the series.

What is actually evidenced#

This section is built to be skipped. Anyone applying the series does not need it; anyone who wants to know what it rests on will find the figures here, with their limits attached.

The effort moved. A longitudinal study of 802 developers and 196,212 pull requests found throughput at 2.09× — and alongside it, per-reviewer load roughly doubled while automated review overtook human review. Output doubled. The reviewing doubled with it. Then the reviewing itself was handed to machines.

Memory. Long conversations do not fail at the boundary; they degrade well before it. Once literal keyword overlap is removed from the task, 11 of 13 models fall below half their own short-context baseline at 32K. And the memory architectures sold as the answer have not fixed it — in one vendor's own evaluation, simply pasting the raw conversation outscored every system tested, including their own.

The unreliability. The word "consistency" does not appear in this area's source texts. The thing itself is measured anyway: spreading one instruction over several conversational turns costs 39% on average — of which only −16% is aptitude, while unreliability rises 112%. And 1,000 completions at temperature 0 produced 80 distinct outputs.

What written rules do — and do not do. They do not make an agent more capable, and what they cost is contested. One controlled evaluation of repository context files found they did not generally improve success rates while raising cost by over 20%; a second study, measuring the same kind of file purely as an efficiency mechanism, found the opposite sign — 16.58% fewer output tokens and 28.64% less wall clock. Two preprints, two different setups, opposite results. The disagreement is not resolved here; both are set out side by side, with their scopes attached, in testing a rule.

What rules do govern is behaviour under conflict, and there the effect is large — removing a single consent clause moved destructive out-of-scope actions from 0.0% to 17.1%. Read that number for what it is: it compares a rule being present against it being absent, not one wording against another. It therefore supports a narrower point than it looks like it does — a rule naming a recognisable action ("never push to main") is easier to apply in the moment than one naming a virtue ("always work cleanly"), because you can tell whether you are about to do it. That is an argument about recognisability, not about compliance rates.

Alongside it, answering a different question, there is a measurement. A large-scale controlled study of agent rule files — 679 scraped from GitHub, 25,532 rules, over 5,000 agent runs on SWE-bench Verified — reports that in its data every rule that improved task performance on its own was a prohibition ("do not refactor unrelated code"), and every rule that hurt it was a positive directive ("follow code style") (Guardrails Beat Guidance, arXiv:2604.11088). Two things in the same paper take the lever away from that. "In our data" means rules classified as they were found in the wild; nobody wrote the same rule both ways and compared. And randomly generated rules helped as much as expert-curated ones, +13.8 pp either way — an effect the authors call largely content-independent. Polarity is a real seam in that corpus. It is not a large lever, and it is about performance, not about whether a rule is obeyed.

That leaves three findings on three axes, easy to collapse into one another. Form — how a rule is encoded, compact header against verbose prose — has no measurable effect (Compact Constraint Encoding, arXiv:2604.07192). Polarity comes apart in the corpus above. Opposing what the model would do anyway outweighs both: in that same encoding study, constraints running against the model's defaults failed 10–100 % of the time where conventional ones held at 99 %+. None of the three measures recognisability — whether a person or an agent can tell, in the moment, that a rule applies. As of 2026-09-04, across the sources listed in this area's introduction, we found nothing that measures it; that argument is reasoning, not measurement. All three, with their limits, are in testing a rule.

Neither rules nor checks contain what was meant. Rules shape what the agent is inclined to do; checks constrain what it is able to do. Together they are the best available — which is not the same as enough.

All figures and their sources are given in full in this area's introduction↗.

Caveats#

• None of this makes the agent more capable. What the toolbox buys is predictability — a different and, for handing work over, more useful property.
• The technology dates fast. File names and tools have a short shelf life; the layer model outlives them, the syntax does not.
• This is one repository and one working style. No study, no comparison, no claim that the order is optimal.
• The toolbox is not a guarantee. It makes work predictable and checkable. It does not make it correct.

Open#

References#

• Agentic development — the introduction to this area↗ (this repository)
• Agentic programming: what did not survive checking↗ (this repository)
• Agent session lifetime and compaction↗ (this repository)
• External sources: the studies quoted in §2.2 are cited in full in the introduction's own reference list; anything cited newly in this series must be opened and dated before the draft ships.

Survival-Toolbox: das eigene Skill-System für die Arbeit mit virtuellen Mitarbeitern bauen#

Für alle, die anfangen, echte Arbeit an einen KI-Agenten zu übergeben — an einen virtuellen Mitarbeiter — und wollen, dass dabei zweimal dasselbe herauskommt. Geschrieben für Product Owner, Sales, Business Analysten, HR, Berufsanfänger und alle, die mit Vibe-Coding angefangen haben. Programmieren muss man dafür nicht.

Die Beispiele stammen aus verschiedenen Rollen, eines pro Schicht. Wo Zahlen und Studien stehen, sind sie in einen eigenen Abschnitt am Ende gewandert — man kann die ganze Reihe anwenden, ohne ihn zu lesen.

In drei Minuten#

Das Problem. Mit einem KI-Agenten ist ein Ergebnis in Minuten da und sieht gut aus. Aber beim zweiten Mal kommt etwas anderes heraus, und niemand kann hinterher sagen, warum. Für eine Demo reicht das. Für etwas, das im Alltag trägt, nicht.

Die Ursache. Der Agent hat kein Gedächtnis für euer Vorhaben und keine Vorstellung davon, was bei euch als „richtig" gilt. Beides muss irgendwo stehen — sonst rät er es jedes Mal neu.

Die Lösung ist kein Werkzeug, sondern ein kleiner Stapel Dateien. Fünf Sorten, in dieser Reihenfolge gebaut:

Nur Nummer 2 hält von allein. Alles andere ist eine Absprache — wertvoll, aber freiwillig.

Was du heute tust. Öffne eine leere Datei, nenne sie AGENTS.md, und schreib drei Sätze hinein, die für jede Aufgabe gelten. Am besten drei Verbote — Dinge, die du schon einmal schiefgehen gesehen hast. Das ist Schicht 1, und sie ist in zehn Minuten fertig.

Wenn du danach weitermachen willst: Schicht 2 ist die einzige, die wirklich hält, und deshalb kommt sie als zweite.

Die Reihe#

Jede Schichten-Seite ist in vier Minuten gelesen und hat denselben Aufbau: in einem Satz · ein Beispiel · was du heute tust · woraus sie besteht · was sie nicht kann · was schiefgeht · fertig, wenn.

Warum es ohne nicht geht#

Ergebnisse zu erzeugen ist leicht geworden. Ein Absatz Text, ein Stück Code, ein Kampagnenentwurf — Minuten, und es sieht gut aus. Das reicht, um Aufmerksamkeit zu wecken. Für alles danach reicht es nicht.

Denn ein Produkt oder ein Prozess, der im Alltag Wert trägt, verlangt etwas anderes als ein gutes Ergebnis. Er verlangt dasselbe gute Ergebnis noch einmal — nächste Woche, von jemand anderem angestossen, in einem Zustand, den niemand mehr im Kopf hat. Per Vibe-Coding steht ein hübscher, lauffähiger Prototyp in einer Stunde; die Strecke von dort zu etwas, das man einem Kunden gibt, ist die eigentliche Arbeit. Ausserhalb der Software ist es dasselbe: eine Präsentation ist in einer Stunde erzeugt, ein Angebotsprozess, den drei Leute ohne Rückfrage bedienen können, nicht.

Der Aufwand ist nicht verschwunden. Er ist umgezogen — vom Erzeugen zum Prüfen, an eine Stelle, für die niemand Personal eingeplant hat. Das ist gemessen; die Zahlen stehen weiter unten unter Was davon belegt ist.

Drei Dinge stehen im Weg#

Gegen die ersten beiden kann man wenig bauen; sie sind Eigenschaften der Werkzeuge und werden besser oder nicht. Das dritte ist anders. Genau dort hilft eine aufgeschriebene Arbeitsweise — und nur darum geht es in dieser Reihe.

„Konsistent" heisst dabei nichts Grosses: dass eine wiederkehrende Aufgabe zweimal gleich läuft, dass nachvollziehbar bleibt, was passieren sollte, und dass jemand, der nicht dabei war, das Ergebnis dagegen halten kann.

Das Zielbild — und der gemessene Abstand dorthin#

Gebaut ist das für eine Arbeitsweise, in der virtuelle und echte Mitarbeiter am selben Produkt arbeiten — mit Product Ownern, die entscheiden, und Anbietern, die liefern. Das ist ein Zielbild, keine Beschreibung von etwas Fertigem, und das Rollenmodell behandelt diese Reihe nicht.

Was sie kann: das Zielbild an der eigenen Erfahrung messen. Von den zehn Themen, die eine solche Arbeitsweise abdecken muss, liegen ausgerechnet zwei nur in der schwächsten Schicht — wer was übergeben darf und wer ohne Rückfrage entscheiden darf (der Vollständigkeitstest). Genau die beiden, die eine Zusammenarbeit tragen müssten, stehen auf nichts als gutem Willen. Und in der Sammlung, aus der diese Reihe stammt, waren von 60 geschriebenen Abläufen 36 nie ein einziges Mal benutzt worden (die Messung).

Das Zielbild bleibt das Ziel; der Abstand dorthin ist gemessen und nicht behauptet.

Die Reihenfolge#

Baut 1 und 2 zuerst. Die meisten fangen bei 3 an, weil einen Ablauf aufzuschreiben der angenehme Teil ist, und kommen bei 2 erst an, nachdem etwas entwischt ist. Wer nur zwei baut, baut 1 und 2: ein Verbot plus eine Prüfung, die feuert, ist eine funktionierende Toolbox. Drei Abläufe und keine Prüfung sind ein Ordner.

Von der Schicht zum Artefakt#

Die fünf Schichten sind Kategorien, keine Dateien. Was daraus wird, wenn es landet — in drei Bildern statt einem, weil elf Artefakte nebeneinander zu klein werden, um sie zu lesen.

Schicht 1 und 2 — die beiden, die zuerst gebaut werden.

Beide Paare sind Absicht. Die Prüfung erscheint doppelt, weil eine Prüfung an genau einer Stelle keine ist: die eine läuft bei dir, die andere zentral — und nur die zentrale kann niemand überspringen. Die Regeldatei erscheint doppelt aus einem anderen Grund: die Datei im Projekt und die für alle Projekte können Verschiedenes sagen, und die nähere gewinnt.

Schicht 3 und 4 — worauf die Arbeit läuft und was sie hinterlässt.

Der Nachweis hat drei Artefakte statt einem, weil „was hätte passieren sollen" auf drei Zeitskalen anfällt: pro Aufgabe, pro Arbeitssitzung, pro Entscheidung.

Schicht 5 — was die anderen vier auffindbar hält.

Diese drei sind für die anderen vier da: der eine Befehl, der alles durchsucht, die Liste, die er erzeugt, und ein Archiv, aus dem man wieder herauskommt.

Woraus ein Artefakt besteht#

Die sieben Bausteine der Ablauf-Datei stehen hier nur mit Namen. Erklärt werden sie genau einmal, in Schicht 3 — dieselbe Regel, die Schicht 5 aufstellt, hier auf die Reihe selbst angewandt. Eine zweite Erklärung wäre eine Kopie, und Kopien driften auseinander.

Wo eine Schicht keinen Dateinamen hat, hat man sie nicht. Das ist der billigste Selbsttest der ganzen Reihe.

Was davon belegt ist#

Dieser Abschnitt ist zum Überspringen gebaut. Wer die Reihe anwenden will, braucht ihn nicht; wer wissen will, worauf sie sich stützt, findet hier die Zahlen mit ihren Einschränkungen.

Der Aufwand ist umgezogen. Eine Längsschnittstudie über 802 Entwickler und 196.212 Pull Requests fand den Durchsatz bei 2,09× — und daneben die Prüflast pro Prüfer ungefähr verdoppelt, während automatische Prüfung die menschliche überholte. Die Ausgabe verdoppelte sich, das Prüfen verdoppelte sich mit, und dann wurde das Prüfen selbst an Maschinen abgegeben.

Das Gedächtnis. Lange Gespräche versagen nicht an der Grenze, sondern lange davor: sobald wörtliche Stichwortüberlappung aus der Aufgabe entfernt wird, fallen 11 von 13 Modellen bei 32K unter die Hälfte ihres eigenen Kurzkontext-Werts. Und die als Antwort verkauften Gedächtnis-Architekturen haben es nicht behoben — in der Auswertung eines Anbieters schlug das blosse Einfügen des Rohgesprächs jedes geprüfte System, das eigene eingeschlossen.

Die Unzuverlässigkeit. Das Wort „Konsistenz" kommt in den Quelltexten dieses Bereichs nicht vor. Gemessen ist die Sache trotzdem: verteilt man eine Anweisung über mehrere Gesprächszüge, kostet das im Mittel 39 % — davon nur −16 % Können, aber +112 % Unzuverlässigkeit. Dazu: 1000 Abrufe bei Temperatur 0 ergaben 80 verschiedene Ausgaben.

Was aufgeschriebene Regeln bewirken — und was nicht. Sie machen einen Agenten nicht fähiger, und was sie kosten, ist umstritten. Eine kontrollierte Auswertung von Repository-Kontextdateien fand, dass sie die Erfolgsraten generell nicht verbesserten, die Kosten aber um über 20 % erhöhten; eine zweite Studie, die dieselbe Art Datei rein als Effizienzmechanismus vermass, fand das umgekehrte Vorzeichen — 16,58 % weniger Ausgabe-Tokens und 28,64 % weniger Laufzeit. Zwei Preprints, zwei verschiedene Versuchsaufbauten, gegensätzliche Ergebnisse. Der Widerspruch ist hier nicht aufgelöst; beide stehen mit ihrem Geltungsbereich nebeneinander in Eine Regel testen.

Was Regeln steuern, ist das Verhalten im Konflikt, und dort ist die Wirkung gross — das Entfernen einer einzigen Zustimmungsklausel hob destruktive Handlungen ausserhalb des Auftrags von 0,0 % auf 17,1 %. Diese Zahl bitte für das lesen, was sie ist: Sie vergleicht eine vorhandene Regel mit einer fehlenden, nicht eine Formulierung mit einer anderen. Sie stützt damit einen engeren Punkt, als es aussieht — eine Regel, die eine erkennbare Handlung benennt („niemals auf main pushen"), lässt sich im Moment leichter anwenden als eine, die eine Tugend benennt („immer sauber arbeiten"), weil man merkt, ob man gerade dabei ist. Das ist ein Argument über Erkennbarkeit, nicht über Befolgungsquoten.

Daneben, und auf eine andere Frage antwortend, steht eine Messung. Eine grossangelegte kontrollierte Studie zu Regeldateien für Agenten — 679 von GitHub gesammelte Dateien, 25.532 Regeln, über 5.000 Agentenläufe auf SWE-bench Verified — berichtet, dass in ihren Daten jede Regel, die für sich genommen die Aufgabenleistung verbesserte, ein Verbot war („do not refactor unrelated code"), und jede, die ihr schadete, ein Gebot („follow code style") (Guardrails Beat Guidance, arXiv:2604.11088). Zwei Dinge aus derselben Arbeit nehmen dem den Hebel. „In our data" heisst: Regeln so klassifiziert, wie sie vorgefunden wurden; niemand hat dieselbe Regel einmal so und einmal so geschrieben und verglichen. Und zufällig erzeugte Regeln halfen genauso viel wie von Fachleuten kuratierte, +13,8 PP in beiden Fällen — ein Effekt, den die Autoren als weitgehend inhaltsunabhängig beschreiben. Die Polarität ist eine echte Naht in diesem Korpus. Ein grosser Hebel ist sie nicht, und sie handelt von Leistung, nicht davon, ob eine Regel befolgt wird.

Damit bleiben drei Befunde auf drei Achsen, die man leicht ineinanderschiebt. Die Form — wie eine Regel kodiert ist, kompakter Kopf gegen ausformulierte Prosa — hat keinen messbaren Effekt (Compact Constraint Encoding, arXiv:2604.07192). Die Polarität tritt im Korpus oben auseinander. Der Widerspruch zu dem, was das Modell ohnehin täte, wiegt schwerer als beides: In derselben Kodierungs-Studie scheiterten Vorgaben gegen die Voreinstellungen des Modells in 10–100 % der Fälle, während konventionelle bei 99 %+ hielten. Keiner der drei misst die Erkennbarkeit — ob ein Mensch oder ein Agent im Moment merkt, dass eine Regel greift. Stand 2026-09-04 fanden wir in den Quellen der Einführung dieses Bereichs nichts, was sie misst; dieses Argument ist eine Überlegung, keine Messung. Alle drei stehen mit ihren Grenzen in Eine Regel testen.

Weder Regeln noch Prüfungen enthalten, was gemeint war. Regeln formen, wozu der Agent neigt; Prüfungen begrenzen, was er tun kann. Zusammen sind sie das Beste, was verfügbar ist — was nicht dasselbe ist wie genug.

Und eine Behauptung, die hier bewusst nicht steht: dass Agenten die Architektur verfallen liessen. Eine gematchte kausale Studie über 151 Repositories fand die Zahl der Architektur-Gerüche unverändert (+1,1 %, p = 0,82); die Negativliste dieses Bereichs führt sie als aktiv widerlegt. Sie würde sich gut machen und ist nicht wahr.

Alle Zahlen und ihre Quellen stehen vollständig in der Einführung dieses Bereichs↗.

Einschränkungen#

• Nichts davon macht den Agenten fähiger. Was die Toolbox einkauft, ist Vorhersagbarkeit — eine andere und, für Übergabe, nützlichere Eigenschaft.
• Die Technik veraltet schnell. Dateinamen und Werkzeuge haben eine kurze Halbwertszeit; das Schichtenmodell überlebt sie, die Syntax nicht.
• Das ist ein Repository und ein Arbeitsstil. Keine Studie, kein Vergleich, keine Behauptung, die Reihenfolge sei optimal.
• Die Toolbox ist keine Garantie. Sie macht Arbeit vorhersagbar und prüfbar. Sie macht sie nicht richtig.

Offen#

Referenzen#

• Agentische Entwicklung — die Einführung in diesen Bereich↗ (dieses Repository)
• Agentische Programmierung: was die Prüfung nicht überstanden hat↗ (dieses Repository)
• Eine Agenten-Session am Leben halten — oder neu starten↗ (dieses Repository)
• Externe Quellen: die in §2.2 zitierten Studien stehen vollständig im Referenzteil der Einführung; alles, was in dieser Reihe neu zitiert wird, muss vor dem Ausliefern des Entwurfs geöffnet und datiert werden.

Bộ đồ nghề sinh tồn: xây dựng hệ thống skill của riêng bạn để làm việc với đồng nghiệp ảo#

Dành cho bất kỳ ai bắt đầu giao việc thật cho một AI agent — một đồng nghiệp ảo — và muốn cùng một thứ được tạo ra hai lần như nhau. Viết cho product owner, sales, business analyst, HR, người mới vào nghề, và bất kỳ ai đã khởi đầu bằng vibe-coding. Bạn không cần biết lập trình.

Các ví dụ đến từ những vai trò khác nhau, mỗi tầng một vai. Ở chỗ có số liệu và nghiên cứu, chúng đã được chuyển vào một mục riêng ở cuối — toàn bộ loạt bài áp dụng được mà không cần đọc mục đó.

Trong ba phút#

Vấn đề. Với một AI agent, một kết quả đến trong vài phút và trông có vẻ ổn. Nhưng lần thứ hai lại ra một thứ khác, và sau đó không ai nói được vì sao. Với một bản demo thì thế là ổn. Với một thứ gánh công việc hằng ngày thì không.

Nguyên nhân. Agent không có ký ức về thứ bạn đang xây và không có ý niệm nào về cái gì được coi là "đúng" ở nơi bạn làm việc. Cả hai đều phải được viết ra ở đâu đó — nếu không thì lần nào nó cũng đoán lại.

Câu trả lời không phải một công cụ. Nó là một chồng file nhỏ. Năm loại, xây theo thứ tự này:

Chỉ số 2 tự nó giữ được. Mọi thứ còn lại là một thoả thuận — có giá trị, và tự nguyện.

Việc bạn làm hôm nay. Mở một file trống, đặt tên là AGENTS.md, và viết vào đó ba câu áp dụng cho mọi công việc. Lý tưởng nhất là ba điều cấm — những thứ bạn đã tận mắt thấy hỏng. Đó là tầng 1, và nó mất mười phút.

Nếu sau đó bạn muốn đi tiếp: tầng 2 là tầng duy nhất thực sự giữ được, và đó là lý do nó đứng thứ hai.

Loạt bài#

Mỗi trang tầng đọc hết trong bốn phút và có cùng một hình dạng: trong một câu · một ví dụ · việc bạn làm hôm nay · nó được làm từ gì · nó không làm được gì · cái gì hỏng · xong khi nào.

Tại sao bạn cần thứ này#

Việc tạo ra đầu ra đã trở nên dễ dàng. Một đoạn văn, một mẩu code, một bản nháp chiến dịch — vài phút, và trông có vẻ ổn. Chừng đó đủ để gây chú ý. Với mọi thứ sau đó, chừng đó là không đủ.

Bởi vì một sản phẩm hay một quy trình gánh giá trị hằng ngày đòi hỏi một thứ khác với một kết quả tốt. Nó đòi hỏi lại đúng kết quả tốt đó — vào tuần sau, do người khác khởi động, trong một trạng thái mà không còn ai giữ trong đầu nữa. Vibe-coding đặt trước mặt bạn một prototype đẹp, chạy được, trong một giờ; khoảng cách từ đó tới thứ bạn giao cho khách hàng mới là phần việc thật sự. Ngoài phần mềm cũng vậy: một bài thuyết trình mất một giờ, còn một quy trình báo giá mà ba người có thể vận hành mà không phải hỏi ai thì không.

Công sức không biến mất. Nó dịch chuyển — từ việc tạo ra sang việc kiểm tra, tới một chỗ chưa ai bố trí người. Điều đó đã được đo; các con số nằm xa hơn phía dưới, ở mục Cái gì thực sự có bằng chứng.

Ba thứ cản đường#

Với hai thứ đầu thì gần như không xây được gì; chúng là thuộc tính của công cụ và sẽ cải thiện hoặc không. Thứ ba thì khác. Đó chính xác là chỗ một cách làm việc thành văn thay đổi kết quả — và đó là điều duy nhất loạt bài này bàn tới.

"Nhất quán" ở đây không có nghĩa gì to tát: rằng một công việc lặp lại chạy giống nhau hai lần, rằng điều lẽ ra phải xảy ra vẫn tái dựng lại được, và rằng một người không có mặt lúc đó vẫn có thể đối chiếu kết quả với nó.

Đích đến — và khoảng cách đã đo được tới nó#

Nó được xây cho một cách làm việc trong đó đồng nghiệp ảo và đồng nghiệp thật cùng làm trên một sản phẩm — với product owner ra quyết định và nhà cung cấp giao hàng. Đó là một đích đến, không phải mô tả một thứ đã hoàn tất, và loạt bài này không xử lý mô hình vai trò.

Cái nó làm được là đối chiếu đích đến với trải nghiệm thực tế. Trong mười chủ đề mà một cách làm việc như thế phải bao phủ, đúng hai chủ đề chỉ nằm ở tầng yếu nhất — ai được bàn giao cái gì, và ai được quyết mà không phải hỏi (bài kiểm tra tính đầy đủ). Hai chủ đề lẽ ra phải gánh sự cộng tác thì lại đứng trên không gì ngoài thiện chí. Và trong bộ sưu tập mà loạt bài này xuất phát, 36 trong 60 quy trình thành văn chưa từng một lần được dùng (phép đo).

Đích đến vẫn là đích đến; khoảng cách tới nó được đo chứ không được khẳng định suông.

Thứ tự#

Xây 1 và 2 trước. Phần lớn mọi người bắt đầu ở 3, vì viết một quy trình ra là phần thú vị, và chỉ đến 2 sau khi có thứ gì đó lọt lưới. Nếu bạn chỉ xây hai tầng, hãy xây 1 và 2: một điều cấm cộng một kiểm tra thực sự bắn ra là một bộ đồ nghề hoạt động được. Ba quy trình và không có kiểm tra nào thì là một thư mục.

Từ tầng tới artefact#

Năm tầng là các phạm trù, không phải các file. Đây là thứ chúng trở thành khi hạ cánh — trong ba hình chứ không phải một, vì mười một artefact vẽ cạnh nhau sẽ ra quá nhỏ để đọc.

Tầng 1 và 2 — hai tầng bạn xây trước.

Cả hai cặp đều có chủ đích. Kiểm tra xuất hiện hai lần, vì một kiểm tra chỉ ở đúng một nơi thì không phải là kiểm tra: một cái chạy trên máy bạn, cái kia chạy tập trung — và chỉ cái tập trung là không thể bỏ qua. File quy tắc xuất hiện hai lần vì một lý do khác: file trong dự án và file bao trùm mọi dự án có thể nói những điều khác nhau, và cái gần hơn thắng.

Tầng 3 và 4 — thứ công việc chạy trên đó, và thứ nó để lại.

Bản ghi có ba artefact chứ không phải một, vì "điều lẽ ra phải xảy ra" tích tụ trên ba thang thời gian: mỗi công việc, mỗi phiên làm việc, mỗi quyết định.

Tầng 5 — thứ giữ cho bốn tầng kia tìm thấy được.

Ba thứ đó tồn tại cho bốn tầng kia: một lệnh duy nhất tìm kiếm mọi thứ, danh sách mà nó tạo ra, và một kho lưu trữ mà bạn có thể quay trở ra.

Một artefact được làm từ gì#

Bảy khối cấu thành của file quy trình ở đây chỉ được gọi tên. Chúng được giải thích đúng một lần, ở tầng 3 — chính quy tắc mà tầng 5 phát biểu, áp dụng ở đây cho chính loạt bài này. Một lời giải thích thứ hai sẽ là một bản sao, và các bản sao trôi dạt khỏi nhau.

Ở đâu một tầng không có tên file, bạn không có tầng đó. Đây là bài tự kiểm tra rẻ nhất trong loạt bài.

Cái gì thực sự có bằng chứng#

Mục này được viết ra để bỏ qua. Ai áp dụng loạt bài này thì không cần nó; ai muốn biết nó dựa trên cái gì sẽ tìm thấy các con số ở đây, kèm theo giới hạn của chúng.

Công sức đã dịch chuyển. Một nghiên cứu dọc trên 802 lập trình viên và 196,212 pull request tìm thấy thông lượng ở mức 2.09× — và song song với đó, tải trên mỗi người review tăng khoảng gấp đôi trong khi review tự động vượt qua review của con người. Đầu ra tăng gấp đôi. Việc review tăng gấp đôi theo. Rồi chính việc review lại được giao cho máy.

Bộ nhớ. Các cuộc hội thoại dài không gãy ở ranh giới; chúng suy giảm từ rất lâu trước đó. Một khi phần trùng lặp từ khoá theo nghĩa đen bị loại khỏi tác vụ, 11 trong 13 mô hình rơi xuống dưới một nửa mức nền ngữ cảnh ngắn của chính chúng ở 32K. Và các kiến trúc bộ nhớ được bán như câu trả lời vẫn chưa sửa được điều đó — trong đánh giá của chính một nhà cung cấp, việc chỉ đơn giản dán nguyên cuộc hội thoại thô vào đã cho điểm cao hơn mọi hệ thống được thử nghiệm, kể cả hệ thống của chính họ.

Sự thiếu tin cậy. Từ "consistency" không xuất hiện trong các văn bản nguồn của lĩnh vực này. Bản thân sự việc thì vẫn được đo: trải một chỉ dẫn ra qua nhiều lượt hội thoại tốn 39% trung bình — trong đó chỉ −16% là năng lực, còn sự thiếu tin cậy tăng 112%. Và 1,000 completion ở temperature 0 tạo ra 80 đầu ra khác biệt.

Quy tắc thành văn làm được gì — và không làm được gì. Chúng không làm cho một agent giỏi hơn, và cái giá chúng tốn thì còn tranh cãi. Một đánh giá có đối chứng về các file ngữ cảnh của repository tìm thấy chúng nói chung không cải thiện tỉ lệ thành công trong khi làm chi phí tăng hơn 20%; một nghiên cứu thứ hai, đo cùng loại file thuần tuý như một cơ chế hiệu quả, lại tìm ra dấu ngược lại — ít hơn 16.58% output token và giảm 28.64% thời gian đồng hồ. Hai preprint, hai thiết lập khác nhau, kết quả trái ngược. Bất đồng này không được giải quyết ở đây; cả hai được trình bày cạnh nhau, kèm phạm vi của chúng, trong kiểm thử một quy tắc.

Cái mà quy tắc thực sự chi phối là hành vi khi có xung đột, và ở đó hiệu ứng là lớn — bỏ đi một điều khoản đồng thuận duy nhất đã đẩy các hành động phá huỷ nằm ngoài phạm vi từ 0.0% lên 17.1%. Hãy đọc con số đó đúng như nó là: nó so sánh việc một quy tắc có mặt với việc nó vắng mặt, chứ không phải một cách diễn đạt này với một cách diễn đạt khác. Vì thế nó chống đỡ cho một luận điểm hẹp hơn vẻ ngoài của nó — một quy tắc gọi tên một hành động nhận ra được ("never push to main") thì dễ áp dụng ngay tại thời điểm đó hơn một quy tắc gọi tên một đức tính ("always work cleanly"), vì bạn phân biệt được mình có sắp làm điều đó hay không. Đó là một lập luận về tính nhận-ra-được, không phải về tỉ lệ tuân thủ.

Bên cạnh đó, trả lời một câu hỏi khác, có một phép đo. Một nghiên cứu có đối chứng quy mô lớn về các file quy tắc cho agent — 679 file cào từ GitHub, 25,532 quy tắc, hơn 5,000 lượt chạy agent trên SWE-bench Verified — báo cáo rằng trong dữ liệu của nó, mọi quy tắc tự nó cải thiện hiệu năng tác vụ đều là một điều cấm ("do not refactor unrelated code"), và mọi quy tắc làm hại hiệu năng đều là một chỉ thị khẳng định ("follow code style") (Guardrails Beat Guidance, arXiv:2604.11088). Hai điều trong chính bài báo đó lấy mất đòn bẩy của luận điểm ấy. "Trong dữ liệu của chúng tôi" nghĩa là các quy tắc được phân loại đúng như chúng được tìm thấy ngoài tự nhiên; không ai viết cùng một quy tắc theo cả hai cách rồi so sánh. Và các quy tắc sinh ngẫu nhiên giúp ích ngang với các quy tắc do chuyên gia biên soạn, +13.8 pp ở cả hai phía — một hiệu ứng mà các tác giả gọi là phần lớn độc lập với nội dung. Cực tính là một đường nối có thật trong kho ngữ liệu đó. Nó không phải một đòn bẩy lớn, và nó nói về hiệu năng, không phải về việc một quy tắc có được tuân theo hay không.

Còn lại ba phát hiện trên ba trục, rất dễ bị gộp lẫn vào nhau. Hình thức — một quy tắc được mã hoá thế nào, tiêu đề gọn so với văn xuôi dài dòng — không có hiệu ứng đo được (Compact Constraint Encoding, arXiv:2604.07192). Cực tính thì rời rạc ra trong kho ngữ liệu ở trên. Việc đi ngược lại điều mô hình vốn dĩ sẽ làm nặng cân hơn cả hai: trong chính nghiên cứu về mã hoá đó, các ràng buộc chạy ngược mặc định của mô hình thất bại 10–100 % số lần, trong khi các ràng buộc thông thường giữ được ở mức 99 %+. Không cái nào trong ba cái đo tính nhận-ra-được — liệu một người hay một agent có phân biệt được, ngay tại thời điểm đó, rằng một quy tắc đang áp dụng hay không. Tính đến 2026-09-04, trên các nguồn được liệt kê trong phần giới thiệu của lĩnh vực này, chúng tôi không tìm thấy gì đo điều đó; lập luận đó là suy luận, không phải phép đo. Cả ba, kèm giới hạn của chúng, nằm trong kiểm thử một quy tắc.

Cả quy tắc lẫn kiểm tra đều không chứa đựng điều đã được ngụ ý. Quy tắc định hình điều agent nghiêng về việc làm; kiểm tra ràng buộc điều nó có khả năng làm. Cùng nhau, chúng là thứ tốt nhất hiện có — điều đó không giống với đủ.

Toàn bộ các con số và nguồn của chúng được nêu đầy đủ trong phần giới thiệu của lĩnh vực này↗.

Lưu ý#

• Không điều nào trong đây làm agent giỏi hơn. Cái mà bộ đồ nghề mua được là tính dự đoán được — một thuộc tính khác, và với việc bàn giao công việc thì hữu ích hơn.
• Công nghệ lỗi thời nhanh. Tên file và công cụ có hạn dùng ngắn; mô hình tầng sống lâu hơn chúng, còn cú pháp thì không.
• Đây là một repository và một phong cách làm việc. Không có nghiên cứu, không có so sánh, không có khẳng định rằng thứ tự này là tối ưu.
• Bộ đồ nghề không phải một bảo đảm. Nó làm cho công việc dự đoán được và kiểm tra được. Nó không làm cho công việc đúng.

Còn mở#

• ✓[VERIFY] — đã giải quyết ngày 2026-09-06. Tài liệu của nhà cung cấp có nêu cơ chế nạp, và nó được trích dẫn kèm ngày đọc trong tầng 3, cùng với tám nơi đã được tra cứu. Kèm theo là hai điểm dè dặt: việc chọn là một phán đoán chứ không phải một phép khớp, và danh sách mang các phần mô tả thì có ngân sách.
• ✓Chỗ ở cuối cùng đã được quyết định — 2026-09-07. Loạt bài ở nguyên chỗ cũ. Việc di dời sẽ phải viết lại khoảng một trăm đường dẫn đã ghim, cả hai bản ghi dẫn xuất và tài liệu đã dựng, mà không mang lại gì cho người đọc; README↗ nay nói thư mục này chứa gì thay vì hứa hẹn assets — đó mới là điều thực sự sai. Assets sẽ có thư mục ghi ngày riêng khi có cái đầu tiên (TODO-027).
• Người đọc thứ hai cho lượt rà soát công bố — §2 của AGENTS.md↗.

Tài liệu tham khảo#

• Agentic development — phần giới thiệu của lĩnh vực này↗ (repository này)
• Agentic programming: cái gì không sống sót qua khâu kiểm chứng↗ (repository này)
• Vòng đời phiên agent và compaction↗ (repository này)
• Nguồn bên ngoài: các nghiên cứu được trích trong §2.2 được dẫn đầy đủ trong danh sách tham khảo riêng của phần giới thiệu; bất cứ thứ gì được trích dẫn mới trong loạt bài này đều phải được mở ra và ghi ngày trước khi bản nháp được phát hành.

Layer 1 — The standing rule file#

Survival toolbox, part 1 of 5 · Start here · next: Layer 2 — the mechanical gate

In one sentence#

A file that is read along with every job, containing only what is always true.

An example: product owner#

Who. A product owner having an agent work up requirements. The job. Turn an idea into a ticket somebody can act on without asking a question. What goes wrong. Every ticket looks different — sometimes the acceptance criteria are missing, sometimes the reason it is being built at all. She explains the same obvious things every time, and slightly differently every time. What you build. A file with the five sentences that hold for every ticket. Not this week's idea — the things that will also hold for the job nobody has thought of yet.

What you do today#

Open an empty file, call it AGENTS.md, write three prohibitions in it. Prohibitions, not instructions: things you have already watched go wrong. Ten minutes, and layer 1 exists.

What it is#

One file, loaded on every task, holding only what is true across all of them. AGENTS.md, CLAUDE.md, .cursorrules, whatever your harness reads — the name is vendor-specific, the role is not. It is the standing context: the conventions, the boundaries, the prohibitions that apply whether the job is a bug fix, a migration or a README.

That it really is resident, rather than fetched when wanted, is the property the whole layer rests on, and it is documented: Anthropic's own Claude Code page draws the contrast the other way round, noting that unlike this file's content, a skill's body loads only when it is used (read 2026-09-06). Which is why the two layers fail differently — see layer 3.

It is the cheapest layer to write and the easiest to ruin, because nothing stops it growing.

The failure it prevents#

Settled conventions re-litigated on every task. Without it, every session re-derives the same decisions — branch naming, commit format, what may be deleted, whether to ask before pushing — and derives them slightly differently each time. The cost is not the wrong answer; it is that there is no stable answer to compare an outcome against.

Its second, larger job is behaviour under conflict: the moment a plausible-looking shortcut exists, the file is what decides whether it is taken. The introduction↗ reports the measured size of that effect — removing one consent clause moved destructive out-of-scope actions from 0.0% to 17.1%.

What belongs in it#

The membership test is a single question: would this still be true of a task I have not thought of yet?

Two entries deserve their own paragraph, because they are usually assumed and therefore absent.

The exceptions, named as exceptions. A rule with an undocumented carve-out is a rule that gets broken confidently — the reader hits the case the rule obviously was not written for, concludes the rule does not apply, and now has a private carve-out nobody else knows about. Write the carve-out down and it becomes a boundary instead of a judgement call. "Never commit directly to main — except a commit touching only *.md" is a rule. "Never commit directly to main" in a repository where people routinely do for docs is a rule that teaches everyone to ignore rules.

Which rules are enforced and which are not. This is the most useful paragraph in the file and the least comfortable to write, because it is an inventory of your own gaps. It is also the only thing that stops the file being read as a set of guarantees. Classify every rule into three buckets:

The middle bucket is where false confidence lives. "Partly enforced" reads as "enforced" to everyone who did not write the check.

The excuse, and the answer to it#

A rule can be correct, findable and still not hold — and when it does not, what comes back is rarely "I forgot". It is an argument, usually a good one. Across 238 published instruction files this turned out to be the single most common defect of the 26 catalogued: 94 % of them contain nothing that discourages reasoning your way out of a required step (appendix 0520).

The remedy is two columns in this file. The excuse on the left, quoted as it was actually given; the answer on the right, closing that specific escape rather than restating the rule.

Two cautions, both measured, both counter-intuitive: rewording the rule does not help — encoding form had no significant effect across 11 models — and naming the penalty makes it worse, because it turns an obligation into arithmetic. What does help is giving the rule a way out, which belongs to layer 3. The evidence, and the method for finding out whether one of your rows works, are in appendix 0520.

Outside software#

The standing rule file is the least software-specific layer in the toolbox. Its non-software forms are older than the software one: the standing brief you give a new contractor on their first day; the two sentences in a team handbook that everyone actually remembers; the "nothing goes to the client without a second pair of eyes" that is repeated at every onboarding. Each is a standing instruction that applies to work not yet imagined, and each fails the same way — by growing into a handbook nobody re-reads.

How to build it#

1. Start from violations you have actually seen. Not from a list of best practices. A rule that answers no observed failure costs context on every task and buys nothing.
2. Write each one as a prohibition where you can. Name a recognisable action, not a virtue. "Never force-push a shared branch" names something you can see yourself about to do; "keep history clean" has to be interpreted first, and interpreting is where a rule quietly turns into a preference. That argument is about recognisability, and it rests on its own reasoning: as of 2026-09-04, across this area's sources, we found no measurement of it. A neighbouring question has been measured, and it points the same way without carrying the weight — in a corpus of 679 scraped rule files, every rule that improved task performance on its own was a prohibition and every one that hurt it was a positive directive, but the same study found randomly generated rules as good as expert-curated ones, which makes polarity a seam in that data rather than a lever (Guardrails Beat Guidance, arXiv:2604.11088; its limits are set out in appendix 0520). It is a different study from the encoding-form one above (Compact Constraint Encoding, arXiv:2604.07192), which varied how a rule is written and found that made no difference at all.
3. Attach the exception to the rule, in the same sentence or the one after it. Never in a different section, and never nowhere.
4. Tag each rule enforced / partial / advisory. If you cannot name the mechanism, it is advisory — write that, do not round it up.
5. Put the irreversible boundary first. In a public repository that is the disclosure rule; in a production system it is the destructive-action rule. Ordering is a signal, and the first section is the one that gets read.
6. Cut until a person would re-read it. The load-bearing reason is the unmeasured one: nobody maintains a document they have stopped reading, and an unmaintained rule file is where the contradictions collect. The cost argument is contested — one controlled study puts the added length at over 20 % extra inference cost, while a rule file measured on its own came out at −16.58 % output tokens and −28.64 % wall clock (appendix 0520). Different setups, so neither number settles the other. Cut for the reader.

What it cannot do#

It cannot make the agent more capable, and it cannot enforce anything. Both halves matter. The first means a rule file is the wrong tool for "the model keeps getting X wrong" — that is a capability problem, and instructions measurably do not fix it. The second means that every sentence in the file, however emphatic, is a disposition: it shapes what is likely, never what is possible.

If a rule must hold when nobody is reading, it is not a layer-1 rule. It is a layer-2 gate that has not been built yet.

Failure modes#

Done when#

• Every rule passes "would this be true of a task I have not thought of yet?"
• Every rule is tagged enforced / partial / advisory, and each enforced one names its mechanism
• Every exception is written next to the rule it qualifies
• The irreversible boundary is in the first section
• Someone who has never seen the project could follow it without asking a question

Next: Layer 2 — the mechanical gate, the only layer that holds when nobody is reading.

Schicht 1 — Die feste Regeldatei#

Survival-Toolbox, Teil 1 von 5 · Hier beginnen · weiter: Schicht 2 — das mechanische Gate

In einem Satz#

Eine Datei, die bei jeder Aufgabe mitgelesen wird und nur das enthält, was immer gilt.

Ein Beispiel: Product Owner#

Wer. Eine Product Ownerin, die Anforderungen von einem Agenten ausarbeiten lässt. Die Aufgabe. Aus einer Idee ein Ticket machen, das jemand ohne Rückfrage umsetzen kann. Was schiefgeht. Jedes Ticket sieht anders aus — mal fehlen die Abnahmekriterien, mal der Grund, warum es überhaupt gebaut wird. Sie erklärt jedes Mal dieselben Selbstverständlichkeiten neu, und jedes Mal ein bisschen anders. Was du baust. Eine Datei mit den fünf Sätzen, die für jedes Ticket gelten. Nicht die Idee dieser Woche — das, was auch für die Aufgabe gilt, an die noch niemand gedacht hat.

Was du heute tust#

Öffne eine leere Datei, nenne sie AGENTS.md, und schreib drei Verbote hinein. Verbote, keine Gebote: Dinge, die du schon einmal schiefgehen gesehen hast. Zehn Minuten, und Schicht 1 steht.

Was sie ist#

Eine Datei, bei jeder Aufgabe geladen, die nur enthält, was für alle gilt. AGENTS.md, CLAUDE.md, .cursorrules — wie sie heisst, ist herstellerabhängig, wozu sie da ist, nicht. Sie ist der stehende Kontext: die Konventionen, die Grenzen, die Verbote, die gelten, ob die Aufgabe ein Bugfix, eine Migration oder eine README ist.

Dass sie wirklich dauerhaft liegt und nicht bei Bedarf geholt wird, ist die Eigenschaft, auf der die ganze Schicht ruht, und sie ist belegt: Anthropics eigene Claude-Code-Seite zieht den Vergleich von der anderen Seite und hält fest, dass anders als der Inhalt dieser Datei der Rumpf einer Skill erst lädt, wenn er gebraucht wird (gelesen 2026-09-06). Deshalb scheitern die beiden Schichten verschieden — siehe Schicht 3.

Sie ist die billigste Schicht im Schreiben und die am leichtesten zu ruinierende, weil nichts ihr Wachstum bremst.

Der Fehler, den sie verhindert#

Geklärte Konventionen, die in jeder Aufgabe neu verhandelt werden. Ohne sie leitet jede Session dieselben Entscheidungen neu her — Branch-Benennung, Commit-Format, was gelöscht werden darf, ob vor dem Push gefragt wird — und jedes Mal ein wenig anders. Der Preis ist nicht die falsche Antwort; er ist, dass es keine stabile Antwort gibt, gegen die man ein Ergebnis halten könnte.

Ihre zweite, grössere Aufgabe ist Verhalten im Konflikt: sobald eine plausibel aussehende Abkürzung existiert, entscheidet die Datei, ob sie genommen wird. Die Einführung↗ nennt die gemessene Grösse dieses Effekts — das Entfernen einer Zustimmungsklausel hob destruktive Handlungen ausserhalb des Auftrags von 0,0 % auf 17,1 %.

Was hineingehört#

Der Zugehörigkeitstest ist eine einzige Frage: wäre das auch für eine Aufgabe wahr, an die ich noch nicht gedacht habe?

Zwei Einträge verdienen einen eigenen Absatz, weil sie üblicherweise vorausgesetzt und deshalb weggelassen werden.

Die Ausnahmen, als Ausnahmen benannt. Eine Regel mit undokumentierter Ausnahme ist eine Regel, die selbstbewusst gebrochen wird — man trifft auf den Fall, für den die Regel offensichtlich nicht geschrieben wurde, schliesst daraus, dass sie nicht gilt, und hat nun eine private Ausnahme, von der niemand sonst weiss. Schreibt man die Ausnahme auf, wird aus einer Ermessensfrage eine Grenze. „Niemals direkt auf main committen — ausser bei einem Commit, der nur *.md berührt" ist eine Regel. „Niemals direkt auf main committen" in einem Repository, in dem alle es für Dokumentation routinemässig tun, ist eine Regel, die allen beibringt, Regeln zu ignorieren.

Welche Regeln erzwungen sind und welche nicht. Das ist der nützlichste Absatz der Datei und der unangenehmste zu schreiben, weil er eine Inventur der eigenen Lücken ist. Er ist zugleich das Einzige, was verhindert, dass die Datei als Sammlung von Garantien gelesen wird. Jede Regel in einen von drei Töpfen:

Der mittlere Topf ist der Ort, an dem falsche Sicherheit wohnt. „Teilweise erzwungen" liest sich für alle, die die Prüfung nicht geschrieben haben, als „erzwungen".

Die Ausrede, und die Antwort darauf#

Eine Regel kann richtig und auffindbar sein und trotzdem nicht halten — und wenn sie es nicht tut, kommt selten „hab ich vergessen" zurück. Es kommt ein Argument, meistens ein gutes. Über 238 veröffentlichte Instruktionsdateien hinweg war das der mit Abstand häufigste von 26 katalogisierten Defekten: 94 % von ihnen enthalten nichts, was davon abhält, sich aus einem verlangten Schritt herauszuargumentieren (Anhang 0520).

Das Mittel sind zwei Spalten in dieser Datei. Links die Ausrede, so zitiert, wie sie wirklich gefallen ist; rechts die Antwort, die genau diesen Ausweg schließt, statt die Regel zu wiederholen.

Zwei Vorbehalte, beide gemessen, beide gegen die Intuition: Umformulieren hilft nicht — die Kodierungsform hatte über 11 Modelle keinen signifikanten Effekt — und die Strafe zu benennen macht es schlimmer, weil sie aus einer Pflicht eine Rechenaufgabe macht. Was hilft, ist der Regel einen Ausweg zu geben, und das gehört zu Schicht 3. Die Belege und die Methode, mit der man herausfindet, ob eine der Zeilen wirkt, stehen im Anhang 0520.

Ausserhalb der Software#

Die feste Regeldatei ist die am wenigsten softwarespezifische Schicht der Toolbox. Ihre Formen ausserhalb der Software sind älter als die softwareseitige: das stehende Briefing, das eine neue externe Kraft am ersten Tag bekommt; die zwei Sätze aus dem Teamhandbuch, die tatsächlich alle behalten; das „nichts geht an den Kunden ohne ein zweites Augenpaar", das bei jedem Onboarding fällt. Jedes davon ist eine stehende Anweisung für Arbeit, die noch niemand sich vorgestellt hat — und jedes scheitert gleich: es wächst zu einem Handbuch, das niemand mehr nachliest.

Wie man sie baut#

1. Von tatsächlich beobachteten Verletzungen ausgehen. Nicht von einer Best-Practice-Liste. Eine Regel, die auf kein beobachtetes Versagen antwortet, kostet Kontext bei jeder Aufgabe und bringt nichts.
2. Wo möglich als Verbot formulieren. Eine erkennbare Handlung benennen, keine Tugend. „Niemals einen geteilten Branch force-pushen" benennt etwas, das man sich selbst im Moment tun sieht; „Historie sauber halten" muss erst interpretiert werden, und beim Interpretieren wird aus einer Regel unbemerkt eine Vorliebe. Dieses Argument handelt von Erkennbarkeit und trägt sich selbst: Stand 2026-09-04 fanden wir in den Quellen dieses Bereichs keine Messung dazu. Gemessen ist eine benachbarte Frage, und sie weist in dieselbe Richtung, ohne das Gewicht zu tragen — in einem Korpus von 679 gesammelten Regeldateien war jede Regel, die für sich genommen die Aufgabenleistung verbesserte, ein Verbot, und jede, die ihr schadete, ein Gebot; dieselbe Studie fand aber zufällig erzeugte Regeln so gut wie von Fachleuten kuratierte, was die Polarität zu einer Naht in diesen Daten macht statt zu einem Hebel (Guardrails Beat Guidance, arXiv:2604.11088; die Grenzen stehen in Anhang 0520). Das ist eine andere Studie als die zur Kodierungsform weiter oben (Compact Constraint Encoding, arXiv:2604.07192), die variierte, wie eine Regel geschrieben ist, und dabei gar keinen Effekt fand.
3. Die Ausnahme an die Regel hängen, im selben Satz oder im nächsten. Nie in einem anderen Abschnitt, und nie nirgends.
4. Jede Regel mit erzwungen / teilweise / advisorisch markieren. Lässt sich kein Mechanismus benennen, ist sie advisorisch — das hinschreiben, nicht aufrunden.
5. Die irreversible Grenze zuerst. In einem öffentlichen Repository ist das die Veröffentlichungsregel, in einem Produktivsystem die Regel über destruktive Handlungen. Reihenfolge ist ein Signal, und der erste Abschnitt ist der, der gelesen wird.
6. Kürzen, bis ein Mensch sie nachlesen würde. Der tragende Grund ist der ungemessene: niemand pflegt ein Dokument, das er nicht mehr liest, und in einer ungepflegten Regeldatei sammeln sich die Widersprüche. Das Kostenargument ist umstritten — eine kontrollierte Studie beziffert die zusätzlichen Inferenzkosten der Länge auf über 20 %, während eine für sich gemessene Regeldatei auf −16,58 % Ausgabe-Tokens und −28,64 % Laufzeit kam (Anhang 0520). Verschiedene Aufbauten, keine der beiden Zahlen entscheidet die andere. Für den Leser kürzen.

Was sie nicht kann#

Sie kann den Agenten nicht fähiger machen, und sie kann nichts erzwingen. Beide Hälften zählen. Die erste bedeutet: eine Regeldatei ist das falsche Werkzeug für „das Modell macht X ständig falsch" — das ist ein Fähigkeitsproblem, und Anweisungen beheben es messbar nicht. Die zweite bedeutet: jeder Satz in der Datei ist, wie nachdrücklich auch immer, eine Disposition — er formt, was wahrscheinlich ist, nie, was möglich ist.

Muss eine Regel halten, wenn niemand hinschaut, ist es keine Schicht-1-Regel. Es ist ein Schicht-2-Gate, das noch nicht gebaut wurde.

Versagensmodi#

Fertig, wenn#

• Jede Regel besteht „wäre das für eine Aufgabe wahr, an die ich noch nicht gedacht habe?"
• Jede Regel ist als erzwungen / teilweise / advisorisch markiert, und jede erzwungene benennt ihren Mechanismus
• Jede Ausnahme steht neben der Regel, die sie einschränkt
• Die irreversible Grenze steht im ersten Abschnitt
• Jemand, der das Projekt nie gesehen hat, könnte ihr ohne Rückfrage folgen

Weiter: Schicht 2 — das mechanische Gate, die einzige Schicht, die hält, wenn niemand hinschaut.

Lớp 1 — Tệp quy tắc thường trực#

Bộ công cụ sinh tồn, phần 1 trong 5 · Bắt đầu tại đây · tiếp theo: Lớp 2 — cổng cơ học

Tóm trong một câu#

Một tệp được đọc kèm theo mọi công việc, chỉ chứa những gì luôn đúng.

Một ví dụ: product owner#

Ai. Một product owner để agent soạn thảo yêu cầu. Công việc. Biến một ý tưởng thành một ticket mà người khác có thể bắt tay vào làm mà không phải hỏi lại câu nào. Điều gì hỏng. Ticket nào cũng một kiểu khác nhau — lúc thì thiếu tiêu chí nghiệm thu, lúc thì thiếu lý do vì sao lại xây thứ đó. Cô ấy giải thích đi giải thích lại cùng những điều hiển nhiên, và lần nào cũng hơi khác đi một chút. Bạn xây gì. Một tệp chứa năm câu đúng cho mọi ticket. Không phải ý tưởng của tuần này — mà là những điều cũng sẽ đúng với công việc chưa ai nghĩ tới.

Việc bạn làm hôm nay#

Mở một tệp trống, đặt tên là AGENTS.md, viết vào đó ba điều cấm. Điều cấm, chứ không phải chỉ dẫn: những thứ bạn đã tận mắt thấy đi sai. Mười phút, và lớp 1 đã tồn tại.

Nó là gì#

Một tệp, được nạp trong mọi tác vụ, chỉ chứa những gì đúng với tất cả các tác vụ đó. AGENTS.md, CLAUDE.md, .cursorrules, bất cứ thứ gì harness của bạn đọc — cái tên là chuyện riêng của từng nhà cung cấp, vai trò thì không. Đó là ngữ cảnh thường trực: các quy ước, các ranh giới, các điều cấm được áp dụng bất kể công việc là sửa lỗi, migration hay một README.

Việc nó thực sự thường trú, chứ không phải được lấy về khi cần, chính là tính chất mà cả lớp này dựa vào, và điều đó có nguồn dẫn: trang Claude Code của chính Anthropic đặt phép so sánh theo chiều ngược lại, ghi rằng khác với nội dung của tệp này, phần thân của một skill chỉ nạp khi nó được dùng đến (đọc 2026-09-06). Đó là lý do hai lớp hỏng theo những cách khác nhau — xem lớp 3.

Đây là lớp rẻ nhất để viết và cũng dễ làm hỏng nhất, vì chẳng có gì ngăn nó phình to ra.

Thất bại mà nó ngăn chặn#

Những quy ước đã chốt lại bị đem ra tranh cãi lại trong từng tác vụ. Không có nó, mỗi phiên lại tự suy ra cùng những quyết định ấy — cách đặt tên nhánh, định dạng commit, cái gì được phép xóa, có phải hỏi trước khi push hay không — và mỗi lần lại suy ra hơi khác đi. Cái giá phải trả không phải là câu trả lời sai; mà là không hề có một câu trả lời ổn định để đối chiếu kết quả.

Nhiệm vụ thứ hai, lớn hơn, của nó là hành vi khi có xung đột: ngay khoảnh khắc xuất hiện một lối tắt trông có vẻ hợp lý, chính tệp này là thứ quyết định lối tắt đó có được đi hay không. Phần giới thiệu↗ báo cáo độ lớn đã đo được của hiệu ứng đó — bỏ đi một điều khoản về sự đồng ý đã đẩy các hành động phá hủy nằm ngoài phạm vi từ 0.0% lên 17.1%.

Cái gì thuộc về nó#

Phép thử tư cách thành viên chỉ gồm một câu hỏi duy nhất: điều này có còn đúng với một tác vụ mà tôi chưa nghĩ tới hay không?

Có hai mục xứng đáng được dành riêng một đoạn, vì chúng thường bị mặc định là hiển nhiên và do đó vắng mặt.

Các ngoại lệ, được gọi tên rõ là ngoại lệ. Một quy tắc có ngoại lệ không được ghi lại là một quy tắc sẽ bị phá một cách đầy tự tin — người đọc gặp đúng trường hợp mà rõ ràng quy tắc không được viết ra cho nó, kết luận rằng quy tắc không áp dụng, và thế là có một ngoại lệ riêng mà không ai khác biết. Viết ngoại lệ đó ra, và nó trở thành một ranh giới thay vì một phán đoán cá nhân. "Không bao giờ commit thẳng vào main — trừ một commit chỉ đụng tới *.md" là một quy tắc. "Không bao giờ commit thẳng vào main" trong một repository mà mọi người vẫn thường xuyên làm vậy với tài liệu là một quy tắc dạy cho tất cả mọi người rằng có thể phớt lờ quy tắc.

Quy tắc nào được cưỡng chế và quy tắc nào không. Đây là đoạn hữu ích nhất trong tệp và cũng khó chịu nhất khi phải viết, vì nó là bản kiểm kê chính những lỗ hổng của bạn. Nó cũng là thứ duy nhất ngăn tệp này bị đọc như một tập hợp các bảo đảm. Hãy phân loại mọi quy tắc vào ba nhóm:

Nhóm ở giữa là nơi trú ngụ của sự tự tin giả. "Được cưỡng chế một phần" thì với bất kỳ ai không tự tay viết phần kiểm tra đó đều đọc thành "được cưỡng chế".

Cái cớ, và câu trả lời cho nó#

Một quy tắc có thể đúng, có thể tìm thấy được, mà vẫn không được giữ — và khi nó không được giữ, thứ quay lại hiếm khi là "tôi quên". Đó là một lập luận, và thường là một lập luận hay. Trên 238 tệp chỉ dẫn đã công bố, đây hóa ra là khiếm khuyết phổ biến nhất trong 26 khiếm khuyết được liệt kê: 94 % trong số đó không chứa bất cứ điều gì ngăn cản việc lập luận để thoát khỏi một bước bắt buộc (phụ lục 0520).

Cách khắc phục là hai cột trong chính tệp này. Cái cớ ở cột trái, được trích đúng như nó đã thực sự được nói ra; câu trả lời ở cột phải, đóng đúng lối thoát cụ thể đó thay vì nhắc lại quy tắc.

Hai điều cần thận trọng, cả hai đều đã được đo, cả hai đều phản trực giác: viết lại quy tắc bằng lời khác không giúp ích gì — hình thức mã hóa không có tác động đáng kể nào trên 11 mô hình — và nêu tên hình phạt lại làm mọi thứ tệ hơn, vì nó biến một nghĩa vụ thành một bài toán số học. Thứ có giúp ích là cho quy tắc một lối ra, và điều đó thuộc về lớp 3. Bằng chứng, cùng với phương pháp để tự tìm hiểu xem một dòng nào đó của bạn có tác dụng hay không, nằm ở phụ lục 0520.

Bên ngoài phần mềm#

Tệp quy tắc thường trực là lớp ít mang tính đặc thù phần mềm nhất trong bộ công cụ. Các hình thái phi phần mềm của nó còn già hơn hình thái phần mềm: bản chỉ dẫn thường trực bạn đưa cho một nhà thầu mới trong ngày đầu tiên; hai câu trong sổ tay của đội mà ai cũng thực sự nhớ; câu "không có gì đến tay khách hàng mà không qua một cặp mắt thứ hai" được lặp lại ở mọi buổi onboarding. Mỗi thứ đó đều là một chỉ dẫn thường trực áp dụng cho công việc chưa hề được hình dung, và mỗi thứ đều hỏng theo cùng một kiểu — bằng cách phình lên thành một cuốn sổ tay không ai đọc lại.

Cách xây dựng nó#

1. Bắt đầu từ những vi phạm bạn đã thực sự chứng kiến. Không phải từ một danh sách các best practice. Một quy tắc không trả lời cho một thất bại nào đã quan sát được thì tiêu tốn ngữ cảnh trong mọi tác vụ mà chẳng mua lại được gì.
2. Viết mỗi quy tắc thành một điều cấm ở những chỗ có thể. Hãy gọi tên một hành động nhận ra được, chứ không phải một đức tính. "Không bao giờ force-push một nhánh dùng chung" gọi tên một thứ mà bạn có thể tự thấy mình sắp làm; "giữ lịch sử sạch sẽ" thì phải diễn giải đã, mà diễn giải chính là chỗ một quy tắc lặng lẽ biến thành một sở thích. Lập luận đó nói về khả năng nhận ra, và nó dựa trên lý lẽ của riêng nó: tính đến 2026-09-04, trên toàn bộ các nguồn của lĩnh vực này, chúng tôi không tìm thấy phép đo nào về nó. Một câu hỏi lân cận thì đã được đo, và nó chỉ về cùng một hướng nhưng không mang được sức nặng ấy — trong một corpus gồm 679 tệp quy tắc thu thập được, mọi quy tắc tự nó cải thiện hiệu năng tác vụ đều là một điều cấm và mọi quy tắc làm hiệu năng tệ đi đều là một chỉ thị khẳng định, nhưng cũng chính nghiên cứu đó phát hiện rằng các quy tắc sinh ngẫu nhiên tốt ngang các quy tắc do chuyên gia tuyển chọn, điều này khiến tính phân cực trở thành một đường nứt trong dữ liệu đó chứ không phải một cái đòn bẩy (Guardrails Beat Guidance, arXiv:2604.11088; các giới hạn của nó được trình bày trong phụ lục 0520). Đây là một nghiên cứu khác với nghiên cứu về hình thức mã hóa ở trên (Compact Constraint Encoding, arXiv:2604.07192), vốn thay đổi cách một quy tắc được viết ra và thấy rằng điều đó chẳng tạo ra khác biệt nào cả.
3. Gắn ngoại lệ vào quy tắc, trong cùng một câu hoặc ngay câu kế tiếp. Không bao giờ để ở một mục khác, và cũng không bao giờ để nó chẳng ở đâu cả.
4. Gắn nhãn cho từng quy tắc: được cưỡng chế / một phần / khuyến nghị. Nếu bạn không nêu được tên cơ chế, thì nó là khuyến nghị — hãy viết đúng như vậy, đừng làm tròn lên.
5. Đặt ranh giới không thể đảo ngược lên đầu tiên. Trong một repository công khai thì đó là quy tắc về tiết lộ thông tin; trong một hệ thống production thì đó là quy tắc về hành động phá hủy. Thứ tự là một tín hiệu, và mục đầu tiên là mục được đọc.
6. Cắt bớt cho đến khi một con người sẽ chịu đọc lại nó. Lý do chịu lực lại chính là lý do chưa được đo: không ai bảo trì một tài liệu mà họ đã thôi đọc, và một tệp quy tắc không được bảo trì chính là nơi các mâu thuẫn tụ lại. Lập luận về chi phí thì còn đang tranh cãi — một nghiên cứu có kiểm soát cho rằng phần độ dài tăng thêm khiến chi phí suy luận đội lên hơn 20 %, trong khi một tệp quy tắc được đo riêng lại cho ra −16.58 % token đầu ra và −28.64 % thời gian thực (phụ lục 0520). Bối cảnh thiết lập khác nhau, nên không con số nào phân xử được con số kia. Hãy cắt vì người đọc.

Những gì nó không thể làm#

Nó không thể làm cho agent giỏi hơn, và nó không thể cưỡng chế bất cứ điều gì. Cả hai nửa đều quan trọng. Nửa đầu nghĩa là một tệp quy tắc là công cụ sai cho chuyện "mô hình cứ làm sai X" — đó là vấn đề năng lực, và chỉ dẫn thì, theo đo đạc, không sửa được nó. Nửa sau nghĩa là mọi câu trong tệp, dù mạnh mẽ đến đâu, cũng chỉ là một khuynh hướng: nó định hình cái gì có khả năng xảy ra, chứ không bao giờ định hình cái gì là có thể.

Nếu một quy tắc buộc phải được giữ ngay cả khi không ai đọc, thì nó không phải là quy tắc lớp 1. Nó là một cổng lớp 2 mà chưa được xây.

Các kiểu thất bại#

Xong khi#

• Mọi quy tắc đều vượt qua câu "điều này có đúng với một tác vụ mà tôi chưa nghĩ tới hay không?"
• Mọi quy tắc đều được gắn nhãn được cưỡng chế / một phần / khuyến nghị, và mỗi quy tắc được cưỡng chế đều nêu tên cơ chế của nó
• Mọi ngoại lệ đều được viết ngay cạnh quy tắc mà nó bổ nghĩa
• Ranh giới không thể đảo ngược nằm ở mục đầu tiên
• Một người chưa từng thấy dự án này có thể theo được nó mà không phải hỏi câu nào

Tiếp theo: Lớp 2 — cổng cơ học, lớp duy nhất giữ được ngay cả khi không ai đọc.

Layer 2 — The mechanical gate#

Survival toolbox, part 2 of 5 · Start here · previous: Layer 1 — the standing rule file · next: Layer 3 — the named ritual

In one sentence#

Something that refuses — including when nobody is looking.

An example: sales#

Who. Somebody in sales preparing quotes with an agent. The job. Send a quote out. What goes wrong. One goes out with an unapproved price. Everyone had agreed beforehand that this must never happen — and that rule existed nowhere except in people's heads. What you build. Something that stops: a template that will not send without the price field, an approval step nobody can skip. Not the sentence "please always get it approved".

What you do today#

Take the one rule whose breach cannot be undone — not the one that annoys you most. Build something that stands in its way. If you cannot build anything, it is not a check but an agreement: then it belongs in layer 1, and at least you know what you are trusting.

What it is#

A program that refuses. A pre-commit hook, a CI job, a server-side rule — something that exits non-zero and stops the work when a condition is violated.

It is the only layer in the toolbox that holds when nobody is reading, and it is therefore the one worth building second rather than last.

The failure it prevents#

The rule everyone agrees with and nobody applies. Not disagreement — agreement plus schedule pressure. Layer 1 states the rule; layer 2 is what makes the statement load-bearing at 18:40 on a Friday.

What belongs in it#

Not every rule. Gates cost real maintenance and every one you add is another thing that can be wrong, so choose by irreversibility, not by annoyance:

The asymmetry is the whole selection rule: gate what you cannot take back.

Outside software#

A gate is anything that refuses. Software has hooks and CI; everywhere else has the form that will not submit without the field, the payment that needs a second signature, the checklist an aircraft cannot move without, the approval step a workflow tool will not skip. The properties that decide whether they work are identical: it must be automatic, it must fail closed, and the person it stops must not be the person who can wave it through.

The reason software examples dominate this page is not that the layer is technical. It is that in software the gate is cheap to build, so you can see all six failure modes below in one small system.

How to build it#

1. Pick the rule whose violation you could not undo. Start there, not with the rule that irritates you most this week.
2. Prove it red before you wire it up. Craft an input that must fail, run the check, watch it exit non-zero for the right reason. A gate that has never been seen red is a gate nobody has tested — and a check that silently matches nothing looks exactly like a check that passes.
3. Wire it in both places. Locally for speed, server-side for truth:

Git never installs hooks. A fresh clone runs unguarded until somebody executes your installer once. If the check exists only locally, then every contributor who skipped that step is running with no gate, and every pipeline stays green while it happens.

1. Fail closed. A missing tool, a missing config file, a skipped stage, an unreadable input — each must exit non-zero. A gate that exits 0 when it cannot run is worse than no gate: it produces the green tick that stops anyone looking.
2. Make it say what it loaded. Print the pattern file it read, the file count it scanned, the rules it applied. A gate running at half strength — half its configuration absent, no error — is indistinguishable from a healthy one, and stays that way for months.
3. Print the reason, not the bypass. If an escape hatch exists, document it where the policy is, not in the failure message. A message that fires daily and offers its own off switch teaches the off switch.
4. Gate the gate. Whatever verifies that the hooks are installed must itself be run by something automatic. Otherwise it is documentation with an exit code.

What it cannot do#

A gate is a fixed proxy for what you meant, and fixity is its failure mode. It checks a condition; you cared about an intent. The two agree until they do not, and the gap is where every bypass lives — the allowlisted command with a flag that turns it into arbitrary execution, the validator that gets monkey-patched, the check whose green tick becomes the goal.

The introduction↗ has the measured version: reward hacking in 30.4% of runs on one evaluation; a benchmark-attack study reaching near-perfect scores without solving a single task; and, in a disclosed vulnerability, an agent writing an auto-approve setting into a config file and switching off its own gate.

So build the gate, and do not read its green tick as verification. It constrains action. It does not contain the intent.

Failure modes#

Each of these is a real pattern, not a hypothetical; all six have been observed in one small public repository whose rules were classified against the mechanisms that actually exist (see Part 3 of the introduction↗).

The last two were added on 2026-09-03 from reading ten public skill repositories, where the first appeared four separate times in projects that otherwise take great care, and the second once in an exact form worth studying — see What the public corpus shows. Neither is an argument against gates. Both are arguments for asking, of every gate you have, which process runs it and what it would say to somebody trying to fix things.

Done when#

• The check has been seen red on a crafted bad input, for the right reason
• It runs locally and server-side, and both run the same code
• It exits non-zero when it cannot run — missing tool, missing config, skipped stage
• It prints what it loaded, so half-strength operation is visible
• The failure message names the reason, not the bypass
• Something automatic verifies that the hooks are installed

Next: Layer 3 — the named ritual, now that there is something underneath it worth trusting.

Schicht 2 — Das mechanische Gate#

Survival-Toolbox, Teil 2 von 5 · Hier beginnen · zurück: Schicht 1 — die feste Regeldatei · weiter: Schicht 3 — das benannte Ritual

In einem Satz#

Etwas, das sich weigert — und zwar auch dann, wenn niemand hinschaut.

Ein Beispiel: Sales#

Wer. Jemand im Vertrieb, der Angebote mit einem Agenten vorbereitet. Die Aufgabe. Ein Angebot rausschicken. Was schiefgeht. Einmal geht eines ohne freigegebenen Preis raus. Alle waren sich vorher einig, dass das nie passieren darf — und genau diese Regel stand nirgends, ausser in den Köpfen. Was du baust. Etwas, das nicht weitergeht: eine Vorlage, die ohne Preisfeld nicht absendet, ein Freigabeschritt, den niemand überspringen kann. Nicht der Satz „bitte immer freigeben lassen".

Was du heute tust#

Nimm die eine Regel, deren Bruch sich nicht rückgängig machen lässt — nicht die, die dich am meisten nervt. Und baue etwas, das dabei stehen bleibt. Wenn du nichts bauen kannst, ist es keine Prüfung, sondern eine Absprache: dann gehört sie in Schicht 1, und du weisst wenigstens, worauf du dich verlässt.

Was es ist#

Ein Programm, das sich weigert. Ein pre-commit-Hook, ein CI-Job, eine serverseitige Regel — etwas, das mit ungleich 0 endet und die Arbeit anhält, wenn eine Bedingung verletzt ist.

Es ist die einzige Schicht der Toolbox, die hält, wenn niemand hinschaut, und deshalb die, die man an zweiter Stelle baut statt an letzter.

Der Fehler, den es verhindert#

Die Regel, der alle zustimmen und die niemand anwendet. Nicht Uneinigkeit — Zustimmung plus Termindruck. Schicht 1 formuliert die Regel; Schicht 2 macht die Formulierung freitags um 18:40 tragend.

Was hineingehört#

Nicht jede Regel. Gates kosten echte Pflege, und jedes weitere ist ein weiteres Ding, das falsch sein kann. Also wählt man nach Irreversibilität, nicht nach Ärgernis:

Die Asymmetrie ist die ganze Auswahlregel: gate, was du nicht zurücknehmen kannst.

Ausserhalb der Software#

Ein Gate ist alles, was sich weigert. Software hat Hooks und CI; überall sonst gibt es das Formular, das ohne das Feld nicht abschickt, die Zahlung, die eine zweite Unterschrift braucht, die Checkliste, ohne die ein Flugzeug nicht rollt, den Freigabeschritt, den ein Workflow-Werkzeug nicht überspringt. Die Eigenschaften, die über das Funktionieren entscheiden, sind dieselben: automatisch, fail closed, und wer aufgehalten wird, darf nicht derselbe sein, der durchwinken kann.

Dass auf dieser Seite Software-Beispiele überwiegen, liegt nicht daran, dass die Schicht technisch wäre. Es liegt daran, dass ein Gate in der Software billig zu bauen ist — man sieht alle sechs Versagensmodi unten in einem einzigen kleinen System.

Wie man es baut#

1. Die Regel wählen, deren Verletzung sich nicht rückgängig machen lässt. Dort anfangen, nicht bei der, die diese Woche am meisten nervt.
2. Rot beweisen, bevor man es verdrahtet. Eine Eingabe bauen, die scheitern muss, die Prüfung laufen lassen, zusehen, wie sie aus dem richtigen Grund mit ungleich 0 endet. Ein Gate, das nie rot gesehen wurde, ist ein Gate, das niemand getestet hat — und eine Prüfung, die still auf nichts matcht, sieht genauso aus wie eine, die durchgeht.
3. An beiden Stellen verdrahten. Lokal für Tempo, serverseitig für Wahrheit:

Git installiert Hooks nie. Ein frischer Klon läuft ungesichert, bis jemand den Installer einmal ausführt. Existiert die Prüfung nur lokal, arbeiten alle, die diesen Schritt übersprungen haben, ohne Gate — und jede Pipeline bleibt grün, während es passiert.

1. Fail closed. Fehlendes Werkzeug, fehlende Konfigurationsdatei, übersprungene Stufe, unlesbare Eingabe — jedes davon muss mit ungleich 0 enden. Ein Gate, das mit 0 endet, wenn es nicht laufen kann, ist schlechter als kein Gate: es erzeugt den grünen Haken, der jedes Nachsehen beendet.
2. Es soll sagen, was es geladen hat. Die gelesene Musterdatei, die Zahl der geprüften Dateien, die angewandten Regeln. Ein Gate auf halber Kraft — die halbe Konfiguration fehlt, kein Fehler — ist von einem gesunden nicht zu unterscheiden und bleibt es monatelang.
3. Den Grund drucken, nicht den Ausweg. Gibt es einen Notausgang, gehört er dorthin, wo die Politik steht, nicht in die Fehlermeldung. Eine Meldung, die täglich feuert und ihren eigenen Ausschalter anbietet, bringt den Ausschalter bei.
4. Das Gate gaten. Was auch immer prüft, dass die Hooks installiert sind, muss selbst von etwas Automatischem ausgeführt werden. Sonst ist es Dokumentation mit einem Exit-Code.

Was es nicht kann#

Ein Gate ist ein fixer Proxy für das Gemeinte, und die Fixiertheit ist sein Versagensmodus. Es prüft eine Bedingung; gemeint war eine Absicht. Die beiden stimmen überein, bis sie es nicht mehr tun, und in dieser Lücke wohnt jede Umgehung — der erlaubte Befehl mit dem Flag, das ihn zu beliebiger Ausführung macht; der Validator, der gepatcht wird; die Prüfung, deren grüner Haken zum Ziel wird.

Die Einführung↗ hat die gemessene Fassung: Reward Hacking in 30,4 % der Läufe einer Evaluation; eine Benchmark-Angriffsstudie, die nahezu perfekte Werte erreicht, ohne eine einzige Aufgabe zu lösen; und, in einer offengelegten Schwachstelle, ein Agent, der eine Auto-Approve-Einstellung in eine Konfigurationsdatei schrieb und damit sein eigenes Gate abschaltete.

Also: das Gate bauen — und seinen grünen Haken nicht als Verifikation lesen. Es begrenzt Handlung. Es enthält die Absicht nicht.

Versagensmodi#

Jeder davon ist ein reales Muster, kein hypothetisches; alle sechs wurden in einem kleinen öffentlichen Repository beobachtet, dessen Regeln gegen die tatsächlich existierenden Mechanismen klassifiziert wurden (siehe Teil 3 der Einführung↗).

Die letzten beiden kamen am 2026-09-03 dazu, aus der Lektüre von zehn öffentlichen Skill-Repositories: das erste tauchte dort viermal getrennt auf, in Projekten, die sonst grosse Sorgfalt zeigen, das zweite einmal in einer Form, die das Studium lohnt — siehe Was das öffentliche Korpus zeigt. Keines von beiden ist ein Argument gegen Gates. Beide sind Argumente dafür, bei jedem Gate, das man hat, zu fragen: welcher Prozess führt es aus, und was sagt es jemandem, der etwas reparieren will?

Fertig, wenn#

• Die Prüfung wurde an einer gebauten Fehleingabe rot gesehen, aus dem richtigen Grund
• Sie läuft lokal und serverseitig, und beide führen denselben Code aus
• Sie endet mit ungleich 0, wenn sie nicht laufen kann — fehlendes Werkzeug, fehlende Konfiguration, übersprungene Stufe
• Sie druckt, was sie geladen hat, damit Halbkraft sichtbar wird
• Die Fehlermeldung benennt den Grund, nicht die Umgehung
• Etwas Automatisches prüft, dass die Hooks installiert sind

Weiter: Schicht 3 — das benannte Ritual, jetzt, wo darunter etwas liegt, dem man trauen kann.

Lớp 2 — Cổng cơ học#

Bộ công cụ sinh tồn, phần 2 trong 5 · Bắt đầu tại đây · trước đó: Lớp 1 — tệp quy tắc thường trực · tiếp theo: Lớp 3 — nghi thức có tên

Tóm trong một câu#

Một thứ biết từ chối — kể cả khi không ai để mắt tới.

Một ví dụ: bán hàng#

Ai. Một người bên bán hàng chuẩn bị báo giá cùng với agent. Công việc. Gửi một bản báo giá đi. Điều gì hỏng. Một bản báo giá được gửi đi với mức giá chưa được duyệt. Trước đó mọi người đều đã đồng ý rằng chuyện này tuyệt đối không được xảy ra — và quy tắc ấy chẳng tồn tại ở đâu ngoài trong đầu người ta. Bạn xây gì. Một thứ biết chặn lại: một mẫu báo giá không cho gửi khi thiếu trường giá, một bước phê duyệt không ai bỏ qua được. Không phải câu "làm ơn luôn xin duyệt nhé".

Việc bạn làm hôm nay#

Hãy lấy đúng cái quy tắc mà vi phạm nó là không thể hoàn tác — chứ không phải cái quy tắc làm bạn khó chịu nhất. Xây một thứ đứng chắn đường nó. Nếu bạn không xây được gì cả, thì đó không phải một phép kiểm tra mà là một thỏa thuận: khi đó nó thuộc về lớp 1, và ít nhất bạn cũng biết mình đang đặt niềm tin vào cái gì.

Nó là gì#

Một chương trình biết từ chối. Một hook pre-commit, một job CI, một quy tắc phía máy chủ — một thứ thoát ra với mã khác 0 và chặn công việc lại khi một điều kiện bị vi phạm.

Đây là lớp duy nhất trong bộ công cụ giữ được ngay cả khi không ai đọc, và vì thế nó là lớp đáng xây thứ hai chứ không phải sau cùng.

Thất bại mà nó ngăn chặn#

Cái quy tắc ai cũng đồng tình và không ai áp dụng. Không phải bất đồng — mà là đồng tình cộng với áp lực tiến độ. Lớp 1 phát biểu quy tắc; lớp 2 là thứ khiến phát biểu ấy chịu lực được vào 18:40 một chiều thứ Sáu.

Cái gì thuộc về nó#

Không phải mọi quy tắc. Cổng tốn công bảo trì thật sự và mỗi cổng bạn thêm vào lại là thêm một thứ có thể sai, nên hãy chọn theo tính không thể đảo ngược, chứ không theo mức độ phiền toái:

Sự bất đối xứng đó chính là toàn bộ quy tắc chọn lựa: hãy đặt cổng cho những gì bạn không rút lại được.

Bên ngoài phần mềm#

Cổng là bất cứ thứ gì biết từ chối. Phần mềm có hook và CI; mọi nơi khác có cái biểu mẫu không cho gửi khi thiếu trường, khoản thanh toán cần chữ ký thứ hai, bản checklist mà thiếu nó thì máy bay không được lăn bánh, bước phê duyệt mà công cụ workflow không cho bỏ qua. Những tính chất quyết định chúng có hiệu quả hay không thì giống hệt nhau: nó phải tự động, nó phải fail closed, và người bị nó chặn không được là người có quyền phẩy tay cho qua.

Lý do các ví dụ phần mềm chiếm ưu thế trên trang này không phải vì lớp này mang tính kỹ thuật. Mà vì trong phần mềm thì cổng rẻ để xây, nên bạn có thể thấy cả sáu kiểu thất bại bên dưới trong một hệ thống nhỏ duy nhất.

Cách xây dựng nó#

1. Chọn cái quy tắc mà vi phạm nó thì bạn không thể hoàn tác. Hãy bắt đầu từ đó, chứ không phải từ cái quy tắc làm bạn bực mình nhất tuần này.
2. Hãy chứng kiến nó đỏ trước khi đấu nối nó. Hãy dựng một đầu vào chắc chắn phải trượt, chạy phép kiểm tra, và xem nó thoát ra với mã khác 0 vì đúng lý do. Một cổng chưa từng được thấy đỏ là một cổng chưa ai kiểm thử — và một phép kiểm tra lặng lẽ không khớp gì cả thì trông y hệt một phép kiểm tra đã pass.
3. Đấu nối nó ở cả hai nơi. Cục bộ để nhanh, phía máy chủ để lấy sự thật:

Git không bao giờ tự cài hook. Một clone mới sẽ chạy mà không có bảo vệ cho tới khi có ai đó chạy trình cài đặt của bạn một lần. Nếu phép kiểm tra chỉ tồn tại cục bộ, thì mọi người đóng góp đã bỏ qua bước đó đều đang chạy mà không có cổng nào, và mọi pipeline vẫn xanh trong suốt thời gian đó.

1. Fail closed. Một công cụ bị thiếu, một tệp cấu hình bị thiếu, một stage bị bỏ qua, một đầu vào không đọc được — mỗi trường hợp đều phải thoát ra với mã khác 0. Một cổng thoát ra 0 khi nó không chạy được còn tệ hơn không có cổng: nó tạo ra dấu tích xanh khiến chẳng ai buồn nhìn nữa.
2. Bắt nó nói ra nó đã nạp những gì. Hãy in ra tệp mẫu (pattern file) nó đã đọc, số tệp nó đã quét, các quy tắc nó đã áp dụng. Một cổng đang chạy ở nửa công suất — mất một nửa cấu hình, không báo lỗi gì — thì không phân biệt được với một cổng khỏe mạnh, và cứ như thế suốt nhiều tháng.
3. In ra lý do, chứ đừng in ra đường vòng. Nếu có một lối thoát hiểm, hãy ghi nó ở chỗ đặt chính sách, chứ không phải trong thông điệp báo lỗi. Một thông điệp nổ ra hằng ngày mà lại tự chìa ra cái công tắc tắt của chính nó thì đang dạy người ta dùng cái công tắc đó.
4. Hãy đặt cổng cho chính cái cổng. Bất cứ thứ gì xác minh rằng các hook đã được cài thì bản thân nó cũng phải được một thứ tự động chạy. Nếu không thì nó chỉ là tài liệu có kèm mã thoát.

Những gì nó không thể làm#

Một cổng là một đại diện cố định cho điều bạn muốn nói, và chính tính cố định ấy là kiểu thất bại của nó. Nó kiểm tra một điều kiện; còn bạn thì quan tâm tới một ý định. Hai thứ đó khớp nhau cho tới khi không khớp nữa, và khoảng cách ấy là nơi trú ngụ của mọi cách né tránh — cái lệnh nằm trong allowlist nhưng có một cờ biến nó thành thực thi tùy ý, cái validator bị monkey-patch, cái phép kiểm tra mà dấu tích xanh của nó trở thành mục tiêu.

Phần giới thiệu↗ có phiên bản đã đo được: reward hacking trong 30.4% số lần chạy trên một bài đánh giá; một nghiên cứu tấn công benchmark đạt điểm gần như hoàn hảo mà không giải được lấy một tác vụ nào; và, trong một lỗ hổng đã được công bố, một agent ghi một thiết lập tự-động-phê-duyệt vào một tệp cấu hình và tắt luôn cái cổng của chính nó.

Vậy nên hãy xây cổng, và đừng đọc dấu tích xanh của nó như một sự xác minh. Nó ràng buộc hành động. Nó không chứa đựng được ý định.

Các kiểu thất bại#

Mỗi kiểu dưới đây là một mẫu hình có thật, không phải giả định; cả sáu đều đã được quan sát trong một repository công khai nhỏ, nơi các quy tắc được phân loại đối chiếu với những cơ chế thực sự tồn tại (xem Phần 3 của phần giới thiệu↗).

Hai kiểu cuối được bổ sung vào 2026-09-03 từ việc đọc mười repository skill công khai, nơi kiểu thứ nhất xuất hiện bốn lần riêng biệt trong những dự án mà mặt khác vốn rất cẩn thận, còn kiểu thứ hai xuất hiện một lần dưới một hình thái chính xác đáng để nghiên cứu — xem Corpus công khai cho thấy điều gì. Không cái nào là lý lẽ chống lại việc dùng cổng. Cả hai đều là lý lẽ cho việc phải hỏi, với mọi cổng bạn đang có, rằng tiến trình nào chạy nó và nó sẽ nói gì với một người đang cố sửa chữa mọi thứ.

Xong khi#

• Phép kiểm tra đã được thấy đỏ trên một đầu vào xấu được dựng có chủ đích, và vì đúng lý do
• Nó chạy cục bộ và phía máy chủ, và cả hai chạy cùng một đoạn mã
• Nó thoát ra với mã khác 0 khi nó không chạy được — thiếu công cụ, thiếu cấu hình, stage bị bỏ qua
• Nó in ra những gì nó đã nạp, để tình trạng chạy ở nửa công suất là nhìn thấy được
• Thông điệp báo lỗi nêu tên lý do, chứ không nêu đường vòng
• Có một thứ tự động xác minh rằng các hook đã được cài

Tiếp theo: Lớp 3 — nghi thức có tên, giờ thì đã có một thứ bên dưới nó đáng để tin cậy.

Layer 3 — The named ritual (a skill)#

Survival toolbox, part 3 of 5 · Start here · previous: Layer 2 — the mechanical gate · next: Layer 4 — the written record

In one sentence#

A recurring job written down once, so that it goes the same way every time.

An example: HR#

Who. HR preparing onboarding with an agent's help. The job. Somebody new starts — accounts, introductions, first week. What goes wrong. Every onboarding runs slightly differently, and under pressure the same things drop out: the introduction to the team, the check-in after two weeks. Not because they are unimportant, but because their value is invisible at the moment of dropping them. What you build. A file called "onboarding" with a trigger ("somebody new has signed"), the steps in the order they are actually done — and the point at which the agent stops and asks a human.

What you do today#

Take the procedure you explained most often this month and write it down the way you actually did it last time — including the step you skipped. That one matters most.

What it is#

A repeatable job written down once, so it goes the same way every time: a file with a name, a trigger, an ordered set of steps and a defined end state. The closeout before you stop work. The preparation of a merge request. The handover.

Unlike layer 1, the body is not loaded until the agent judges the skill relevant — so it costs almost nothing until then. Unlike layer 2, nothing makes it run.

The failure it prevents#

The multi-step job done differently each time, and worst under pressure. The steps that get dropped are never random: they are the ones whose value is not visible at the moment of dropping them — the record, the cleanup, the note explaining why the rejected option was rejected.

What belongs in it — when a job earns a file#

All four must hold:

A step that only forbids is unfinished#

The strongest single intervention measured in this area was not a firmer prohibition. It was giving the agent a licensed alternative action for the moment of conflict — what to do instead, at the point where following the ritual has become expensive. In one benchmark that change moved the exploit rate on one model from over 85 % to 1 %; the same wording moved another model to 33 %, so take the shape rather than the number (appendix 0520).

Applied here: every step that says do not names what to do instead. "Do not merge without a review" becomes "if no reviewer is available within the hour, mark it blocked and say so in the channel". The escape-hatch policy below is where the legitimate exceptions live, and it exists for the same reason — a step nobody can follow does not stay unfollowed quietly, it becomes a step everybody skips.

When not to write one#

A skill that restates what the model already does well has negative value: it costs context in the listing the agent carries on every task, and it competes for attention with the rules that matter. Four tests, and a proposal has to pass all four:

The same four tests as a path, with the exit each failure takes:

"Nothing matched" is a claim about a search you ran, not a feeling. If you cannot quote the search, you have not run it.

Outside software#

A named ritual is a standard operating procedure with a trigger. The month-end close. The handover template before annual leave. The pre-flight checklist. What makes the agent version different is only the trigger: a person consults a procedure when they recognise the situation, and an agent consults it when it judges the description relevant — which is why the description carries so much more weight here than in a human SOP, and why it is the part most often written last.

How to build it#

1. Write the description first, not last. At startup the agent pre-loads only the name and description of every installed skill; the body is read later, and only if the agent judges the skill relevant to the task in front of it. The description is therefore the whole of what that decision has to go on. A situation-shaped description — "closing out a session before compaction" — gives it something to recognise; a category-shaped one — "session utilities" — does not. This is where most unused skills die, and it is the part people write in a hurry after the interesting work is done.

Two qualifications, both from the vendor's own documentation, and both worth knowing because they are what separates a rule from a superstition. It is a judgement, not a match. Anthropic's own skill-creator warns that a query may fail to trigger a skill even when the description matches perfectly, because an agent consults one only for work it cannot easily do itself. And the listing is budgeted. Every skill's name is always present, but when the listing overflows its budget — one per cent of the context window by default — descriptions are shortened or dropped, least-used first. So a skill can be perfectly described and still never fire. What was checked, and where, is in what we checked.

1. Write the steps as you actually did them the last time — including the step you skipped, and why skipping it was tempting.
2. Add the activation gate. What must be true before step 1: the right branch, the right repository, a configuration present, a prior step completed. A ritual that runs half-configured produces a confident wrong result, which is worse than not running.
3. Write the non-goals. Explicitly: what this deliberately does not do. Without them two skills grow into each other and the session has to guess which one is current.
4. Write the stop conditions. The point at which it stops and hands back to a human. A ritual with no stop condition runs past the moment it should have asked.
5. Decide the escape-hatch policy — who may skip it, on what grounds, and where that is recorded. Undecided means "anyone, silently".

The anatomy of a skill file that survives#

What it cannot do#

Nothing makes it run. A ritual is advisory in the strictest sense: it is a file that describes a procedure, and no mechanism observes whether the procedure happened. Worse, its output often looks identical whether or not the ritual was followed — which means an omission leaves no trace and cannot be found afterwards.

So: if a step must happen, it is not a ritual step. It is a layer-2 gate. And if you want to be able to tell afterwards whether the ritual ran, that is layer 4 — the record is what makes the omission visible.

Failure modes#

Done when#

• The description names a situation, and an agent reading only that line would judge it relevant
• The preconditions are written, and the ritual fails loudly when they are unmet
• The non-goals are written
• The stop conditions are written
• The escape-hatch policy is decided and recorded
• Someone else could run it from the file alone
• Every step that must happen has been moved to layer 2

What we checked#

The claim above is the only one in this series about the internals of somebody else's product. It therefore carries its sources instead of asserting them. Eight surfaces were searched on 2026-09-06, in this order of expected authority. Only the first three could settle the mechanism; the rest can show that other people observe the same behaviour, which is a different and weaker thing.

Tier A is the vendor's own documentation, B is vendor-adjacent — an Anthropic repository, or an identifiable maintainer speaking on the record — and C is everyone else. The column is not decoration. A pile of tier-C reports, however large, never promotes into a statement about how the tool works; it was A and B that answered the question. What tier C bought is the two qualifications in the text above, which is why they are there and the rest of the pile is not.

References#

• Agent Skills — overview (read 2026-09-06)
• Agent Skills — best practices (read 2026-09-06)
• Skills in Claude Code (read 2026-09-06)
• Equipping agents for the real world with Agent Skills (read 2026-09-06)
• anthropics/skills — the skill-creator skill (read 2026-09-06)
• The listing budget, stated by a maintainer (read 2026-09-06)
• A skill that did not fire on its own trigger word (read 2026-09-06)

Next: Layer 4 — the written record, which is how you find out afterwards whether any of this happened.

Schicht 3 — Das benannte Ritual (ein Skill)#

Survival-Toolbox, Teil 3 von 5 · Hier beginnen · zurück: Schicht 2 — das mechanische Gate · weiter: Schicht 4 — der schriftliche Nachweis

In einem Satz#

Ein wiederkehrender Ablauf, einmal aufgeschrieben, damit er jedes Mal gleich läuft.

Ein Beispiel: HR#

Wer. HR, das Onboarding mit Unterstützung eines Agenten vorbereitet. Die Aufgabe. Eine neue Person fängt an — Zugänge, Einführung, erste Woche. Was schiefgeht. Jedes Onboarding läuft ein bisschen anders, und unter Druck fällt immer dasselbe weg: die Vorstellung im Team, das Gespräch nach zwei Wochen. Nicht weil es unwichtig wäre, sondern weil sein Wert im Moment des Weglassens nicht sichtbar ist. Was du baust. Eine Datei „Onboarding" mit einem Auslöser („eine neue Person hat unterschrieben"), den Schritten in der Reihenfolge, in der sie wirklich gemacht werden — und dem Punkt, an dem der Agent aufhört und einen Menschen fragt.

Was du heute tust#

Nimm den Ablauf, den du diesen Monat am häufigsten erklärt hast, und schreib ihn so auf, wie du ihn beim letzten Mal wirklich gemacht hast — einschliesslich des Schritts, den du übersprungen hast. Der ist der wichtigste.

Was es ist#

Eine wiederkehrende Aufgabe, einmal aufgeschrieben, damit sie jedes Mal gleich läuft: eine Datei mit Namen, Auslöser, geordneten Schritten und definiertem Endzustand. Der Abschluss, bevor man aufhört. Die Vorbereitung eines Merge Requests. Die Übergabe.

Anders als Schicht 1 wird der Körper erst geladen, wenn der Agent die Skill für einschlägig hält — bis dahin kostet er fast nichts. Anders als Schicht 2 sorgt nichts dafür, dass es läuft.

Der Fehler, den es verhindert#

Der mehrstufige Ablauf, jedes Mal anders ausgeführt und am schlechtesten unter Druck. Die Schritte, die wegfallen, sind nie zufällig: es sind die, deren Wert im Moment des Weglassens nicht sichtbar ist — der Nachweis, das Aufräumen, die Notiz, warum die verworfene Option verworfen wurde.

Was hineingehört — wann eine Aufgabe eine Datei verdient#

Alle vier müssen gelten:

Ein Schritt, der nur verbietet, ist unfertig#

Der stärkste einzelne Eingriff, der in diesem Feld gemessen wurde, war kein härteres Verbot. Es war, dem Agenten eine erlaubte Alternativhandlung für den Moment des Konflikts zu geben — was stattdessen zu tun ist, an der Stelle, an der das Befolgen des Rituals teuer geworden ist. In einem Benchmark bewegte diese Änderung die Ausbeutungsrate bei einem Modell von über 85 % auf 1 %; dieselbe Formulierung brachte ein anderes Modell auf 33 % — nimm also die Form, nicht die Zahl (Anhang 0520).

Hier angewandt: jeder Schritt, der nicht sagt, benennt, was stattdessen zu tun ist. Aus „nicht ohne Review mergen" wird „wenn binnen einer Stunde niemand reviewen kann, als blockiert markieren und das im Kanal sagen". Die Escape-Hatch-Policy weiter unten ist der Ort für die legitimen Ausnahmen, und sie existiert aus demselben Grund — ein Schritt, den niemand befolgen kann, bleibt nicht still unbefolgt, er wird zu einem Schritt, den alle überspringen.

Wann man keinen schreibt#

Ein Skill, der wiederholt, was das Modell ohnehin gut kann, hat negativen Wert: er kostet Kontext in der Auflistung, die der Agent bei jeder Aufgabe mitführt, und er konkurriert um Aufmerksamkeit mit den Regeln, auf die es ankommt. Vier Tests, und ein Vorschlag muss alle vier bestehen:

Dieselben vier Tests als Weg, mit dem Ausgang, den jedes Scheitern nimmt:

„Nichts passte" ist eine Aussage über eine ausgeführte Suche, kein Gefühl. Wer die Suche nicht zitieren kann, hat sie nicht ausgeführt.

Ausserhalb der Software#

Ein benanntes Ritual ist eine Verfahrensanweisung mit einem Auslöser. Der Monatsabschluss. Die Übergabevorlage vor dem Urlaub. Die Checkliste vor dem Start. Was die Agenten-Fassung unterscheidet, ist allein der Auslöser: ein Mensch zieht ein Verfahren heran, wenn er die Situation erkennt, ein Agent, wenn er die Beschreibung für einschlägig hält — weshalb die Beschreibung hier weit mehr Gewicht trägt als in einer menschlichen Verfahrensanweisung, und weshalb sie der Teil ist, der am häufigsten zuletzt geschrieben wird.

Wie man es baut#

1. Die Beschreibung zuerst schreiben, nicht zuletzt. Beim Start lädt der Agent nur Name und Beschreibung jeder installierten Skill vor; der Körper wird später gelesen, und nur dann, wenn der Agent die Skill für die vorliegende Aufgabe als einschlägig beurteilt. Die Beschreibung ist damit alles, worauf sich diese Entscheidung stützen kann. Eine situationsförmige Beschreibung — „eine Session vor der Verdichtung abschliessen" — gibt ihr etwas zu erkennen; eine kategorienförmige — „Session-Werkzeuge" — nicht. Hier sterben die meisten ungenutzten Skills, und es ist der Teil, den man in Eile schreibt, nachdem die interessante Arbeit getan ist.

Zwei Einschränkungen, beide aus der Dokumentation des Herstellers selbst, und beide wissenswert, weil sie eine Regel von einem Aberglauben trennen. Es ist ein Urteil, kein Abgleich. Anthropics eigener skill-creator warnt, dass eine Anfrage eine Skill auch dann nicht auslösen kann, wenn die Beschreibung perfekt passt — ein Agent zieht eine Skill nur für Arbeit heran, die er nicht ohne Weiteres selbst erledigt. Und die Auflistung hat ein Budget. Der Name jeder Skill ist immer vorhanden, aber wenn die Auflistung ihr Budget überschreitet — voreingestellt ein Prozent des Kontextfensters — werden Beschreibungen gekürzt oder fallen weg, die am wenigsten genutzten zuerst. Eine Skill kann also perfekt beschrieben sein und trotzdem nie feuern. Was geprüft wurde und wo, steht unter was wir geprüft haben.

1. Die Schritte so schreiben, wie man sie beim letzten Mal wirklich gemacht hat — einschliesslich des Schritts, den man ausgelassen hat, und warum das Auslassen verlockend war.
2. Das Aktivierungs-Gate ergänzen. Was vor Schritt 1 wahr sein muss: der richtige Branch, das richtige Repository, eine vorhandene Konfiguration, ein abgeschlossener Vorschritt. Ein Ritual, das halb konfiguriert läuft, erzeugt ein selbstbewusstes falsches Ergebnis — schlimmer, als nicht zu laufen.
3. Die Nicht-Ziele schreiben. Ausdrücklich: was es bewusst nicht tut. Ohne sie wachsen zwei Skills ineinander, und die Session muss raten, welcher aktuell ist.
4. Die Abbruchbedingungen schreiben. Der Punkt, an dem es aufhört und an einen Menschen zurückgibt. Ein Ritual ohne Abbruchbedingung läuft über den Moment hinaus, an dem es hätte fragen müssen.
5. Die Politik für die Notausgänge entscheiden — wer darf überspringen, aus welchem Grund, und wo wird das festgehalten. Unentschieden heisst „alle, stillschweigend".

Die Anatomie einer Skill-Datei, die überlebt#

Was es nicht kann#

Nichts sorgt dafür, dass es läuft. Ein Ritual ist advisorisch im strengsten Sinn: eine Datei, die ein Verfahren beschreibt, und kein Mechanismus beobachtet, ob das Verfahren stattfand. Schlimmer: sein Ergebnis sieht oft gleich aus, ob es befolgt wurde oder nicht — eine Auslassung hinterlässt also keine Spur und lässt sich hinterher nicht finden.

Also: muss ein Schritt stattfinden, ist es kein Ritualschritt. Es ist ein Schicht-2-Gate. Und wer hinterher wissen will, ob das Ritual lief, braucht Schicht 4 — der Nachweis ist das, was die Auslassung sichtbar macht.

Versagensmodi#

Fertig, wenn#

• Die Beschreibung benennt eine Situation, und ein Agent, der nur diese Zeile liest, hielte sie für einschlägig
• Die Vorbedingungen stehen, und das Ritual scheitert laut, wenn sie fehlen
• Die Nicht-Ziele stehen
• Die Abbruchbedingungen stehen
• Die Politik für die Notausgänge ist entschieden und festgehalten
• Jemand anderes könnte es allein aus der Datei ausführen
• Jeder Schritt, der stattfinden muss, ist nach Schicht 2 verschoben

Was wir geprüft haben#

Die Behauptung oben ist die einzige dieser Reihe, die von der Innenmechanik eines fremden Produkts handelt. Sie führt deshalb ihre Quellen mit, statt sie zu behaupten. Acht Anlaufstellen wurden am 2026-09-06 durchsucht, in dieser Reihenfolge erwarteter Verbindlichkeit. Nur die ersten drei konnten den Mechanismus klären; der Rest kann zeigen, dass andere dasselbe beobachten — und das ist etwas anderes und Schwächeres.

Stufe A ist die Dokumentation des Herstellers selbst, B ist herstellernah — ein Anthropic-Repository oder eine namentlich erkennbare Maintainerin oder ein Maintainer, der öffentlich spricht — und C ist alles andere. Die Spalte ist keine Deko. Ein Stapel Stufe-C-Berichte wird, wie gross er auch sei, niemals zu einer Aussage darüber, wie das Werkzeug funktioniert; geklärt haben es A und B. Was Stufe C eingebracht hat, sind die beiden Einschränkungen oben — deshalb stehen sie im Text und der Rest des Stapels nicht.

Referenzen#

• Agent Skills — Übersicht (gelesen 2026-09-06)
• Agent Skills — Best Practices (gelesen 2026-09-06)
• Skills in Claude Code (gelesen 2026-09-06)
• Equipping agents for the real world with Agent Skills (gelesen 2026-09-06)
• anthropics/skills — die skill-creator-Skill (gelesen 2026-09-06)
• Das Budget der Auflistung, von einem Maintainer benannt (gelesen 2026-09-06)
• Eine Skill, die auf ihr eigenes Auslösewort nicht feuerte (gelesen 2026-09-06)

Weiter: Schicht 4 — der schriftliche Nachweis, mit dem man hinterher herausfindet, ob irgendetwas davon passiert ist.

Lớp 3 — Nghi thức có tên (một skill)#

Bộ công cụ sinh tồn, phần 3 trong 5 · Bắt đầu tại đây · trước đó: Lớp 2 — cổng cơ học · tiếp theo: Lớp 4 — bản ghi được viết ra

Tóm trong một câu#

Một công việc lặp đi lặp lại được viết ra một lần, để mỗi lần nó diễn ra theo cùng một cách.

Một ví dụ: HR#

Ai. Bộ phận HR chuẩn bị onboarding với sự trợ giúp của một agent. Công việc. Có người mới vào — tài khoản, giới thiệu, tuần đầu tiên. Điều gì hỏng. Mỗi lần onboarding lại chạy hơi khác nhau, và khi bị áp lực thì vẫn chính những thứ đó rơi rụng: phần giới thiệu với đội, buổi check-in sau hai tuần. Không phải vì chúng không quan trọng, mà vì giá trị của chúng vô hình ngay tại thời điểm bị bỏ đi. Bạn xây gì. Một tệp tên là "onboarding" với một trigger ("có người mới vừa ký"), các bước theo đúng thứ tự chúng thực sự được làm — và điểm mà tại đó agent dừng lại và hỏi con người.

Hôm nay bạn làm gì#

Hãy lấy quy trình mà tháng này bạn phải giải thích nhiều lần nhất và viết nó ra đúng theo cách bạn thực sự đã làm lần gần nhất — bao gồm cả bước bạn đã bỏ qua. Bước đó mới là quan trọng nhất.

Nó là gì#

Một công việc lặp lại được viết ra một lần, để mỗi lần nó diễn ra theo cùng một cách: một tệp có tên, một trigger, một tập các bước có thứ tự và một trạng thái kết thúc được định nghĩa. Phần đóng việc trước khi bạn ngừng làm. Việc chuẩn bị một merge request. Việc bàn giao.

Khác với lớp 1, phần thân chỉ được nạp khi agent đánh giá skill là phù hợp — nên trước đó nó gần như không tốn gì. Khác với lớp 2, không có gì bắt nó chạy.

Thất bại mà nó ngăn chặn#

Công việc nhiều bước, mỗi lần làm một khác, và tệ nhất là khi bị áp lực. Những bước bị bỏ rơi không bao giờ là ngẫu nhiên: chúng là những bước mà giá trị không hiện ra ngay tại thời điểm bị bỏ — bản ghi, việc dọn dẹp, ghi chú giải thích vì sao phương án bị loại đã bị loại.

Cái gì thuộc về nó — khi nào một công việc xứng đáng có một tệp riêng#

Cả bốn điều phải đúng:

Một bước chỉ biết cấm là một bước chưa hoàn chỉnh#

Can thiệp đơn lẻ mạnh nhất được đo trong lĩnh vực này không phải là một lệnh cấm cứng rắn hơn. Đó là việc trao cho agent một hành động thay thế được cho phép, dành cho khoảnh khắc xung đột — làm gì thay vào đó, tại điểm mà việc tuân theo nghi thức đã trở nên đắt đỏ. Trong một benchmark, thay đổi đó đã kéo tỉ lệ khai thác trên một mô hình từ hơn 85 % xuống 1 %; cùng cách diễn đạt ấy chỉ đưa một mô hình khác xuống 33 %, nên hãy lấy hình dạng chứ đừng lấy con số (phụ lục 0520).

Áp dụng vào đây: mọi bước nói không được đều nêu rõ phải làm gì thay vào đó. "Không được merge khi chưa có review" trở thành "nếu trong vòng một giờ không có ai review được, hãy đánh dấu là blocked và nói ra điều đó trong kênh". Chính sách cửa thoát hiểm ở dưới là nơi các ngoại lệ chính đáng cư trú, và nó tồn tại vì cùng một lý do — một bước không ai theo nổi sẽ không lặng lẽ nằm đó mà không được theo, nó trở thành một bước ai cũng bỏ qua.

Khi không nên viết một cái#

Một skill chỉ nhắc lại những gì mô hình vốn đã làm tốt thì có giá trị âm: nó tốn context trong danh sách mà agent mang theo ở mọi tác vụ, và nó cạnh tranh sự chú ý với những quy tắc thực sự quan trọng. Bốn phép thử, và một đề xuất phải vượt qua cả bốn:

Cũng bốn phép thử ấy dưới dạng một lối đi, kèm cửa ra mà mỗi lần trượt sẽ đi qua:

"Không có gì khớp" là một khẳng định về một lần tìm kiếm mà bạn đã chạy, không phải một cảm giác. Nếu bạn không trích dẫn được lần tìm kiếm đó, thì bạn chưa chạy nó.

Ngoài phạm vi phần mềm#

Một nghi thức có tên là một quy trình vận hành chuẩn có kèm trigger. Việc chốt sổ cuối tháng. Mẫu bàn giao trước kỳ nghỉ phép năm. Danh sách kiểm tra trước chuyến bay. Điều duy nhất làm phiên bản dành cho agent khác đi chính là trigger: một người tra cứu quy trình khi họ nhận ra tình huống, còn một agent tra cứu nó khi nó đánh giá phần mô tả là phù hợp — đó là lý do phần mô tả ở đây có sức nặng lớn hơn nhiều so với trong một SOP của con người, và cũng là lý do nó là phần thường bị viết sau cùng nhất.

Cách xây dựng nó#

1. Viết phần mô tả trước, không phải sau cùng. Khi khởi động, agent chỉ nạp trước tên và phần mô tả của mọi skill đã cài; phần thân được đọc sau, và chỉ khi agent đánh giá skill là phù hợp với tác vụ đang có. Vì vậy phần mô tả là toàn bộ những gì quyết định ấy có thể dựa vào. Một mô tả có hình dạng của một tình huống — "đóng một phiên làm việc trước khi compaction" — cho quyết định ấy một thứ để nhận ra; một mô tả có hình dạng của một hạng mục — "tiện ích cho phiên làm việc" — thì không. Đây là chỗ mà phần lớn các skill không bao giờ được dùng đến chết đi, và nó là phần người ta viết vội sau khi phần việc thú vị đã xong.

Hai điểm dè dặt, cả hai đều lấy từ chính tài liệu của nhà cung cấp, và cả hai đều đáng biết vì chúng là ranh giới giữa một quy tắc và một điều mê tín. Đó là một phán đoán, không phải một phép khớp. Chính skill-creator của Anthropic cảnh báo rằng một truy vấn có thể không kích hoạt được skill ngay cả khi phần mô tả khớp hoàn hảo, bởi agent chỉ tra cứu một skill cho công việc mà nó không tự làm được một cách dễ dàng. Và danh sách có ngân sách. Tên của mọi skill thì luôn có mặt, nhưng khi danh sách vượt ngân sách của nó — mặc định là một phần trăm cửa sổ context — các phần mô tả sẽ bị cắt ngắn hoặc bị bỏ, bắt đầu từ những skill ít được dùng nhất. Vậy nên một skill có thể được mô tả hoàn hảo mà vẫn không bao giờ chạy. Những gì đã được kiểm tra, và ở đâu, nằm trong những gì chúng tôi đã kiểm tra.

1. Viết các bước đúng như bạn đã thực sự làm lần gần nhất — bao gồm cả bước bạn đã bỏ qua, và vì sao việc bỏ qua nó lại hấp dẫn.
2. Thêm cổng kích hoạt. Điều gì phải đúng trước bước 1: đúng branch, đúng repository, một cấu hình đã có mặt, một bước trước đó đã hoàn tất. Một nghi thức chạy khi mới cấu hình được một nửa sẽ cho ra một kết quả sai đầy tự tin, và như thế còn tệ hơn là không chạy.
3. Viết ra các phi-mục-tiêu. Một cách tường minh: thứ này cố ý không làm những gì. Không có chúng thì hai skill sẽ mọc chồng vào nhau và phiên làm việc phải đoán xem cái nào là cái hiện hành.
4. Viết ra các điều kiện dừng. Điểm mà tại đó nó dừng lại và trả việc về cho con người. Một nghi thức không có điều kiện dừng sẽ chạy vượt qua cái khoảnh khắc lẽ ra nó phải hỏi.
5. Quyết định chính sách cửa thoát hiểm — ai được phép bỏ qua nó, với lý do gì, và điều đó được ghi lại ở đâu. Không quyết định nghĩa là "bất kỳ ai, một cách lặng lẽ".

Giải phẫu một tệp skill sống sót được#

Điều nó không làm được#

Không có gì bắt nó chạy. Một nghi thức mang tính khuyến nghị theo nghĩa chặt chẽ nhất: nó là một tệp mô tả một quy trình, và không có cơ chế nào quan sát xem quy trình đó có diễn ra hay không. Tệ hơn, đầu ra của nó thường trông y hệt nhau dù nghi thức có được tuân theo hay không — nghĩa là một lần bỏ sót không để lại dấu vết nào và về sau không thể tìm ra.

Vậy nên: nếu một bước bắt buộc phải xảy ra, thì nó không phải là một bước của nghi thức. Nó là một cổng thuộc lớp 2. Và nếu bạn muốn về sau có thể biết được nghi thức có chạy hay không, thì đó là lớp 4 — chính bản ghi mới làm cho việc bỏ sót nhìn thấy được.

Các kiểu thất bại#

Xong khi#

• Phần mô tả gọi tên một tình huống, và một agent chỉ đọc riêng dòng đó cũng sẽ đánh giá nó là phù hợp
• Các tiền điều kiện đã được viết ra, và nghi thức thất bại ầm ĩ khi chúng không được thỏa mãn
• Các phi-mục-tiêu đã được viết ra
• Các điều kiện dừng đã được viết ra
• Chính sách cửa thoát hiểm đã được quyết định và ghi lại
• Một người khác có thể chạy nó chỉ dựa vào tệp đó
• Mọi bước bắt buộc phải xảy ra đều đã được chuyển sang lớp 2

Những gì chúng tôi đã kiểm tra#

Khẳng định ở trên là khẳng định duy nhất trong loạt bài này nói về cơ chế bên trong sản phẩm của người khác. Vì vậy nó mang theo nguồn dẫn của mình thay vì chỉ tuyên bố. Tám nơi đã được tra cứu ngày 2026-09-06, theo thứ tự thẩm quyền dự kiến. Chỉ ba nơi đầu mới có thể giải quyết được cơ chế; phần còn lại chỉ cho thấy rằng người khác cũng quan sát thấy điều tương tự — và đó là một điều khác, yếu hơn.

Bậc A là tài liệu của chính nhà cung cấp, B là gần nhà cung cấp — một kho của Anthropic, hoặc một maintainer có danh tính rõ ràng phát biểu công khai — và C là tất cả những nguồn còn lại. Cột này không phải để trang trí. Một chồng báo cáo bậc C, dù lớn đến đâu, cũng không bao giờ trở thành một phát biểu về cách công cụ hoạt động; giải quyết được câu hỏi là A và B. Cái mà bậc C mang lại là hai điểm dè dặt ở trên — đó là lý do chúng có mặt trong bài, còn phần còn lại của chồng báo cáo thì không.

Tài liệu tham khảo#

• Agent Skills — tổng quan (đọc 2026-09-06)
• Agent Skills — best practices (đọc 2026-09-06)
• Skills trong Claude Code (đọc 2026-09-06)
• Equipping agents for the real world with Agent Skills (đọc 2026-09-06)
• anthropics/skills — skill-creator (đọc 2026-09-06)
• Ngân sách của danh sách, do một maintainer nêu ra (đọc 2026-09-06)
• Một skill không chạy dù prompt chứa đúng từ khoá kích hoạt của nó (đọc 2026-09-06)

Tiếp theo: Lớp 4 — bản ghi được viết ra, là cách để về sau bạn biết được liệu có điều nào trong số này thực sự đã xảy ra hay không.

Layer 4 — The written record#

Survival toolbox, part 4 of 5 · Start here · previous: Layer 3 — the named ritual · next: Layer 5 — index, triggers and upkeep

In one sentence#

A short note written before the work about what should happen — so that afterwards somebody can check whether it did.

An example: business analyst#

Who. An analyst who has worked through three options with an agent. The job. Recommend one of them. What goes wrong. Six weeks later somebody proposes exactly the option she rejected — well argued, so she checks it a second time. The reason for rejecting it existed only in her head. The result was saved; the rejected option was not. What you build. A note written beforehand: the goal in one sentence that could also be wrong — and under it "rejected, because …" with a checkable reason. "The form does not allow two contacts" stays checkable. "Wasn't a good idea" does not.

What you do today#

On the next job: three lines before you start. Goal · steps · what you are deliberately not doing. Write it afterwards and you record only the result — which was visible anyway.

What it is#

A record of what was supposed to happen, written before the work, against which the outcome can be checked afterwards by someone who was not there.

A branch charter. A handover note. A decision entry with its reasoning. The format matters far less than two properties: it is written in advance, and it is specific enough to be wrong.

Two kinds of artefact live here, and their lifetimes are opposite. A per-work record — a charter for one branch, a note for one task — is true only while that work is in flight, and becomes noise once it lands; it is removed at the end. A decision record is durable: it is written to be read later by someone who was not there, and it is not removed. Neither of them is a reusable asset — a ritual, a skill, anything written to be found again — which belongs to layer 5 and is retired rather than deleted there. "Remove it when the work is done", below, is about the first of the three and nothing else.

This is the layer people skip, because it is the only one that produces nothing at the moment of writing it.

The failure it prevents#

That nobody can check, afterwards, what was supposed to happen. Every other layer addresses the work in flight. This one addresses the far more common situation: a week later, someone — possibly you — needs to know whether what landed is what was intended, and the only surviving evidence is the outcome itself.

An outcome cannot be compared against an intention that was never written down. It can only be rationalised.

There is a second thing this layer protects, and it is the more valuable one. The record is the only place a rejected path and the reason for rejecting it can survive. Results are saved, sent and filed; the option you deliberately did not take exists in exactly one head, and no output format has a field for it. That is the knowledge a restart destroys and a summary rarely keeps — and the knowledge that removing this record destroys too, if it was not carried out first. Point 6 below is that step.

What belongs in it#

"Rejected, because" is the highest-value line in the file — and only if the reason is checkable rather than a judgement. "The export has no change date" stays true and can be re-tested; "wasn't a good idea" cannot be re-evaluated by anyone, including its author.

Outside software#

The non-software forms are familiar and usually thinner than they should be: the decision log after a meeting, the brief written before a project rather than the report written after it, the note that says which supplier was not chosen and why. All of them fail in the same place — they record the outcome, which was visible anyway, and not the intention or the rejected option, which was not.

How to build it#

1. One record per unit of work — a branch, a task, a session. Not one per project; a record that covers everything is consulted for nothing.
2. Create it before the first commit. After the fact you can only record the outcome, and the outcome is the one thing that is already visible. The intention is what needs preserving, and it degrades within hours.
3. State the goal so that it could be wrong. "Improve the docs" cannot be checked. "Every changed article has its mirror updated in the same commit" can.
4. Pin every claim to a commit and a date. This is the technique that turns an advisory rule into something auditable without making it enforced: "as of commit abc1234, the branch had no upstream" stays checkable forever by anyone with the repository. A present-tense claim about compliance expires the moment the state changes; a dated one becomes a record. The introduction↗ walks through a worked instance of exactly this.
5. Keep the open decisions as checkboxes, and tick them when they are resolved rather than deleting them. A resolved decision that is still visible is how the next person learns that the question was asked.
6. Carry the reasoning out, then remove it. A per-work record is removed when the work lands: a charter that outlives its branch becomes noise, and noise is how a record stops being read. But the rejected paths and their checkable reasons are what this page calls the layer's most valuable content, and deleting the charter deletes them with it. So the last step before removal is to copy them into the durable decision record — which is a layer-4 artefact in its own right, and is not removed. Deletion without that step destroys precisely the knowledge the layer exists to preserve.

What it cannot do#

It controls nothing. It stops nothing, blocks nothing, and its absence causes no failure at the time. Everything it is worth is retrospective, which is precisely why it is the first thing dropped and the last thing missed.

It also cannot make an advisory rule enforced. It makes it auditable — a different and smaller claim, but the only one available when a rule is genuinely unmechanisable. "Never invent knowledge" cannot be checked by a program. Whether the person who wrote it said in advance what they intended to verify, and whether they did, can be.

Failure modes#

Done when#

• It exists before the first commit of the work it describes
• The goal is stated so that it could be shown to be wrong
• Compliance claims are pinned to a commit and a date, not to the present tense
• Rejected options carry a checkable reason
• Open decisions are checkboxes, and resolved ones stay visible
• Its removal is part of the cleanup, not a separate act of tidiness — and the rejected paths were carried into the durable decision record before it went
• A stranger could compare the outcome against it without asking a question

Next: Layer 5 — index, triggers and upkeep, which is what keeps the other four from rotting.

Schicht 4 — Der schriftliche Nachweis#

Survival-Toolbox, Teil 4 von 5 · Hier beginnen · zurück: Schicht 3 — das benannte Ritual · weiter: Schicht 5 — Index, Auslöser und Pflege

In einem Satz#

Eine kurze Notiz vor der Arbeit darüber, was passieren soll — damit hinterher jemand prüfen kann, ob es passiert ist.

Ein Beispiel: Business Analyst#

Wer. Eine Analystin, die mit einem Agenten drei Lösungswege durchgespielt hat. Die Aufgabe. Einen davon empfehlen. Was schiefgeht. Sechs Wochen später schlägt jemand genau den Weg vor, den sie damals verworfen hatte — gut begründet, und deshalb prüft sie ihn ein zweites Mal. Der Grund fürs Verwerfen existierte nur in ihrem Kopf. Das Ergebnis wurde gespeichert, die verworfene Option nicht. Was du baust. Eine Notiz, die vorher entsteht: das Ziel in einem Satz, der auch falsch sein könnte — und darunter „verworfen, weil …" mit einem nachprüfbaren Grund. „Das Formular lässt keine zwei Kontakte zu" bleibt prüfbar. „War keine gute Idee" nicht.

Was du heute tust#

Bei der nächsten Aufgabe: drei Zeilen, bevor du anfängst. Ziel · Schritte · was du bewusst nicht machst. Wer hinterher schreibt, hält nur das Ergebnis fest — und das war ohnehin sichtbar.

Was er ist#

Ein Nachweis dessen, was hätte passieren sollen, vor der Arbeit geschrieben, an dem sich das Ergebnis hinterher von jemandem prüfen lässt, der nicht dabei war.

Ein Branch-Charter. Eine Übergabenotiz. Ein Entscheidungseintrag mit seiner Begründung. Das Format zählt weit weniger als zwei Eigenschaften: er entsteht vorher, und er ist konkret genug, um falsch sein zu können.

Hier leben zwei Arten von Artefakt, und ihre Lebensdauern sind entgegengesetzt. Ein Nachweis pro Arbeitseinheit — ein Charter für einen Branch, eine Notiz zu einer Aufgabe — gilt nur, solange diese Arbeit läuft, und wird zu Rauschen, sobald sie gelandet ist; er wird am Ende entfernt. Ein Entscheidungsnachweis ist dauerhaft: Er entsteht, um später von jemandem gelesen zu werden, der nicht dabei war, und er wird nicht entfernt. Keines von beiden ist ein wiederverwendbares Asset — ein Ritual, ein Skill, alles, was geschrieben wurde, um wiedergefunden zu werden —; das gehört zu Schicht 5 und wird dort ausgemustert statt gelöscht. „Ihn entfernen, wenn die Arbeit fertig ist" weiter unten meint das erste der drei und sonst nichts.

Das ist die Schicht, die übersprungen wird, weil sie als einzige im Moment des Schreibens nichts produziert.

Der Fehler, den er verhindert#

Dass hinterher niemand prüfen kann, was passieren sollte. Alle anderen Schichten adressieren die Arbeit im Fluss. Diese adressiert die weit häufigere Lage: eine Woche später muss jemand — womöglich man selbst — wissen, ob das Gelandete das Gemeinte ist, und das einzige überlebende Zeugnis ist das Ergebnis selbst.

Ein Ergebnis lässt sich nicht gegen eine Absicht halten, die nie aufgeschrieben wurde. Es lässt sich nur rationalisieren.

Es gibt noch etwas, das diese Schicht schützt, und es ist das Wertvollere. Der Nachweis ist der einzige Ort, an dem ein verworfener Weg samt Grund für das Verwerfen überleben kann. Ergebnisse werden gespeichert, verschickt, abgelegt; die Option, die man bewusst nicht genommen hat, existiert in genau einem Kopf, und kein Ausgabeformat hat ein Feld dafür. Genau dieses Wissen zerstört ein Neustart und bewahrt eine Zusammenfassung selten — und genau dieses Wissen zerstört auch das Entfernen des Nachweises, wenn es nicht vorher herausgetragen wurde. Punkt 6 weiter unten ist dieser Schritt.

Was hineingehört#

„Verworfen, weil" ist die wertvollste Zeile der Datei — und nur dann, wenn der Grund prüfbar ist statt ein Urteil. „Das Formular lässt keine zwei Kontakte zu" bleibt wahr und lässt sich nachprüfen; „war keine gute Idee" kann niemand neu bewerten, auch der Verfasser nicht.

Ausserhalb der Software#

Die Formen ausserhalb der Software sind vertraut und meist dünner, als sie sein sollten: das Entscheidungsprotokoll nach einer Besprechung, das Briefing vor einem Projekt statt des Berichts danach, die Notiz, welcher Lieferant nicht genommen wurde und warum. Alle scheitern an derselben Stelle — sie halten das Ergebnis fest, das ohnehin sichtbar war, und nicht die Absicht oder die verworfene Option, die es nicht war.

Wie man ihn baut#

1. Ein Nachweis pro Arbeitseinheit — ein Branch, eine Aufgabe, eine Session. Nicht einer pro Projekt; ein Nachweis, der alles abdeckt, wird für nichts konsultiert.
2. Vor dem ersten Commit anlegen. Hinterher lässt sich nur das Ergebnis festhalten, und das Ergebnis ist das Einzige, was ohnehin sichtbar ist. Bewahrt werden muss die Absicht, und die verfällt innerhalb von Stunden.
3. Das Ziel so formulieren, dass es falsch sein könnte. „Die Doku verbessern" lässt sich nicht prüfen. „Jeder geänderte Artikel hat seine Spiegelung im selben Commit" schon.
4. Jede Aussage an Commit und Datum heften. Das ist die Technik, die eine advisorische Regel auditierbar macht, ohne sie zu erzwingen: „Stand Commit abc1234 hatte der Branch kein Upstream" bleibt für jeden mit dem Repository dauerhaft prüfbar. Eine Aussage über Einhaltung im Präsens verfällt in dem Moment, in dem der Zustand sich ändert; eine datierte wird zum Nachweis. Die Einführung↗ geht ein Beispiel genau dafür durch.
5. Offene Entscheidungen als Checkboxen führen und sie abhaken statt löschen, wenn sie gelöst sind. Eine gelöste Entscheidung, die sichtbar bleibt, ist die Art, wie die nächste Person erfährt, dass die Frage gestellt wurde.
6. Die Begründung heraustragen, dann entfernen. Ein Nachweis pro Arbeitseinheit wird entfernt, wenn die Arbeit gelandet ist: Ein Charter, der seinen Branch überlebt, wird Rauschen — und Rauschen ist der Weg, auf dem ein Nachweis aufhört, gelesen zu werden. Aber die verworfenen Wege samt ihren prüfbaren Gründen sind das, was diese Seite den wertvollsten Inhalt der Schicht nennt, und das Löschen des Charters löscht sie mit. Der letzte Schritt vor dem Entfernen ist deshalb, sie in den dauerhaften Entscheidungsnachweis zu übertragen — der selbst ein Artefakt der Schicht 4 ist und nicht entfernt wird. Ein Entfernen ohne diesen Schritt zerstört genau das Wissen, für dessen Bewahrung es die Schicht gibt.

Was er nicht kann#

Er kontrolliert nichts. Er verhindert nichts, blockiert nichts, und sein Fehlen verursacht zum Zeitpunkt nichts. Alles, was er wert ist, ist rückblickend — genau deshalb wird er als Erstes weggelassen und als Letztes vermisst.

Er kann auch keine advisorische Regel erzwungen machen. Er macht sie auditierbar — eine andere und kleinere Behauptung, aber die einzige verfügbare, wenn eine Regel wirklich nicht mechanisierbar ist. „Erfinde kein Wissen" kann kein Programm prüfen. Ob die Person, die das schrieb, vorher gesagt hat, was sie zu prüfen gedachte, und ob sie es tat, schon.

Versagensmodi#

Fertig, wenn#

• Er existiert vor dem ersten Commit der Arbeit, die er beschreibt
• Das Ziel ist so formuliert, dass es sich als falsch zeigen liesse
• Einhaltungsaussagen sind an Commit und Datum geheftet, nicht ans Präsens
• Verworfene Optionen tragen einen prüfbaren Grund
• Offene Entscheidungen sind Checkboxen, und gelöste bleiben sichtbar
• Sein Entfernen ist Teil des Aufräumens, kein separater Akt der Ordentlichkeit — und die verworfenen Wege wurden vorher in den dauerhaften Entscheidungsnachweis übertragen
• Eine fremde Person könnte das Ergebnis ohne Rückfrage dagegen halten

Weiter: Schicht 5 — Index, Auslöser und Pflege, die verhindert, dass die anderen vier verrotten.

Lớp 4 — Bản ghi được viết ra#

Bộ công cụ sinh tồn, phần 4 trong 5 · Bắt đầu tại đây · trước đó: Lớp 3 — nghi thức có tên · tiếp theo: Lớp 5 — chỉ mục, trigger và bảo trì

Tóm trong một câu#

Một ghi chú ngắn viết trước khi làm việc về điều lẽ ra sẽ xảy ra — để về sau ai đó có thể kiểm tra xem nó có xảy ra thật hay không.

Một ví dụ: business analyst#

Ai. Một analyst đã cùng một agent làm việc qua ba phương án. Công việc. Đề xuất chọn một trong số đó. Điều gì hỏng. Sáu tuần sau, có người đề xuất đúng cái phương án mà cô đã loại — lập luận chặt chẽ, nên cô phải kiểm tra lại nó lần thứ hai. Lý do loại nó chỉ tồn tại trong đầu cô. Kết quả thì đã được lưu; phương án bị loại thì không. Bạn xây gì. Một ghi chú được viết từ trước: mục tiêu trong một câu mà cũng có thể sai — và bên dưới là "bị loại, vì …" với một lý do kiểm chứng được. "Biểu mẫu không cho phép hai người liên hệ" thì vẫn kiểm chứng được. "Không phải ý hay" thì không.

Hôm nay bạn làm gì#

Ở công việc tiếp theo: ba dòng trước khi bắt đầu. Mục tiêu · các bước · những gì bạn cố ý không làm. Viết nó sau khi xong thì bạn chỉ ghi lại kết quả — thứ mà đằng nào cũng nhìn thấy được.

Nó là gì#

Một bản ghi về điều lẽ ra phải xảy ra, được viết trước khi làm việc, để về sau kết quả có thể được đối chiếu với nó bởi một người không có mặt lúc đó.

Một hiến chương cho branch. Một ghi chú bàn giao. Một mục ghi quyết định kèm lập luận của nó. Định dạng ít quan trọng hơn nhiều so với hai tính chất: nó được viết từ trước, và nó cụ thể đủ để có thể sai.

Có hai loại artefact sống ở đây, và vòng đời của chúng ngược nhau. Một bản ghi cho từng đơn vị công việc — một hiến chương cho một branch, một ghi chú cho một task — chỉ đúng trong lúc công việc đó còn đang chạy, và trở thành nhiễu một khi nó đã hạ cánh; nó được gỡ bỏ ở cuối. Một bản ghi quyết định thì bền: nó được viết để về sau một người không có mặt lúc đó đọc, và nó không bị gỡ bỏ. Cả hai đều không phải là một tài sản dùng lại được — một nghi thức, một skill, bất cứ thứ gì được viết ra để rồi được tìm lại — thứ đó thuộc về lớp 5 và ở đó nó được cho về hưu chứ không bị xóa. "Gỡ bỏ nó khi công việc đã xong", ở dưới, chỉ nói về loại thứ nhất trong ba loại và không nói gì khác.

Đây là lớp mà người ta hay bỏ qua, vì nó là lớp duy nhất chẳng tạo ra gì ngay tại thời điểm viết nó.

Thất bại mà nó ngăn chặn#

Rằng về sau không ai kiểm tra được điều lẽ ra phải xảy ra là gì. Mọi lớp khác đều nhắm vào công việc đang diễn ra. Lớp này nhắm vào tình huống phổ biến hơn nhiều: một tuần sau, ai đó — có thể chính là bạn — cần biết thứ đã hạ cánh có đúng là thứ đã được dự định hay không, và bằng chứng duy nhất còn sót lại chính là bản thân kết quả.

Không thể đối chiếu một kết quả với một ý định chưa từng được viết ra. Nó chỉ có thể được hợp lý hóa.

Có một thứ thứ hai mà lớp này bảo vệ, và nó mới là thứ giá trị hơn. Bản ghi là nơi duy nhất mà một con đường bị loại và lý do loại nó có thể sống sót. Kết quả thì được lưu, được gửi đi và được lưu hồ sơ; phương án mà bạn cố ý không chọn chỉ tồn tại trong đúng một cái đầu, và không có định dạng đầu ra nào có một ô dành cho nó. Đó là tri thức mà một lần khởi động lại sẽ hủy đi và một bản tóm tắt hiếm khi giữ lại — và cũng là tri thức mà việc gỡ bỏ bản ghi này sẽ hủy theo, nếu nó không được mang ra ngoài trước. Điểm 6 ở dưới chính là bước đó.

Cái gì thuộc về nó#

"Bị loại, vì" là dòng có giá trị cao nhất trong tệp — và chỉ khi lý do là thứ kiểm chứng được chứ không phải một phán đoán. "Bản xuất dữ liệu không có ngày thay đổi" thì vẫn đúng và có thể kiểm lại; "không phải ý hay" thì không ai đánh giá lại được, kể cả tác giả của nó.

Ngoài phạm vi phần mềm#

Các dạng ngoài phần mềm thì quen thuộc và thường mỏng hơn mức đáng có: sổ ghi quyết định sau một cuộc họp, bản brief viết trước một dự án chứ không phải bản báo cáo viết sau nó, tờ ghi chú nói nhà cung cấp nào đã không được chọn và vì sao. Tất cả chúng đều hỏng ở cùng một chỗ — chúng ghi lại kết quả, thứ đằng nào cũng nhìn thấy được, chứ không ghi ý định hay phương án bị loại, những thứ vốn không nhìn thấy được.

Cách xây dựng nó#

1. Một bản ghi cho mỗi đơn vị công việc — một branch, một task, một phiên làm việc. Không phải một bản cho mỗi dự án; một bản ghi bao trùm mọi thứ thì chẳng được tra cứu vì chuyện gì cả.
2. Tạo nó trước commit đầu tiên. Làm sau thì bạn chỉ ghi lại được kết quả, mà kết quả lại chính là thứ duy nhất vốn đã nhìn thấy được. Ý định mới là thứ cần được giữ lại, và nó phai đi trong vòng vài giờ.
3. Phát biểu mục tiêu sao cho nó có thể sai. "Cải thiện tài liệu" thì không kiểm được. "Mọi bài viết bị thay đổi đều có bản mirror của nó được cập nhật trong cùng một commit" thì kiểm được.
4. Neo mọi khẳng định vào một commit và một ngày. Đây là kỹ thuật biến một quy tắc khuyến nghị thành một thứ kiểm toán được mà không cần cưỡng chế nó: "tính đến commit abc1234, branch này chưa có upstream" thì mãi mãi vẫn kiểm chứng được bởi bất kỳ ai có repository. Một khẳng định ở thì hiện tại về việc tuân thủ sẽ hết hạn ngay khoảnh khắc trạng thái thay đổi; một khẳng định có ngày tháng thì trở thành một bản ghi. Phần giới thiệu↗ đi qua một trường hợp cụ thể đúng về chuyện này.
5. Giữ các quyết định còn mở dưới dạng checkbox, và tích vào chúng khi chúng được giải quyết thay vì xóa đi. Một quyết định đã được giải quyết mà vẫn còn nhìn thấy được chính là cách người tiếp theo biết rằng câu hỏi đó đã từng được đặt ra.
6. Mang phần lập luận ra ngoài trước, rồi mới gỡ bỏ nó. Một bản ghi cho từng đơn vị công việc được gỡ bỏ khi công việc hạ cánh: một hiến chương sống lâu hơn branch của nó thì trở thành nhiễu, và nhiễu chính là cách một bản ghi thôi được đọc. Nhưng các con đường bị loại cùng những lý do kiểm chứng được của chúng lại chính là thứ mà trang này gọi là nội dung giá trị nhất của lớp, và xóa hiến chương là xóa chúng theo. Vì vậy bước cuối cùng trước khi gỡ bỏ là chép chúng vào bản ghi quyết định bền vững — thứ tự nó cũng là một artefact của lớp 4, và không bị gỡ bỏ. Xóa mà bỏ qua bước đó thì hủy đúng cái tri thức mà lớp này tồn tại để bảo tồn.

Điều nó không làm được#

Nó không kiểm soát gì cả. Nó không dừng gì, không chặn gì, và sự vắng mặt của nó không gây ra thất bại nào tại thời điểm đó. Toàn bộ giá trị của nó là hồi cố, và đó chính xác là lý do nó là thứ bị bỏ đi đầu tiên và là thứ được nhớ đến sau cùng.

Nó cũng không thể biến một quy tắc khuyến nghị thành một quy tắc được cưỡng chế. Nó làm cho quy tắc đó kiểm toán được — một tuyên bố khác và nhỏ hơn, nhưng là tuyên bố duy nhất còn khả dụng khi một quy tắc thực sự không cơ giới hóa được. "Không bao giờ bịa ra tri thức" thì một chương trình không kiểm được. Còn việc người viết ra nó có nói trước rằng họ định kiểm chứng điều gì hay không, và họ có làm hay không, thì kiểm được.

Các kiểu thất bại#

Xong khi#

• Nó tồn tại trước commit đầu tiên của công việc mà nó mô tả
• Mục tiêu được phát biểu sao cho có thể chỉ ra rằng nó sai
• Các khẳng định về việc tuân thủ được neo vào một commit và một ngày, không neo vào thì hiện tại
• Các phương án bị loại đều mang theo một lý do kiểm chứng được
• Các quyết định còn mở là những checkbox, và những cái đã giải quyết vẫn còn nhìn thấy được
• Việc gỡ bỏ nó là một phần của việc dọn dẹp, không phải một hành động gọn gàng riêng lẻ — và các con đường bị loại đã được mang vào bản ghi quyết định bền vững trước khi nó biến mất
• Một người lạ có thể đối chiếu kết quả với nó mà không cần hỏi câu nào

Tiếp theo: Lớp 5 — chỉ mục, trigger và bảo trì, là thứ giữ cho bốn lớp kia không mục ruỗng.

Layer 5 — Index, triggers and upkeep#

Survival toolbox, part 5 of 5 · Start here · previous: Layer 4 — the written record · next: Appendix 0510 — the architecture of a discipline

In one sentence#

Making sure you can find what you wrote — and that each thing exists only once.

An example: vibe coder#

Who. Somebody who has accumulated prompts and procedures over months. The job. Find the procedure that worked last time. What goes wrong. There are three versions, all of them plausible, none of them dated. So you write a fourth. Next time there are five. What you build. One place where everything lives, and one command that searches it — including what you set aside. Because that is exactly what gets rebuilt next.

What you do today#

Search once before you next write something new — on disk, not from memory. If you cannot quote the search result, you did not search.

What it is#

The maintenance layer. It owns no artefact of its own; it keeps the other four honest as the collection grows past the point where one person remembers all of it.

What it governs is the reusable asset — a ritual, a skill, a template, a shared rule: anything written to be found again. The per-work record, which is meant to stop existing once its work has landed, is layer 4's business and takes the opposite instruction there. Nothing on this page applies to it.

It is the layer that is never finished, and the only one whose absence is invisible for a long time and then all at once.

The failure it prevents#

Two failures, and they are the same failure seen from opposite ends.

The skill nobody invokes. A collection grows a long tail of files that never fire. Each one cost a day to write, costs context to keep, and returns nothing. Crucially you cannot tell from the file whether it never fires because it is badly described, because it was never needed, or because it never reached the agent at all — the listing that carries the descriptions is budgeted, and drops the least-used ones first. Those demand different fixes, and one of them is not a fix to the file.

The same rule stated twice. Two documents that were both correct on the day they were written, drifting apart ever since. The session that reads them has to guess which is current, and a guess that goes wrong here is expensive precisely because both sources look authoritative.

A measurement on the collection this series comes from. Of 60 written rituals, 24 had ever been invoked and 36 not once — by full-text search across 2,686 session transcripts, taken on 2026-09-03, on one machine and in one working style.

The figure is a lower bound, from two directions: a full-text search sees only what is in the corpus, and only what appears there as text. A ritual used before the corpus began, or whose invocation left no searchable trace, counts as never invoked. So the true share of silent files is at most the measured one — probably lower, and still more than half.

The 36 were then retired rather than deleted. That is the point at which this layer actually ran instead of merely being documented — and also the point at which it fails the standard this series sets elsewhere. Layer 2 requires that whatever verifies must itself be run by something automatic, and calls the alternative "documentation with an exit code". This count was run once, by hand, because somebody thought to run it. By that standard it does not qualify: nothing would notice if it were never run again, and the number above is already ageing.

The named next step that would fix it: emit the invocation count from the same command that generates the index, run that command on a schedule, and let it fail when the index is older than the collection it describes. It does not exist. Until it does, this layer is written up here at a level it has not reached in practice — measured once, acted on once, and wired to nothing that will do either again. The appendix's second diagnostic asks whether the loop is closed. For this layer, on this collection, the honest answer today is no.

What belongs in it#

Outside software#

Every organisation has already met this layer's failure and usually lost to it: the shared drive nobody can search, the template library with three versions of the same template and no way to tell which is current, the policy that exists twice because the second author could not find the first. Agents change the stakes rather than the problem — a person who cannot find the right template asks a colleague, and an agent confidently uses the wrong one.

How to build it#

1. Make the search one command, and make it cover the archive. The index must include what has been retired, because the most likely thing to be rebuilt is exactly what was recently tidied out of sight. An asset invisible to search does not exist, and a search that only covers the active set will confidently report that nothing matches.
2. Search before writing — from disk, not from memory. This is the rule that has to be mechanical, because the failure mode is a feeling of confidence. Quote the search output in the justification for a new asset; if you cannot quote it, you did not run it.
3. Prefer extending to creating. Two assets that overlap by 80% are worse than one with a second mode: they drift, and every session has to work out which is current. If the new job is a variation of an existing one, it belongs inside that one.
4. One canonical statement per shared rule; reference it, never copy it. A copy is a future contradiction with a date on it. When several assets need the same rule, that rule gets its own file and everything else points at it.
5. Retire rather than delete — a reusable asset, that is; a charter for a finished branch is removed instead, as its own page says. An archived asset that is one command from returning costs almost nothing and removes the pressure to keep marginal things active. Deletion, being irreversible, makes people keep everything instead.
6. Look at invocation, if you can see it. An asset that has never fired is a question, not a verdict: rewrite the description first, and only retire it if it still never fires.

What it cannot do#

It cannot tell you why a skill never fired. The index knows what exists and, at best, what ran. The distinction that actually matters — mis-described, unnecessary, or never listed in the first place — is not in the data, and guessing wrong costs you either a good asset or a wasted rewrite. See what we checked in layer 3 for the third case, which is the one nothing in the file can show you.

Nor can it prevent duplication on its own. It makes duplication findable. Somebody still has to look, and that discipline is the part no mechanism supplies.

Failure modes#

Done when#

• One command searches every asset, active and retired
• A new asset is justified with a quoted search result
• Every shared rule has exactly one home, and every other mention is a reference
• Retirement is reversible and has actually been used
• The index is generated, not hand-maintained
• The invocation count is produced by something that runs on a schedule, not once by hand

That is the toolbox. Whether your five layers add up to a working discipline is the question of the appendix: 0510 — the architecture of a discipline. Or back to the map and the recipe.

Schicht 5 — Index, Auslöser und Pflege#

Survival-Toolbox, Teil 5 von 5 · Hier beginnen · zurück: Schicht 4 — der schriftliche Nachweis · weiter: Anhang 0510 — die Architektur einer Disziplin

In einem Satz#

Dafür sorgen, dass man wiederfindet, was man geschrieben hat — und dass es jede Sache nur einmal gibt.

Ein Beispiel: Vibe Coder#

Wer. Jemand, der sich über Monate Prompts und Abläufe angesammelt hat. Die Aufgabe. Den Ablauf wiederfinden, der letztes Mal funktioniert hat. Was schiefgeht. Es gibt drei Fassungen, alle sehen plausibel aus, und keine trägt ein Datum. Also schreibt man eine vierte. Beim nächsten Mal sind es fünf. Was du baust. Einen Ort, an dem alles liegt, und einen Befehl, der ihn durchsucht — auch das, was du aussortiert hast. Denn genau das wird sonst als Nächstes neu gebaut.

Was du heute tust#

Such einmal, bevor du das nächste Mal etwas Neues schreibst — auf der Platte, nicht im Kopf. Wer das Suchergebnis nicht zitieren kann, hat nicht gesucht.

Was sie ist#

Die Pflegeschicht. Sie besitzt kein eigenes Artefakt; sie hält die anderen vier ehrlich, während die Sammlung über den Punkt hinauswächst, an dem eine Person sie noch ganz erinnert.

Was sie regiert, ist das wiederverwendbare Asset — ein Ritual, ein Skill, eine Vorlage, eine geteilte Regel: alles, was geschrieben wurde, um wiedergefunden zu werden. Der Nachweis pro Arbeitseinheit, der aufhören soll zu existieren, sobald seine Arbeit gelandet ist, ist Sache von Schicht 4 und bekommt dort die entgegengesetzte Anweisung. Nichts auf dieser Seite gilt für ihn.

Sie ist die Schicht, die nie fertig wird, und die einzige, deren Fehlen lange unsichtbar bleibt und dann auf einmal nicht mehr.

Der Fehler, den sie verhindert#

Zwei Fehler, und es ist derselbe Fehler von entgegengesetzten Enden aus gesehen.

Der Skill, den niemand aufruft. Eine Sammlung bildet einen langen Schwanz von Dateien, die nie feuern. Jede hat einen Tag im Schreiben gekostet, kostet Kontext im Behalten und liefert nichts. Entscheidend: der Datei sieht man nicht an, ob sie nie feuert, weil sie schlecht beschrieben ist, weil sie nie gebraucht wurde, oder weil sie den Agenten gar nicht erst erreicht hat — die Auflistung, die die Beschreibungen trägt, hat ein Budget und lässt die am wenigsten genutzten zuerst fallen. Das verlangt verschiedene Abhilfen, und eine davon ist keine Abhilfe an der Datei.

Dieselbe Regel zweimal formuliert. Zwei Dokumente, beide korrekt am Tag ihrer Entstehung, seither auseinanderdriftend. Die Session, die sie liest, muss raten, welches aktuell ist, und ein falscher Rat ist hier gerade deshalb teuer, weil beide Quellen massgeblich aussehen.

Eine Messung an der Sammlung, aus der diese Reihe stammt. Von 60 geschriebenen Ritualen waren 24 je aufgerufen worden und 36 kein einziges Mal — per Volltextsuche über 2.686 Sitzungsprotokolle, erhoben am 2026-09-03, auf einer Maschine und in einem Arbeitsstil.

Die Zahl ist eine Untergrenze, und das aus zwei Richtungen: eine Volltextsuche sieht nur, was im Korpus steht, und nur, was dort als Text auftaucht. Ein Ritual, das vor Beginn des Korpus benutzt wurde oder dessen Aufruf keine durchsuchbare Spur hinterliess, zählt als nie aufgerufen. Der wahre Anteil der stillen Dateien ist also höchstens so hoch wie gemessen — vermutlich niedriger, und trotzdem betrifft er mehr als die Hälfte.

Die 36 wurden daraufhin ausgemustert statt gelöscht. Das ist der Punkt, an dem diese Schicht einmal tatsächlich gelaufen ist statt bloss dokumentiert zu sein — und zugleich der Punkt, an dem sie an dem Massstab scheitert, den diese Reihe an anderer Stelle setzt. Schicht 2 verlangt, dass alles, was prüft, selbst von etwas Automatischem ausgeführt werden muss, und nennt die Alternative „Dokumentation mit einem Exit-Code". Diese Zählung lief einmal, von Hand, weil jemand daran dachte. An diesem Massstab gemessen genügt sie nicht: Nichts würde bemerken, wenn sie nie wieder liefe, und die Zahl oben altert bereits.

Der benannte nächste Schritt, der das beheben würde: die Aufrufzählung aus demselben Befehl ausgeben, der den Index generiert, diesen Befehl nach Zeitplan laufen lassen und ihn scheitern lassen, wenn der Index älter ist als die Sammlung, die er beschreibt. Er existiert nicht. Bis er existiert, ist diese Schicht hier auf einem Niveau beschrieben, das sie in der Praxis nicht erreicht hat — einmal gemessen, einmal danach gehandelt, und an nichts angeschlossen, das eines von beidem wiederholen wird. Die zweite Diagnose des Anhangs fragt, ob der Kreis geschlossen ist. Für diese Schicht, auf dieser Sammlung, lautet die ehrliche Antwort heute: nein.

Was hineingehört#

Ausserhalb der Software#

Jede Organisation ist dem Versagen dieser Schicht schon begegnet und hat meist verloren: das Netzlaufwerk, das niemand durchsuchen kann; die Vorlagensammlung mit drei Fassungen derselben Vorlage und ohne Hinweis, welche gilt; die Richtlinie, die es zweimal gibt, weil die zweite Autorin die erste nicht fand. Agenten ändern nicht das Problem, sondern den Einsatz — ein Mensch, der die richtige Vorlage nicht findet, fragt jemanden; ein Agent nimmt selbstbewusst die falsche.

Wie man sie baut#

1. Die Suche zu einem Befehl machen — und das Archiv einschliessen. Der Index muss enthalten, was ausgemustert wurde, denn am wahrscheinlichsten neu gebaut wird genau das, was gerade aus dem Blickfeld aufgeräumt wurde. Ein für die Suche unsichtbares Asset existiert nicht, und eine Suche, die nur den aktiven Bestand abdeckt, meldet selbstbewusst, dass nichts passt.
2. Vor dem Schreiben suchen — von der Platte, nicht aus dem Gedächtnis. Diese Regel muss mechanisch sein, weil der Versagensmodus ein Gefühl von Sicherheit ist. Die Suchausgabe in der Begründung für ein neues Asset zitieren; wer sie nicht zitieren kann, hat sie nicht ausgeführt.
3. Erweitern schlägt Erzeugen. Zwei Assets mit 80 % Überlappung sind schlechter als eines mit einem zweiten Modus: sie driften, und jede Session muss herausfinden, welches aktuell ist. Ist die neue Aufgabe eine Variante einer bestehenden, gehört sie in jene hinein.
4. Eine kanonische Formulierung pro geteilter Regel; referenzieren, nie kopieren. Eine Kopie ist ein künftiger Widerspruch mit Datum. Brauchen mehrere Assets dieselbe Regel, bekommt die Regel eine eigene Datei, und alles andere zeigt darauf.
5. Ausmustern statt löschen — beim wiederverwendbaren Asset, wohlgemerkt; ein Charter für einen fertigen Branch wird stattdessen entfernt, wie seine eigene Seite sagt. Ein archiviertes Asset, das einen Befehl von der Rückkehr entfernt ist, kostet fast nichts und nimmt den Druck, Grenzwertiges aktiv zu halten. Löschen, weil unumkehrbar, führt dazu, dass stattdessen alles behalten wird.
6. Auf Aufrufe schauen, wenn man sie sehen kann. Ein Asset, das nie gefeuert hat, ist eine Frage, kein Urteil: zuerst die Beschreibung neu schreiben, und erst ausmustern, wenn es dann immer noch nie feuert.

Was sie nicht kann#

Sie kann nicht sagen, warum ein Skill nie ausgelöst hat. Der Index weiss, was existiert, und bestenfalls, was lief. Die Unterscheidung, auf die es ankommt — schlecht beschrieben, überflüssig, oder überhaupt nie aufgelistet — steht nicht in den Daten, und falsch zu raten kostet entweder ein gutes Asset oder eine vergebliche Überarbeitung. Zum dritten Fall, den die Datei selbst niemals zeigen kann, siehe was wir geprüft haben in Schicht 3.

Ebenso wenig kann sie Duplikation allein verhindern. Sie macht Duplikation auffindbar. Nachsehen muss jemand, und diese Disziplin ist der Teil, den kein Mechanismus liefert.

Versagensmodi#

Fertig, wenn#

• Ein Befehl durchsucht jedes Asset, aktiv wie ausgemustert
• Ein neues Asset wird mit einem zitierten Suchergebnis begründet
• Jede geteilte Regel hat genau einen Ort, und jede weitere Nennung ist ein Verweis
• Ausmustern ist umkehrbar und wurde tatsächlich benutzt
• Der Index ist generiert, nicht handgepflegt
• Die Aufrufzählung wird von etwas erzeugt, das nach Zeitplan läuft, nicht einmal von Hand

Das ist die Toolbox. Ob die eigenen fünf Schichten eine arbeitende Disziplin ergeben, ist die Frage des Anhangs: 0510 — die Architektur einer Disziplin. Oder zurück zu Karte und Rezept.

Lớp 5 — Chỉ mục, trigger và việc duy trì#

Bộ công cụ sinh tồn, phần 5 trên 5 · Bắt đầu tại đây · trước đó: Lớp 4 — bản ghi thành văn · tiếp theo: Phụ lục 0510 — kiến trúc của một kỷ luật

Tóm trong một câu#

Bảo đảm rằng bạn tìm lại được thứ mình đã viết — và rằng mỗi thứ chỉ tồn tại đúng một lần.

Một ví dụ: vibe coder#

Ai. Một người đã tích luỹ prompt và quy trình suốt nhiều tháng. Công việc. Tìm lại quy trình đã chạy được lần trước. Chỗ hỏng. Có ba phiên bản, cả ba đều hợp lý, không phiên bản nào có ngày tháng. Thế là bạn viết phiên bản thứ tư. Lần sau sẽ có năm. Bạn xây gì. Một chỗ duy nhất chứa tất cả, và một câu lệnh duy nhất tìm kiếm trong đó — kể cả những thứ bạn đã cất sang một bên. Bởi đó chính xác là thứ sẽ bị xây lại lần tới.

Việc bạn làm hôm nay#

Hãy tìm kiếm một lần trước khi viết thứ mới tiếp theo — trên đĩa, không phải từ trí nhớ. Nếu bạn không trích dẫn được kết quả tìm kiếm thì bạn đã không tìm kiếm.

Nó là gì#

Lớp bảo trì. Nó không sở hữu artefact nào của riêng nó; nó giữ cho bốn lớp kia trung thực khi bộ sưu tập lớn vượt quá điểm mà một người còn nhớ được hết.

Thứ nó quản là tài sản dùng lại được — một nghi thức, một skill, một template, một quy tắc dùng chung: bất cứ thứ gì được viết ra để tìm lại được. Bản ghi theo từng phần việc, thứ vốn được định là ngừng tồn tại khi phần việc của nó đã đáp xuống, là chuyện của lớp 4 và ở đó nó nhận chỉ dẫn ngược lại. Không điều gì trên trang này áp dụng cho nó.

Đây là lớp không bao giờ xong, và là lớp duy nhất mà sự vắng mặt của nó vô hình trong một thời gian dài rồi bỗng lộ ra tất cả cùng một lúc.

Thất bại mà nó ngăn chặn#

Hai thất bại, và chúng là cùng một thất bại nhìn từ hai đầu đối diện.

Cái skill không ai gọi. Một bộ sưu tập mọc ra một cái đuôi dài gồm những file không bao giờ kích hoạt. Mỗi file tốn một ngày để viết, tốn context để giữ, và không trả lại gì. Điều then chốt là bạn không thể nhìn vào file mà biết được nó không bao giờ kích hoạt vì được mô tả tệ, vì nó chưa bao giờ cần thiết, hay vì nó chưa từng đến được tay agent — danh sách mang các phần mô tả có ngân sách, và bỏ những skill ít dùng nhất trước. Những trường hợp đó đòi các cách sửa khác nhau, và một trong số đó không phải là sửa vào file.

Cùng một quy tắc được phát biểu hai lần. Hai tài liệu đều đúng vào ngày chúng được viết, rồi trôi xa nhau kể từ đó. Phiên làm việc đọc chúng phải đoán xem cái nào là hiện hành, và một cú đoán sai ở đây đắt đỏ chính vì cả hai nguồn đều trông có thẩm quyền.

Một phép đo trên chính bộ sưu tập mà loạt bài này xuất phát. Trong 60 nghi thức thành văn, 24 cái từng được gọi và 36 cái chưa một lần — theo tìm kiếm toàn văn trên 2,686 transcript phiên làm việc, thực hiện ngày 2026-09-03, trên một máy và trong một phong cách làm việc.

Con số này là một cận dưới, từ hai hướng: một tìm kiếm toàn văn chỉ thấy những gì có trong kho ngữ liệu, và chỉ thấy những gì xuất hiện ở đó dưới dạng văn bản. Một nghi thức được dùng trước khi kho ngữ liệu bắt đầu, hoặc mà lần gọi của nó không để lại dấu vết tìm được, sẽ bị tính là chưa bao giờ được gọi. Vậy nên tỷ lệ thật của những file im lặng nhiều nhất là bằng con số đo được — có lẽ thấp hơn, và vẫn hơn một nửa.

36 file đó sau đó được cho nghỉ chứ không xoá. Đó là thời điểm lớp này thực sự chạy thay vì chỉ được viết ra thành tài liệu — và cũng là thời điểm nó không đạt chuẩn mà loạt bài này đặt ra ở những chỗ khác. Lớp 2 đòi rằng thứ nào đi kiểm chứng thì bản thân nó phải được một thứ tự động chạy, và gọi phương án còn lại là "tài liệu có mã thoát". Phép đếm này được chạy một lần, bằng tay, vì có người nghĩ ra là nên chạy. Theo chuẩn đó thì nó không đủ tư cách: sẽ chẳng có gì nhận ra nếu nó không bao giờ được chạy lại, và con số ở trên thì đã đang già đi.

Bước tiếp theo được nêu tên và sẽ sửa được điều đó: cho chính câu lệnh sinh ra chỉ mục phát ra luôn số lần gọi, chạy câu lệnh đó theo lịch, và để nó fail khi chỉ mục cũ hơn bộ sưu tập mà nó mô tả. Nó không tồn tại. Chừng nào nó chưa tồn tại, lớp này ở đây được viết lên ở một mức mà trong thực tế nó chưa đạt tới — đo một lần, hành động một lần, và không được nối vào thứ gì sẽ làm lại một trong hai việc đó. Phép chẩn đoán thứ hai của phụ lục hỏi vòng lặp đã khép hay chưa. Với lớp này, trên bộ sưu tập này, câu trả lời trung thực hôm nay là chưa.

Cái gì thuộc về nó#

Ngoài phạm vi phần mềm#

Mọi tổ chức đều đã gặp thất bại của lớp này và thường là đã thua nó: ổ đĩa chung không ai tìm được gì, thư viện template có ba phiên bản của cùng một template và không có cách nào biết cái nào là hiện hành, chính sách tồn tại hai lần vì tác giả thứ hai không tìm thấy bản của tác giả thứ nhất. Agent làm thay đổi mức độ rủi ro chứ không thay đổi vấn đề — một người không tìm được template đúng thì đi hỏi đồng nghiệp, còn một agent thì tự tin dùng nhầm cái sai.

Xây nó thế nào#

1. Biến việc tìm kiếm thành một câu lệnh duy nhất, và cho nó phủ luôn kho lưu trữ. Chỉ mục phải bao gồm những gì đã cho nghỉ, bởi thứ dễ bị xây lại nhất chính là thứ vừa mới được dọn khỏi tầm mắt. Một tài sản mà tìm kiếm không thấy thì không tồn tại, và một tìm kiếm chỉ phủ tập đang hoạt động sẽ tự tin báo rằng không có gì khớp.
2. Tìm kiếm trước khi viết — từ đĩa, không phải từ trí nhớ. Đây là quy tắc bắt buộc phải mang tính máy móc, vì kiểu hỏng của nó là một cảm giác tự tin. Hãy trích dẫn kết quả tìm kiếm trong phần biện minh cho một tài sản mới; nếu bạn không trích dẫn được thì bạn đã không chạy nó.
3. Ưu tiên mở rộng hơn là tạo mới. Hai tài sản trùng nhau 80% thì tệ hơn một tài sản có thêm một chế độ thứ hai: chúng trôi xa nhau, và mọi phiên làm việc phải tự tìm ra cái nào là hiện hành. Nếu công việc mới là một biến thể của công việc đã có, nó thuộc về bên trong cái đã có.
4. Một phát biểu chuẩn duy nhất cho mỗi quy tắc dùng chung; tham chiếu tới nó, đừng bao giờ chép lại. Một bản sao là một mâu thuẫn tương lai có kèm ngày tháng. Khi nhiều tài sản cần cùng một quy tắc, quy tắc đó có file riêng của nó và mọi thứ khác trỏ về đấy.
5. Cho nghỉ thay vì xoá — ý là với một tài sản dùng lại được; còn một charter của nhánh đã xong thì bị gỡ đi, như trang của chính nó nói. Một tài sản đã lưu trữ mà chỉ cách một câu lệnh là quay lại được thì gần như không tốn gì và gỡ bỏ áp lực phải giữ những thứ nửa vời trong trạng thái hoạt động. Xoá, vì không đảo ngược được, khiến người ta giữ lại mọi thứ.
6. Hãy nhìn vào số lần gọi, nếu bạn thấy được nó. Một tài sản chưa bao giờ kích hoạt là một câu hỏi, không phải một phán quyết: viết lại phần mô tả trước đã, và chỉ cho nó nghỉ nếu nó vẫn không bao giờ kích hoạt.

Nó không làm được gì#

Nó không nói được cho bạn vì sao một skill chưa bao giờ kích hoạt. Chỉ mục biết cái gì tồn tại và, tốt nhất, cái gì đã chạy. Sự phân biệt thực sự quan trọng — bị mô tả sai, không cần thiết, hay chưa từng được liệt kê — không nằm trong dữ liệu, và đoán sai sẽ khiến bạn mất hoặc một tài sản tốt hoặc một lần viết lại vô ích. Về trường hợp thứ ba, cái mà bản thân file không bao giờ cho bạn thấy, xem những gì chúng tôi đã kiểm tra ở lớp 3.

Nó cũng không tự mình ngăn được sự trùng lặp. Nó làm cho sự trùng lặp tìm thấy được. Vẫn phải có ai đó đi nhìn, và tính kỷ luật đó là phần mà không cơ chế nào cung cấp.

Các kiểu hỏng#

Xong khi#

• Một câu lệnh tìm kiếm mọi tài sản, đang hoạt động lẫn đã cho nghỉ
• Một tài sản mới được biện minh bằng một kết quả tìm kiếm được trích dẫn
• Mỗi quy tắc dùng chung có đúng một chỗ ở, và mọi lần nhắc khác đều là một tham chiếu
• Việc cho nghỉ đảo ngược được và đã thực sự được dùng
• Chỉ mục được sinh ra, không phải duy trì bằng tay
• Số lần gọi được tạo ra bởi một thứ chạy theo lịch, chứ không phải một lần bằng tay

Đó là toàn bộ hộp công cụ. Còn liệu năm lớp của bạn có cộng lại thành một kỷ luật hoạt động được hay không là câu hỏi của phụ lục: 0510 — kiến trúc của một kỷ luật. Hoặc quay lại bản đồ và công thức.

Appendix 0510 — The architecture of a discipline#

Survival toolbox, appendix to part 5 · Start here · previous: Layer 5 — Index, triggers and upkeep

Why this page exists#

The five layers say what kinds of artefact a discipline is made of. They cannot say whether a discipline is complete. You can hold all five and still have no idea what happens when the agent does something irreversible at 18:40, who is accountable for the result, or how you would notice that the discipline had stopped working.

This page supplies the missing axis: the shape of a whole discipline, the topics it has to cover, and a test for finding your own gap. It is an appendix, not a sixth layer — it adds no artefact.

A discipline is a closed loop, not a pile of documents#

The following diagram shows how the five layers connect once they are all present. The prose below carries the same content.

Rules and gates feed the rituals; the gates also constrain the work directly, which is the whole reason they are the layer that holds unattended. The work leaves records. The records are what measurement reads. Measurement feeds upkeep, and upkeep changes the rules and the gates — which is where the loop closes.

Most written disciplines are the left half of that picture only. They have rules, procedures and good intentions, and nothing that ever comes back and changes them. That is not a discipline; it is a pile of documents that happen to be in one folder.

The two elements the five layers do not contain#

Reviewing a working discipline surfaced two properties that none of the five layers can express, and both are in the loop above:

Integrity is the one people miss. It is not "is the rule right" — a question every layer already asks — it is "is the rule in front of the reader the current one". The two failures look identical from the outside and have opposite fixes.

What a discipline has to cover#

Ten topics. This list is not taken from a standard: as of 2026-09-03, none of the sources named below publishes one — see the next section for exactly how far that claim goes and what it rests on. It is derived from observing one working discipline, then cross-checked against what published sources do say. The last column names the cross-check, or says plainly that there is none.

The phase column is the second ordering in that list: the ten topics are not spread evenly, they cluster before the work and at the end. The following diagram shows where they sit in the course of a single delegated piece of work.

The thin middle is not an oversight in the list. There is least to govern during the work, because by then everything has been decided — and that is exactly why it is so easy to skip the topics before it and believe you have a discipline.

Topic 7 is marked because it is the honest gap: the one thing this list asserts on observation alone, its row carrying the date of the search that found nothing rather than a standing claim that none exists. It is in the list because a discipline without it fails in ways this series has watched happen — but a reader should know it rests on observation alone. Topic 10 was the second such gap until 2026-09-03, when reading the public corpus turned up four repositories measuring exactly it. Its row records that correction rather than quietly absorbing it.

Where this list comes from, and what it is not#

The temptation here is to dress a derived list in the authority of a standard. Three things make that unnecessary, and one of them makes it dishonest.

The gap is documented, not merely asserted. A February 2026 preprint scores five established frameworks — Scrum, DevOps, MLOps, AI Governance and human-in-the-loop — against the operational needs of teams where agents do substantive work, and marks task delegation to AI as not addressed by three of them and only partially addressed by the other two. Its diagnosis is the sharpest sentence found in this research: "Governance defines constraints; it does not define workflows." That is exactly the distance between an AI management standard and what a team needs on Monday.

Two independent 2026 efforts are converging on the same missing vocabulary — autonomy tiers, delegation accountability, named ownership, decommissioning. That convergence is the strongest thing this page can honestly claim: not "grounded in an established standard" but "the gap is real, it is documented, and independent attempts to fill it agree on roughly these topics."

And two large standards must not be cited as if they answered this. ISO/IEC 42001 and the NIST AI Risk Management Framework are organisation-level assurance frameworks; their unit of analysis is an AI system in a risk portfolio, not a person handing over a task and taking it back. Individual NIST subcategories are quoted above because they say something precise about override, stop and role definition. The frameworks as wholes are not a topic list for a working discipline, and presenting them as one would misrepresent both.

Deliberately not cited: an internal-controls framework whose object is organisational assurance rather than delegation; a leadership model whose empirical support is weak enough that it may serve as vocabulary but not as evidence; and two 2026 documents — a draft profile and a single-author preprint that says its own empirical validation is future work — which are useful signals of convergence and are not established practice.

The completeness test#

Ten topics down the side, five layers across the top, and in each cell the artefact that carries it. Below is the typical arrangement as a starting point — laying your own beside it is the whole test.

● carries the topic · ○ also covers it · blank — not there

The matrix answers three questions without anyone having to think:

• A row with no ● is a gap. The topic has no artefact — it lives in people's heads.
• A row whose only ● is in column 1 is a rule you are hoping people follow. In the typical arrangement above that is precisely delegation and authority — the two topics with the largest consequences, and the two standing on nothing but goodwill.
• An empty column 5 means the discipline grows and nobody tidies.
• A column with no ● at all is a column looking for its row. Column 6 is exactly that, and it is the newest thing on this page. See below.
• A column naming more than its rows reach is the same fault, one size down. Column 5 is named for three things and the ten topics reach two of them: nothing down the side asks whether a file fires at the right moment. Layer 5's trigger third has no row here.

The two diagnostics worth running once a quarter:

1. Which topics live only in layer 1? Those are the ones that will not survive schedule pressure. That is not an argument to gate all of them — some genuinely cannot be gated — but it is the list of things you are trusting rather than enforcing, and it should be a decision rather than an accident.
2. Is the loop closed? If nothing you measure ever changes a rule or a gate, the right half of the diagram is decoration.

Column 6 — compliance, and why it has no ●#

Column 6 was added on 2026-09-03 after reading ten public skill repositories (the evidence section). Three of them build something none of the five layers describes: work aimed at the gap between an instruction that is correct and an instruction that is followed under pressure. Scenario files that push an agent hard to see whether it abandons the procedure; a required table pairing each predicted excuse with its rebuttal, enforced by the repository's own linter; a body of research on the failure modes of the delegate itself.

A gate stands outside the work and refuses. This stands inside it and argues. It is not layer 1 — it is not a statement of what is true. It is not layer 2 — nothing exits non-zero. And it is not simply good writing, which is the objection to beat: good technical writing answers a question the reader asked; this answers the objection the reader has not raised, and would only raise under pressure.

The published literature agrees with the placement rather than with the promotion. A study of 238 instruction files classifies it as a missing section — not a missing artefact — and finds it absent in 94 % of them. The measurements, the three things that do not work, and the method for testing a rule are collected in appendix 0520.

And it earns no ● in any row, which is the interesting part. It also covers boundaries, procedure and verification, and it is none of them. Either the ten topics are missing a row — call it adherence — or compliance is a mode in which the other topics are pursued rather than a topic of its own. This page does not settle that, because three repositories are enough to show a thing exists and not enough to restructure a method around it. A column with no ● is a column looking for its row, and saying so is more useful than filling a cell to make the table look finished.

What this page cannot do#

It cannot tell you the right level of delegation for your work. The published prior art is unanimous on one point and silent after it: the level is set per decision area, not per person and not once — and nobody has a rule for choosing it that survives contact with a specific team. The one asymmetry that recurs across sources is worth adopting anyway: promotion is slow and evidence-based; demotion is fast and available to anyone.

Nor is a complete discipline a good one. Completeness is a coverage property. Whether the rules are the right rules, and whether the whole arrangement is worth its cost, is what topic 10 is for — and topic 10 is the one with the least support behind it.

Done when#

• Every one of the ten topics has a named artefact covering it
• The topics living only in layer 1 are a decision, written down, not a leftover
• Something you measure has actually changed a rule or a gate at least once
• There is a way to tell that an artefact in front of a reader is the current one
• The list of topics has been re-read against your own incidents, and extended where yours differ

References#

All opened 2026-09-03. The measured literature on whether a written rule is adhered to under conflict is collected in appendix 0520 rather than duplicated here — one canonical list, or the copies drift.

• EU AI Act, Article 14 — Human oversight. <https://artificialintelligenceact.eu/article/14/>
• NIST AI Risk Management Framework 1.0 (NIST AI 100-1, January 2023) — subcategories GOVERN 3.2, MANAGE 2.4, MANAGE 4.1. <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf>
• ISO/IEC 42001:2023, clause structure from the publisher's free preview — cited here only to say what it is not about.
• Anthropic, "Building effective agents" (2024-12-19). <https://www.anthropic.com/engineering/building-effective-agents>
• Anthropic, "Our framework for developing safe and trustworthy agents" (2025-08-04). <https://www.anthropic.com/news/our-framework-for-developing-safe-and-trustworthy-agents>
• OpenAI, "A practical guide to building agents" — tool-risk rating and escalation triggers. <https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf>
• Google, "An Introduction to Google's Approach for Secure AI Agents" (2025). <https://research.google/pubs/an-introduction-to-googles-approach-for-secure-ai-agents/>
• Parasuraman, Sheridan & Wickens (2000), "A model for types and levels of human interaction with automation" — the canonical prior art for delegating to a machine, twenty-five years early.
• Delegation Poker / the Delegation Board — seven levels, authority set per decision area. <https://management30.com/practice/delegation-poker/>
• WHO Surgical Safety Checklist — the checkpoint-boundary pattern, with outcome data. <https://www.nejm.org/doi/full/10.1056/NEJMsa0810119>
• HAIF, arXiv:2602.07641 (February 2026) — the documented coverage gap. Single-author preprint, not peer-reviewed; its own empirical validation is stated as future work. <https://arxiv.org/pdf/2602.07641>
• Cloud Security Alliance, "NIST AI RMF: Agentic Profile" (draft, 2026-03-27) — a draft, authored by CSA and not endorsed by NIST. <https://labs.cloudsecurityalliance.org/agentic/agentic-nist-ai-rmf-profile-v1/>

Back to the map and the recipe.

Anhang 0510 — Die Architektur einer Disziplin#

Survival-Toolbox, Anhang zu Teil 5 · Hier beginnen · zurück: Schicht 5 — Index, Auslöser und Pflege

Warum es diese Seite gibt#

Die fünf Schichten sagen, aus welchen Arten von Artefakt eine Disziplin besteht. Sie können nicht sagen, ob eine Disziplin vollständig ist. Man kann alle fünf haben und trotzdem nicht wissen, was passiert, wenn der Agent freitags um 18:40 etwas Unumkehrbares tut, wer für das Ergebnis geradesteht, oder woran man merken würde, dass die Disziplin aufgehört hat zu wirken.

Diese Seite liefert die fehlende Achse: die Gestalt einer ganzen Disziplin, die Themen, die sie abdecken muss, und einen Test, um die eigene Lücke zu finden. Sie ist ein Anhang, keine sechste Schicht — sie fügt kein Artefakt hinzu.

Eine Disziplin ist ein geschlossener Kreis, kein Stapel Dokumente#

Das folgende Diagramm zeigt, wie die fünf Schichten zusammenhängen, sobald sie alle da sind. Die Prosa darunter trägt denselben Inhalt.

Regeln und Gates münden in die Rituale; die Gates begrenzen zusätzlich die Arbeit direkt — genau deshalb sind sie die Schicht, die unbeaufsichtigt hält. Die Arbeit hinterlässt Nachweise. Die Nachweise sind das, was die Messung liest. Die Messung speist die Pflege, und die Pflege verändert Regeln und Gates — dort schliesst sich der Kreis.

Die meisten geschriebenen Disziplinen sind nur die linke Hälfte dieses Bildes. Sie haben Regeln, Abläufe und gute Absichten, und nichts, was jemals zurückkommt und sie ändert. Das ist keine Disziplin, sondern ein Stapel Dokumente, der zufällig in einem Ordner liegt.

Die zwei Elemente, die in keiner der fünf Schichten stecken#

Die Durchsicht einer arbeitenden Disziplin förderte zwei Eigenschaften zutage, die keine der fünf Schichten ausdrücken kann — beide stehen im Kreis oben:

Integrität ist das, was übersehen wird. Es ist nicht „ist die Regel richtig" — das fragt jede Schicht ohnehin — sondern „ist die Regel vor dem Leser die aktuelle". Von aussen sehen beide Fehler gleich aus und haben entgegengesetzte Abhilfen.

Was eine Disziplin abdecken muss#

Zehn Themen. Diese Liste stammt nicht aus einer Norm: Stand 2026-09-03 veröffentlicht keine der unten genannten Quellen eine — der nächste Abschnitt sagt genau, wie weit diese Aussage trägt und worauf sie ruht. Sie ist aus der Beobachtung einer arbeitenden Disziplin abgeleitet und anschliessend gegen das geprüft worden, was veröffentlichte Quellen tatsächlich sagen. Die letzte Spalte nennt die Gegenprobe — oder sagt klar, dass es keine gibt.

Die Phasen-Spalte ist die zweite Ordnung in dieser Liste: die zehn Themen verteilen sich nicht gleichmässig, sondern ballen sich vor der Arbeit und am Ende. Das folgende Diagramm zeigt, wo sie im Lauf einer einzelnen übergebenen Aufgabe sitzen.

Dass die Mitte dünn ist, ist kein Versehen der Liste. Während der Arbeit ist am wenigsten zu regeln, weil dann schon alles entschieden ist — und genau deshalb fällt es so leicht, die Themen davor zu überspringen und zu glauben, man habe eine Disziplin.

Thema 7 ist markiert, weil es die ehrliche Lücke ist: das eine Ding, das diese Liste allein aus Beobachtung behauptet — seine Zeile trägt das Datum der Suche, die nichts fand, statt der stehenden Behauptung, es gebe nichts. Es steht darin, weil eine Disziplin ohne es auf Arten scheitert, die diese Reihe hat passieren sehen — aber ein Leser soll wissen, dass es allein auf Beobachtung ruht. Thema 10 war bis zum 2026-09-03 die zweite solche Lücke; die Lektüre des öffentlichen Korpus förderte dann vier Repositories zutage, die genau das messen. Seine Zeile hält die Korrektur fest, statt sie stillschweigend zu schlucken.

Woher diese Liste kommt, und was sie nicht ist#

Die Versuchung wäre, eine abgeleitete Liste in die Autorität einer Norm zu kleiden. Drei Dinge machen das unnötig, und eines davon macht es unredlich.

Die Lücke ist dokumentiert, nicht bloss behauptet. Ein Preprint vom Februar 2026 bewertet fünf etablierte Rahmenwerke — Scrum, DevOps, MLOps, KI-Governance und Human-in-the-Loop — gegen die operativen Bedürfnisse von Teams, in denen Agenten substanzielle Arbeit leisten, und markiert Aufgabenübergabe an KI bei dreien als nicht abgedeckt und bei den anderen beiden als nur teilweise. Seine Diagnose ist der schärfste Satz dieser Recherche: „Governance definiert Beschränkungen; sie definiert keine Arbeitsabläufe." Genau das ist die Distanz zwischen einer KI-Managementnorm und dem, was ein Team am Montag braucht.

Zwei unabhängige Anläufe von 2026 konvergieren auf dasselbe fehlende Vokabular — Autonomiestufen, Verantwortlichkeit bei der Übergabe, benannte Eigentümerschaft, Ausserbetriebnahme. Diese Konvergenz ist das Stärkste, was diese Seite redlich behaupten kann: nicht „gestützt auf eine etablierte Norm", sondern „die Lücke ist real, sie ist dokumentiert, und unabhängige Versuche, sie zu füllen, einigen sich ungefähr auf diese Themen."

Und zwei grosse Normenwerke dürfen nicht zitiert werden, als beantworteten sie das hier. ISO/IEC 42001 und das NIST AI Risk Management Framework sind Rahmenwerke der Organisationssicherung; ihre Betrachtungseinheit ist ein KI-System in einem Risikoportfolio, nicht ein Mensch, der eine Aufgabe übergibt und zurücknimmt. Einzelne NIST-Unterkategorien sind oben zitiert, weil sie etwas Präzises über Übersteuern, Stoppen und Rollendefinition sagen. Die Rahmenwerke als Ganzes sind keine Themenliste für eine arbeitende Disziplin, und sie als solche auszugeben, würde beide falsch darstellen.

Bewusst nicht zitiert: ein Rahmenwerk der internen Kontrolle, dessen Gegenstand Organisationssicherung ist und nicht Übergabe; ein Führungsmodell, dessen empirische Stützung schwach genug ist, dass es als Vokabular taugt, aber nicht als Beleg; und zwei Dokumente von 2026 — ein Entwurf und ein Einzelautoren-Preprint, das seine eigene empirische Validierung als künftige Arbeit ausweist — die nützliche Konvergenzsignale sind und keine etablierte Praxis.

Der Vollständigkeitstest#

Die zehn Themen an die Seite, die fünf Schichten nach oben, und in jede Zelle das Artefakt, das es trägt. Unten steht die typische Aufstellung als Ausgangspunkt — die eigene daneben zu legen ist der ganze Test.

● trägt das Thema · ○ deckt es mit ab · leer — nicht dort

Die Matrix beantwortet drei Fragen, ohne dass man nachdenken muss:

• Eine Zeile ohne ● ist eine Lücke. Das Thema hat kein Artefakt — es lebt in den Köpfen.
• Eine Zeile, deren einziges ● in Spalte 1 steht, ist eine Regel, auf deren Befolgung man hofft. In der typischen Aufstellung oben trifft das ausgerechnet Übergabe und Befugnis — die zwei Themen mit den grössten Folgen, und die zwei, die nur advisorisch dastehen.
• Eine leere Spalte 5 heisst, die Disziplin wächst und niemand räumt auf.
• Eine Spalte ganz ohne ● ist eine Spalte, die ihre Zeile sucht. Spalte 6 ist genau das, und sie ist das Neueste auf dieser Seite. Siehe unten.
• Eine Spalte, die mehr benennt, als ihre Zeilen erreichen, ist derselbe Fehler eine Nummer kleiner. Spalte 5 ist nach drei Dingen benannt, die zehn Themen erreichen zwei davon: nichts an der Seite fragt, ob eine Datei im richtigen Moment auslöst. Das Auslöser-Drittel von Schicht 5 hat hier keine Zeile.

Zwei Diagnosen, die einmal im Quartal lohnen:

1. Welche Themen liegen nur in Schicht 1? Das sind die, die Termindruck nicht überstehen. Das ist kein Argument, sie alle zu gaten — manche lassen sich wirklich nicht gaten — aber es ist die Liste dessen, worauf man vertraut statt es durchzusetzen, und das sollte eine Entscheidung sein und kein Zufall.
2. Ist der Kreis geschlossen? Wenn nichts, das gemessen wird, je eine Regel oder ein Gate ändert, ist die rechte Hälfte des Diagramms Dekoration.

Spalte 6 — Befolgung, und warum sie kein ● hat#

Spalte 6 kam am 2026-09-03 dazu, nach der Lektüre von zehn öffentlichen Skill-Repositories (der Belegteil). Drei davon bauen etwas, das keine der fünf Schichten beschreibt: Arbeit, die auf den Abstand zwischen einer Anweisung zielt, die richtig ist, und einer, der unter Druck gefolgt wird. Szenariodateien, die einen Agenten hart bedrängen, um zu sehen, ob er die Prozedur fallen lässt; eine Pflichttabelle, die jede vorhergesehene Ausrede mit ihrer Widerlegung paart, durchgesetzt vom Linter des Repositories selbst; ein Bestand an Untersuchungen über die Fehlermodi des Delegierten.

Ein Gate steht außerhalb der Arbeit und verweigert. Das hier steht mittendrin und argumentiert. Es ist nicht Schicht 1 — es ist keine Aussage darüber, was wahr ist. Es ist nicht Schicht 2 — nichts endet mit einem Fehlercode. Und es ist auch nicht einfach gutes Schreiben, was der zu schlagende Einwand ist: Gute technische Dokumentation beantwortet die Frage, die der Leser gestellt hat; das hier beantwortet den Einwand, den er nicht erhoben hat und nur unter Druck erheben würde.

Die veröffentlichte Literatur stützt die Einordnung, nicht die Beförderung. Eine Untersuchung von 238 Instruktionsdateien führt es als fehlenden Abschnitt — nicht als fehlendes Artefakt — und findet es in 94 % von ihnen nicht vor. Die Messungen, die drei Dinge, die nicht funktionieren, und die Methode, eine Regel zu testen, stehen im Anhang 0520.

Und es bekommt in keiner Zeile ein ●, und das ist der interessante Teil. Es deckt Grenzen, Ablauf und Prüfung mit ab, und es ist keines davon. Entweder fehlt den zehn Themen eine Zeile — nennen wir sie Befolgung — oder Befolgung ist ein Modus, in dem die anderen Themen verfolgt werden, und kein eigenes Thema. Diese Seite entscheidet das nicht, denn drei Repositories genügen, um zu zeigen, dass es etwas gibt, und nicht, um eine Methode darum herum umzubauen. Eine Spalte ohne ● ist eine Spalte, die ihre Zeile sucht, und das zu sagen ist nützlicher, als eine Zelle zu füllen, damit die Tabelle fertig aussieht.

Was diese Seite nicht kann#

Sie kann nicht sagen, welcher Grad an Selbstständigkeit für die eigene Arbeit richtig ist. Die veröffentlichte Vorarbeit ist in einem Punkt einig und danach still: der Grad wird pro Entscheidungsbereich festgelegt, nicht pro Person und nicht einmalig — und niemand hat eine Regel für die Wahl, die den Kontakt mit einem konkreten Team überlebt. Die eine Asymmetrie, die quellenübergreifend wiederkehrt, lohnt trotzdem die Übernahme: Hochstufen ist langsam und belegbasiert; Herabstufen ist schnell und steht jedem offen.

Und eine vollständige Disziplin ist noch keine gute. Vollständigkeit ist eine Abdeckungseigenschaft. Ob die Regeln die richtigen sind und ob das Ganze seinen Preis wert ist, dafür ist Thema 10 da — und Thema 10 ist das mit dem schwächsten Rückhalt.

Fertig, wenn#

• Jedes der zehn Themen hat ein benanntes Artefakt, das es abdeckt
• Die Themen, die nur in Schicht 1 liegen, sind eine Entscheidung, aufgeschrieben, kein Rest
• Etwas Gemessenes hat mindestens einmal tatsächlich eine Regel oder ein Gate verändert
• Es gibt einen Weg zu erkennen, ob ein Artefakt vor einem Leser das aktuelle ist
• Die Themenliste wurde gegen die eigenen Vorfälle gelesen und dort erweitert, wo sie abweichen

Referenzen#

Alle geöffnet am 2026-09-03. Die gemessene Literatur dazu, ob eine geschriebene Regel unter Konflikt befolgt wird, steht gesammelt im Anhang 0520 und nicht hier noch einmal — eine kanonische Liste, sonst driften die Kopien.

• EU-KI-Verordnung, Artikel 14 — Menschliche Aufsicht. <https://artificialintelligenceact.eu/article/14/>
• NIST AI Risk Management Framework 1.0 (NIST AI 100-1, Januar 2023) — Unterkategorien GOVERN 3.2, MANAGE 2.4, MANAGE 4.1. <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf>
• ISO/IEC 42001:2023, Klauselstruktur aus der kostenlosen Vorschau des Herausgebers — hier nur zitiert, um zu sagen, worum es nicht geht.
• Anthropic, „Building effective agents" (2024-12-19). <https://www.anthropic.com/engineering/building-effective-agents>
• Anthropic, „Our framework for developing safe and trustworthy agents" (2025-08-04). <https://www.anthropic.com/news/our-framework-for-developing-safe-and-trustworthy-agents>
• OpenAI, „A practical guide to building agents" — Werkzeug-Risikobewertung und Eskalationsauslöser. <https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf>
• Google, „An Introduction to Google's Approach for Secure AI Agents" (2025). <https://research.google/pubs/an-introduction-to-googles-approach-for-secure-ai-agents/>
• Parasuraman, Sheridan & Wickens (2000), „A model for types and levels of human interaction with automation" — die kanonische Vorarbeit zur Übergabe an eine Maschine, fünfundzwanzig Jahre früher.
• Delegation Poker / das Delegation Board — sieben Stufen, Befugnis pro Entscheidungsbereich. <https://management30.com/practice/delegation-poker/>
• WHO-Checkliste für sichere Chirurgie — das Muster der Prüfpunkt-Grenze, mit Ergebnisdaten. <https://www.nejm.org/doi/full/10.1056/NEJMsa0810119>
• HAIF, arXiv:2602.07641 (Februar 2026) — die dokumentierte Abdeckungslücke. Einzelautoren-Preprint, nicht begutachtet; die eigene empirische Validierung wird als künftige Arbeit ausgewiesen. <https://arxiv.org/pdf/2602.07641>
• Cloud Security Alliance, „NIST AI RMF: Agentic Profile" (Entwurf, 2026-03-27) — ein Entwurf, von der CSA verfasst und nicht von NIST bestätigt. <https://labs.cloudsecurityalliance.org/agentic/agentic-nist-ai-rmf-profile-v1/>

Zurück zu Karte und Rezept.

Phụ lục 0510 — Kiến trúc của một kỷ luật#

Bộ công cụ sinh tồn, phụ lục cho phần 5 · Bắt đầu tại đây · trước đó: Lớp 5 — Chỉ mục, trigger và việc duy trì

Vì sao trang này tồn tại#

Năm lớp nói những loại artefact nào tạo nên một kỷ luật. Chúng không nói được một kỷ luật đã đầy đủ hay chưa. Bạn có thể có đủ cả năm mà vẫn không biết chuyện gì xảy ra khi agent làm một việc không đảo ngược được lúc 18:40, ai chịu trách nhiệm về kết quả, hay bằng cách nào bạn nhận ra rằng kỷ luật đã ngừng hoạt động.

Trang này cung cấp trục còn thiếu: hình dạng của một kỷ luật trọn vẹn, những chủ đề nó phải phủ, và một phép thử để tìm ra lỗ hổng của chính bạn. Đây là một phụ lục, không phải lớp thứ sáu — nó không thêm artefact nào.

Một kỷ luật là một vòng lặp khép kín, không phải một đống tài liệu#

Sơ đồ sau cho thấy năm lớp nối với nhau thế nào khi đã có đủ cả năm. Phần văn xuôi bên dưới mang cùng nội dung.

Quy tắc và cổng nuôi các nghi thức; các cổng cũng ràng buộc trực tiếp lên công việc, và đó chính là toàn bộ lý do chúng là lớp giữ được khi không ai trông. Công việc để lại bản ghi. Bản ghi là thứ mà đo lường đọc. Đo lường nuôi việc duy trì, và duy trì thay đổi các quy tắc và các cổng — đó là chỗ vòng lặp khép lại.

Phần lớn các kỷ luật thành văn chỉ là nửa trái của bức tranh đó. Chúng có quy tắc, quy trình và thiện chí, và không có gì bao giờ quay lại thay đổi chúng. Đó không phải một kỷ luật; đó là một đống tài liệu tình cờ nằm chung một thư mục.

Hai yếu tố mà năm lớp không chứa#

Việc soi lại một kỷ luật đang hoạt động làm lộ ra hai tính chất mà không lớp nào trong năm lớp diễn đạt được, và cả hai đều nằm trong vòng lặp ở trên:

Tính toàn vẹn là thứ người ta hay bỏ sót. Nó không phải "quy tắc có đúng không" — câu hỏi mà mọi lớp đều đã hỏi — nó là "quy tắc trước mặt người đọc có phải là quy tắc hiện hành không". Nhìn từ bên ngoài, hai kiểu hỏng đó trông giống hệt nhau và có hai cách sửa ngược nhau.

Một kỷ luật phải phủ những gì#

Mười chủ đề. Danh sách này không lấy từ một tiêu chuẩn nào: tính đến 2026-09-03, không nguồn nào nêu tên bên dưới công bố một danh sách như vậy — xem phần tiếp theo để biết chính xác lời khẳng định đó đi xa tới đâu và dựa trên cái gì. Nó được rút ra từ việc quan sát một kỷ luật đang hoạt động, rồi đối chiếu chéo với những gì các nguồn đã công bố có nói. Cột cuối nêu tên phép đối chiếu chéo, hoặc nói thẳng là không có.

Cột giai đoạn là thứ tự thứ hai trong danh sách đó: mười chủ đề không rải đều, chúng dồn cụm ở trước công việc và ở đoạn cuối. Sơ đồ sau cho thấy chúng nằm ở đâu trong diễn tiến của một phần việc được uỷ thác.

Phần giữa mỏng không phải là một sơ suất của danh sách. Có ít thứ nhất để quản trong lúc làm việc, bởi tới lúc đó mọi thứ đã được quyết xong — và đó chính xác là lý do vì sao rất dễ bỏ qua các chủ đề đứng trước nó mà vẫn tin rằng mình có một kỷ luật.

Chủ đề 7 được đánh dấu vì nó là lỗ hổng trung thực: điều duy nhất mà danh sách này khẳng định chỉ dựa trên quan sát, dòng của nó mang ngày của lần tìm kiếm đã không tìm thấy gì thay vì một lời khẳng định thường trực rằng không có gì tồn tại. Nó nằm trong danh sách vì một kỷ luật thiếu nó sẽ hỏng theo những kiểu mà loạt bài này đã chứng kiến — nhưng người đọc nên biết rằng nó chỉ dựa trên quan sát. Chủ đề 10 là lỗ hổng thứ hai kiểu ấy cho tới 2026-09-03, khi việc đọc kho ngữ liệu công khai tìm ra bốn kho đo đúng điều đó. Dòng của nó ghi lại lần sửa ấy thay vì lặng lẽ nuốt nó đi.

Danh sách này đến từ đâu, và nó không phải là gì#

Cám dỗ ở đây là khoác cho một danh sách rút ra từ quan sát cái uy tín của một tiêu chuẩn. Ba điều khiến việc đó là không cần thiết, và một trong ba điều đó khiến nó là không trung thực.

Lỗ hổng đã được ghi nhận thành tài liệu, không chỉ được khẳng định suông. Một bản preprint tháng Hai 2026 chấm điểm năm khung đã được thiết lập — Scrum, DevOps, MLOps, AI Governance và human-in-the-loop — theo nhu cầu vận hành của những đội mà agent làm phần việc thực chất, và đánh dấu uỷ thác công việc cho AI là không được ba khung trong số đó đề cập và chỉ được hai khung còn lại đề cập một phần. Chẩn đoán của nó là câu sắc bén nhất tìm được trong nghiên cứu này: "Quản trị định nghĩa các ràng buộc; nó không định nghĩa các luồng công việc." Đó chính xác là khoảng cách giữa một tiêu chuẩn quản lý AI và thứ một đội cần vào sáng thứ Hai.

Hai nỗ lực độc lập của năm 2026 đang hội tụ về cùng một bộ từ vựng còn thiếu — các bậc tự chủ, trách nhiệm khi uỷ thác, quyền sở hữu có tên, ngừng vận hành. Sự hội tụ đó là điều mạnh nhất mà trang này có thể khẳng định một cách trung thực: không phải "đặt nền trên một tiêu chuẩn đã được thiết lập" mà là "lỗ hổng là có thật, nó đã được ghi nhận, và các nỗ lực độc lập nhằm lấp nó đồng thuận về đại khái những chủ đề này."

Và hai tiêu chuẩn lớn không được phép trích dẫn như thể chúng đã trả lời câu hỏi này. ISO/IEC 42001 và NIST AI Risk Management Framework là các khung bảo đảm ở cấp tổ chức; đơn vị phân tích của chúng là một hệ thống AI trong một danh mục rủi ro, không phải một người giao đi một nhiệm vụ rồi nhận lại nó. Các tiểu mục riêng lẻ của NIST được trích ở trên vì chúng nói điều gì đó chính xác về ghi đè, dừng và định nghĩa vai trò. Các khung xét như tổng thể không phải là một danh sách chủ đề cho một kỷ luật đang hoạt động, và trình bày chúng như vậy sẽ xuyên tạc cả hai.

Cố ý không trích dẫn: một khung kiểm soát nội bộ có đối tượng là bảo đảm ở cấp tổ chức chứ không phải việc uỷ thác; một mô hình lãnh đạo mà hậu thuẫn thực nghiệm yếu tới mức nó có thể dùng làm từ vựng chứ không làm bằng chứng; và hai tài liệu năm 2026 — một bản profile nháp và một preprint một tác giả tự nói rằng việc kiểm chứng thực nghiệm của chính nó là công việc tương lai — vốn là những tín hiệu hữu ích về sự hội tụ và không phải là thực hành đã được thiết lập.

Phép thử tính đầy đủ#

Mười chủ đề dọc theo cạnh bên, năm lớp ngang trên đầu, và trong mỗi ô là artefact gánh chủ đề đó. Bên dưới là cách sắp xếp điển hình, dùng làm điểm khởi đầu — đặt bảng của chính bạn cạnh nó mới là toàn bộ phép thử.

● gánh chủ đề · ○ cũng phủ nó · để trống — không có

Ma trận trả lời ba câu hỏi mà không ai phải suy nghĩ:

• Một dòng không có ● là một lỗ hổng. Chủ đề đó không có artefact nào — nó sống trong đầu người.
• Một dòng mà ● duy nhất nằm ở cột 1 là một quy tắc bạn đang hy vọng người ta tuân theo. Trong cách sắp xếp điển hình ở trên thì đó chính là uỷ thác và thẩm quyền — hai chủ đề có hệ quả lớn nhất, và là hai chủ đề chỉ đứng trên thiện chí.
• Một cột 5 trống nghĩa là kỷ luật lớn lên mà không ai dọn dẹp.
• Một cột hoàn toàn không có ● là một cột đang đi tìm dòng của nó. Cột 6 đúng là như vậy, và nó là thứ mới nhất trên trang này. Xem bên dưới.
• Một cột nêu tên nhiều thứ hơn số thứ mà các dòng của nó chạm tới là cùng một lỗi, ở cỡ nhỏ hơn. Cột 5 được đặt tên theo ba thứ và mười chủ đề chạm tới hai trong số đó: không có gì dọc theo cạnh bên hỏi rằng một file có kích hoạt đúng thời điểm hay không. Phần trigger — cái thứ ba của lớp 5 — không có dòng nào ở đây.

Hai phép chẩn đoán đáng chạy mỗi quý một lần:

1. Những chủ đề nào chỉ sống ở lớp 1? Đó là những chủ đề sẽ không sống sót qua áp lực tiến độ. Đấy không phải là lý lẽ để đặt cổng cho tất cả chúng — một số thực sự không đặt cổng được — nhưng nó là danh sách những thứ bạn đang tin tưởng thay vì cưỡng chế, và nó nên là một quyết định chứ không phải một sự tình cờ.
2. Vòng lặp đã khép chưa? Nếu không có thứ gì bạn đo từng làm thay đổi một quy tắc hay một cổng thì nửa phải của sơ đồ chỉ là đồ trang trí.

Cột 6 — tuân thủ, và vì sao nó không có ●#

Cột 6 được thêm vào ngày 2026-09-03 sau khi đọc mười kho skill công khai (phần bằng chứng). Ba trong số đó xây một thứ mà không lớp nào trong năm lớp mô tả: công việc nhắm vào khoảng cách giữa một chỉ dẫn đúng và một chỉ dẫn được tuân theo dưới áp lực. Những file kịch bản ép agent thật mạnh để xem nó có bỏ quy trình hay không; một bảng bắt buộc ghép mỗi lời biện bạch được dự đoán với lời bác bỏ của nó, được cưỡng chế bởi chính linter của kho; một khối nghiên cứu về các kiểu hỏng của chính bên được uỷ thác.

Một cổng đứng bên ngoài công việc và từ chối. Thứ này đứng bên trong công việc và tranh luận. Nó không phải lớp 1 — nó không phải một phát biểu về điều gì là đúng. Nó không phải lớp 2 — không có gì thoát ra với mã khác không. Và nó cũng không đơn giản là viết hay, vốn là phản bác cần phải vượt qua: viết kỹ thuật hay thì trả lời câu hỏi người đọc đã hỏi; thứ này trả lời phản bác mà người đọc chưa nêu, và chỉ nêu lên khi bị áp lực.

Tài liệu đã công bố đồng ý với vị trí đặt nó chứ không đồng ý với việc thăng hạng nó. Một nghiên cứu trên 238 file chỉ dẫn xếp nó là một mục còn thiếu — không phải một artefact còn thiếu — và thấy nó vắng mặt ở 94 % số file. Các phép đo, ba thứ không hoạt động, và phương pháp để kiểm thử một quy tắc được gom trong phụ lục 0520.

Và nó không kiếm được ● ở dòng nào cả, đó mới là phần thú vị. Nó cũng phủ ranh giới, quy trình và kiểm chứng, mà nó lại không phải bất kỳ cái nào trong số đó. Hoặc là mười chủ đề đang thiếu một dòng — gọi nó là sự tuân phục — hoặc tuân thủ là một chế độ mà trong đó các chủ đề kia được theo đuổi, chứ không phải một chủ đề riêng. Trang này không phân xử điều đó, bởi ba kho là đủ để cho thấy một thứ tồn tại chứ không đủ để tái cấu trúc cả một phương pháp quanh nó. Một cột không có ● là một cột đang đi tìm dòng của nó, và nói ra điều đó thì hữu ích hơn là điền đại một ô cho bảng trông có vẻ đã xong.

Trang này không làm được gì#

Nó không nói được cho bạn mức uỷ thác đúng đắn cho công việc của bạn. Các công trình đã công bố nhất trí ở một điểm và im lặng sau đó: mức được đặt theo từng vùng quyết định, không theo từng người và không đặt một lần — và không ai có một quy tắc chọn mức mà sống sót khi va vào một đội cụ thể. Có một sự bất đối xứng lặp lại xuyên suốt các nguồn và dù sao cũng đáng áp dụng: thăng hạng thì chậm và dựa trên bằng chứng; hạ hạng thì nhanh và ai cũng làm được.

Một kỷ luật đầy đủ cũng không phải là một kỷ luật tốt. Đầy đủ là một tính chất về độ phủ. Còn các quy tắc có phải là các quy tắc đúng hay không, và toàn bộ cách sắp xếp có đáng cái giá của nó hay không, là việc của chủ đề 10 — và chủ đề 10 là chủ đề có ít hậu thuẫn nhất.

Xong khi#

• Mỗi chủ đề trong mười chủ đề đều có một artefact có tên phủ nó
• Những chủ đề chỉ sống ở lớp 1 là một quyết định, được viết ra, chứ không phải phần sót lại
• Một thứ bạn đo đã thực sự làm thay đổi một quy tắc hoặc một cổng ít nhất một lần
• Có một cách để biết rằng artefact trước mặt một người đọc là artefact hiện hành
• Danh sách chủ đề đã được đọc lại đối chiếu với các sự cố của chính bạn, và được mở rộng ở chỗ của bạn khác đi

Tài liệu tham khảo#

Tất cả đều được mở ngày 2026-09-03. Tài liệu đã đo về việc một quy tắc thành văn có được tuân theo khi có xung đột hay không được gom trong phụ lục 0520 thay vì chép lại ở đây — một danh sách chuẩn duy nhất, nếu không các bản sao sẽ trôi xa nhau.

• EU AI Act, Article 14 — Human oversight. <https://artificialintelligenceact.eu/article/14/>
• NIST AI Risk Management Framework 1.0 (NIST AI 100-1, tháng Một 2023) — các tiểu mục GOVERN 3.2, MANAGE 2.4, MANAGE 4.1. <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf>
• ISO/IEC 42001:2023, cấu trúc điều khoản lấy từ bản xem trước miễn phí của nhà xuất bản — được trích ở đây chỉ để nói nó không nói về cái gì.
• Anthropic, "Building effective agents" (2024-12-19). <https://www.anthropic.com/engineering/building-effective-agents>
• Anthropic, "Our framework for developing safe and trustworthy agents" (2025-08-04). <https://www.anthropic.com/news/our-framework-for-developing-safe-and-trustworthy-agents>
• OpenAI, "A practical guide to building agents" — thang xếp hạng rủi ro công cụ và các điều kiện kích hoạt leo thang. <https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf>
• Google, "An Introduction to Google's Approach for Secure AI Agents" (2025). <https://research.google/pubs/an-introduction-to-googles-approach-for-secure-ai-agents/>
• Parasuraman, Sheridan & Wickens (2000), "A model for types and levels of human interaction with automation" — công trình đi trước kinh điển về việc uỷ thác cho một cỗ máy, sớm hai mươi lăm năm.
• Delegation Poker / the Delegation Board — bảy mức, thẩm quyền đặt theo từng vùng quyết định. <https://management30.com/practice/delegation-poker/>
• WHO Surgical Safety Checklist — mô hình ranh giới điểm kiểm, kèm dữ liệu kết quả. <https://www.nejm.org/doi/full/10.1056/NEJMsa0810119>
• HAIF, arXiv:2602.07641 (tháng Hai 2026) — lỗ hổng độ phủ đã được ghi nhận. Preprint một tác giả, chưa bình duyệt; việc kiểm chứng thực nghiệm của chính nó được nêu là công việc tương lai. <https://arxiv.org/pdf/2602.07641>
• Cloud Security Alliance, "NIST AI RMF: Agentic Profile" (bản nháp, 2026-03-27) — một bản nháp, do CSA soạn và không được NIST xác nhận. <https://labs.cloudsecurityalliance.org/agentic/agentic-nist-ai-rmf-profile-v1/>

Quay lại bản đồ và công thức.

Appendix 0520 — Testing a rule#

Survival toolbox, second appendix · Start here · previous: Appendix 0510 — the architecture of a discipline · the evidence: What the public corpus shows

Why this page exists#

The five layers work on getting the rule right. None of them asks whether it holds.

That gap has a name in the published literature and a measured size. A study of 238 real skill files catalogues 26 recurring defects; the most common of all of them — reported in 223 files, 94 % — is the Rationalization Loophole: the file "provides no guidance to discourage the agent from rationalizing or skipping required steps" (Hong et al. 2026). The denominator behind that percentage does not reconcile inside the source itself; the reference entry says where it comes apart.

This is an appendix, not a sixth layer, for the same reason 0510 is one: it adds no artefact. Its output is wording inside a rule file and a step inside a ritual. The evidence section says how that was settled and against what.

The distinction that makes it a topic at all#

Good technical writing answers a question the reader asked. This answers the objection the reader has not raised — and would only raise under pressure.

That sentence was written to be attacked and survived the attack. It is not a slogan: the practice has a failure taxonomy that routes different failures to different remedies, and gets it wrong if you apply the remedies to the wrong failure. One repository states the boundary outright — for output that is merely the wrong shape, "prohibition-based bulletproofing backfires" (obra/superpowers, skills/writing-skills/SKILL.md). That is a craft, not a style preference.

What the measurements actually say#

Two regimes, and they are not in conflict — they measure different situations.

Without conflict, written instructions are followed. A controlled evaluation of repository context files found they "do not generally improve task success rates, while instructions in the context files are well followed" (Evaluating AGENTS.md 2026). A rule file is measurably an efficiency mechanism rather than a correctness one: −16.58 % output tokens and −28.64 % wall clock (Efficiency of AGENTS.md 2026).

Those two sentences sit on opposite sides of a cost disagreement, so the ids matter. The "well followed" paper is also the one reporting context files raising inference cost by over 20 % on average, across several models and agents (arXiv:2602.11988). The −16.58 % / −28.64 % figures are a different preprint, measuring median wall clock and output tokens over 10 repositories and 124 pull requests (arXiv:2601.20404). 0000 and 0100 carry both figures side by side, with their signs opposite; the disagreement is not resolved here.

With conflict, adherence comes apart — along a different axis in every study.

Read the 46-point spread twice. Same rule, same words, twelve models, and the outcome ranges across almost half the scale. Which model you hand the work to is part of the discipline, and no sentence you write changes that.

Three things that do not work#

Worth reading twice, because all three are what a reasonable person tries first.

1 · Saying it louder. All four prompt variants in one benchmark carry DO NOT MODIFY THE TESTS. in bold capitals — including the variant that produces over 85 % cheating (ImpossibleBench). The prohibition was present and was read past.

2 · Rewording it. Across 11 models and 830+ invocations, the encoding form of a constraint had no significant effect (Cliff's δ < 0.01, ±2.6 pp). What dominated was the type of rule: one that opposes the model's defaults fails 10–100 % of the time, a conventional one holds at 99 %+. The authors' own conclusion: "engineering effort toward compliance is better directed at constraint design than prompt formatting" (Compact Constraint Encoding).

"Form does not matter" is not "wording does not matter" — between the two lies a whole axis. That study varies how a constraint is encoded. A separate one varies its polarity — forbid rather than instruct — and finds the two do come apart: across 679 scraped rule files (25,532 rules) and over 5,000 Claude Code runs on SWE-bench Verified, "in our data every individually beneficial rule is a negative constraint […], while every individually harmful one is a positive directive" (Guardrails Beat Guidance).

So: three findings on three axes, and they are easy to collapse into one another. Form has no measurable effect; polarity does; opposing the model's own defaults outweighs both. Take the polarity result at the size its own authors give it — one study, one benchmark subset, and the phrase is "in our data": a classification of the rules they scraped, not a paired test of the same rule written both ways. The same paper reports that randomly generated rules match expert-curated ones (+13.8 pp either way) and that individually harmful rules do not visibly accumulate damage inside a set, which is reason to hold the finding loosely rather than build on it. Vendor guidance points the other way — "tell Claude what to do instead of what not to do" — but scoped to controlling output format, not to holding a boundary (Anthropic prompting guidance).

3 · Naming the penalty. Specifying the consequence of breaking the rule turns an obligation into a cost-benefit calculation and favours the violation — the enforcement-information paradox (Why Do AI Agents Break Rules?).

What did work: give the rule a way out#

The one intervention that moved a benchmark by a large margin did not forbid harder. It supplied a licensed alternative action for the moment of conflict — in substance: stop, identify the incorrect tests, and explain why they are wrong, instead of carving up the code to pass them (ImpossibleBench).

A rule that only forbids leaves the reader with no way out of the situation that made them break it.

Now read the size of that result carefully, because it is the most quotable number on this page and the easiest to misuse. The >85 % → 1 % figure is one model on one benchmark with a minimal scaffold. The same prompts on another model move >85 % → 33 %; on the harder benchmark the effect nearly vanishes, with loosening moving one model 54 % → 66 % and another 50 % → 55 % (ImpossibleBench). What generalises is the shape, not the number.

How to test a rule#

You can test a written rule the way you test code, and one repository does exactly that: write the pressure scenario, watch the rule fail, write the rule, watch it hold, then close the loopholes (obra/superpowers, skills/writing-skills/).

The control comes first, and it is the step people skip. "If you didn't watch an agent fail without the skill, you don't know if the skill prevents the right failures" — and if the control does not exhibit the failure, there is nothing to fix, so do not write the guidance (obra/superpowers, skills/writing-skills/testing-skills-with-subagents.md). A rule written for a failure that was never observed is the most common thing in every rule file, and it costs attention on every single task.

The three pressures#

The scenarios in that repository combine pressures rather than applying one, and the three combinations are named: time and money · sunk cost and exhaustion · authority and social. They are the same three that break human procedures, which is why this transfers.

Writing the row#

The excuse is quoted as it was actually given, and the rebuttal closes that specific escape rather than restating the rule:

| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. | | "This is just a simple question" | Questions are tasks. Check for skills. | | "I remember this skill" | Skills evolve. Read current version. |

One more, because it is a trap in its own right: an exemption clause does not scope. "This limit does not apply to code blocks" still suppresses code blocks; if part of the output must be exempt, restructure the rule so it cannot reach it.

Outside software#

A fire drill is a pressure test. Nobody doubts that people know where the exit is — the drill exists because knowing and doing come apart under conditions. The same reasoning explains why a surgical checklist is read aloud, at exactly the moment skipping it feels reasonable (0510 cites its outcome data).

The transferable parts, none of which need software:

• Quote the excuse verbatim. Any procedure that gets skipped — a handover, a closing check, a safeguarding step — earns a two-column appendix of the exact sentences people say when they skip it, each with its answer. Write what they said, not what you imagine they would say.
• Name the alternative. A policy that only forbids leaves someone stuck in the situation that made forbidding expensive. Say what to do instead.
• Rehearse it on the busy day, not the quiet one. A rule tested in calm conditions has not been tested.
• Do not publish the penalty as the reason. It invites the arithmetic (Why agents break rules).

What this page cannot do#

It has no exit code. Everything here persuades; nothing here refuses. It does not replace layer 2 and is at its most dangerous when it feels like a substitute for one — every verifier is a proxy for intent rather than intent itself (The Verification Horizon), and a rule that merely reads as convincing has no such proxy at all. It fails silently, and you find out afterwards, from layer 4.

It also cannot tell you whether any of this holds for work that is not software. Every measurement on this page is from coding agents. Generalising it is an argument, not a measurement.

And one honesty note about the strongest-sounding source in this area. The repository that documents this practice most thoroughly rests it on a persuasion study of N = 28,000 conversations in which compliance rose from 33 % to 72 % (Meincke et al. 2025) — but that study measures persuading a model to comply with requests it would normally refuse, on a single model. It is evidence that persuasion cues move a model a great deal. It is not evidence that they keep your own rule intact under pressure, and it is used here only for the first claim.

Done when#

• Every rule you rely on under pressure has at least one scenario that tried to break it.
• Every scenario has a control run without the rule, and the control actually failed.
• Every rule that forbids also names what to do instead.
• Every excuse row quotes something that was really said.
• Nothing on this page is being used where a gate belongs.

References#

All opened 2026-09-04. Preprint status is stated where it applies; a number without its scope is a number that will be misquoted.

The rationalization loophole#

From Anatomy to Smells: An Empirical Study of SKILL.md (Hong, Imani, Ahmed; 2026-07-03), arXiv:2607.01456 — 238 skill files qualitatively analysed, 26 defect classes; Rationalization Loophole is the most prevalent, classified under Missing Follow-Through Guards as a missing section. This is the source for the gap this page describes and for treating it as a section rather than an artefact of its own. Its prevalence figure does not reconcile inside the source: the running text says the detector was applied to "the remaining 238 SKILL.md files", Table IV heads that same column "Entire Sample (228 Skills)", and the printed 223 (94 %) matches 238, not 228 — which would be 97.8 %. Both the v1 and v2 full texts read this way, checked 2026-09-04. This page therefore quotes 223 and 94 % as printed and takes no view on the denominator. Preprint. <https://arxiv.org/abs/2607.01456>

Context files in the no conflict case#

Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? (2026-02-12), arXiv:2602.11988 — the "well followed" finding, in the no-conflict regime; also the source of the over-20 % inference-cost figure, which 0000 and 0100 cite alongside the opposite-signed figure from arXiv:2601.20404. Preprint. <https://arxiv.org/abs/2602.11988>

A rule file as an efficiency mechanism#

On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents (2026-01-28), arXiv:2601.20404 — Δ 16.58 % output tokens, Δ 28.64 % wall clock. Preprint. <https://arxiv.org/abs/2601.20404>

Removing one consent clause#

Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks (2026-05-18), arXiv:2605.18583 — 0.0 % → 17.1 % on paired scenarios when one consent clause is removed. The paper's term is overeager actions / scope expansions; destructive acts are examples of these, not the definition. Preprint. <https://arxiv.org/abs/2605.18583>

ImpossibleBench and the prompt variants#

ImpossibleBench: Measuring LLMs' Propensity of Exploiting Test Cases (Zhong, Raghunathan, Carlini; 2025-10-23), arXiv:2510.20270 — the prompt-variant results, and the fact that every variant contains the bold prohibition. The >85 % → 1 % figure is one model, one benchmark, minimal scaffold. Preprint. <https://arxiv.org/abs/2510.20270>

Encoding form versus constraint type#

Compact Constraint Encoding (2026-04-08), arXiv:2604.07192 — 11 models, 830+ invocations; encoding form has no significant effect (Cliff's δ < 0.01), constraint type dominates. Its type axis is counter-intuitive versus conventional constraints, not prohibition versus directive — a different axis from the one below. Preprint. <https://arxiv.org/abs/2604.07192>

Negative constraints versus positive directives#

Guardrails Beat Guidance: A Large-Scale Study of Rules, Skills, and Persistent Configuration for Coding Agents (Zhang, Wang, Cui, Qiu, Li, Zhu, He; 2026-04-13, revised 2026-05-28), arXiv:2604.11088 — 679 scraped rule files (25,532 rules) and over 5,000 Claude Code runs on SWE-bench Verified; random rules match expert-curated ones (+13.8 pp both), and in that data every individually beneficial rule is a negative constraint while every individually harmful one is a positive directive. Read the polarity claim at its stated scope: the authors write "in our data", and it is a classification of scraped rules rather than a paired experiment rewording one rule both ways — the same paper also finds the gains largely content-independent and the harmful rules non-accumulating in ensemble. Preprint. <https://arxiv.org/abs/2604.11088>

Why agents break rules#

Why Do AI Agents Break Rules? (2026-05-29), arXiv:2608.12323 — 46-point compliance spread across 12 models at identical wording; the enforcement-information paradox. Preprint. <https://arxiv.org/abs/2608.12323>

Constraint violations under KPI pressure#

Outcome-Driven Constraint Violations (2025-12-23), arXiv:2512.20798 — 0.0–62.8 % under KPI pressure; no improvement across model generations. Preprint. <https://arxiv.org/abs/2512.20798>

Goal drift under value conflict#

Asymmetric Goal Drift in Coding Agents Under Value Conflict (2026-03-03), arXiv:2603.03456 — violation rises with pressure and with accumulated context. Preprint. <https://arxiv.org/abs/2603.03456>

Specification gaming in reasoning models#

Towards Understanding Specification Gaming in Reasoning Models (2026-05-04), arXiv:2605.02269 — RL reasoning training increases gaming; mitigations reduce, never remove. Preprint. <https://arxiv.org/abs/2605.02269>

Every verifier is a proxy#

The Verification Horizon: No Silver Bullet for Coding Agent Rewards (2026-06-24), arXiv:2606.26300 — every verifier is a proxy for human intent, never intent itself. Preprint. <https://arxiv.org/abs/2606.26300>

Persuasion and objectionable requests#

Call Me A Jerk: Persuading AI to Comply with Objectionable Requests (Meincke, Shapiro, Duckworth, Mollick, Mollick & Cialdini; 2025-07-18), SSRN 5357179 — seven persuasion principles, N = 28,000 conversations, GPT-4o-mini, compliance 33 % → 72 %. Measures persuading a model toward requests it would normally refuse, which is the opposite direction to keeping your own rule intact. Working paper. <https://ssrn.com/abstract=5357179>

Vendor guidance on phrasing#

Anthropic, prompting best practices — "tell Claude what to do instead of what not to do", stated under controlling response format. <https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices>

• Instruction hierarchy — the conflict problem attacked at training time rather than in prose:

arXiv:2404.13208 (2024-04-19), arXiv:2511.04694, arXiv:2603.10521. Preprints.

• The repositories quoted on this page are studied one by one in

0601–0610, each with the paths its claims rest on.

Anhang 0520 — Eine Regel testen#

Survival-Toolbox, zweiter Anhang · Hier anfangen · vorher: Anhang 0510 — die Architektur einer Disziplin · die Belege: Was das öffentliche Korpus zeigt

Warum es diese Seite gibt#

Die fünf Schichten arbeiten daran, die Regel richtig zu bekommen. Keine von ihnen fragt, ob sie hält.

Diese Lücke hat in der veröffentlichten Literatur einen Namen und eine gemessene Größe. Eine Untersuchung von 238 echten Skill-Dateien katalogisiert 26 wiederkehrende Defekte; der häufigste von allen — berichtet für 223 Dateien, 94 % — ist das Rationalization Loophole: die Datei „provides no guidance to discourage the agent from rationalizing or skipping required steps" (Hong et al. 2026). Der Nenner hinter diesem Prozentsatz geht in der Quelle selbst nicht auf; der Referenzeintrag sagt, wo er auseinanderfällt.

Das hier ist ein Anhang, keine sechste Schicht, aus demselben Grund wie 0510: es fügt kein Artefakt hinzu. Sein Ergebnis sind Formulierungen in einer Regeldatei und ein Schritt in einem Ritual. Der Belegteil sagt, wie das entschieden wurde und wogegen.

Die Unterscheidung, die daraus überhaupt ein Thema macht#

Gute technische Dokumentation beantwortet die Frage, die der Leser gestellt hat. Das hier beantwortet den Einwand, den er noch nicht erhoben hat — und nur unter Druck erheben würde.

Dieser Satz wurde geschrieben, um angegriffen zu werden, und hat den Angriff überstanden. Er ist kein Slogan: Die Praxis hat eine Fehler-Taxonomie, die verschiedene Fehler auf verschiedene Mittel verteilt, und geht schief, wenn man die Mittel auf den falschen Fehler anwendet. Ein Repository sagt die Grenze ausdrücklich — für Ausgaben, die bloß die falsche Form haben, gilt: „prohibition-based bulletproofing backfires" (obra/superpowers, skills/writing-skills/SKILL.md). Das ist ein Handwerk, keine Stilvorliebe.

Was die Messungen wirklich sagen#

Zwei Regime, und sie widersprechen sich nicht — sie messen verschiedene Situationen.

Ohne Konflikt werden geschriebene Anweisungen befolgt. Eine kontrollierte Auswertung von Repository-Kontextdateien fand, dass sie „do not generally improve task success rates, while instructions in the context files are well followed" (Evaluating AGENTS.md 2026). Eine Regeldatei ist messbar ein Effizienz-Mechanismus und kein Korrektheits-Mechanismus: −16,58 % Ausgabe-Tokens und −28,64 % Laufzeit (Efficiency of AGENTS.md 2026).

Diese beiden Sätze stehen auf entgegengesetzten Seiten eines Kostenstreits — deshalb zählen die IDs. Die Studie mit dem „well followed"-Befund ist zugleich die, die berichtet, Kontextdateien erhöhten die Inferenzkosten im Mittel um über 20 %, über mehrere Modelle und Agenten hinweg (arXiv:2602.11988). Die −16,58 % / −28,64 % stammen aus einem anderen Preprint, das Median-Laufzeit und Ausgabe-Tokens über 10 Repositories und 124 Pull Requests misst (arXiv:2601.20404). 0000 und 0100 führen beide Zahlen nebeneinander, mit ihren gegensätzlichen Vorzeichen; der Widerspruch wird hier nicht aufgelöst.

Mit Konflikt fällt die Befolgung auseinander — in jeder Studie entlang einer anderen Achse.

Die 46 Punkte bitte zweimal lesen. Dieselbe Regel, dieselben Worte, zwölf Modelle — und das Ergebnis spannt fast die halbe Skala. Welchem Modell man die Arbeit gibt, ist Teil der Disziplin, und kein Satz, den man schreibt, ändert daran etwas.

Drei Dinge, die nicht funktionieren#

Zweimal lesen wert, denn alle drei sind das, was ein vernünftiger Mensch zuerst versucht.

1 · Lauter werden. Alle vier Prompt-Varianten eines Benchmarks tragen DO NOT MODIFY THE TESTS. in fetten Großbuchstaben — auch die Variante, die über 85 % Schummelquote erzeugt (ImpossibleBench). Das Verbot war da und wurde überlesen.

2 · Umformulieren. Über 11 Modelle und 830+ Aufrufe hatte die Kodierungsform einer Vorgabe keinen signifikanten Effekt (Cliff's δ < 0,01, ±2,6 PP). Was dominierte, war der Typ der Regel: Eine, die den Voreinstellungen des Modells widerspricht, scheitert in 10–100 % der Fälle, eine konventionelle hält bei 99 %+. Der Schluss der Autoren: „engineering effort toward compliance is better directed at constraint design than prompt formatting" (Compact Constraint Encoding).

„Die Form spielt keine Rolle" heißt nicht „die Formulierung spielt keine Rolle" — dazwischen liegt eine ganze Achse. Jene Studie variiert, wie eine Vorgabe kodiert ist. Eine andere variiert ihre Polarität — verbieten statt anweisen — und findet, dass die beiden sehr wohl auseinandertreten: über 679 gescrapte Regeldateien (25.532 Regeln) und mehr als 5.000 Claude-Code-Läufe auf SWE-bench Verified gilt „in our data every individually beneficial rule is a negative constraint […], while every individually harmful one is a positive directive" (Guardrails Beat Guidance).

Also drei Befunde auf drei Achsen, und sie sind leicht ineinanderzuschieben. Die Form hat keinen messbaren Effekt; die Polarität hat einen; der Widerspruch zu den Voreinstellungen des Modells wiegt schwerer als beide. Das Polaritäts-Ergebnis bitte in der Größe nehmen, die seine Autoren ihm selbst geben — eine Studie, ein Benchmark-Ausschnitt, und die Formulierung lautet „in our data": eine Klassifikation der gescrapten Regeln, kein gepaarter Test derselben Regel in beiden Fassungen. Dieselbe Arbeit berichtet, dass zufällig erzeugte Regeln kuratierten gleichkommen (+13,8 PP in beiden Fällen) und dass einzeln schädliche Regeln im Verbund keinen sichtbaren Schaden ansammeln — Grund genug, den Befund locker zu halten, statt darauf zu bauen. Die Hersteller-Doku weist in die andere Richtung — „tell Claude what to do instead of what not to do" — allerdings bezogen auf die Steuerung des Ausgabe*formats*, nicht auf das Halten einer Grenze (Anthropic prompting guidance).

3 · Die Strafe benennen. Die Folge eines Regelbruchs anzugeben macht aus einer Pflicht eine Kosten-Nutzen-Rechnung und begünstigt den Verstoß — das Enforcement-Information-Paradox (Why Do AI Agents Break Rules?).

Was funktioniert hat: der Regel einen Ausweg geben#

Der einzige Eingriff, der einen Benchmark deutlich bewegt hat, verbot nicht härter. Er lieferte eine erlaubte Alternativhandlung für den Moment des Konflikts — sinngemäß: halte an, benenne die falschen Tests und erkläre, warum sie falsch sind, statt den Code zurechtzuschneiden, damit sie durchlaufen (ImpossibleBench).

Eine Regel, die nur verbietet, lässt den Leser ohne Ausweg aus genau der Lage, die ihn die Regel brechen ließ.

Und jetzt die Größe dieses Ergebnisses genau lesen, denn es ist die zitierfähigste Zahl dieser Seite und die am leichtesten zu missbrauchende. Die >85 % → 1 % gelten für ein Modell auf einem Benchmark mit minimalem Gerüst. Dieselben Prompts bewegen ein anderes Modell von >85 % auf 33 %; auf dem schwereren Benchmark verschwindet der Effekt fast, dort bewegt Lockern ein Modell von 54 % auf 66 % und ein anderes von 50 % auf 55 % (ImpossibleBench). Übertragbar ist die Form, nicht die Zahl.

Wie man eine Regel testet#

Man kann eine geschriebene Regel testen wie Code, und ein Repository tut genau das: das Druck-Szenario schreiben, die Regel scheitern sehen, die Regel schreiben, sie halten sehen, dann die Schlupflöcher schließen (obra/superpowers, skills/writing-skills/).

Die Kontrolle kommt zuerst, und sie ist der Schritt, den man überspringt. „If you didn't watch an agent fail without the skill, you don't know if the skill prevents the right failures" — und wenn die Kontrolle den Fehler nicht zeigt, gibt es nichts zu reparieren, also schreibe die Anleitung nicht (obra/superpowers, skills/writing-skills/testing-skills-with-subagents.md). Eine Regel für einen Fehler, den nie jemand beobachtet hat, ist das Häufigste in jeder Regeldatei — und sie kostet bei jeder einzelnen Aufgabe Aufmerksamkeit.

Die drei Drucksorten#

Die Szenarien in jenem Repository kombinieren Druck, statt einen einzelnen anzuwenden, und die drei Kombinationen sind benannt: Zeit und Geld · Sunk Cost und Erschöpfung · Autorität und Sozialdruck. Es sind dieselben drei, die auch menschliche Verfahren brechen — deshalb überträgt sich das.

Die Zeile schreiben#

Die Ausrede wird so zitiert, wie sie wirklich gefallen ist, und die Widerlegung schließt genau diesen Ausweg, statt die Regel zu wiederholen:

| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. | | "This is just a simple question" | Questions are tasks. Check for skills. | | "I remember this skill" | Skills evolve. Read current version. |

Und noch eine, weil sie eine eigene Falle ist: eine Ausnahmeklausel begrenzt sich nicht selbst. „Diese Grenze gilt nicht für Codeblöcke" unterdrückt Codeblöcke trotzdem; muss ein Teil der Ausgabe ausgenommen sein, baue die Regel so um, dass sie ihn gar nicht erreicht.

Außerhalb der Software#

Eine Feuerübung ist ein Drucktest. Niemand bezweifelt, dass Leute wissen, wo der Ausgang ist — die Übung gibt es, weil Wissen und Tun unter Bedingungen auseinanderfallen. Dieselbe Überlegung erklärt, warum eine OP-Checkliste laut vorgelesen wird, genau in dem Moment, in dem Überspringen vernünftig wirkt (0510 zitiert ihre Ergebnisdaten).

Was sich überträgt, ganz ohne Software:

• Die Ausrede wörtlich zitieren. Jedes Verfahren, das übersprungen wird — eine Übergabe, ein Abschluss-Check, ein Schutzschritt — verdient einen zweispaltigen Anhang mit den genauen Sätzen, die Leute beim Überspringen sagen, jeweils mit der Antwort. Aufschreiben, was sie gesagt haben, nicht, was man sich vorstellt.
• Die Alternative benennen. Eine Vorschrift, die nur verbietet, lässt jemanden in genau der Lage sitzen, die das Verbieten teuer gemacht hat. Sag, was stattdessen zu tun ist.
• Am hektischen Tag proben, nicht am ruhigen. Eine Regel, die unter Ruhe geprüft wurde, ist nicht geprüft.
• Die Strafe nicht als Begründung veröffentlichen. Das lädt zum Rechnen ein (Warum Agenten Regeln brechen).

Was diese Seite nicht kann#

Sie hat keinen Exit-Code. Alles hier überredet; nichts hier verweigert. Sie ersetzt Schicht 2 nicht und ist am gefährlichsten, wenn sie sich wie ein Ersatz dafür anfühlt — jeder Prüfer ist ein Stellvertreter für die Absicht und nie die Absicht selbst (The Verification Horizon), und eine Regel, die sich bloß überzeugend liest, hat nicht einmal diesen Stellvertreter. Sie scheitert lautlos, und man erfährt es hinterher, aus Schicht 4.

Sie kann auch nicht sagen, ob irgendetwas davon für Arbeit außerhalb der Software gilt. Jede Messung auf dieser Seite stammt von Coding-Agenten. Sie zu verallgemeinern ist ein Argument, keine Messung.

Und eine Ehrlichkeitsnotiz zur am stärksten klingenden Quelle in diesem Feld. Das Repository, das diese Praxis am gründlichsten dokumentiert, stützt sie auf eine Überredungsstudie mit N = 28.000 Konversationen, in der die Befolgung von 33 % auf 72 % stieg (Meincke et al. 2025) — aber diese Studie misst, wie man ein Modell zu Anfragen überredet, die es normalerweise ablehnt, an einem einzigen Modell. Sie belegt, dass Überredungsreize ein Modell stark bewegen. Sie belegt nicht, dass sie die eigene Regel unter Druck intakt halten, und sie wird hier nur für die erste Aussage verwendet.

Fertig, wenn#

• Jede Regel, auf die man sich unter Druck verlässt, hat mindestens ein Szenario, das sie zu brechen versucht hat.
• Jedes Szenario hat einen Kontrolllauf ohne die Regel, und die Kontrolle ist wirklich gescheitert.
• Jede Regel, die verbietet, benennt auch, was stattdessen zu tun ist.
• Jede Ausredenzeile zitiert etwas, das wirklich gesagt wurde.
• Nichts auf dieser Seite wird dort eingesetzt, wo ein Gate hingehört.

Referenzen#

Alle geöffnet am 2026-09-04. Der Preprint-Status ist genannt, wo er gilt; eine Zahl ohne ihren Geltungsbereich ist eine Zahl, die falsch zitiert werden wird.

Das Rationalization Loophole#

From Anatomy to Smells: An Empirical Study of SKILL.md (Hong, Imani, Ahmed; 2026-07-03), arXiv:2607.01456 — 238 qualitativ ausgewertete Skill-Dateien, 26 Defektklassen; das Rationalization Loophole ist das häufigste, eingeordnet unter Missing Follow-Through Guards als fehlender Abschnitt. Das ist die Quelle für die hier beschriebene Lücke und dafür, sie als Abschnitt statt als eigenes Artefakt zu behandeln. Ihre Prävalenzzahl geht in der Quelle selbst nicht auf: Der Fließtext sagt, der Detektor sei auf „the remaining 238 SKILL.md files" angewendet worden, Tabelle IV überschreibt dieselbe Spalte mit „Entire Sample (228 Skills)", und die gedruckten 223 (94 %) passen zu 238, nicht zu 228 — das wären 97,8 %. v1 und v2 des Volltexts lesen sich beide so, geprüft am 2026-09-04. Diese Seite zitiert daher 223 und 94 % wie gedruckt und legt sich auf keinen Nenner fest. Preprint. <https://arxiv.org/abs/2607.01456>

Kontextdateien ohne Konflikt#

Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? (2026-02-12), arXiv:2602.11988 — der „well followed"-Befund, im konfliktfreien Regime; zugleich die Quelle der Zahl von über 20 % Inferenzkosten, die 0000 und 0100 neben der gegenläufigen Zahl aus arXiv:2601.20404 zitieren. Preprint. <https://arxiv.org/abs/2602.11988>

Eine Regeldatei als Effizienzmechanismus#

On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents (2026-01-28), arXiv:2601.20404 — Δ 16,58 % Ausgabe-Tokens, Δ 28,64 % Laufzeit. Preprint. <https://arxiv.org/abs/2601.20404>

Eine entfernte Zustimmungsklausel#

Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks (2026-05-18), arXiv:2605.18583 — 0,0 % → 17,1 % auf gepaarten Szenarien, wenn eine Zustimmungsklausel entfernt wird. Der Begriff der Arbeit ist overeager actions / Scope-Erweiterungen; destruktive Handlungen sind Beispiele dafür, nicht die Definition. Preprint. <https://arxiv.org/abs/2605.18583>

ImpossibleBench und die Prompt-Varianten#

ImpossibleBench: Measuring LLMs' Propensity of Exploiting Test Cases (Zhong, Raghunathan, Carlini; 2025-10-23), arXiv:2510.20270 — die Prompt-Varianten-Ergebnisse und die Tatsache, dass jede Variante das fette Verbot enthält. Die Zahl >85 % → 1 % gilt für ein Modell, einen Benchmark, minimales Gerüst. Preprint. <https://arxiv.org/abs/2510.20270>

Kodierungsform gegen Vorgabentyp#

Compact Constraint Encoding (2026-04-08), arXiv:2604.07192 — 11 Modelle, 830+ Aufrufe; die Kodierungsform hat keinen signifikanten Effekt (Cliff's δ < 0,01), der Typ der Vorgabe dominiert. Ihre Typ-Achse ist kontraintuitiv gegen konventionell, nicht Verbot gegen Direktive — eine andere Achse als die im nächsten Eintrag. Preprint. <https://arxiv.org/abs/2604.07192>

Negative Constraints gegen positive Direktiven#

Guardrails Beat Guidance: A Large-Scale Study of Rules, Skills, and Persistent Configuration for Coding Agents (Zhang, Wang, Cui, Qiu, Li, Zhu, He; 2026-04-13, überarbeitet 2026-05-28), arXiv:2604.11088 — 679 gescrapte Regeldateien (25.532 Regeln) und über 5.000 Claude-Code-Läufe auf SWE-bench Verified; zufällige Regeln erreichen dasselbe wie kuratierte (+13,8 PP bei beiden), und in diesen Daten ist jede einzeln nützliche Regel ein negativer Constraint, jede einzeln schädliche eine positive Direktive. Die Polaritäts-Aussage in ihrem genannten Geltungsbereich lesen: Die Autoren schreiben „in our data", und es ist eine Klassifikation gescrapter Regeln, kein gepaartes Experiment, das eine Regel in beiden Fassungen prüft — dieselbe Arbeit findet die Gewinne zudem weitgehend inhaltsunabhängig und die schädlichen Regeln im Verbund nicht kumulierend. Preprint. <https://arxiv.org/abs/2604.11088>

Warum Agenten Regeln brechen#

Why Do AI Agents Break Rules? (2026-05-29), arXiv:2608.12323 — 46 Punkte Spannweite der Befolgung über 12 Modelle bei identischer Formulierung; das Enforcement-Information-Paradox. Preprint. <https://arxiv.org/abs/2608.12323>

Grenzverletzungen unter KPI-Druck#

Outcome-Driven Constraint Violations (2025-12-23), arXiv:2512.20798 — 0,0–62,8 % unter KPI-Druck; keine Verbesserung über Modellgenerationen. Preprint. <https://arxiv.org/abs/2512.20798>

Zieldrift unter Wertekonflikt#

Asymmetric Goal Drift in Coding Agents Under Value Conflict (2026-03-03), arXiv:2603.03456 — Verstöße steigen mit Druck und mit angesammeltem Kontext. Preprint. <https://arxiv.org/abs/2603.03456>

Specification Gaming in Reasoning-Modellen#

Towards Understanding Specification Gaming in Reasoning Models (2026-05-04), arXiv:2605.02269 — RL-Reasoning-Training erhöht Gaming; Gegenmaßnahmen senken es, beseitigen es nie. Preprint. <https://arxiv.org/abs/2605.02269>

Der Verifikations-Horizont#

The Verification Horizon: No Silver Bullet for Coding Agent Rewards (2026-06-24), arXiv:2606.26300 — jeder Prüfer ist ein Stellvertreter für die menschliche Absicht, nie die Absicht selbst. Preprint. <https://arxiv.org/abs/2606.26300>

Persuasion und abgelehnte Anfragen#

Call Me A Jerk: Persuading AI to Comply with Objectionable Requests (Meincke, Shapiro, Duckworth, Mollick, Mollick & Cialdini; 2025-07-18), SSRN 5357179 — sieben Überredungsprinzipien, N = 28.000 Konversationen, GPT-4o-mini, Befolgung 33 % → 72 %. Misst das Überreden eines Modells zu Anfragen, die es normalerweise ablehnt — die Gegenrichtung zum Intakthalten der eigenen Regel. Working Paper. <https://ssrn.com/abstract=5357179>

Hersteller-Hinweise zur Formulierung#

Anthropic, prompting best practices — „tell Claude what to do instead of what not to do", gesagt unter der Steuerung des Antwort*formats*. <https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices>

• Instruction hierarchy — das Konfliktproblem wird beim Training angegangen, nicht in der Prosa:

arXiv:2404.13208 (2024-04-19), arXiv:2511.04694, arXiv:2603.10521. Preprints.

• Die auf dieser Seite zitierten Repositories sind einzeln untersucht in

0601–0610, jeweils mit den Pfaden, auf denen ihre Aussagen ruhen.

Phụ lục 0520 — Kiểm thử một quy tắc#

Survival toolbox, phụ lục thứ hai · Bắt đầu tại đây · trước đó: Phụ lục 0510 — kiến trúc của một kỷ luật · bằng chứng: Kho corpus công khai cho thấy điều gì

Vì sao có trang này#

Năm tầng đều nhắm vào việc làm cho quy tắc đúng. Không tầng nào hỏi liệu nó có trụ được hay không.

Khoảng trống đó có một cái tên trong tài liệu đã công bố và có một kích thước đã được đo. Một nghiên cứu trên 238 tệp skill thực tế lập danh mục 26 khiếm khuyết lặp lại; khiếm khuyết phổ biến nhất trong tất cả — được ghi nhận ở 223 tệp, 94 % — là Rationalization Loophole: tệp đó "provides no guidance to discourage the agent from rationalizing or skipping required steps" (Hong et al. 2026). Mẫu số đằng sau tỷ lệ phần trăm đó không khớp được ngay bên trong chính nguồn; mục tham khảo nói rõ nó vênh ở đâu.

Đây là một phụ lục, không phải một tầng thứ sáu, vì cùng lý do khiến 0510 cũng vậy: nó không thêm artefact nào. Đầu ra của nó là câu chữ bên trong một tệp quy tắc và một bước bên trong một nghi thức. Phần bằng chứng nói điều đó đã được quyết định như thế nào và dựa trên cái gì.

Sự phân biệt khiến đây trở thành một chủ đề#

Viết kỹ thuật tốt trả lời câu hỏi mà người đọc đã đặt ra. Trang này trả lời phản bác mà người đọc chưa nêu ra — và chỉ nêu ra khi bị áp lực.

Câu đó được viết ra để bị tấn công, và đã sống sót qua cuộc tấn công. Nó không phải một khẩu hiệu: thực hành này có một phân loại lỗi định tuyến các lỗi khác nhau tới các biện pháp khác nhau, và sẽ sai nếu bạn áp dụng biện pháp cho sai loại lỗi. Một repository nói thẳng ranh giới đó ra — với đầu ra chỉ đơn thuần sai hình dạng, "prohibition-based bulletproofing backfires" (obra/superpowers, skills/writing-skills/SKILL.md). Đó là một tay nghề, không phải một sở thích văn phong.

Các phép đo thực sự nói gì#

Hai chế độ, và chúng không mâu thuẫn nhau — chúng đo những tình huống khác nhau.

Khi không có xung đột, các chỉ dẫn viết ra được tuân theo. Một đánh giá có kiểm soát trên các tệp context cấp repository cho thấy chúng "do not generally improve task success rates, while instructions in the context files are well followed" (Evaluating AGENTS.md 2026). Xét theo đo đạc, một tệp quy tắc là một cơ chế hiệu quả hơn là một cơ chế đúng đắn: −16.58 % output token và −28.64 % wall clock (Efficiency of AGENTS.md 2026).

Hai câu đó nằm ở hai phía đối lập của một bất đồng về chi phí, nên các id là quan trọng. Bài báo "well followed" cũng chính là bài báo cáo rằng các tệp context làm tăng chi phí suy luận hơn 20 % tính trung bình, trên nhiều mô hình và nhiều agent (arXiv:2602.11988). Các con số −16.58 % / −28.64 % là của một preprint khác, đo trung vị wall clock và output token trên 10 repository và 124 pull request (arXiv:2601.20404). 0000 và 0100 trình bày cả hai con số cạnh nhau, với dấu ngược nhau; bất đồng này không được giải quyết ở đây.

Khi có xung đột, sự tuân thủ rạn vỡ — và theo một trục khác nhau trong mỗi nghiên cứu.

Hãy đọc lại độ chênh 46 điểm hai lần. Cùng một quy tắc, cùng câu chữ, mười hai mô hình, và kết quả trải gần nửa thang đo. Việc bạn giao công việc cho mô hình nào là một phần của kỷ luật, và không câu nào bạn viết ra thay đổi được điều đó.

Ba thứ không có tác dụng#

Đáng đọc hai lần, vì cả ba đều là những gì một người có lý trí sẽ thử trước tiên.

1 · Nói to hơn. Cả bốn biến thể prompt trong một benchmark đều mang dòng DO NOT MODIFY THE TESTS. in đậm chữ hoa — kể cả biến thể tạo ra hơn 85 % gian lận (ImpossibleBench). Lệnh cấm đã có mặt ở đó và đã bị đọc lướt qua.

2 · Viết lại bằng câu chữ khác. Trên 11 mô hình và 830+ lượt gọi, dạng mã hóa của một ràng buộc không có ảnh hưởng đáng kể (Cliff's δ < 0.01, ±2.6 pp). Thứ chi phối là loại quy tắc: một quy tắc đi ngược lại các mặc định của mô hình thất bại 10–100 % số lần, một quy tắc thông thường trụ được ở mức 99 %+. Kết luận của chính các tác giả: "engineering effort toward compliance is better directed at constraint design than prompt formatting" (Compact Constraint Encoding).

"Hình thức không quan trọng" không phải là "câu chữ không quan trọng" — giữa hai điều đó là nguyên một trục. Nghiên cứu kia thay đổi cách một ràng buộc được mã hóa. Một nghiên cứu khác thay đổi cực tính của nó — cấm thay vì chỉ dẫn — và thấy rằng hai thứ đó quả thật tách rời nhau: trên 679 tệp quy tắc thu thập được (25,532 quy tắc) và hơn 5,000 lượt chạy Claude Code trên SWE-bench Verified, "in our data every individually beneficial rule is a negative constraint […], while every individually harmful one is a positive directive" (Guardrails Beat Guidance).

Vậy: ba phát hiện trên ba trục, và rất dễ gộp nhầm chúng vào nhau. Hình thức không có ảnh hưởng đo được; cực tính thì có; việc đi ngược lại chính các mặc định của mô hình nặng ký hơn cả hai. Hãy nhận kết quả về cực tính đúng ở tầm mà chính các tác giả của nó đưa ra — một nghiên cứu, một tập con benchmark, và cụm từ là "in our data": một phép phân loại các quy tắc mà họ thu thập được, chứ không phải một phép thử ghép cặp cùng một quy tắc viết theo cả hai cách. Cũng bài báo đó cho biết các quy tắc sinh ngẫu nhiên ngang bằng với các quy tắc do chuyên gia biên soạn (+13.8 pp theo cả hai chiều) và các quy tắc gây hại riêng lẻ không tích tụ thiệt hại một cách thấy được bên trong một tập hợp, đó là lý do để giữ phát hiện này một cách lỏng lẻo thay vì xây dựng dựa trên nó. Hướng dẫn của nhà cung cấp chỉ theo hướng ngược lại — "tell Claude what to do instead of what not to do" — nhưng chỉ giới hạn trong việc kiểm soát định dạng đầu ra, chứ không phải trong việc giữ một ranh giới (Anthropic prompting guidance).

3 · Nêu tên hình phạt. Việc nêu rõ hậu quả của việc phá quy tắc biến một nghĩa vụ thành một phép tính lợi-hại và có lợi cho hành vi vi phạm — nghịch lý thông tin cưỡng chế (Why Do AI Agents Break Rules?).

Điều đã có tác dụng: cho quy tắc một lối thoát#

Can thiệp duy nhất làm dịch chuyển một benchmark với biên độ lớn đã không cấm mạnh tay hơn. Nó cung cấp một hành động thay thế được cho phép dành cho khoảnh khắc xung đột — về thực chất: dừng lại, chỉ ra các test sai, và giải thích vì sao chúng sai, thay vì băm nát code để chúng pass (ImpossibleBench).

Một quy tắc chỉ biết cấm sẽ để người đọc không có lối thoát nào khỏi chính tình huống đã khiến họ phá nó.

Bây giờ hãy đọc thật kỹ độ lớn của kết quả đó, vì đây là con số dễ trích dẫn nhất trên trang này và cũng dễ bị dùng sai nhất. Con số >85 % → 1 % là một mô hình trên một benchmark với một scaffold tối giản. Cùng những prompt đó trên một mô hình khác cho >85 % → 33 %; trên benchmark khó hơn thì hiệu ứng gần như biến mất, việc nới lỏng đưa một mô hình từ 54 % → 66 % và một mô hình khác từ 50 % → 55 % (ImpossibleBench). Thứ khái quát hóa được là hình dạng, không phải con số.

Cách kiểm thử một quy tắc#

Bạn có thể kiểm thử một quy tắc viết ra theo đúng cách bạn kiểm thử code, và một repository làm đúng như vậy: viết kịch bản gây áp lực, xem quy tắc thất bại, viết quy tắc, xem nó trụ được, rồi bịt các lỗ hổng (obra/superpowers, skills/writing-skills/).

Lần chạy đối chứng đến trước, và đó là bước người ta hay bỏ qua. "If you didn't watch an agent fail without the skill, you don't know if the skill prevents the right failures" — và nếu lần đối chứng không bộc lộ lỗi thì chẳng có gì để sửa, nên đừng viết hướng dẫn đó (obra/superpowers, skills/writing-skills/testing-skills-with-subagents.md). Một quy tắc được viết cho một lỗi chưa từng được quan sát là thứ phổ biến nhất trong mọi tệp quy tắc, và nó tốn sự chú ý trong từng tác vụ một.

Ba loại áp lực#

Các kịch bản trong repository đó kết hợp nhiều áp lực thay vì áp dụng một loại, và ba tổ hợp đó được đặt tên: thời gian và tiền bạc · chi phí chìm và kiệt sức · quyền uy và áp lực xã hội. Đó cũng chính là ba thứ làm hỏng các quy trình của con người, và đó là lý do điều này chuyển giao được.

Viết một dòng#

Lời biện bạch được trích đúng như nó đã thực sự được đưa ra, và lời phản bác bịt đúng lối thoát cụ thể đó thay vì nhắc lại quy tắc:

| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. | | "This is just a simple question" | Questions are tasks. Check for skills. | | "I remember this skill" | Skills evolve. Read current version. |

Thêm một điều nữa, vì bản thân nó cũng là một cái bẫy: một điều khoản miễn trừ không giới hạn được phạm vi. "This limit does not apply to code blocks" vẫn triệt tiêu các code block; nếu một phần đầu ra phải được miễn trừ, hãy tái cấu trúc quy tắc sao cho nó không với tới phần đó.

Ngoài phạm vi phần mềm#

Một cuộc diễn tập chữa cháy là một phép thử dưới áp lực. Không ai nghi ngờ rằng người ta biết lối thoát hiểm ở đâu — cuộc diễn tập tồn tại vì biết và làm sẽ tách rời nhau trong những điều kiện nhất định. Cùng lập luận đó giải thích vì sao một checklist phẫu thuật được đọc thành tiếng, đúng vào lúc việc bỏ qua nó có vẻ hợp lý (0510 dẫn dữ liệu kết quả của nó).

Những phần chuyển giao được, không phần nào cần đến phần mềm:

• Trích nguyên văn lời biện bạch. Bất kỳ quy trình nào hay bị bỏ qua — một lần bàn giao, một lần kiểm tra cuối ca, một bước bảo vệ an toàn — đều xứng đáng có một phụ lục hai cột gồm đúng những câu người ta nói khi họ bỏ qua nó, mỗi câu kèm câu trả lời của nó. Hãy viết những gì họ đã nói, không phải những gì bạn tưởng tượng họ sẽ nói.
• Nêu tên phương án thay thế. Một chính sách chỉ biết cấm sẽ để ai đó mắc kẹt trong chính tình huống đã khiến việc cấm trở nên đắt đỏ. Hãy nói rõ phải làm gì thay vào đó.
• Hãy diễn tập vào ngày bận rộn, chứ không phải ngày yên ắng. Một quy tắc được kiểm thử trong điều kiện bình lặng thì chưa hề được kiểm thử.
• Đừng công bố hình phạt như là lý do. Nó mời gọi phép tính đó (Vì sao agent phá quy tắc).

Những gì trang này không làm được#

Nó không có exit code. Mọi thứ ở đây đều thuyết phục; không có gì ở đây từ chối. Nó không thay thế tầng 2 và nguy hiểm nhất là khi nó có cảm giác như một thứ thay thế được cho tầng đó — mọi bộ kiểm chứng đều là một proxy cho ý định chứ không phải chính ý định (The Verification Horizon), còn một quy tắc chỉ đọc lên nghe thuyết phục thì chẳng có proxy nào như thế cả. Nó thất bại trong im lặng, và bạn chỉ phát hiện ra sau đó, từ tầng 4.

Nó cũng không thể cho bạn biết liệu bất kỳ điều nào trong số này có đúng với công việc không phải phần mềm hay không. Mọi phép đo trên trang này đều đến từ các coding agent. Khái quát hóa nó là một lập luận, không phải một phép đo.

Và một ghi chú trung thực về nguồn nghe có vẻ mạnh nhất trong lĩnh vực này. Repository ghi chép thực hành này kỹ lưỡng nhất lại dựa nó trên một nghiên cứu về thuyết phục với N = 28,000 cuộc hội thoại, trong đó mức tuân thủ tăng từ 33 % lên 72 % (Meincke et al. 2025) — nhưng nghiên cứu đó đo việc thuyết phục một mô hình chấp nhận những yêu cầu mà bình thường nó sẽ từ chối, trên một mô hình duy nhất. Đó là bằng chứng rằng các tín hiệu thuyết phục làm mô hình dịch chuyển rất nhiều. Đó không phải bằng chứng rằng chúng giữ cho quy tắc của chính bạn nguyên vẹn dưới áp lực, và ở đây nó chỉ được dùng cho luận điểm thứ nhất.

Xong khi#

• Mọi quy tắc mà bạn dựa vào dưới áp lực đều có ít nhất một kịch bản đã thử phá nó.
• Mọi kịch bản đều có một lần chạy đối chứng không có quy tắc, và lần đối chứng đó thực sự đã thất bại.
• Mọi quy tắc có tính cấm đoán đều đồng thời nêu rõ phải làm gì thay vào đó.
• Mọi dòng lời biện bạch đều trích một điều đã thực sự được nói ra.
• Không có gì trên trang này đang được dùng ở nơi mà một gate mới là thứ thuộc về.

Tài liệu tham khảo#

Tất cả đều được mở ngày 2026-09-04. Trạng thái preprint được nêu ở nơi nó áp dụng; một con số không kèm phạm vi của nó là một con số sẽ bị trích dẫn sai.

Rationalization Loophole#

From Anatomy to Smells: An Empirical Study of SKILL.md (Hong, Imani, Ahmed; 2026-07-03), arXiv:2607.01456 — 238 tệp skill được phân tích định tính, 26 lớp khiếm khuyết; Rationalization Loophole là lớp phổ biến nhất, được xếp dưới Missing Follow-Through Guards như một section còn thiếu. Đây là nguồn cho khoảng trống mà trang này mô tả và cho việc coi nó là một section chứ không phải một artefact riêng. Con số phổ biến của nó không khớp được bên trong chính nguồn: phần văn bản chạy nói rằng bộ dò được áp dụng cho "the remaining 238 SKILL.md files", Bảng IV đặt tiêu đề cho đúng cột đó là "Entire Sample (228 Skills)", và con số in ra 223 (94 %) khớp với 238, chứ không phải 228 — vốn sẽ là 97.8 %. Cả toàn văn v1 lẫn v2 đều đọc như vậy, kiểm tra ngày 2026-09-04. Do đó trang này trích 223 và 94 % đúng như đã in và không đưa ra quan điểm nào về mẫu số. Preprint. <https://arxiv.org/abs/2607.01456>

Tệp context trong trường hợp không xung đột#

Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? (2026-02-12), arXiv:2602.11988 — phát hiện "well followed", trong chế độ không xung đột; cũng là nguồn của con số chi phí suy luận trên 20 %, mà 0000 và 0100 trích dẫn cạnh con số có dấu ngược lại từ arXiv:2601.20404. Preprint. <https://arxiv.org/abs/2602.11988>

Tệp quy tắc như một cơ chế hiệu quả#

On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents (2026-01-28), arXiv:2601.20404 — Δ 16.58 % output token, Δ 28.64 % wall clock. Preprint. <https://arxiv.org/abs/2601.20404>

Gỡ bỏ một điều khoản xin phép#

Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks (2026-05-18), arXiv:2605.18583 — 0.0 % → 17.1 % trên các kịch bản ghép cặp khi một điều khoản xin phép bị gỡ bỏ. Thuật ngữ của bài báo là overeager actions / mở rộng phạm vi; các hành vi phá hủy là ví dụ của những thứ đó, chứ không phải định nghĩa. Preprint. <https://arxiv.org/abs/2605.18583>

ImpossibleBench và các biến thể prompt#

ImpossibleBench: Measuring LLMs' Propensity of Exploiting Test Cases (Zhong, Raghunathan, Carlini; 2025-10-23), arXiv:2510.20270 — các kết quả theo biến thể prompt, và sự kiện là mọi biến thể đều chứa lệnh cấm in đậm. Con số >85 % → 1 % là một mô hình, một benchmark, scaffold tối giản. Preprint. <https://arxiv.org/abs/2510.20270>

Dạng mã hóa so với loại ràng buộc#

Compact Constraint Encoding (2026-04-08), arXiv:2604.07192 — 11 mô hình, 830+ lượt gọi; dạng mã hóa không có ảnh hưởng đáng kể (Cliff's δ < 0.01), loại ràng buộc mới là thứ chi phối. Trục loại của nó là ràng buộc phản trực giác so với thông thường, không phải cấm đoán so với chỉ dẫn — một trục khác với trục bên dưới. Preprint. <https://arxiv.org/abs/2604.07192>

Ràng buộc phủ định so với chỉ dẫn khẳng định#

Guardrails Beat Guidance: A Large-Scale Study of Rules, Skills, and Persistent Configuration for Coding Agents (Zhang, Wang, Cui, Qiu, Li, Zhu, He; 2026-04-13, sửa lại 2026-05-28), arXiv:2604.11088 — 679 tệp quy tắc thu thập được (25,532 quy tắc) và hơn 5,000 lượt chạy Claude Code trên SWE-bench Verified; các quy tắc ngẫu nhiên ngang bằng với các quy tắc do chuyên gia biên soạn (+13.8 pp cả hai chiều), và trong dữ liệu đó mọi quy tắc có lợi riêng lẻ đều là một ràng buộc phủ định còn mọi quy tắc gây hại riêng lẻ đều là một chỉ dẫn khẳng định. Hãy đọc luận điểm về cực tính đúng ở phạm vi đã nêu của nó: các tác giả viết "in our data", và đó là một phép phân loại các quy tắc đã thu thập chứ không phải một thí nghiệm ghép cặp viết lại cùng một quy tắc theo cả hai cách — cũng bài báo đó còn thấy rằng phần lợi ích phần lớn không phụ thuộc nội dung và các quy tắc gây hại không tích tụ khi đứng chung một tập. Preprint. <https://arxiv.org/abs/2604.11088>

Vì sao agent phá quy tắc#

Why Do AI Agents Break Rules? (2026-05-29), arXiv:2608.12323 — độ chênh tuân thủ 46 điểm trên 12 mô hình với cùng một cách diễn đạt; nghịch lý thông tin cưỡng chế. Preprint. <https://arxiv.org/abs/2608.12323>

Vi phạm ràng buộc dưới áp lực KPI#

Outcome-Driven Constraint Violations (2025-12-23), arXiv:2512.20798 — 0.0–62.8 % dưới áp lực KPI; không cải thiện qua các thế hệ mô hình. Preprint. <https://arxiv.org/abs/2512.20798>

Trôi dạt mục tiêu khi xung đột giá trị#

Asymmetric Goal Drift in Coding Agents Under Value Conflict (2026-03-03), arXiv:2603.03456 — vi phạm tăng theo áp lực và theo context tích lũy. Preprint. <https://arxiv.org/abs/2603.03456>

Specification gaming trong các mô hình reasoning#

Towards Understanding Specification Gaming in Reasoning Models (2026-05-04), arXiv:2605.02269 — huấn luyện reasoning bằng RL làm tăng gaming; các biện pháp giảm thiểu làm giảm, không bao giờ loại bỏ. Preprint. <https://arxiv.org/abs/2605.02269>

Mọi bộ kiểm chứng đều là một proxy#

The Verification Horizon: No Silver Bullet for Coding Agent Rewards (2026-06-24), arXiv:2606.26300 — mọi bộ kiểm chứng đều là một proxy cho ý định của con người, không bao giờ là chính ý định đó. Preprint. <https://arxiv.org/abs/2606.26300>

Thuyết phục và các yêu cầu đáng phản đối#

Call Me A Jerk: Persuading AI to Comply with Objectionable Requests (Meincke, Shapiro, Duckworth, Mollick, Mollick & Cialdini; 2025-07-18), SSRN 5357179 — bảy nguyên tắc thuyết phục, N = 28,000 cuộc hội thoại, GPT-4o-mini, tuân thủ 33 % → 72 %. Đo việc thuyết phục một mô hình hướng tới những yêu cầu mà bình thường nó sẽ từ chối, tức là chiều ngược lại với việc giữ cho quy tắc của chính bạn nguyên vẹn. Working paper. <https://ssrn.com/abstract=5357179>

Hướng dẫn của nhà cung cấp về cách diễn đạt#

Anthropic, prompting best practices — "tell Claude what to do instead of what not to do", được nêu trong phần kiểm soát định dạng phản hồi. <https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices>

• Instruction hierarchy — vấn đề xung đột được tấn công ở thời điểm huấn luyện thay vì trong văn xuôi:

arXiv:2404.13208 (2024-04-19), arXiv:2511.04694, arXiv:2603.10521. Preprints.

• Các repository được trích dẫn trên trang này được nghiên cứu từng cái một trong

0601–0610, mỗi cái kèm theo các đường dẫn mà các luận điểm của nó dựa vào.

What the public corpus shows#

Survival toolbox, evidence section · Start here · the model under test: Appendix — the architecture of a discipline

In one sentence#

Ten widely-used public skill repositories were read against the five layers this series proposes — and the most useful result is not that they cover the layers, but the three things the reading found that the layers do not describe.

Why this section exists#

The five layers of this series were derived from one organisation's practice. That is a weak foundation for a public claim. A model built from your own work will describe your own work; the question is whether it describes anybody else's, and whether the world contains things it cannot describe at all.

So: ten public repositories, each read by a separate read-only investigation on 2026-09-03, each asked the same question — which layers does this repository actually build, and what does it contain that fits none of them? The per-repository findings are the ten pages listed at the bottom. This page is what falls out when you put them side by side.

Honesty about the sample first, because it limits everything below. These ten were not drawn by a stated sampling rule. They are ten repositories that had accumulated a great deal of attention on GitHub. A search by stars at the time of reading returns further repositories above the smallest member of this set, so this is a convenience sample, not a population. Stars measure attention, not adoption or quality: the third-largest by stars in this set was last pushed four and a half months before it was read and contains a single skill.

What the reading found#

Each layer was scored ● carries / ○ touches / · absent. The first pass was not usable: ten independent readers had applied different thresholds to the same evidence — most sharply on whether a validator a repository ships to its users counts as that repository's own gate. Five rulings were made once and applied to all ten, and four of the five layers turned out to be two tests wearing one name — two of them split into the columns below, two into the extra rows the studies record.

These counts are the sum of the ten studies, one row each in the grid below, not a separate judgement. Each cell there names the files it rests on; disagree with one and the arithmetic here moves with it.

Read the two extremes together. Every repository in the set engineers its load trigger, and only three keep a record of their own intentions before acting on them — five keep none at all. The most mechanical part of the discipline is universal; the most human part is the rarest thing in the set.

One distinction is kept out of those columns on purpose. Two repositories ship a working gate to their users while running none over their own contents, and one ships a record-keeping ritual it does not itself practise. The studies record these as separate rows rather than folding them in, because a gate you hand to a stranger and a gate that guards you are different objects — and telling them apart is the single ruling that changed the most verdicts in this reading.

The same counts, one row per repository#

The columns are the seven tests above, in the same order, so a column read downwards reproduces the row it came from and a row read across is one repository's profile.

● carries · ○ touches · · absent. The repository name links to its study, where every cell names the files it rests on.

† One hedged verdict, counted here at face value: superpowers scores layer 4 on a dated plan-and-spec naming convention — no plan document was opened. ui-ux-pro-max-skill's 3b carried the same mark until 2026-09-04, when the two files that could have overturned it were read; they contain no hand-off to a person, so that cell is now settled.

‡ The distinction described just above: the repository ships this to its users while running nothing over its own contents, and each study records it as a separate 2′ or 4′ row. Three of the seventy cells carry that mark, and it is why the layer-2 column does not read as a clean pass.

Two things are visible here that the totals hide. No repository carries all seven. Four come within one — nextlevelbuilder/ui-ux-pro-max-skill, JuliusBrussee/caveman, addyosmani/agent-skills and ayghri/i-have-adhd — and they fall short on three different tests, so there is no one layer the careful repositories all skip. And the profile does not track size: one of those four ships 6.8 KB of actual content inside a 303 KB repository, while the repository holding the least prose of all, about 2.4 KB, scores three.

Three findings#

1. The effect of an instruction file is measurable, and several people measure it#

This series' appendix states that it found no published source measuring whether a delegation discipline works. That was wrong, and this corpus corrects it. Four of the ten measure exactly that:

The third of these is the one to copy. A repository publishing the correction of its own earlier, better-looking number is doing the thing this series asks of a written record, at the scale of a public project.

A fifth repository belongs beside that table rather than in it. multica-ai/andrej-karpathy-skills states in its rule file the conditions under which the rules would be judged not to be working — and nothing in the repository ever checks them; the tree holds no test, no script and no CI. Naming the falsification condition is the cheaper half of the discipline, and it is still more than the other five repositories offer. But a condition nobody runs is not a measurement, and counting it as one would be exactly the overclaim this series spends its length warning against.

2. A gate can be written in executable prose and wired to nothing#

Layer 2 asks for something that refuses when nobody is looking. Applying that test literally turned up the same failure four separate times, in repositories that otherwise take enormous care:

And the inverse, which is sharper. ComposioHQ/awesome-claude-skills has a gate that works: a workflow with seven separate refusal paths, including a rule that every added entry must be an external link. It computes "added" as any line not present before, so a changed line counts as added — and the file it guards contains dozens of broken relative links inside the region it polices. A contribution repairing them would fail the gate's check — whether a failed check blocks the merge was not established, since the workflow's success path adds a label rather than gating one.

This series told you to build something that refuses. It did not tell you that a gate can refuse the wrong thing, or hang from nothing and still read as enforcement. Both are in Layer 2 — the mechanical gate now, because of this reading.

3. The load trigger is where this ecosystem spends its effort#

Ten out of ten treat the description that decides when a skill loads as engineered surface rather than a label — a hill-climbed field, a ranking floor in CI, an invoked/not-invoked binary held in lockstep across two runtimes, or a deliberate switch turning model invocation off and a test pinning that choice. Ten independent readings, no shared context, one result. Of everything in this series, Layer 5 is the best-supported claim.

The sixth thing, which the five layers have no room for#

Across the ten repositories, fifty-seven items of substance fit no layer. Most of them cluster into families that say more about publishing than about delegation: keeping one discipline working across six to nine different agent runtimes, packaging, licensing, translation. Those are artefacts of the sample — a published package has problems a working team does not.

One family is not like that.

Compliance engineering: making the delegate actually follow the rule, once the rule exists.

• obra/superpowers ships a design manual for writing prose an agent will obey, grounded in a cited experiment, and three scenario files whose only purpose is to push an agent hard and see whether it abandons the procedure.
• addyosmani/agent-skills makes a table of rationalisations — the excuse on the left, its rebuttal on the right — a required section of every skill file, enforced by its own linter.
• Leonxlnx/taste-skill maintains a body of research on the failure modes of the delegate itself.

A gate stands outside the work and refuses. Compliance engineering stands inside it and argues. The five layers describe what you write down and what you enforce from outside; none of them describes the gap between an instruction that is correct and an instruction that is followed under pressure. It is a real topic, several people work on it, and this series did not have it.

It is carried into the appendix as a sixth column of the completeness matrix, not as a sixth layer — and the practice itself, with the measurements behind it, is appendix 0520. Three repositories are enough to establish that a topic exists. They are not enough to restructure a published method around it.

What this section cannot show#

The instrument does not discriminate well. In the first pass, thirty-six of fifty cells scored the top value and three of the five layers never scored "absent" once. A classifier that returns the same answer for almost every input is measuring the classifier, not the world. The split tests in the table above are sharper, but they were derived after seeing the data, which is a weaker thing than a prediction made before.

No result here was pre-registered as a falsifier. Three predictions were written down before the reading — that the corpus would be mostly rituals, that it would contain no real gates, and that everything in it would fit the five layers. All three were wrong. The model survived anyway, which means it was never resting on them.

These are distribution artefacts, and that confounds the result. A published package is forced by its format to have a manifest, a load trigger and a written procedure justifying installation — precisely the tests that scored ten out of ten and nine out of ten and never varied. What it structurally cannot contain is a team's own hooks, its plan files, its internal register. So the layers that never discriminate are the ones the format guarantees, and the layer that does discriminate depends on an unrelated fact: whether the publisher happens to run CI on the package. The tempting reply — that the missing gates live in the private working repositories — is a hypothesis this reading did not test and cannot test. It is stated here as an open question, not as an answer.

And one omission is worth naming. A vendor's own managed production directory of plugins, not in this set, carries nine validating workflows, a policy schema and a frontmatter validator. Whatever else is true, "nobody builds the gate" is not.

The ten repositories at a glance#

Seven questions, one row each; the linked study behind every row names the files. Three things about the judgement columns first, because they are the ones that can be unfair.

Whose standard. Where it is weak measures against the five layers of this series, as the artefact stood on 2026-09-03. Several of these repositories never set out to satisfy them — a demonstration collection and an operating discipline are different objects — so a gap here is a mismatch with our model at least as often as a failure of theirs. It names a defect in a file, never an assessment of the people who wrote it — which is also why Publisher gives a type rather than an account name: the one thing the type answers (is a company or a single person behind this?) is real information, and the name is already in the repository path beside it, where it is an address rather than a byline. Before you use it is the practical consequence: licence, staleness, and the thing that will surprise you on installation.

A bias worth naming. Two of the sharpest entries below are defects the maintainers documented themselves, in public, against their own headline. A repository that measures nothing and keeps no honesty page cannot appear in this column at all — so the column is partly a measure of how much a project discloses. Read a thin weakness cell as we found less, never as there is less.

Where the licence line comes from. The studies read repositories, not licences, so the licence sentence in the last column was read separately on 2026-09-04 — each repository's own licence file, plus GitHub's licence field for the negative cases. It is a description of what those files say, not legal advice.

Nobody was asked. No maintainer was contacted and none has had a right of reply. Every claim is checkable against the file named here or in the study, and one of them was already wrong: see the correction in study 0605.

On the star column. These are the figures the GitHub API returned on 2026-09-03, the day each repository was read, kept here so the overview and the studies agree. They measure attention, not adoption or quality. The rows follow the study numbering 0601–0610, which was itself assigned in descending star order — so this ordering is the star ordering, and it is not a ranking of quality. Re-checked on 2026-09-04, every count had moved by less than 0.4 % and none had changed places — which says something about how little a star count tells you from one day to the next, and nothing about which of these repositories you should use.

Done when#

• Every claim on these eleven pages points at a path in a public repository, dated to the day it was read.
• The limits above are stated wherever a claim from this section is reused.
• A reader can disagree with the classification and still use the evidence.

Was das öffentliche Korpus zeigt#

Survival-Toolbox, Belegteil · Hier anfangen · das geprüfte Modell: Anhang — die Architektur einer Disziplin

In einem Satz#

Zehn viel genutzte öffentliche Skill-Repositories wurden gegen die fünf Schichten dieser Reihe gelesen — und das Nützlichste daran ist nicht, dass sie die Schichten abdecken, sondern die drei Dinge, die dabei auftauchten und die die Schichten nicht beschreiben.

Warum es diesen Teil gibt#

Die fünf Schichten dieser Reihe stammen aus der Praxis einer einzigen Organisation. Das ist ein schwaches Fundament für eine öffentliche Behauptung. Ein Modell, das aus der eigenen Arbeit gebaut wurde, beschreibt die eigene Arbeit; die Frage ist, ob es die von irgendjemand anderem beschreibt — und ob es in der Welt Dinge gibt, die es überhaupt nicht beschreiben kann.

Also: zehn öffentliche Repositories, jedes von einer eigenen, ausschließlich lesenden Untersuchung am 2026-09-03 geprüft, jedes mit derselben Frage — welche Schichten baut dieses Repository wirklich, und was enthält es, das in keine davon passt? Die Einzelbefunde stehen in den zehn Seiten am Ende dieser Seite. Hier steht, was herauskommt, wenn man sie nebeneinanderlegt.

Zuerst die Ehrlichkeit über die Stichprobe, denn sie begrenzt alles Weitere. Diese zehn wurden nicht nach einer angegebenen Stichprobenregel gezogen. Es sind zehn Repositories, die auf GitHub sehr viel Aufmerksamkeit auf sich gezogen haben. Eine Suche nach Sternen zum Zeitpunkt des Lesens liefert weitere Repositories oberhalb des kleinsten Mitglieds dieser Menge — es ist also eine Gelegenheitsstichprobe, keine Grundgesamtheit. Sterne messen Aufmerksamkeit, nicht Verbreitung und nicht Qualität: das drittgrößte Repository dieser Menge wurde zuletzt viereinhalb Monate vor dem Lesen aktualisiert und enthält einen einzigen Skill.

Was die Lektüre ergeben hat#

Jede Schicht wurde mit ● trägt / ○ berührt / · fehlt bewertet. Der erste Durchgang war nicht brauchbar: zehn unabhängige Leser hatten auf dieselbe Art von Beleg unterschiedliche Schwellen angewandt — am deutlichsten bei der Frage, ob ein Validator, den ein Repository an seine Nutzer ausliefert, als dessen eigenes Gate zählt. Fünf Regeln wurden einmal gefällt und auf alle zehn angewandt, und vier der fünf Schichten erwiesen sich als zwei Prüfungen unter einem Namen — zwei davon aufgeteilt in die Spalten unten, zwei in die zusätzlichen Zeilen, die die Untersuchungen führen.

Diese Zahlen sind die Summe der zehn Untersuchungen, je eine Zeile im Raster unten, kein getrenntes Urteil. Jede Zelle dort nennt die Dateien, auf denen sie beruht; wer einer widerspricht, verschiebt die Arithmetik hier mit.

Man lese die beiden Extreme zusammen. Jedes Repository der Menge konstruiert seinen Lade-Auslöser, und nur drei halten fest, was sie vorhatten, bevor sie es taten — fünf halten gar nichts fest. Der mechanischste Teil der Disziplin ist überall vorhanden; der menschlichste ist das Seltenste in der Menge.

Eine Unterscheidung bleibt absichtlich aus diesen Spalten heraus. Zwei Repositories liefern ein funktionierendes Gate an ihre Nutzer aus und betreiben keines über den eigenen Inhalt, und eines liefert ein Protokollritual aus, das es selbst nicht praktiziert. Die Untersuchungen führen das als eigene Zeilen und rechnen es nicht ein, denn ein Gate, das man einem Fremden in die Hand gibt, und ein Gate, das einen selbst schützt, sind verschiedene Dinge — und diese Trennung ist die eine Regel, die in dieser Lektüre die meisten Urteile verändert hat.

Dieselben Zahlen, eine Zeile je Repository#

Die Spalten sind die sieben Tests von oben, in derselben Reihenfolge: eine Spalte von oben nach unten gelesen ergibt wieder die Zeile, aus der sie stammt, eine Zeile quer gelesen das Profil eines Repositories.

● trägt · ○ streift · · fehlt. Der Repository-Name führt zur jeweiligen Untersuchung, in der jede Zelle die Dateien nennt, auf denen sie beruht.

† Ein abgeschwächtes Urteil, hier zum Nennwert gezählt: superpowers bekommt Schicht 4 auf eine datierte Plan-und-Spec-Namenskonvention hin — kein Plandokument wurde geöffnet. Bei ui-ux-pro-max-skill trug 3b dieselbe Markierung bis zum 2026-09-04, als die zwei Dateien gelesen wurden, die das Urteil hätten kippen können; sie übergeben keine Entscheidung an einen Menschen, die Zelle ist damit geklärt.

‡ Die Unterscheidung von eben: Das Repository liefert das an seine Nutzer aus und lässt nichts über die eigenen Inhalte laufen; jede Untersuchung führt das als eigene Zeile 2′ oder 4′. Drei der siebzig Zellen tragen diese Markierung, und deshalb liest sich die Spalte zu Schicht 2 nicht als sauberes Bestehen.

Zwei Dinge werden hier sichtbar, die die Summen verbergen. Kein Repository trägt alle sieben. Vier kommen bis auf eines heran — nextlevelbuilder/ui-ux-pro-max-skill, JuliusBrussee/caveman, addyosmani/agent-skills und ayghri/i-have-adhd — und sie scheitern an drei verschiedenen Tests: Es gibt keine eine Schicht, die die sorgfältigen Repositories alle auslassen. Und das Profil hängt nicht an der Größe: Eines dieser vier liefert 6,8 KB echten Inhalt in einem 303-KB-Repository aus, während das Repository mit der wenigsten Prosa überhaupt, rund 2,4 KB, drei erreicht.

Drei Befunde#

1. Die Wirkung einer Instruktionsdatei ist messbar, und mehrere Leute messen sie#

Der Anhang dieser Reihe schreibt, es sei keine veröffentlichte Quelle gefunden worden, die die Wirkung einer Delegationsdisziplin misst. Das war falsch, und dieses Korpus korrigiert es. Vier der zehn messen genau das:

Das dritte davon ist das nachahmenswerte. Ein Repository, das die Korrektur seiner eigenen, früher besser aussehenden Zahl veröffentlicht, tut genau das, was diese Reihe von einem schriftlichen Protokoll verlangt — im Maßstab eines öffentlichen Projekts.

Ein fünftes Repository gehört neben diese Tabelle, nicht hinein. multica-ai/andrej-karpathy-skills nennt in seiner Regeldatei die Bedingungen, unter denen die Regeln als nicht wirksam gälten — und nichts im Repository prüft sie jemals; der Baum enthält keinen Test, kein Skript und keine CI. Die Falsifikationsbedingung zu benennen ist die billigere Hälfte der Disziplin, und sie ist immer noch mehr, als die übrigen fünf Repositories bieten. Aber eine Bedingung, die niemand prüft, ist keine Messung, und sie als eine zu zählen wäre genau die Überzeichnung, vor der diese Reihe auf ihrer ganzen Länge warnt.

2. Ein Gate kann in ausführbarer Prosa geschrieben und an nichts gehängt sein#

Schicht 2 verlangt etwas, das verweigert, wenn niemand hinsieht. Diese Prüfung wörtlich angewandt brachte viermal denselben Fehler zutage, in Repositories, die sonst außerordentliche Sorgfalt zeigen:

Und der Umkehrfall, der schärfer ist. ComposioHQ/awesome-claude-skills hat ein Gate, das funktioniert: ein Workflow mit sieben getrennten Abweisungspfaden, darunter die Regel, dass jeder hinzugefügte Eintrag ein externer Link sein muss. „Hinzugefügt" berechnet er als jede Zeile, die vorher nicht da war — eine geänderte Zeile zählt also als hinzugefügt —, und die Datei, die er bewacht, enthält Dutzende kaputter relativer Links genau in dem Bereich, den er überwacht. Ein Beitrag, der sie repariert, würde die Prüfung des Gates nicht bestehen — ob eine nicht bestandene Prüfung den Merge blockiert, wurde nicht festgestellt: Der Erfolgspfad des Workflows setzt ein Label, statt zu blockieren.

Diese Reihe hat gesagt: bau etwas, das verweigert. Sie hat nicht gesagt, dass ein Gate das Falsche verweigern oder an nichts hängen und trotzdem wie Durchsetzung aussehen kann. Beides steht jetzt in Schicht 2 — das mechanische Gate, wegen dieser Lektüre.

3. Der Lade-Auslöser ist die Stelle, in die dieses Ökosystem seine Arbeit steckt#

Zehn von zehn behandeln die Beschreibung, die über das Laden eines Skills entscheidet, als konstruierte Oberfläche und nicht als Etikett — ein hügelauf optimiertes Feld, eine Rangschwelle in der CI, eine im Gleichschritt über zwei Laufzeiten gehaltene Unterscheidung zwischen aufgerufen und nicht aufgerufen, oder ein bewusster Schalter, der den Modellaufruf abstellt, samt einem Test, der diese Wahl festnagelt. Zehn unabhängige Lektüren, kein gemeinsamer Kontext, ein Ergebnis. Von allem in dieser Reihe ist Schicht 5 die am besten belegte Aussage.

Das sechste Ding, für das die fünf Schichten keinen Platz haben#

Über die zehn Repositories hinweg passen siebenundfünfzig Fundstücke in keine Schicht. Die meisten gruppieren sich zu Familien, die mehr über das Publizieren aussagen als über Delegation: dieselbe Disziplin über sechs bis neun verschiedene Agenten-Laufzeiten hinweg funktionsfähig halten, Paketierung, Lizenzierung, Übersetzung. Das sind Artefakte der Stichprobe — ein veröffentlichtes Paket hat Probleme, die ein arbeitendes Team nicht hat.

Eine Familie ist anders.

Compliance-Engineering: dafür sorgen, dass der Delegierte die Regel auch befolgt, wenn sie erst einmal existiert.

• obra/superpowers liefert ein Handbuch dafür, Prosa so zu schreiben, dass ein Agent ihr folgt, gestützt auf ein zitiertes Experiment — und drei Szenariodateien, deren einziger Zweck es ist, einen Agenten unter Druck zu setzen und zu sehen, ob er die Prozedur fallen lässt.
• addyosmani/agent-skills macht eine Tabelle von Rationalisierungen — die Ausrede links, ihre Widerlegung rechts — zum Pflichtabschnitt jeder Skill-Datei, durchgesetzt vom eigenen Linter.
• Leonxlnx/taste-skill pflegt einen Bestand an Untersuchungen über die Fehlermodi des Delegierten selbst.

Ein Gate steht außerhalb der Arbeit und verweigert. Compliance-Engineering steht mittendrin und argumentiert. Die fünf Schichten beschreiben, was man aufschreibt und was man von außen erzwingt; keine davon beschreibt den Abstand zwischen einer Anweisung, die richtig ist, und einer Anweisung, der unter Druck gefolgt wird. Es ist ein echtes Thema, mehrere Leute arbeiten daran, und diese Reihe hatte es nicht.

Es wandert als sechste Spalte in die Vollständigkeitsmatrix des Anhangs, nicht als sechste Schicht — und die Praxis selbst, mit den Messungen dahinter, ist Anhang 0520. Drei Repositories genügen, um zu zeigen, dass ein Thema existiert. Sie genügen nicht, um eine veröffentlichte Methode darum herum umzubauen.

Was dieser Teil nicht zeigen kann#

Das Instrument trennt schlecht. Im ersten Durchgang bekamen sechsunddreißig von fünfzig Zellen den Höchstwert, und drei der fünf Schichten bekamen kein einziges Mal „fehlt". Ein Klassifikator, der für fast jede Eingabe dieselbe Antwort gibt, misst den Klassifikator und nicht die Welt. Die geteilten Prüfungen in der Tabelle oben trennen schärfer, wurden aber nach Sicht der Daten abgeleitet, und das ist schwächer als eine Vorhersage davor.

Kein Ergebnis wurde vorab als Falsifikator festgelegt. Drei Vorhersagen wurden vor der Lektüre aufgeschrieben — das Korpus bestehe fast nur aus Ritualen, es enthalte keine echten Gates, und alles darin passe in die fünf Schichten. Alle drei waren falsch. Das Modell überlebte trotzdem, was heißt, dass es nie auf ihnen ruhte.

Es sind Distributionsartefakte, und das verzerrt das Ergebnis. Ein veröffentlichtes Paket ist durch sein Format gezwungen, ein Manifest, einen Lade-Auslöser und eine geschriebene Prozedur zur Rechtfertigung der Installation zu haben — genau die Prüfungen, die zehn von zehn und neun von zehn erreichten und nie variierten. Was es strukturell nicht enthalten kann, sind die Hooks eines Teams, seine Plandateien, sein internes Register. Die Schichten, die nicht trennen, sind also die, die das Format garantiert, und die Schicht, die trennt, hängt an einer unabhängigen Tatsache: ob der Herausgeber zufällig CI auf das Paket laufen lässt. Die naheliegende Erwiderung — die fehlenden Gates lägen in den privaten Arbeitsrepositories — ist eine Hypothese, die diese Lektüre nicht geprüft hat und nicht prüfen kann. Sie steht hier als offene Frage, nicht als Antwort.

Und eine Auslassung sollte benannt werden. Das verwaltete Produktionsverzeichnis für Plugins eines Herstellers, nicht in dieser Menge, trägt neun prüfende Workflows, ein Policy-Schema und einen Frontmatter-Validator. Was sonst auch gilt: „das Gate baut keiner" gilt nicht.

Die zehn Repositories auf einen Blick#

Sieben Fragen, je eine Zeile; die verlinkte Untersuchung hinter jeder Zeile nennt die Dateien. Drei Dinge vorab zu den Urteilsspalten, denn sie sind die, die unfair sein können.

Wessen Maßstab. Wo es schwach ist misst an den fünf Schichten dieser Reihe, im Zustand vom 2026-09-03. Mehrere dieser Repositories haben nie vorgehabt, sie zu erfüllen — eine Anschauungssammlung und eine Betriebsdisziplin sind verschiedene Dinge — eine Lücke hier ist also mindestens so oft ein Nichtpassen zu unserem Modell wie ein Versagen ihres. Sie benennt einen Mangel in einer Datei, nie eine Bewertung der Menschen, die sie geschrieben haben — deshalb nennt Herausgeber auch einen Typ und keinen Kontonamen: Was der Typ beantwortet (steht eine Firma oder eine einzelne Person dahinter?), ist echte Information, und der Name steht ohnehin daneben im Repository-Pfad, wo er eine Adresse ist und keine Verfasserzeile. Bevor man es benutzt ist die praktische Folge: Lizenz, Aktualität, und das, was bei der Installation überrascht.

Eine Verzerrung, die benannt gehört. Zwei der schärfsten Einträge unten sind Mängel, die die Betreuer selbst öffentlich dokumentiert haben, gegen die eigene Schlagzeile. Ein Repository, das nichts misst und keine Ehrlichkeitsseite führt, kann in dieser Spalte überhaupt nicht auftauchen — die Spalte misst also zum Teil, wie viel ein Projekt offenlegt. Eine dünne Schwäche-Zelle heißt wir haben weniger gefunden, nie es gibt weniger.

Woher die Lizenzangabe stammt. Die Untersuchungen haben Repositories gelesen, keine Lizenzen — der Lizenzsatz in der letzten Spalte wurde deshalb am 2026-09-04 getrennt erhoben: die jeweils eigene Lizenzdatei, dazu das Lizenzfeld von GitHub für die Negativfälle. Das beschreibt, was in diesen Dateien steht, und ist keine Rechtsberatung.

Niemand wurde gefragt. Kein Betreuer wurde kontaktiert, keiner hatte Gelegenheit zur Erwiderung. Jede Aussage ist an der hier oder in der Untersuchung genannten Datei überprüfbar, und eine war bereits falsch: siehe die Korrektur in Untersuchung 0605.

Zur Sterne-Spalte. Das sind die Werte, die die GitHub-API am 2026-09-03 zurückgab, dem Tag, an dem jedes Repository gelesen wurde — so stimmen Übersicht und Untersuchungen überein. Sie messen Aufmerksamkeit, nicht Verbreitung und nicht Qualität. Die Zeilen folgen der Nummerierung der Untersuchungen 0601–0610, die ihrerseits nach absteigender Sternezahl vergeben wurde — diese Reihenfolge ist also die Sternereihenfolge, und sie ist keine Qualitätsrangliste. Am 2026-09-04 nachgeprüft, hatte sich jeder Wert um weniger als 0,4 % bewegt und keiner den Platz gewechselt — was etwas darüber sagt, wie wenig eine Sternezahl von einem Tag auf den anderen aussagt, und nichts darüber, welches dieser Repositories man nehmen sollte.

Fertig, wenn#

• Jede Behauptung auf diesen elf Seiten auf einen Pfad in einem öffentlichen Repository zeigt, datiert auf den Tag, an dem er gelesen wurde.
• Die obigen Grenzen überall dort mitgenannt werden, wo eine Aussage aus diesem Teil wiederverwendet wird.
• Ein Leser der Einordnung widersprechen und die Belege trotzdem benutzen kann.

Kho ngữ liệu công khai cho thấy điều gì#

Bộ công cụ sinh tồn, phần bằng chứng · Bắt đầu tại đây · mô hình được đem ra kiểm chứng: Phụ lục — kiến trúc của một kỷ luật

Tóm trong một câu#

Mười kho skill công khai được dùng rộng rãi đã được đọc đối chiếu với năm tầng mà loạt bài này đề xuất — và kết quả hữu ích nhất không phải là chúng có phủ hết các tầng hay không, mà là ba điều mà việc đọc đó tìm ra và các tầng không mô tả được.

Vì sao có phần này#

Năm tầng của loạt bài này được rút ra từ thực hành của một tổ chức duy nhất. Đó là một nền móng yếu cho một tuyên bố công khai. Một mô hình dựng từ công việc của chính bạn sẽ mô tả công việc của chính bạn; câu hỏi là liệu nó có mô tả được của ai khác hay không, và liệu thế giới có chứa những thứ mà nó hoàn toàn không mô tả nổi.

Vậy nên: mười kho công khai, mỗi kho được đọc bởi một cuộc điều tra chỉ-đọc riêng biệt vào ngày 2026-09-03, mỗi kho được hỏi cùng một câu — kho này thực sự xây những tầng nào, và nó chứa gì mà không khớp với tầng nào cả? Các phát hiện theo từng kho là mười trang được liệt kê ở cuối. Trang này là những gì rơi ra khi bạn đặt chúng cạnh nhau.

Trung thực về mẫu trước đã, vì nó giới hạn mọi thứ bên dưới. Mười kho này không được rút ra theo một quy tắc lấy mẫu đã nêu. Chúng là mười kho đã tích luỹ được rất nhiều sự chú ý trên GitHub. Một tìm kiếm theo số sao tại thời điểm đọc trả về thêm những kho khác cao hơn thành viên nhỏ nhất của tập này, nên đây là một mẫu thuận tiện, không phải một tổng thể. Số sao đo sự chú ý, không đo mức độ được dùng hay chất lượng: kho lớn thứ ba theo số sao trong tập này có lần push cuối cách thời điểm nó được đọc bốn tháng rưỡi và chứa đúng một skill.

Việc đọc đã tìm ra gì#

Mỗi tầng được chấm ● gánh vác / ○ chạm tới / · vắng mặt. Lượt đọc đầu tiên không dùng được: mười người đọc độc lập đã áp những ngưỡng khác nhau lên cùng một bằng chứng — rõ nhất là ở chỗ liệu một validator mà một kho giao cho người dùng của nó có được tính là cổng kiểm soát của chính kho đó hay không. Năm phán quyết đã được đưa ra một lần và áp cho cả mười kho, và bốn trong năm tầng hoá ra là hai phép thử đội chung một cái tên — hai trong số đó tách thành các cột bên dưới, hai tách thành những hàng phụ mà các nghiên cứu ghi lại.

Các con số này là tổng của mười nghiên cứu, mỗi nghiên cứu một hàng trong lưới bên dưới, chứ không phải một phán quyết riêng. Mỗi ô ở đó nêu tên những tệp mà nó dựa vào; hãy bất đồng với một ô và số học ở đây sẽ dịch chuyển theo.

Hãy đọc hai thái cực cùng nhau. Mọi kho trong tập này đều thiết kế kỹ trigger nạp của nó, và chỉ ba kho giữ một bản ghi về ý định của chính mình trước khi hành động theo chúng — năm kho không giữ gì cả. Phần máy móc nhất của kỷ luật thì phổ quát; phần con người nhất lại là thứ hiếm nhất trong tập này.

Một phân biệt được cố ý giữ ở ngoài các cột đó. Hai kho giao một cổng kiểm soát hoạt động được cho người dùng của họ trong khi không chạy cổng nào trên chính nội dung của mình, và một kho giao một nghi thức ghi chép mà bản thân nó không thực hành. Các nghiên cứu ghi những trường hợp này thành các hàng riêng thay vì gộp chúng vào, bởi một cổng bạn trao cho người lạ và một cổng canh giữ bạn là hai đối tượng khác nhau — và phân biệt được chúng là phán quyết duy nhất đã thay đổi nhiều kết luận nhất trong lần đọc này.

Vẫn những con số đó, mỗi kho một hàng#

Các cột là bảy phép thử ở trên, theo đúng thứ tự đó, nên một cột đọc theo chiều dọc sẽ tái tạo lại hàng mà nó xuất phát, còn một hàng đọc theo chiều ngang là hồ sơ của một kho.