sir-ad/claude-setup-skill

/claude-setup

Erstelle ein funktionierendes .claude/-Verzeichnis für das aktuelle Projekt. Lies den Codebestand, erkenne den Kontext, schreibe nur das, was seinen Wert auf diesem Stack beweist.

Die harte Regel dieses Skills: Erzeuge kein Cargo-Cult. Keine leeren Ordner. Keine generischen Platzhalter. Wenn eine Regel, ein Skill oder ein Agent keinen echten Grund hat, für DIESES Projekt zu existieren, dann überspringe sie.

---

Phase 1: Erkennung

Führe diese Befehle parallel aus und untersuche die Ausgabe:

!pwd && echo "---" && ls -la !cat README.md 2>/dev/null | head -120 !cat package.json Cargo.toml pyproject.toml go.mod Gemfile pom.xml build.gradle build.gradle.kts deno.json bun.lockb 2>/dev/null | head -300 !ls .claude/ 2>/dev/null && echo "---vorhandene claude-Konfiguration oben---" !cat .gitignore 2>/dev/null | head -60 !ls docs/ docs/rfcs/ docs/adr/ docs/architecture/ 2>/dev/null

Basierend auf dieser Ausgabe entscheide:

• Stack: Rust (Cargo.toml), Node/TS (package.json), Python (pyproject.toml/requirements.txt), Go (go.mod), Ruby (Gemfile), Java/Kotlin (pom.xml/build.gradle), Deno (deno.json), Bun oder gemischt. Bei mehreren wähle den dominanten und notiere den sekundären.
• Layout: Monorepo (workspaces/turbo/nx/lerna/cargo [workspace]/Go-Workspace) vs. Einzelprojekt.
• Vorhandenes .claude/: falls vorhanden, ist es eine Zusammenführung – niemals ohne Datei-bestätigte Freigabe überschreiben.
• Harte Regeln aus README/RFCs/ADRs extrahiert: Wörter wie "locked", "banned", "no ", "must ", "RFC", "ADR-NNN", "invariant" sind Signale. Kodiere die echten – erfinde keine.
• Testframework, Linter, Formatierer, Paketmanager – aus Konfigurationen und Skripten extrahieren, damit die Befehle in CLAUDE.md real sind.

Wenn die Erkennung wirklich mehrdeutig ist (mehrere Lockfiles, keine klare primäre Sprache, kein README), STOPP und stelle dem Benutzer eine gezielte Frage zur Klärung. Frage nicht nach Dingen, die du erkennen kannst.

---

Phase 2: Die passende Vorlage lesen

Die mit diesem Skill gebündelten Vorlagen beschreiben, was pro Stack generiert werden soll. Lese die zutreffende (verwende ${CLAUDE_SKILL_DIR}/templates/<name>.md):

• rust-workspace.md — Cargo [workspace]
• rust-single.md — einzelne Cargo.toml
• node-monorepo.md — npm/yarn/pnpm workspaces, turbo, nx, lerna
• node-single.md — einzelne package.json (Next.js, Vite, Express, etc.)
• python.md — Poetry, pip+venv, uv, hatch
• go.md — go.mod-Projekte
• generic.md — Fallback für alles andere

Jede Vorlage listet auf, was CLAUDE.md enthalten sollte, welche Berechtigungen wichtig sind, welche Pfad-begrenzten Regeln ihren Wert beweisen, wie der Code-Reviewer-Unteragent optimiert wird und welche Skills für diesen Stack typischerweise nützlich sind.

Die Vorlagen sind Referenzen, keine Boilerplate zum Einfügen. Verwende sie, um zu entscheiden, was generiert werden soll; formuliere die Ausgabe in Bezug auf DIESES Projekt.

---

Phase 3: Planen und bestätigen

Gib dem Benutzer einen Plan aus, bevor du etwas schreibst:

Erkannt: <stack> (<layout>)
Projektname: <name>
Primäre Befehle: build=<cmd>, test=<cmd>, lint=<cmd>

Wird erstellt:
  CLAUDE.md                                  (NEU | ZUSAMMENFÜHREN | ÜBERSPRINGEN)
  .worktreeinclude                           (NEU | ÜBERSPRINGEN)
  .claude/settings.json                      (NEU)
  .claude/rules/<n>.md                       (NEU, Pfad: <glob>)
  .claude/agents/<lang>-reviewer.md          (NEU)
  .claude/skills/<n>/SKILL.md                (NEU)

Wird übersprungen (kein klarer Anwendungsfall): output-styles/, commands/, agent-memory/

Vorhandene Dateien: <Liste mit Aktion: behalten/ersetzen/zusammenführen>

Harte Regeln aus README/RFCs erkannt:
  - <Zitat 1> → kodiert in rules/<datei>.md
  - <Zitat 2> → kodiert in CLAUDE.md

Fortfahren? [j/N/Vorschau-Plan-bearbeiten]

Wenn --dry-run: hier anhalten.

Wenn eine Datei bereits existiert, ist die Standardaktion behalten. Vor dem Ersetzen nachfragen.

Wenn --minimal: nur CLAUDE.md + .claude/settings.json planen.

Wenn --skip-skills: skills/ aus dem Plan auslassen.

---

Phase 4: Generieren

Schreibe Dateien gemäß dem Plan. Regeln pro Datei:

CLAUDE.md

• Oben: Einzeiler zum Stack.
• ## Befehle-Block: echte Befehle, extrahiert aus package.json-Skripten / Makefile / Cargo-Aliasen / pyproject-Skripten. Liste keine Befehle auf, die nicht existieren.
• ## Repo-Karte-Block: nur die Verzeichnisse, die wichtig sind. Überspringe node_modules, target, dist, .next, __pycache__.
• ## Harte Regeln: nur das, was aus README/RFCs/ADRs stammt. Wenn nichts vorhanden ist, lasse den Abschnitt weg – fülle nicht auf.
• ## Verhaltensprinzipien: behalte die vorhandenen Prinzipien des Benutzers, wenn CLAUDE.md sie bereits hat; ansonsten weglassen (die globale ~/.claude/CLAUDE.md deckt dies wahrscheinlich ab).

.claude/settings.json

• permissions.allow: auf den Stack abgestimmt. Für Rust: cargo *, git diff *, gh *. Für Node: npm test *, npm run *, pnpm *. Erlaube kein pauschales Bash(*).
• permissions.deny: minimal rm -rf *, git push --force *, git reset --hard *. Füge Stack-spezifische destruktive hinzu (z. B. npm publish * für Bibliotheken).
• Keine Hooks, es sei denn, das Projekt hat einen klaren Pre-/Post-Tool-Bedarf.

.claude/rules/<name>.md

Pfad-begrenzte Regeln NUR für Verzeichnisse mit echten Konventionen. Heuristik:

• Monorepos: eine Regel pro Workspace-Mitglied mit unterschiedlichen Regeln.
• Testkonventionen: eine Regel, begrenzt auf **/*test*-Muster, WENN das Projekt nicht offensichtliche Testkonventionen hat.
• Infra/IaC: eine Regel, begrenzt auf infra/**, WENN das Projekt IaC hat.
• API-Design: eine Regel, begrenzt auf API-Routen, WENN ein klarer Formvertrag existiert.

Generiere keine Regel nur, weil das Dokumentationsbeispiel eine hatte. Wenn die Konventionen aus CLAUDE.md offensichtlich sind, ist keine Regel erforderlich.

.claude/agents/<lang>-reviewer.md

• Tools: nur Read, Grep, Glob (schreibgeschützt).
• Körper: sprachabgestimmte Checkliste (siehe Vorlage).
• Die Beschreibung muss spezifisch genug sein, damit Claude sie automatisch für Überprüfungsaufgaben aufruft: "Überprüft -Änderungen auf ..." – liste die spezifischen Prüfungen auf.

.claude/skills/<n>/SKILL.md

Generiere NUR Skills, die einen klaren, wiederholbaren Arbeitsablauf haben:

• /release — wenn das Projekt eine Versionsdatei (Cargo.toml, package.json, pyproject.toml) UND eine CHANGELOG.md hat.
• /test — wenn es einen nicht-trivialen Testbefehl gibt (z. B. Matrix, mehrere Suiten). Ein einzelnes cargo test benötigt keinen Skill.
• /lint — gleiche Logik.
• Stack-spezifisch (z. B. /db-migrate für Django/Rails, /deploy-preview für Next.js).

Generiere keine Platzhalter-Skills mit TODO-Body. Funktionsfähig oder übersprungen, kein Dazwischen.

.worktreeinclude

• Liste git-ignorierte Dateien, die Worktrees benötigen: .env, .env.local.
• Wenn CLAUDE.md oder .mcp.json git-ignoriert sind (.gitignore prüfen), füge sie hinzu, damit Worktrees nicht blind sind.
• Wenn .claude/settings.local.json git-ignoriert ist, füge es hinzu.

---

Phase 5: Überprüfen und berichten

Nach dem Schreiben:

echo "=== generierter Baum ==="
find .claude -type f | sort
echo "=== Zeilenzahlen ==="
find .claude -type f -exec wc -l {} \;

Gib aus:

1. Endgültigen Baum.
2. Zeilenzahlen (Ziel: jede Datei ≤ 100 Zeilen; melde, wenn eine 150 überschreitet).
3. Einen konkreten Überprüfungsschritt (z. B. "öffne eine Sitzung, führe /permissions aus, bestätige, dass cargo * als committed angezeigt wird").
4. Erinnerung: füge .claude/settings.local.json zu .gitignore hinzu, falls noch nicht geschehen.

---

Anti-Ziele (zur Klarstellung wiederholt)

1. Keine leeren Ordner. Kein output-styles/ ohne echten Stil. Kein commands/ (Skills ersetzen diese laut Anthropic-Dokumentation).
2. Kein Copy-Paste aus dem Dokumentationsbeispiel. testing.md und api-design.md aus dem kanonischen Baum sind Beispiele – generiere nur dann etwas Analoges, wenn DIESES Projekt diese Konventionen tatsächlich hat.
3. Kein Überschreiben ohne Freigabe. Bestätige immer pro Datei, bevor du ersetzt.
4. Keine harten Regeln aus dem Nichts. Ziehe sie aus README/RFCs/ADRs. Wenn sie nicht existieren, hat das Projekt keine harten Regeln – sage das und fahre fort.
5. Keine Skills mit TODOs. Funktionsfähig oder übersprungen.
6. Keine globalen Wildcards in Berechtigungen. Bash(cargo *) nicht Bash(*).

---

Referenz der Flags

• --minimal: nur CLAUDE.md + .claude/settings.json.
• --skip-skills: Skills/ auslassen.
• --dry-run: Plan ausgeben, nichts schreiben.

(Alle Flags optional. Standard ist das vollständige kanonische Layout, Stack-bewusst, mit Bestätigung.)