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.
- **★ ZIEL-PLATTFORM + INFRASTRUKTUR aus dem Auftrag sind BINDEND.** Stehen im Auftrag Zeilen
  „ZIEL-PLATTFORM (vom Commander gewaehlt): LXC/DOCKER …" und/oder „INFRASTRUKTUR des Commanders:
  …", dann plane den Tech-Vorschlag (Abschnitt 6) GENAU dafuer — nicht nach Industrie-Default.
  Der Commander faehrt ein Heimlabor mit Proxmox/LXC, systemd-Diensten und self-hosted Gitea, alles
  lokal — „einfach mal Docker" ist bei ihm NICHT automatisch die einfachste Loesung. Die beiden
  Ziele sind sauber getrennt: **LXC** = Dienst im Proxmox-Container (systemd, PBS sichert mit);
  **DOCKER** = NATIVES Docker nach Standard-Praxis (Dockerfile, compose, portabel, ueber
  CI-Pipelines baubar) — dieses Projekt darf bewusst ausserhalb der LXC-Welt leben, also KEINE
  Misch-Konstrukte wie „Docker im LXC mit Nesting" vorschlagen. Traegt die gewaehlte Plattform fuer
  dieses Projekt nicht (noetige Komponente gibt es nur als Image o. ae.), sag das im Konzept
  AUSDRUECKLICH mit Begruendung — still ignorieren gilt nicht.
- **★ 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
```

> **Arbeitest du an einer Kanban-Karte, sind Schritt 5-Kopie und Schritt 6 NICHT dein Ende.**
> Die Ablage- und Uebergabe-Wege deiner Rolle (Profil-SOUL) gelten — z. B. `projektstart`:
> Konzept ins **Repo** als `KONZEPT.md`, dann `kanban_complete`. Die Kopie nach `~/konzepte/`
> ist dann nur ein Zweitablage-Ort, kein Abschluss. Nur ohne Karte (direkter Zuruf) endet
> das Fliessband hier mit Schritt 6.

### 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.