claude-dev-skill

Was ist claude-dev-skill?

claude-dev-skill ist eine Custom Skill für Claude Code, die Claude zu einem „Tech-Lead“-Prozess für die Softwareentwicklung mit mehreren KI-Worker-Agents macht. Die Skill bietet einen strukturierten mehrphasigen Workflow, der parallele Worker-Arbeiten in isolierten Worktrees koordiniert und Kontextverluste sowie Merge-Konflikte durch PR-Routing und Reviews minimiert.

Ihr Kernzweck ist es, über single-threaded Code-Generation hinauszugehen: Sie leitet Anforderungsabstimmung (PRD), Architekturentscheidungen, Task-Dekomposition, parallele Implementierung, statische QA-Checks und einen strukturierten PR-Review-/Merge-Schritt.

Wichtige Features

• /dev-Befehls-Workflow (mehrphasiges SOP): Startet mit Request-Klassifikation und durchläuft PRD-Alignment, Architektur und Issue-Erstellung, Worker-Implementierung, QA-Verifikation sowie PR-Merge-Koordination.
• Tech-Lead-Routing-Regel: Das Hauptgespräch agiert als Koordinator; es „schreibt nie direkt Code“, Änderungen müssen über Worker Agent → PR → Review laufen.
• Parallele Worker-Agents via Worktrees: Erzeugt mehrere Worker-Agents, die parallel in isolierten Worktrees entwickeln, um verschiedene Feature-Teile zu unterstützen (z. B. Auth, API, Frontend).
• Pre-Coding-Konflikt-Scan: Vor Arbeitsstart scannen Worker-Agents offene Issues auf Datei-Überlappungen, um Konflikte früh zu erkennen.
• Post-Merge-PR-Koordination: Nach Merges scannt es offene PRs und benachrichtigt Branches, die ein Rebase benötigen.
• Security-Gate vor Review: Erzwingt den Einsatz von Security-Tools (z. B. bandit plus pip-audit für Python oder npm audit für Node) als Pflichtschritt vor der Review-Phase.
• Strukturierter PR-Review-Checkliste mit Veto-Bedingungen: Code-Review erfolgt über eine 7-Punkte-Checkliste mit obligatorischen Veto-Bedingungen.
• Counterexample-Self-Check für Testabdeckung: Enthält einen Sechs-Kategorien-Self-Check, der sicherstellt, dass Worker Null/Empty/Boundary/External-Failure/Concurrency/Malicious-Input-Szenarien berücksichtigen.

claude-dev-skill nutzen

1. Skill-Dateien installieren in das Commands-Verzeichnis von Claude Code (scriptbasierte Installation für macOS/Linux/Windows oder manuelles Kopieren unter Beibehaltung der Verzeichnisstruktur).
2. Stelle sicher, dass Claude Code (offizielles Anthropic-CLI) angemeldet ist.
3. Verwende die GitHub CLI (gh) mit authentifizierter Session (zuerst gh auth login ausführen).
4. In Claude Code /dev [optionale Beschreibung] ausführen. Die Skill klassifiziert die Anfrage (z. B. neues Projekt, neue Feature, Bugfix, Hotfix, Architekturänderung, Refactoring) und startet den passenden Flow.

Ein typischer Lauf folgt den Phasen im Repository: PRD-Alignment (zwei Runden), Architektur und Task-Dekomposition mit GitHub Issues, parallele Worker-Ausführung in Worktrees, statische QA-Verifikation sowie checklistgesteuerte PR-Review und Merge.

Anwendungsfälle

• Aufbau einer small-to-medium Web-Backend-Feature mit bestehendem PRD: /dev nutzen, um ein vorhandenes Product-Requirement-Document in Architekturentscheidungen, GitHub Issues und parallele Worker-Implementierungen umzusetzen.
• Mehrere Module gleichzeitig implementieren bei minimalen Merge-Konflikten: Separate Worker-Agents für verschiedene Komponenten einsetzen (z. B. Auth vs. Task-CRUD-API vs. Frontend) und auf Pre-Coding-Konflikt-Scan sowie Post-Merge-Rebase-Koordination setzen.
• Koordinierte Bugfix- oder Hotfix-Arbeit: Bei Bugfixes oder Emergency-Hotfixes klassifiziert der Flow den Request-Typ und leitet durch Architektur-Review, Worker-Änderungen, QA-Verifikation und strukturierten PR-Merge.
• Systematisches Refactoring mit strukturierter Review: Beim Refactoring helfen SOP-Counterexample-Self-Check und Pre-Merge-Security-Gate, Edge-Cases zu berücksichtigen und Audit-Tools vor Review auszuführen.
• Architekturänderungen mit Alignment vor Coding: Phase-1-PRD-Alignment und Phase-2-Architekturentscheidungen nutzen, um den Team-Plan vor Worker-Implementierung zu klären.

FAQ

• Was bedeutet „tech lead“ in diesem Skill-Workflow? Das Hauptgespräch agiert als Koordinator: Es richtet PRD aus, entscheidet die Architekturrichtung, erzeugt Worker Agents und erzwingt, dass Code-Änderungen über Worker-Agent-PRs und Reviews fließen, statt direkter Bearbeitungen im Chat.

• Schreibt claude-dev-skill Code direkt aus dem Hauptgespräch? Nein. Der Workflow enthält eine „Iron Rule“, dass das Hauptgespräch nie direkt Code schreibt; Änderungen müssen über einen Worker Agent und dann eine PR zur Überprüfung laufen.

• Wie werden Konflikte bei paralleler Entwicklung gehandhabt? Der Skill umfasst einen Pre-Coding-Konflikt-Scan (Worker Agents prüfen offene Issues auf Datei-Überlappungen vor dem Start) und einen Post-Merge-Schritt, der offene PRs scannt, um Branches zu identifizieren, die ein Rebase benötigen.

• Welche Security-Checks werden erzwungen? Vor der Review-Phase wird das Ausführen von Security-Tools wie bandit plus pip-audit für Python oder npm audit für Node vorgeschrieben, gemäß der Security-Gate-Beschreibung des Repositories.

• Ist das für Production-Deployment-Projekte gedacht? Die Repository-Scope-Notiz gibt an, es ist nicht für Projekte mit Production-Deployment geeignet, da es keine DevOps/Deployment-Fähigkeiten bietet.

Alternativen

• Single-Agent-Code-Assistenten (Autocomplete/Chat-Stil): Diese schreiben Code direkt aus Prompts, bieten aber typischerweise keinen Multi-Agent-Workflow von PRD bis PR mit erzwungenen Review-Gates.
• Konventionelle Multi-Step-Prompting + manuelle PR-Workflows: Sie können Claude selbst prompten, um Tasks zu zerlegen und Workers manuell zu starten, verlieren aber die integrierte SOP-Struktur (Klassifikation, Konflikt-Scanning, QA und Checklist-Review-Koordination).
• Standard GitHub-gesteuerte Team-Workflows (Issues/PRs ohne AI-SOP): Teams können Teile des Flows mit GitHub Issues und PR-Reviews nachbilden, aber die „Worker-Agent“-Parallelisierung und automatisierte Phasen-Routing fehlen.
• Andere Claude Code Custom Skills für Planning oder Testing: Statt paralleler Worker Agents end-to-end zu koordinieren, zielen manche Skills nur auf einen Workflow-Teil (z. B. Test-Generierung) ab und überlassen Integration und Merge-Koordination dem User.