القائمة
Use when starting autonomous end-to-end work on a GitHub issue — from first analysis to a merge-ready pull request, without interrupting the user.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | forgecrate-issue-resolver |
| description | Use when starting autonomous end-to-end work on a GitHub issue — from first analysis to a merge-ready pull request, without interrupting the user. |
Autonomer Senior-Entwickler-Workflow: Issue $ARGUMENTS end-to-end bearbeiten — von Analyse bis Merge-Ready-PR — ohne Rückfragen.
Superpowers-Skills sind verpflichtende Workflows, keine Vorschläge. Fortschritt wird als Issue-Kommentare dokumentiert.
$ARGUMENTS)Alle optional, frei kombinierbar:
42) — Standard-Modus, ein Issuecount:N — N Issues parallel bearbeiten (Default 1, Maximum 5); Auto-Auswahl der nächsten offenen Issues nach Prioritätlabel:<name> — nur Issues mit diesem Label berücksichtigen12 15 18) — diese Issues parallel bearbeitenBei count > 1 oder mehreren Issue-Nummern:
isolation: "worktree" + run_in_background: true dispatchenforgecrate-research)Vor der Issue-Analyse: forgecrate-research aufrufen.
Thema: betroffene Technologie, Muster oder API aus dem Issue-Kontext.
Research-Block im Issue-Kommentar 🔍 Research dokumentieren.
using-superpowers)Issue als Assignee beanspruchen, Status auf „in progress" setzen. Issue vollständig lesen: Body, Labels, Sub-Issues, Kommentare, Querverweise. Betroffene Codepfade analysieren (git log, git blame, Tests, Patterns).
brainstorming)Mindestens 2–3 grundlegend verschiedene Lösungsansätze entwickeln. Für jeden: Kurzbeschreibung, Trade-offs (Komplexität, Performance, Wartbarkeit, Risiko), Aufwand (S/M/L).
→ Issue-Kommentar 🧠 Brainstorming mit Optionen, Trade-offs, finalem Design.
writing-plans)Besten Ansatz wählen. Plan mit 2–5-Minuten-Tasks erstellen: exakte Datei-/Funktionspfade, Code-Stubs, Verifikationsschritte.
Teststrategie als eigener Abschnitt:
Branch-Name: <type>/<issue-id>-<kurz> — Conventional Commits mit Issue-Referenz.
→ Issue-Kommentar 📋 Plan mit Ansatz, Schritten, Teststrategie, Coverage-Ziel, Akzeptanzkriterien.
using-git-worktrees)Isolierten Worktree auf neuem Branch anlegen. Projekt-Setup ausführen. Test-Baseline (alle Tests grün) verifizieren — vor jeder Änderung.
Multiagent: Parallelisierung und Subagenten proaktiv einsetzen.
run_in_background: trueisolation: "worktree"subagent-driven-development oder executing-plans)Plan strikt umsetzen. Atomare Commits, finaler Commit mit closes #<issue>. Linting/Formatting/Type-Checks einhalten.
Bei unerwarteten Fehlern: systematic-debugging (vierphasige Root-Cause-Analyse). Intern replanen, im Issue dokumentieren — nicht den User fragen.
test-driven-development)Strikt RED-GREEN-REFACTOR. Code vor Test = löschen und neu anfangen.
sleep, keine Reihenfolge-Kopplung, deterministische Fixturesverification-before-completion, requesting-code-review)Linter, Formatter, Type-Checks, vollständige Test-Suite lokal grün. Coverage-Report mit Vorher/Nachher. Self-Review entlang der Review-Kategorien (Code Quality, Architecture, Security, Performance, Error Handling, Tests). Nur Evidenz zählt, keine Behauptungen — Logs und Coverage-Zahlen müssen vorliegen.
finishing-a-development-branch)PR-Titel: <type>(<scope>): <beschreibung> (#<issue>). PR-Body: Zusammenfassung, Issue-Link, Akzeptanzkriterien abgehakt, Test-Evidenz (Logs, Coverage-Vergleich). Labels und Reviewer setzen. Issue-Status auf „in review". Worktree aufräumen.
→ Issue-Kommentar ✅ Umsetzung mit Branch, PR-Nummer, Änderungen pro Datei, Validierungsergebnissen, neuen Tests (Regressionstest namentlich), Coverage-Vergleich.
| Schritt | Skill |
|---|---|
| 0 Research | forgecrate-research |
| 1 Verstehen | using-superpowers |
| 2 Brainstormen | brainstorming |
| 3 Planen | writing-plans |
| 4 Worktree | using-git-worktrees |
| 5 Umsetzen | subagent-driven-development, systematic-debugging |
| 6 Tests | test-driven-development |
| 7 Validieren | verification-before-completion, requesting-code-review |
| 8 Ausliefern | finishing-a-development-branch |
Alle technischen Entscheidungen selbst treffen: Naming, Bibliothekswahl, Commit-Aufteilung, kleinere Refactorings. Wesentliche Entscheidungen im Issue-Kommentar dokumentieren.
Nur in diesen 5 Fällen den User fragen — mit genau einer präzisen Frage und Optionen A/B/C:
verification-before-completion durch istPFLICHT nach jedem abgeschlossenen Brainstorming. Bewertet das Ergebnis mit WSJF-Score und K.O.-Kriterien. Entscheidet: "Umsetzbar jetzt" (→ writing-plans) oder "Future Feature" (→ GitHub Issue anlegen). UNBEDINGT nutzen, sobald eine neue Idee, ein Bug, eine Erweiterung oder ein Feature-Wunsch erwähnt wird, oder Fragen wie "ist das wichtig?", "gehört das auf die Roadmap?", "Bugfix oder Feature?", "was als nächstes?", "Release planen", "Backlog aufräumen" gestellt werden — auch wenn der Skill nicht ausdrücklich genannt wird.
PFLICHT vor jeder nicht-trivialen Änderung. Recherchiert aktuelle Doku, Best Practices oder spezifische Quellen und gibt einen strukturierten Research-Block aus, den folgende Skills referenzieren können. UNBEDINGT aufrufen bevor Code geschrieben oder geändert wird.