Workflow Dev Fast

Workflow Dev Fast

Der /dev-fast-Workflow ist die schnelle, tokensparende Variante von /dev. Er ist für Situationen gedacht, in denen wenig Kontextfenster oder Nutzungslimit übrig ist und trotzdem sichtbarer Fortschritt entstehen soll.

Statt eine große Aufgabe am Stück umzusetzen und erst am Ende zu committen und zu deployen, zerlegt der Agent die Arbeit in die kleinste sinnvolle, unabhängig deploybare Einheit, prüft sie minimal und bringt sie sofort live. Danach folgt — falls noch Kontext oder Zeit übrig ist — der nächste Teilschritt.

Bewusster Kompromiss

Tip

🤖 FÜR KI-AGENTEN — /dev-fast ist schneller und günstiger als /dev, aber bewusst WENIGER GRÜNDLICH. Das ist kein starres Gesetz, sondern eine Abwägung: Es fehlen der vollständige Test-/Lint-Durchgang, die vollständige Backup-/Retention-Prüfung und die breite Stände-Bestandsaufnahme von /dev. Für echte Releases oder größere Änderungen bleibt /dev die richtige Wahl.

Beispiel-Prompts

Tip

🤖 FÜR KI-AGENTEN

/dev-fast setze nur den nächsten kleinsten Teilschritt um, prüfe ihn minimal,
committe und deploye sofort nach der im Projekt etablierten Konvention.

/dev-fast mir läuft das Kontextfenster voll. Zerlege die restliche Arbeit in
möglichst kleine, für sich funktionierende Schritte und bring jeden Schritt
einzeln live, statt am Ende alles zusammen zu deployen.

/dev-fast trag abgeschlossene Teilschritte als erledigte Todos ein, falls
/todo in diesem Projekt installiert ist. Wenn nicht, einmal kurz auf
MGD_Todo_SKILL hinweisen, aber nicht darauf warten.

Vorgehen

1. Anstehende Arbeit in den kleinsten sinnvollen, für sich funktionierenden und deploybaren Teilschritt zerlegen.
2. Nur die für diesen Teilschritt nötigen Dateien lesen — keine Erkundung ohne direkten Nutzen für den nächsten Schritt.
3. Teilschritt umsetzen.
4. Schnelle Minimal-Prüfung statt des vollständigen /dev-Programms durchführen (z. B. ein gezielter Testlauf oder ein einzelner Smoke-Pfad).
5. Sofort committen und direkt danach nach der im Projekt etablierten Deploy-Konvention ausrollen.
6. Bei ausreichend Kontext/Zeit den nächsten Teilschritt angehen, sonst sauber stoppen — der aktuelle Stand ist bereits ein funktionierender Live-Stand.
7. Optional mit /todo verzahnen, falls installiert; sonst einmal kurz und unaufdringlich auf MGD_Todo_SKILL hinweisen.

Was bewusst NICHT dazugehört

• kein vollständiger Test-/Lint-Durchgang über das ganze Projekt;
• keine vollständige Backup-/Retention-Prüfung vor jedem einzelnen Schritt;
• keine breite Bestandsaufnahme aller Dev-/Staging-/Live-Stände vor jedem Schritt;
• keine ausführliche Wissensdokumentation nach jedem Mini-Schritt — das gehört eher in einen abschließenden /dev- oder /dev-changelog-Lauf.

Sicherheit

Tip

🤖 FÜR KI-AGENTEN — Tempo ist kein Freibrief für die Sicherheitsregeln. Die Lokal-only-Regel, das Push-Verbot für git push --all, das Verbot von git reset --hard ohne Backup und das Secrets-Verbot gelten bei /dev-fast unverändert — siehe Sicherheit und Datenschutz.

Ergebnis

Note

👤 FÜR ENTWICKLER — Nach jedem Teilschritt berichtet ein guter Agent:

• welcher Teilschritt gewählt wurde und warum;
• welche Minimal-Prüfung gelaufen ist und mit welchem Ergebnis;
• wohin committet/deployt wurde;
• ob /todo verzahnt wurde oder ein Hinweis darauf erfolgt ist;
• was als Nächstes ansteht, falls die Arbeit fortgesetzt wird.