Claude Projects: So schreibst du Anweisungen, die wirklich funktionieren

Auf einen Blick: Claude Projects laufen oder kippen über die Custom Instructions. Sechs Bausteine sind die Pflicht: Rolle, Zielgruppe, Ergebnisformat, Tonalität, Beispiele, Stopp-Kriterien. Anthropic empfiehlt 2-3 konkrete Beispiele und XML-Tags statt langer Regelwerke. Wer das beachtet, spart pro Antwort Korrekturzeit.

Claude Projects gibt es seit Juni 2024 für Pro, Team und Enterprise. Die meisten Nutzer kennen die Oberfläche: Custom Instructions auf der einen Seite, eine kleine Wissensbibliothek mit hochgeladenen Dateien auf der anderen. Was die Oberfläche nicht zeigt: Die Custom Instructions dürfen bis zu 200 KB groß sein. Das ist deutlich mehr als ChatGPTs Custom-GPT-Limit, und es ist mehr Platz, als die meisten Anwender überhaupt brauchen. Das Problem ist selten zu wenig Platz. Das Problem ist falsch verteilter Platz.

Wer Claude für wiederkehrende Aufgaben einsetzen will (Newsletter-Entwurf, Mandanten-Memo, Code-Review, Marketing-Briefing), merkt schnell: Die Standard-Antwort ist meist okay, aber selten lieferbar. Es fehlen Zwischenüberschriften, der Ton ist zu salopp, das Format passt nicht zur eigenen Vorlage. Jede Antwort braucht Nacharbeit. Mit guten Custom Instructions verschwindet ein großer Teil dieser Nacharbeit, und zwar dauerhaft.

Die sechs Bausteine, die wirklich zählen

In unseren Beratungsmandaten sehen wir immer wieder dieselben sechs Lücken in Claude-Projects-Anweisungen. Wenn diese sechs Bausteine sauber gesetzt sind, läuft der Output. Wenn auch nur einer fehlt, holt die Nacharbeit alles wieder rein.

Rolle. Wer ist Claude in diesem Project? Nicht "Du bist ein hilfreicher Assistent", das ist Default. Sondern: "Du bist Senior-Redakteur eines B2B-Newsletters für Steuerberatungskanzleien. Du hast 15 Jahre Erfahrung im Fachjournalismus und kennst Quellen wie NWB, Beck-online und das BMF-Schreiben-Archiv." Je präziser die Rolle, desto präziser greift Claude auf die richtigen Sprachregister zurück.

Zielgruppe. Wer liest das Ergebnis? "Steuerberater 35-55 Jahre, Einzelkanzlei oder kleine Sozietät, lesen mobil im Zug oder zwischen Mandantenterminen, haben keine Zeit für lange Einleitungen." Das ist eine Anweisung, mit der ein Modell etwas anfangen kann. "Fachkundige Leser" ist es nicht.

Ergebnisformat. Welche Struktur, welche Länge, welche Pflicht-Elemente? "Newsletter-Artikel, 350-450 Wörter, eine H2-Hauptüberschrift, zwei bis drei H3-Zwischenüberschriften, ein Praxisbeispiel, ein Quellen-Hinweis am Ende." Wer das nicht definiert, bekommt jedes Mal etwas anderes.

Tonalität. Du oder Sie? Aktiv oder passiv? Welche Wörter sind verboten? Bei einer Kanzlei meist Sie, sachlich, ohne Floskeln. Bei einem D2C-Shop meist Du, locker, mit Pointe. Beides geht, aber Claude muss wissen, was gilt. Liste mit Wörtern, die nicht vorkommen dürfen, hilft enorm.

Beispiele. Zwei bis drei konkrete Beispiele für gewünschten Output schlagen jedes abstrakte Regelwerk. Anthropic empfiehlt das explizit. Ein Beispiel für einen guten Newsletter-Anriss, ein Beispiel für eine gute H3-Zwischenüberschrift, ein Beispiel für ein gutes Praxisbeispiel. Das Modell lernt aus dem Konkreten besser als aus dem Abstrakten.

Stopp-Kriterien. Wann soll Claude nachfragen statt zu liefern? Wann soll er einen Auftrag ablehnen? "Wenn der Mandantenname konkret genannt wird, frage erst nach, ob die Mail intern oder extern gehen soll. Wenn die Recherche-Quelle älter als 12 Monate ist, weise darauf hin." Stopp-Kriterien sind der unterschätzteste Baustein. Sie verhindern Output, der oberflächlich gut aussieht, aber inhaltlich daneben liegt.

XML-Tags machen den Unterschied

Anthropic dokumentiert intern, dass Claude besser auf strukturierte Anweisungen reagiert, wenn diese in XML-Tags eingerahmt sind. Das klingt technisch, ist aber simpel. Statt eines Fließtexts wie

Schreibe einen Newsletter-Artikel über das Thema XY für Steuerberater.
Der Artikel soll 400 Wörter haben, eine Überschrift, drei Abschnitte.
Wichtig: keine Floskeln, keine Em-Dashes, immer Quellen nennen.

funktionieren XML-Tags besser:

<rolle>
Senior-Redakteur eines B2B-Newsletters für Steuerberater
</rolle>

<zielgruppe>
Steuerberater 35-55 Jahre, lesen mobil, wenig Zeit
</zielgruppe>

<format>
- 400 Wörter
- 1 H2-Überschrift
- 3 H3-Abschnitte
- Quellen am Ende als Liste
</format>

<regeln>
- Keine Floskeln (besonders: "in der heutigen Zeit")
- Keine Em-Dashes
- Jede konkrete Behauptung mit Quellenangabe
</regeln>

<beispiel>
[Hier ein 200-Wort-Beispiel eines guten Anrisses]
</beispiel>

Die XML-Struktur hilft Claude, jeden Block sauber zu trennen. In unseren Tests mit Claude Sonnet 4.8 ist die Modell-Treue gegenüber den Regeln deutlich höher, wenn die Anweisungen so strukturiert sind. Mit Sonnet 4.6 war der Effekt schon spürbar, mit 4.8 ist er noch messbarer.

Eine schlechte und eine bessere Anweisung im Vergleich

Das ist eine typische Anweisung, die wir in Kunden-Projects sehen, bevor wir sie überarbeiten:

Du bist ein hilfreicher Assistent für unsere Marketing-Abteilung.
Bitte schreibe LinkedIn-Posts, die professionell und ansprechend
sind. Achte auf gute Lesbarkeit und verwende Hashtags.

Und das ist die Version nach Überarbeitung:

<rolle>
Social-Media-Manager einer mittelständischen Maschinenbau-Firma
(180 MA, B2B, Anlagen für Lebensmittelindustrie). Du kennst
die Zielkunden (Produktionsleiter, Werksleiter, Einkaufsleiter)
und die Wettbewerber (Multivac, GEA, Krones).
</rolle>

<zielgruppe>
LinkedIn-Nutzer, 40-55 Jahre, Führungspositionen Produktion und
Einkauf, lesen auf dem Smartphone, scannen die ersten 3 Zeilen,
klicken "mehr anzeigen" nur bei klarem Mehrwert.
</zielgruppe>

<format>
- 800-1.100 Zeichen (inkl. Leerzeichen)
- Hook in der ersten Zeile (max 80 Zeichen, MUSS Neugier auslösen)
- 3-5 kurze Absätze mit Leerzeile dazwischen
- Eine konkrete Zahl oder ein konkretes Beispiel pro Post
- CTA am Ende (Frage oder Aufforderung, kein Link)
- 3-5 Hashtags am Ende
</format>

<tonalitaet>
Sachlich, kompetent, kein Hype. Verboten: "innovativ",
"einzigartig", "revolutionär", "Game-Changer", "disruptiv",
Em-Dashes, Emoji am Anfang einer Zeile.
</tonalitaet>

<beispiel_gut>
Wenn eine Verpackungsmaschine ausfällt, sind in der
Lebensmittelproduktion 8.000 Euro pro Stunde weg.

Wir haben uns angesehen, warum 60 Prozent der ungeplanten
Stillstände vermeidbar wären. Drei Punkte stehen ganz oben.

[Drei Punkte mit jeweils 1-2 Sätzen]

Frage an die Produktionsleiter in der Liste: Welcher dieser
drei Punkte trifft bei euch am häufigsten?

#Maschinenbau #Produktion #Lebensmittelindustrie #Wartung
</beispiel_gut>

<stopp_kriterium>
Wenn das Thema rechtlich heikel ist (Schadenersatz, Haftung,
Konkurrenten namentlich), erst eine Rückfrage stellen statt
direkt zu liefern.
</stopp_kriterium>

Die zweite Version ist länger. Das ist Absicht. Sie ersetzt aber jede einzelne Korrektur, die der Marketing-Mitarbeiter sonst pro Post macht. Bei 5 Posts pro Woche ist das schnell eine halbe Stunde pro Woche, die wegfällt. Über das Jahr gerechnet ist das eine Arbeitswoche.

Praxisbeispiel: Kanzlei Hartmann & Partner, Würzburg

Eine mittelständische Steuerkanzlei in Würzburg mit 12 Mitarbeitern setzt Claude Projects seit Anfang 2025 produktiv ein. Drei Projects laufen parallel: Mandanten-E-Mails (Erstentwurf), Recherche-Memos (interne Notizen zu Fachfragen), Newsletter (monatlich an 800 Mandanten).

Die Custom Instructions für das Mandanten-Mail-Project sind etwa 6.000 Zeichen lang. Sie enthalten alle sechs Bausteine in XML-Tags, plus drei Beispiele für gute Mandanten-Mails (anonymisiert, aus dem eigenen Archiv) und ein Beispiel für eine schlechte Mandanten-Mail mit Kommentar, warum sie schlecht ist. Beispiele für Verbotenes funktionieren überraschend gut, weil das Modell so explizit lernt, was es vermeiden soll.

Der Effekt: Erstentwürfe für Mandanten-Mails brauchen jetzt im Schnitt 2-3 Minuten Bearbeitung statt 15-20 Minuten Komplettschreiben. Bei rund 40 Mails pro Woche sind das knapp 8 Stunden, die in Mandantenarbeit fließen. Die Kanzlei hat das interne Project nach einem Quartal evaluiert und das Setup auf das Newsletter-Project und das Recherche-Memo-Project ausgeweitet. Vergleichbares haben wir mit dem DigiMan-Curriculum in unseren Kohorten gesehen, wenn Teilnehmer Projects sauber aufsetzen statt ad hoc zu prompten.

Wichtig dabei: Die Kanzlei prüft jede ausgehende Mail vor dem Versand selbst. KI-Erstentwurf ersetzt keine berufliche Sorgfalt, und die Berufshaftpflicht greift nur, wenn der Berater den Output kontrolliert freigegeben hat.

Was die meisten falsch machen

Die häufigste Schwäche, die wir sehen, ist nicht zu wenig Anweisung. Es ist zu viel Anweisung in der falschen Form. Lange Fließtext-Absätze mit verschachtelten Bedingungen, Negativ-Regeln ohne Beispiele, abstrakte Tonalitäts-Beschreibungen ("authentisch und nahbar"), die jeder anders interpretiert.

Custom Instructions, die in jeder Anfrage in den Context geladen werden, kosten Tokens. Bei 200 KB voller Anweisungen kann das bei einem ausführlichen Dialog spürbar werden. Schlanke, strukturierte Anweisungen mit klaren Beispielen sind nicht nur wirksamer, sie sind auch günstiger im Verbrauch.

Wer das unterschätzt, hat in der Regel ein anderes Problem: Er hat seine eigene Aufgabe nicht klar genug durchdacht. Wenn du Claude nicht in sechs Bausteinen briefen kannst, kannst du die Aufgabe auch nicht an einen menschlichen Mitarbeiter delegieren. Das Project zwingt dich zur Klarheit, und das ist der eigentliche Wert.

Wenn du anfängst: Eine pragmatische Reihenfolge

Wer sein erstes ernsthaftes Project aufsetzt, kann sich an dieser Reihenfolge orientieren.

1. Aufgabe konkret benennen. Was soll am Ende rauskommen? Ein Newsletter? Eine Mail? Ein Memo? Ein Code-Review-Kommentar?
2. Zwei bis drei reale gute Beispiele aus dem eigenen Archiv kopieren. Anonymisieren wo nötig.
3. Aus diesen Beispielen ableiten: Rolle (Wer hat das geschrieben?), Zielgruppe (Wer hat es gelesen?), Format (Wie ist es aufgebaut?), Tonalität (Wie klingt es?).
4. Diese vier Punkte als XML-Tags strukturieren, Beispiele als -Tag einfügen.
5. Zwei Stopp-Kriterien überlegen: Wann soll Claude lieber nachfragen?
6. Ersten Testlauf mit einer realen Aufgabe. Output bewerten, fehlende Aspekte in die Anweisungen ergänzen.

Nach drei bis fünf Iterationen ist ein Project meist auf einem Niveau, auf dem der Output nutzbar ist. Danach kommen nur noch kleine Feinjustierungen, wenn neue Edge-Cases auftauchen.

Was Sonnet 4.8 besser macht

Mit Claude Sonnet 4.8 (Release Mai 2026) folgt das Modell Anweisungen messbar präziser als Sonnet 4.6. In der Praxis heißt das: Du brauchst weniger Wiederholungen in den Custom Instructions, und das Modell hält sich konsequenter an Format-Vorgaben über lange Dialoge hinweg. Anweisungen, die in 4.6 zwei Beispiele brauchten, kommen mit 4.8 oft mit einem einzigen aus.

Das ändert nichts an der Grundstruktur. Die sechs Bausteine bleiben Pflicht, XML-Tags bleiben besser als Fließtext. Aber der Aufwand für gute Projects sinkt mit jedem Modell-Update spürbar. Wer vor einem Jahr aufgegeben hat, weil die ersten Projects mühsam waren, kann es 2026 noch einmal versuchen. Es ist deutlich einfacher geworden.

Häufige Fragen

Wie lang sollten Custom Instructions in einem Claude Project sein?

Es gibt kein optimales Limit, aber als Daumenregel sind 3.000-8.000 Zeichen für die meisten Anwendungen genug. Die technische Obergrenze liegt bei 200 KB. Wer da hineinläuft, hat meist zu viel redundante Text-Anweisung und zu wenig strukturierte Beispiele. Kürze und strukturiere lieber, statt mehr zu schreiben.

Funktionieren XML-Tags auch in ChatGPT oder Mistral Le Chat?

XML-Tags helfen bei allen großen Modellen, weil sie das Parsing von Block-Strukturen erleichtern. Anthropic hat es zuerst dokumentiert, aber ChatGPT und Mistral profitieren ebenfalls. Wenn du Multi-Tool-Workflows hast, lohnt es sich, Custom Instructions einheitlich strukturiert zu schreiben, damit sie portabel sind.

Kann ich Claude Projects auch ohne Custom Instructions nutzen?

Ja, aber dann ist der Mehrwert gegenüber einem normalen Chat begrenzt. Der eigentliche Wert eines Projects liegt in der Kombination aus persistenten Anweisungen und der hochgeladenen Wissensbibliothek. Wer nur Dateien hochladen will ohne Anweisungen, kann das auch im normalen Chat machen.

Was sind realistische Stopp-Kriterien für ein Project?

Gute Stopp-Kriterien sind konkret und prüfbar. "Wenn der Mandantenname genannt wird, frage erst nach der Versand-Variante" funktioniert. "Wenn es heikel wird, melde dich" funktioniert nicht, weil das Modell "heikel" nicht zuverlässig erkennt. Je messbarer das Kriterium, desto verlässlicher hält Claude es ein.

Zuletzt geprüft am 21. Mai 2026.

Bereit für den nächsten Schritt? Wenn du KI im Geschäftsalltag systematisch einsetzen willst, schau dir unseren kostenlosen KI-Schnupperkurs an. Fünf Lektionen, eine Live-Demo pro Woche, null Euro. Für die umfassende Schulung mit Bildungsgutschein oder QCG-Förderung lohnt sich unser Digitalisierungsmanager, der KI-Praxis, Prompting und Compliance in 16 Wochen kombiniert.

Über den Autor

Dr. Jens Aichinger ist promovierter Wirtschaftspädagoge, Erwachsenenbildner und Geschäftsführer von SkillSprinters by Dr. Aichinger. Er bildet seit über 15 Jahren Berufstätige, Fachkräfte und Quereinsteiger weiter, hat über 70 Fachbücher zu Prüfungsvorbereitung und Karrierethemen veröffentlicht und betreibt mit SkillSprinters einen der digital am stärksten wachsenden Bildungsträger im DACH-Raum.