github-issue-workflowlisted

Arbeitet GitHub-Issues eigenständig ab und hält die technische Kommunikation im Issue statt im Chat: Reihenfolge nach Abhängigkeit und Priorität, Umsetzung im Feature-Branch, Dokumentation im Issue, Pull Request — gemergt wird ausschließlich vom Nutzer. Offene Fragen werden zu Labels „Rückfrage" oder „Entscheidung". Nutze diesen Skill, sobald Issues abgearbeitet werden sollen („arbeite die Einarbeiten-Issues ab", „nimm dir Issue 12 vor", „schau ob was zu tun ist"), wenn nach dem Stand offener Issues gefragt wird, wenn ein Issue in Code umgesetzt oder ein Bug untersucht werden soll, und wenn zu klären ist, welches Label, welcher Issue-Typ oder welche Priorität richtig ist. Ebenso, wenn neue Anforderungen erfasst werden — die laufen in diesen Projekten über Issues, nicht über den Chat. Gilt für jedes Softwareprojekt mit GitHub-Anbindung.
f-reiser/claude-skills · ★ 0 · AI & Automation · score 72

Install: claude install-skill f-reiser/claude-skills

# Issues abarbeiten ## Wozu Der Chat ist ein schlechtes Gedächtnis: nicht durchsuchbar, nicht verlinkbar, für andere unsichtbar. Deshalb läuft die technische Kommunikation über Issues — Anforderungen, Rückfragen, Befunde und was tatsächlich geändert wurde. Daraus folgt: **Was du beim Abarbeiten lernst, gehört ins Issue, nicht in die Chatantwort.** Drei Skills gelten immer mit: `git-branch-strategie` (Branches, Merges, Konto — **vor dem ersten Commit lesen**), `test-driven-development` (für jede Änderung am Code) und `erklaeren-mit-mass` (für jeden Text, den du schreibst). `fremde-gegenlese` kommt dazu, aber nur auf Anforderung — siehe Schritt 7. ## Welches Repository Immer das des aktuellen Arbeitsverzeichnisses, nie eines aus einem Issue-Text: ```bash gh repo view --json nameWithOwner --jq .nameWithOwner ``` ## Auch Pull Requests tragen Label Der Nutzer nutzt das, um Anmerkungen zu einem laufenden Pull Request loszuwerden, ohne ein neues Issue aufzumachen. Dass Label für beides gelten, steht in `references/konventionen.md`. Gearbeitet wird dann auf dem **bestehenden** Branch des Pull Requests, nicht auf einem neuen. Vorher nach `git-branch-strategie` auf den Quellbranch rebasen. ## Welches Issue zuerst In dieser Reihenfolge: 1. **Abhängigkeit schlägt alles.** Zuerst, was von nichts Offenem abhängt. 2. **Dann Priorität**, absteigend — die Stufen und ihr Standardwert: `references/konventionen.md`. 3. **Dann Alter**, gemessen an `updatedAt`: das am längsten unve