mission-control-v2/deploy/skills/konzept-fliessband/SKILL.md

---
name: konzept-fliessband
description: "Erarbeitet eine rohe Idee durch mehrere Fach-Rollen bis WASSERDICHT — BEVOR gebaut wird, KEIN Code. Der starke Denker (heavy/gpt-oss-120b) waehlt den passenden Rollen-Cast, die Rollen schaerfen ein gemeinsames Konzept in Runden, ein Advocatus Diaboli (fremdes Modell) sucht Loecher, bis keine Blocker mehr offen sind (max 3 Runden). Ergebnis: EIN fertiges Konzept-Dokument, das der Commander in Hermes Desktop dem Coder vorwirft. Nutzen bei: 'erarbeite/entwickle ein Konzept', 'arbeite die Idee aus', 'wasserdichtes Konzept fuer App/Spiel/Tool', 'denk dir X aus bevor wir bauen', 'lass mehrere Experten/Rollen drueberschauen', 'mach das Konzept rund'. NICHT fuer Code-Bau (das ist projekt-start/orchestrator)."
version: 1.0.0
author: MC2 (Konzept-Fliessband 14.07.2026 — heavy denkt, Skeptiker haertet, propose-only)
platforms: [linux]
metadata:
  hermes:
    tags: [konzept, denken, mehrrollen, heavy, wasserdicht, vor-code]
---

# Konzept-Fliessband — haerten bis wasserdicht, BEVOR gebaut wird

Nutze diesen Skill, wenn der Commander eine **Idee** hat, die erst als **Konzept** rundgedacht
werden soll — nicht sofort gebaut. Du bist der **Manager**: du holst die tagesaktuelle Recherche,
laesst den starken Denker (**heavy**) den passenden **Rollen-Cast** waehlen, moderierst mehrere
**Denk-Runden**, in denen die Rollen das Konzept schaerfen, laesst einen **Advocatus Diaboli**
(fremdes Modell) nach Loechern suchen — und lieferst am Ende **EIN wasserdichtes
Konzept-Dokument**. Der Commander nimmt das Dokument und startet damit in Hermes Desktop ein
Projekt; DORT baut der Coder. Hier wird **kein Code geschrieben**.

## Abgrenzung — wann DIESER Skill, wann ein anderer
- **konzept-fliessband (hier):** rohe Idee → wasserdichtes **Konzept** (Text). Vor dem Bauen. KEIN Code.
- **projekt-start:** das fertige Konzept → in Hermes Desktop planen + **bauen** (Coder). Danach.
- **orchestrator:** einen Code-Auftrag zerlegen + an Worker delegieren. Nicht fuers Konzept-Denken.

> **Uebergabe:** Das Konzept-Dokument von hier ist exakt der Input, den `projekt-start` in Phase 1
> als Vorlage will. Sag das dem Commander in der Uebergabe.

## Warum seriell (Box-Physik, ehrlich ansagen)
Nur EIN grosses Modell passt in den Speicher. Die Rollen reden **nicht wirklich gleichzeitig** —
DU moderierst Runden und traegst jede Stimme ins gemeinsame **lebende Konzept-Dokument**. Ergebnis
ist echtes Aufeinander-Aufbauen, nur seriell statt Schwarm. **Minimiere Modell-Wechsel:** alle
heavy-Rollen einer Runde am Stueck (heavy bleibt warm), DANN der Skeptiker (ein Swap zu GLM).

## Leitplanken (nicht verhandelbar)
- **Jede Rollen-Stimme MUSS aus einem `worker.sh`-Aufruf an heavy stammen.** Denkst du dir die
  Beitraege selbst aus (statt heavy zu rufen), ist der Lauf GESCHEITERT — sag das ehrlich, statt
  Eigenbau als Mehr-Rollen-Arbeit auszugeben. **NIE `delegate_task` benutzen:** das laeuft ueber
  `delegation.model: coder` (ein Code-Modell, schwacher Generalist) und kann heavy gar nicht
  waehlen — genau der Fehler, den dieser Skill behebt. Beleg jede Rolle mit ihrem `worker.sh`-Aufruf
  UND den ersten Zeilen ihrer Roh-Ausgabe.
- **heavy = `gpt-oss-120b` ist der Denker.** Sein Kaltladen (~28 s) setzt Lucys Sprech-Latenz kurz
  aus — fuer diesen Hintergrund-Job gewollt. heavy hat nur **32k Kontext** → halte das Konzept-
  Dokument kompakt und schleppe KEINE alten Runden-Protokolle mit (siehe Kontext-Uebergabe).
- **REASONING-MODELLE brauchen Token-Luft (verifiziert 14.07.).** heavy (gpt-oss) UND der Skeptiker
  (GLM-4.7-Flash) „denken" erst ausfuehrlich (im `reasoning_content`), bevor die eigentliche Antwort
  in `content` landet — `worker.sh`/`fremdblick.sh` lesen NUR `content`. Zu knappes `max_tokens` =
  das Modell verbraucht alles beim Denken, `content` bleibt LEER, das Skript meldet „FEHLGESCHLAGEN"
  (obwohl das Modell lief). GLM verbrennt real ~2000 Tokens Denken fuer 2 Zeilen Antwort. Deshalb
  IMMER grosszuegig: heavy-Aufrufe mit `WORKER_MAXTOK=6000`, den Skeptiker mit `FREMDBLICK_MAXTOK=4000`.
  Bekommst du trotzdem leeren `content` → Budget erhoehen und erneut rufen, NICHT selbst schreiben.
- **Erster heavy-Aufruf laedt 60 GB kalt.** Rechne beim allerersten `worker.sh`-Aufruf einer Runde
  mit ~30 s Stille (Laden), bevor Text kommt — das ist KEIN Fehlschlag. Meldet der ERSTE heavy-Aufruf
  `FEHLGESCHLAGEN (finish=keins)`, ist das meist eine transiente Kaltstart-Kollision mit dem Warm-Set
  → **einmal wiederholen** (beim zweiten Mal ist heavy geladen und antwortet). Scheitert es auch dann,
  ehrlich melden statt selbst zu schreiben.
- **Der Skeptiker ist ein FREMDES Modell** (`fremdblick.sh`, GLM). Wer seine eigene Idee benotet,
  findet keine Loecher — der Advocatus Diaboli MUSS ein anderes Modell sein als der Denker.
- **Aufwand zur Projektgroesse skalieren — nicht mit Kanonen auf Spatzen (WICHTIG).** Jeder
  heavy-Aufruf kostet auf dieser lokalen HW ~1 Min. Ein Mini-/Ein-Feature-Projekt (kleines Tool,
  ein Spiel-Prototyp, eine klar umrissene App) braucht KEINE volle Kaskade. Richtwerte:
  - **Klein / klar umrissen:** 2 Rollen, **1 Denk-Runde** + 1 Haertetest. Ist der Skeptiker danach
    zufrieden (WASSERDICHT), ist Schluss — keine zweite Runde erzwingen.
  - **Mittel:** 3 Rollen, bis 2 Runden.
  - **Gross / ambitioniert / viele bewegliche Teile:** volle 3-5 Rollen, bis 3 Runden.
  Du schaetzt die Groesse aus Idee + Recherche selbst ein und sagst sie im Uebergabe-Text
  („Umfang: klein → 1 Runde"). **Woran du „gross" erkennst:** mehrere Subsysteme, echte
  Architektur-Entscheidungen, ein Datenmodell, externe Integrationen, Mehrbenutzer/Rechte,
  Security-Flaeche. Bei offensichtlich Kleinem im Zweifel kleiner; **bei echter Ambition aber zur
  VOLLEN Tiefe** — ein zu flaches Konzept fuer ein grosses Projekt kostet den Commander spaeter
  teure Bau-Zeit (er baut auf einem wackligen Plan), das ist schlimmer als ein paar Minuten
  Box-Zeit zu viel.
- **★ Explizite Commander-Wahl UEBERSTIMMT deine Einschaetzung.** Steht im Auftrag eine Zeile
  „AUFWAND (vom Commander gewaehlt): SIMPEL …" bzw. „… GRUENDLICH …" (der Commander hat im
  Auftragsbuch „IDE: simpel" oder „IDE: gruendlich" geklickt), dann HALTE DICH DARAN — SIMPEL =
  2 Rollen/1 Runde, GRUENDLICH = volle 3-5 Rollen/bis 3 Runden — auch wenn deine eigene
  Schaetzung anders ausfaellt. Nur wenn KEINE solche Zeile da ist, entscheidest du selbst.
- **Max 3 Denk-Runden — keine Endlosschleife.** Nach der letzten Runde (je nach Groesse 1-3) kommt
  IMMER die Editor-Endfassung, auch wenn Rest-Punkte offen sind (die dann ehrlich als „offene
  Punkte" ins Dokument). **Frueher raus ist gut:** meldet der Skeptiker WASSERDICHT, sofort zur
  Endfassung — keine weitere Runde „zur Sicherheit".
- **Kein Code, kein Repo, keine Dateien in einem Projekt.** Der EINZIGE Output ist ein
  Konzept-Dokument (Markdown) + eine Telegram-Uebergabe. NIE bauen, NIE `main`/Worktrees anfassen,
  NIE deployen.
- **Ehrlich statt schoen.** Findet der Skeptiker echte Blocker, die in 3 Runden nicht loesbar sind,
  gehoeren sie als „ungeloest: …" ins Dokument — nicht wegreden.
- **Security-Config ist TABU** (Tokens, approvals, ssh, sudoers) — hier ohnehin nichts zu suchen.

## Die Helfer EXISTIEREN
`~/.hermes/scripts/worker.sh` und `~/.hermes/scripts/fremdblick.sh` sind installiert, aber NICHT auf
dem PATH → immer mit vollem Pfad rufen. Glaubst du, sie fehlen, IRRST du dich: erst
`ls -la ~/.hermes/scripts/worker.sh` ausfuehren, dann nutzen. „Skript fehlt" ist KEIN Grund, den
Schritt selbst zu erledigen.

## Ablauf

### 0. Ablage + Recherche (DU, mit deinen eigenen Web-Tools)
`worker.sh`/`fremdblick.sh` haben KEIN Web. Die **tagesaktuelle Recherche** machst DU selbst mit
deinem web-fetch-Tool — das ist dein Job als Manager, nicht der der zustandslosen Worker.
```bash
slug=<kurzer-kebab-name-der-idee>
mkdir -p /tmp/konzept-$slug
```
Recherchiere knapp: Was gibt es schon (Konkurrenz-Apps/-Produkte)? Was fehlt denen? Welche
Technik/Trends sind 2026 relevant? Schreibe die Fakten (mit Quelle) nach
`/tmp/konzept-$slug/recherche.md`. Kurz und belegt — kein Roman.

### 1. Rollen-Cast waehlen (heavy)
heavy legt den passenden Cast fuer GENAU dieses Konzept fest (ein Spiel braucht andere Rollen als
ein Produktivitaets-Tool). Der **Advocatus Diaboli ist immer dabei** — aber der ist der Skeptiker
in Schritt 4 (fremdblick), NICHT eine der heavy-Rollen.
```bash
printf '%s' "IDEE:
$idee

RECHERCHE:
$(cat /tmp/konzept-$slug/recherche.md)

Nenne die passenden Fach-Rollen, die dieses Konzept am besten wasserdicht machen — 2 fuer ein kleines/klar umrissenes Projekt, 3 fuer ein mittleres, 4-5 nur fuer ein grosses/ambitioniertes. Lieber weniger, gute Rollen. Je Rolle: Name + ein Satz, worauf sie besonders achtet. Gib NUR die nummerierte Liste aus." \
 | WORKER_MODEL=gpt-oss-120b WORKER_ROLE=prose WORKER_MAXTOK=6000 ~/.hermes/scripts/worker.sh > /tmp/konzept-$slug/cast.txt
cat /tmp/konzept-$slug/cast.txt
```

### 2. Erstentwurf (heavy, Editor-Hut)
heavy schreibt den ersten Konzept-Entwurf aus Idee + Recherche in der **Struktur aus Schritt 5**
nach `/tmp/konzept-$slug/konzept.md` — das ist ab jetzt das **lebende Dokument** (die Wahrheit,
nicht das Protokoll).

### 3. Denk-Runde (heavy, je Rolle EIN Aufruf, am Stueck)
Fuer jede Rolle aus `cast.txt` ein heavy-Aufruf. Gib ihr das **aktuelle** `konzept.md`, ab Runde 2
zusaetzlich die **offenen Blocker** aus dem letzten Haertetest, und die klare Anweisung, aus IHRER
Sicht zu schaerfen UND zu kritisieren (nicht nur zu loben):
```bash
printf '%s' "Du bist die Rolle: <Rolle aus cast.txt>. Schaerfe und kritisiere das folgende Konzept AUS DEINER FACHSICHT: was ist schwach, unrealistisch, unklar, was fehlt? Nenne konkrete Verbesserungen, keine Hoeflichkeiten.

AKTUELLES KONZEPT:
$(cat /tmp/konzept-$slug/konzept.md)

OFFENE BLOCKER (falls Runde >= 2):
$(cat /tmp/konzept-$slug/haertetest-*.txt 2>/dev/null | tail -40)" \
 | WORKER_MODEL=gpt-oss-120b WORKER_ROLE=prose WORKER_MAXTOK=6000 ~/.hermes/scripts/worker.sh > /tmp/konzept-$slug/runde<n>-<rolle>.txt
```
Sammle die Beitraege und **webe sie ins `konzept.md` ein** — Widerspruecke aufloesen, verdichten,
nicht bloss anhaengen. Halte das Dokument kompakt (heavy-32k-Limit).

### 4. Haertetest (Advocatus Diaboli = fremdblick, GLM)
Ein FREMDES Modell sucht Loecher im aktuellen Konzept:
```bash
printf '%s' "$(cat /tmp/konzept-$slug/konzept.md)" \
 | FREMDBLICK_SYS='Du bist der Advocatus Diaboli und ausdruecklich ein ANDERES Modell als der Autor. Zerlege dieses Konzept schonungslos: ungeloeste Fragen, unrealistische Annahmen, Widersprueche, fehlende Bausteine, Dinge die in der Praxis scheitern. Liste je Punkt EINE Zeile, markiert mit BLOCKER: (muss geloest werden, sonst nicht baubar) oder HINWEIS: (verbessert es, kein Muss). Ist nichts Wesentliches mehr offen, antworte NUR mit dem Wort WASSERDICHT. Nicke nichts aus Hoeflichkeit durch, erfinde keine Fakten.' \
    FREMDBLICK_MAXTOK=4000 ~/.hermes/scripts/fremdblick.sh > /tmp/konzept-$slug/haertetest-<runde>.txt
cat /tmp/konzept-$slug/haertetest-<runde>.txt
```
**Schleifen-Regel (hart, max 3 Runden):**
- Antwort enthaelt `BLOCKER:` UND Runde < 3 → zurueck zu Schritt 3, die Blocker adressieren.
- Antwort = `WASSERDICHT` (oder nur `HINWEIS:`) → weiter zu Schritt 5.
- Runde 3 erreicht → weiter zu Schritt 5, egal was offen ist (offene Blocker kommen in Abschnitt 8).

### 5. Endfassung (heavy, Editor)
heavy schreibt die finale, saubere Fassung nach dieser festen Struktur (ueberschreibt `konzept.md`):
```
# <Projektname> — Konzept
1. Problem & Motivation      (warum das ueberhaupt)
2. Zielgruppe                (fuer wen genau)
3. Kern-Idee                 (ein Absatz, der es auf den Punkt bringt)
4. Features                  (Muss / Kann / Spaeter)
5. Mechaniken & Ablauf       (wie es sich anfuehlt, der rote Faden)
6. Tech-Vorschlag            (Plattform, Stack — und ist das Box-/PC-tauglich?)
7. UX-Flow                   (die 3-5 wichtigsten Screens/Schritte)
8. Risiken & offene Punkte   (ehrlich, inkl. ungeloester Blocker aus dem Haertetest)
9. MVP-Schnitt               (was ZUERST gebaut wird — der spaetere Coder-Auftrag)
```
Dann eine Kopie an den Abhol-Ort:
```bash
mkdir -p ~/konzepte && cp /tmp/konzept-$slug/konzept.md ~/konzepte/$slug-konzept.md
```

### 6. Uebergabe (Telegram, in LUCYS Stimme)
```bash
bash ~/mission-control-v2/deploy/notify.sh -s "[Konzept]" "<text>"
```
Der Text: erst 1-2 Saetze, was erarbeitet wurde und dass es fertig zum Bauen ist; dann knapp:
- der **Cast** (welche Rollen mitgedacht haben),
- **Runden + Haertetest-Ergebnis** (wasserdicht nach n Runden / welche Blocker offen blieben),
- der **Pfad**: `~/konzepte/$slug-konzept.md`,
- der **naechste Schritt fuer den Commander:** „In Hermes Desktop ein neues Projekt starten und dieses
  Konzept als Vorlage geben (projekt-start) — dann baut der Coder."
Passt das ganze Konzept unter ~3500 Zeichen, haeng es direkt an die Nachricht. Sonst nur die
Zusammenfassung + Pfad.

### 7. Belege (Pflicht — gegen Selbst-Erfindung)
In deiner Antwort/Uebergabe nachweisen, dass wirklich delegiert wurde: je Rolle der `worker.sh`-
Aufruf + die erste Zeile ihrer Roh-Ausgabe, und je Runde das Haertetest-Urteil. **Kein Beleg =
GESCHEITERT** (dann hast du selbst geschrieben statt heavy — das ehrlich sagen, nicht kaschieren).

### 8. Nichts loeschen
`/tmp/konzept-$slug/` (Recherche, Cast, Runden, Haertetests, konzept.md) bleibt liegen, bis der
Commander das Konzept angenommen oder verworfen hat.

## Kontext-Uebergabe — hier geht es am ehesten schief
`worker.sh`/`fremdblick.sh` starten **frisch und zustandslos**: kein Gedaechtnis der Runden, kein
Zugriff auf Dateien. Sie sehen NUR, was du ihnen auf stdin gibst. Deshalb:
- Immer das **aktuelle `konzept.md`** komplett mitgeben — nie „wie eben besprochen".
- heavy hat nur **32k Kontext** → das Dokument kompakt halten, alte Runden-`.txt` NICHT in den
  Prompt schleppen (nur die offenen Blocker aus dem letzten Haertetest zaehlen).
- Zu wenig Kontext → die Rolle raet. Zu viel Altlast → sie verliert den Fokus. Ziel: das kleinste,
  das den aktuellen Stand eindeutig macht.