SKILL.md
Wann verwenden
- Wenn Agenten deterministisch-markenbasiert analysieren sollen und gleichzeitig intuitiver in der Auswahl, Gewichtung und Reihenfolge der Marker werden sollen (SFT→RL).
- Wenn Marker nicht erneut abgebildet werden müssen: die vollständigen Marker liegen bereits zentral vor (ZIP/Supabase) und werden live bezogen.
- Wenn RF‑Kontext und Intuition (provisional→confirmed→decayed) die Interpretation schärfen sollen und MEMA/ARS als systemische Diagnose benötigt wird.
Workflow/Anweisungen
- Datenbasis übernehmen
Verwende die bereitgestellten Marker‑Sätze (ZIP/Supabase) als „Single Source of Truth". Trainings‑Inputs im SFT‑Format: [Instruktion/Kontext] | [Erwarteter Output]; Beispiele enthalten ATO→SEM→CLU→MEMA inkl. RF‑Manifestation. Begründung: SFT‑Format & Vier‑Ebenen‑Kaskade. [Quellen im Skill‑Paket]
- Deterministische Basis-Pipeline fixieren
Erzwinge: (i) SEM‑Komposition ≥2 unterschiedliche ATOs, (ii) Bottom‑up‑Evaluierung (höhere Ebenen nur bei aktiver Unterebene), (iii) MEMA‑Aktivierung durch **composedof ≥2 CLU\*, (iv) ARS 0–5** mit Decay. Diese Pipeline dient als Orakel und späteres Evaluations‑Backbone.
- SFT (Supervised Fine‑Tuning)
Feine Abstimmung auf präzises Erkennen/Anwenden/Interpretieren der Marker inkl. Intuition‑Zuständen (provisional→confirmed→decayed) und temporärem Multiplier bei confirmed; RF‑Manifestation immer explizit labeln.
- RL‑Feintuning (Policy lernen)
Definiere eine MarkerEnv mit Gym‑API:
- State: Fenster aus Nachrichten, aktive Marker, letzte Aktionen, RF‑Level‑Schätzung. - Actions: APPLY(markerid) | PROMOTE(family) | SKIP | ADJUSTWINDOW(k) (diskret). - Reward (pro Schritt): +F1‑Delta, +Gate‑Pass, +SEM‑Regel erfüllt, +ARS‑Kohärenz; −False‑Positive, −Regelverstoß, −Überdetektion. Trainiere Actor‑Critic (z. B. PPO). Exportiere policy.json (Multiplikatoren/Fenster/Heuristik).
- Lehr‑Loop & Guardrails
Nach jeder Epoche: 1–2 Sätze Validierung (z. B. „SEM‑Regelverletzungen ↓22 %, ARS‑Kohärenz +0.08; nächster Schritt: LR halbieren"). Bei Misserfolg: Korrekturschleife (Reward‑Shaping anpassen, Fenster regulieren, Data‑Augment).
- Deployment
Runtime lädt Marker live aus Supabase und optional policy.json. Policy priorisiert und gewichtet, die Regeln der Kaskade bleiben unverändert (Policy darf nicht gegen SEM‑Regel oder Bottom‑up verstoßen). Ausgabe als NDJSON‑Events inkl. ARS.
Eingaben
- text: String | Liste von Nachrichten | Stream.
- markers_source:
supabase(empfohlen) |zip|local;supabase= URL/Key in ENV. - runtime:
{ semwindow, cluwindow, rfenabled, gates{mintotalmarkers,minsegments} }. - policy_path: optionaler Pfad zu
policy.json.
Ausgabeformat
JSON‑Objekt (vereinfacht):
{
"events": [
{
"type": "ATO_HIT",
"id": "ATO_HESITATION",
"messageId": "m1",
"span": [0, 3]
},
{
"type": "SEM_HIT",
"id": "SEM_UNCERTAINTY_TONING",
"window": ["m1"],
"evidence": ["ATO_HESITATION", "ATO_DOUBT_PHRASE"]
},
{
"type": "CLU_HIT",
"id": "CLU_CONFLICT_ESCALATION",
"window": ["m1", "m2"]
},
{
"type": "MEMA_HIT",
"id": "MEMA_RELATIONSHIP_STRAIN",
"ars": 2.8,
"decay": "0.85/24h"
}
],
"rf_context": { "level": "L1-STONE", "intensity": 0.52 },
"telemetry": { "sem_violations": 0, "policy": "policy.json@ts=..." }
}Beispiele
Dialog (Kurz) → bis SEM
„Ich bin mir nicht ganz sicher… vielleicht überschätze ich die Nachfrage." / „Können wir das auf morgen schieben?" → ATOs für Unsicherheit/Hedging/Delay → SEMUNCERTAINTYTONING, SEMAVOIDANTBEHAVIOR.
Intuition (Cluster) → confirmed
Mehrere weiche Unsicherheits‑SEMs → CLUINTUITIONUNCERTAINTY: provisional; „hartes" Ziel‑SEM im Fenster → confirmed, temporärer Multiplier x1.5 für Unsicherheits‑Familie.
MEMA (Meta) → ARS
CLUCONFLICTCYCLE + CLUREPAIR → MEMARELATIONSHIP_STRAIN mit ARS (z. B. 2.3/5) und Decay.
Qualitätssicherung
CI‑Checks: SEM‑Komposition (≥2 ATOs), Single‑Structure‑Block, Bottom‑up‑Prüfungen, Gate‑Pass.
Eval: ATO/SEM/CLU‑F1, ARS‑Kohärenz, Regelverletzungen/Episode, Policy‑Abstürze (0‑Toleranz).