AI-translated from English; not yet reviewed by a fluent editor. # Eine genehmigte Funktion durch Jira und eine geprüfte Änderung mit Claude Code führen > Führe eine genehmigte Funktion durch ein echtes Jira-Epic, alle Storys und sinnvolle Unteraufgaben. Prüfe jede Änderung mit Claude Code, kontrolliere die Vorgangsaktualisierungen und überprüfe die Entscheidung zu den Projektanweisungen. By BIG CHANGE Editorial Published: 2026-10-20T13:23:38.288Z Updated: 2026-10-20T13:23:38.288Z Canonical: https://bigchange.ai/blog/claude-code-jira-approved-feature-guide ![Conceptual charcoal illustration of a developer at a standing counter reviewing a generic two-column code diff on an arm-mounted display.](https://bigchange.ai/api/media/file/claude-code-jira-feature-review-hero-v2.png) AI-generated conceptual illustration by BIG CHANGE. Eine genehmigte Funktion kann vor ihrem Abschluss drei Systeme durchlaufen: ein Anforderungsdokument, eine Jira-Vorgangshierarchie und ein Repository. Claude Code kann beim Entwurf und bei der Umsetzung helfen, doch die Verbindungen zwischen diesen Systemen benötigen menschliche Genehmigung und direkte Kontrollen. Dieser Leitfaden führt Entwickler oder Teamleitungen durch eine echte Funktion, einschließlich **jeder genehmigten Story**, ihrer ursprünglichen Tests, autorisierter Jira-Aktualisierungen und einer überprüften Entscheidung zu den Projektanweisungen. Dies ist ein dokumentationsbasiertes Verfahren. BIG CHANGE hat weder auf ein Jira-Projekt zugegriffen noch Claude Code ausgeführt, ein Repository verändert oder eine Umsetzungsdauer gemessen. Die konkreten Vorgangstypen, Felder, Übergänge, Befehle und Kosten ergeben sich aus deinem Projekt und Konto. ## Die große Veränderung - **Was sich geändert hat:** Eine Funktion lässt sich von ihrer genehmigten Anforderung über einen echten übergeordneten Jira-Vorgang und jede Story bis zu geprüftem Code, ursprünglichen Kontrollen und autorisierten Vorgangsaktualisierungen verfolgen. - **Warum das wichtig ist:** Die Vorgangszuordnung, Testaufzeichnungen und direkt aus Jira zurückgelesenen Daten zeigen, welche genehmigten Arbeiten abgeschlossen sind und welche Story noch offen ist. - **Worauf zu achten ist:** Projektspezifische Felder und Übergänge, Schreibvorgänge mit unklarem Ergebnis und fehlgeschlagene Prüfungen müssen Menschen klären; Anweisungen für Claude Code allein erteilen keine Arbeitsberechtigung. ## Vor dem Start Wähle eine Funktion mit einem vom Verantwortlichen genehmigten Auftrag, einem Repository, das du bearbeiten darfst, und einer ausführbaren ursprünglichen Abnahmeprüfung. Die tatsächliche Arbeit muss im gewählten Jira-Cloud-Projekt einen übergeordneten Vorgang auf Epic-Ebene, alle genehmigten Storys und mindestens eine sinnvolle Unteraufgabe unter einer Story rechtfertigen. Gibt es keine echte Unteraufgabe, bleibt dieses vollständige Ergebnis offen; ein rein dekorativer Vorgang würde den Plan verfälschen. Erfasse Auftraggeber, Genehmigungsbefugnis, Quellrevision, erlaubte Daten, anfänglichen Git-Commit, Isolierungs- oder Rücksetzweg und die Person, die Code prüfen und den Jira-Status ändern darf. Prüfe die installierte [Version, Authentifizierung und Berechtigungen von Claude Code](https://code.claude.com/docs/en/permissions). Stelle sicher, dass die `CLAUDE.md` des Repositorys Projektanweisungen enthält, aber keine Erlaubnis zum Bearbeiten, Ausführen von Befehlen oder Senden von Daten erteilt. Lege fest, welche Anforderungen und welchen Code Claude erhalten darf, welche Befehle es ausführen darf und welche Nutzungsgrenze für diese Funktion gilt. Die Nutzung von Claude Code kann ein Abonnementkontingent verbrauchen oder Anbietergebühren verursachen; [Anthropics Kostenleitfaden](https://code.claude.com/docs/en/costs) legt deine Rechnung nicht im Voraus fest. Für Jira benötigst du die Erlaubnis, die betreffenden Vorgangstypen anzusehen und anzulegen sowie später als autorisierte Person zu kommentieren oder Statusübergänge auszuführen. Ein privates Skript kann [die von Atlassian dokumentierte Methode mit E-Mail und API-Token](https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis) verwenden; eine Integration benötigt möglicherweise OAuth. Bewahre Zugangsdaten in einem privaten Geheimnisspeicher auf. Halte sie aus Prompts, Vorgangstexten, `CLAUDE.md`, Protokollen und Versionsverwaltung heraus. Vereinbare die Sichtbarkeit der Vorgänge, bevor du Anforderungen an Jira sendest. Führe während des Ablaufs sieben private Aufzeichnungen: `docs/feature-prd.md`, `ticket-plan.json`, ein nur ergänzbares Protokoll der Vorgangsschreibzugriffe, `ticket-map.json`, einen Umsetzungsnachweis je Story, ein Jira-Aktualisierungsprotokoll und eine Rückblickentscheidung. Dies sind Aufzeichnungen deiner Funktion, keine von BIG CHANGE bereitgestellten oder ausgeführten Dateien. ## 1. Ein genaues PRD genehmigen Gib Claude Code den tatsächlich genehmigten Funktionsauftrag und lasse offene Fragen vor dem Entwurf von `docs/feature-prd.md` ermitteln. Das Dokument benötigt Auftraggeber und genehmigenden Verantwortlichen, Eingangsrevision, Problem und Zielnutzer, Umfang und Ausschlüsse, nummerierte Anforderungs-IDs, Abnahmeprüfungen mit Belegquellen, nichtfunktionale Einschränkungen, Jira-Projekt und offene Fragen. Eine verantwortliche Person vergleicht den Entwurf mit dem ursprünglichen Auftrag und genehmigt eine genaue Inhaltsrevision samt Hash. Kläre wesentliche Fragen, bevor du Vorgänge anlegst oder Code bearbeitest. Der Hash gibt späteren Aufzeichnungen eine genaue Quelle. Ändert sich das PRD, prüfe den betroffenen Vorgangsplan und die Kontrollen erneut; eine fehlgeschlagene Umsetzung rechtfertigt nicht, Abnahmekriterien so umzuschreiben, dass sie bestanden werden. ## 2. Jira-Hierarchie und Felder dieses Projekts ermitteln Mit autorisierten **rein lesenden** Jira-REST-API-v3-Anfragen blätterst du durch `GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes`. Blättere für jeden geplanten Vorgangstyp durch `GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId}`, um Pflichtfelder beim Anlegen und erlaubte Werte zu finden. Atlassian kennzeichnet die breit gefasste Operation `GET /issue/createmeta` in seiner [Vorgangs-API-Referenz](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) als veraltet. Bestätige für dieses Projekt einen echten übergeordneten Vorgang entsprechend einem Epic, untergeordnete Story-Vorgänge und unterstützte Unteraufgaben. Atlassian beschreibt [die Standardhierarchie und ihre Konfiguration](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/); Typnamen und IDs gelten nicht universell. Prüfe, wie das Projektfeld Parent auf jeder untergeordneten Ebene funktioniert und welche benutzerdefinierten Felder oder Sichtbarkeitseinstellungen das Anlegen erfordert. Kann das Projekt die genehmigte Struktur nicht darstellen, erfasse den fehlenden Typ, das Feld oder die Berechtigung und halte das Anlegen an. Eine allgemeine Vorgangsverknüpfung erzeugt keine Eltern-Kind-Beziehung. ## 3. Vor Schreibzugriffen den gesamten Vorgangsplan prüfen Ordne jede PRD-Anforderung und Abnahmeprüfung in `ticket-plan.json` zu. Erfasse dessen `planVersion`, den PRD-Hash, Jira-Site und Projektschlüssel, eine lokale Ausführungs-ID sowie Planfreigebenden und Zeitpunkt. Erfasse für jeden geplanten Vorgang eine eindeutige lokale ID, die vorgesehene lokale Eltern-ID, ermittelten Vorgangstyp-ID, Projektpflichtfelder, Zusammenfassung, Beschreibung, Anforderungs- und Abnahme-IDs, Verantwortlichen und erlaubte Sichtbarkeit. Die genehmigte Arbeit bestimmt die Zahl der Storys und Unteraufgaben. Jede Unteraufgabe muss echte Arbeit unter ihrer tatsächlichen Story leisten. Jira REST v3 verwendet **Atlassian Document Format (ADF)**, ein strukturiertes JSON-Dokument, für mehrzeilige Vorgangsbeschreibungen und Kommentare. Bereite diese Dokumente aus genehmigten Inhalten vor und prüfe die von der Site gelieferten Feldmetadaten, bevor du jede Anfrage erstellst. Die [Vorgangs-API](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) dokumentiert das Anlegen, kann aber kein fertiges Feldobjekt für ein unbekanntes Projekt liefern. Ein Mensch muss die vollständige Struktur, Abdeckung aller Anforderungen, Elternbeziehungen und das genaue Schreibziel vor jedem `POST` genehmigen. ## 4. Zuerst Elternvorgänge anlegen und jeden Vorgang zurücklesen Lege den genehmigten Elternvorgang über `POST /rest/api/3/issue` an, danach seine Storys und anschließend jede echte Unteraufgabe. Ergänze vor **jeder** Anfrage eine private Protokollzeile mit Ausführungs-ID, lokaler Vorgangs-ID, gegebenenfalls bestätigtem Elternschlüssel, Ziel, Hash der genauen genehmigten Anfrage, UTC-Versuchszeit und dem Zustand `pending`. Füge kein Token hinzu. Bei HTTP 201 notierst du die zurückgegebene Jira-Vorgangs-ID und den Schlüssel und rufst danach direkt `GET /rest/api/3/issue/{issueIdOrKey}` auf. Vergleiche Projekt, Typ, Zusammenfassung, Beschreibung oder PRD-Verweis und Elternvorgang mit dem genehmigten Plan. Markiere die Zeile erst nach diesem Zurücklesen als `confirmed`. Erst ein bestätigter Elternvorgang gibt seine Kinder frei. Bei Zeitüberschreitung oder verlorener Antwort markierst du den Vorgang als `unknown`. Untersuche Jira anhand von Projekt, Zeit, genehmigter Zusammenfassung und Planverweis, öffne wahrscheinliche Treffer direkt und lasse den autorisierten Verantwortlichen die Identität klären. [Atlassian warnt vor Verzögerungen bei der Suche nach einem Schreibzugriff](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/). Ein ausbleibender Suchtreffer ist kein Beweis dafür, dass das Anlegen fehlgeschlagen ist. Ausführungs-ID und Protokoll helfen beim Abgleich, bewirken aber keine serverseitige Ablehnung doppelter Anlagen. Wiederhole einen unklaren `POST` niemals blind. Lies die fertige Struktur direkt in `ticket-map.json` ein: jede lokale ID, tatsächliche Jira-ID und Schlüssel, kanonische Vorgangs-URL, Projekt, Typ, Elternschlüssel, PRD- und Abnahme-IDs, Zurücklesezeit und Protokollverweis. Vergleiche **alle** genehmigten Vorgänge und Kriterien mit dem PRD. Stoppe weitere Schreibzugriffe, wenn ein Vorgang fehlt oder falsch untergeordnet ist, und nutze das überprüfte Korrekturverfahren des Projekts. ## 5. Jede genehmigte Story umsetzen und unabhängig prüfen Arbeite die genehmigten Storys in Abhängigkeitsreihenfolge ab. Erfasse je Story Jira-Schlüssel, anfänglichen Git-Commit und Branch oder Worktree, ursprünglichen Abnahmebefehl sowie erlaubte Pfade und Befehle. Bitte Claude Code, mit [Plan mode](https://code.claude.com/docs/en/common-workflows) die Kriterien dieser Story dem Repository zuzuordnen. Ein Entwickler prüft den Plan und erlaubt eine begrenzte Bearbeitung. Die Story-Grenze hält die Änderung prüfbar; sie entfernt nicht die übrigen genehmigten Storys aus der Funktion. Bewahre nach der Bearbeitung den genauen Diff, ursprünglichen Prüfbefehl mit vollständiger Ausgabe und Exit-Status, relevante gezielte Tests und ein Urteil je Anforderungs-ID auf. Untersuche den tatsächlichen Code und die Protokolle. Ein schriftlicher Plan, erzeugte Dateien oder Claudes Aussage über bestandene Tests belegen keine funktionierende Änderung. Halte die Story bei fehlgeschlagener Prüfung, unerwartetem Geheimnis, Abhängigkeitsänderung, externem Schreibzugriff oder breitem Refactoring an; repariere im genehmigten Umfang und wiederhole die ursprüngliche Prüfung. Ein separater Codeprüfer entscheidet, ob der entstandene Commit akzeptiert oder der Diff zurückgehalten wird. Erfasse diese Entscheidung für jede Story. [Unser früherer Leitfaden zu einer geprüften Änderung mit Claude Code](https://bigchange.ai/blog/superpowers-claude-code-plan-test-review-change-guide) behandelt die engere Codeprüfungsphase; PRD und vollständige Jira-Struktur definieren hier die umfassendere Funktionsgrenze. ## 6. Autorisierte Jira-Aktualisierungen verifizieren Lies für jede geprüfte Story den aktuellen Jira-Status und fordere `GET /rest/api/3/issue/{key}/transitions?expand=transitions.fields` an. Prüfe den diesem Nutzer tatsächlich verfügbaren Übergang, sein Ziel, Pflichtfelder und erlaubte Werte. Ein autorisierter Verantwortlicher kann den ausgewählten Übergang dann über `POST /rest/api/3/issue/{key}/transitions` mit den für das Projekt ermittelten Feldwerten absenden. Lies den Vorgang erneut direkt und bestätige den neuen Status. Eine bestandene Codeprüfung autorisiert allein weder Done noch Zusammenführung oder Bereitstellung. Erfasse im Jira-Aktualisierungsprotokoll Status vor dem Schreiben, vorgesehenen Übergang, handelnden Nutzer, Anfrage und Antwort. Veröffentliche über `POST /rest/api/3/issue/{key}/comment` einen sachlichen ADF-Nachweiskommentar mit akzeptiertem Commit oder zurückgehaltenem Diff, ursprünglicher Prüfung und gezielten Tests, verbleibenden Fehlern und Prüferentscheidung. Lies ID und Text des angelegten Kommentars aus Jiras [Kommentar-API](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) zurück. Ist eine Schreibantwort unklar, prüfe Status oder Kommentare direkt, bevor du eine weitere Anfrage erwägst. Eine leere Übergangsliste oder ein nicht verfügbares Pflichtfeld ist eine mit dem Projektverantwortlichen zu klärende Workflow- oder Berechtigungslücke, keine Einladung, eine ID zu erfinden. ## 7. Entscheiden, ob `CLAUDE.md` geändert werden soll Vergleiche die tatsächlichen PRD-, Vorgangs-, Diff-, Test-, Prüf- und Jira-Aufzeichnungen. Bitte Claude um einen kurzen Rückblick auf beobachtete Missverständnisse oder fehlende Kontrollen. Ein Mensch wählt eine genaue Anweisungsänderung oder dokumentiert mit Prüfer und Zeitpunkt die Entscheidung gegen eine Änderung. Bei Genehmigung prüfst und committest du nur diesen `CLAUDE.md`-Diff samt Hash. [Anthropics Speicherleitfaden](https://code.claude.com/docs/en/memory) beschreibt Projektanweisungen; diese Prüfung genehmigt künftige Arbeit nicht automatisch. Füge keine Geheimnisse hinzu und mache eine spekulative Erkenntnis nicht zur Projektregel. ## Abschluss und Wiederherstellung Die Funktion ist erst abgeschlossen, wenn die genehmigte PRD-Revision der direkt bestätigten Epic-/Story-/Unteraufgabenstruktur entspricht; **jede genehmigte Story** ihren Anfangszustand, akzeptierten Diff, Belege der ursprünglichen Prüfung und gezielter Tests sowie eine unabhängige Prüfung hat; jeder autorisierte Jira-Übergang und Nachweiskommentar direkt zurückgelesen wurde; und ein Mensch über den Rückblick entschieden hat. Erfasse bei fehlenden Punkten die genaue verbleibende Phase. [Die Auswahl einer ersten KI-Aufgabe](https://bigchange.ai/blog/map-work-choose-first-ai-task-guide) endet früher, bei Aufgabenauswahl und vorgeschlagener Prüfung; sie belegt dieses Umsetzungsergebnis nicht. Ein unklarer Jira-Anlegeversuch bleibt `unknown`, bis ein Mensch seine Identität abgeglichen hat. Ein falscher Elternvorgang stoppt das Anlegen von Kindern. Fehlgeschlagene Tests behalten ihre ursprünglichen Kriterien. Ein fehlender Übergang oder erschöpftes Nutzungslimit hinterlässt einen datierten Teilnachweis für den Verantwortlichen. Beschränke Anforderungen und Kundendaten auf das für Claude und Jira genehmigte Minimum, prüfe aktuelle Kontokosten und Berechtigungen und plane menschliche Codeprüfung ein. Dieser Leitfaden beschreibt einen bedingten Weg durch die Werkzeuge; er berichtet keine durch BIG CHANGE abgeschlossene Funktion, Jira-Schreiboperation, Modellausführung, gemessene Einsparung, Zusammenführung oder Bereitstellung. ## Quellen und weiterführende Informationen - [Atlassian: Jira Cloud REST API v3, Vorgangsoperationen](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/): eingegrenzte Anlegemetadaten, Anlegen und Lesen von Vorgängen sowie Übergangsoperationen. Felder und IDs des Leserprojekts müssen dort ermittelt werden. - [Atlassian: Vorgangskommentare](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/): Anlegen und Zurücklesen von ADF-Kommentaren. Berechtigungen und tatsächliche Antwort bleiben abhängig von der Site. - [Atlassian: Suche und Abgleich](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/): erklärt, warum ein fehlender Suchtreffer direkt nach einem Schreibzugriff einen unklaren Anlegevorgang nicht klärt. - [Atlassian: Vorgangstyp-Hierarchie](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/): Standardebenen und Konfiguration; die Struktur des gewählten Projekts muss weiterhin geprüft werden. - [Anthropic: Arbeitsabläufe mit Claude Code](https://code.claude.com/docs/en/common-workflows), [Berechtigungen](https://code.claude.com/docs/en/permissions), [Speicher](https://code.claude.com/docs/en/memory) und [Kosten](https://code.claude.com/docs/en/costs): Planung, Bearbeitungsbefugnis, `CLAUDE.md`-Anweisungen und Nutzung. Sie dokumentieren keine Ausführung dieser Funktion. ## Sources - [Atlassian Jira Cloud REST API v3, Vorgänge](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) — Dokumentiert eingegrenzte Anlegemetadaten, Vorgangs-POST/GET und Übergänge; umfassende Anlegemetadaten sind veraltet. Projektfelder, IDs und erlaubte Übergänge müssen aus der Site des Lesers stammen. - [Atlassian Jira Cloud REST API v3, Vorgangskommentare](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) — Dokumentiert Anlegen und Zurücklesen von ADF-Kommentaren unter tatsächlichen Berechtigungen. Für diesen Leitfaden wurde kein Kommentar veröffentlicht. - [Atlassian: Suche und Abgleich](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/) — Erklärt die verzögerte Konsistenz der Suche; ein fehlender Treffer kann nach unklarer Anlegeantwort nicht beweisen, dass kein Vorgang existiert. - [Atlassian: Vorgangstyp-Hierarchie konfigurieren](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/) — Erklärt Standardhierarchie und Konfigurationsmöglichkeiten. Ebenen und Parent-Verhalten des gewählten Projekts müssen direkt ermittelt werden. - [Atlassian: Basisauthentifizierung für REST-APIs](https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis/) — Beschreibt E-Mail plus API-Token für ein einfaches privates Skript und Unterschiede zu Integrationen; Zugangsdaten müssen privat bleiben. - [Anthropic Claude Code: häufige Arbeitsabläufe](https://code.claude.com/docs/en/common-workflows) — Dokumentiert Plan mode und Programmierabläufe; dies beweist weder Umsetzung noch Prüfungen eines Lesers. - [Anthropic Claude Code: Berechtigungen](https://code.claude.com/docs/en/permissions) — Dokumentiert wirksame Werkzeugberechtigungen und Genehmigungen; CLAUDE.md-Anweisungen allein autorisieren keine Befehle oder Schreibzugriffe. - [Anthropic Claude Code: Speicher](https://code.claude.com/docs/en/memory) — Erklärt CLAUDE.md-Projektanweisungen; die vorgeschlagene Änderung aus dem Rückblick benötigt menschliche Prüfung und ist kein automatisches Lernen. - [Anthropic Claude Code: Kosten](https://code.claude.com/docs/en/costs) — Nutzung und Abrechnung hängen von Tarif und Anbieter ab; dieser ausschließlich dokumentationsbasierte Leitfaden misst weder Gebühren noch Einsparungen.