Automatischer Push: 25 Datei(en) geändert
- .claude/agents/executer.md - .claude/agents/recherche.md - .claude/skills/anleitung-straffen/SKILL.md - .vault-tools/linkcheck/docs/plans/2026-09-29-waisen/00-uebersicht.md - .vault-tools/linkcheck/docs/plans/2026-09-29-waisen/task-01-zaehler.md - .vault-tools/linkcheck/docs/plans/2026-09-29-waisen/task-02-sitzungsstart.md - .vault-tools/linkcheck/docs/plans/2026-09-29-waisen/task-03-regeltexte.md - .vault-tools/linkcheck/docs/plans/2026-09-29-waisen/task-04-bestandsskript.md - .vault-tools/linkcheck/docs/plans/2026-09-29-waisen/task-05-bestandslauf.md - .vault-tools/workflow-pruefung/docs/plans/2026-09-29-quorum/00-uebersicht.md - .vault-tools/workflow-pruefung/docs/plans/2026-09-29-quorum/task-01-quorum-werkzeug.md - .vault-tools/workflow-pruefung/docs/plans/2026-09-29-quorum/task-02-quorum-workflow.md - … und 13 weitere Erzeugt vom PostToolUse-Hook .vault-tools/auto-push/auto_push.py. Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
Pascal MichelandClaude Opus 5 committed
1 parent
8e29a16e7b
commit
e8472409e9
25 files changed
+6403
-86
No files matched your search
@@ -1,11 +1,11 @@
|
||||
---
|
||||
type: resource
|
||||
status: reference
|
||||
status: pending-review
|
||||
title: Codedoku und Dateikopf
|
||||
summary: Wie Produktivdateien aussehen — Dateikopf mit genau drei Angaben, CHANGELOG statt Versionsnummern in der Datei, was aus dem Code verschwindet, was drinbleibt, und wohin die Codedoku gehört.
|
||||
tags: [regelwerk, codeworkflow, code-projekte, dokumentation]
|
||||
created: 2026-08-30
|
||||
updated: 2026-08-30
|
||||
updated: 2026-09-29
|
||||
---
|
||||
|
||||
# Codedoku und Dateikopf
|
||||
@@ -79,9 +79,16 @@ Faustregel: **was** und **wie** gehören in die Doku, **warum ausgerechnet so**
|
||||
|
||||
## Die Codedoku
|
||||
|
||||
Liegt im Projektordner unter `docs/code/`, eine Datei je Modul oder Skript, gleicher Name. Sie beantwortet vier Dinge: wofür das Ding da ist, wie der Ablauf von oben nach unten läuft, welche Annahmen es über seine Umgebung macht, und was beim Anfassen weh tut. Ton und Grenzen: [[AI/Regelwerk/schreibstil|schreibstil.md]].
|
||||
- Ort: Projektordner unter `docs/code/`, eine Datei je Modul oder Skript, gleicher Name.
|
||||
- Vier Überschriften, darunter Stichpunkte, keine Textblöcke:
|
||||
- **Wofür** — eine Zeile
|
||||
- **Ablauf** — nummerierte Liste von oben nach unten
|
||||
- **Annahmen** über die Umgebung
|
||||
- **Was beim Anfassen weh tut**
|
||||
- Form und Grenzen: [[AI/Regelwerk/schreibstil|schreibstil.md]].
|
||||
- `docs/plans/` bleibt für Umsetzungspläne, `books/` für Betriebs- und Kundendokumentation. Die Codedoku ist für den, der den Code ändert, nicht für den, der ihn benutzt.
|
||||
|
||||
`docs/plans/` bleibt wie gehabt für Umsetzungspläne. `books/` bleibt für Betriebs- und Kundendokumentation — die Codedoku ist für den, der den Code ändert, nicht für den, der ihn benutzt.
|
||||
**Code in Dokumenten ist etwas anderes als Produktivcode.** Codeblöcke in Anleitungen und Codedoku bekommen eine Kommentarzeile je Abschnitt, was er tut ([[AI/Regelwerk/schreibstil|schreibstil.md]], „Code in Dokumenten"). Die Regeln oben über Kommentare, die Code nacherzählen, gelten nur für Produktivdateien. Ein wörtlicher Auszug aus einer Produktivdatei bleibt mit seinen Kommentaren stehen; die erste Zeile kennzeichnet ihn als Auszug (`# Auszug aus <datei>`).
|
||||
|
||||
## Ausnahme: Prüfskripte
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ title: Codeworkflow
|
||||
summary: Arbeitsweise für Code-Projekte — Standardschleife, Planaufteilung je Task, Subagenten und ihre Modellstufen und Effort, Gegenprüfung, Lauf mit echten Daten, Aufgabenmanagement.
|
||||
tags: [regelwerk, codeworkflow, code-projekte]
|
||||
created: 2026-08-03
|
||||
updated: 2026-09-27
|
||||
updated: 2026-09-29
|
||||
---
|
||||
|
||||
# Codeworkflow
|
||||
@@ -132,7 +132,7 @@ Was echte Daten aufdecken und Fixtures nicht: verdrehte Vorzeichen, Skalierungsp
|
||||
|
||||
### Nur für Claude Fable 5.1
|
||||
|
||||
Läuft der Koordinator auf Fable 5.1, gelten in der Schleife zusätzlich die Punkte 3, 8, 10, 13 und 15 aus [[AI/Regelwerk/fable-5-1|fable-5-1.md]]: unabhängige Werkzeugaufrufe in einer Antwort bündeln, einen entschiedenen Schritt ausführen statt ankündigen, Änderungen und Tests auf den Auftrag beschränken (der Regressionsfall je Nachbesserung aus Schritt 5 bleibt Pflicht — er ist beauftragt, kein Zusatz), Edit vor Write, und während ein Executer läuft das erledigen, was nicht von seinem Ergebnis abhängt. Opus 5, Sonnet 5 und Haiku 4.5 entscheiden selbst, ob sie etwas davon übernehmen — die Rollentabelle ändert sich dadurch nicht.
|
||||
Läuft der Koordinator auf Fable 5.1, gelten in der Schleife zusätzlich die Punkte 3, 8, 10, 13 und 15 aus [[AI/Regelwerk/fable-5-1|fable-5-1.md]]: unabhängige Werkzeugaufrufe in einer Antwort bündeln, einen entschiedenen Schritt ausführen statt ankündigen, Änderungen und Tests auf den Auftrag beschränken (der Regressionsfall je Nachbesserung aus Schritt 5 bleibt Pflicht — er ist beauftragt, kein Zusatz), Edit vor Write, und während ein Executer läuft das erledigen, was nicht von seinem Ergebnis abhängt. Opus 5, Sonnet 5, Sonnet 5.5 und Haiku 4.5 entscheiden selbst, ob sie etwas davon übernehmen — die Rollentabelle ändert sich dadurch nicht.
|
||||
|
||||
### Haltung zwischen den Schritten
|
||||
|
||||
@@ -174,7 +174,7 @@ Wer Schritt 4 auf „Tests laufen lassen" verkürzt, findet nichts davon.
|
||||
|
||||
Lagere Recherche, Erkundung und parallele Analysen an Subagenten aus — das hält den Koordinatorkontext frei, und das ist die knappe Ressource. Ein Ansatz pro Subagent, sonst vermischen sich die Befunde.
|
||||
|
||||
Wie ein Auftrag an einen Subagenten formuliert wird — Imperativ statt „kannst du vorschlagen", Grund zur Regel, Beispiele in Tags, Subagenten nicht für das, was ein `grep` erledigt — steht in [[AI/Regelwerk/prompting|prompting.md]] (Abschnitte 3 und 5). Was das jeweilige Zielmodell daraus macht: [[AI/Regelwerk/opus-5|opus-5.md]] für `planer` und `pruefer` (keine Selbstprüf-Anweisungen, keine Schwere-Schwelle im Prüfauftrag — Abschnitte 5 und 8), [[AI/Regelwerk/sonnet-5|sonnet-5.md]] für `executer` und Recherche (wörtliches Befolgen, Geltungsbereich je Task nennen — Abschnitt 5). Verbindlich für Fable 5.1 als Auftraggeber; die Modelle selbst entscheiden.
|
||||
Wie ein Auftrag an einen Subagenten formuliert wird — Imperativ statt „kannst du vorschlagen", Grund zur Regel, Beispiele in Tags, Subagenten nicht für das, was ein `grep` erledigt — steht in [[AI/Regelwerk/prompting|prompting.md]] (Abschnitte 3 und 5). Was das jeweilige Zielmodell daraus macht: [[AI/Regelwerk/opus-5|opus-5.md]] für `planer` und `pruefer` (keine Selbstprüf-Anweisungen, keine Schwere-Schwelle im Prüfauftrag — Abschnitte 5 und 8), [[AI/Regelwerk/sonnet-5-5|sonnet-5-5.md]] für `executer` und Recherche (Auftragsvorlagen A2 und A3, Stoppsatz gegen ungefragte Zusätze), dazu [[AI/Regelwerk/sonnet-5|sonnet-5.md]] Abschnitt 5 (wörtliches Befolgen, Geltungsbereich je Task nennen). Verbindlich für Fable 5.1 als Auftraggeber; die Modelle selbst entscheiden.
|
||||
|
||||
**Executer-Subagent (`executer`, Sonnet — bei reiner Abschrift Haiku, siehe Modellzuordnung unten)** — definiert in `.claude/agents/executer.md`, eingesetzt in Schritt 3 der Standardschleife oben.
|
||||
|
||||
@@ -192,7 +192,7 @@ Dieselbe Quellenpflicht gilt für dich als Koordinator. Was du nicht an einer Qu
|
||||
|
||||
### Modellzuordnung und Superpowers
|
||||
|
||||
Die Rollentabelle steht im Stamm ([[CLAUDE|Claude.md]], Abschnitt „Agenten & Modelle"). Kurz: Denken und Prüfen auf **Opus 5.5**, Tippen und Suchen auf **Sonnet 5**. Den Effort je Rolle regelt „Effort je Rolle" unten.
|
||||
Die Rollentabelle steht im Stamm ([[CLAUDE|Claude.md]], Abschnitt „Agenten & Modelle"). Kurz: Denken und Prüfen auf **Opus 5.5**, Tippen und Suchen auf **Sonnet 5.5**. Den Effort je Rolle regelt „Effort je Rolle" unten.
|
||||
|
||||
**Beim Start eines Subagenten das Modell immer explizit angeben.** Ohne Angabe erbt der Subagent das Sitzungsmodell — bei Opus-Sitzungen laufen dann auch mechanische Umsetzungsaufgaben auf Opus, was die Zuordnung still aushebelt.
|
||||
|
||||
@@ -232,15 +232,16 @@ Der Effort ist neben dem Modell der zweite Regler, und bis 2026-09-23 war er nir
|
||||
|
||||
Woher ein Agent seinen Effort bekommt, in dieser Rangfolge (nachgelesen im Programm 2.1.280): eine gesetzte Umgebungsvariable `CLAUDE_CODE_EFFORT_LEVEL` schlägt alles, ist im Vault aber nicht gesetzt (geprüft 2026-09-23); danach der `effort`-Parameter eines Workflow-`agent()`-Aufrufs, dann `effort:` im Frontmatter der Agentendatei, dann der Effort der Sitzung, dann der Standard des Modells. Das Agent-Werkzeug hat keinen Effort-Parameter; dort wirkt nur das Frontmatter. Belegt am 2026-09-23 in einer frischen Sitzung auf `xhigh`: `executer` lief mit `medium`, `pruefer` mit `high`, beides aus dem Transkriptfeld `effort`. Belegt ist das auch im Workflow: Mit `agentType` liefen `executer` und `recherche` mit `medium` aus dem Frontmatter, der Agent ohne Typ mit dem `xhigh` der Sitzung. Zwei Fallstricke dabei. Eine geänderte Agentendatei wirkt in der laufenden Sitzung nicht sofort: Die Änderung von 13:58 zeigte sich um 14:00 noch nicht, knapp eine Stunde später schon. Was das Nachladen auslöst, ist nicht bekannt; sicher ist nur der Blick ins Transkriptfeld `effort`. Einen neu angelegten gespeicherten Workflow kannte die laufende Sitzung zuerst nicht, eine frische schon. Gut eine Stunde später war er auch in der laufenden aufrufbar. Und Haiku 4.5 kennt keinen Effort; ein gesetzter Wert wird gar nicht gesendet.
|
||||
|
||||
Die Werte stammen aus einer Messung vom 2026-09-23 an drei Prüfständen mit bekanntem Ergebnis, je Stufe zwei Läufe:
|
||||
Die Werte der ersten drei Zeilen stammen aus einer Messung vom 2026-09-23 an drei Prüfständen mit bekanntem Ergebnis, je Stufe zwei Läufe; die Sonnet-5.5-Zeile vom 2026-09-29:
|
||||
|
||||
| Rolle | Effort | Was gemessen wurde | Median je Lauf |
|
||||
|---|---|---|---|
|
||||
| `pruefer` (Opus 5.5) | `high` | Review-Fall mit neun eingebauten Fehlern gegen eine SPEC, Tests grün. Jede Stufe von `low` bis `xhigh` fand 9 von 9, keine Fehlalarme. Berechtigte Zusatzfunde je Lauf: `low` 1 und 1, `medium` 3 und 1, `high` 3 und 3, `xhigh` 3 und 3. | `low` 0,24 $, `medium` 0,29 $, `high` 0,34 $, `xhigh` 1,09 $ |
|
||||
| `planer` (Opus 5.5) | `high` | Korrekturplan für dieselben neun Fehler, danach mit `plan_materialisiere.py` angewendet. Alle sechs Pläne ließen sich anwenden, Suite grün, 9 von 9 behoben (eigene Probe). Gegen den alten Code schlugen je Plan 9 bis 13 der neuen Tests fehl; die 1 bis 3 schon vorher grünen sind laut Planerbericht bewusste Absicherungstests. Bei Anwendbarkeit, Suite und Probe kein Unterschied zwischen den Stufen. | `medium` 0,75 $, `high` 0,82 $, `xhigh` 2,90 $ |
|
||||
| `executer` (Sonnet 5) | `medium` | Abschrift-Task mit einem Prüf-grep, der den Docstring trifft. Alle Stufen schrieben gleich treu ab und meldeten den Widerspruch, statt den Docstring umzuformulieren. | `low` 0,13 $, `medium` 0,15 $, `high` 0,19 $ |
|
||||
| `executer` (Sonnet 5.5, 2026-09-29) | `medium` | Derselbe Abschrift-Task plus ein Doku-Task (Anleitung und Hintergrund aus zehn Dossier-Aussagen, bewertet per Skript). Abschrift auf allen Stufen gleich, mit derselben Schreibschicht-Abweichung; Doku: Bewerter ohne Befund, strengere Probe mit Schwächen bei `low` und einmal `medium`. Einzelheiten in [[AI/Regelwerk/sonnet-5-5|sonnet-5-5.md]], A1. | Ausgabetokens Doku: `low` 3.000, `medium` 3.370, `high` 5.070 |
|
||||
|
||||
Warum nicht überall die billigste Stufe: Beim Prüfer ist Abdeckung der Zweck. Ab `high` brachten beide Läufe die drei Zusatzfunde, darunter nicht; `xhigh` brachte nicht mehr als `high`. Beim Planer war `medium` gleich gut und 9 Prozent billiger. Ein Fehler im Plan kostet aber Executer-Wellen und Korrekturrunden im Koordinatorkontext, deshalb `high`. Beim Executer entspricht `medium` laut Doku etwa Sonnet 4.6 bei `high`. Ob `medium` bei Tasks mit Ermessen hält, ist nicht gemessen; scheitert ein Executer dort, gilt die Hochstufung auf Opus aus dem Abschnitt oben.
|
||||
Warum nicht überall die billigste Stufe: Beim Prüfer ist Abdeckung der Zweck. Ab `high` brachten beide Läufe die drei Zusatzfunde, darunter nicht; `xhigh` brachte nicht mehr als `high`. Beim Planer war `medium` gleich gut und 9 Prozent billiger. Ein Fehler im Plan kostet aber Executer-Wellen und Korrekturrunden im Koordinatorkontext, deshalb `high`. Beim Executer auf Sonnet 5 entsprach `medium` laut Doku etwa Sonnet 4.6 bei `high`; für Sonnet 5.5 sagt die Doku nur, die Stufen seien neu geeicht. Ob `medium` bei Tasks mit Ermessen hält, ist nicht gemessen; scheitert ein Executer dort, gilt die Hochstufung auf Opus aus dem Abschnitt oben.
|
||||
|
||||
`xhigh` kostete beim Prüfer das 3,2-Fache, beim Planer das 3,5-Fache von `high`, ohne einen zusätzlichen Treffer im Schlüssel. Ein Prüfer auf `xhigh` fuhr dafür laut seinem Bericht einen großen eigenen Datenlauf (600 Artikel, 5000 Buchungen). Das ist genau der Lauf mit echten Daten, der Fehler findet, die erst bei realistischen Mengen auftreten — der Prüfstand hatte keinen solchen Fehler. Für die Abschlussprüfung einer sicherheits- oder datenrelevanten Änderung gibst du im Workflow deshalb `effort: 'xhigh'` mit.
|
||||
|
||||
@@ -311,5 +312,5 @@ Dateikopf, CHANGELOG statt Versionsnummern in der Datei, was aus dem Code versch
|
||||
- [[AI/Regelwerk/wiederkehrende-jobs|wiederkehrende-jobs.md]] — Interviewform, „Fertig heißt“-Checks, Ablage
|
||||
- [[AI/Regelwerk/fable-5-1|fable-5-1.md]] — nur für Fable 5.1: modellspezifische Verhaltensunterschiede
|
||||
- [[AI/Regelwerk/prompting|prompting.md]] — Aufträge an Subagenten formulieren
|
||||
- [[AI/Regelwerk/opus-5|opus-5.md]], [[AI/Regelwerk/sonnet-5|sonnet-5.md]] — Verhalten der Zielmodelle von Planer/Prüfer bzw. Executer
|
||||
- [[AI/Regelwerk/opus-5|opus-5.md]], [[AI/Regelwerk/sonnet-5-5|sonnet-5-5.md]], [[AI/Regelwerk/sonnet-5|sonnet-5.md]] — Verhalten der Zielmodelle von Planer/Prüfer bzw. Executer
|
||||
- [[Code Projekte/_MOC-Code-Projekte|Code Projekte (Oberseed)]]
|
||||
@@ -5,7 +5,7 @@ title: Prompting-Hinweise für Claude Fable 5.1
|
||||
summary: Verhaltensunterschiede und Prompt-Muster von Claude Fable 5.1 (Teil A) sowie Spezifikation, API-Brüche, neue Funktionen, Preise und Datenhaltung (Teil B) aus der Anthropic-Doku — gilt nur, wenn Fable 5.1 das Modell ist; andere Modelle entscheiden selbst.
|
||||
tags: [regelwerk, modelle, fable, prompting]
|
||||
created: 2026-09-05
|
||||
updated: 2026-09-05
|
||||
updated: 2026-09-29
|
||||
source: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-1
|
||||
---
|
||||
|
||||
@@ -13,7 +13,7 @@ source: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering
|
||||
|
||||
> **Geltungsbereich — bitte zuerst lesen.**
|
||||
> Diese Datei gilt **nur für Claude Fable 5.1** (und das baugleiche Claude Mythos 5.1). Läufst du als Fable 5.1, berücksichtigst du die Punkte unten als Teil deiner Arbeitsweise.
|
||||
> Läufst du als **Opus 5, Sonnet 5 oder Haiku 4.5**, dann sind das keine Anweisungen an dich. Diese Modelle arbeiten nach ihren eigenen Optimierungen und entscheiden selbst, ob sie einen Punkt übernehmen. Die Rollentabelle im Stamm ([[CLAUDE|Claude.md]], „Agenten & Modelle") bleibt unverändert.
|
||||
> Läufst du als **Opus 5, Sonnet 5, Sonnet 5.5 oder Haiku 4.5**, dann sind das keine Anweisungen an dich. Diese Modelle arbeiten nach ihren eigenen Optimierungen und entscheiden selbst, ob sie einen Punkt übernehmen. Die Rollentabelle im Stamm ([[CLAUDE|Claude.md]], „Agenten & Modelle") bleibt unverändert.
|
||||
> Angeordnet am 2026-09-05. Quellen: Anthropic-Doku „Prompting Claude Fable 5.1" (Teil A), „What's new in Claude Fable 5.1" (Teil B) und der Migrationsleitfaden (Teil C), alle abgerufen am 2026-09-05. Die Aussagen stammen aus diesen Seiten, nicht aus eigener Messung — wo die Doku eine Bedingung nennt, steht sie hier mit. Die modellübergreifenden Techniken stehen in [[AI/Regelwerk/prompting|prompting.md]].
|
||||
|
||||
## Wozu diese Datei
|
||||
@@ -104,7 +104,7 @@ Mannered prose substitutes metaphor and flourish for direct statement. Instead o
|
||||
|
||||
Die Kurzform tut es laut Doku meist auch: `Please remove all mannered prose.`
|
||||
|
||||
Für dich als Fable 5.1 im Vault: Das deckt sich mit [[AI/Regelwerk/schreibstil|schreibstil.md]] — sag, was du meinst; wenn eine wörtliche Formulierung da ist, nimm sie. Zusätzlich gilt für dich ausdrücklich: **Absätze brechen, Sätze kurz halten.** Der Schreibstil verlangt ganze Sätze, nicht lange.
|
||||
Für dich als Fable 5.1 im Vault: Das deckt sich mit [[AI/Regelwerk/schreibstil|schreibstil.md]] — sag, was du meinst; wenn eine wörtliche Formulierung da ist, nimm sie. Zusätzlich gilt für dich ausdrücklich: **Liste statt Absatz, Sätze kurz halten.** Der Schreibstil verlangt Stichpunkte mit ganzer Aussage, keine Textblöcke.
|
||||
|
||||
## 6 Formatierung im Chat (Sitzung)
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ title: Prompting-Hinweise für Claude Opus 5
|
||||
summary: Verhaltensunterschiede und Prompt-Muster von Claude Opus 5 (Teil A) sowie Spezifikation, API-Brüche, neue Funktionen, Preise (Teil B) aus der Anthropic-Doku; Teil D nennt, was bei Opus 5.5 abweicht. Betrifft Koordinator, Planer und Prüfer.
|
||||
tags: [regelwerk, modelle, opus, prompting]
|
||||
created: 2026-09-05
|
||||
updated: 2026-09-23
|
||||
updated: 2026-09-29
|
||||
source: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5
|
||||
---
|
||||
|
||||
@@ -63,7 +63,7 @@ Getrennt von der Gesprächslänge: Dateien, die Opus 5 auf die Platte schreibt
|
||||
Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.
|
||||
```
|
||||
|
||||
Deckt sich mit [[AI/Regelwerk/schreibstil|schreibstil.md]] („Kein Fazit, das wiederholt, was oben stand") und mit Punkt 6 der [[AI/Regelwerk/dokumentations-grossprojekte|Dokumentations-Großprojekte]] (keine Zeilenzahl-Vorgaben, sondern inhaltliche Mindestanforderungen).
|
||||
Deckt sich mit [[AI/Regelwerk/schreibstil|schreibstil.md]] („kein Fazit, das wiederholt") und mit Punkt 6 der [[AI/Regelwerk/dokumentations-grossprojekte|Dokumentations-Großprojekte]] (keine Zeilenzahl-Vorgaben, sondern inhaltliche Mindestanforderungen).
|
||||
|
||||
## 5 Umfang und Über-Verifikation
|
||||
|
||||
@@ -214,7 +214,7 @@ Bei Opus 4.5 oder älter zusätzlich: Prefill entfernt; JSON-Escaping in Werkzeu
|
||||
|
||||
Gleiche API-Oberfläche — Thinking an, Effort `high`, 1M/128k, kein Priority Tier, keine Sampling-Parameter, kein Prefill. Vier Unterschiede: Preis 5 $ / 25 $ statt 2 $ / 10 $; **Sonnet 5 erlaubt `disabled` bei jedem Effort, Opus 5 nur bis `high`**; **Mid-Conversation-System-Nachrichten gibt es auf Sonnet 5 nicht**; Web Fetch gibt es auf Opus 5 nicht. Tokens neu zählen — anderer Tokenizer.
|
||||
|
||||
Für den Vault heißt das konkret: Ein Harness, der rundenbezogene System-Nachrichten oder Werkzeugänderungen im Gespräch nutzt, läuft so nur auf Opus 5 und Fable 5.1, nicht auf dem Executer-Modell.
|
||||
Für den Vault heißt das konkret: Ein Harness, der rundenbezogene System-Nachrichten oder Werkzeugänderungen im Gespräch nutzt, läuft so auf Opus 5 und Fable 5.1. Für Sonnet 5 und Sonnet 5.5 (Executer-Modell seit 2026-09-29) widersprechen sich Doku und CLI-Katalog, siehe sonnet-5-5.md C2.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ title: Portfolio-Monitor
|
||||
summary: Was der wöchentliche Depotbericht prüft, welche Grenzwerte anschlagen, was er liefern darf und was nicht.
|
||||
tags: [regelwerk, finanzen, monitor, agent]
|
||||
created: 2026-09-01
|
||||
updated: 2026-09-01
|
||||
updated: 2026-09-29
|
||||
---
|
||||
|
||||
# Portfolio-Monitor
|
||||
@@ -47,7 +47,7 @@ Die Halbleiterschwelle von 35 % stammt aus dem Falsifikationskriterium von These
|
||||
|
||||
## Was im Bericht steht
|
||||
|
||||
Ablage: `Finanzen/Berichte/JJJJ-MM-TT-depotbericht.md`. Ton nach [[AI/Regelwerk/schreibstil|schreibstil.md]] — kurz, ganze Sätze, keine Zusammenfassung dessen, was oben schon stand.
|
||||
Ablage: `Finanzen/Berichte/JJJJ-MM-TT-depotbericht.md`. Form nach [[AI/Regelwerk/schreibstil|schreibstil.md]] — Tabellen und Stichpunkte mit ganzer Aussage, keine Zusammenfassung dessen, was oben schon stand.
|
||||
|
||||
1. **Eine Zeile Lage.** Was sich seit dem letzten Bericht geändert hat, oder dass sich nichts geändert hat.
|
||||
2. **Kennzahlen** mit Stichtag: Aktienteil, Halbleiteranteil, größte Einzelposition, Aufteilung Themen gegen breit, Cash.
|
||||
|
||||
@@ -5,7 +5,7 @@ title: Prompting-Grundlagen für aktuelle Claude-Modelle
|
||||
summary: Die allgemeinen Prompt-Techniken aus der Anthropic-Doku „Prompting best practices" — Klarheit, Beispiele, XML-Struktur, Werkzeugnutzung, Thinking, lange Aufgaben, Subagenten. Verbindlich für Fable 5.1; andere Modelle entscheiden selbst.
|
||||
tags: [regelwerk, modelle, prompting, subagenten]
|
||||
created: 2026-09-05
|
||||
updated: 2026-09-05
|
||||
updated: 2026-09-29
|
||||
source: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
|
||||
---
|
||||
|
||||
@@ -18,7 +18,7 @@ source: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering
|
||||
|
||||
Die meisten Punkte hier betreffen nicht das Sprechen mit dem Nutzer, sondern das **Schreiben von Aufträgen**: an Subagenten, in Agent- und Skill-Dateien, in Plänen, und in System-Prompts eigener Integrationen in Code-Projekten. Wer einen Executer-Auftrag oder einen Prüfauftrag formuliert, schreibt einen Prompt. Dafür gelten die Regeln unten. Die eigene Modell-Seite (für Fable 5.1: [[AI/Regelwerk/fable-5-1|fable-5-1.md]]) liest man laut Doku zuerst, dann diese Techniken.
|
||||
|
||||
Die Modellseiten dazu: [[AI/Regelwerk/fable-5-1|fable-5-1.md]], [[AI/Regelwerk/opus-5|opus-5.md]], [[AI/Regelwerk/sonnet-5|sonnet-5.md]]. Nicht eingearbeitet sind „Prompting Claude Fable 5" und „Prompting Claude Opus 4.8" — beide Modelle laufen im Vault nicht.
|
||||
Die Modellseiten dazu: [[AI/Regelwerk/fable-5-1|fable-5-1.md]], [[AI/Regelwerk/opus-5|opus-5.md]], [[AI/Regelwerk/sonnet-5-5|sonnet-5-5.md]], [[AI/Regelwerk/sonnet-5|sonnet-5.md]]. Nicht eingearbeitet sind „Prompting Claude Fable 5" und „Prompting Claude Opus 4.8" — beide Modelle laufen im Vault nicht.
|
||||
|
||||
## 1 Allgemeine Prinzipien
|
||||
|
||||
|
||||
+133
-47
@@ -2,94 +2,180 @@
|
||||
type: resource
|
||||
status: reference
|
||||
title: Schreibstil
|
||||
summary: Ton und harte Grenzen für Anleitungen, Handouts, Kunden- und Codedoku — Kaffeepausen-Maßstab, Realität vor Stil, Referenzdokument.
|
||||
summary: "Stichpunkte und Tabellen statt Textblöcke, Anleitung und Hintergrund als getrennte Seiten, eine Kommentarzeile je Codeabschnitt — Realität vor Stil, Referenzdokument."
|
||||
tags: [regelwerk, schreibstil, dokumentation]
|
||||
created: 2026-08-24
|
||||
updated: 2026-09-05
|
||||
updated: 2026-09-29
|
||||
---
|
||||
|
||||
# Schreibstil
|
||||
|
||||
Angeordnet am 2026-08-24. Gilt für alles, was ein Mensch lesen soll: Anleitungen, Handouts, Kundendokumentation, Bookstack-Artikel, Projektdokumentation, Codedoku unter `docs/`, Sitzungszusammenfassungen.
|
||||
Angeordnet am 2026-08-24, umgestellt auf Pascals Anordnung am 2026-09-29: lange Anleitungen erschlagen den Leser und führen zu Frust.
|
||||
|
||||
Nicht gemeint sind Prüfprotokolle, Regelteile von Compliance-Dokumenten und alles, was jemand später gegen mich hält — dazu unten „Wo der Ton nicht gilt".
|
||||
Gilt für alles, was ein Mensch lesen soll:
|
||||
|
||||
- Technische Anleitungen, Handouts, Bookstack-Artikel, Kundendokumentation
|
||||
- Codedoku unter `docs/code/`, Projektdokumentation
|
||||
- Konzepte, Portfolio-Dokumente, Entscheidungsvorlagen
|
||||
- Sitzungszusammenfassungen und Agentenprotokoll
|
||||
|
||||
Ausnahmen stehen unten unter „Wo der Stil nicht gilt".
|
||||
|
||||
## Der Maßstab
|
||||
|
||||
Erklär es so, wie du es einem guten Freund in der Kaffeepause erklären würdest — und zwar dem, der es hinterher wirklich umsetzen muss.
|
||||
- **Kurz, aber vollständig.** Jede Aussage, die der Leser zum Umsetzen braucht, bleibt drin. Gekürzt wird die Verpackung, nie der Inhalt.
|
||||
- **Stichpunkte und Tabellen statt Textblöcke.** Fließtext höchstens zwei Sätze am Stück, danach Liste oder Tabelle.
|
||||
- **Ein Stichpunkt trägt eine ganze Aussage.** Wer, was, unter welcher Bedingung. Kein Stichwort-Telegramm wie „Firewall — beachten".
|
||||
- **Tabellen für alles Vergleichbare:** Optionen, Parameter, Rollen, Zuständigkeiten, Vorher/Nachher.
|
||||
- **Du sprichst zu jemandem.** „Du brauchst dafür", nicht „es wird benötigt". Die Sie-Form nur, wo eine Datei sie verlangt (etwa [[AI/Regelwerk/seo|seo.md]]).
|
||||
- **Zuerst, wofür das gut ist.** Eine Zeile, dann der Weg.
|
||||
- **Wörtlich statt bildhaft.** Sag, was du meinst; gibt es eine wörtliche Formulierung, nimm sie.
|
||||
- **Kein Vortragston.** Keine Einleitung über die Wichtigkeit, kein Fazit, das wiederholt.
|
||||
|
||||
Das heißt konkret:
|
||||
## Anleitung und Hintergrund — zwei Seiten
|
||||
|
||||
- **Du sprichst zu jemandem.** Nicht ins Leere, nicht in eine Zielgruppe. Also „du brauchst dafür" statt „es wird benötigt".
|
||||
- **Die Reihenfolge folgt dem Gespräch, nicht dem Handbuch.** Zuerst wofür das gut ist, dann der Weg, dann die Fallstricke. Nicht: Definition, Architektur, Voraussetzungen, Schritt 1.
|
||||
- **Der Fallstrick kommt da, wo man reinläuft.** Nicht gesammelt in einem Kapitel „Bekannte Probleme" am Ende.
|
||||
- **Ganze Sätze.** Ein Stichpunkt ist keine Erklärung, sondern die Erinnerung an eine, die mal jemand hatte.
|
||||
- **Kein Vortragston.** Keine Einleitung darüber, wie wichtig das Thema ist. Kein Fazit, das wiederholt, was oben stand.
|
||||
Eine technische Anleitung besteht aus zwei Dateien nebeneinander:
|
||||
|
||||
| | `<thema>-anleitung.md` | `<thema>-hintergrund.md` |
|
||||
|---|---|---|
|
||||
| Enthält | Zweck (eine Zeile), Link auf den Hintergrund, Voraussetzungen, nummerierte Schritte, Codeblöcke, Prüfen | Link zurück auf die Anleitung, Warum so, Architektur, Fallstricke im Detail, Alternativen, Quellen |
|
||||
| Enthält nicht | Begründungen, Architektur, Historie, Alternativen | die Schrittfolge |
|
||||
| Form | Liste und Code | Stichpunkte und Tabellen, kurze Absätze erlaubt |
|
||||
|
||||
- In Bookstack: zwei Seiten im selben Kapitel, „<Thema> — Anleitung" und „<Thema> — Hintergrund".
|
||||
- **Der Fallstrick bleibt am Schritt, an dem man reinläuft** — als eine Zeile mit ⚠. Die Erklärung dazu steht im Hintergrund.
|
||||
- Kurze Anleitungen ohne nennenswerten Hintergrund brauchen keine zweite Seite. Dann fehlt der Link, und es steht nichts Erklärendes in der Anleitung.
|
||||
|
||||
## Code in Dokumenten
|
||||
|
||||
- **Eine Kommentarzeile über jedem Codeblock-Abschnitt**, die sagt, was der Abschnitt tut.
|
||||
- **Keine Zeilenkommentare.** Was ein Schalter bedeutet, steht im Hintergrund.
|
||||
- Ein Block mit mehreren Aufgaben wird in Abschnitte geteilt, jeder mit seiner Kommentarzeile.
|
||||
- Kommentarzeichen der Sprache: `#` für Bash, PowerShell, Python, YAML; `//` für JavaScript und C#; `--` für SQL; `REM` für cmd.
|
||||
- Gilt nur für Code **in Dokumenten**. Produktivdateien folgen [[AI/Regelwerk/codedoku|codedoku.md]].
|
||||
|
||||
## Weitere Dokumentarten
|
||||
|
||||
| Dokumentart | Form |
|
||||
|---|---|
|
||||
| Codedoku `docs/code/` | vier Fragen aus [[AI/Regelwerk/codedoku|codedoku.md]] als Überschriften, darunter Stichpunkte; Ablauf als nummerierte Liste |
|
||||
| Konzept, Portfolio, Entscheidungsvorlage | Tabellen und Stichpunkte; eine Empfehlung steht mit ihrem Grund in derselben Zeile |
|
||||
| Sitzungsbericht, Agentenprotokoll | Stichpunkte je Thema: was erledigt, was offen, was Pascal tun muss |
|
||||
|
||||
## Die Grenze — Realität vor Stil
|
||||
|
||||
Der Ton ändert sich, die Aussagen nicht. Vier Regeln, die keinen Ermessensspielraum haben:
|
||||
Die Form ändert sich, die Aussagen nicht. Vier Regeln ohne Ermessensspielraum:
|
||||
|
||||
1. **Nichts erfinden.** Keine Zahlen, keine Versionsnummern, keine Pfade, keine Fehlermeldungen aus dem Gedächtnis. Konkretheit kommt aus der Quelle oder gar nicht.
|
||||
2. **Nichts weichzeichnen.** Wenn eine Aussage nur unter einer Bedingung stimmt, bleibt die Bedingung im Satz. Auch wenn er dadurch sperrig wird. Ein sperriger Satz, der stimmt, schlägt einen schönen, der beim Kunden bricht.
|
||||
3. **Lücken benennen, nicht überbrücken.** „Ob das unter Rocky 10 genauso läuft, habe ich nicht geprüft" ist ein Ergebnis. Ein glatter Satz, der die Frage offen lässt, ohne es zu sagen, ist eine Falle.
|
||||
4. **Keine Position, die das Material nicht hergibt.** Eine Empfehlung braucht einen Grund, der im Text steht. Sonst ist es Geschmack im Gewand einer Aussage.
|
||||
1. **Nichts erfinden.** Keine Zahlen, Versionsnummern, Pfade oder Fehlermeldungen aus dem Gedächtnis. Konkretheit kommt aus der Quelle oder gar nicht.
|
||||
2. **Nichts weichzeichnen.** Gilt eine Aussage nur unter einer Bedingung, bleibt die Bedingung im Stichpunkt — auch wenn er dadurch lang wird. Kürzen heißt nicht, Bedingungen zu streichen.
|
||||
3. **Lücken benennen, nicht überbrücken.** „Unter Rocky 10 nicht geprüft" ist ein Ergebnis und bekommt einen eigenen Stichpunkt.
|
||||
4. **Keine Position, die das Material nicht hergibt.** Eine Empfehlung braucht einen Grund, der danebensteht.
|
||||
|
||||
Der Grund für die Härte: Vermenschlichen hat genau eine bekannte Fehlerart — es erfindet Konkretheit, damit der Text weniger nach Modell klingt. Bei einem Blogpost ist das peinlich. Bei einer Kundendokumentation steht am Ende jemand vor einem System, das anders reagiert als beschrieben.
|
||||
Der Grund für die Härte: Kürzen und Glätten haben dieselbe Fehlerart — Bedingungen und Vorbehalte fallen weg, weil sie sperrig sind. Vermenschlichen hat eine zweite: Es erfindet Konkretheit, damit der Text weniger nach Modell klingt. Am Ende steht jemand vor einem System, das anders reagiert als beschrieben.
|
||||
|
||||
## Vorher / Nachher
|
||||
|
||||
| Statt | Besser |
|
||||
|---|---|
|
||||
| „Im Anschluss erfolgt die Konfiguration des Dienstes." | „Danach konfigurierst du den Dienst." |
|
||||
| „Es ist zu beachten, dass unter Umständen Probleme auftreten können." | „Auf Windows-Konsolen bricht das ab, wenn ein Umlaut in der Ausgabe steht — cp1252." |
|
||||
| „Diese Lösung bietet zahlreiche Vorteile." | Streichen. Wenn es Vorteile gibt, benenne sie; wenn nicht, war der Satz leer. |
|
||||
| „Best Practice ist die Verwendung von X." | „Ich nehme X, weil Y. Z ginge auch, kostet aber W." |
|
||||
| Absatz aus fünf Sätzen über Voraussetzungen | Liste „Voraussetzungen", ein Punkt je Voraussetzung |
|
||||
| „Im Anschluss erfolgt die Konfiguration des Dienstes." | „3. Dienst konfigurieren:" plus Codeblock |
|
||||
| Codeblock mit Kommentar an jeder Zeile | eine Kommentarzeile je Abschnitt; Schalter im Hintergrund erklärt |
|
||||
| „Es ist zu beachten, dass unter Umständen Probleme auftreten können." | „⚠ Auf Windows-Konsolen bricht das bei Umlauten in der Ausgabe ab (cp1252)." |
|
||||
| „Firewall beachten" | „Port 443 eingehend muss am Perimeter offen sein, sonst schlägt die Registrierung fehl." |
|
||||
| „Best Practice ist X." | Tabellenzeile: Option X — nehme ich, weil Y; Option Z — ginge, kostet W |
|
||||
| „Diese Lösung bietet zahlreiche Vorteile." | Streichen. Gibt es Vorteile, je Vorteil ein Stichpunkt; sonst war der Satz leer. |
|
||||
| „Studien zeigen, dass …" | Quelle nennen oder Behauptung streichen. |
|
||||
| „Der Prozess ist nun abgeschlossen." | Streichen. Der Leser merkt, wenn die Anleitung aufhört. |
|
||||
| „Der Prozess ist nun abgeschlossen." | Streichen. |
|
||||
|
||||
## Das Referenzdokument
|
||||
|
||||
Ton per Beispiel, nicht per Beschreibung — dieselbe Regel wie bei den Dokumentations-Großprojekten. Wenn ein Set von Dokumenten entsteht, bekommt jeder Subagent ein fertiges Referenzdokument mit. Das hier ist die Vorlage, an der sich alles ausrichtet:
|
||||
Ton per Beispiel, nicht per Beschreibung — dieselbe Regel wie bei den Dokumentations-Großprojekten. Jeder Subagent, der Dokumente schreibt, bekommt dieses Paar mit:
|
||||
|
||||
> ### Tote Links im Vault finden
|
||||
>
|
||||
> Der Linkcheck zeigt dir, welche Wikilinks ins Leere zeigen. Er lässt Codeblöcke aus. Deshalb meldet er ein `[[ $EUID -eq 0 ]]` aus einem Bash-Beispiel nicht als toten Link. Der `vault_doctor` aus dem alten Toolkit tut genau das: Er fand dort 92 Leichen, und keine davon war echt.
|
||||
>
|
||||
> ```bash
|
||||
> PYTHONIOENCODING=utf-8 python .vault-tools/linkcheck/linkcheck.py --vault .
|
||||
> ```
|
||||
>
|
||||
> Das `python` ist kein Tippfehler. `python3` startet auf dieser Maschine den Microsoft-Store-Stub und meldet „Python was not found", statt zu laufen. Ohne `PYTHONIOENCODING` zerlegt die Windows-Konsole außerdem die Umlaute in der Ausgabe.
|
||||
>
|
||||
> Was der Linkcheck nicht sieht, sind Pfade in Backticks. Wer in einer Tagesnotiz `AI/sessions/…` statt `[[AI/sessions/…]]` schreibt, hat einen Verweis, den keine Prüfung kontrolliert.
|
||||
````markdown
|
||||
### Tote Links im Vault finden — Anleitung
|
||||
|
||||
Woran man den Ton erkennt: Der erste Satz sagt, wofür das Ding gut ist. Der Fallstrick steht direkt am Befehl, nicht in einem Kapitel weiter unten. Und die Stelle, die das Werkzeug nicht sieht, wird benannt statt umschifft.
|
||||
Zeigt alle Wikilinks, die ins Leere zeigen. Warum so: [[tote-links-finden-hintergrund|Hintergrund]]
|
||||
|
||||
**Voraussetzungen**
|
||||
|
||||
- Python ist unter dem Befehl `python` erreichbar.
|
||||
- Du stehst im Vault-Root.
|
||||
|
||||
**Schritte**
|
||||
|
||||
1. Linkcheck starten:
|
||||
|
||||
```bash
|
||||
# Linkcheck über den ganzen Vault, Ausgabe in UTF-8
|
||||
PYTHONIOENCODING=utf-8 python .vault-tools/linkcheck/linkcheck.py --vault .
|
||||
```
|
||||
|
||||
⚠ `python3` startet hier den Microsoft-Store-Stub und läuft nicht.
|
||||
|
||||
2. Gemeldete Links in den genannten Dateien korrigieren.
|
||||
|
||||
**Prüfen**
|
||||
|
||||
- Ein zweiter Lauf meldet die korrigierten Links nicht mehr.
|
||||
- Pfade in Backticks prüft der Linkcheck nicht — die siehst du von Hand durch.
|
||||
````
|
||||
|
||||
````markdown
|
||||
### Tote Links im Vault finden — Hintergrund
|
||||
|
||||
- **Warum der Linkcheck:** Er lässt Codeblöcke aus. Der `vault_doctor` aus dem alten Toolkit tut das nicht und fand dort 92 tote Links, keiner davon echt — etwa `[[ $EUID -eq 0 ]]` aus einem Bash-Beispiel.
|
||||
- **Warum `PYTHONIOENCODING=utf-8`:** Ohne die Variable zerlegt die Windows-Konsole die Umlaute in der Ausgabe.
|
||||
- **Warum `python`:** `python3` meldet auf dieser Maschine „Python was not found".
|
||||
- **Blinder Fleck:** Wer `AI/sessions/…` in Backticks statt `[[AI/sessions/…]]` schreibt, hat einen Verweis, den keine Prüfung kontrolliert.
|
||||
|
||||
Zur Anleitung: [[tote-links-finden-anleitung|Anleitung]]
|
||||
````
|
||||
|
||||
Woran man den Stil erkennt:
|
||||
|
||||
- Die erste Zeile sagt, wofür das Ding gut ist.
|
||||
- Die Anleitung enthält keinen einzigen Begründungssatz, nur den ⚠-Hinweis am Schritt.
|
||||
- Jede Aussage des Hintergrunds ist ein Stichpunkt mit fettem Stichwort.
|
||||
- Die Stelle, die das Werkzeug nicht sieht, wird benannt.
|
||||
|
||||
## Bestehende Anleitungen umbauen
|
||||
|
||||
- Neue Dokumente entstehen im neuen Stil. Der Bestand bleibt, bis jemand ihn anfasst.
|
||||
- Umbau auf Zuruf mit dem Skill `anleitung-straffen` (`.claude/skills/anleitung-straffen/`).
|
||||
- **Beim Umbau behält die bestehende Datei ihren Namen und Titel und wird die Anleitung.** Grund: Wikilinks und die Bookstack-Zuordnung zeigen auf sie. Neu daneben entsteht `<alter-dateiname>-hintergrund.md` mit Titel „<alter Titel> — Hintergrund".
|
||||
|
||||
## Verhältnis zum `humanizer`-Skill
|
||||
|
||||
Diese Datei ist die **Voreinstellung** — so wird geschrieben, ohne dass jemand danach fragt.
|
||||
|
||||
Der `humanizer`-Skill ist der **Nachbearbeitungsgang** für Texte, die schon glatt geraten sind: er misst Satzlängen-Varianz objektiv (`scripts/rhythmus.py`), kennt die deutschen KI-Marker und hat dieselbe harte Regel „Nichts erfinden". Ihn rufen, wenn ein fertiger Entwurf nach Modell klingt oder ein Kundendokument den letzten Schliff braucht — nicht als Ersatz für sauberes Schreiben von Anfang an.
|
||||
- Diese Datei ist die **Voreinstellung**.
|
||||
- Der `humanizer` ist der **Nachbearbeitungsgang** für Texte, die schon glatt geraten sind und nach Modell klingen. Er misst die Satzlängen-Varianz (`scripts/rhythmus.py`), kennt die deutschen KI-Marker und hat dieselbe Regel „Nichts erfinden".
|
||||
- Ihn rufen, wenn ein fertiger Entwurf nach Modell klingt oder ein Kundendokument den letzten Schliff braucht — nicht als Ersatz für sauberes Schreiben.
|
||||
- **Der humanizer kennt diese Datei nicht.** Er rät, Aufzählungen zu entkalibrieren, sparsam zu fetten und Listen mit fettem Stichwort und Doppelpunkt in Prosa aufzulösen — genau die Hintergrund-Form dieser Datei. Nach seinem Durchgang prüfst du: Listen und Tabellen sind Listen und Tabellen geblieben, die fetten Stichwörter im Hintergrund stehen noch.
|
||||
|
||||
## Nur für Claude Fable 5.1
|
||||
|
||||
Schreibt Fable 5.1 den Text, kommen drei modellspezifische Punkte aus [[AI/Regelwerk/fable-5-1|fable-5-1.md]] dazu (Abschnitte 5, 6, 7): Die Prosa neigt zu langen, dichten Sätzen ohne Absatzbrüche — also Absätze brechen und die wörtliche Formulierung der bildhaften vorziehen. Im Chat greift es seltener zu Listen und Fettdruck als frühere Modelle — bei vielgliedrigem Inhalt trotzdem eine Liste nehmen. Und beim Zusammenfassen übernimmt es Quellwortlaut eher unmarkiert — entweder als Zitat kennzeichnen oder in eigenen Worten wiedergeben. Andere Modelle entscheiden selbst, ob sie das übernehmen; die Regeln dieser Datei gelten für alle.
|
||||
Schreibt Fable 5.1 den Text, kommen drei Punkte aus [[AI/Regelwerk/fable-5-1|fable-5-1.md]] dazu (Abschnitte 5, 6, 7):
|
||||
|
||||
## Wo der Ton nicht gilt
|
||||
- Die Prosa neigt zu langen, dichten Sätzen — hier also erst recht Liste statt Absatz.
|
||||
- Im Chat greift es seltener zu Listen als frühere Modelle — bei vielgliedrigem Inhalt trotzdem Liste oder Tabelle.
|
||||
- Beim Zusammenfassen übernimmt es Quellwortlaut eher unmarkiert — als Zitat kennzeichnen oder in eigenen Worten.
|
||||
|
||||
Gleichförmigkeit ist dort ein Feature, nicht ein Fehler:
|
||||
Andere Modelle entscheiden selbst, ob sie das übernehmen; die Regeln dieser Datei gelten für alle.
|
||||
|
||||
- **Regelteile von ISMS- und Compliance-Dokumenten.** Eine Anforderung wird zitiert, nicht erzählt. Basis- und Zusatzkriterien bleiben getrennt und gekennzeichnet.
|
||||
- **Prüfprotokolle, Nachweise, Abnahmedokumente.** Dort steht, was gemessen wurde, mit welchem Befehl, mit welchem Ergebnis.
|
||||
- **Kopfkommentare von Prüfskripten.** Geltungsbereich und benannte Lücken, so nüchtern wie möglich — siehe [[AI/Regelwerk/pruefwerkzeuge|pruefwerkzeuge.md]].
|
||||
- **Rechtliche und vertragliche Texte.** Präzision schlägt Lesbarkeit.
|
||||
## Wo der Stil nicht gilt
|
||||
|
||||
In allen vier Fällen darf der **umgebende** Text trotzdem in diesem Ton stehen — Einleitung, Begründung, Handlungsempfehlung. Nur der Kern bleibt formal.
|
||||
Dort bleibt die Form, die das Dokument verlangt:
|
||||
|
||||
- **Regelteile von ISMS- und Compliance-Dokumenten.** Eine Anforderung wird zitiert, nicht umformuliert. „Muss" und „darf nicht" bleiben. Basis- und Zusatzkriterien bleiben getrennt und gekennzeichnet.
|
||||
- **Prüfprotokolle, Nachweise, Abnahmedokumente** — alles, was jemand später gegen uns hält. Was gemessen wurde, mit welchem Befehl, mit welchem Ergebnis.
|
||||
- **Kopfkommentare von Prüfskripten.** Geltungsbereich und benannte Lücken — siehe [[AI/Regelwerk/pruefwerkzeuge|pruefwerkzeuge.md]].
|
||||
- **Rechtliche und vertragliche Texte.** Präzision schlägt Kürze.
|
||||
|
||||
Der **umgebende** Text — Einleitung, Begründung, Handlungsempfehlung — steht trotzdem in diesem Stil.
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [[CLAUDE|↑ Claude.md (Stamm)]]
|
||||
- [[AI/Regelwerk/codeworkflow|Codeworkflow]] — Abschnitt „Produktivdateien und Codedoku"
|
||||
- [[AI/Regelwerk/codedoku|codedoku.md]] — Kommentare in Produktivdateien, Codedoku
|
||||
- [[AI/Regelwerk/dokumentations-grossprojekte|dokumentations-grossprojekte.md]] — Referenzdokument bei Fan-Out
|
||||
- [[AI/Regelwerk/pruefwerkzeuge|Prüfwerkzeuge]]
|
||||
- [[AI/Regelwerk/fable-5-1|fable-5-1.md]] — nur für Fable 5.1: Schreibdichte, Formatierung, Zitieren
|
||||
+3
-3
@@ -1,11 +1,11 @@
|
||||
---
|
||||
type: resource
|
||||
status: reference
|
||||
status: pending-review
|
||||
title: SEO-Arbeit an WordPress-Kundensites über WPVibe
|
||||
summary: Regeln für SEO-Audits und deren Umsetzung auf WordPress-Sites (Rank Math, Salient/WPBakery, WP Super Cache, WPCode) über den WPVibe-Connector — Arbeitsweise, Werkzeugwege, Messregeln, bekannte Fallen. Nur laden, wenn eine Website auditiert oder nach einem Audit umgebaut wird.
|
||||
tags: [regelwerk, seo, wordpress, wpvibe, rank-math]
|
||||
created: 2026-09-07
|
||||
updated: 2026-09-17
|
||||
updated: 2026-09-29
|
||||
---
|
||||
|
||||
# SEO-Arbeit an WordPress-Kundensites über WPVibe
|
||||
@@ -81,7 +81,7 @@ Alles hier stammt aus der Arbeit an einer Kundensite zwischen dem 02.09. und dem
|
||||
- Frage-Antwort-Toggles (`[toggle title="…"]`) werden serverseitig gerendert und sind crawlbar; das FAQPage-Schema liest sie aus dem Rohinhalt. Zielkorridor je Antwort für KI-Zitierbarkeit 134–167 Wörter; 120–150 ist erreichbar, ohne zu schwafeln.
|
||||
- Jede Antwort: Faustregel mit Rechenbeispiel, Preisbeispiel mit Datum und „freibleibend, inklusive Mehrwertsteuer", zuständige Person mit Link auf `/team/`. Preise nur aus der Preisliste des Betreibers, mit Stand.
|
||||
- Team-Verlinkung heißt Link **im Inhalt**, nicht im Menü.
|
||||
- Schreibstil nach [[AI/Regelwerk/schreibstil|schreibstil.md]]: Sie-Form wie die Site, ganze Sätze, keine Marketingfloskeln.
|
||||
- Schreibstil nach [[AI/Regelwerk/schreibstil|schreibstil.md]]: Sie-Form wie die Site, keine Marketingfloskeln. Ausnahme vom Listenstil: FAQ-Antworten auf der Site bleiben Fließtext im Zielkorridor oben, weil Schema und KI-Zitierbarkeit ganze Antworten lesen.
|
||||
|
||||
## Verwandt
|
||||
|
||||
|
||||
@@ -0,0 +1,178 @@
|
||||
---
|
||||
type: resource
|
||||
status: reference
|
||||
title: "Arbeiten mit Claude Sonnet 5.5"
|
||||
summary: "Sonnet 5.5 als executer und recherche: Effort je Rolle nach Messung vom 2026-09-29, tokensparende Auftragsvorlagen, Prüfpunkte, Verhalten und Prompt-Muster, Spezifikation und API-Brüche."
|
||||
tags: [regelwerk, modelle, sonnet, prompting]
|
||||
created: 2026-09-29
|
||||
updated: 2026-09-29
|
||||
source: "https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5"
|
||||
---
|
||||
|
||||
# Arbeiten mit Claude Sonnet 5.5
|
||||
|
||||
Angeordnet von Pascal am 2026-09-29. Quellen: Anthropic-Doku (abgerufen 2026-09-29 von einem `recherche`-Agenten, Zitate aus seinem Bericht) und der Modellkatalog in Claude Code 2.1.285 (am Abbild gelesen, nicht gelaufen). Eigene Messung: Abschnitt A1.
|
||||
|
||||
## Geltungsbereich
|
||||
|
||||
- Der Alias `sonnet` löst in Claude Code 2.1.285 auf `claude-sonnet-5-5` auf, auf der Anthropic-API. Seit 2.1.284 ist Sonnet 5.5 dort das Standard-Sonnet.
|
||||
- Damit laufen `executer` und `recherche` (`model: sonnet`) auf Sonnet 5.5, ohne dass eine Agentendatei geändert wurde. Belegt am 2026-09-29 im Transkript: drei `recherche`-Agenten liefen mit `claude-sonnet-5-5` und Effort `medium`.
|
||||
- Auf Bedrock, Vertex, Foundry und Mantle löst `sonnet` auf `claude-sonnet-4-5` auf, über `anthropic_aws` und Gateway auf `claude-sonnet-4-6`. Für den Vault ohne Belang, solange die Sitzung über die Anthropic-API läuft.
|
||||
- [[AI/Regelwerk/sonnet-5|sonnet-5.md]] bleibt für Sonnet 5 stehen. Sonnet 5 ist das Ausweichmodell bei Ablehnungen (Abschnitt C3).
|
||||
- Zwei Leser: Fable 5.1 als Koordinator (für ihn verbindlich), Opus 5.5 als Koordinator (entscheidet selbst). Sonnet 5.5 selbst entscheidet, ob es einen Punkt übernimmt.
|
||||
|
||||
# Teil A — Was im Vault gilt
|
||||
|
||||
## A1 Effort je Rolle
|
||||
|
||||
| Rolle | Effort | Grund |
|
||||
|---|---|---|
|
||||
| `executer` | `medium` | Katalog-Standard und Doku-Empfehlung für gut spezifizierte Agentenarbeit. Die Messung unten stützt die Wahl nur schwach: `low` fiel bei der strengeren Doku-Probe zweimal durch, `medium` einmal, `high` nie, bei gut 50 % mehr Ausgabe |
|
||||
| `executer`, Abschrift mit typografischen Zeichen | `low` | Regel aus [[AI/Regelwerk/codeworkflow|codeworkflow.md]], Schritt 3; auf 5.5 gleich treu wie `high` |
|
||||
| `recherche` | `medium` | nicht neu gemessen; Doku: `medium` für mehrstufige Werkzeugarbeit, `low` für einfache Subagenten |
|
||||
|
||||
Messung vom 2026-09-29, je Stufe zwei Kopfsitzungen `claude -p --model claude-sonnet-5-5 --effort <stufe>` mit dem Executer-Prompt als `--append-system-prompt`, Effort und Modell aus dem Transkript belegt, Mediane vom `pruefer` nachgerechnet:
|
||||
|
||||
| Prüfstand | Ergebnis | Ausgabetokens je Lauf (Median) | Dauer |
|
||||
|---|---|---|---|
|
||||
| Abschrift (Prüfstand vom 2026-09-23) | alle sechs Läufe gleich: zwei Dateien byte-gleich, eine Abweichung — die Escape-Folge `\u2028` kam als echtes Zeichen an | `low` 2.650, `medium` 2.700, `high` 3.290 | 28–35 s |
|
||||
| Doku: Anleitung + Hintergrund aus zehn Dossier-Aussagen, bewertet von `score_doku.py` (elf Fakten, Kommentar je Codeblock, keine Begründung in der Anleitung, keine Textblöcke, keine fremden Zahlen) | Bewerter: alle sechs ohne Befund. Strengere Probe des `pruefer`: einen echten Wikilink auf den Hintergrund setzten nur `high` 2 von 2, `medium` 1 von 2, `low` 0 von 2 | `low` 3.000, `medium` 3.370, `high` 5.070 | `low` 23 s, `medium` 26 s, `high` 38–48 s |
|
||||
|
||||
Was die Messung nicht belegt:
|
||||
|
||||
- Beide Prüfstände sind klein. Lange Aufgaben mit vielen Dateien und Ermessen sind nicht gemessen.
|
||||
- Die Kosten je Lauf (0,17–0,32 $) streuen nach Cache-Treffern der parallel gestarteten Läufe, nicht nach Stufe. Vergleichbar sind nur die Ausgabetokens.
|
||||
- Die Abschrift ist auf allen Stufen gleich — gleich fehlerhaft an derselben Stelle. Das liegt an der Schreibschicht, nicht am Modell (Abschnitt A4).
|
||||
- Laut Doku prüft Sonnet 5.5 auf `low` Änderungen manchmal nicht nach. Auf `low` **und** `medium` hält es bei langen Aufgaben eher an und fragt zurück (B2).
|
||||
- Gemessen in Kopfsitzungen ohne Vault-`CLAUDE.md`, nicht als Subagent mit Frontmatter. Gemessen wurden Vorfassungen von `executer.md` (ohne den Stoppsatz aus A2) und `schreibstil.md`.
|
||||
- **Nebenfund: Das Referenzdokument wird abgeschrieben, auch seine Schwächen.** Die damalige Fassung zeigte statt eines Links die Behelfsform „→ Hintergrund (Wikilink auf …)"; zwei Läufe (`low`, `medium`) übernahmen sie wörtlich, ein dritter (`low`) setzte ebenfalls keinen Link. Die Fassung ist seitdem korrigiert.
|
||||
- `recherche` ist auf 5.5 nicht gemessen.
|
||||
|
||||
- Die schwachen Link-Ergebnisse bei `low` und `medium` hängen mit dieser Behelfsform zusammen. Mit der korrigierten Vorlage ist die Probe nicht wiederholt.
|
||||
- **Offen für Pascal:** Der Alias hat umgestellt, bevor gemessen war. Die Messung trägt `medium` nur schwach. Bleiben beim Alias (Sonnet 5.5) oder `model: claude-sonnet-5` in `executer.md` und `recherche.md` festsetzen — entscheidet Pascal.
|
||||
|
||||
Rohwerte je Lauf: [[AI/secondbrain/regelwerk-memory/2026-09-29-sonnet-5-5-messung|Messbericht Sonnet 5.5]].
|
||||
|
||||
## A2 Auftragsvorlage `executer`
|
||||
|
||||
```text
|
||||
Taskdatei: <absoluter Pfad>
|
||||
Zieldateien (nur diese anlegen oder ändern): <Liste>
|
||||
Verbote: kein git commit; keine anderen Dateien; ein Widerspruch im Plan wird gemeldet, nicht still aufgelöst.
|
||||
Prüfbefehl: <Befehl> → <erwartetes Ergebnis ohne gepflegte Zahlen>
|
||||
Wenn die beauftragte Arbeit erledigt und geprüft ist: aufhören und berichten. Keine ungefragten Tests, Dateien oder Doku; Vorschläge ans Ende des Berichts.
|
||||
Schlussbericht im Format deiner Agentendatei.
|
||||
```
|
||||
|
||||
Warum so, und warum das Tokens spart:
|
||||
|
||||
- **Kein Kontext im Auftrag.** Alles Fachliche steht in der Taskdatei. Ein nacherzählter Plan wird doppelt gelesen.
|
||||
- **Stoppsatz.** Laut Doku ergänzt Sonnet 5.5 auf jeder Stufe ungefragt Tests, Doku und Hilfsdateien. Der Satz ist die gekürzte Fassung des Doku-Absatzes (Abschnitt B2).
|
||||
- **Prüfbefehl mit Erwartung.** Laut Doku meldet 5.5 auf `low` teils ohne echten Test „fertig". Mit Befehl und Erwartung im Auftrag fällt eine Fertigmeldung ohne Lauf beim Wiederholen durch den Koordinator auf.
|
||||
- **Ein Auftrag, der für sich steht,** geht an einen frischen Agenten, nicht per Fortsetzung (Messung in [[AI/Regelwerk/codeworkflow|codeworkflow.md]], Schritt 5).
|
||||
|
||||
## A3 Auftragsvorlage `recherche`
|
||||
|
||||
```text
|
||||
Frage: <genau eine Frage oder ein eng umrissener Fragenblock>
|
||||
Suchraum: <Vault-Pfade | Web | Programmdatei>; nicht: <Ausschlüsse>
|
||||
Prüfe Einzelheiten, die sich seit deinem Training geändert haben können, mit der Suche, auch wenn du dir sicher bist.
|
||||
Belege: je Aussage Fundstelle, selbst geöffnet; Unbelegtes unter „Offen".
|
||||
Ausgabe: <Tabellenkopf>; als Schlussantwort vollständig, ohne Vorrede.
|
||||
```
|
||||
|
||||
- **Eine Frage je Agent.** Mehrere Agenten parallel statt einer mit fünf Themen.
|
||||
- **Suchsatz aus der Doku** (Abschnitt B2): 5.5 antwortet sonst teils aus dem Trainingswissen.
|
||||
- **Gezielt lesen:** `Grep` mit Zeilennummern, `Read` mit `offset`/`limit`. Bei Sonnet-Agenten treibt das Lesen die Kosten, nicht der Effort ([[AI/Regelwerk/codeworkflow|codeworkflow.md]], „Effort je Rolle").
|
||||
|
||||
## A4 Prüfpunkte statt Garantie
|
||||
|
||||
„Garantiert richtig" gibt es nicht. Es gibt Stellen, an denen ein Fehler auffällt:
|
||||
|
||||
| Fehlerquelle | Prüfpunkt |
|
||||
|---|---|
|
||||
| Plan lückenhaft | Plankritik bei Code, `pruefer` bei Doku ([[AI/Regelwerk/codeworkflow|codeworkflow.md]]) |
|
||||
| Executer weicht still ab | Byte-Vergleich Plan gegen Datei (Code); mechanische Prüfung und Aussagenliste (Doku) |
|
||||
| Escape-Folgen und unsichtbare Zeichen | Byte-Vergleich; die Schreibschicht verlor die Folge am 2026-09-23 in 8 von 8 Läufen (Haiku, Sonnet 5) und am 2026-09-29 in 6 von 6 (Sonnet 5.5) — auch beim Koordinator selbst beim Schreiben dieser Datei |
|
||||
| Fertigmeldung ohne Test | Prüfbefehl im Auftrag; der Koordinator wiederholt ihn selbst |
|
||||
| Aussage ohne Quelle | Quellenpflicht im Recherche-Auftrag; `pruefer` zieht Stichproben |
|
||||
| Ablehnung durch den Cyber-Schutz | Bericht führt sie als abgelehnt; bei Bedarf das Modell im Transkript prüfen (C3) |
|
||||
|
||||
# Teil B — Verhalten und Prompt-Muster
|
||||
|
||||
Aus „Prompting Claude Sonnet 5.5". Die Seite behandelt Antwortlänge, Code-Review, Dokumentlänge und wörtliches Befolgen **nicht**. Ob die Aussagen aus [[AI/Regelwerk/sonnet-5|sonnet-5.md]] dazu weiter gelten, ist ein Rückschluss, kein Beleg.
|
||||
|
||||
## B1 Effort und Thinking
|
||||
|
||||
- Die Stufen sind neu geeicht: dieselbe Stufe erzeugt nicht dieselbe Menge Denken wie bei Sonnet 5. Die Doku rät zu einem frischen Durchlauf über alle Stufen, statt Werte zu übernehmen.
|
||||
- Ab `medium` denkt 5.5 kurz vor fast jeder Antwort, auf `low` bei einfachen Anfragen meist nicht.
|
||||
- Eine Anweisung im System-Prompt, weniger zu denken, wirkt laut Doku nicht verlässlich. Wer weniger Denken will, senkt den Effort.
|
||||
- `xhigh` laut Doku für lange agentische Aufgaben über 30 Minuten; `xhigh` und `max` nur, wo Evals einen Gewinn zeigen.
|
||||
- Denken zählt zu `max_tokens`, auch wenn der Inhalt nicht zurückkommt.
|
||||
|
||||
## B2 Initiative und Umfang
|
||||
|
||||
| Verhalten | Wann | Gegenmittel laut Doku |
|
||||
|---|---|---|
|
||||
| Fragt zwischendurch nach | `low`/`medium`, lange Agentenaufgaben | höherer Effort, oder: „Keep working until everything the user asked for is done, and only stop to ask when you can't go on without the user or before a risky step." |
|
||||
| Ergänzt ungefragt Tests, Doku, Hilfsdateien | jede Stufe, mit höherem Effort mehr | „When the work the user asked for is done and checked, stop and report. Don't add features, tests, files, docs or refactors that weren't asked for." |
|
||||
| Startet eigene Review-Runden, teils mit Subagenten | `xhigh`/`max` | „…don't launch reviewer sub-agents unless the user asked for a review." Laut Hersteller bei `max` ein Drittel weniger Kosten, Qualität gleich |
|
||||
| Baut bei offenen Anfragen gleich etwas | „zeig, was du kannst" | „When the user asks for ideas, options or a plan, give them that and stop." |
|
||||
| Meldet auf `low` ohne echten Test „fertig" | `low`, Coding | Absatz „run a real check that exercises the change before reporting it done" |
|
||||
| Antwortet aus Trainingswissen statt zu suchen | Chat, Wissensarbeit | sperrende Sätze („minimize tool calls") entfernen, Suchsatz aus A3 |
|
||||
|
||||
## B3 Fortschritt und Nachrichten
|
||||
|
||||
- Vorgaben wie „alle Befunde bis zur Schlussantwort zurückhalten" entfernen; gewünschte Meldepunkte im System-Prompt benennen.
|
||||
- Text zwischen Werkzeugaufrufen, länger als ein bis zwei Sätze, kommt als `thinking`-Block. Beim Standard `display: "omitted"` ist sein Text leer; ein eigener Client zeigt dann nichts an.
|
||||
- Nutzertext nie in ein `tool_result` legen: 5.5 hält ihn dort teils für Prompt-Injection.
|
||||
- Werkzeugnamen gelegentlich in falscher Schreibweise (`bash` statt `Bash`); ein eigenes Harness akzeptiert eindeutige Treffer.
|
||||
|
||||
## B4 JSON und mehrstufiges Rechnen
|
||||
|
||||
- Auf `low`/`medium` antwortet 5.5 bei mehrstufigen Rechnungen oft ohne Denken. Abhilfe: „Think the problem through before you answer." am Ende des System-Prompts, oder höherer Effort.
|
||||
- Bei Structured Outputs auf `low`/`medium` kann das Denken selten bis `max_tokens` laufen: `stop_reason: "max_tokens"` als gescheitert behandeln.
|
||||
|
||||
# Teil C — Spezifikation und API
|
||||
|
||||
## C1 Spezifikation
|
||||
|
||||
| Punkt | Wert | Quelle |
|
||||
|---|---|---|
|
||||
| Modell-ID | `claude-sonnet-5-5`, veröffentlicht 2026-09-28 | Doku, Übersicht |
|
||||
| Kontext / Ausgabe | 1M / 128k (Doku, Katalog); Batch bis 300k mit `output-300k-2026-03-24` (nur Doku) | Doku; Katalog |
|
||||
| Preis je Mio. Tokens | 2 $ Eingabe, 10 $ Ausgabe, 0,20 $ Cache-Lesen (wie Sonnet 5) | Doku; Katalog `tier_2_10` |
|
||||
| Cache-Mindestlänge | 512 Tokens (Sonnet 5: 1.024) | Doku |
|
||||
| Wissensstand | Juni 2026 | Doku; Katalog |
|
||||
| Standard-Effort | API: `high`; Claude Code: `medium` | Doku; Katalog `default_effort` |
|
||||
| Kostenfaktoren je Stufe | im Katalog nicht hinterlegt (Sonnet 5: `xhigh` 2,41×, `max` 5,59× von `high`) | Katalog |
|
||||
| Tokenizer | wie Sonnet 5; gegenüber Sonnet 4.6 etwa 30 % mehr Tokens | Doku |
|
||||
| Zero Data Retention | für das Modell keine Aussage gefunden | offen |
|
||||
|
||||
## C2 API-Brüche gegenüber Sonnet 5
|
||||
|
||||
- `thinking: {"type": "disabled"}` liefert 400. Niedrigste Einstellung: `{"type": "between_tools"}`, nur bei `low`/`medium`/`high`.
|
||||
- `budget_tokens` liefert 400.
|
||||
- `tool_choice` mit `any` oder `tool` liefert 400. Ersatz: `auto` plus `strict: true` oder Structured Outputs.
|
||||
- `temperature`, `top_p`, `top_k` abseits des Standards liefern 400. Prefill liefert 400.
|
||||
- Thinking-Blöcke sind modellgebunden und kontogebunden; Konversation nur anhängen, nie ändern ([[AI/Regelwerk/api-mechanik|api-mechanik.md]]).
|
||||
- Computer Use auf der Claude-API nur mit `computer_toolset_20260801`.
|
||||
- Neu gegenüber Sonnet 5 laut Doku: Effort je Nachricht, System-Nachrichten mitten im Gespräch, Kompaktierung auf Abruf, Werkzeuge je Nachricht (alle Beta).
|
||||
- **Widerspruch zum CLI-Katalog 2.1.285:** Dort führt auch `claude-sonnet-5` die Fähigkeit `mid_conv_system`, und `claude-sonnet-5-5` führt `mid_conv_tool_change` nicht. Welche Seite für die API gilt, ist offen.
|
||||
|
||||
## C3 Ablehnungen und Ausweichmodell
|
||||
|
||||
- Fünf Kategorien in `stop_details`: cyber, bio, frontier_llm, reasoning_extraction, general_harms.
|
||||
- Das Ausweichen (Beta) wiederholt laut Doku cyber und frontier_llm auf **Sonnet 5**. Der Katalog von Claude Code 2.1.285 führt dieselbe Zuordnung; der CLI-eigene Ausweichweg im Programm löst dagegen auf ein Opus-Modell auf (am minifizierten Abbild gelesen, nicht gelaufen). Welcher Weg in einer Sitzung greift, ist offen.
|
||||
- Folge für den Vault: Ein Härtungs- oder Scan-Task kann still auf einem anderen Modell weiterlaufen. Wo das zählt, das Feld `model` im Transkript ansehen.
|
||||
- Anweisungen, die Begründung in der Antwort auszugeben, laden `reasoning_extraction`-Ablehnungen ein.
|
||||
- Umgang mit Ablehnungen im Executer: [[AI/Regelwerk/sonnet-5|sonnet-5.md]], B4 — unverändert.
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [[CLAUDE|↑ Claude.md (Stamm)]] — Rollentabelle
|
||||
- [[AI/Regelwerk/codeworkflow|codeworkflow.md]] — Standardschleife, Effort je Rolle
|
||||
- [[AI/Regelwerk/sonnet-5|sonnet-5.md]] — Vorgänger, Ausweichmodell, Cyber-Schutz
|
||||
- [[AI/Regelwerk/opus-5|opus-5.md]] — Planer und Prüfer
|
||||
- [[AI/Regelwerk/api-mechanik|api-mechanik.md]] — Mechanik für eigene API-Integrationen
|
||||
- Quellen (abgerufen 2026-09-29): https://platform.claude.com/docs/en/models/sonnet-5-5/whats-new-sonnet-5-5, https://platform.claude.com/docs/en/models/sonnet-5-5/overview, https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5, https://platform.claude.com/docs/en/build-with-claude/effort, https://platform.claude.com/docs/en/models/sonnet-5-5/migration-guide
|
||||
@@ -5,12 +5,14 @@ title: Prompting-Hinweise für Claude Sonnet 5
|
||||
summary: Verhaltensunterschiede und Prompt-Muster von Claude Sonnet 5 (Teil A) sowie Spezifikation, API-Brüche, Tokenizer, Cyber-Schutz, ZDR-Fähigkeit (Teil B) aus der Anthropic-Doku. Betrifft den Executer und die Recherche-Agenten.
|
||||
tags: [regelwerk, modelle, sonnet, prompting]
|
||||
created: 2026-09-05
|
||||
updated: 2026-09-23
|
||||
updated: 2026-09-29
|
||||
source: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-sonnet-5
|
||||
---
|
||||
|
||||
# Prompting-Hinweise für Claude Sonnet 5
|
||||
|
||||
> **Seit 2026-09-29 laufen `executer` und `recherche` auf Sonnet 5.5** (Alias `sonnet` in Claude Code 2.1.284+). Maßgeblich für sie ist [[AI/Regelwerk/sonnet-5-5|sonnet-5-5.md]]. Diese Datei bleibt für Sonnet 5 als Ausweichmodell bei Ablehnungen, für den Cyber-Schutz (B4) und für das, was die Sonnet-5.5-Doku nicht neu behandelt. Der Geltungsbereich unten beschreibt den Stand bis 2026-09-28.
|
||||
|
||||
> **Geltungsbereich.** Diese Datei beschreibt, wie sich **Claude Sonnet 5** verhält und wie man Aufträge an es formuliert. Im Vault läuft Sonnet 5 als `executer` (Effort `medium`), als Rechercheagent `recherche` (Effort `medium`, seit 2026-09-23 statt `general-purpose`) und im eingebauten `Explore`. Zwei Leser: (1) **Fable 5.1**, wenn es als Koordinator einen Auftrag an einen Sonnet-Subagenten schreibt — dann ist das hier verbindlich für die Formulierung. (2) **Sonnet 5 selbst** — es arbeitet nach seinen eigenen Optimierungen und entscheidet selbst, ob es einen Punkt übernimmt. Die Rollentabelle im Stamm ([[CLAUDE|Claude.md]]) bleibt unverändert.
|
||||
> Angeordnet am 2026-09-05. Quellen: „Prompting Claude Sonnet 5" (Teil A), „What's new in Claude Sonnet 5" (Teil B) und der Migrationsleitfaden (Teil C), alle abgerufen am 2026-09-05. Aussagen stammen aus der Doku, nicht aus eigener Messung.
|
||||
|
||||
|
||||
Reference in new issue
Block a user