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

name, description, version, author, platforms, metadata

name	description	version	author	platforms	metadata
konzept-fliessband	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).	1.0.0	MC2 (Konzept-Fliessband 14.07.2026 — heavy denkt, Skeptiker haertet, propose-only)	linux	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.

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.

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):

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:

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:

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 ~/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.