From just-ship
Implements features or fixes from chat context without tickets using full agent workflow: derives spec, creates git worktree branch, runs steps to open PR.
npx claudepluginhub yves-s/just-ship --plugin just-shipThis skill uses the workspace's default tool permissions.
Starte den vollen Agent-Workflow direkt aus dem Chat-Kontext oder einer expliziten Beschreibung.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Starte den vollen Agent-Workflow direkt aus dem Chat-Kontext oder einer expliziten Beschreibung.
Kein Board, kein Ticket, keine Status-Updates erforderlich.
Gleicher Prozess wie /develop, aber ohne Pipeline-Events, Triage und Ticket-Status.
STOPPE NICHT ZWISCHEN DEN SCHRITTEN. Alle Schritte 1–9 hintereinander ausführen. Kein "Soll ich...?", kein "Möchtest du...?". ALLES DURCHLAUFEN. Schritt 8 endet mit einem offenen PR — KEIN Merge, nicht warten auf Bestätigung.
git add -A oder git add .--force push--amend bei Hook-Failure/ship aufrufensend-event.sh aufrufenLies project.json für:
build, test)Pipeline-Config wird ignoriert — dieser Command läuft immer im Standalone-Modus.
Guard: Falls kein Argument übergeben wurde UND kein klares Implementierungsziel aus der Konversation ableitbar ist (leere Session, themenfremdes Gespräch, mehrere widersprüchliche Themen) → STOP: "Ich konnte kein klares Implementierungsziel aus dem Chat ableiten. Bitte beschreibe kurz, was gebaut werden soll."
Mit Argument (/implement Beschreibung):
Nutze $ARGUMENTS direkt als Spec-Basis.
Ohne Argument (/implement):
Lies die aktuelle Konversation und destilliere eine kompakte Spec:
Spec ausgeben (immer, egal ob aus Argument oder Chat abgeleitet):
▶ Spec: {einzeiliges Summary}
Ziel: {Was wird gebaut}
Bereich: {Betroffene Dateien/Komponenten}
Danach SOFORT weiter — kein Warten auf Bestätigung.
Branch-Prefix aus Spec ableiten:
fix/chore/docs/feature/{slug} = kurze Kebab-Case-Zusammenfassung der Spec (max. 5 Wörter)
Prüfe zuerst ob das aktuelle Verzeichnis bereits ein Worktree ist:
git rev-parse --git-dir 2>/dev/null
Falls die Ausgabe .git enthält (kein Worktree):
# Worktree erstellen für parallele Ausführung
git fetch origin main
BRANCH="{prefix}/{slug}"
WORKTREE_DIR=".worktrees/{slug}"
git worktree add "$WORKTREE_DIR" -b "$BRANCH" origin/main
# Symlink .env.local from repo root into worktree (credentials for board-api.sh etc.)
REPO_ROOT=$(git rev-parse --show-toplevel)
ln -sf "$REPO_ROOT/.env.local" "$WORKTREE_DIR/.env.local" 2>/dev/null || true
Danach: Alle weiteren Schritte (3-9) im Worktree-Verzeichnis ausführen. Nutze $WORKTREE_DIR als Arbeitsverzeichnis für alle Bash-Befehle (cwd), Read, Edit, Glob, Grep.
Ausgabe: ▶ worktree — .worktrees/{slug} erstellt
Falls bereits in einem Worktree (z.B. bei Resume): einfach den Branch erstellen wie bisher:
git checkout main && git pull origin main
git checkout -b {prefix}/{slug}
Lies nur die 5–10 betroffenen Dateien direkt mit Read/Glob/Grep.
Lies CLAUDE.md für Architektur und Konventionen.
Lies project.json für Pfade und Stack-Details.
Dann: Instruktionen für Agents formulieren — mit exakten Code-Änderungen und neuen Dateien direkt im Prompt.
Spawne Agents via Agent-Tool mit konkreten Instruktionen:
| Agent | model | Wann |
|---|---|---|
data-engineer | haiku | Bei Schema-Änderungen |
backend | sonnet | Bei API/Hook-Änderungen |
frontend | sonnet | Bei UI-Änderungen |
Ausgabe vor Agent-Start: ▶ [{agent-type}] — {was der Agent macht}
Ausgabe nach Agent-Ende: ✓ [{agent-type}] abgeschlossen
Prompt-Muster: Exakte Dateiliste + Code-Snippets, NICHT "lies die Spec".
Ausgabe: ▶ build-check — {build command}
Lies Build-Commands aus project.json und führe sie aus.
Nur bei Build-Fehlern: DevOps-Agent spawnen (model: haiku) um Fehler zu beheben.
Ausgabe: ▶ devops — Build-Fehler beheben
NICHT STOPPEN. SOFORT weiter zu Schritt 6.
Ausgabe: ▶ qa — Acceptance Criteria & Security prüfen
Ein QA-Agent (model: haiku):
Ausgabe nach Abschluss: ✓ qa abgeschlossen
NICHT STOPPEN. SOFORT weiter zu Schritt 7.
Ausgabe: ▶ docs — Dokumentation prüfen
Ermittle alle geänderten Dateien auf diesem Branch:
git diff --name-only $(git merge-base main HEAD) HEAD
git status --porcelain
Der Docs-Check hat zwei Teile: einen universellen Teil (läuft in jedem Projekt) und einen projektspezifischen Teil (nur wenn die jeweiligen Dateien existieren).
CHANGELOG.md wird bei JEDER Änderung aktualisiert — egal welches Projekt, egal welche Dateien sich geändert haben.
Falls CHANGELOG.md nicht existiert, erstelle sie mit diesem Header:
# Changelog
All notable changes to this project will be documented in this file.
Format: [Keep a Changelog](https://keepachangelog.com/)
## [Unreleased]
Falls CHANGELOG.md existiert aber keine [Unreleased]-Sektion hat, füge sie als erste Sektion nach dem Header ein.
Format: Keep-a-Changelog mit Gruppen ### Added, ### Changed, ### Fixed, ### Removed. Beschreibung auf Englisch, 1 Zeile pro Änderung. Nur Gruppen verwenden, die auch Einträge haben.
Prüfe ob die jeweilige Zieldatei existiert. Nur bestehende Dateien aktualisieren — keine neuen Docs anlegen. Falls eine Zieldatei nicht existiert, diesen Eintrag überspringen.
| Geänderte Dateien | Zu prüfende Docs | Aktion |
|---|---|---|
commands/*.md | README.md | Commands-Tabelle + Architecture-Abschnitt |
agents/*.md | README.md | Agents-Tabelle |
skills/*.md | README.md | Skills-Tabelle |
pipeline/**, agents/*.md, commands/*.md | README.md | Workflow-Diagramm |
pipeline/**, agents/*.md, .claude/** | docs/ARCHITECTURE.md | Betroffene Sektionen (Agent System, Slash Commands, Pipeline SDK, etc.) |
| Pipeline/Architektur-Strukturen | CLAUDE.md | Architektur-Abschnitt |
commands/*.md, agents/*.md, skills/*.md | templates/CLAUDE.md | Template aktualisieren falls Commands/Agents/Skills-Referenzen enthalten |
pipeline/worker.ts, pipeline/server.ts | docs/ARCHITECTURE.md | Pipeline-Server Abschnitt |
| Workflow, Conventions, Dev-Setup | CONTRIBUTING.md | Contributing Guidelines |
| Keine der obigen Trigger-Dateien | — | Teil 2 überspringen |
Falls Anpassung nötig: direkt mit Edit-Tool ändern.
Ausgabe pro geprüfter Datei:
✓ docs — CHANGELOG.md aktualisiert✓ docs — README.md aktualisiert✓ docs — docs/ARCHITECTURE.md aktualisiert✓ docs — templates/CLAUDE.md aktualisiert✓ docs — docs/ARCHITECTURE.md aktualisiert (Pipeline-Server)✓ docs — CONTRIBUTING.md aktualisiert✓ docs — keine Änderungen nötig (falls nur CHANGELOG und sonst nichts zu tun war)NICHT STOPPEN. SOFORT weiter zu Schritt 8.
NICHT den Skill finishing-a-development-branch aufrufen.
NICHT dem User Optionen präsentieren.
NICHT fragen ob committed/gepusht werden soll.
NICHT mergen. NICHT auf main wechseln.
8a. Commit:
git add <betroffene-dateien>
git commit -m "feat: {englische Beschreibung}
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>"
8b. Push:
git push -u origin $(git branch --show-current)
8c. PR erstellen:
gh pr view 2>/dev/null || gh pr create \
--title "feat: {Beschreibung}" \
--body "$(cat <<'EOF'
## Summary
- {Bullet Points}
## Test plan
- {Was wurde getestet}
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
NICHT mergen. Der PR bleibt offen bis der User freigibt (via /ship oder "passt").
Nur ausführen wenn hosting.provider gesetzt ist. Die Scripts prüfen selbst ob ein Hosting-Provider konfiguriert ist und exiten graceful wenn nicht. Bei nicht gesetztem hosting-Feld wird dieser gesamte Schritt übersprungen — kein API-Call, kein Warten.
WICHTIG: Die Preview-URL MUSS eine Deployment-URL sein (z.B. https://<project>-<hash>.vercel.app, https://<store>.myshopify.com/?preview_theme_id=... oder https://<app>.coolify-domain.tld). NIEMALS einen GitHub-Link, PR-URL oder Repository-URL als Preview-URL verwenden.
# Read hosting provider from project.json (supports object and legacy string format)
HOSTING_PROVIDER=$(node -e "
const c = require('./project.json');
const h = c.hosting;
if (typeof h === 'object' && h !== null) {
process.stdout.write(h.provider || '');
} else if (typeof h === 'string') {
process.stdout.write(h);
}
")
if [ "$HOSTING_PROVIDER" = "shopify" ]; then
PREVIEW_URL=$(bash .claude/scripts/shopify-dev.sh start "T-${TICKET_NUMBER}" "${TITLE}")
elif [ "$HOSTING_PROVIDER" = "vercel" ]; then
PREVIEW_URL=$(bash .claude/scripts/get-preview-url.sh 30)
elif [ "$HOSTING_PROVIDER" = "coolify" ]; then
PREVIEW_URL=$(bash .claude/scripts/get-preview-url.sh 60)
else
# No hosting provider configured — skip preview URL entirely
PREVIEW_URL=""
fi
Falls eine URL gefunden wurde, nur ausgeben:
✓ preview — {PREVIEW_URL}✓ preview — kein Deployment gefunden, übersprungen (falls Deployment-Script keine URL lieferte)✓ preview — übersprungen (kein Preview-Deployment konfiguriert) (falls kein Hosting-Provider gesetzt)Kein Fehler wenn keine URL gefunden wird. Die Scripts exiten immer mit Code 0. Projekte ohne Vercel-, Shopify- oder Coolify-Integration überspringen diesen Schritt automatisch.
✓ Implementiert: {Beschreibung}
Branch: {branch-name}
Worktree: {worktree-dir}
PR: {url}
→ Zum Mergen: /ship oder "passt"
Hinweis: Worktree wird NICHT hier aufgeräumt — das passiert in /ship nach dem Merge, damit Nachbesserungen nach Code Review im Worktree möglich bleiben.