From 6d3a0bf3a62b051991c1064dec04ad69bfea195f Mon Sep 17 00:00:00 2001 From: Hitonabi Date: Tue, 21 Jul 2026 10:41:59 +0200 Subject: [PATCH] IDE-Skill 'projekt-uebernehmen': vorbereitetes Projekt in Zed starten MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Der Weg von der Box in die IDE endete bisher am Repo: der Commander klont es, oeffnet Zed/OpenCode — und der Agent weiss nicht, dass hier bereits ein gehaertetes Konzept liegt. Ohne Anleitung plant er entweder neu (projekt-start springt an) oder fragt ins Blaue. - client/ide-skills/projekt-uebernehmen/SKILL.md (Quelle im Repo, installiert nach ~/.agents/skills/ — dort liegen die uebrigen PC-Skills, OpenCode 1.18 laedt von dort). Ablauf: einlesen (Konzept/Roadmap/Savepoint + git-Stand) -> 3-6 blockierende Fragen MIT Empfehlung -> Etappe-1-Plan -> "los" -> bauen, Savepoints, live testen. Zwei Abbruch-Faelle: schon Code da (dann Fortsetzung nach SAVEPOINT) und nur KONZEPT.md ohne ROADMAP (das ist ein geprueftes Ideen-Repo -> Hinweis auf "Gefaellt mir - Projekt daraus machen"). Modus-Wechsel ist Teil des Skills: lesen/fragen im Planer, bauen im Coder. - deploy/projektstart-SOUL.md: die von der Box erzeugte AGENTS.md nennt den Skill jetzt woertlich. AGENTS.md wird automatisch als Kontext geladen — das ist der zuverlaessige Kanal; auf spontane Skill-Wahl ist bei den lokalen Modellen kein Verlass (nachgemessen: heavy und coder greifen bei einem vagen "ich moechte hier loslegen" NICHT von selbst zum Skill). - ~/.agents/skills/projekt-start/SKILL.md (ausserhalb des Repos) bekam eine Abgrenzungszeile: nicht nutzen, wenn KONZEPT.md + ROADMAP.md schon liegen. Sonst plant er ein vorbereitetes Projekt neu. Co-Authored-By: Claude Opus 4.8 --- .../ide-skills/projekt-uebernehmen/SKILL.md | 76 +++++++++++++++++++ deploy/projektstart-SOUL.md | 4 + 2 files changed, 80 insertions(+) create mode 100644 client/ide-skills/projekt-uebernehmen/SKILL.md diff --git a/client/ide-skills/projekt-uebernehmen/SKILL.md b/client/ide-skills/projekt-uebernehmen/SKILL.md new file mode 100644 index 0000000..8b8b175 --- /dev/null +++ b/client/ide-skills/projekt-uebernehmen/SKILL.md @@ -0,0 +1,76 @@ +--- +name: projekt-uebernehmen +description: Ein von der AI-Box vorbereitetes Projekt in Zed uebernehmen und starten - Konzept und Roadmap einlesen, die offenen Punkte mit dem Commander klaeren, dann Etappe 1 planen und bauen. Nutze diesen Skill beim ERSTEN Chat in einem Projekt-Ordner, der KONZEPT.md und ROADMAP.md enthaelt, aber noch keinen (oder kaum) eigenen Code - also bei jedem frisch vorbereiteten Repo aus dem Auftragsbuch. +metadata: + quelle: mission-control-2/client/ide-skills +--- + +# Vorbereitetes Projekt übernehmen + +Die Box hat gedacht, du baust. Das Konzept in diesem Ordner ist **bereits gehärtet** — mehrere +Fach-Rollen und ein Advocatus Diaboli haben es auf der Box durchgearbeitet. Deine Aufgabe ist +nicht, es neu zu denken, sondern es umzusetzen. + +**Zwei Modelle, ein Ablauf:** Stufe 1 und 2 (einlesen, nachfragen, planen) gehören in den +**Planer**, Stufe 3 (bauen) in den **Coder**. Du kannst nicht selbst umschalten — wenn der Plan +freigegeben ist, bitte den Commander ausdrücklich darum, oben im Modellwähler auf Coder zu +wechseln. Läufst du schon im Coder, ist das auch in Ordnung: dann gilt trotzdem erst lesen, +fragen, Plan zeigen — und **keine Datei vor seinem „los"**. + +Drei Stufen, in dieser Reihenfolge. **Vor Stufe 3 wird keine Datei angefasst.** + +## 1. Einlesen — still, ohne Rückfragen + +Lies, was da ist: `KONZEPT.md`, `ROADMAP.md`, `AGENTS.md`, `SAVEPOINT.md`, `README.md`. +Verschaff dir den Ist-Zustand: `git log --oneline -5` und den Dateibaum. + +Zwei Abbruch-Fälle — prüfe sie ZUERST: + +- **Es gibt schon Code und Historie.** Dann ist das keine Übernahme, sondern Fortsetzung: + arbeite nach `SAVEPOINT.md` weiter und sag in zwei Sätzen, wo ihr steht. Dieser Skill ist + hier fertig. +- **Nur `KONZEPT.md` + `README.md`, keine `ROADMAP.md`.** Das ist ein *geprüfte-Idee*-Repo, kein + startklares Projekt — die Box legt bei „Idee prüfen" bewusst kein Gerüst an. Sag dem Commander: + *„Das ist bisher nur ein durchdachtes Konzept, noch kein Projekt. Im Auftragsbuch gibt es auf + der Karte den Knopf ‚Gefällt mir — Projekt daraus machen'; danach hat das Repo eine Roadmap und + ich kann loslegen."* Dann **STOPP**, nichts bauen. + +Sonst: fasse in **höchstens 8 Zeilen** zusammen — was gebaut wird, für wen, welche Technik, +und was laut Roadmap **Etappe 1** ist. Alltagssprache, keine Fachbegriffe ohne Übersetzung. + +## 2. Fragen stellen — der eigentliche Wert dieses Schritts + +Stell **3 bis 6 Fragen**. Nicht mehr, und nur solche, die den Start wirklich blockieren. + +- **Nichts fragen, was in den Dokumenten steht.** Wer das Konzept nicht gelesen hat, merkt man + genau hier. +- Jede Frage: eine Zeile, Alltagssprache, **mit deiner Empfehlung** („ich würde X nehmen, weil …"). + Der Commander ist kein Entwickler — frag nach Zielen, Vorlieben und Gegebenheiten, nie nach + Bau-Prinzipien oder Architektur-Geschmack. Das ist dein Job. +- Die üblichen echten Lücken: Wo läuft es am Ende? Welche Zugänge/Geräte/Pfade brauchst du von + ihm? Was ist in Etappe 1 ausdrücklich **nicht** drin? Woran merkt ihr beide, dass Etappe 1 + fertig ist? +- Der Abschnitt „offene Punkte" / „Risiken" im Konzept ist deine Fundgrube — genau dafür steht er da. + +Dann **warten**. Keine Annahmen, kein Vorpreschen, kein „ich fange schon mal an". + +## 3. Plan → „los" → bauen + +1. **Etappe-1-Plan** vorlegen: Ziel · Vorgehen in kleinen Schritten · Technik und warum · + Fertig-Kriterien · Risiken. Etappe 1 muss **für sich lauffähig** sein — eine halbe Baustelle ist + kein Meilenstein. +2. **STOPP**, auf sein „los" warten. Danach der Satz, den er hören muss: *„Bitte oben im + Modellwähler auf **Coder** umschalten, dann lege ich los."* Umschalten kannst du nicht selbst. +3. Bauen: kleine Schritte, ein Sicherungspunkt (Commit mit klarem Namen) je Meilenstein und vor + riskanten Änderungen. Am Ende **live testen** — beweisen statt behaupten. +4. Nachführen: `SAVEPOINT.md` (Stand, nächster Schritt, offene Fragen) und die erledigte Etappe in + `ROADMAP.md` abhaken. Das ist das Gedächtnis für den nächsten Chat. + +## Merksätze + +- **Du denkst das Konzept nicht neu.** Findest du einen echten Widerspruch oder eine Lücke: + benenne sie und frag — bau nicht still etwas anderes. +- **Nichts bauen, was nicht in Etappe 1 steht.** Ideen für später gehören in die Roadmap, nicht + in den Code. +- Geheimnisse (Schlüssel, Passwörter, Tokens) nie in den Code — `.env` plus `.gitignore`. +- Klemmt dieselbe Sache zweimal: anhalten, sichern, erklären, fragen. diff --git a/deploy/projektstart-SOUL.md b/deploy/projektstart-SOUL.md index 3f63869..cb541d3 100644 --- a/deploy/projektstart-SOUL.md +++ b/deploy/projektstart-SOUL.md @@ -87,6 +87,10 @@ genau diese Dateien — sonst **nichts**, kein Code, kein Gerüst: - **`AGENTS.md`** — Arbeits-Konventionen für den Zed-Coder (nach dem `projekt-start`-Ritual): Deutsch/Nicht-Entwickler, Plan-vor-Code, kleine Schritte, beweisen statt behaupten, Savepoints, Box-Modelle je Aufgabe (plan=heavy, build=coder). Kurz, konkret, projektbezogen. + **Ganz oben hinein — wörtlich:** „Dieses Projekt ist von der AI-Box vorbereitet: KONZEPT.md ist + bereits gehärtet, ROADMAP.md ist der Plan. Beim ersten Chat den Skill **`projekt-uebernehmen`** + nutzen (einlesen → nachfragen → Etappe 1) — das Konzept wird NICHT neu geplant." + Das ist die Übergabe an den Agenten in Zed; ohne diese Zeile fängt er womöglich von vorn an. - **`README.md`** — was das Projekt ist, in Alltagssprache; erste Schritte zum Loslegen in Zed. - **`SAVEPOINT.md`** — Startzustand: „vorbereitet — Bau beginnt in Zed", Stand/nächste Schritte/ offene Fragen (lebendes Übergabe-Dokument für den ersten Zed-Chat).