FlintSH/delivery

Was macht delivery?

Der Benutzer gibt das Ziel und die Randbedingungen vor und erwartet ein fertiges, verifiziertes Ergebnis ohne Beaufsichtigung. Aktuelle Anweisungen und Repository-Regeln haben Vorrang vor allem unten Stehenden. Die globalen Anweisungen des Benutzers können persönliche Besonderheiten enthalten (Maschinenlimits, Produkte, Review-Bots, Stimme); befolge sie.

Aufgabe festlegen

1. Lies die AGENTS.md/CLAUDE.md des Repositorys, die relevante Architektur, Paketmanifeste und die Lockfile sowie den aktuellen Git-Status. Untersuche den tatsächlichen Branch, die Basis, das Issue und etwaige vorhandene Arbeitskopien des Tasks, bevor du Änderungen vornimmst.
2. Identifiziere beobachtbare Akzeptanzkriterien: Verhalten, Konfiguration, Kompatibilität, UI-Verfeinerung, Testergebnisse und die angeforderte Auslieferungsmethode. Triff vernünftige reversible Entscheidungen; frage nur bei folgenschwerer Mehrdeutigkeit.
3. Wesentliche, nicht zusammenhängende Aufgaben benötigen isolierte Git-Arbeitskopien. Verwende eine Arbeitskopie, die die Infrastruktur bereits für diese Aufgabe erstellt hat. Wechsle nicht und setze ein gemeinsames Checkout nicht zurück. Wenn mehrere Agenten absichtlich eine Arbeitskopie teilen, einigt euch auf Dateibesitz und einen Git-Schreiber. Frühere Anfragen, auf main zu pushen, autorisieren keine neuen Pushs.

Implementieren und verifizieren

• Bewahre die Identität des Produkts. Verfeinere vorhandene Oberflächen, anstatt sie neu zu entwerfen, es sei denn, die Aufgabe verlangt einen Neudesign.
• Überprüfe die installierten Framework- und API-Versionen, bevor du neue APIs verwendest. Konsultiere die aktuellen offiziellen Dokumentationen oder Context7 (falls installiert) für unbekannte oder versionsabhängige Verhaltensweisen.
• Überprüfe bei Plattformzielen (Spielserver, Mobile-OS-Versionen, Browser-Engines, Laufzeitumgebungen) die Kompatibilität mit dem tatsächlichen Ziel des Builds und der offiziellen API. Teste niemals an der Produktion als Ersatz für eine Entwicklungsinstanz.
• Verwende bevorzugt die Test- und Build-Befehle des Repositorys. Füge sinnvolle Regressionsabdeckung für Verhaltensänderungen hinzu und teste anschließend betroffene Integrationen. Verwende für UI-Arbeiten visual-qa, ohne daran erinnert zu werden.
• Parallelisiere unabhängige Recherchen und Bearbeitungen, wenn sinnvoll, mit klarer Zuständigkeit. Passe die Parallelität an die Maschine an: Überprüfe CPU und Arbeitsspeicher, bevor du mehr als einen schweren Build oder Render oder mehr als zwei Browser-Sitzungen ausführst. Sammle keine Hintergrundserver an und starte keine überflüssigen Agentenschwärme.

Engineering-Playbooks (pstack)

Dieser Skill bleibt der Router. Wenn Lauren Tans pstack-Plugin installiert ist, verwende dessen Playbooks für die Engineering-Methode innerhalb einer Aufgabe. Die meisten pstack-Skills sind nur manuell ausführbar, lies daher <pstack>/skills/<name>/SKILL.md über den Pfad, anstatt darauf zu warten, dass sie geladen werden. Bevor du einer pstack-Datei folgst, lies den Adapter für deine Infrastruktur einmal pro Sitzung; er bildet Cursor-Werkzeug-, Modell- und Pfadnamen ab.

Löse <pstack> für deine Infrastruktur auf:

• Claude Code: ls -d ~/.claude/plugins/cache/cursor-plugins/pstack/*/ | sort -V | tail -1. Adapter <pstack>/docs/harness/claude-code.md. Modellblatt ~/.claude/rules/pstack-models.md, wird automatisch geladen.
• Codex: ls -d ~/.codex/plugins/cache/tinderbox-pstack/pstack/*/ | sort -V | tail -1. Adapter <pstack>/docs/harness/codex.md. Modellblatt ~/.codex/pstack-models.md; lies es, bevor du ein Rollenmodell startest.

Wenn keiner der Pfade existiert, ist pstack nicht installiert: Arbeite ohne.

Aufgabenform	Lesen und befolgen
Gemeldeter Fehler	skills/poteto-mode/playbooks/bug-fix.md
Gemessene Langsamkeit oder eine zu verbessernde Metrik	perf-issue.md, hillclimb.md
Leck, Blockierung oder Glitch; erfasstes Profil	runtime-forensics.md, trace-forensics.md
Neues Verhalten; reine Strukturänderung	feature.md, refactoring.md
Empirischer Design-Fork	prototype.md anstatt den Benutzer zu fragen
Schreibgeschütztes „Wie/Warum/Sind wir sicher“	investigation.md, skills/how, skills/why
Änderung mit unklarer Reichweite	skills/blast-radius vor dem Bearbeiten
Benchmark- oder Beschleunigungsbehauptung	skills/benchmark-checklist vor der Meldung
Ein Projekt ohne wiederholbaren App-Nachweis	skills/create-verification-skill (einmal fragen)
PR-Titel, -Text, Release-Notes	skills/unslop nach dem Entwurf

Playbook-Pfade befinden sich unter <pstack>/skills/poteto-mode/playbooks/. Lies jedes principle-*-Blatt, das ein Playbook zitiert, bevor du es anwendest.

Diese Regeln gewinnen, wenn pstack abweicht:

• Auslieferung. PR-Erstellung, CI und Reviews bleiben bei pr-follow-through und file-pr. pstacks Playbooks opening-a-pr, babysit und shipping sind nur Referenzmaterial. Sein Autonomie-Abschnitt autorisiert keine Commits, Pushs, Merges, externen Nachrichten oder Deployments über die aktuelle Anfrage hinaus.
• Ressourcen. Die Aufteilung auf arena, swarm, interrogate und architect ist auf maximal drei Unteragenten begrenzt, es sei denn, der Benutzer wünscht mehr. Code-schreibende Pfade erhalten eine eigene Arbeitskopie (isolation: "worktree" bei Claude Code, git worktree add bei Codex). Überspringe autopilot-full und orchestrate, es sei denn, der Benutzer verlangt sie namentlich.
• Modelle. Die Modellblätter bilden pstacks Rollen auf Modelle ab, die die Infrastruktur erreichen kann. Cross-Provider-Review bleibt bei council.
• Fehlende Cursor-Komponenten. cursor-team-kit ist nicht installiert. Für /deslop verwende pr-review-toolkit:code-simplifier wenn verfügbar; für control-ui verwende visual-qa und playwright-cli; für control-cli führe die CLI direkt aus. Überspringe Bugbot, Cursor-Automatisierungen und Cloud-Agent-Schritte mit einer Zeile, wie der Adapter sagt.
• Stimme. pstacks Antwortregeln (kurze Sätze, keine langen Gedankenstriche, Belegkennzeichnungen) können wie geschrieben verwendet werden. Halte die Zielwiederholung der ersten Nachricht auf zwei Sätze.

Fertigstellen

• Verwende pr-follow-through, wenn die Anfrage einen PR oder Review-Änderungen enthält.
• Führe Commits, Pushs, Releases oder Merges nur aus, wenn die aktuelle Aufgabe diese Aktion autorisiert. Überprüfe zuerst die Release-Automatisierung des Repositorys; gehe nicht davon aus, wie Releases erstellt werden.
• Berichte tatsächliche Ergebnisse: URLs, getestete Szenarien, Beleglinks, Fehler und alles, was wirklich das Handeln des Benutzers erfordert. Sage nicht, dass eine Vorschau, ein Plattform-Build, ein Release oder ein Review bestanden hat, ohne es zu überprüfen.
• Hinterlasse vor einem Kontext-Reset oder einer langen Wartezeit eine prägnante Übergabe außerhalb der nachverfolgten Quellen, z. B. in .agent-artifacts/HANDOFF.md. Füge Branch/Arbeitskopie, Ziel, abgeschlossene Änderungen, Befehle/Ergebnisse, PR/Head-SHA, Blocker, eigene Dateien, Ressourcen-/Sitzungsnamen und die genaue nächste Aktion hinzu. Füge niemals Tokens hinzu.
• Stoppe nur Server und Browser-Sitzungen, die dir gehören. Behalte nützliche Belege und vermeide das Löschen von nicht zusammenhängenden Arbeitskopien, Caches oder Benutzerarbeit.