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. 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 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 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 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; 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 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. 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 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 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 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 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 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