Jira-Tickets mit Claude Code

Mitten in der Entwicklung fällt mir ein Bug auf. Nicht kritisch, aber er gehört ins Backlog. Mein bisheriger Workflow sah ungefähr so aus: Notiz-App öffnen, Stichpunkte reintippen, weiterentwickeln – und irgendwann später, wenn ich Zeit habe, Jira öffnen, das richtige Projekt suchen, den passenden Issue-Typ auswählen, alle Pflichtfelder befüllen, das eigentliche Problem ausformulieren, dabei auf das richtige Format achten, schnell noch ein paar AKs überlegen und ach ja noch schnell das Backlog checken ob’s das Problem oder ein ähnliches schon dokumentiert ist und „schon“ kann das Ticket angelegt werden.

Das kostet nicht nur Zeit, sondern reist einen auch aus dem Kontext.

Kurze Unterbrechung – KI, die im Unternehmen wirklich ankommt

Seit ein paar Wochen läuft das bei mir allerdings anders. Ein wilder Bug erscheint, ich tippe ein paar Stichpunkte in Claude Code (oder kopiere das Problem als Log einfach direkt dort hin), sage „erstell mir daraus ein Ticket“ – funkelnder Glitzerstaub fliegt durch die Luft – und das Ticket liegt schon in Jira bereit. Fertig ausformuliert, ohne Kontextwechsel, ohne Pflichtfeld-Gefummel, ohne die Jira-Oberfläche überhaupt zu öffnen.

Dahinter steckt ein selbstgeschriebener Claude Code Skill in Kombination mit dem Atlassian MCP-Server. Wie ich dahin gekommen bin und was es dafür gebraucht hat, möchte ich im folgenden beschreiben.

Atlassian MCP: Jira direkt aus dem Terminal

MCPs – also Model Context Protocol Server – kennen wir mittlerweile alle. Sie ermöglichen es KI-Assistenten mit externen Systemen zu kommunizieren: Datenbanken abfragen, APIs ansprechen, Dateien in Cloud-Diensten verwalten. Für Atlassian gibt es einen offiziellen MCP-Server, der Claude Code direkten Zugriff auf Jira und Confluence gibt.

Die Einrichtung ist ein Einzeiler. In Claude Code reicht ein einziger Befehl:

claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp

Beim ersten Aufruf wird man zur Authentifizierung auf die Atlassian-Seite weitergeleitet, und danach stehen die Jira-Tools zur Verfügung; Projekte abfragen, Issues durchsuchen, Tickets anlegen. Der erste Test funktioniert prompt. Nach ein paar Funktionstests stellt sich allerdings schnell heraus, dass zwischen „funktioniert im Test“ und „funktioniert im Alltag“ noch ein gutes Stück Weg liegt.

Der naive Ansatz: „Claude, leg ein Ticket an“

Mein erster Versuch war denkbar einfach: Ich habe Claude gebeten, für einen gefundenen Bug ein Jira-Ticket anzulegen. Claude hat auch sofort losgelegt und ein Ticket formuliert. Summary, Description, alles da. Nur hat das Format und Layout so gar nicht zu unseren Team-Konventionen gepasst. Also habe ich Claude gebeten, sich erst mal bestehende Tickets im Projekt anzuschauen und daraus abzuleiten, wie unsere Tickets aussehen.

Daraufhin versuchte Claude, über den MCP das Jira-Projekt zu finden und Tickets zu lesen. Mehrere Versuche, verschiedene API-Calls – und keiner funktionierte. Nach ein paar Runden stellte sich heraus: Der MCP war gar nicht mehr authentifiziert. Der Token war abgelaufen. Also habe ich mich neu eingeloggt und Claude gebeten, es nochmal zu versuchen.

Diesmal klappte die Verbindung. Claude fand das richtige Projekt, las eine Reihe bestehender Tickets durch und hatte daraus ein deutlich besseres Ticket formuliert; Format und Struktur stimmten jetzt ungefähr. Ich habe noch ein paar Anpassungen an der Description gemacht, und dann sollte Claude das Ticket über den MCP in Jira anlegen.

Der nächste Fehler: Projektspezifische Pflichtfelder waren nicht gesetzt. Verantwortliches Team, Ticket-Size, zugewiesener Bearbeiter – all diese Custom Fields, die unser Jira-Projekt verlangt, kannte Claude natürlich nicht. Also wieder zurück: Bestehende Tickets analysieren, die Pflichtfelder identifizieren. Ich habe Claude mitgeteilt, mit welchen Werten die Felder befüllt werden sollen. Und schließlich, nach dem beschriebenen Hin und Her, legte Claude tatsächlich das Ticket an. Erfolg.

Puh, eine ganz schöne Odyssee. Händisch hätte ich das Ticket vermutlich genauso schnell angelegt. Und das größte Problem: Ist der Claude-Kontext einmal gelöscht, geht das Spiel von vorne los. Also musste eine Lösung her. Die CLAUDE.md (also Claudes projektweite Konfigurationsdatei) damit vollzustopfen wäre eine Möglichkeit, allerdings würde diese Informationen dann mit jedem einzelnen Prompt mitgeschleppt werden. Eher unpraktisch.

Die Lösung: Ein Skill als Gedächtnis

Claude Code bietet neben der CLAUDE.md noch eine zweite Möglichkeit, Wissen zu hinterlegen: Skills. Ein Skill ist im Kern eine Markdown-Datei, oder eine Sammlung davon, mit Anleitungen und Kontextinformationen. Also ähnlich wie die CLAUDE.md, aber mit einem entscheidenden Unterschied: Skills werden nicht bei jedem Prompt automatisch mitgeladen. Stattdessen kann man sie entweder gezielt manuell aufrufen oder Claude erkennt selbstständig, dass für eine bestimmte Aufgabe ein passender Skill vorhanden ist, und lädt ihn eigenständig.

Genau das richtige für meinen Fall. All das Wissen, das wir in der Odyssee zuvor mühsam zusammengetragen hatten – welches Projekt, welche Issue-Typen, welche Pflichtfelder, welche Description-Templates – lässt sich in einem Skill ablegen. Sage ich Claude „erstell ein Jira-Ticket“, lädt er den Skill und hat sofort alles parat. Frage ich ihn dagegen nach einem Code-Review, bleibt der Jira-Skill außen vor und belastet den Kontext nicht.

Ich habe Claude den Skill selbst schreiben lassen, und zwar iterativ. Jeder fehlgeschlagene Ticket-Versuch hat ein neues Learning produziert, das direkt in den Skill eingeflossen ist. Pflichtfeld vergessen? Ab in den Skill. Falsches Description-Format? Template anpassen. Auth abgelaufen? Health-Check einbauen. So ist Stück für Stück ein Skill entstanden, der alle Eigenheiten unseres Jira-Projekts kennt.

Was der Skill leistet

Im Kern löst der Skill drei Probleme:

Erstens kennt er das Projekt. Alle projektspezifischen Informationen – Issue-Typen, Pflichtfelder mit ihren kryptischen Custom-Field-IDs, Standardwerte, das zugehörige Epic – stehen direkt im Skill. Claude muss nichts mehr recherchieren und kann sofort loslegen.

Zweitens strukturiert er den Workflow. Statt ins Blaue rein ein Ticket anzulegen und bei Fehlern nachzubessern, sammelt Claude zuerst alle nötigen Informationen und fragt proaktiv nach, was noch fehlt. Erst wenn alles vollständig ist, wird mir das Ticket zur Freigabe vorgelegt. Und erst nach meinem OK wird es tatsächlich in Jira erstellt. Kein Trial-and-Error mehr.

Drittens fängt er MCP-Probleme ab. Der Atlassian MCP-Server verliert regelmäßig die Verbindung … die Authentifizierung läuft ab und der Token wird ungültig. Ohne den Skill lief Claude einfach gegen Auth-Fehler und versuchte trotzdem weiterzuarbeiten. Jetzt wird gleich am Anfang ein Health-Check ausgeführt: Ein einfacher API-Call prüft, ob die Verbindung steht. Wenn nicht, bekomme ich sofort den Hinweis, dass ich mich neu authentifizieren muss.

Der Skill im Detail

Damit nachvollziehbar wird, was genau in so einem Skill steckt, hier der vollständige Skill:

---
description: "Create Jira tickets for <Projekt> following team conventions"
---

# Create Jira Ticket

Erstelle Jira-Tickets für das <Projekt>-Projekt nach Team-Konventionen.

## Voraussetzungen

- Atlassian MCP-Server muss verbunden sein
- Cloud ID: '<cloud-id>'
- Projekt: '<PROJECT-KEY>'

## Issue Types

| Type | Verwendung |
|------|------------|
| Bug (<type-id>) | Fehler, unerwartetes Verhalten |
| Task (<type-id>) | Neue Features, Refactoring, technische Aufgaben |

## Description-Format

### Für Bugs:
'''
[Problembeschreibung in 1-2 Sätzen]

**Beispiel:**
* Frage: _[Beispiel-Input]_
* Ergebnis: [Beobachtetes Verhalten]

**AKs:**
- [ ] [Akzeptanzkriterium 1]
- [ ] [Akzeptanzkriterium 2]

**Notizen:**
[Zusätzliche Infos, Referenzen]
'''

### Für Tasks:
'''
Als Entwickler möchte ich [Ziel], damit [Nutzen].

## Hintergrund
[Kontext und Problemstellung]

## Lösungsvorschlag
[Empfohlener Ansatz]

**AKs:**
- [ ] [Akzeptanzkriterium 1]
- [ ] [Akzeptanzkriterium 2]

**Notizen:**
[Betroffene Dateien, Referenzen]
'''

## Workflow

1. **Auth prüfen**: Zuerst mcp__atlassian__atlassianUserInfo aufrufen,
   um zu prüfen ob die Authentifizierung aktiv ist
   - Die Atlassian-Auth läuft täglich ab und muss neu authentifiziert werden
   - Bei Auth-Fehler: Nutzer informieren, dass er sich neu einloggen muss
2. **Ticket vorbereiten**: Summary und Description nach obigem Format erstellen
3. **Nutzer-Approval**: Ticket dem Nutzer zur Freigabe präsentieren
4. **Ticket erstellen**: Nach Approval via mcp__atlassian__createJiraIssue anlegen

## API-Aufruf

Verwende 'mcp__atlassian__createJiraIssue' mit:
- cloudId: '<cloud-id>'
- projectKey: '<PROJECT-KEY>'
- issueTypeName: 'Bug' oder 'Task'
- summary: Kurzer, prägnanter Titel
- description: Markdown nach obigem Format
- additional_fields: Pflichtfelder (siehe unten)

## Pflichtfelder (additional_fields)

Diese Felder müssen bei jedem Ticket gesetzt werden:

'''json
{
  "customfield_1234": [{"id": "1001"}],
  "customfield_2345": [{"id": "1002"}],
  "customfield_3456": {"id": "1003"},
  "customfield_4567": {"id": "1004"},
  "customfield_5678": {"id": "<user-id>"},
  "customfield_6789": "<EPIC-KEY>"
}
'''

| Feld | customfield | Wert | ID |
|------|-------------|------|-----|
| Country assignment | 1234 | Deutschland | 1001 |
| Internal client | 2345 | <Kundenname> | 1002 |
| Responsible team | 3456 | <Team-Name> | 1003 |
| Ticket-Size | 4567 | S (<3 PT) | 1004 |
| Task responsible | 5678 | <Bearbeiter> | <user-id> |
| Epic Link | 6789 | <EPIC-KEY> | - |

## Parent Epic

Standard-Epic für <Projekt>-Arbeit: '<EPIC-KEY>'

Wie sich der Alltag verändert hat

Wenn mir beim Entwickeln ein Bug auffällt oder eine technische Aufgabe einfällt, tippe ich ein paar Stichpunkte in Claude Code:

Bug: Wenn man im Suchfeld ein Sonderzeichen eingibt, wird die Ergebnisliste nicht aktualisiert. Tritt auf bei &, < und >. Vermutlich fehlendes Escaping.

Claude nimmt diese Stichpunkte, formt daraus ein sauber strukturiertes Ticket nach unserem Team-Template, zeigt es mir zur Freigabe und legt es nach meinem OK in Jira an. Das Ganze kostet mich kaum eine Minute und ich kann sofort zu meinem aktuellen Task zurückkehren.

Was ich daraus gelernt habe

MCPs geben Claude Zugriff auf externe Systeme, aber das Wissen über deren Eigenheiten muss jedes mal ermittelt werden. Dieses projektspezifische Wissen in einem Skill zu speichern macht den Unterschied zwischen einem „dummen“ Workflow, der sich immer wieder die gleichen Informationen zusammensuchen muss, und einem Werkzeug, das einfach funktioniert.

Außerdem lohnt es sich, den Skill iterativ zusammen mit Claude zu entwickeln. Jeder Fehler wird zum Anlass, den Skill zu verbessern – und Claude schreibt die Lösungen gleich mit rein.

Fazit

Der MCP liefert die technische Anbindung an Jira. Der Skill liefert das Wissen darüber, wie unser Jira Projekt funktioniert. Zusammen ergibt das einen Workflow, der mir tatsächlich Arbeit abnimmt. Nicht als Proof of Concept, sondern im täglichen Einsatz.