netresearch/jujutsu-workflow-skill

Jujutsu Workflow

Für agentisches Coding jj (Jujutsu) gegenüber rohem git bevorzugen, sofern ein .jj/-Repository vorhanden ist – es ist die überlegene lokale Änderungsschicht. Git bleibt das kanonische Remote-/PR-/CI-/Audit-Interface: Änderungen mit jj, Überprüfung mit schreibgeschütztem Git.

1. Erkennen und Absichern zuerst

${CLAUDE_SKILL_DIR}/scripts/detect_jj_state.sh ausführen oder manuell prüfen:

• .jj/ vorhanden → jj-Repo: jj verwenden, niemals mutierendes rohes git.
• .jj/ und .git/ → kolokalisiert: mit jj mutieren, mit git lesen, niemals den Git-Index/Staging-Bereich anfassen.
• nur .git/ → reines Git-Repo: jj nicht einführen, es sei denn, es wird darum gebeten.

Siehe references/git-interop.md.

2. Agentensicherheitsregeln (nicht verhandelbar)

• Bei Ausgabebefehlen immer --no-pager; jj config set --user ui.paginate never setzen.
• Immer -m. Niemals Editor-/TUI-Formulare ausführen – reines jj describe|commit|squash, jj split (interaktiv), jj squash -i, jj resolve, jj diffedit – sie lassen Agenten hängen.
• jj erstellt einen Snapshot des Arbeitsverzeichnisses nur, wenn ein jj-Befehl läuft, nicht bei jedem Dateischreibvorgang.

Siehe references/agent-safety.md.

3. Bearbeitungsschleife

jj --no-pager status
# Dateien bearbeiten (Snapshot beim nächsten jj-Befehl)
jj --no-pager diff
jj describe -m "<projektkonforme Nachricht>"
jj new -m "<nächste Einheit>"     # eine Änderung pro logischer Einheit – vermeidet einen einzelnen fetten Commit

Eine gemischte Änderung nicht-interaktiv aufteilen: jj split <pfad> -m "<nachricht>". Siehe references/command-map.md.

4. Wiederherstellen (reversibel)

jj --no-pager op log → jj undo (letzte Operation) oder jj op restore <id>. Konflikte sind erstklassig: jj status markiert sie; durch Bearbeiten der Markierungen auflösen, dann verifizieren. Siehe references/recovery-playbook.md.

5. Übergabe via Git

jj git fetch
jj rebase -d <default-branch>
jj bookmark create <branch> -r @-
jj git push --bookmark <branch>      # neue Bookmarks direkt pushen

Nie auf einen geschützten/Default-Branch pushen; nie öffentliche Historie umschreiben, es sei denn, es ist erlaubt. PR mit gh/glab eröffnen. Siehe references/pr-handoff.md.

6. Parallele Agenten

Ein jj workspace pro parallelem Agenten – niemals ein Arbeitsverzeichnis teilen. Siehe references/parallel-agents.md.

7. Vor „erledigt“ verifizieren

${CLAUDE_SKILL_DIR}/scripts/verify_handoff.sh ausführen oder jj --no-pager status, jj --no-pager log --limit 10, jj --no-pager diff --stat, git status --short --branch melden. Exakte Befehle und Ausgaben berichten; niemals „erledigt/getestet/bereit“ ohne diese Angaben behaupten; Force-Pushes, Wiederherstellungen und Konflikte offenlegen.

Warum jj für Agenten besser ist als Git (und wann man es NICHT verwenden sollte): references/why-jj-for-agents.md.