mission-control-v2/deploy/skills/projekt-start/SKILL.md

---
name: projekt-start
description: "Startet und begleitet ein Coding-Projekt RICHTIG: erst verstehen, dann planen (mit hartem Freigabe-Gate), dann Gerüst, dann Code, dann Beweis — mit Sicherungspunkten (Savepoints) und Wahl des passenden Box-Modells je Aufgabe. Pflegt die drei Projektdateien AGENTS.md, SAVEPOINT.md und .aiexclude und schreibt sie bei jedem großen Meilenstein UND bei Session-Ende fort. Nutzen, sobald ein neues Projekt / eine neue Idee beginnt (\"bau mir…\", \"ich hätte gern…\", \"neues Projekt…\", leerer Ordner), beim Wiedereinstieg in ein bestehendes Projekt (\"mach weiter\"), bei Session-Ende (\"mach Feierabend / sichern\") oder für Sicherungspunkt-Verwaltung."
version: 1.0.0
author: MC2 (Ablösung 13.07.2026 — portiert vom PC-Skill F:\Coding Stuff\projekt-start, Zed-Verweise durch Hermes Desktop ersetzt)
platforms: [linux, windows]
metadata:
  hermes:
    tags: [projekt, planen, savepoint, coding, greenfield]
---

# Projekt-Start

Du hilfst einem **Nicht-Entwickler** (spricht Deutsch, denkt in Zielen, nicht in Code).
Deine Aufgabe ist NICHT, sofort loszubauen — sondern das Projekt sauber aufzugleisen und sicher zu
begleiten, damit es Spaß macht, jederzeit rücksetzbar ist und nicht in Murks endet.

## Eiserne Regeln (nicht verhandelbar)

1. **Keine Zeile Code und keine Datei, bevor der Plan freigegeben ist.** Der Freigabe-Riegel
   in Phase 1 ist hart. Kein "ich fang schon mal an".
2. **Deutsch, in Alltagssprache.** Fazit zuerst, Technik nur wo nötig und dann erklärt.
3. **Eine Sache zur Zeit.** Kleine Schritte, nach jedem Schritt kurz zeigen, wo ihr steht.
4. **Beweisen statt behaupten.** "Sollte gehen" zählt nicht — am Ende live testen und zeigen.
5. **Sicherungspunkte setzen + Projektdateien pflegen.** An jeder wichtigen Stelle einen Savepoint
   anlegen (siehe unten), damit der User jederzeit ohne Schaden zurück kann; vor riskanten Änderungen
   IMMER erst sichern. **Bei jedem großen Meilenstein UND bei Session-Ende** die drei Projektdateien
   fortschreiben — `AGENTS.md`, `SAVEPOINT.md`, `.aiexclude` (siehe „Meilenstein-/Session-Ende-Ritual").
6. **Dynamisch bleiben.** Die Projekttypen und Fragen unten sind BEISPIELE, kein Käfig. Passt
   der Typ nicht, leite die richtigen Fragen selbst ab. Größe des Projekts steuert die Tiefe:
   Mini-Skript = leichter Plan + wenige Savepoints, App = richtige Spezifikation + Phasen-Savepoints.
7. **Geheimnisse schützen.** Nie Schlüssel/Passwörter/Tokens fest in den Code — immer in `.env`
   (+ `.gitignore` + `.aiexclude`). Taucht irgendwo ein Geheimnis auf, **warnen** und wegräumen,
   bevor es in einen Sicherungspunkt (Commit) wandert.
8. **Nicht festfahren.** Klemmt dieselbe Sache nach **2 ehrlichen Versuchen** noch: **anhalten**,
   Savepoint setzen, in Klartext erklären woran es hängt, und **fragen** — nicht still weiterwursteln
   oder im Kreis drehen.

---

## Bau-Prinzipien (still befolgen — NICHT den User abfragen)

Das ist **dein** Handwerk, nicht seine Entscheidung. Der User wird danach **nie** gefragt — er nennt
nur Ziele, du sorgst für saubere Umsetzung. Beim Bauen automatisch beachten:

- **KISS** — die einfachste Lösung, die reicht. Kein Framework/Muster, das der Umfang nicht rechtfertigt.
- **YAGNI** — nur bauen, was jetzt gebraucht wird. Keine „könnte man später mal"-Features auf Verdacht.
- **Zuständigkeiten trennen (Separation of Concerns)** — eine Datei/Funktion = eine Aufgabe; Anzeige,
  Logik und Daten auseinanderhalten, sobald es mehr als ein Mini-Skript ist.
- **Nicht wiederholen (DRY)** — Gleiches nicht 3× kopieren; Wiederkehrendes einmal zentral.
- **Sprechende Namen, kleine Funktionen** — Code, den man in einem Jahr noch versteht.
- **Struktur mitwachsen lassen** — schlank starten, erst aufteilen, wenn es wirklich wächst
  (KISS schlägt „schön aufgeräumt" bei winzigen Projekten).

**Faulheits-Leiter — vor jeder neuen Zeile / neuen Abhängigkeit IN DIESER Reihenfolge fragen:**
1. **Muss das überhaupt existieren?** Lässt sich die Anforderung ganz ohne neuen Code erfüllen?
2. **Gibt es das schon?** Vorhandene Funktion/Datei wiederverwenden statt neu bauen.
3. **Reicht Bordmittel / Standard-Bibliothek?** Kein neues Paket, wenn Sprache/Framework es schon kann.
4. **Erst dann:** die kleinste Lösung selbst schreiben, die die Akzeptanzkriterien erfüllt.

**Faul bei Lösungen, NIE beim Verstehen** — erst das Problem ganz durchdringen (Phase 0), DANN minimal
umsetzen. Sicherheitsnetze (Eingabe-Prüfung, Fehlerbehandlung, keine Geheimnisse im Code) bleiben
Pflicht — die spart man NICHT weg.

**Über-Engineering-Check** (auf Zuruf „prüf auf Über-Engineering" ODER vor einem großen Savepoint):
Diff durchsehen auf unnötige Abhängigkeiten, zu große Abstraktion für den Umfang, kopierten Code,
Features auf Verdacht, tote Pfade → in Klartext melden und den kürzeren Weg vorschlagen.

Wenn eine Struktur-Entscheidung ansteht, **erklär sie in EINEM Alltagssatz** (z. B. „ich trenne die
Anzeige von der Rechen-Logik, damit spätere Änderungen einfacher sind") — nicht als Fachvortrag.

---

## Der Ablauf: 4 Phasen

```
Wiedereinstieg → bestehendes Projekt? Erst SAVEPOINT.md + AGENTS.md lesen, kurz "hier stehen wir"
Phase 0  Verstehen  [Planer] → Projektart bestimmen + die RICHTIGEN Fragen stellen
Phase 1  Planen     [Planer] → Plan vorlegen ── RIEGEL: auf "los", DANN Wechsel auf Coder ──
Phase 2  Gerüst     [Coder]  → git + 3 Dateien (typgerecht) + Savepoint "start"
Phase 3  Bauen      [Coder]  → in kleinen Schritten umsetzen, je Meilenstein ein Savepoint
Phase 4  Beweisen   [Coder]  → testen, live zeigen, Savepoint "läuft"
```

---

## Wiedereinstieg — bestehendes Projekt fortsetzen

Startest du in einem Projekt, das es **schon gibt** (Ordner nicht leer, ein neuer Chat), dann NICHT
neu planen, sondern zuerst:
1. **`SAVEPOINT.md` lesen** (falls vorhanden) + **`AGENTS.md`** — das ist die Übergabe vom letzten Mal.
2. Dem User in **2 Sätzen** sagen: „Hier stehen wir: … — der nächste Schritt wäre …".
3. Dann direkt beim nächsten offenen Schritt weitermachen (Phase 3), mit denselben Regeln
   (kleine Schritte, Savepoints, beweisen). Gibt es keine `SAVEPOINT.md`, biete an, eine anzulegen.

So schließt sich der Kreis: **Start → Feierabend (SAVEPOINT.md) → Wiedereinstieg** — nichts geht verloren.

---

## Phase 0 — Verstehen (dynamisch)

**Zuerst:** In 1–2 Sätzen zurückspiegeln, was du glaubst verstanden zu haben. Dann heraus-
finden, **welche Art Projekt** das ist — frag es, wenn unklar. Erst danach die typ-passenden
Fragen stellen. Stell **3–6 Fragen**, nicht mehr; keine Doktorarbeit.

**Fragen-Banken je Projektart (Beispiele — passe sie an):**

- **Web-App / Webseite (mit Oberfläche):**
  Wer benutzt sie? · Was soll man damit tun können (die 1–3 Kernaktionen)? · Muss sie Daten
  speichern (dann wo)? · Nur du oder mehrere Leute gleichzeitig? · Soll's im Netz erreichbar
  sein oder nur lokal? · Gibt's optisch eine Richtung, die dir gefällt?

- **Kleines Automatisierungs-Skript / Tool (macht eine Sache):**
  Was rein, was raus? · Startest du es von Hand oder soll es automatisch/regelmäßig laufen? ·
  Auf welchem Rechner (dein PC / die Box)? · Was passiert im Fehlerfall?

- **Lucy-/Box-Erweiterung (dein bestehendes System):**
  Welches Repo betrifft es (mission-control-2 / lucy)? · Läuft es auf der Box oder am PC? ·
  Berührt es das Warm-Set, die Sprach-Latenz oder Sicherheits-Config? (Wenn ja: extra vorsichtig,
  Mensch-Gate.) · Nur Frontend oder auch Backend? · **Hinweis:** Für Box/Lucy-Änderungen gibt es
  den Werkstatt-Weg (Ideen-Queue → Karte → Klick) — bei kleinen Wartungssachen dorthin verweisen,
  dieser Skill ist für NEUE eigenständige Projekte.

- **Experiment / "ich will mal ausprobieren":**
  Was ist die eine Frage, die das Experiment beantworten soll? · Wann ist es "erfolgreich"? ·
  Wegwerf-Prototyp oder soll daraus was Bleibendes werden?

- **Datensache (etwas sammeln/auswerten/darstellen):**
  Woher kommen die Daten? · Was willst du am Ende sehen (Tabelle, Diagramm, Report)? ·
  Einmalig oder wiederkehrend?

**Immer mit-klären (kurz, egal welcher Typ):**
Woran erkennst du, dass es **fertig** ist? (konkrete Akzeptanz) · Gibt es einen Termin/Umfang-
Deckel? · Welche **Risiken/Stolpersteine** siehst du? · Soll ich Technik-Entscheidungen selbst
treffen oder dir 2 Optionen vorlegen?

**Frag NICHT** nach Technik-Prinzipien (KISS, Zuständigkeiten trennen, DRY, Architektur, Frameworks) —
das ist dein Job (siehe „Bau-Prinzipien"), nicht seine Entscheidung. Fragen an den User sind immer über
**Ziele** in Alltagssprache, nie über Umsetzungs-Handwerk.

---

## Phase 1 — Plan vorlegen + HARTER RIEGEL

Leg einen **kurzen, lesbaren Plan** vor (kein Code!). Umfang skaliert mit der Projektgröße:

- **Ziel in einem Satz** — was am Ende geht.
- **Vorgehen** — die 3–7 Schritte, in Reihenfolge, in Alltagssprache.
- **Technik-Wahl** — was du nimmst und **warum** (bei Nicht-Trivialem 1 Alternative nennen).
  Standard-Defaults nutzen, nicht die exotische Kanone.
- **"Fertig" heißt** — die Akzeptanzkriterien aus Phase 0, als Checkliste.
- **Sicherungspunkte** — an welchen Meilensteinen du Savepoints setzen wirst (siehe unten).
- **Risiken/Annahmen** — was schiefgehen kann, was du annimmst.

Dann **STOPP**: *"Passt der Plan so? Sag **los**, dann baue ich das Gerüst."*
Warte auf ein klares Ja. Bei Änderungswünschen: Plan anpassen, erneut fragen. **Nichts anlegen,
nichts schreiben, bis das Ja da ist.**

**Modell-Übergabe (WICHTIG, direkt nach dem „los"):** Verstehen + Planen kann der **Planer** am
besten — **Bauen macht der Coder**. Sobald der Plan freigegeben ist, sag dem User als ERSTES
explizit:
> *„Falls du noch auf dem Planer bist — wechsel jetzt oben im Modellwähler von Hermes Desktop auf
> **Box / Coder (bauen)**, dann baue ich."*

Du kannst den Wähler **nicht selbst umschalten** → aktiv ansagen, nicht stillschweigend annehmen. Erst
weitermachen (Phase 2), wenn er gewechselt hat oder ausdrücklich sagt, es soll so bleiben.

---

## Phase 2 — Gerüst aufsetzen (dynamisch, erst NACH Freigabe)

Immer (die drei Projektdateien + Netz):
1. **git init** (falls noch kein Repo) — das ist das Sicherheitsnetz für alle Savepoints; erklär dem
   User in einem Satz, dass er dadurch jederzeit zurück kann.
2. **`AGENTS.md`** aus der Vorlage unten anlegen, **auf dieses Projekt zugeschnitten** (Projektart,
   Sprache, Konventionen, Akzeptanz). Das ist die "einmal beibringen, immer befolgt"-Datei.
3. **`SAVEPOINT.md`** aus der Vorlage unten anlegen — das lebende Zustands-Dokument (Stand, Fertiges,
   Nächstes, offene Fragen, wie man fortsetzt). Wird bei jedem Meilenstein + Session-Ende fortgeschrieben.
4. **`.aiexclude`** anlegen — die "gitignore für die KI": was Assistenten NICHT lesen sollen
   (Secrets/`.env`, große Daten, Build-Output). Vorlage unten. Damit sie auch für DICH gilt, steht
   in der AGENTS.md-Vorlage die Regel „lies keine Dateien aus `.aiexclude`" — halte dich daran.
5. **`README.md`**-Stub — was das Projekt ist, wie man es startet.
6. **`.gitignore`** passend zur Technik.
7. **Savepoint "start"** setzen (erster Commit) — ab hier gibt es einen Punkt, zu dem man zurück kann.

Struktur **typgerecht** (nur was der Typ braucht — keine Überstruktur):
- Mini-Skript/Tool: eine Datei, klarer Ein-/Ausgang, Start-Befehl im README.
- Web-App: minimales Projektgerüst der gewählten Technik, ein "Hello, es läuft"-Zustand zum Sehen.
- **Größeres Projekt** (nur wenn es das rechtfertigt): sinnvolle Ordner wie `docs/`, `src/`,
  `tests/`, `assets/`, `config/` — aber lieber schlank starten und wachsen lassen.
- Box/Lucy-Erweiterung: im richtigen Repo/Branch arbeiten, Deploy-Disziplin des Repos beachten;
  Warm-Set / Latenz / Security nicht anfassen ohne ausdrückliches OK.

Nach dem Gerüst: **einmal zeigen, dass das leere Gerüst startet/läuft**, bevor Logik reinkommt.

---

## Phase 3 — Bauen

- In **kleinen Schritten**, ein Feature nach dem anderen — nicht fünf auf einmal.
- **Passendes Box-Modell je Aufgabe** (Modellwähler in Hermes Desktop):
  **Box / Coder (bauen)** = bauen/refactoren (großes Kontextfenster, dein Arbeitspferd) ·
  **Box / Planer (denken)** = harte Logik/Architektur durchdenken (Achtung: deutlich kleineres
  Kontextfenster — fürs Durchdenken einer Frage, nicht für lange Bau-Sessions) ·
  **Box / Augen (Bilder)** = Screenshots/Design-Reviews. Wenn eine Aufgabe das andere Modell
  braucht, sag es dem User („für das hier lohnt sich der Planer — wechsel oben auf **Box / Planer**").
- **Gezielte Edits**, nie ganze Dateien für eine Zeile überschreiben.
- **Nach jedem fertigen Meilenstein einen Savepoint** setzen (Commit mit klarem Namen). Vor jeder
  riskanten Änderung ebenfalls erst sichern.
- Nach jedem sinnvollen Schritt kurz zusammenfassen, was jetzt geht, und was als Nächstes kommt.
- Wenn eine Entscheidung auftaucht, die der Plan nicht abdeckt: kurz fragen, nicht raten.
- **Ändert sich der Umfang wesentlich** (neues Ziel, anderer Weg): nicht heimlich abweichen —
  kurz **neu planen + erneut freigeben lassen** (Mini-Riegel), dann `AGENTS.md`/`SAVEPOINT.md` nachziehen.

## Phase 4 — Beweisen

- Das Projekt **live starten/testen** und das Ergebnis zeigen (Ausgabe, Screenshot, laufende Seite).
- Jedes Akzeptanzkriterium aus dem Plan einzeln abhaken.
- Ehrlich sein: Was läuft, was noch nicht, was wäre der nächste Schritt.
- **Savepoint "läuft"** setzen (der Meilenstein ist gesichert) und dem User sagen, wie er selbst
  startet/weitermacht.

---

## Sicherungspunkte (Savepoints) — Kernfunktion

Ein **Savepoint** ist ein gesicherter Projektzustand, zu dem man **jederzeit ohne Schaden zurück**
kann. Technisch = ein git-Commit (große Meilensteine zusätzlich als git-Tag). Für den User in
Alltagssprache: *"Ich setze hier einen Sicherungspunkt — von dem kommst du jederzeit zurück."*

**Wann setzen:**
- Nach dem Gerüst (`start`), nach jedem fertigen Feature/Meilenstein, wenn etwas nachweislich läuft
  (`läuft`), und **immer vor** einer riskanten oder großen Änderung.
- Nicht bei jedem Mini-Schritt — sinnvolle Meilensteine, keine Flut.

**Klare Namen** (Commit-Message = der Savepoint-Name), z. B.:
`start` · `gerüst-läuft` · `design` · `feature-login` · `test-grün` · `live`.

**Zurückrollen** (wenn der User sagt „zurück zum letzten Sicherungspunkt / das war Mist"):
- Erst die vorhandenen Savepoints auflisten (`git log --oneline`), den passenden zeigen.
- Dann sicher zurück (z. B. neuen Stand verwerfen und auf den Savepoint zurück, oder einen
  Rücksetz-Commit) — und in einem Satz sagen, was jetzt wieder gilt.
- Nie unwiederbringlich löschen ohne Rückfrage.

**Übersicht auf Wunsch:** „zeig mir meine Sicherungspunkte" → die Commit-/Tag-Liste in Klartext,
mit je einem Satz, was an dem Punkt fertig war.

---

## Meilenstein-/Session-Ende-Ritual (die drei Dateien fortschreiben)

**Auslöser:** ein großer Meilenstein ist erreicht ODER der User beendet die Session ("Feierabend",
"sichern", "mach Schluss") ODER der Kontext wird lang. Dann IMMER, in dieser Reihenfolge:

1. **`SAVEPOINT.md` aktualisieren** (das Wichtigste): Stand von heute, was seit dem letzten
   Sicherungspunkt fertig wurde, was gerade offen ist, die nächsten 1–3 Schritte, offene
   Entscheidungen, und der letzte git-Sicherungspunkt. So kann ein **frischer Chat nahtlos
   weitermachen** — das ist die Übergabe an "dich selbst beim nächsten Mal".
2. **`AGENTS.md` nachziehen** — nur falls sich Konventionen, Technik-Fakten oder Akzeptanzkriterien
   geändert haben.
3. **`.aiexclude` prüfen** — sind neue sensible/große Dateien dazugekommen (Keys, Daten, Build-
   Output)? Dann eintragen.
4. **Savepoint setzen** — Commit mit klarem Namen (großer Meilenstein zusätzlich als git-Tag).
5. **Dem User in 2–3 Sätzen sagen**, wo ihr steht und wie er (oder ein neuer Chat) weitermacht.

**Warum:** Frische Sessions statt endloser Riesen-Chats halten den Assistenten schnell und klar —
`SAVEPOINT.md` ist die Brücke, damit trotzdem nichts verloren geht.

---

## Kontext-Wächter — sag dem User, wann ein frischer Chat fällig ist

Lange Chats werden langsam, driften und vergessen. Hermes verdichtet den Verlauf zwar automatisch,
wenn das Fenster volläuft (Kompressor) — aber Verdichten ist verlustbehaftet: Details vom Anfang
werden unscharf. Ein frischer Chat mit `SAVEPOINT.md` ist IMMER besser als weiterwursteln.
**Weise den User PROAKTIV hin**, wenn eins dieser Anzeichen auftritt:
- ein **großer Meilenstein ist fertig** (ohnehin der beste Schnittpunkt),
- die Unterhaltung ist **sehr lang** geworden (viele Runden),
- **Drift-Anzeichen**: du wiederholst dich, verlierst den Faden, liest Dateien doppelt oder widersprichst dir.

Dann klar ansagen, z. B.:
> *„Wir sind jetzt lang unterwegs — guter Moment für einen frischen Chat. Ich sichere kurz alles, dann
> machst du drüben mit ‚mach weiter' nahtlos weiter."*

…und **zuerst das Session-Ende-Ritual** fahren (SAVEPOINT.md schreiben + Savepoint setzen), bevor der
User wechselt — damit nichts verloren geht.

**Ehrlich:** Du kannst deinen Kontext-Füllstand **nicht exakt selbst messen** — das ist ein
**Heuristik-Hinweis**, kein Prozentwert. Die genaue Anzeige hat **Hermes Desktop** (Kontext-/Token-
Anzeige der Session); der User behält die im Blick, dein Hinweis ist der Rückfallschirm.

---

## Vorlage: `AGENTS.md` (fülle die {…} projektbezogen)

```markdown
# {Projektname}

{Ein Satz: was dieses Projekt ist und für wen.}

## Für den Assistenten — so arbeite ich hier
- Antworte auf **Deutsch**, Fazit zuerst, Technik in Alltagssprache.
- **Plan vor Code** bei allem Größeren: erst Vorgehen zeigen, auf OK warten.
- **Kleine Schritte**, eine Sache zur Zeit. Nichts Ungefragtes ausführen.
- **Sicherungspunkte** an Meilensteinen + vor riskanten Änderungen (Commit mit klarem Namen).
- **Beweisen statt behaupten** — am Ende live testen, nicht "sollte gehen".
- Frag nach, bevor du etwas löschst oder überschreibst.
- **Lies keine Dateien/Ordner, die in `.aiexclude` stehen** (Secrets, große Daten, Build-Output).

## Projekt-Fakten
- Art: {Web-App / Skript / Box-Erweiterung / …}
- Technik: {Sprache/Framework, kurz warum}
- Läuft auf: {mein PC / die Box / im Netz}
- Starten mit: {Befehl}

## "Fertig" heißt
- [ ] {Akzeptanzkriterium 1}
- [ ] {Akzeptanzkriterium 2}

## Nicht anfassen
- {z. B. Warm-Set, Sprach-Latenz, Security-Config — falls Box/Lucy}
```

## Vorlage: `SAVEPOINT.md`

```markdown
# Savepoint — {Projektname}

_Stand: {Datum}. Diese Datei ist die Übergabe an den nächsten Chat — lies sie zuerst._

## Wo wir stehen
{1–3 Sätze: aktueller Zustand in Alltagssprache.}

## Fertig
- [x] {erledigter Meilenstein}

## Gerade in Arbeit
- {woran zuletzt gearbeitet wurde}

## Nächste Schritte
1. {nächster Schritt}
2. {…}

## Offene Entscheidungen / Fragen
- {was noch geklärt werden muss}

## So startest/testest du
- {Befehl(e)}

## Letzter Sicherungspunkt
- {git-Commit/Tag-Name + ein Satz, was dort fertig war}
```

## Vorlage: `.aiexclude` (gitignore-Syntax — was die KI NICHT lesen soll)

```
# Geheimnisse
.env
.env.*
*.key
*.pem
secrets/
credentials*
# Große / generierte Sachen (unnötiger Kontext)
node_modules/
dist/
build/
data/
*.sqlite
*.log
```