---
type: skill
name: linkedin-research
agent_ready: true
schema_version: 1
bundle_skill: true
bundle_version: "0.28.0"
scope: vault
default_active:
  allgemein: true
  content: true
conflicts_with: []
depends_on: []
trigger_words:
  - linkedin-research
  - auto-research
  - research-loop
  - karpathy-loop
created: 2026-05-18
updated: 2026-05-18
description: "Auto-Research-Loop für LinkedIn-Post-Entwürfe nach Karpathys Methode. Liest Post-Frontmatter status: entwurf und ## Entwurf-Abschnitt, erzeugt iterativ bis zu 3 verbesserte Varianten, bewertet jede gegen eingefrorene Evals (7 harte + 6 weiche Assertions) und zeigt dem Anwender die beste Variante neben dem Original."
---

# LinkedIn Research — Auto-Research-Loop

Der Loop läuft maximal drei Runden. Sobald der Score das Eval-Gate erreicht oder zwei Iterationen ohne Verbesserung vergehen, stoppt er. Die beste Variante wird mit dem Original verglichen und danach an `linkedin-finalize` übergeben, wenn das Profil es aktiviert hat.

`default_active.content: true` gilt, weil der Skill für jeden Content-Vault mit LinkedIn-Aktivität sinnvoll ist und keinen opt-in erfordert. Der Anwender konfiguriert den Pfad zu den Karpathy-Datenfiles über `paths.auto_research_root` in `skill.config.yaml`.

## Voraussetzungen

- Ein Post-Entwurf existiert als Markdown-Datei mit `status: entwurf` im Frontmatter und einem `## Entwurf`-Abschnitt
- Die Experiment-Dateien liegen unter `{system}/Karpathy Methoden/Auto-Research/LinkedIn-Post/`

## Ablauf

### Schritt 1: Post finden und Kontext laden

**Post finden:** Mit Argument: Glob-Suche in `{areas}/Content & Positionierung/LinkedIn Posts/**/*.md`. Ohne Argument: alle Entwürfe mit `status: entwurf` auflisten, Anwender wählt.

**Kontext laden (Read-Tool):**
1. `{context}/Schreibstil` (inkl. Take-away-Pflicht)
2. `{context}/Branding`
3. `{context}/ICP`
4. `{context}/Glossar`
5. `{areas}/Content & Positionierung/LinkedIn-Strategie`
6. `{areas}/Content & Positionierung/LinkedIn Best Practices/00-Übersicht` und die verlinkten Referenzposts als Qualitätsmaßstab für S5/S6

**Experiment-Dateien laden** (aus `paths.auto_research_root`):
1. `evals.json`
2. `program.md`
3. `judge-prompt.md`

Den Original-Entwurf aus dem `## Entwurf`-Abschnitt der Post-Datei extrahieren und merken.

### Schritt 2: Original bewerten

Führe die harten Assertions (H1-H7) per `run_loop.py --mode evaluate --evals <auto_research_root>/evals.json --file <draft.md> --json` gegen den Original-Text aus.

Bewerte die weichen Assertions (S1-S6) selbst als LLM-Judge, exakt nach dem Judge-Prompt. Antworte pro Assertion nur mit PASS oder FAIL.

Zeige dem Anwender den Original-Score:

```
Original-Score: X/13  (11 = gut, 12 = sehr gut, 13 = perfekt)
Hart: H1✓ H2✗ H3✓ H4✓ H5✓ H6✓ H7✓
Weich: S1✓ S2✗ S3✓ S4✓ S5✗ S6✗
```

Falls der Original-Score bereits ≥ 11/13: Anwender informieren, Research-Loop optional anbieten. Bei Score < 11: Loop starten.

### Schritt 3: Iterations-Loop (max. 3 Iterationen, konfigurierbar via `max_iterations`)

**Pro Iteration:**

1. **Generator-Prompt bauen.** Kontext:
   - Der Original-Entwurf
   - Die Eval-Ergebnisse der vorherigen Iteration (welche Assertions sind gefailed?)
   - Die geladenen Vault-Regeln (Schreibstil, Branding, ICP, Strategie)
   - Explizite Anweisung: "Verbessere den Post gezielt bei den gefailten Assertions, ohne die bestandenen zu verschlechtern."

2. **Variante erzeugen.** Schreibe eine verbesserte Version des Posts. Nicht komplett neu erfinden, gezielt die Schwachstellen adressieren.

3. **Variante bewerten.** Harte Assertions per `run_loop.py --mode evaluate --evals <auto_research_root>/evals.json`, weiche per Judge-Prompt (du selbst als Judge).

4. **In loop-log.md dokumentieren** (append-only):
   ```markdown
   ## Iteration N — YYYY-MM-DD HH:MM

   **Score:** X/13 (vorher: Y/13)
   **Hart:** H1✓ H2✗ ...
   **Weich:** S1✓ S2✗ ... S6✗

   **Variante:**
   [vollständiger Post-Text]

   **Änderungen vs. vorherige Iteration:**
   [kurze Stichpunkte, was geändert wurde und warum]
   ```

5. **Abbruchbedingung prüfen:**
   - Score ≥ 11/13 → Loop beenden, Variante ist Gewinner
   - 2 Iterationen ohne Score-Verbesserung → Loop beenden, bisherige beste Variante ist Gewinner
   - Max-Iterationen erreicht → Loop beenden

### Schritt 4: Ergebnis präsentieren

Zeige dem Anwender:

```
┌─────────────────────────────────┐
│ ORIGINAL (Score: X/13)          │
├─────────────────────────────────┤
│ [Original-Text]                 │
├─────────────────────────────────┤
│ BESTE VARIANTE (Score: Y/13)    │
├─────────────────────────────────┤
│ [Varianten-Text]                │
├─────────────────────────────────┤
│ VERBESSERUNGEN:                 │
│ • H2: Hook von 180 auf 130 Z.  │
│ • S3: Aufzählung durch Fließ-  │
│   text ersetzt                  │
│ • ...                           │
└─────────────────────────────────┘
```

Frage: **"Variante übernehmen oder Original behalten?"**

### Schritt 5: Übergang zu linkedin-finalize

Falls Skill `linkedin-finalize` im aktuellen Profil als `default_active: true` konfiguriert ist (Check via `manifest.json` → `skills.linkedin-finalize.default_active.<profil>`): Skill aufrufen. Sonst: fertige Variante an Anwender zur manuellen Finalisierung übergeben.

- **"Variante übernehmen":** Schreibe den Varianten-Text in den `## Entwurf`-Abschnitt der Post-Datei. Dann linkedin-finalize aufrufen (wenn aktiv) oder übergeben.
- **"Original behalten":** linkedin-finalize direkt aufrufen (wenn aktiv) oder Anwender informieren.

## Budget-Caps

| Parameter | Standard | Konfigurierbar |
|---|---|---|
| Max-Iterationen | 3 | Ja, via Feature-Flag `max_iterations` in skill.config.yaml |
| Max-Tokens | 50.000 | Nicht in dieser Version |
| Ziel-Score | 11/13 | Aus evals.json |

## Dateien

| Datei | Rolle | Wer schreibt |
|---|---|---|
| `evals.json` | Eingefrorene Assertions | Niemand (read-only) |
| `program.md` | Zieldefinition | Mensch |
| `judge-prompt.md` | Judge-Anweisung | Mensch |
| `loop-log.md` | Iterations-Protokoll | Skill (append-only) |
| `run_loop.py` | Harte Eval-Checks | Mensch |

## Hinweise

- Der Skill schreibt NIE in Wiki-Dateien, Daily Notes oder CLAUDE.md.
- Der Skill verändert NIE die evals.json, program.md oder judge-prompt.md.
- Alle Vault-Regeln aus CLAUDE.md gelten (Glossar-Pflicht, Updated-Pflicht).
- `loop-log.md` wird bei jedem neuen Lauf mit einem neuen Lauf-Header ergänzt (append), nicht überschrieben.

## Verknüpfungen

- Konsument des Post-Schemas von [[linkedin-entwurf]] und [[linkedin-ideen]] (liest `status: entwurf` und `## Entwurf`)
- Übergibt an [[linkedin-finalize]] (wenn im Profil aktiv)
- Karpathy-Experiment-Dateien liegen unter `{system}/Karpathy Methoden/Auto-Research/LinkedIn-Post/`
