Harness Designer v4
Prinzip: "Gib dem Agenten eine Karte, kein 1000-seitiges Handbuch." — OpenAI Harness Engineering Prinzip: "Lass den Erzeuger nicht seine eigene Arbeit bewerten." — Anthropic GAN-Inspired Harness
Die 5 Säulen des Harness-Designs
Jeder von dieser Skill erstellte Arbeitsbereich muss die folgenden fünf Säulen erfüllen:
| Säule | Kernfrage | Prinzip |
|---|---|---|
| Progressive Disclosure | Kann der Agent nur das Nötigste sehen? | Inhaltsverzeichnis (~100 Zeilen) → Pointer → tiefergehende Dokumente |
| Mechanische Durchsetzung | Werden Regeln mechanisch erzwungen? | Dokumentation allein reicht nicht, um Konsistenz zu gewährleisten |
| Feedback-Loop | Ermöglicht ein Fehler strukturelle Verbesserungen? | Nicht „mehr Anstrengung“, sondern „welche Fähigkeit hat gefehlt“ |
| Sitzungskontinuität | Ist der Übergang zwischen Sitzungen sauber? | progress + feature-status + git |
| Entropiemanagement | Bleibt die Struktur über die Zeit erhalten? | Regelmäßige Bereinigung, Prüfung der Dokumentfrische |
Beziehung der beiden Schichten
┌─────────────────────────────────────────────────────┐
│ SCHICHT 1: Meta (Aufgabe dieser Skill) │
│ │
│ Planer ──→ Generator ──→ Evaluator │
│ ↑ (unidirektional sequenziell, keine Rückverweise) │
│ └──── Feedback bei Mängeln ─────────────┘ │
│ │
│ Zweck: Entwerfen, Erstellen und Prüfen der │
│ Arbeitsbereichsstruktur selbst │
└─────────────────────────┬───────────────────────────┘
│ Struktur nach Genehmigung abgeschlossen
▼
┌─────────────────────────────────────────────────────┐
│ SCHICHT 2: Betrieb (Aufgabe des fertigen │
│ Arbeitsbereichs) │
│ │
│ ┌ Initialisierer (nur für erste Ausführung) ─→ Umgebungseinrichtung │
│ │ │
│ └ Betriebsagent (wiederholte Ausführung): │
│ Agent-A ─┐ │
│ Agent-B ─┼──→ Vorsitzender Synthese ──→ Endprodukt│
│ Agent-C ─┘ (unabhängig parallel, kein Austausch)│
│ │
│ Zweck: Tatsächliche Arbeit (Analyse, │
│ Entscheidungsfindung, Berichte usw.) │
└─────────────────────────────────────────────────────┘
SCHICHT 1: Meta – Der Harness-Design-Prozess
L1 Agententypen (unidirektional sequenziell, keine Rückverweise)
Die Ergebnisse werden in der Reihenfolge Planer → Generator → Evaluator weitergegeben. Jeder Agent erhält nur die Ergebnisse des vorherigen Schrittes und sieht die Ergebnisse des nächsten Schrittes nicht im Voraus.
Planer
Analysiert die Benutzerabsicht und entwirft die Harness-Struktur.
- Eingabe: Benutzeranforderungen (gesammelt durch Fragen)
- Ausgabe: Agentenzusammenstellung + Ordnerstrukturentwurf + Bewertungskriterienvorschlag
- Einschränkung: Entwirft, bevor er Generator- und Evaluator-Ergebnisse sieht
Generator
Setzt den Plan des Planers in tatsächliche Dateien um.
- Eingabe: Genehmigter Plan des Planers
- Ausgabe: Tatsächliche .md/.json-Dateien (vollständige Liste der Ergebnisse siehe Phase 2)
- Einschränkung: Baut, ohne die Evaluator-Kriterien im Voraus zu sehen
Evaluator
Prüft die Ergebnisse des Generators unabhängig.
- Eingabe: Generierte Dateien des Generators + Bewertungskriterien des Planers
- Ausgabe: Punktzahl basierend auf den 5 Säulen + funktionale Prüfergebnisse + Verbesserungsfeedback
- Einschränkung: Betrachtet nur die Ergebnisse, nicht die Absicht des Generators
L1 Phase 0: Pattern Match – Referenz auf harness-100 (neu v4.1)
„99 % eines guten Designs hat bereits jemand gemacht. Finde es und passe es an.“
Vor der Discovery aus dem Fundus von harness-100 (https://github.com/revfactory/harness-100, Apache-2.0) das ähnlichste, geprüfte Exemplar suchen und als Referenz verwenden. Nicht-Entwickler werden an die harness-starter-workspace-Skill weitergeleitet.
Ziel-Exemplare (73 Arbeitsbereichsdomänen)
- Content #01–15, Business #43–55, Education #56–65, Legal #66–72, Lifestyle #73–80, Docs #81–88, Operations #89–95, Specialized #96–100
Phase 0 Ablauf
- Aus der 1–2-Satz-Anfrage des Benutzers Domain-Keywords extrahieren
- Die 3 besten Kandidaten aus den 73 Exemplaren vorschlagen + Benutzerbestätigung einholen
- Die ausgewählte Exemplarnummer im Feld
reference_exemplarder Datei_workspace/00_input.mdnotieren - Bei einer Matching-Ähnlichkeit < 0,5 → Rückfall in den freien Entwurfsmodus (Fortsetzung mit der bestehenden Phase 1)
Ergebnisse von Phase 0 in nachfolgende Schritte einfließen lassen
- Planer: Die Zusammenstellung von 4–5 Spezialisten + Reviewer des Exemplars als Grundlage verwenden
- Generator: Das Gerüst des Exemplars als Ausgangspunkt, Nummernkonvention der Dateien
_workspace/NN_*.mderzwingen - Evaluator: Die 8 Qualitätsstandards des Exemplars (Agent Team Mode / Domain Expertise / Structured Outputs / Dependency DAG / Error Handling / Scale Modes / Test Scenarios / Trigger Boundaries) als Rubrik verwenden
Pattern Fidelity (qualitative Bewertung, beschränkt auf Phase 0)
Wird nicht in die automatische Bewertung der 5 Säulen einbezogen. Wird in Phase 0 beim Matching von Exemplaren qualitativ bewertet.
Die 8 Qualitätsstandards des in Phase 0 ausgewählten harness-100-Exemplars (Agent Team Mode / Domain Expertise / Structured Outputs / Dependency DAG / Error Handling / Scale Modes / Test Scenarios / Trigger Boundaries) werden unabhängig von der Evaluator-Bewertung geprüft.
- Anwendungszeitpunkt: Einmalig in Phase 0 (Exemplarauswahl) und einmalig bei der Berichterstattung nach bestandenem Evaluator
- Keine Punktevergabe: Keine Einbeziehung in die Bewertung der 22 Punkte der 5 Säulen
- pillar-weight: Nur Anpassung der Gewichtung der 5 Säulen möglich. Pattern Fidelity unterliegt keiner Gewichtung
Reviewer als Pflicht
Die Betriebsschicht muss einen Reviewer-Agenten (Cross-Validation-Rolle) enthalten. Hinzufügen eines Reviewer-Check-Schrittes zum bestehenden Vorsitzenden-Synthese-Modell.
Trigger Boundaries (should + NOT)
Planer/Generator müssen in die erstellte orchestrator skill.md zwingend einen Abschnitt should-NOT trigger aufnehmen.
Domain-Framework-Injektion
Automatische Injektion von bewährten Frameworks pro Kategorie:
- Content: AIDA, Pattern Interrupt, CURVE formula
- Business: BMC, TAM/SAM/SOM, Porter's 5 Forces, RICE, Van Westendorp PSM
- Education: Bloom's Taxonomy, ADDIE, CEFR, SM-2, Toulmin Model
- Legal: IRAC, MQM, GDPR/PIPA, IPC/CPC
- Lifestyle: BMR/TDEE, ACSM Guidelines, Compound Interest
- Docs: Diataxis, PREP, STAR, MADR, SemVer
- Operations: SIPOC/RACI, 4C Framework, SMART, NPS/CSAT, BARS
- Specialized: GHG Protocol, Cap Rate/IRR, IMRaD, Georgia-Pacific, Double Materiality
L1 Phase 1: Discovery – Planer in Aktion
Die Discovery besteht aus 4 Stufen von Fragen. Jede Stufe wird der Reihe nach durchlaufen, wobei die Folgefragen basierend auf den Antworten des Benutzers verzweigen. Nach Erhalt einer Antwort auf eine Stufe wird zur nächsten Stufe übergegangen. Fragen Sie nicht alles auf einmal.
1-1. Stufe 1 – Zweck und Kontext (WARUM / WER)
Verstehen Sie den Grund für die Existenz dieses Arbeitsbereichs, nicht seine Struktur.
W1. Welches Problem soll dieser Arbeitsbereich lösen?
(Welche Entscheidung/Analyse/Beurteilung funktioniert gerade nicht gut?)
W2. Wer verwendet ihn?
(Nur Agenten / Agenten + Menschen / Menschen konsumieren die Ergebnisse)
→ Nachfrage: Wie hoch ist die Domain-Expertise des Benutzers?
W3. Was sind die Erfolgskriterien für diesen Arbeitsbereich?
(Welches Ergebnis bedeutet „gut gemacht“?)
W4. Gibt es einen ähnlichen bestehenden Prozess?
(Ersetzt er einen / wird er neu erstellt)
→ Nachfrage [Ersetzt]: Was ist das größte Problem mit dem bestehenden Prozess?
→ Nachfrage [Neu]: Gibt es ein System, das als Benchmark dient?
Verzweigung der Folgefragen:
- Bei W2 „Menschen konsumieren Ergebnisse“ → „Welche Position/Rolle hat die Person, die die Ergebnisse erhält? Welches Format wird bevorzugt?“
- Bei vagen Antworten zu W3 → „Welches konkrete Ergebnis würde als Erfolg gelten?“
1-2. Stufe 2 – Ergebnisse und Struktur (WAS)
Was wird erstellt, welche Perspektiven sind nötig.
S1. Was ist das endgültige Ergebnis?
(Bericht / Entscheidungsprotokoll / Analysebericht / Plan)
S2. Was ist das sich wiederholende Kernarbeitsmuster?
(Eingabe → Analyse → Entscheidung → Aufzeichnung → Wissensaufbau)
S3. Wie viele Perspektiven/Rollen werden benötigt? Welchen Charakter hat jede?
(z.B. optimistisch/pessimistisch/Daten/Erfahrung/Regulierung – sie stehen in Konflikt/ergänzen sich)
→ Nachfrage: Gibt es eine Priorität unter den Perspektiven? Sind sie gleichwertig?
S4. Wird ein Vorsitzender (Syntheserolle) benötigt?
(Zuständig für die Hauptsitzung / separater Agent / nicht benötigt)
→ Nachfrage [Benötigt]: Wie ist die Agentenmodellkonfiguration?
→ Nach Referenz in references/agent-archetypes.md vorschlagen
S5. Welche Form hat die Eingabe?
(Texteingabe / Datei-Upload / URL / gemischt)
S6. Welche Ausgaben sollen erhalten bleiben?
(Sitzungsdateien / Entscheidungsprotokolle / Wissensaufbau / deep-research)
Verzweigung der Folgefragen:
- Bei S3 mit 5 oder mehr Perspektiven → „Können diese Perspektiven in Gruppen zusammengefasst werden? Sequentiell oder parallel?“
- Bei S4 mit „separater Agent“ → „Was ist der Entscheidungsrahmen des Vorsitzenden? Go/Pivot/No-Go?“
1-2.5. Stufe 2.5 – Wissensmanagement (WISSEN) [Bedingt]
Wiki-Option für Multi-Agenda-Forschungsarbeitsbereiche, um bestehende Forschung systematisch zu referenzieren. Bei Single-Agenda- oder Nicht-Forschungsarbeitsbereichen überspringen.
K1. „Muss bei der Bearbeitung mehrerer Agenden (Forschungsthemen) auf bestehende Forschung in nachfolgenden Studien Bezug genommen werden?“
→ „Nein“ → Kein Wiki. Weiter zu Stufe 3.
→ „Ja“ → Weiter zu K2.
K2. Installation der /graphify-Skill prüfen (automatische Erkennung)
- Existenz von ~/.claude/skills/graphify/ oder .claude/skills/graphify/ prüfen
- Installiert → Weiter zu K3.
- Nicht installiert → Erklärung bereitstellen:
┌─────────────────────────────────────────────────┐
│ Das Wiki wird mit der /graphify-Skill erstellt. │
│ Ohne diese Skill kann kein Wiki erstellt werden.│
│ │
│ Was ist /graphify? │
│ - Analysiert Dokumente/Berichte und erstellt │
│ Wissensgraphen │
│ - Erkennt und visualisiert automatisch │
│ Verbindungen zwischen Konzepten │
│ - Erstellt automatisch Community-basierte │
│ Wiki-Dokumente │
└─────────────────────────────────────────────────┘
„Möchten Sie graphify installieren?“
- Globale Installation (~/.claude/skills/) [Verwendung in allen Projekten]
- Projektinstallation (.claude/skills/) [Nur in diesem Projekt]
- Nicht installieren → ⚠️ „Die Wiki-Funktion wird deaktiviert.
Der Ordner 45-wiki/ wird erstellt, bleibt aber leer.
Sie kann später nach der Installation von /graphify
mit /wiki-update erstellt werden.“
→ Nur Wiki-Struktur enthalten, deaktiviert. Weiter zu Stufe 3.
K3. „Wo soll das Wiki-Repository abgelegt werden?“
- Innerhalb des Projekts (45-wiki/) [Standard]
- Externer Pfad
K4. „Soll bei Beginn einer neuen Recherche automatisch im Wiki navigiert werden?“
- Automatische Navigation + Referenz nach Benutzerzustimmung [Standard]
- Nur manueller Aufruf (/wiki-ref) erlaubt
Zusätzliche Ausgabe des Planers (Wiki-bezogen):
wiki_enabled: true/falsewiki_location: "45-wiki/" oder benutzerdefinierter Pfadwiki_auto_ref: true/falsegraphify_installed: true/falsegraphify_scope: "global" | "project" | "none"
⚠️ Schutz der Unabhängigkeit der Wiki-Referenz:
- Keinesfalls Wiki-Inhalte in Agenten der Phase A (unabhängige Recherche) einspritzen
- Nur in Phase B (Creative Thinker) / Phase C (Vorsitzender) ist eine Referenz nach Benutzerzustimmung erlaubt
- Bei Referenzen nur Frameworks/Methodologien/Datenpunkte übermitteln, keine Schlussfolgerungen
- In den Ergebnissen müssen
wiki_ref,ref_approved_byundref_approval_dateprotokolliert werden
1-2.6. Stufe 2.6 – Änderungshistorie des Ablaufs (FLOW HISTORY) [Optional]
Empfohlen für Projekte, bei denen eine Verbesserung des Workflows im Laufe der Zeit erwartet wird. Kann bei einmaligen Analysen oder einmaligen Projekten übersprungen werden.
F1. „Soll eine Historie der Änderungen oder Verbesserungen des Workflows aufgezeichnet werden?“
Verwendung:
- Rückblick auf die Verbesserungshistorie des Projekts (Warum hat es sich geändert?)
- Grundlage für einen Rollback auf eine frühere Version
- Referenz für die Planung ähnlicher zukünftiger Projekte
※ Nicht zum Lesen in jeder neuen Sitzung gedacht.
Nur beim Ändern, Zurücksetzen oder Übertragen eines Ablaufs referenzieren.
→ „Nein“ → Kein Ordner 05-flow-history/. Weiter zu Stufe 3.
→ „Ja“ → Weiter zu F2.
F2. „Soll der erste Build (v1) automatisch als Datensatz change 0001 aufgezeichnet werden?“
- Standard: Ja (Die Antworten aus der Planer-Discovery bleiben als Entwurfsbegründung erhalten)
- Nein → Nur CHANGELOG erstellen und beim ersten Ändern manuell aufzeichnen
Grundsätze der Verwaltung der Ablaufhistorie (nach Erstellung im Betrieb):
Diese Historie zeichnet nur Änderungen am Workflow-System (Regeln, Verfahren, Tools, Prompts, Befehle, Skripte, CLAUDE.md) auf. Ergebnisse, die das System erzeugt (Forschungsergebnisse, Berichte, Analysen, Agenda-Einträge), sind nicht aufzuzeichnen.
Unterscheidungskriterium: „Würde das nächste ausgeführte Ergebnis anders sein, wenn diese Änderung nicht vorgenommen worden wäre?“
→ Anders = Systemänderung = aufzeichnen / Nicht anders = Ergebnis = keine Aufzeichnung erforderlich
Details: 00-system/protocols/flow-change-protocol.md
Zusätzliche Ausgabe des Planers (Flow-History-bezogen):
flow_history_enabled: true/falseflow_history_initial_record: true/false(Antwort auf F2)
1-3. Stufe 3 – Umgebung und Werkzeuge (WIE)
In welcher Umgebung und wie wird es betrieben?
H1. Welche KI-Tools werden verwendet?
(Claude Code / Desktop Claude / andere)
→ Die Art des Harnesses hängt vom Tool ab
H2. Ist Sitzungskontinuität erforderlich?
(Einmalige Analyse / Langzeitprojekt / Multi-Sitzung)
→ Bei „Langzeit“ Sitzungsübergabeergebnisse einbeziehen
H3. Wie ist die Agentenmodellkonfiguration?
→ Aktuelles Claude-Modell über Websuche prüfen und vorschlagen
→ Modellnamen nicht hartcodieren. Benutzer entscheidet immer.
H4. Wie hoch ist der Autonomiegrad des Agenten?
(Mensch prüft jedes Mal / Agent entscheidet autonom + Bericht / Voll autonom)
Verzweigung der Folgefragen:
- Bei H2 „Langzeit“ → „Erwartete Anzahl von Sitzungen? Ist Wissensaufbau wichtig?“
- Bei H4 „Voll autonom“ → „Was sind die Eskalationskriterien? In welchen Situationen sollte der Mensch gefragt werden?“
1-4. Stufe 4 – Qualität und Bewertungskriterien (QUALITÄT / EVALUIEREN)
Verstehen Sie die Werte, die dem Benutzer wichtig sind, und vereinbaren Sie Bewertungskriterien.
E1. Was sind die wichtigsten Qualitätsattribute dieses Arbeitsbereichs? (Top 3 auswählen)
□ Analysetiefe (nicht oberflächliche Einsichten)
□ Unabhängigkeit (unabhängige Analyse ohne Einfluss zwischen Agenten)
□ Quellenangabe (evidenzbasierte Schlussfolgerungen)
□ Konsistenz (gleichbleibende Qualität über Sitzungen hinweg)
□ Schnelle Reaktion (kurze Bearbeitungszeit)
□ Skalierbarkeit (einfaches Hinzufügen von Agenten/Rollen)
□ Dokumentation (Nachvollziehbarkeit von Prozess und Ergebnissen)
□ Benutzerzugänglichkeit (auch Nicht-Experten verstehen die Ergebnisse)
E2. Gibt es zukünftige Erweiterungspläne?
(Keine / Hinzufügen von Perspektiven / Anwendung auf andere Domänen / Stärkere Automatisierung)
E3. Was darf in diesem Arbeitsbereich niemals kompromittiert werden?
(z.B. „Agenten dürfen sich nicht gegenseitig beeinflussen“, „Keine Schlussfolgerungen ohne Quellen“)
E4. Umgekehrt: Was kann anfangs fehlen?
Verzweigung der Folgefragen:
- Bei E1 „Unabhängigkeit“ → „Welches Niveau? Ist auch das Teilen von Ergebnissen verboten? Oder nur die Analyse unabhängig?“
- Antwort von E3 → Wird als Kernerfahrung für die Gewichtung des Evaluators verwendet
1-5. Gewichtungsvereinbarung (nach Stufe 4)
Analysieren Sie die Antworten der Stufen 1–4 und schlagen Sie eine Gewichtung der 5 Säulen vor. Vereinbaren Sie diese mit dem Benutzer und legen Sie sie endgültig fest.
[Prozess zur Gewichtungsvorschlag]
SCHRITT 1. Extrahieren von Keywords aus den Antworten der Stufen 1–4
- „Unabhängigkeit ist ein Muss“ → Mechanische Durchsetzung ↑
- „Langzeitprojekt“ → Sitzungskontinuität ↑, Entropiemanagement ↑
- „Schnelle Reaktion“ → Progressive Disclosure ↑
- „Quellenangabe“ → Mechanische Durchsetzung ↑
SCHRITT 2. Anpassung der Standardgewichtung und Vorschlag
Standardgewichtung (vor Berücksichtigung der Projekteigenschaften):
| Säule | Standard | Anpassungsgrund | Vorschlag |
|------|----------|----------------|----------|
| Progressive Disclosure | 20% | (Änderungsgrund) | ?% |
| Mechanische Durchsetzung | 25% | (Änderungsgrund) | ?% |
| Feedback-Loop | 20% | (Änderungsgrund) | ?% |
| Sitzungskontinuität | 15% | (Änderungsgrund) | ?% |
| Entropiemanagement | 20% | (Änderungsgrund) | ?% |
„Unter Berücksichtigung von [Grund] für dieses Projekt habe ich
die Gewichtung der Säule [Säule] von [Standard]% auf [Vorschlag]% angepasst.
Bitte geben Sie Ihr Feedback oder Änderungswünsche."
SCHRITT 3. Benutzerfeedback einarbeiten
- Zustimmung → Festlegung
- „Erhöhe die Unabhängigkeit“ → Mechanische Durchsetzung erhöhen, andere Säulen verringern, erneut vorschlagen
SCHRITT 4. Endgültige Genehmigung
→ Die vereinbarte Gewichtung anstelle der Standardgewichtung in evaluator-protocol-workspace.md verwenden
1-6. Automatische Musterzuordnung
Auf Basis der Antworten von Stufe 2 wird automatisch ein Ordnermuster empfohlen:
| Benutzerantwort-Keyword | Empfohlenes Muster | Referenz |
|---|---|---|
| Analyse, Investition, Entscheidungsfindung, Beurteilung | Muster A (Analyse/Entscheidungstyp) | folder-patterns.md |
| Bau, Prozess, Leistungsverzeichnis, Bauwesen | Muster B (Bau-/Projektmanagementtyp) | folder-patterns.md |
| Recherche, Content, Bericht | Muster C (Recherche-/Content-Typ) | folder-patterns.md |
| Langzeit-Coding, Automatisierungs-Build | Muster D (Langzeit-Agententyp) | folder-patterns.md |
1-7. Planer-Ergebnisse
① Projektkontextzusammenfassung – Zweck, Benutzer, Erfolgskriterien, Kernbeschränkungen (basierend auf Stufen 1–2) ② Agentenzusammenstellung – Rollen, Charaktere, Modellplatzierung ③ Ordnerstrukturentwurf – Musterzuordnung + Anpassung ④ Sitzungskontinuitätsdesign – Festlegung der Übergabemethode (einmalig / Verwendung von progress.json) ⑤ Erweiterungsstrategie – Designentscheidungen in Vorbereitung auf zukünftige Erweiterungen (basierend auf Stufe 4, E2) ⑥ Bewertungskriterien + vereinbarte Gewichtung – Checkliste der 5 Säulen + Gewichtungstabelle
[Planer abgeschlossen – Benutzerzustimmung erforderlich]
Bitte überprüfen Sie ①–⑥ und teilen Sie uns Änderungen mit.
Nach der Genehmigung beginnt der Generator mit dem Bau.
L1 Phase 2: Bau – Generator in Aktion
Erstellung von Dateien in der folgenden Reihenfolge nach Genehmigung der Planer-Ergebnisse. Der Generator erstellt sowohl die Ordnerstruktur als auch den Inhalt der Dateien.
2-1. Workflow-Diagramm (Mermaid)
Ein Diagramm, das beide Schichten darstellt, einschließlich der Evaluator→Planer-Neuentwurfsschleife:
flowchart TD
USER[Benutzer] -->|Anforderungen| P
subgraph L1[Schicht 1: Meta]
P[Planer] --> G[Generator]
G --> E[Evaluator]
E -->|Mangelhaft 70–89%| G
E -->|Neuentwurf <70%| P
E -->|Genehmigt 90%+| DONE[Struktur abgeschlossen]
end
DONE --> INIT
subgraph L2[Schicht 2: Betrieb]
INIT[Initialisierer
nur für erste Ausführung] --> OP
subgraph OP[Wiederholte Ausführung des Betriebsagenten]
INPUT[Eingabe] --> SPLIT[ ]
SPLIT --> A1[Agent-A]
SPLIT --> A2[Agent-B]
SPLIT --> A3[Agent-C]
A1 --> CH[Vorsitzender Synthese]
A2 --> CH
A3 --> CH
CH --> OUT[Ausgabe + Zustand speichern]
end
end
2-2. Kerenergebnisse erstellen (in der Reihenfolge)
| Schritt | Ergebnis | Referenzdatei | Hinweis |
|---|---|---|---|
| 2-2a | WORKSPACE_TREE.md | folder-patterns.md | Ordnerstruktur festlegen |
| 2-2b | CLAUDE.md (~100 Zeilen) | claude-md-template.md | Als Inhaltsverzeichnis, Referenz-Routing-Tabelle ist Pflicht |
| 2-2c | AGENTS.md | (Leitfaden in dieser Skill) | Agentenbetriebsregeln + model_config |
| 2-2d | Agentenrollendateien | agent-archetypes.md | 00-system/prompts/*.md |
| 2-2e | 5 Protokolle | (Leitfaden in dieser Skill) | 00-system/protocols/ |
| 2-2f | Sitzungsübergabeergebnisse | session-handoff.md | progress.json + feature-status.json |
| 2-2g | Erzwungene Regeln | enforcement-patterns.md | Strukturell überprüfbare Regeln |
| 2-2h | Slash-Befehle | (Basierend auf Planer-Design) | .claude/commands/*.md |
| 2-2i | README.md | (Benutzerleitfaden) | Schnellstart + Befehle + Fehlerbehebung |
| 2-2j | Wiki der Ablaufänderungshistorie (optional) | flow-history-template.md | Nur, wenn in Stufe 2.6 F1=Ja |
2-2b. Regeln für die Erstellung von CLAUDE.md (höchste Priorität)
→ Siehe references/claude-md-template.md. Muss unter 100 Zeilen sein.
CLAUDE.md ist der Einstiegspunkt des Agenten. Zu lange Anweisungen werden zu „Nicht-Anleitungen (non-guidance)“:
- Der Kontext verdrängt die Arbeit und den Code
- Der Agent verfällt in lokales Pattern Matching anstatt in bewusste Erkundung
- Monolithische Dokumente veralten sofort
Muss enthalten:
- Identität des Arbeitsbereichs (3 Zeilen)
- Tabelle der Agentenzusammenstellung
- Referenz-Routing-Tabelle ← Kern von Progressive Disclosure
- Pointer zum Unabhängigkeitsprinzip
- Befehlsliste
Format der Referenz-Routing-Tabelle:
## Referenz-Routing
| Situation | Datei zum Lesen |
|------|---------------|
| Agentenrolle prüfen | → 00-system/prompts/[role].md |
| Diskussionsregeln | → 00-system/protocols/council-protocol.md |
| Details zum Unabhängigkeitsprinzip | → 00-system/protocols/independence-protocol.md |
| Sitzungsstatus prüfen | → progress.json |
| Funktionsfertigstellungsstatus | → feature-status.json |
2-2c. Regeln für die Erstellung von AGENTS.md
Muss enthalten:
- Tabelle der Agentenliste von Schicht 2 (Rolle / Modell / Aktivierungsbedingung)
- Abschnitt model_config (vom Benutzer gewähltes Modell + Trigger zur Neubewertung)
- Synthesemethode des Vorsitzenden + Entscheidungsrahmen (Go/Pivot/No-Go)
- Zusammenfassung des Unabhängigkeitsprinzips
- Kontextmanagementregeln