Pragmatischer Claude Code Einsatz für C# Entwickler auf Mac

Wer als Software-Entwickler morgens seinen RSS-Feed öffnet, in YouTube schaut oder die aktuellen Newsletter liest, könnte den Eindruck gewinnen, er sei versehentlich in einem Teilchenbeschleuniger gelandet: Täglich kollidieren neue AI-Tools, Frameworks und "revolutionäre" Workflows miteinander – und jedes einzelne will natürlich sofort ausprobiert werden. Die Realität sieht anders aus. Zwischen Sprint-Meetings, Code-Reviews und der Pflege bestehender Systeme bleibt oft wenig Zeit für ausgedehnte Evaluierungszyklen.

Gleichzeitig ist KI-gestützte Entwicklung kein vorübergehender Hype mehr. Teams, die AI-Coding-Tools effektiv einsetzen, berichten von erheblichen Produktivitätssteigerungen – vorausgesetzt, der Einarbeitungsaufwand bleibt beherrschbar. Genau hier setzt dieser Artikel an: Ein pragmatischer Ansatz, der gute Ergebnisse bei vertretbarem Setup- und Lernaufwand liefert. Kein "hier sind 47 Tools die du alle kennen musst", sondern ein erprobtes Setup, das sich im täglichen .NET-Entwicklungsalltag auf dem Mac bewährt hat.

Alle in diesem Artikel erwähnten Skills, Custom Commands und Subagent-Konfigurationen stehen im begleitenden GitHub-Repository zur Verfügung.

Die großen Coding-LLMs wurden überwiegend mit Python, TypeScript und JavaScript Codebases trainiert. Das merkt man: Fragt man Claude, GPT oder Gemini nach einer Lösung, kommt häufig idiomatisches Python – bei C# hingegen landet man gelegentlich bei Patterns, die eher an C# 8 als an C# 14 erinnern. Besonders aktuelle Sprachfeatures wie Primary Constructors, Collection Expressions oder das field Keyword werden von Coding-LLMs nicht automatisch verwendet, wenn man sie nicht explizit dazu anleitet.

Die Frage, die sich etablierte .NET-Entwicklungsteams daher stellen: Funktioniert AI-gestützte Entwicklung auch mit unserem Tech-Stack? Und wenn ja, wie gut?

Die kurze Antwort: Ja, es funktioniert – und zwar besser als man erwarten würde. Der Schlüssel liegt darin, dem LLM den notwendigen Kontext über die eigenen Code-Standards, bevorzugte Sprachfeatures und projektspezifische Patterns mitzugeben. Dafür stellt Claude Code mit Skills, CLAUDE.md und Custom Commands die richtigen Werkzeuge bereit (dazu mehr in den folgenden Abschnitten).

Eine pragmatische Empfehlung für die Praxis: Anwendungen mit langfristiger Wartungsperspektive in C# / .NET realisieren. Für temporäre Tooling-Aufgaben wie Datenmigrationen, Build-Scripts oder Analyseskripte spricht dagegen nichts gegen Python – sofern sie nicht unternehmenskritisch sind. Hier profitiert man vom stärkeren LLM-Training auf Python und der schnelleren Umsetzung.

Wir arbeiten mit VS Code als IDE auf dem Mac. Das ist für C#-Entwickler nicht zwingend aber naheliegend: Das C# Dev Kit mit seinem vollen Funktionsumfang ist an den Visual Studio Marketplace gebunden. IDE-Alternativen wie Cursor oder Windsurf verwenden einen alternativen Marketplace (ohne C# DevKit) und bieten deshalb nicht denselben .NET-Tooling-Komfort. JetBrains Rider ist eine valide Alternative, liegt aber preislich höher.

Der entscheidende Vorteil von Claude Code gegenüber IDE-integrierten AI-Assistenten: Es läuft im Terminal und blockiert die IDE nicht. Über Git Worktrees lässt sich parallel an einer anderen Branch in der IDE weiterarbeiten, während Claude Code eigenständig ein Feature implementiert. Das ist in der Praxis ein erheblicher Produktivitätsgewinn – man muss nicht "zusehen" wie der Agent arbeitet, sondern kann die Zeit sinnvoll nutzen.

Hinzu kommt, dass Anthropic bei der Integration neuer Möglichkeiten oft Vorreiter ist. Features wie Skills, Agent Teams oder das Plugin-System wurden in schneller Folge eingeführt und kontinuierlich verbessert. Die flexiblen Erweiterungs- und Anpassungsmöglichkeiten über MCP Server, Skills und Custom Commands ermöglichen es, Claude Code präzise an den eigenen Workflow anzupassen – ein Aspekt, der bei vielen Alternativen in dieser Tiefe nicht gegeben ist. Trotzdem sollten OpenAI's Codex oder Cursor von der Kommandozeile einen ähnlichen Komfort und Leistungsumfang bieten.

Hinweis: Die Verwendung der besprochenen Skills etc. und die empfohlene Vorgehensweise ist unter Windows genau so möglich. 

Die folgenden Erfahrungswerte basieren auf mehreren Projekten, ich möchte mich hier besonders auf ein konkretes Projekt beziehen: einer ASP.NET Razor Pages Website für einen Budo-Verein. Das Projekt eignet sich besonders gut als Referenz, weil es bei beschränktem Budget eine bemerkenswerte Feature-Dichte erforderte: Shop mit Warenkorbsystem, Rechnungsstellung und Bestellverwaltung, Seminarbuchung mit Verwaltungsoberfläche, Dojo-Verwaltung mit OpenStreetMap-Integration, Registrierung mit Benutzerprofilen, CMS-basierte Inhaltsseiten über Directus Headless CMS (für das kein offizielles C# SDK existiert – der Client wurde auf Basis der REST-API eigen- (bzw. teils KI :)) implementiert), Volltextsuche mit Vektor-Datenbank, ein eigener AI-Assistant ("Karate-Cat") auf Basis Microsoft Extensions AI, Blog- und News-Management mit Kommentarverwaltung und einiges mehr.

Die Zeitersparnis durch den AI-gestützten Entwicklungsansatz liegt bei mindestens 50%, realistisch betrachtet wahrscheinlich deutlich darüber. Das macht Projekte realisierbar, die ohne AI-Unterstützung entweder gar nicht oder nur in deutlich abgespeckter Form umgesetzt werden könnten.

Besonders bemerkenswert: Features, für die man üblicherweise auf SaaS-Lösungen zurückgreifen würde (etwa ein Warenkorbsystem oder eine Seminarbuchung), konnten als integrierte, maßgeschneiderte Lösung implementiert werden. Das gesamte System – von der Datenbank bis zum Deployment – wird von einem einzelnen Entwickler über alle Ebenen bereitgestellt und gepflegt.

Ein oft unterschätzter Nebeneffekt: Schnelle Previews werden möglich, da Bilder, Texte und andere Inhalte bis zur Bereitstellung finaler Daten per AI generiert und bereitgestellt werden können. Das beschleunigt Feedback-Zyklen mit Stakeholdern erheblich.

Bei verantwortungsvoller Realisierung bleibt jedoch noch einiger manueller Aufwand:

Viele von diesen Punkten sind nur relevant, wenn man eine Langzeitpflege sicherstellen möchte und entfallen bei einfachen Tools für Einmalverwendung, die per reinem "Vibe-Coding" (meist in Python) erstellt werden, z.B. für initiale Befüllung der DB, Erzeugen von Video-Transcripts und Vorschaubildern etc.

Die Installation von Claude Code selbst ist unkompliziert und in der offiziellen Dokumentation beschrieben. Für C#-Entwickler auf dem Mac sind darüber hinaus folgende Voraussetzungen relevant:

Grundvoraussetzungen:

Claude Code Installation und Ersteinrichtung:

Das csharp-lsp Plugin verdient besondere Erwähnung: Es verbindet Claude Code über das Language Server Protocol mit dem C#-Sprachserver und ermöglicht damit IntelliSense-ähnliche Funktionalität, die das Coding-LLM bei der Codeanalyse und -generierung nutzen kann.

Nach der Erstinstallation sollte als nächstes die CLAUDE.md Datei mit den projektspezifischen Informationen befüllt und die für das Projekt relevanten MCP Server konfiguriert werden (siehe Abschnitte "CLAUDE.md" und "MCP").

Git Worktree für paralleles Arbeiten:

Claude Code übernimmt dabei die gesamte Verwaltung: Der Worktree wird unter .claude/worktrees/<name>/ angelegt, eine Branch worktree-<name> automatisch erstellt, und nach Beendigung wird aufgeräumt – bei Änderungen wird nachgefragt, ohne Änderungen wird der Worktree automatisch entfernt.

Der Vorteil gegenüber der manuellen Variante (git worktree add + cd + claude) liegt neben dem geringeren Aufwand vor allem in der Integration mit dem Session-Management: Worktree-Sessions erscheinen im Session-Picker und lassen sich jederzeit fortsetzen:

In Kombination mit --tmux lassen sich so mehrere parallele Claude Code Sessions in getrennten Terminal-Tabs betreiben – z.B. ein Feature-Worktree und ein Bugfix-Worktree gleichzeitig.

Tipp: .claude/worktrees/ in die .gitignore aufnehmen, damit die Worktree-Inhalte nicht als Untracked Files erscheinen. Auch Subagenten können per isolation: worktree in ihrer Konfiguration automatisch in eigenen Worktrees arbeiten.

Gute Erfahrungen haben wir mit der Aufteilung der Realisierung eines Features per AI Coding Tool in drei Phasen gemacht:

Die prinzipielle Idee dazu stammt von Colin Medin (siehe GitHub), der den Ansatz ursprünglich für Python entwickelt hat. Er hat sich im täglichen Einsatz als produktiv erwiesen. Hier die von uns auf die Verwendung mit .NET / C# angepassten Versionen als Custom Commands (siehe auch Abschnitt "Custom Commands"):

Das generate-prd.md Command verwendet dabei eine PRD-Vorlage (prd-base.md), die den Aufbau des PRD vorgibt: Ziel, Begründung, benötigter Kontext, Implementierungs-Blueprint, Validierungsschleifen und eine finale Checkliste. Generell geht es darum, dem Coding-LLM optimalen Kontext für die anstehende Aufgabe zu geben. Das sollte z.B. über die Bereitstellung von Beispielcode für typische Aufgaben und vertikale Funktionalitäten in einem /examples Verzeichnis erfolgen.

Wichtig beim PRD-basierten Vorgehen:

Tipp für den PRD-Workflow: Mit claude --dangerously-skip-permissions lässt sich Claude Code ohne ständige Bestätigungsdialoge starten, was den Workflow bei der PRD-Ausführung deutlich flüssiger macht. Wie der Name suggeriert: Nur in vertrauenswürdigen Umgebungen verwenden und vorher sicherstellen, dass das PRD keine destruktiven Operationen enthält.

Beispiel für einen

Claude Code unterstützt verschiedene Möglichkeiten, um die Codegenerierung an die eigenen Erfordernisse anzupassen. Die folgenden Abschnitte beschreiben die wichtigsten Stellschrauben.

Claude Code unterscheidet mehrere Konfigurationsebenen, die bei der Organisation von Skills, MCP Servern und Settings relevant sind:

Projektebene (.claude/): Wird ins Repository eingecheckt und ist damit für das gesamte Team verfügbar. Hier gehören projektspezifische Skills, Custom Commands und MCP-Konfigurationen hin.

Benutzerebene (~/.claude/): Globale Einstellungen, die projektübergreifend gelten. Ideal für persönliche Präferenzen und Skills, die in allen Projekten verwendet werden sollen (z.B. dotnet-code-standards).

Weitergabe zwischen Projekten: Skills und Agents, die man zwischen verschiedenen Projekten auf dem eigenen Rechner teilen möchte, legt man am besten in ~/.claude/skills/ ab. Für die Weitergabe an Kollegen oder die Community empfiehlt sich die Verpackung als Plugin (siehe Abschnitt "Plugins").

CLAUDE.md ist das "Gedächtnis" des Coding-LLMs für das aktuelle Projekt. Opus 4.6 hat zwar ein sehr großes nutzbares Kontextfenster von 1 Mio. Token, aber nach jeder halbwegs komplexen Teilaufgabe ist dieses erschöpft und muss entweder zusammengefasst (/compact) oder gelöscht (/clear) werden.

Es ist daher essentiell, die Datei nach der Umsetzung jedes PRD updaten zu lassen. Ansonsten muss das Coding-LLM vor Umsetzung eines PRD jedesmal eine token- (und kosten-) intensive Analyse des Quellcode-Standes durchführen. 

Tipp: Statt alles in eine monolithische CLAUDE.md zu packen, empfiehlt es sich, diese mit Referenzen auf weitere Markdown-Dateien zu splitten. Claude Code folgt Dateireferenzen automatisch. So bleibt die Kontextbelastung gering, während trotzdem alle relevanten Informationen bei Bedarf verfügbar sind. Ist bereits eine komplexe CLAUDE.md vorhanden, Claude bitten diese entsprechend feature-basiert zu splitten, die eigentliche CLAUDE.md sollte nur immer relevante Informationen enthalten, wie Tech-Stack und vertikale Funktionalitäten.

Claude Code stellt selbst viele Konfigurationsmöglichkeiten und Aktionen per "Slash"-Commands wie /init, /compact, /plugins etc. zur Verfügung (Übersicht mit /help). Neben diesen vordefinierten Commands ist es möglich, eigene "Custom" Commands hinzuzufügen, um zusätzlichen Kontext zum eigenen Prompt hinzuzufügen. Wir verwenden hier z.B.:

Mehr Informationen zum PRD-Workflow unter Punkt "Vorgehen".

Anmerkung: In den letzten Claude Code Versionen hat Anthropic Custom Commands und Skills zusammengeführt:

Ich halte die gedankliche Trennung zwischen der aktiver Ausführung (Präzisierung des eigenen Prompts per Custom Command) und der Bereitstellung zusätzlichen "Wissens" bzw. von Fähigkeiten zu bestimmten Bereichen per "Skills" - die automatisch vom Agenten nach Bedarf geladen werden - nach wie vor für sinnvoll, aber das ist natürlich jedem selbst überlassen.

Skills erweitern Claude Code mit Wissen und Kontext über bestimmte Tools (z.B. Datenbanken, CMS), Vorgehenskonzepte (bevorzugte Systemarchitektur, Quellcodeorganisation, Dateibenennung), bevorzugte Quellcode-Formatierung, Einsatz von bestimmten Sprachfeatures usw. Jeder Skill besteht aus YAML-Metainformationen (Name, Beschreibung) und detaillierten Anweisungen im Markdown-Format innerhalb einer Datei skills/skill-name/SKILL.md. Aufbau lt. Dokumentation z.B.

Wir setzen z.B. für die .NET Entwicklung folgende (eigenen) Skills ein:

Statt dem manuellen Schreiben von Skills oder der ausschließlichen Verwendung vorgefertigter Skills lassen sich Skills sehr gut anhand einer existierenden Code-Basis mit dem gewünschten Feature per Claude Code extrahieren. Ein bei uns praktisch verwendeter Prompt lautet:

Der erstellte Skill sollte natürlich einem Review unterzogen und ggf. mit iterativen Prompts verbessert werden.

Lieber Skills als Subagenten: Skills belasten den Kontext weniger als Subagenten und sind für die meisten spezialisierten Aufgaben ausreichend. Subagenten erst einsetzen, wenn ein dediziertes Modell oder separate Tool-Zuordnung wirklich notwendig ist.

Übersicht behalten: Nicht wahllos Skill-Repositories klonen. Jeder Skill erweitert den Kontext, den das Coding-LLM verarbeiten muss. Fokus auf Skills, die tatsächlich regelmäßig benötigt werden.

Sicherheit bei Fremd-Skills: Nur Skills aus vertrauenswürdigen Quellen verwenden. Bei externen Skills explizit auf Prompt-Injection prüfen: Enthält die SKILL.md Anweisungen, die das LLM dazu bringen könnten, unerwünschte Aktionen auszuführen, z.B. Daten an externe URLs zu senden oder Systemdateien zu modifizieren? Besonders auf versteckte Instruktionen in Code-Beispielen oder "unsichtbarem" Text achten.

Skill-Validierung: Den Skill-Validierer einsetzen, um die Konformität mit der Skill-Spezifikation sicherzustellen.

Skills aus existierendem Code erstellen: Das ist der effizienteste Weg. Claude Code analysiert bestehende Implementierungen und extrahiert die Patterns, Conventions und Gotchas automatisch – wesentlich schneller und vollständiger als manuelles Dokumentieren.

MCP Server ermöglichen es dem Coding-LLM auf externe Ressourcen und Software-Tools zuzugreifen, z.B. Versionsverwaltung (GitHub, GitLab), Datenbanken, Dokumentationen und vieles mehr. Obwohl nahezu unendliche Möglichkeiten bestehen, ist wichtig zu beachten, dass jeder MCP Server Zugriff auf zahlreiche einzelne Tools bereitstellt (z.B. Lesen/Schreiben von Struktur und Daten bei einer Datenbank) – teilweise 30 bis 40 Einzelaufrufsmöglichkeiten für das Coding-LLM. Dies kann ein LLM schnell überfordern, wenn es zwischen mehreren hundert Tools für eine bestimmte Aufgabe auswählen muss. Daher MCP Server mit Bedacht auswählen, so dass möglichst eine Höchstzahl von ca. 100 Einzeltools nicht überschritten wird.

Folgende MCP Server verwenden wir bei der .NET Entwicklung:

Die Installation der MCP Server kann auf verschiedenen Wegen erfolgen:

Hier Beispiele zur Installation / Entfernung weiterer MCP Server in Claude Code:

Hooks sind Pre- und Post-Execution-Scripts, die Claude Code automatisch vor oder nach bestimmten Tool-Aufrufen ausführt. Für .NET-Entwickler ist das besonders relevant, um Code-Qualität automatisch sicherzustellen. Ein typisches Beispiel: Nach jeder Dateiänderung an einer .cs-Datei automatisch dotnet format ausführen, so dass der generierte Code sofort den Formatierungsvorgaben entspricht.

Hooks werden in der Claude Code Konfiguration (.claude/settings.json) definiert. Details zur Konfiguration in der offiziellen Dokumentation.

Hier z.B. ein Hook, um automatisch dotnet format nach jedem Durchlauf auszuführen:

Subagents sind autonom arbeitende, spezialisierte Agents für bestimmte Aufgaben. Claude Code verwendet z.B. eigene Subagents für Codeanalyse (via Haiku, da schneller und effizienter) und Planungsaufgaben (/plan Mode, z.B. per Opus). Der Vorteil gegenüber Skills: Subagenten kann ein eigenes Modell (Haiku, Sonnet, Opus – z.B. zur Kostenoptimierung) und spezielle, ausgewählte Tools (MCP Server) für die jeweilige Aufgabe zugeordnet werden.

Zu bedenken ist jedoch die Koordination zwischen Subagenten und dem Hauptagenten. Der Hauptagent hat keinen Einblick in den genauen Ablauf innerhalb des Subagenten und sieht nur die finalen Ergebnisse. Zwei mögliche Ansätze dazu:

Denkbare Einsatzzwecke für Subagenten in .NET-Projekten wären z.B. Frontend-Entwicklung fokussiert auf ein bestimmtes UI-Framework wie Tailwind CSS, SEO-Analyse und -Umsetzung, Code-Review oder Code-Formatierung und -Dokumentation. Im begleitenden Repository finden sich ein Beispiele:

Aus der bisherigen Erfahrung heraus lassen sich die meisten spezialisierten Aufgaben jedoch mit Skills einfacher umsetzen, da selten die Zuordnung eines speziellen Modells wirklich notwendig ist.

Agent Teams ist ein noch neues Feature und zum Zeitpunkt der Erstellung dieses Artikels als "experimental" gekennzeichnet. Die Agenten innerhalb eines Agent Teams unterscheiden sich von Subagenten dadurch, dass sie nicht isoliert arbeiten, sondern miteinander und mit dem Hauptagenten kommunizieren. Das funktioniert über mehrere getrennte Claude Code Instanzen in getrennten Terminalfenstern mit getrennten Kontextfenstern. Sie adressieren damit gezielt die oben genannte Schwäche von Subagenten: die fehlende Kommunikation.

Eine gute Einführung (neben der offiziellen Dokumentation) findet sich hier. Bei uns wurde das noch nicht produktiv getestet; Vorteil ist eindeutig die Möglichkeit, umfangreiche Projekte deutlich schneller zu realisieren. Nachteil soll jedoch der relativ hohe Token-Verbrauch (und damit die Kosten) sowie die teils noch mangelhafte Synchronisierung der Agenten sein.

Plugins sind "verpackte" Bündel aus Skills, Agents, Hooks und MCP Servern zur einfachen Verteilung. Die Verpackung geschieht durch die Bereitstellung in einem eigenen Verzeichnis [my-plugin] mit einem Unterverzeichnis .claude-plugin, das Meta-Daten in Form einer JSON-Datei plugin.json enthält. Der Name [my-plugin] fungiert dann gleichzeitig als Namespace für die enthaltenen Skills etc., so dass sich verschiedene Plugins nicht bei der Benennung "in die Quere" kommen. Aufruf z.B. /my-plugin:my-skill.

Vorteil ist die einfache Verteilbarkeit zwischen Kollegen, in Marktplätzen etc. (per Plugins bzw. Konnektoren in den Claude Desktop Einstellungen bzw. /plugin Slash Command in Claude Code). Genaue Beschreibung siehe hier. Das Teilen von Skills, Agenten etc. auf einem Rechner zwischen verschiedenen Projekten kann jedoch auch per Konfigurationsverzeichnis erfolgen (siehe Abschnitt "Konfigurationsebenen").

Tipp: Claude Code stellt über /plugins vorgefertigte Plugins zur Verfügung. Für C#-Entwickler besonders interessant ist das csharp-lsp Plugin (Language Server Protocol – ein offenes Protokoll zur Kommunikation zwischen Editoren oder wie hier Claude Code und einem Language Server, z.B. für IntelliSense). Daneben gibt es viele weitere interessante Plugins, die hier nicht näher besprochen werden sollen.

Claude Code wird entweder über die Anthropic API oder einen Anthropic Plan abgerechnet. Die Kosten hängen bei API Nutzung primär vom gewählten Modell und der Komplexität der Aufgaben ab. Opus 4.6 liefert bei komplexen .NET-Aufgaben die besten Ergebnisse, ist aber auch das teuerste Modell. Bei Plan-Nutzung gibt es ein bestimmtes Token-Inklusivvolumen und zwar sowohl pro 5 Stunden Zeitfenster als auch pro Woche.

Zur Orientierung:

Zur Kostenkontrolle (siehe Artikel Manage Cost effectively bei Anthropic):

Kontextfenster im Griff behalten: Das Kontextfenster ist die kritischste Ressource bei der Arbeit mit Claude Code. Mit /context lässt sich die aktuelle Auslastung prüfen. Liegt sie über 50%, empfiehlt sich ein /compact um den Kontext zusammenzufassen. Alternativ kann mit /clear ein kompletter Neustart erfolgen – in diesem Fall ist eine aktuelle CLAUDE.md umso wichtiger, da sie dem Coding-LLM den verlorenen Kontext zurückgibt. Man kann sich sogar von Claude Code eine Statuszeile für Claude Code selbst erstellen lassen, die einen sofortigen Überblick über das genutzte Kontextfenster erlaubt:

System initial manuell aufsetzen: Die Grundstruktur eines neuen Projekts sollte man bewusst "per Hand" anlegen. Das stellt sicher, dass die Strukturvorgaben korrekt sind und das Coding-LLM ab dem ersten PRD konsistente Patterns vorfindet, denen es folgen kann.

Hi, can you create a status bar for me, which shows me always the amount of context used in Claude Code? Take the layout in attached picture as template.

- If critical information is missing or if there are implementation alternatives, ask clarifying questions before generating any code
- Hint me also for things I may have overseen or topics which also probably have to covered.

Iterativ verbessern: Skills, CLAUDE.md und PRD-Templates sind keine statischen Artefakte. Wenn auffällt, dass das Coding-LLM wiederholt bestimmte Fehler macht oder Patterns nicht einhält, ist das ein Signal, den entsprechenden Skill oder die CLAUDE.md zu ergänzen. Die Investition zahlt sich bei jedem folgenden Feature zurück.

Sprache: Englisch als Sprache für Code, Kommentare, CLAUDE.md und Skills bevorzugen. Die LLM-Training-Daten sind überwiegend englisch, und die Qualität der Ausgabe ist messbar besser.

Modellwahl: Für Coding-Aufgaben Claude Opus 4.6 verwenden. Der Qualitätsunterschied zu Sonnet ist bei komplexeren .NET-Aufgaben spürbar. Sonnet oder Haiku eignen sich dagegen gut für Subagenten mit klar eingegrenzten Aufgaben.

Weitere Skills: Eine kuratierte Sammlung von Skills für verschiedene Anwendungsfälle findet sich unter skills.sh.

Neben Claude Code haben sich in der täglichen Arbeit weitere AI-Tools bewährt, die den Entwicklungsworkflow sinnvoll ergänzen:

Bildgenerierung mit Gemini: Googles Gemini Nano Banana Pro (Pro ist wichtig) liefert aktuell die besten Ergebnisse für die Generierung von Bildern, die in Web-Projekten verwendet werden sollen – von Hero-Images über Illustrationen bis zu Platzhalterbildern für Previews - insbesondere wegen der korrekten und konsistenten Textausgabe in Bildern.

UI-Prototyping mit Aura.build: Für schnelle UI-Prototypen und Landing Pages hat sich Aura.build als hilfreich erwiesen. Es generiert aus Textbeschreibungen funktionale Web-Interfaces, die als Ausgangspunkt für die eigentliche Implementierung dienen können. Und zwar im Plain HTML Format, dass ich einfach dann in ASP.NET Razor Templates konvertieren lässt.

Auch gut: Readdy.ai - Aber hier wurde die Generierung von HTML auf React umgestellt, was zwar leistungsfähig ist - aber für .NET Entwickler auch schwer verwertbar.

GSD (Get Shit Done): Wer den in diesem Artikel beschriebenen PRD-basierten Workflow weiter formalisieren und automatisieren möchte, sollte sich GSD ansehen. GSD ist ein Context-Engineering-Framework für Claude Code (und andere AI-Coding-Assistenten), das den gesamten Entwicklungszyklus – von der Anforderungserfassung über die Planung bis zur parallelen Ausführung – in einem strukturierten Pipeline-Ansatz orchestriert. Es adressiert dabei gezielt das Problem der "Context Rot" (Qualitätsverlust bei wachsendem Kontextfenster), indem jede Aufgabe mit frischem Kontext ausgeführt wird. GSD generiert dabei automatisch Projektdokumentation (PROJECT.md, REQUIREMENTS.md, ROADMAP.md, PLAN.md), die als persistentes "Gedächtnis" über Sessions hinweg dient.