---
bundle_template: true
please_customize: true
type: projekt-notiz
agent_ready: false
description: "Zieldefinition für den Auto-Research-Pilot. Definiert was der Loop erreichen soll, welche Regeln gelten und wann er abbricht."
tags:
  - auto-research
  - karpathy
  - pilot
created: YYYY-MM-DD
updated: YYYY-MM-DD
---

> **Hinweis (Bundle-Template):** Passe diese Datei an deinen konkreten Anwendungsfall an.
> Ersetze die `[PLATZHALTER]` mit deinen Angaben. Die Abbruchbedingungen und Kontext-Quellen
> sind Ausgangspunkt, nicht Enddefinition.

# Program — [Dein Skill-Name] Auto-Research-Pilot

## Ziel

Nimm einen bestehenden [Inhaltstyp, z.B. LinkedIn-Post]-Entwurf und erzeuge iterativ bessere Varianten, bis der Inhalt die Eval-Kriterien erfüllt oder das Budget erschöpft ist. Am Ende steht die beste Variante zur Auswahl neben dem Original.

## Rollen

- **Generator:** Erzeugt eine neue Variante auf Basis des Originals, der Eval-Ergebnisse der vorherigen Iteration und der Vault-Regeln.
- **Verifier (Judge):** Bewertet jede Variante gegen die eingefrorenen Assertions in `evals.json`. Gibt pro Assertion ein binäres Ergebnis (pass/fail) plus Gesamtscore.

## Kontext-Quellen (bei jedem Loop-Start frisch laden)

1. `{context}/Schreibstil` — Tonalität, Stilregeln
2. `{context}/Branding` — Positionierung
3. `{context}/ICP` — Zielgruppe
4. `{context}/Glossar` — Korrekte Schreibweisen
5. `[Weitere relevante Dateien aus deinem Vault — Strategie, Best Practices etc.]`

## Regeln

1. Der Loop schreibt ausschließlich in sein Experiment-Verzeichnis. Keine Wiki-Änderungen, keine Daily Notes.
2. Jede Variante wird vollständig in `loop-log.md` dokumentiert (Iteration, Score, Text, Judge-Begründung).
3. Das Original bleibt unverändert. Der Loop arbeitet auf Kopien.
4. Der Judge darf ausschließlich die Assertions aus `evals.json` prüfen. Kein Freitext-Urteil.
5. Varianten, die schlechter scoren als die bisherige beste, werden als "verworfen" geloggt, nicht gelöscht.

## Abbruchbedingungen

Der Loop endet, sobald eine dieser Bedingungen eintritt:

1. **Ziel-Score erreicht:** Eine Variante besteht mindestens [X] von [Y] Assertions.
2. **Budget-Cap Iterationen:** Maximale Anzahl Iterationen erreicht (Standard: 3).
3. **Budget-Cap Tokens:** Maximale Token-Obergrenze erreicht (Standard: 50.000).
4. **Stagnation:** Zwei aufeinanderfolgende Iterationen ohne Score-Verbesserung.

## Output

Nach Abschluss des Loops:

1. Anwender sieht: Original vs. beste Variante, mit Score-Vergleich.
2. Anwender wählt: "Original behalten" oder "Variante übernehmen".
3. Bei "übernehmen": Der gewählte Text wird als neuer Entwurf gespeichert. Dann Finalisierungs-Skill aufrufen (falls konfiguriert).
4. Bei "Original behalten": Direkt zum Finalisierungs-Skill.
