AGENTS.md — one.OS Master-Agentensteuerung

Pflichtlektüre vor jeder Aufgabe. Jede Änderung erfordert explizite Freigabe von Jonas. Einzelne Agent-Definitionen: Agents/AGENT_*.md

1. Das 95%-Prinzip — Pflicht für alle Agenten

Kein Agent beginnt Arbeit, bevor er zu ≥ 95% sicher ist, was getan werden soll.

WENN Aufgabe unklar ODER mehrdeutig ODER kritische Info fehlt:
  → Gezielte Fragen stellen (max. 3 pro Runde, priorisiert)
  → Warten auf Antwort
  → Wiederholen bis Sicherheit ≥ 95%
  → DANN erst mit Arbeit beginnen

Fragenkategorien (in dieser Priorität):

Scope — Was genau soll geändert werden? Welche Seite / Funktion / Layer?
Basis — Welche Versionsdatei ist Ausgangspunkt?
Constraints — Gibt es Deadlines, Design-Vorgaben, Nicht-Ziele?

Beispiel-Einstieg: „Bevor ich beginne: [Frage 1]? [Frage 2]?"

2. Modell-Routing

Aufgabentyp	Modell	Begründung
Coding, HTML/CSS/JS, Integration	claude-sonnet-4-6	Beste Code-Qualität, präzise Diff-Ausgabe
Sub-Agenten, schnelle Analyse, Routing	claude-haiku-4-5	Schnell, kosteneffizient für atomare Tasks
Architekturentscheidungen, Opus-Qualität	claude-opus-4-6	⚠️ Nur nach expliziter Bestätigung durch Jonas

Regel: Opus nie autonom starten. Immer erst ankündigen: „Diese Aufgabe würde von Opus profitieren — soll ich wechseln?"

3. Agentenübersicht

Agent	Datei	Modell	Trigger
ORCHESTRATOR	`Agents/AGENT_ORCHESTRATOR.md`	sonnet	Jede Aufgabe mit >1 Schritt
ANALYST	`Agents/AGENT_ANALYST.md`	haiku	„analysiere", „status", „was fehlt"
DESIGNER	`Agents/AGENT_DESIGNER.md`	sonnet	UI, Layout, neue Komponente
DEVELOPER	`Agents/AGENT_DEVELOPER.md`	sonnet	Feature, Fix, Integration
INTEGRATOR	`Agents/AGENT_INTEGRATOR.md`	sonnet	„integriere aus", Portierung
VERSIONER	`Agents/AGENT_VERSIONER.md`	haiku	Nach jeder Iteration
REVIEWER	`Agents/AGENT_REVIEWER.md`	haiku	Vor jedem Release / ANCHOR

4. Aufgaben-Routing

Anfrage enthält...	Pattern	Primäragent
„analysiere", „zeige", „status", „was fehlt"	D	ANALYST
„integriere", „portiere", „füge ein aus"	A	ORCHESTRATOR → INTEGRATOR
„neue Seite", „neues Feature", „erstelle"	B	ORCHESTRATOR → DESIGNER → DEVELOPER
„fix", „repariere", „korrigiere"	C	DEVELOPER
„neue Version", „ANCHOR", „stable"	—	VERSIONER
„redesign", „ändere Design"	B/C	DESIGNER
„API", „Backend", „Supabase", „Endpoint"	E	ORCHESTRATOR → DEVELOPER

5. Workflow-Patterns (Kurzform)

Pattern A — Feature-Integration aus Altdatei:
  ANALYST → DESIGNER → DEVELOPER → INTEGRATOR → REVIEWER → VERSIONER

Pattern B — Neues Feature-Modul:
  ANALYST → DESIGNER → DEVELOPER → REVIEWER → VERSIONER

Pattern C — Bugfix / UI-Detail:
  DEVELOPER → REVIEWER → VERSIONER (nur wenn relevant)

Pattern D — Analyse & Planung (kein Code):
  ANALYST → Report

Pattern E — Backend-Erweiterung:
  ANALYST → DEVELOPER (Backend) → DEVELOPER (Frontend) → REVIEWER → VERSIONER

6. Parallelisierung

✅ Parallel erlaubt:
  - ANALYST liest Quell- und Zieldatei gleichzeitig
  - DESIGNER (CSS) + DEVELOPER (JS-Logik) parallel planen
  - Mehrere unabhängige Seiten entwickeln

❌ Sequenziell (immer in dieser Reihenfolge):
  ANALYST → DESIGNER → DEVELOPER → REVIEWER → VERSIONER

7. Eskalation & Stopps

Situation	Aktion
Scope unklar	95%-Regel anwenden — fragen, nicht raten
ANCHOR-Datei würde überschrieben	SOFORT stoppen, Jonas informieren
Neue Farbe / neues Framework nötig	Erst ankündigen, auf Freigabe warten
Opus benötigt	Ankündigen: „Soll ich Opus verwenden?"
Performance-Risiko (>5 MB, >10s)	REVIEWER blockiert, Jonas informieren

8. Versionierungsregel

Bugfix / UI-Detail  → PATCH  (1.8.x → 1.8.x+1)
Neues Feature-Modul → MINOR  (1.8 → 1.9)
Redesign / Layer    → MAJOR  (1.x → 2.0)

PFLICHT: Neue Datei, nie überschreiben.
Code-Index nach größeren Änderungen aktualisieren → CODE_INDEX.md

Version: AGENTS.md v2.0 | 2026-04-03 | Änderungen nur mit Freigabe Jonas

4.4 KiB Raw Permalink Blame History