What is marker-engine-rl?

The marker-engine-rl skill is a sophisticated framework for Claude agents designed to enhance diagnostic precision through Supervised Fine-Tuning (SFT) and Reinforcement Learning (RL). By leveraging LeanDeep 4.0 and a multi-layered marker hierarchy (ATO, SEM, CLU, MEMA), it allows developers to train agents with intuitive decision-making policies. This tool is essential for building agents that require high-level contextual awareness, systemic analysis, and rigorous performance validation using a bottom-up logic approach.

When should I use marker-engine-rl?

marker-engine-rl is useful in the following scenarios: • Advanced Behavioral Analysis: Training agents to identify complex emotional states or behavioral patterns in text using the SFT/RL fine-tuning loop for higher diagnostic accuracy. • Dynamic Policy Optimization: Automating the optimization of agent decision-making policies using the integrated Gym-API MarkerEnv to improve how agents weight and sequence information. • Systemic Diagnostic Reporting: Implementing a structured, multi-level pipeline to analyze communication dynamics and relationship strain (ARS) in real-time dialogues. • Automated Agent Quality Assurance: Enhancing agent reliability through automated CI checks that enforce semantic composition rules and hierarchical logic, ensuring zero-tolerance for policy crashes.

marker-engine-rl – AI Agent Skills

name	marker-engine-rl
description	Vertieft den Marker-Engine-Skill um SFT/RL-Feinabstimmung mit LeanDeep 4.0; lädt Marker aus Supabase/ZIP und lernt eine Policy zur präzisen, kontextualisierten Marker-Anwendung bei strikter Bottom-up-Logik.

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(marker_id) | PROMOTE(family) | SKIP | ADJUST_WINDOW(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: { sem_window, clu_window, rf_enabled, gates{min_total_markers,min_segments} }.
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 → SEM_UNCERTAINTY_TONING, SEM_AVOIDANT_BEHAVIOR.

Intuition (Cluster) → confirmed

Mehrere weiche Unsicherheits‑SEMs → CLU_INTUITION_UNCERTAINTY: provisional; „hartes" Ziel‑SEM im Fenster → confirmed, temporärer Multiplier x1.5 für Unsicherheits‑Familie.

MEMA (Meta) → ARS

CLU_CONFLICT_CYCLE + CLU_REPAIR → MEMA_RELATIONSHIP_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).

marker-engine-rl

When & Why to Use This Skill

Use Cases