jackleh/claude-skills

Starte Arbeitselement

Wandelt ein eingefügtes ADO-Ticket um in: einen neuen (oder korrekt fortgesetzten) Branch, einen Kontext-Speicher, den spätere Sitzungen fortsetzen können, eine fundierte Codebase-Erkundung und entweder eine Ursachenanalyse oder ein Feature-Layout. Es endet an einem Checkpoint — präsentiere die Ergebnisse und warte. Kein Fix- oder Feature-Code wird in dieser Fähigkeit geschrieben; der Benutzer genehmigt zuerst die Richtung, denn eine falsche RCA, die schnell ausgeliefert wird, kostet einen vollständigen QA-Durchlauf.

0. Lade die lokale Konfiguration

Lies zuerst config.local.md in diesem Skill-Ordner — bevor du das Ticket parst. Sie enthält die Begriffe, die dieser Skill bewusst nicht fest codiert: Branch-Präfix, Basis-Branch, das Layering-Dokument des Projekts, wo Untersuchungen gespeichert werden, blinde Flecken des Code-Index und vergangene Speicher, auf die es sich lohnt hinzuweisen. Die Qualität der Erkundung hängt von diesen Angaben ab, also überspringe sie nicht.

Wenn sie fehlt (Neuinstallation), schließe, was du kannst — Basis-Branch aus git remote show origin (HEAD-Branch), Präfix aus den vorhandenen Branches des Benutzers (git branch --list "*/*") — teile dem Benutzer mit, was du geschlossen hast, und biete an, es als config.local.md zu speichern (siehe config.example.md).

Das Speicherverzeichnis ist das, das dein System-Prompt für dieses Projekt benennt; das Repository ist das, in dem du arbeitest. Beides benötigt keine Konfiguration.

1. Parse das Ticket

Extrahiere, was immer eingefügt wurde. ADOs Seiten-Kopieren-und-Einfügen ist verrauscht: die erste Zeile ist der Typ und die ID in Großbuchstaben (USER STORY 12345, BUG 12346), jedes Feld-Label steht in einer eigenen Zeile mit dem Wert in der nächsten (State / Dev In Progress), Tags erscheinen als nackte Zeilen oben, und es gibt UI-Chrome, das ignoriert werden sollte (Save, Follow, Click to add …, switch to HTML editor, leere TestRail-Abschnitte). Bilder und Anhänge überleben das Einfügen nicht.

• ID (Zahl) und Arbeitselement-Typ — Bug vs. User Story / Feature / PBI / Task. Wenn der Typ nicht angegeben ist, schließe ihn (Repro-Schritte + Erwartet/Ist ⇒ Bug; „Als … möchte ich“ oder Abnahmekriterien ⇒ Feature) und sage, was du geschlossen hast.
• Titel, Status, Bereich/Iteration falls vorhanden
• Bug: Repro-Schritte, erwartetes vs. tatsächliches Verhalten, Build-Nummer, Plattform/Gerät/Betriebssystem, Deep-Links, Namen angehängter Logs, erwähnte Screenshots
• Feature: Beschreibung, Abnahmekriterien, verlinkte Designs, Feature-Flag/Experiment-Namen
• Diskussion/Kommentare: frühere Versuche, QA-Notizen und deren Daten, PR-Nummern

Wenn es keine ID gibt, frage danach, bevor du etwas erstellst — die ID steuert die Branch- und Speicher-Namen. Notiere alles, was referenziert, aber nicht sichtbar ist (Screenshots, Logs), damit du am Checkpoint danach fragen kannst, anstatt über den Inhalt zu raten.

2. Branch

Führe git in dem Repository aus, in dem du arbeitest (wenn die Sitzung in einem Worktree oder einem anderen Klon ist, verwende diesen — wechsle niemals mit cd von ihm weg):

git status --porcelain

Wenn der Baum nicht sauber ist, halte an. Liste die Dateien und den aktuellen Branch auf und frage, wie weiter verfahren werden soll (übernehmen, stashen oder auf dem alten Branch committen). Nicht committete Dateien aus einem Element gelangen in die Commits des nächsten; der Benutzer entscheidet das, nicht du.

Wenn sauber:

git fetch origin
git branch --list "<prefix>/<id>*"; git branch -r --list "origin/<prefix>/<id>*"

Wenn kein Branch für die ID existiert, erstelle <prefix>/<id> von origin/<base> aus und zeichne die kurze SHA auf (git rev-parse --short HEAD).

Wenn <prefix>/<id> oder <prefix>/<id>-N bereits existiert (lokal oder remote), schaue dir den neuesten an, bevor du entscheidest — dieselbe ID kann zu drei sehr unterschiedlichen Zeitpunkten eintreffen:

git log --oneline origin/<base>..<prefix>/<id>[-N]   # Unzusammengeführte Commits?
git log --oneline origin/<base> --grep=<id>           # "Merged PR NNNN: ... <id>" = zusammengeführt

ADO führt mit Squash-Merge zusammen, daher zeigt ein zusammengeführter Branch seine Commits immer noch als „voraus“ zum Basis-Branch — die Merged PR-Zeile auf dem Basis-Branch sagt dir, dass er zusammengeführt wurde. Lies sie zusammen mit dem Status des Tickets und dem Datum des neuesten QA-Kommentars im Vergleich zum letzten Commit des Branchs.

Neuester vorhandener Branch	Typischer Ticketstatus	Was zu tun ist
Keine Commits über origin/<base> hinaus (oft der Branch, auf dem du bist — der Benutzer hat ihn vor dem Einfügen erstellt)	Neu / Dev In Progress	Wiederverwenden. Checke ihn aus, git merge --ff-only origin/<base>.
Zusammengeführt (ein Merged PR für diese ID auf dem Basis-Branch) und QA hat es seitdem als fehlgeschlagen markiert	Aktiv / wiedereröffnet, fehlgeschlagener QA-Kommentar neuer als der Merge	Nächstes Suffix erstellen (-1, -2, …) von origin/<base>; der vorherige Versuch wird zum primären Erkundungsmaterial.
Nicht zusammengeführte Commits (gepusht oder nicht), oder ein noch offener PR	PR Review / Fertig zum Testen / In Bearbeitung	In Bearbeitung — keinen Branch erstellen. Berichte, was darauf ist (Commits, ob gepusht, wie weit hinter dem Basis-Branch es ist), mache es zum Gegenstand der Erkundung und frage, ob fortgesetzt oder ein neuer Versuch gestartet werden soll.

Wenn die Signale widersprüchlich sind (z. B. Status sagt Neu, aber es gibt einen nicht zusammengeführten Branch), behandle es als in Bearbeitung und frage — einen doppelten Branch zu erstellen, ist der teure Fehler. Wenn git fetch fehlschlägt (VPN / Authentifizierung), sage das und verwende den lokalen origin/<base>, und weise darauf hin, dass der Basis-Branch veraltet sein könnte.

Push nicht und committe nicht — der Benutzer hat nicht darum gebeten.

3. Kontext-Speicher (jetzt schreiben, später aktualisieren)

Schreibe den Speicher vor der Erkundung, mit Status ⏳, damit das Element auch dann fortsetzbar ist, wenn die Sitzung mitten in der Untersuchung stirbt. Verwende references/memory-template.md.

• Bug → bug-<id>-context.md, Feature/Story/Task → feature-<id>-context.md
• Wenn für diese ID bereits einer existiert, aktualisiere ihn anstatt einen zweiten zu erstellen — und korrigiere alles darin, was der Git-Status jetzt widerspricht.
• Füge einen einzeiligen Verweis in MEMORY.md hinzu. Ohne diesen finden spätere Sitzungen den Speicher nie.

4. Codebase-Erkundung

Das Ziel ist es, die tatsächlichen Codepfade zu finden, die das Ticket berührt, und die Historie darum herum — genug, dass die RCA/das Layout datei:zeile angibt, nicht Vermutungen.

• Verwende den Code-Index, falls vorhanden (CodeGraph, LSP): beginne mit einer Kontextabfrage zu den Substantiven des Tickets (Seite, Steuerelement, Service, DTO), dann ein Explore-Aufruf zu dem, was es an die Oberfläche bringt; Aufrufer/Auswirkungen auf das verdächtige Symbol. Überprüfe die Konfiguration auf blinde Flecken des Index (Dateitypen, die er nicht parst) und grep diese stattdessen.
• Routen und UI-Namen: Seitenrouten, Komponentennamen, CSS-Klassen und Deep-Link-Schemata aus dem Ticket sind gute Grep-Begriffe.
• Vorherige Arbeit: git log --oneline --all --grep=<id>, git log --oneline -20 -- <verdächtige Dateien>, der docs/investigations-Ordner des Projekts (Konfiguration) und das Speicherverzeichnis für Aufzeichnungen zum selben Bereich. Ein früherer Fix für dasselbe Symptom, der QA nicht bestanden hat, ist das Wertvollste, was du finden kannst.
• Vergleiche die bestehenden und fehlschlagenden Fälle. Wenn QA Fälle auflistet, die bestehen, und einen, der fehlschlägt, finde heraus, was tatsächlich zwischen ihnen im Code anders ist — die Host-Seite, der Datenpfad, das Timing — bevor du dich auf einen Mechanismus festlegst.
• Jeder Host/Plattform: Wenn die UI über mehrere Hosts geteilt wird (mobiles Shell, Web), überprüfe, ob das Ticket plattformspezifisch ist und ob der Code es ist.
• Baue nicht während der Erkundung. Code zu lesen reicht hier; Builds sind langsam und gehören zur Implementierung.

Für breite Durchläufe über viele Ordner hinweg ist ein Explore-Subagent in Ordnung; für einen bekannten Bereich erledige es direkt.

5a. Bug → Ursachenanalyse

Verwende die Fähigkeit superpowers:systematic-debugging für die Methode, falls verfügbar. Die Messlatte ist gemessen, nicht geraten: benenne den Mechanismus und die genaue datei:zeile, und erkläre, warum er genau das berichtete Symptom und kein anderes erzeugt (warum der fehlschlagende Fall fehlschlägt und die bestehenden Fälle bestehen).

• Verfolge den Pfad von der Benutzeraktion in den Repro-Schritten bis zum fehlerhaften Zustand. Zitiere die relevanten Zeilen.
• Reproduziere, wo möglich ohne Gerät: Komponententests für Status/Markup, eine headless-Browser-Statik-Replik für Layout/Scroll/CSS-Probleme (die Konfiguration kann auf einen Speicher verweisen, der eine vorhandene Testumgebung beschreibt). Wenn du nicht reproduzieren kannst, sage das klar, gib dein Vertrauen an und welche Beweise es bestätigen würden (z. B. eine bestimmte Log-Zeile oder ein Screenshot von QA).
• Trenne die Ursache von beitragenden Faktoren und von angrenzenden Problemen, die in andere Tickets gehören.
• Schlage eine Fix-Richtung vor (oder 2–3 Optionen mit einer Empfehlung) und den Regressionstest, der es festnageln würde — aber schreibe sie noch nicht.
• In-Bearbeitung-Element (Schritt 2): die RCA wird zu einer Überprüfung des bereits auf dem Branch befindlichen Fixes — adressiert er den neuesten QA-Fehler, und welche Restrisiken würden ihn auf dem Gerät fehlschlagen lassen? Empfehle, ihn fortzusetzen, und sage, welches QA-Ergebnis einen neuen Versuch rechtfertigen würde.

5b. Feature → Layout und Ausarbeitung

Verwende die Fähigkeit superpowers:brainstorming für das Design-Gespräch, falls verfügbar.

Beurteile zuerst, ob die Abnahmekriterien ausreichend sind. Sie sind ausreichend, wenn:

• jedes AK in eine konkrete Testbehauptung umgewandelt und einer zu bearbeitenden Datei zugeordnet werden kann, und
• UI-Zustände (Laden, Leer, Fehler, Deaktiviert), plattformspezifisches Verhalten, Analyse-Events und Feature-Flagging entweder spezifiziert oder eindeutig nicht anwendbar sind.

Wenn sie ausreichend sind, stelle keine Fragen um der Fragen willen — lege das Feature dar. Wenn sie nicht ausreichend sind, ist eine Ausarbeitung erforderlich: frage nur nach den Lücken, gebündelt in einem AskUserQuestion (bis zu 4 Fragen, konkrete Optionen, eine empfohlene Standardeinstellung zuerst). Vage AKs, über die geraten wird, verursachen Nacharbeit.

Sortiere jede Lücke vor dem Fragen: Wenn die Antwort das Design ändern würde (was gezeigt wird, woher Daten kommen, was der Benutzer beim Tippen sieht), ist es eine Frage. Wenn es etwas mit einer offensichtlichen Hauskonvention ist — ein Feature-Flag-Schlüssel, ein Analyse-Event-Name, eine DI-Registrierung — wähle den konventionellen Wert, schreibe ihn im Layout als Angenommen:, damit der Benutzer es auf einen Blick korrigieren kann, und frage nicht. Das 4-Fragen-Bündel ist die gesamte Anfrage; kein „auch, bitte bestätigen Sie…“-Anhang danach, denn das sind nur weitere Fragen ohne Optionen.

Das Layout umfasst:

• Dateien zum Hinzufügen/Ändern, platziert gemäß dem Layering des Projekts (die Konfiguration zeigt auf das Dokument, das es definiert), einschließlich DI-Registrierung in jedem Host
• Datenfluss: woher die Daten kommen, welcher Service den Zustand besitzt, wie es die Komponente erreicht
• AK → Testzuordnung, Benennung des Testprojekts für jedes
• Plattformunterschiede, Analysen/Flags, Risiken und offene Fragen

6. Checkpoint

Aktualisiere die Speicherdatei mit dem, was du gefunden hast (Status 🔄, Ursachenanalyse oder Layout-Zusammenfassung, offene Fragen), präsentiere dann dem Benutzer:

Bug:

## Bug <id>: <title>
Branch: <prefix>/<id> (von origin/<base> @ <sha>)   — oder: in Bearbeitung auf <branch>, kein neuer Branch
Speicher: bug-<id>-context.md

### Ursache
<Mechanismus, datei:zeile, warum es zum Symptom passt> — Vertrauen: <hoch/mittel/niedrig + was es erhöhen würde>

### Beweise
<Code-Zitate, Reproduktionsergebnisse, Historie: frühere PRs/Versuche>

### Vorgeschlagener Fix
<Richtung oder Optionen + Empfehlung; Regressionstest zum Hinzufügen; zu bearbeitende Dateien>

### Benötigt von dir
<Fehlende Screenshots/Logs, Entscheidungen>

Feature:

## Feature <id>: <title>
Branch / Speicher: ...

### Was die AKs sagen vs. was fehlt
### Vorgeschlagenes Layout (Dateien, Datenfluss, AK → Tests, jede Plattform, Angenommen: …)
### Fragen  (oder „Keine — AKs sind ausreichend")

Halte dann an und warte auf Genehmigung. Wenn die RCA oder das Layout 5+ Dateien umfasst oder die Architektur ändert, biete an, es im docs/investigations-Ordner des Projekts (Konfiguration) aufzuschreiben — biete an, erstelle nicht automatisch.