Files

T

Hitonabi 6d3a0bf3a6 IDE-Skill 'projekt-uebernehmen': vorbereitetes Projekt in Zed starten

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 <noreply@anthropic.com>

2026-07-21 10:41:59 +02:00

4.5 KiB

Raw Permalink Blame History

name, description, metadata

name

description

metadata

projekt-uebernehmen

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.

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

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.
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.
Bauen: kleine Schritte, ein Sicherungspunkt (Commit mit klarem Namen) je Meilenstein und vor riskanten Änderungen. Am Ende live testen — beweisen statt behaupten.
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.

4.5 KiB Raw Permalink Blame History Unescape Escape