Claude Code Best Practices: Community Secrets für 10x Produktivität
TeamDay
TeamDay
2026/01/20
18 min read

Claude Code Best Practices: Community Secrets für 10x Produktivität

Claude Code ist stillschweigend zum bevorzugten Werkzeug für KI-native Entwickler und Knowledge Worker geworden. Aber zwischen der offiziellen Dokumentation und den YouTube-Tutorials gibt es eine Lücke: die echten Praktiken, die produktive Nutzer von denen unterscheiden, die "Geld an Anthropic spenden."

Dieser Leitfaden vereint Erkenntnisse von Claude Code-Schöpfer Boris Cherny, Produktentdeckungsexpertin Teresa Torres und Community-Pädagogen wie Greg Isenberg und Ross Mike—kombiniert offizielle Fähigkeiten mit bewährten Workflows, die tatsächlich funktionieren.

Der Kerngedanke: Input-Qualität bestimmt Output-Qualität

Lassen Sie uns mit der wichtigsten Lektion beginnen, artikuliert von Ross Mike in der Greg Isenberg Show:

"However good your inputs are will dictate how good your output is. We're getting to a point where the models are so freakishly good that if you are producing quote unquote slop, it's because you've given it slop."

Dies ist nicht nur motivierende Rhetorik—es ist das fundamentale Prinzip hinter jeder Best Practice in diesem Leitfaden. Claude's Fähigkeiten haben einen Punkt erreicht, an dem Qualitätsprobleme auf menschliche Anweisungen zurückzuführen sind, nicht auf Modellbeschränkungen.

Teil 1: Das ask_user_question-Geheimnis

Die meisten Claude Code-Nutzer kennen dieses Tool nicht. Diejenigen, die es kennen, betrachten es als die wichtigste Funktion für nicht-triviale Projekte.

Was es tut

Bei der Planung einer Funktion kann Claude Sie mit Multiple-Choice-Fragen über Spezifika befragen, die Sie nie selbst angeben würden. Anstatt Claude's generische Planungsfragen zu akzeptieren, zwingt das ask_user_question-Tool zu granularem Denken über:

  • Datenbankentscheidungen und Datenmodelle
  • UI/UX-Layouts und Interaktionen
  • Kostenbehandlung und Grenzfälle
  • Fehler-States und Recovery-Flows
  • Test-Strategien

Wie man es aufruft

Bitten Sie einfach Claude, Sie über Ihr Projekt zu befragen:

> Interview me about this feature: user authentication system

Oder seien Sie spezifischer:

> Before implementing the payment flow, use ask_user_question to understand my requirements for:
> - Payment providers
> - Currency handling
> - Refund policies
> - Error recovery

Claude wird Multiple-Choice-Fragen stellen und Sie die Entscheidungen durchdenken lassen, bevor Code geschrieben wird.

Warum das wichtig ist

Greg Isenberg's Schlüsseleinsicht: "A lot of times people will describe a product, not describe features, and will be frustrated with AI." Der ask_user_question-Ansatz zwingt Sie, in konkreten Funktionen mit klaren Akzeptanzkriterien zu denken.

Die Investition in vorausgehende Fragen verhindert teure Iterationsschleifen später. Wie Ross Mike sagt: "If you have a terrible plan, if you have a terrible PRD, this doesn't matter. You're just donating money to Anthropic."

Teil 2: Context-Architektur (Die Teresa Torres-Methode)

Teresa Torres—Autorin von Continuous Discovery Habits—schreibt keinen Code. Doch sie ist eine der sophistiziertesten Claude Code-Nutzerinnen geworden, indem sie das entwickelt hat, was sie "context architecture" nennt.

Das Prinzip

"To do context well, it's not just that we have to document everything. We have to document everything in teeny-tiny files so that when we ask Claude to do a task, we can give Claude just the context it needs."

Dies ist das Gegenteil des typischen Ansatzes (eine massive CLAUDE.md-Datei). Stattdessen erstellt Torres granulare Context-Bibliotheken:

.claude/
├── CLAUDE.md                    # High-level project overview
├── context/
│   ├── business-profile.md      # Company background, goals
│   ├── writing-style.md         # Tone, vocabulary preferences
│   ├── product-docs/
│   │   ├── auth-system.md       # Authentication details
│   │   ├── payment-flow.md      # Payment implementation
│   │   └── api-design.md        # API conventions
│   └── personal/
│       ├── preferences.md       # Your work preferences
│       └── schedule.md          # Availability, deadlines
└── commands/
    ├── today.md                 # Daily task generation
    ├── blog-review.md           # Writing feedback
    └── research.md              # Research automation

"Lazy Prompting" durch Context

Mit umfangreichen Context-Bibliotheken kann Torres "faul bei Prompts" sein:

> Claude, blog post review

Claude lädt ihren Writing-Style-Leitfaden und bietet Feedback an, das auf ihren tatsächlichen Zielen basiert—keine lange Erklärung nötig.

Pair Programming für alles

Torres's mächtigste Einsicht geht über Code hinaus:

"I pair program now with everything I do, even if it's not programming. I pair task manage and I pair write and I pair everything."

Ihr eigener /today-Befehl generiert täglich To-Do-Listen durch Überprüfung mehrerer Quellen:

  • Markdown Task-Dateien
  • Trello-Boards
  • Kalenderintegrationen
  • Unvollendete Elemente des Vortags

Teil 3: Die 50%-Context-Regel

Ross Mike betont einen kritischen Schwellenwert, den die meisten Nutzer ignorieren:

"Never exceed 50% context. Once you hit ~100K tokens in a session, model quality deteriorates."

Wie man Context überwacht

Nutzen Sie den /context-Befehl, um Ihre Token-Nutzung zu visualisieren:

> /context

Dies zeigt ein farbiges Gitter, das zeigt, was Ihren Context-Fenster verbraucht.

Wann Sie einen Neustart beginnen sollten

Starten Sie neue Sessions, wenn:

  • Context über 50% geht: Die Qualität verschlechtert sich mit sehr großen Kontexten
  • Sie zwischen Projekten wechseln: Verschiedene Codebases benötigen verschiedene Kontexte
  • Die Task sich dramatisch ändert: Frontend zu DevOps, zum Beispiel
  • Die Konversation wird alt: Alte Informationen können Claude verwirren

Konversationen komprimieren

Der /compact-Befehl fasst Ihre Konversationshistorie zusammen, gibt Token frei und bewahrt wichtige Informationen:

> /compact focus on the authentication changes we made

Dies erstellt eine Zusammenfassung und startet die Konversation mit dieser Zusammenfassung als Context neu.

Teil 4: RALPH Loops (Mit Vorsicht verwenden)

RALPH (benannt nach Ralph Wiggum aus The Simpsons) ist eine autonome Entwicklungstechnik, bei der Claude eine Task-Liste iterativ ohne menschliche Intervention durcharbeitet.

Wie es funktioniert

  1. Sie stellen ein PRD (Product Requirements Document) mit einer Task-Liste bereit
  2. Ein Hook verhindert, dass Claude nach der Vollendung jeder Task beendet wird
  3. Claude arbeitet an Task 1, dokumentiert den Fortschritt, zieht zu Task 2
  4. Die Loop setzt sich fort, bis alle Tasks abgeschlossen sind

Die Warnung

Ross Mike ist unmissverständlich über RALPH Loops:

"If you haven't built anything, deployed anything, there isn't a URL that I myself or Greg can click on that you've built, you have no business using RALPH."

RALPH Loops verstärken Ihre Planungsqualität:

  • Gutes PRD + RALPH = Multi-Tag-Loops, die vollständige Anwendungen erstellen
  • Schlechtes PRD + RALPH = Teures Chaos

Best Practices für RALPH

Falls Sie RALPH Loops verwenden:

  1. Extrem detailliertes PRD: Nutzen Sie ask_user_question, um jede Lücke zu füllen
  2. Klare Akzeptanzkriterien: Jede Funktion benötigt testbare Kriterien
  3. Test-zuerst Verifikation: Tests nach jeder Funktion durchlaufen, bevor Sie fortfahren
  4. Unter 50% Context bleiben: Token-Nutzung durchgehend überwachen

Teil 5: Die Boris Cherny-Prinzipien

Als Claude Code-Schöpfer bietet Boris Cherny einzigartige Einsichten, wie man über KI-gestützte Entwicklung denkt.

70% Produktivitätssteigerung

Bei Anthropic, wo Claude Code entwickelt wurde:

"Anthropic has tripled in headcount, but productivity per engineer has grown 70% because of Claude Code. That's not automation replacing work—that's augmentation creating leverage."

Dies ist keine Automation—es ist Augmentation. Claude handhabt die mühsamen Teile, während Menschen Urteil und Richtung bieten.

Bauen für zukünftige Modelle

"Don't build for the model of today. Build for the model 6 months from now."

Cherny's Schätzung: Ein Projekt, das 20-30 Ingenieuren zwei Jahre brauchte (Facebook Groups Migration), könnte jetzt von 5 Ingenieuren in 6 Monaten durchgeführt werden. In weiteren 6 Monaten? Vielleicht nur einer.

Dies bedeutet:

  • Investieren Sie in gute Architektur über clevere Prompts
  • Bauen Sie Workflows, die mit Modellverbesserungen skalieren können
  • Nicht über-optimieren für aktuelle Beschränkungen

Der Generalist-Vorteil

"At Anthropic, product managers code. Data scientists code. User researchers code. This isn't about job titles blurring—it's about reducing the coordination costs of building."

Claude Code ermöglicht diesen Generalist-Ansatz. Wenn jeder zum vollständigen Stack beitragen kann, erhöht sich die Geschwindigkeit exponentiell.

Teil 6: Automation vs. Augmentation

Teresa Torres's Framework für jede Task:

"I forced myself every time I did a task to ask: How can AI help with this? Can it automate it? Can it augment it? Do I like doing it? Do I want AI to do it for me?"

Was man automatisieren sollte

  • Research-Zusammenfassungen (arXiv, Google Scholar-Papiere)
  • Datenverarbeitung und Formatierung
  • Boilerplate-Code-Generierung
  • Test-Schreiben
  • Dokumentation-Updates

Was man augmentieren sollte (Menschliche Beteiligung behalten)

  • Schreiben (wenn Sie es gerne tun)
  • Design-Entscheidungen
  • User Research-Synthese
  • Strategische Planung
  • Code-Architektur

Torres's Einsicht: "I love to write. I don't want to automate writing." Während KI-Fähigkeiten expandieren, seien Sie absichtsvoll, welche Teile Ihrer Arbeit Sie definieren.

Teil 7: Wesentliche Workflows

Tägliches Task-Management

Erstellen Sie einen /today-Befehl, der mehrere Quellen überprüft:

<!-- .claude/commands/today.md -->
Check my task sources and generate today's priorities:
1. Review @tasks/current.md for active items
2. Check for any overdue deadlines
3. Consider my calendar for today
4. Prioritize by impact and urgency

Format as a numbered list with time estimates.

Research-Automation

Richten Sie nächtliche Research-Verarbeitung ein:

<!-- .claude/commands/research.md -->
Process papers I've downloaded to @research/inbox/:
1. Summarize key findings (3-5 bullet points each)
2. Identify relevance to my current project @context/project-goals.md
3. Extract quotes worth saving
4. Move processed files to @research/processed/

Code Review

Erstellen Sie einen umfassenden Review-Befehl:

<!-- .claude/commands/review.md -->
Review the code changes in my current branch:
1. Check for security vulnerabilities
2. Evaluate against our standards @context/code-standards.md
3. Identify potential performance issues
4. Suggest improvements (be specific)
5. Note any missing tests

Intelligente Suche

Torres's Ansatz zum Finden von Dingen über Notizen:

> I have a thing called new blog post tomorrow

Claude sucht Context und findet "article Wednesday"—verstehen der Absicht, auch wenn Sie sich falsch erinnern.

Teil 8: CLAUDE.md Best Practices

Ihre CLAUDE.md-Datei ist Claude's persistentes Gedächtnis. Hier erfahren Sie, wie man es effektiv strukturiert:

Hierarchie

Enterprise policy (organization-wide)
    └── Project memory (team-shared, in git)
        └── Project rules (modular topics)
            └── User memory (your preferences)
                └── Local project (not in git)

Gute CLAUDE.md-Struktur

# Project Name

## Architecture
- Framework: [your stack]
- Database: [your database]
- Key patterns: [important conventions]

## Code Standards
- [Specific, actionable rules]
- [Not generic advice]

## Commands
- `bun run dev`: Start development
- `bun test`: Run tests

## Important Context
- [Project-specific gotchas]
- [Things Claude should always remember]

## Don'ts
- [Specific anti-patterns to avoid]

Bedingte Regeln

Nutzen Sie Frontmatter für Path-spezifische Regeln:

---
paths:
  - "src/api/**/*.ts"
---

# API Development Rules

- All endpoints must include input validation
- Use the standard error response format
- Include OpenAPI documentation

Teil 9: Für nicht-technische Nutzer

Claude Code ist nicht nur für Entwickler. Teresa Torres nutzt es täglich ohne Coding-Erfahrung.

Erste Schritte

  1. Installieren Sie Claude Code: Folgen Sie dem Setuphandbuch
  2. Beginnen Sie einfach: Bitten Sie Claude, Ihre Projektstruktur zu erklären
  3. Bauen Sie Context schrittweise auf: Erstellen Sie Context-Dateien, während Sie lernen

Fragen, die Sie stellen können

> What does this code do?
> Explain this error in simple terms
> I need a feature where users can [describe what you want]
> Fix the bug when I click [describe the problem]

Tipps

  • Seien Sie spezifisch: "Fix the bug when I click submit" ist besser als "fix the bug"
  • Teilen Sie Fehler: Kopieren Sie den vollständigen Fehlertext—das hilft Claude zu diagnostizieren
  • Fragen Sie nach Erklärungen: "Explain what you just did in simple terms"
  • Benennen Sie Sessions: Nutzen Sie /rename my-task, um später zurückzukehren

Teil 10: TeamDay-Integration

TeamDay führt Claude Code auf Linux-Servern aus und macht es über Web-Browser zugänglich. Das bedeutet, Sie können:

  • Auf Claude Code von jedem Gerät zugreifen, ohne lokale Installation
  • Sessions mit Teamkollegen teilen
  • Mit TeamDay's Agent-Ökosystem integrieren
  • Lange laufende Tasks ausführen, ohne Ihren Laptop offen zu halten

Erste Schritte mit TeamDay + Claude Code

  1. Erstellen Sie einen TeamDay-Workspace
  2. Verbinden Sie Ihre Repositories
  3. Starten Sie eine Claude Code-Session von der Web-Oberfläche
  4. Ihre CLAUDE.md und Context-Dateien werden automatisch geladen

Wichtige Erkenntnisse

  1. Input-Qualität ist alles: Nutzen Sie ask_user_question gewissenhaft
  2. Context-Architektur: Granulare Dateien schlagen monolithische Dokumentation
  3. Überwachen Sie Context-Nutzung: Bleiben Sie unter 50%, nutzen Sie /compact, wenn nötig
  4. RALPH Loops benötigen Expertise: Bauen Sie zuerst manuelle Wiederholungen auf
  5. Automatisieren Sie selektiv: Behalten Sie, was Sie lieben, automatisieren Sie, was Sie nicht lieben
  6. Bauen Sie für die Zukunft: Modelle verbessern sich schneller als Ihre Workflows

Was ist als nächstes

Die Experten sind sich einig: Wir sind in den frühen Tagen der KI-gestützten Arbeit. Boris Cherny's Vorhersage, dass ein 20-30 Ingenieur-Projekt bald von einer Person durchgeführt werden könnte, ist keine Übertreibung—es ist die Flugbahn, auf der wir sind.

Die Gewinner werden nicht diejenigen mit den besten Tools sein, sondern diejenigen, die in die Erstellung präziser Eingaben investieren. Beginnen Sie mit ask_user_question, bauen Sie Ihre Context-Bibliothek auf und iterieren Sie.


Sources