kimal3 0.4.0 → 0.6.0

package/skill/commands/k3plan.md

@@ -0,0 +1,347 @@
+---
+description: Die Specs gegen den Code prüfen und die Planung in die App hochladen
+---
+
+<!-- kimal3:erzeugt — diese Datei wird von `kimal3 skill install` gepflegt und bei
+     jedem Update ueberschrieben. Eigene Aenderungen gehen dabei verloren; wer sie
+     behalten will, kopiert die Datei unter einem anderen Namen. -->
+# Planung prüfen und hochladen
+
+## 1. Wozu
+
+Du prüfst die User Stories in den Specs dieses Projekts gegen den Code und lädst **nur das
+Ergebnis** in die App hoch — nie den Code. Dort sieht der Mensch auf der Projektseite (Reiter
+„Planung"), was offen ist, was auf seinen Test wartet und was fertig ist, und urteilt mit
+„Passt" oder „Passt nicht".
+
+Arbeite die Abschnitte der Reihe nach ab. Die Regeln (Abschnitt 5) und das Dateiformat
+(Abschnitt 6) brauchst du schon ab Abschnitt 2 — lies sie zuerst. Was ein Rückgabewert von
+`kimal3` heißt, steht in **`~/.claude/skills/kimal3/SKILL.md`, Abschnitt „Rückgabewerte"**;
+diese Datei wiederholt es nicht.
+
+🔑 **`/k3plan` prüft, ordnet ein und lädt hoch — es baut nichts.** Was nachzubessern ist, steht
+danach als Befund an der Story; gebaut wird, wenn der Mensch es sagt.
+
+## 2. Rückmeldungen holen
+
+Arbeite im **Projektordner** (dort, wo Specs und Code liegen). Die Datei heißt immer
+`plan/stand.json`, relativ zu diesem Ordner.
+
+```
+kimal3 plan
+```
+
+**Kommt `Im Ordner liegt keine plan/stand.json.`**, ist es das erste Mal (oder du stehst im
+falschen Ordner — prüf das zuerst):
+
+1. `kimal3 projekt liste` — such das Projekt, um das es hier geht. Gibt es **kein** passendes,
+   frag den Menschen, welches gemeint ist, und schlag `/k3projekt <was du gebaut hast>` vor:
+   Ohne Eintrag im Erfolgsprofil gibt es keine Projektseite. Hier aufhören, nichts erfinden.
+2. Leg `plan/stand.json` an, mit dem Namen **genau so, wie die Liste ihn schreibt**:
+
+   ```json
+   {
+     "format": 1,
+     "projekt": "LinkedIn Content-App",
+     "projekt_id": null,
+     "basis": null,
+     "geprueft_am": "2026-10-21T22:10:00+02:00",
+     "specs": [],
+     "themen": [],
+     "uebernommen": []
+   }
+   ```
+
+   (Name und Zeitpunkt sind ein Beispiel.) `projekt_id` und `basis` trägt `kimal3 plan hoch`
+   nach dem ersten Hochladen selbst ein — **lass sie bei `null`**.
+3. `kimal3 plan` noch einmal.
+
+**Was die Ausgabe heißt** (Beispiel, erfundene Werte):
+
+```
+#12 · passt nicht · 2026-09-23-content-planer / US-2 (Runde 1): Beim Ziehen springt er auf Dienstag
+#13 · Thema: Kalender soll Feiertage zeigen
+Bestätigt: 2026-09-23-content-planer / US-1 (Runde 1)
+Ansehen: https://app.kimal3.de/projekt/…
+```
+
+- `#12 · passt nicht · <Spec> / <Story> (Runde n): <Satz>` — der Mensch hat die Story getestet,
+  sie hält nicht. → Regel 1 in Abschnitt 5. Die Nummer brauchst du später für `uebernommen`.
+- `#13 · Thema: <Satz>` — etwas Neues, das er in der App notiert hat. → Regel 3.
+- `Bestätigt: …` — für diese Stories hat er in **dieser** Runde „Passt" gesagt; sie sind fertig.
+  Ein „Passt" musst du nicht übernehmen.
+- `Ansehen: …` — der Link zur Planung. Merk ihn dir für den Bericht.
+- `Keine offenen Rückmeldungen.` — nichts zu übernehmen; weiter mit Abschnitt 3.
+
+**Absagen:**
+- `Kein Projekt heißt „…“. Deine Projekte: … Trag den Namen in plan/stand.json genau so ein.` —
+  übernimm den passenden Namen **wörtlich** aus der Liste in `"projekt"`. Passen zwei, frag.
+- `Mehrere deiner Projekte heißen „…“ (Nummern: …).` — frag den Menschen, welches gemeint ist, und
+  trag dessen Nummer als `"projekt_id"` ein.
+- `Die Projektnummer in plan/stand.json gehört zu keinem deiner Projekte.` — die Nummer stammt aus
+  einem kopierten Ordner oder einem gelöschten Projekt. Setz `"projekt_id"` auf `null` (die Zeile
+  bleibt stehen, das Feld ist Pflicht); dann sucht kimal3 nach dem Namen. Das ist der **einzige**
+  Fall, in dem du `projekt_id` selbst änderst.
+- `Der Plan ist nicht lesbar: plan/stand.json enthält kein gültiges JSON-Objekt.` — Klammern oder
+  Kommas in der Datei reparieren.
+
+## 3. Specs finden
+
+Such im Projektordner in **`docs/superpowers/specs/`**, **`plan/`** und **`docs/specs/`** nach
+Markdown-Dateien mit User Stories („Als … will ich … damit …", oft `US-1`, `US-2`, mit
+Akzeptanzkriterien und Gegenprobe). `plan/stand.json` selbst, Statuszettel und Aufgabenlisten
+sind keine Specs.
+
+Je Spec ein Eintrag in `specs`, je User Story ein Eintrag in `stories`, je Akzeptanzkriterium
+ein Eintrag in `kriterien` (kurz gefasst, höchstens 500 Zeichen: Ausgangslage → Handlung →
+Ergebnis).
+
+🔴 **Die Schlüssel sind bindend.** Die App hängt jedes „Passt" und „Passt nicht" an
+Spec-Schlüssel + Story-Schlüssel + Runde. Steht eine Spec oder Story schon in `plan/stand.json`,
+**übernimm ihren Schlüssel unverändert** — ein umbenannter Schlüssel lässt das Urteil des
+Menschen verschwinden. Neu: Spec-Schlüssel = Dateiname ohne `.md`; Story-Schlüssel = die Nummer
+aus der Spec (`US-3`); nummeriert die Spec nicht, zähl selbst `US-1`, `US-2` … in ihrer
+Reihenfolge.
+
+- `titel`: die Überschrift der Spec bzw. der Story. `datei`: der Pfad der Spec im Projektordner (relativ, endet auf `.md`; sonst `null`). Den **Text** der Spec
+  liest `kimal3 plan hoch` aus dieser Datei und schickt ihn mit — Pfade außerhalb des Projektordners
+  liest es nicht.
+- Der Story-Schlüssel ist **derselbe wie in der Überschrift der Spec**, wo die Spec ihre Stories
+  nummeriert (`### US-3 · …` → `US-3`): Die App findet die Story im Spec-Text über diesen Schlüssel.
+- Eine Spec ohne Stories kommt mit `"stories": []` hinein; sag es im Bericht.
+- Grenzen: höchstens 50 Specs, 60 Stories je Spec, 400 zusammen. Sind es mehr, frag den
+  Menschen, welche Specs hineingehören.
+
+**Der Stand je Story:**
+- `offen` — noch nichts gebaut.
+- `in_arbeit` — teilweise gebaut, oder ein Befund ist offen. `gebaut_am` ist dann `null`.
+- `gebaut` — gebaut. `gebaut_am`: das Datum, an dem **diese Runde** fertig wurde (`JJJJ-MM-TT`);
+  dazu ein `testen`-Satz (Abschnitt 4).
+- `weggelassen` — bewusst nicht gebaut, `grund` ist Pflicht (Regel 8). Nur, wenn die Spec oder
+  der Mensch das so entschieden hat — nie von dir allein, um aufzuräumen. Im Zweifel: `offen`
+  lassen und im Bericht fragen.
+
+## 4. Gegen den Code prüfen
+
+Führ je Kriterium seine Gegenprobe aus, **wo es geht**: die Wächter oder Tests des Projekts
+(`npm test`, `npm run …`), einen Befehl, die App starten und die Adresse aufrufen, eine Datei
+lesen.
+
+- `bestanden` — **nur**, wenn die Gegenprobe in dieser Sitzung gelaufen ist und das erwartete
+  Ergebnis gezeigt hat. Nie aus dem Gedächtnis, nie vom letzten Mal, nie weil der Code „richtig
+  aussieht".
+- `gescheitert` — sie ist gelaufen und hat etwas anderes gezeigt. Das ist ein Befund (Regel 1);
+  die App stellt die Story und ihre Spec damit nach „In Arbeit".
+- `offen` — alles, was nicht gelaufen ist: braucht einen Browser, eine Anmeldung, echte Daten
+  oder einen Menschen. Lesen zählt nur, wenn das Kriterium etwas über die Datei selbst sagt (eine
+  Datei gibt es, ein Text steht so da) — ein Verhalten beweist Lesen nicht.
+
+⚠️ Eine Story mit einem `offen`-Kriterium steht in „Claude-Test offen", und der Mensch kann sie
+noch nicht testen. Sag im Bericht, was fehlt, damit die Gegenprobe laufen kann.
+
+**Der `testen`-Satz** (bei jeder `gebaut`-Story, höchstens 1000 Zeichen) nennt die **Adresse oder
+den Befehl** und **was dort zu sehen sein muss**, zum Beispiel: „Starte `npm run dev`, öffne
+http://localhost:3000/kalender und zieh den Beitrag vom Montag auf den Mittwoch — er steht danach
+am Mittwoch." Ohne ihn zeigt die App: „Claude hat nicht aufgeschrieben, wie man das testet".
+
+**Befunde** (`befunde`): nur **offene**. `quelle: "claude"` für etwas, das die Story verspricht und
+nicht tut, und das kein Kriterium abdeckt. `seit`: das Datum, an dem der Befund entstand — steht
+er schon in der Datei, bleibt sein altes Datum.
+
+**Die Runde** bindet ein Urteil an einen Bau-Stand — wie ein Stempel auf einer Fassung:
+- Sie beginnt bei `1` und wird **nie** kleiner.
+- **Um genau 1 erhöhen**, wenn eine Story mit einem Befund des Menschen (`quelle: "mensch"`)
+  seitdem nachgebessert wurde (Git-Verlauf, und die Gegenproben bestehen jetzt): dann
+  `befunde: []`, `stand: "gebaut"`, neues `gebaut_am`, neuer `testen`-Satz. Der Mensch testet neu.
+  Ist unklar, ob nachgebessert wurde: Befund stehen lassen und im Bericht fragen.
+- **Auch erhöhen**, wenn du eine **bestätigte** Story so geändert hast, dass der Mensch es merken
+  würde — sein altes „Passt" gilt dann nicht mehr (Regel 7).
+- Sonst **nicht anfassen**: Eine bestätigte Story bleibt fertig, solange ihre Runde gleich bleibt.
+
+## 5. Die acht Regeln
+
+Die App zeigt sie dem Menschen in genau diesem Wortlaut („So bleibt die Planung kurz"):
+
+1. **Ein Befund ist keine neue Karte.** Hält eine Story nicht, was sie verspricht — Claudes Gegenprobe scheitert oder du sagst „Passt nicht" —, hängt der Befund an **dieser** Story, und ihre Spec geht zurück nach „In Arbeit“.
+2. **Neu ist nur, was niemand versprochen hat. Das kommt in den Eingang, und der hat fünf Plätze.**
+3. **Claude ordnet jedes Thema beim nächsten `/k3plan` ein:** als neue Story in eine Spec, als Befund an eine Story, oder gestrichen mit Begründung. „Für später" gibt es nicht. Was daraus wurde, steht unter „Zuletzt eingeordnet".
+4. **Nichts liegt länger als 14 Tage im Eingang.**
+5. **Höchstens eine Spec gleichzeitig in Arbeit** („In Arbeit“ und „Claude-Test offen“ zusammen). Erst fertig machen, dann die nächste beginnen.
+6. **Höchstens fünf Stories warten auf deinen Test.** Sind es mehr, fängt Claude nichts Neues an, bis du getestet hast.
+7. **Fertig heißt zweimal geprüft:** Claudes Gegenproben bestanden, und du hast „Passt" gesagt — für genau diesen Stand.
+8. **Eine Spec ist erst abgeschlossen, wenn jede Story fertig oder bewusst weggelassen ist** — mit Grund. Einen stillen Rest gibt es nicht.
+
+**Was du danach tust:**
+
+- **Regel 1 — jedes `passt nicht` aus `kimal3 plan`:** Gibt es die Story noch, häng den Satz des
+  Menschen als Befund an sie (`{ "text": "<sein Satz>", "quelle": "mensch", "seit": "<heute>" }`),
+  `stand: "in_arbeit"`, `gebaut_am: null`. Ist sie seitdem schon nachgebessert, stattdessen
+  Runde + 1 und `befunde: []` (Abschnitt 4). Dazu in `uebernommen`:
+  `{ "rueckmeldung": 12, "antwort": "Befund an US-2" }`. Gibt es die Story nicht mehr, sagt die
+  `antwort`, warum. ⚠️ Ohne Befund von `mensch` und ohne höhere Runde lehnt der Server das
+  Hochladen ab.
+- **Regel 2 — Neues:** Was dir beim Prüfen auffällt oder der Mensch im Gespräch sagt und was
+  **keine** Spec verspricht, kommt nach `themen`:
+  `{ "schluessel": "T-1", "text": "…", "quelle": "claude" | "mensch", "seit": "<heute>" }`.
+  Die fünf Plätze teilen sich `themen` und die offenen Notizen aus der App.
+- **Regel 3 — einordnen:** Jedes `Thema` aus `kimal3 plan` **und** jedes Thema, das schon von
+  früher in `themen` steht, ordnest du **jetzt** ein — eins von dreien:
+  - **neue Story:** schreib sie in die Spec, zu der sie gehört (User Story, Akzeptanzkriterium mit
+    Gegenprobe), und in `plan/stand.json` mit `stand: "offen"`. Passt keine Spec, frag, wohin.
+    Antwort: `neue Story US-7 in „Content-Planer“`.
+  - **Befund an eine Story:** wie bei Regel 1. Antwort: `Befund an US-2 in „Content-Planer“`.
+  - **gestrichen:** Antwort `gestrichen: <Grund in einem Satz>`, zum Beispiel
+    `gestrichen: Feiertage stehen schon im Kalender-Werkzeug.`
+
+  Für eine Notiz aus der App gehört die Antwort als **ein Satz** in `uebernommen` (die App zeigt
+  sie unter „Zuletzt eingeordnet" als `<Notiz> → <Antwort>`); schreib sie darum **ohne** Pfeil
+  am Anfang. Ein Thema aus der Datei nimmst du aus `themen` heraus und nennst seine Einordnung im
+  Bericht.
+- **Regel 4:** Weil du bei jedem `/k3plan` alles einordnest, liegt nichts lange. Ein Thema mit
+  `seit` vor mehr als 14 Tagen ordnest du **auf jeden Fall** jetzt ein.
+- **Regel 5 und 6 — keine neue Spec beginnen**, solange eine andere Spec in Arbeit ist (eine ihrer
+  Stories ist `in_arbeit`, hat einen Befund oder eine gescheiterte Gegenprobe, oder ist `gebaut`
+  mit einem `offen`-Kriterium oder ganz ohne Kriterien), oder solange mehr als fünf Stories auf den Test des Menschen
+  warten (`gebaut`, alles bestanden, kein Befund, noch nicht bestätigt). **Sag dem Menschen
+  stattdessen, was er testen soll** — mit den `testen`-Sätzen. Ordnest du ein Thema als neue Story
+  in eine Spec ein, beginnst du sie damit nicht: Sie steht `offen`, und die Spec gilt nicht als in
+  Arbeit.
+- **Regel 7:** „Fertig" setzt nur der Mensch mit „Passt" in der App; in der Datei gibt es dafür kein
+  Feld. Du hältst nur die Runde stabil (Abschnitt 4).
+- **Regel 8:** `weggelassen` nur mit `grund` (Abschnitt 3).
+
+## 6. Die Datei
+
+`plan/stand.json` steht unter Git. Beispiel, gekürzt:
+
+```json
+{
+  "format": 1,
+  "projekt": "LinkedIn Content-App",
+  "projekt_id": null,
+  "basis": null,
+  "geprueft_am": "2026-10-21T22:10:00+02:00",
+  "specs": [
+    {
+      "schluessel": "2026-09-23-content-planer",
+      "titel": "Content-Planer als Seite",
+      "datei": "plan/2026-09-23-content-planer-seite-spec.md",
+      "stories": [
+        {
+          "schluessel": "US-2",
+          "titel": "Beiträge im Kalender verschieben",
+          "stand": "gebaut",
+          "runde": 1,
+          "gebaut_am": "2026-10-21",
+          "kriterien": [
+            { "text": "Beitrag vom Montag auf Mittwoch ziehen → steht am Mittwoch", "gegenprobe": "bestanden" }
+          ],
+          "befunde": [],
+          "testen": "Öffne /kalender, zieh den Beitrag vom Montag auf den Mittwoch.",
+          "grund": null
+        }
+      ]
+    }
+  ],
+  "themen": [
+    { "schluessel": "T-1", "text": "Kalender soll Feiertage zeigen", "quelle": "mensch", "seit": "2026-10-21" }
+  ],
+  "uebernommen": [
+    { "rueckmeldung": 12, "antwort": "Befund an US-2" }
+  ]
+}
+```
+
+**Die Felder** — jedes muss da sein, auch wenn es `null` oder leer ist; ein unbekanntes Feld
+(ein Tippfehler wie `"befund"`) lehnt der Server ab:
+
+- `format`: genau `1`.
+- `projekt`: der Name wie in der App, 1–200 Zeichen.
+- `projekt_id`, `basis`: am Anfang `null`; danach schreibt sie `kimal3 plan hoch` — **nie von Hand
+  ändern**. Einzige Ausnahme: die Absage „Die Projektnummer in plan/stand.json gehört zu keinem
+  deiner Projekte." — dann `projekt_id` auf `null` setzen (Abschnitt 2).
+- `geprueft_am`: jetzt, mit Zeitzone (`date +%Y-%m-%dT%H:%M:%S%:z` in der Bash, `Get-Date -Format
+  "yyyy-MM-ddTHH:mm:sszzz"` in PowerShell).
+- `specs[]`: `schluessel` (eindeutig, 1–80 Zeichen), `titel` (1–200), `datei` (Pfad oder `null`),
+  `stories[]`.
+- `stories[]`: `schluessel` (eindeutig in ihrer Spec), `titel`, `stand` (`offen` · `in_arbeit` ·
+  `gebaut` · `weggelassen`), `runde` (1–999), `gebaut_am` (`JJJJ-MM-TT` bei `gebaut`, sonst
+  `null`), `kriterien[]`, `befunde[]`, `testen` (Satz oder `null`), `grund` (Pflicht bei
+  `weggelassen`, sonst `null`).
+- `kriterien[]`: `{ "text", "gegenprobe": "bestanden" | "gescheitert" | "offen" }`, höchstens 30
+  je Story.
+- `befunde[]`: `{ "text", "quelle": "claude" | "mensch", "seit": "JJJJ-MM-TT" }` — nur offene,
+  höchstens 20.
+- `themen[]`: `{ "schluessel", "text", "quelle", "seit" }`, höchstens 50 (der Eingang hat fünf
+  Plätze, Regel 2).
+- `uebernommen[]`: `{ "rueckmeldung": <Nummer aus kimal3 plan>, "antwort": "<ein Satz>" }`. Leert
+  `kimal3 plan hoch` nach dem Hochladen selbst.
+- Die ganze Datei: höchstens 300 KB.
+
+## 7. Hochladen
+
+Erst der Probelauf — er prüft alles und speichert nichts:
+
+```
+kimal3 plan hoch --probe
+```
+
+`Probelauf: würde 9 Stories hochladen, 2 Rückmeldungen als übernommen melden. Gespeichert wurde
+nichts.` (Zahlen als Beispiel.) **Vergleich die zweite Zahl** mit den offenen Rückmeldungen aus
+`kimal3 plan`: Ist sie kleiner, hast du eine vergessen — sie bliebe in der App unter „Wartet auf
+Claude".
+
+Dann:
+
+```
+kimal3 plan hoch
+```
+
+Geklappt hat es bei `✓ Planung für „…“ hochgeladen: … Stories, … warten auf deinen Test.` und
+`Ansehen: …`; beim ersten Mal zusätzlich `projekt_id und basis stehen jetzt in plan/stand.json.`
+Die CLI hat `projekt_id` und `basis` eingetragen und `uebernommen` geleert — lass die Datei so.
+Sag dem Menschen, dass `plan/stand.json` geändert ist und in den nächsten Commit gehört.
+
+Danach steht eine Zeile `Spec-Texte hochgeladen: 1 von 3. Ohne Text: …` — der Text der Specs geht mit hoch.
+Eine Spec ohne Text ist ein **Hinweis, kein Fehlschlag** (Rückgabewert `0`): Nenn dem Menschen die
+Specs, die in der Klammer stehen, und was zu tun ist (Pfad in `datei` berichtigen; über 300 KB
+lässt sich nicht hochladen).
+
+**Absagen — die Meldung lesen, beheben, Probelauf, noch einmal:**
+
+| Meldung beginnt mit | Was du tust |
+|---|---|
+| `Der Plan ist nicht lesbar: <Ort> …` | Die Stelle (`specs[0].stories[2].stand`) in der Datei reparieren. |
+| `Kein Projekt heißt …` · `Mehrere deiner Projekte heißen …` · `Die Projektnummer in plan/stand.json gehört zu keinem deiner Projekte.` | Wie in Abschnitt 2. Bei der Projektnummer darfst du `projekt_id` auf `null` setzen — nur hier. |
+| `<Spec> / <Story> hat Runde 1, gespeichert ist schon Runde 2.` | Die Datei ist älter als der gespeicherte Stand. Runde auf den gespeicherten Wert setzen — nie kleiner. |
+| `Rückmeldung 12 gibt es in diesem Projekt nicht oder steht zweimal …` | Nur Nummern aus `kimal3 plan`, jede einmal. |
+| `Rückmeldung 12 („…“) ist als übernommen gemeldet, aber US-2 hat keinen Befund von dir …` | Den Befund mit `quelle: "mensch"` an die Story hängen (Regel 1) — oder Runde + 1, wenn nachgebessert ist. |
+| `In der App liegt ein neuerer Plan (hochgeladen …).` | Eine andere Arbeitskopie hat hochgeladen. **Nicht überschreiben.** Sag es dem Menschen und frag, ob ihr deren Stand erst holt (Git) und neu prüft. `kimal3 plan hoch --ueberschreiben` **nur nach seinem ausdrücklichen Ja.** |
+| `Die gespeicherte Planung in der App ist beschädigt …` | Auch hier `--ueberschreiben` **nur nach seinem Ja.** |
+| `Die Planung ist gespeichert, aber die Rückmeldungen sind noch nicht als übernommen markiert.` | `kimal3 plan hoch` **unverändert** noch einmal — das ist harmlos, die CLI hat `basis` schon nachgetragen und `uebernommen` stehen lassen. |
+| ``Die Planung ist gespeichert, aber die Spec-Texte nicht. Führ `kimal3 plan hoch` noch einmal aus.`` | `kimal3 plan hoch` **unverändert** noch einmal — der Plan steht schon in der App, die CLI hat `basis` nachgetragen. |
+| `⚠ Die Planung ist gespeichert, aber plan/stand.json ließ sich nicht nachtragen. Trag selbst ein: …` | Genau diese Werte in die Datei schreiben. |
+| `… ließ sich gerade nicht laden` / `… nicht speichern` | Einmal wiederholen; klappt es dann nicht, dem Menschen sagen. |
+
+🔴 **`--ueberschreiben` ersetzt, was ein anderer hochgeladen hat.** Nie aus eigenem Entschluss,
+auch nicht, wenn die Meldung es vorschlägt.
+
+## 8. Dem Menschen berichten
+
+**Höchstens fünf Zeilen**, ohne Fachjargon:
+
+- was **fertig** wurde (seit dem letzten Mal bestätigt),
+- was **auf seinen Test wartet** — mit dem `testen`-Satz, damit er gleich loslegen kann,
+- was im **Eingang** entschieden wurde (jedes Thema mit seiner Antwort),
+- eine **Warnung**, wenn Regel 5 oder 6 verletzt ist: „Teste zuerst …" statt einer neuen Story,
+- der **Link** aus `Ansehen: …`.
+
+Beispiel (erfundene Werte):
+
+```
+Fertig: US-1 „Beiträge anlegen“.
+Dein Test: US-2 — öffne /kalender und zieh den Beitrag vom Montag auf den Mittwoch.
+Eingang: „Kalender soll Feiertage zeigen“ → neue Story US-7 in „Content-Planer“.
+Claude-Test offen: US-4 braucht einen Browser, den ich hier nicht habe.
+Planung: https://app.kimal3.de/projekt/…
+```

package/skill/commands/k3start.md

@@ -24,7 +24,7 @@ nicht relevant, sag das kurz und überspring ihn — kein Leerlauf.
 - Gibt es ein Status-Doc (`WEITER-HIER.md` oder `ROADMAP.md`) — eine kleine Datei, in der der
   letzte Stand und der nächste Schritt festgehalten sind? Dann lies es.
 - **Wo der Statuszettel liegt und wie er heißt.** Die Projektregel gilt **nur innerhalb eines Arbeitsplatzes**: Liegt ein Ordner `projekte/` oder `projects/` direkt in einem Ordner `werkbank-…` oder `workbench-…` (beide Schreibweisen kommen vor, auch gemischt) und steht die Sitzung in oder unter einem Ordner darin, ist dieser **Projektordner** der Ort. Name dort: unter `projekte/` `WEITER-HIER.md`, unter `projects/` `NEXT-STEPS.md`. **Überall sonst** (Starter-Paket, eigene Repos, auch ein Ordner `~/projects/mein-repo`) bleibt es wie bisher: Der Zettel liegt im Startordner, liegt einer da, nimm ihn; muss einer neu entstehen, heißt er `WEITER-HIER.md` — oder `NEXT-STEPS.md`, wenn der Ordner englisch angelegt wurde. Liegen beide da, frag, welcher gilt, und schreib in keinen, bevor die Antwort da ist. **Welcher gilt (im Arbeitsplatz):** Hat das Projekt einen, gilt der des Projekts. Sonst gilt ein vorhandener Werkbank-Zettel (`werkbank-…/WEITER-HIER.md` oder `workbench-…/NEXT-STEPS.md` aus der alten Vorlage) — den liest und pflegst du weiter. Gibt es keinen von beiden, entsteht er **im Projekt**. **Leg nie einen neuen Zettel in der Werkbank an.**
-- **Stehst du in der Werkbank selbst (`werkbank-…` oder `workbench-…`), nicht in einem Projekt?** Steht in ihrer `CLAUDE.md` der Abschnitt „Erste Sitzung“ (englisch „First session“), folge **ihm** — er hat Vorrang vor allem Folgenden. Steht er nicht (mehr) da, zeig die Projekte in `projekte/` bzw. `projects/` (ohne `beispiel-rechnungen-erfassen` und `example-capture-invoices`) mit je der **ersten Stand-Zeile** ihres Zettels, oder „noch kein Zettel“, wenn keiner da ist; ein vorhandener Werkbank-Zettel (`WEITER-HIER.md` oder `NEXT-STEPS.md`) steht darüber. Empfiehl daraus **eines** und stell **eine** Frage dazu.
+- **Stehst du in der Werkbank selbst (`werkbank-…` oder `workbench-…`), nicht in einem Projekt?** Steht in ihrer `CLAUDE.md` der Abschnitt „Erste Sitzung“ (englisch „First session“), folge **ihm** — er hat Vorrang vor allem Folgenden. Steht er nicht (mehr) da, zeig die Projekte in `projekte/` bzw. `projects/` (ohne `beispiel-rechnungen-erfassen` und `example-capture-invoices`) mit je der **ersten Stand-Zeile** ihres Zettels, oder „noch kein Zettel“, wenn keiner da ist; ein vorhandener Werkbank-Zettel (`WEITER-HIER.md` oder `NEXT-STEPS.md`) steht darüber. Empfiehl daraus **eines** und stell **eine** Frage dazu. Wählt der Mensch ein Projekt aus der Liste oder nennt eine neue Aufgabe (dann legst du erst Ordner und Statuszettel im Projekt an, nie in der Werkbank), bring die Sitzung in den Projektordner: mit `change_directory` (steht es nur als Name in deiner Werkzeugliste, lade es über die Werkzeugsuche) — und sag vorher: „Gleich fragt dich die Claude-App, ob ich den Ordner wechseln darf, und danach, ob du ihm vertraust — beides ist richtig so, klick jeweils auf Erlauben. Landest du danach in einem leeren Gespräch, tipp dort `/k3start`; dieses Gespräch findest du links in der Liste wieder.“ Ohne das Werkzeug oder wenn der Mensch ablehnt: nenne den genauen Projektordner (nicht die Werkbank darüber) — in der App „Ordner wählen“ und diesen Ordner nehmen, im Terminal `/exit`, `cd '‹Pfad›'`, `claude` — und dann `/k3start`. Bei einem neuen Projekt lies vorher `projekte/CLAUDE.md` (englisch `projects/CLAUDE.md`): ab jetzt gilt sie.
 - Kein Status-Doc? **Sieh erst nach, ob ein `.git`-Ordner im Zettel-Ort liegt** (im Arbeitsplatz der Projektordner, sonst der Startordner). Wenn ja, führt dieses
   Projekt eine Versionsgeschichte, und `git log --oneline -10` plus `git status` zeigen dir den
   letzten Stand.