Workflow · Multi-Session · Claude Code + Codex

PM-Berater
+ Session-Sync

Sechs Skills, ein Workflow. Für große Projekte mit parallelen Arbeits-Sessions. Liegen in ~/.agents/skills/, laufen in Claude Code und Codex. Der PM berät, plant und setzt Git-Identity. Der Sync hält Sessions synchron und committed. /feierabend pusht am Ende. Kein Tool schreibt blind Code.

6 Commands 3 Phasen 2 Verzeichnisse parallele Sessions
01

Die 6 Commands

Command
Wann
Zweck
/pm-consultant
Projektstart + alle paar Tage
Plant, berät, setzt Git-Identity, generiert Briefings — nie Code
/sync-init <name>
1× am Start jeder Session
Registriert Session
/sync-start
Anfang jeder Arbeits-Session
Zeigt was andere Sessions gemacht haben
/sync-end
Vor Pause / Session-Ende
Status-Update + Contract-Check + Commit der Session-Arbeit
/sync-status
Jederzeit
Tabelle aller Sessions
/feierabend
Ganz am Ende
Zero-question Abschluss + HANDOFF.md + Push aller Branches
02

Der perfekte Workflow

Phase 1 Kickoff 1× pro Projekt · Solo-Session
/pm-consultant
  • Er fragt 4 Dinge: Was baust du, Greenfield?, Deadline-Gefühl?, Git-Identity (Name + Email)
  • Setzt direkt git config --local user.name/email — alle Sessions committen automatisch mit der richtigen Identity
  • Schlägt 3–7 Work Packages + Dependency-Graph vor
  • Diskutiert Session-Splits (was parallel, was seriell)
  • Legt .plan/ an: overview.md (inkl. Git-Setup-Sektion), decisions.md, beratung-log.md

Dann:

"schreib mir briefings für alle packages"

Copy-Paste-Ready Markdown-Blöcke pro Session + Next-Actions-Tabelle mit Modus + Branch pro Session

Phase 2 Parallele Arbeit N Sessions gleichzeitig

Einstieg — jede Session, immer gleich

[Briefing + Next-Actions-Block aus Phase 1 in den Chat pasten]
git checkout -b feat/auth          # Branch aus Next-Actions-Tabelle
/sync-init auth-feature          # eigener Name
/sync-start                       # was machen die anderen?

Während der Arbeit

  • Contract-Änderung (API, Types, DB-Schema)? → ankündigen, am Ende mit /sync-end in _shared.md dokumentieren
  • Frage an andere Session? → in eigenem Session-File unter "Open questions" mit @other-session taggen
  • Zwischendurch Überblick nötig?/sync-status

Session-Ende — immer in dieser Reihenfolge

/sync-end        # Status + Contract-Check (ja/gesehen/nein) + git commit
/feierabend      # Abschluss-Report + HANDOFF.md + git push aller Branches
Wichtig: /sync-end committed nur, pusht nicht. /feierabend pusht alle lokalen Branches mit unpushed Commits — ein Aufruf reicht auch für Multi-Session-Tage.
Phase 3 Regelmäßiger Strategie-Check alle 2–3 Tage
/pm-consultant

Er liest still: .plan/ + .sync/ + HANDOFF.md + git log seit letzter Beratung · prüft Identity-Match

Zeigt Delta:

  • ✓ Erledigt (mit Commits)
  • ⚠️ Abweichungen vom Plan
  • 🔄 Neue Contract-Changes
  • 📝 Offene Action-Items vom letzten Mal
  • 🔐 Identity-Mismatch? (unpushed → Rewrite-Vorschlag · pushed → Force-Push-Warnung mit 3 Optionen)

Dann freies Gespräch:

  • Entscheidungen neue ADRs in decisions.md
  • Neue Pakete Plan-Update + neue Briefings
  • Blockierte Session Re-Priorisierung

Und immer am Ende: Next-Actions-Tabelle mit konkreten /sync-init <name>-Befehlen + empfohlenem Modus (Plan / Auto / Bypass-Permissions) + Branch + 1-Satz-Briefing pro Session.

03

Dateisystem

Alle Workflow-Artefakte liegen im Projekt-Root, nicht unter .claude/. Grund: Claude Code hat für .claude/ eine hardcoded sensitive-file protection, die bei jedem Write prompted (auch im Bypass-Modus).

<projekt>/ ├── .plan/ ← /pm-consultant │ ├── overview.md Work Packages, Status, Git Setup (living) │ ├── decisions.md ADRs (append-only) │ ├── beratung-log.md Jede Beratung (append-only) │ └── briefings/ Optional: gespeicherte Briefings ├── .sync/ ← /sync-* │ ├── _shared.md Contracts, Types, Breaking Changes │ ├── _active.json Session-Registry │ └── <session>.md Pro Session: Scope, Files, Fragen └── HANDOFF.md ← /feierabend (Root, sichtbar in git)
04

Goldene Regeln

1
/pm-consultant schreibt nie Code. Implementierung → immer neue Session mit Briefing.
2
/sync-end blockt nie. Contract-Warnung = "ja / gesehen / nein", kein Stopp.
3
Eine Session = ein Name. /sync-init einmal, dann bleibt er stecken.
4
_shared.md ist die Wahrheit für alles zwischen Sessions.
5
@<session>-Tags nutzen — der Empfänger sieht sie bei /sync-start.
6
Nach Pause immer erst /pm-consultant — nie blind reinspringen, er hat den Überblick.
7
Session committed, Feierabend pusht. Nie umgekehrt. Nie manuell --force.
8
Identity beim Kickoff setzen. pm-consultant fragt Name + Email ab und setzt git config --local — Commits landen beim richtigen GitHub-Account.
05

Git-Policy

Wer committet, wer pusht, wer setzt Identity — klare Zuständigkeiten, keine manuelle Pflege.

Wer
Was
Wann
/pm-consultant
Setzt git config --local user.name/email, dokumentiert Identity + Branch-Policy in overview.md
Kickoff
/pm-consultant
Prüft Identity-Match, warnt bei Mismatch, empfiehlt Branch pro Work-Package (Next-Actions-Spalte)
Jeder Refresh
Working Session
git checkout -b <branch> (falls im Briefing empfohlen) — dann arbeiten
Session-Start
/sync-end
git add <touched files> + git commit mit sauberer Session-Message. Nicht pushen.
Pro Session-Ende
/feierabend
git push aller Branches wenn Pre-flight grün (Upstream, clean, tests green, Identity-Match pro Commit)
Absolutes Ende
User manuell
Rewrites (rebase, filter-branch), Force-Pushes, Cherry-Picks, Merge-Konflikt-Resolves
Bei Bedarf
Pre-flight-Fails werden im /feierabend-Report geskipped + gemeldet — nie blockiert, nie geforced. Identity-Mismatch pro Branch wird erkannt; andere Branches pushen trotzdem durch.

Branch-Heuristik

06

TL;DR

Merken
Start:    /pm-consultant  Git-Identity + Briefings + Next-Actions-Tabelle
Session:  git checkout <branch>  /sync-init  /sync-start  arbeiten
           /sync-end (committed)  /feierabend (pusht)
Check:    /pm-consultant (er refreshed sich selbst, prüft Identity)