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.
• ★ 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

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.