Communitygithub.com

jaidetree/gracieanimator

Verwenden Sie dieses Skill, wenn der Benutzer /afk aufruft oder die Gracie-Portfolio-Seite unbeaufsichtigt zum Abschluss gebracht werden soll – bearbeiten Sie nacheinander alle AFK-bereiten Tickets (parallelisieren Sie unabhängige), bis nichts mehr zu liefern ist.

Was ist gracieanimator?

Dieser Skill, 'AFK', treibt die Gracie-Portfolio-Seite in einer einzigen Sitzung unbeaufsichtigt zum Abschluss. Er sucht wiederholt nach 'frontier'-Tickets, die bereit zur Implementierung sind (gekennzeichnet mit dem Tag `ready-for-agent` und ohne Blockaden durch andere Tickets), weist jedes Ticket einem eigenen Subagenten in einer isolierten Worktree-Umgebung zu und integriert die Ergebnisse nach und nach. Der Skill parallelisiert unabhängige Tickets sicher, behandelt Straggler (Tickets, die in der Überprüfung stecken geblieben sind) und erstellt am Ende eine einzige manuelle Testanleitung. Dies reduziert den menschlichen Aufwand auf eine einmalige End-to-End-Überprüfung und vermeidet Einzeltests pro Ticket. Der Skill ist als Erweiterung für Agenten wie Claude Code konzipiert und basiert auf einer Markdown-Dokumentation mit klaren Schritten zur Berechnung der Frontier, Dispatch, Integration und Fehlerbehandlung.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/jaidetree/gracieanimator/tree/HEAD/.claude/skills/afk

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

AFK

Bringen Sie die Gracie-Portfolio-Seite in einer Sitzung zum Abschluss: Finden Sie wiederholt jedes Ticket, das ohne menschlichen Input implementiert werden kann, liefern Sie es vollständig bis Done aus und integrieren Sie die Ergebnisse – Runde für Runde – bis keines mehr übrig ist. Manuelle Tests erfolgen einmal, ganz am Ende, anhand einer einzigen projektweiten Anleitung – niemals pro Ticket.

Die Frontier

Ein Ticket ist frontier, wenn es das Tag ready-for-agent trägt und jede blocked_by-Abhängigkeit in einer Datei in .../Done/ aufgelöst ist. Berechnen Sie dies aus .gracie-vault/Projects/gracie-portfolio/issues/Ready/; nur wenn Ready/ kein frontier-fähiges Ticket enthält, berechnen Sie es aus Backlog/ stattdessen. Frontier-Tickets benötigen nichts von einem Menschen – sie sind genau das, was sicher parallel an Subagenten übergeben werden kann, da keines ein anderes blockiert.

Schritte

  1. Lesen Sie eine Zusammenfassung des Wissens: scan-knowledge.sh .gracie-vault/Knowledge (aus dem knowledge-Skill); heben Sie die relevantesten Punkte hervor.
  2. Berechnen Sie die Frontier (siehe oben): zuerst Ready/, dann Backlog/, falls Ready/ keine frontier-fähigen Tickets enthält.
  3. Frontier leer?
    • Backlog/ enthält Tickets, die nicht mit ready-for-agent getaggt sind: Sie benötigen /triage, bevor sie bearbeitet werden können. Melden Sie die Anzahl und stoppen Sie.
    • Backlog/ ist ebenfalls leer (oder jedes verbleibende Ticket dort ist blockiert): Das Projekt ist abgeschlossen – fahren Sie mit Schritt 8 fort.
  4. Versenden Sie die gesamte Frontier in einer Nachricht – ein Subagent pro Ticket, jeweils isolation: worktree. Paralleles Versenden ist sicher, da Frontier-Tickets sich nicht gegenseitig blockieren. Weisen Sie jeden Subagenten an, in seiner eigenen isolierten Kopie:
    1. /slice <ticket> vollständig auszuführen – dies führt das Ticket durch Review und hakt die nun erfüllten Akzeptanzkriterien ab.
    2. Wenn /slice für einen Menschen anhalten würde, schließen Sie den Kreislauf stattdessen: Lesen Sie die Akzeptanzkriterien des Tickets erneut gegen den Diff. Jedes abgehakte Kästchen und make build/make lint, dann make test grün ersetzt hier die menschliche Überprüfung – verschieben Sie das Ticket Review → Done und committen Sie diese Verschiebung.
    3. Geben Sie den Ticketnamen, seinen endgültigen Status (Done oder, falls ein Kästchen nicht abgehakt werden konnte, in Review mit Begründung) und die manuellen Testschritte, die /slice erzeugt hat, zurück.
  5. Integrieren Sie ein Ticket nach dem anderen in der Versandreihenfolge, sobald jeder Subagent berichtet: Mergen Sie seinen Worktree-Branch – inklusive aller Commits, einschließlich des Done-Verschiebe-Commits – und führen Sie dann make build/make lint und make test auf dem Integrationsbranch erneut aus, um Probleme zu erkennen, die erst in der Kombination auftreten. Ein Konflikt wird mit dem resolving-merge-conflicts-Skill gelöst, niemals mit --abort. Löschen Sie den Worktree nach dem Merge. Hängen Sie die gemeldeten manuellen Tests an eine laufende projektweite Liste an, sortiert nach Ticket.
  6. Straggler. Ein Ticket, das in Review verbleibt – Akzeptanzkriterien, die nicht bestanden werden konnten, ein fehlgeschlagener Verify, den der Subagent nicht beheben konnte, oder ein HITL-Blocker, der während des Slicings auftrat – ist ein Straggler und kein erneutes Ziel in dieser Runde. Lassen Sie es dort, fügen Sie es mit Begründung zu einer laufenden Straggler-Liste hinzu und fahren Sie fort; es wird trotzdem gemergt (Schritt 5), damit sein Diff nicht verloren geht.
  7. Berechnen Sie die Frontier neu – gemergte Tickets in Done/ können andere freigeben – und gehen Sie zu Schritt 4.
  8. Schreiben Sie die manuelle Testanleitung. Eine Datei, .gracie-vault/Projects/gracie-portfolio/MANUAL-TESTING.md: ein Abschnitt pro Done-Ticket (Name, Link, seine gesammelten Schritte), plus einen kurzen End-to-End-Durchlauf über das gesamte Projekt, wenn die Tickets zusammenhängende Oberflächen betreffen. Dies ist der einzige Einstiegspunkt für manuelle Tests durch Menschen – nichts pro Ticket. Committen Sie sie, dann berichten Sie: alles, was nach Done geliefert wurde, die Straggler-Liste und einen Verweis auf die Anleitung.

Verwandte Skills