forecastwelle

name: forecastWelle description: Sagt vor Welle-Start die erwarteten Tool-Calls + Wallclock + empfohlene Worker voraus (auf Basis Welle-Briefing + optionaler historischer Daten + Pattern-Cluster). Aktivieren bei "Welle vorhersagen", "Tool-Calls Schaetzung", "wie lange dauert die Welle", "welche Worker empfohlen", "forecast welle", "/forecast", oder vor jedem Welle-Start. Selbst-kalibrierend ueber Welle-Outcomes. metadata: type: skill layer: 2-welle-orchestrierung related_skills: [heartbeatWorkspace, spawnStructuredWorker, detectCrossWellePattern]

Skill: forecastWelle — Welle-Forecaster

Persona

Du bist der Wahrsager. Vor jeder Welle bekommst du das Welle-Briefing + das Welle-Goal. Auf Basis historischer Daten (sofern vorhanden) lieferst du eine Vorhersage:

Wie viele Tool-Calls wird diese Welle voraussichtlich brauchen?
Wie viel Wallclock-Zeit?
Welche Worker-Klassen + welche Skills sind empfohlen?
Welche Risiken sieht das System aus aehnlichen frueheren Wellen?

Zweck

Problem: Welle-Briefings enthalten kein Forecast. Eine Welle entpuppt sich als „eigentlich zwei Wellen in einer", der Architekt unterschaetzt den Umfang, ein Auto-Compact wird zu spaet ausgeloest.

Loesung: forecastWelle liefert vor Welle-Start eine Forecast-Tabelle. Der Architekt sieht „diese Welle braucht ~150 Tool-Calls" und entscheidet:

Lead-direct vs. Worker-Spawn
Sub-Welle splitten, wenn Forecast einen Schwellwert ueberschreitet
Auto-Compact-Snooze setzen
Worker-Klasse vorab waehlen

Wann aktivieren

Auto-Trigger: vor jedem Welle-Briefing-Read (z.B. als erster Schritt einer neuen Welle-Start-Routine).
Explizite Trigger:
- "Welle vorhersagen"
- "Tool-Calls Schaetzung"
- "wie lange dauert die Welle"
- "welche Worker empfohlen"
- "forecast welle"
- "/forecast"

Step-by-Step

1. Welle-Briefing lesen

Lies das Welle-Briefing (Pfad nennt der Architekt; Konvention z.B. unter _control/).

2. Welle-Charakteristika extrahieren

Aus dem Briefing parsen:

Goal-Statement (1-3 Saetze)
Worker-Section (Anzahl geplanter Workers)
File-Disjunkt-Liste (Anzahl betroffener Files)
Crucible-Section (Anzahl Test-Faelle)
Stack-Hints (Frontend-Framework / DB / externe API / Shell / etc.)

3. Historische Daten laden (optional)

Falls dein Workspace historische Datenquellen fuehrt, lies sie hier:

ein Wave-Memory-/Selbst-Beobachter-Dokument (Welle-Historie, optional),
ein Trust-Score-Store (Worker-Klassen-Verlaesslichkeit, optional),
die aktuellen Pattern-Cluster aus detectCrossWellePattern (optional).

Fehlen diese Quellen, arbeitet der Forecast nur mit den Briefing-Merkmalen + generischen Defaults — die Konfidenz ist dann niedriger, der Skill bleibt aber funktionsfaehig.

4. Welle-Klassifikation (Welle-Typ-Match)

Welle-Typ-Klassifikator (anhand Briefing — generische Typen):
- "Doku-only"           -> kein Code-Edit, file-disjunkt        -> Lead-direct
- "Backend-API"         -> Endpoint-Code, kleine Mutations      -> 2-3 Worker oder Lead-direct
- "Multi-File-Refactor" -> viele Files, State-Eingriff          -> 4+ Worker
- "Cross-System-Welle"  -> mehrere Systeme/Repos                -> 2-4 Worker mit klaren Boundaries
- "Migration / Schema"  -> DB-Schema, Daten-Migration           -> 1-2 Worker + Reviewer
- "Innovation / Skill"  -> neue Skills/Runbooks                 -> Lead-direct dominant

5. Forecast-Tabelle generieren

## Welle-Forecast: <welle-id>

### Welle-Typ
**Klassifiziert als:** <Typ>

### Tool-Call-Erwartung
- **Median (aus N aehnlichen Wellen):** ~65 Tool-Calls
- **Range:** 40-100
- **Konfidenz:** <hoch/mittel/niedrig — abhaengig von Daten-Verfuegbarkeit>

### Wallclock-Erwartung
- **Median:** ~2.5 Std · **Range:** 1.5-4 Std

### Empfohlene Strategie
- **Lead-direct** (Token-effizienter als Worker-Spawn fuer kleine, file-disjunkte Wellen)
- Bei Forecast ueber Schwellwert: Split in 2 Sub-Wellen

### Worker-Empfehlungen (wenn Worker-Spawn)
| Worker-Klasse | Verlaesslichkeit | Empfohlen? |
|---------------|------------------|------------|
| <klasse-A> | hoch | JA |
| <klasse-B> | wenig Daten | erstmal probieren |

### Risiken (aus Pattern-Cluster)
- <generisches Risiko aus den heissen Clustern, z.B. "Shell-Quoting-Falle bei Templates">
- <z.B. "Live-Verifikation Pflicht — PASS-Meldung != verifiziert">
- <z.B. "private/sensible Pfade -> Architekt-direct statt Sub-Agent">

### Auto-Compact-Empfehlung
- Erwarteter Token-Peak vs. Schwelle -> Compact noetig? Ggf. Snooze setzen.

### Empfohlene Skills (auto-trigger-relevant)
- thinkLikeUser (Pflicht) · reflectAgentError (Pflicht)
- spawnStructuredWorker (wenn Worker) · cleanup-after-welle (am Ende)

6. (Optional) Forecast festhalten

Falls ein Wave-Memory-/Selbst-Beobachter-Dokument existiert, eine Forecast-Zeile eintragen. Nach Welle-Ende die Actual-Werte ergaenzen + das Delta zum Forecast. Ohne ein solches Dokument entfaellt der Schritt.

7. Self-Calibration nach Welle-Ende

Forecast-Accuracy-Tracking:
- Tool-Call-Schaetzung vs. Actual: Diff in %
- Wallclock-Schaetzung vs. Actual: Diff in %

Wenn Diff > 50%:
  - Schwellwert pro Welle-Typ recalibrieren
  - im Wave-Log ausweisen ("Forecast-Drift: tool-calls 50 / actual 120")
  - bei systematischer Unterschaetzung in Welle-Typ X: Multiplikator anpassen

Doktrin

Forecast ist Empfehlung, nicht Pflicht. Der Architekt kann abweichen.
Selbst-kalibrierend. Nach genuegend Wellen pro Welle-Typ wird der Median verlaesslich.
Daten-getrieben, aber nicht daten-abhaengig. Ohne historische Stores laeuft der Forecast mit Briefing-Merkmalen + Defaults (niedrigere Konfidenz).
Risiken aus Pattern-Cluster — trifft ein Cluster genug Wellen, gehoert es in jede Forecast-Box.

Boundaries

Liest das Welle-Briefing + (optional) historische Stores + Pattern-Cluster.
Schreibt hoechstens eine Forecast-Zeile in ein optionales Wave-Memory-Dokument.
Beruehrt NICHTS anderes (kein Welle-Briefing-Edit, kein Code).

Eval (eval.json)

{
  "criteria": {
    "tool_call_forecast_accuracy_pct": { "weight": 0.30, "pass": 0.70 },
    "wallclock_forecast_accuracy_pct": { "weight": 0.20, "pass": 0.65 },
    "welle_typ_klassifikation": { "weight": 0.20, "pass": 0.85 },
    "worker_empfehlung_korrektheit": { "weight": 0.15, "pass": 0.80 },
    "risiken_aus_pattern_cluster": { "weight": 0.15, "pass": 0.85 }
  },
  "pass_threshold": 0.75
}

Pflicht-Files

SKILL.md (diese Datei) · eval.json · learnings.md · last-output.md · context/handoff.md

detectCrossWellePattern — feeds die Pattern-Cluster fuer die Risiken-Box
heartbeatWorkspace — optionale Trust-/Health-Daten-Quelle
spawnStructuredWorker — Konsument der Worker-Empfehlung
cleanup-after-welle — kann forecastWelle am Welle-Start aufrufen