d5da853db2
Zweiter, dezenter Schalter (nur bei IDE): Ziel = LXC (Standard) oder Docker. Die Wahl fliesst als 'ZIEL-PLATTFORM'-Zeile in den Auftrag, dazu immer ein Infrastruktur-Steckbrief (Proxmox/LXC, PBS-Backups, systemd, self-hosted Gitea, alles lokal) — sonst plant jedes Modell nach Industrie-Default Docker/Cloud. Skill: Ziel + Infrastruktur sind bindend; traegt die Wahl nicht, muss das Konzept es ausdruecklich sagen statt sie still zu ignorieren. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
216 lines
15 KiB
Markdown
216 lines
15 KiB
Markdown
---
|
|
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 Proxmox mit LXC-Containern, systemd-Dienste, self-hosted Gitea, alles lokal;
|
|
„einfach mal Docker" ist bei ihm NICHT automatisch die einfachste Loesung. 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
|
|
```
|
|
|
|
### 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.
|