itswenxin/motion-retrospective

Motion Retrospektive

Jedes abgeschlossene Projekt sollte den Agenten schlauer zurücklassen. Sobald ein Rendering bestätigt ist, überprüfe den gesamten Build, während die Beweise noch in der Laufzeitumgebung vorhanden sind (ausgeführte Befehle werden nach 7 Tagen gelöscht), und verwandle ihn in Wissen, das die nächste Sitzung wiederverwenden kann.

Auslöser

Starte diese Skill im selben Zug, in dem der Benutzer ein finales Rendering/Export bestätigt, z. B.: "gerendert / exportieren das / das isses / ship it / sieht gut aus, wird exportiert". Die Bridge fügt außerdem bridgeHealth.retrospective zum Ergebnis jedes Render-Befehls als Erinnerung hinzu. Warte nicht darauf, erneut gefragt zu werden.

Schritte

1. Sammeln. Notiere den Startzeitpunkt der Sitzung und führe dann aus:

   python3 tools/retrospective.py --slug <Projektname> --since <Sitzungsstart oder z. B. 6h> [--match "<Hauptkomp-Name>"]
   

   Dies schreibt cases/_inbox/<Datum>-<Slug>/ mit TIMELINE.md, FAILURES.md, scripts/ (jedes erfolgreiche mutierende Skript, dedupliziert) und stats.json.

2. Beweise erfassen. Nimm 4–6 Frames des finalen Renderings auf (captureFrame oder tools/run_capture.sh) und erstelle ein Kontaktblatt mit tools/sheet.py. Speichere es in evidence/. Committe niemals das Video, die .aep-Datei oder Kundendaten/-Schriftarten.

3. Timeline überprüfen. Schreibe für jede Ausführung von Befehlen auf:

   • was der Benutzer verlangt hat (aus dem Gespräch), was sich geändert hat und welches Skript es gemacht hat;
   • den Mechanismus, nicht nur das Aussehen (Rig-Struktur, Expression, Key-Values, Ebenenreihenfolge);
   • die Zahlen, die es zum Funktionieren gebracht haben (Dauern, Easing-Stärke, Offsets, Größen);
   • jeden Fehler in FAILURES.md: seine Ursache und die Lösung.

4. In Rezepte aufteilen. Ein Projekt enthält normalerweise mehrere wiederverwendbare Techniken. Gib jeder Technik einen eigenen Ordner cases/<Kategorie>/<Technik>/ (Kategorien: text-animation, shape-animation, ui-animation, transitions, effects) mit RECIPE.md, einem bereinigten, wiederverwendbaren .jsx, PROMPT_TEMPLATE.md und Beweisen. Pflege einen Projektindex in cases/projects/<Projekt>/RECIPE.md, der sie verlinkt, wie sync-dubbing-studio. Trenne projektspezifische Ebenennamen von der übertragbaren Methode.

5. Regeln fördern. Kopiere alles, was über dieses Projekt hinausgeht, in skills/SKILL.md: neue Fallstricke (坑位速查), neue Übersetzungen des Benutzerfeedbacks (反馈翻译表) und den Rezeptindex. Hake Punkte in LEARNING_MAP.md ab oder füge sie hinzu. Aktualisiere die Fallanzahl und die Projekttabelle in README.md / README.zh-CN.md, wenn sie sich ändern.

6. Veröffentlichen.

   tools/publish_case.sh cases/<Kategorie>/<Technik> "was gelernt wurde" --push
   

   Das Skript säubert /Users/<Name>/-Pfade, lehnt Video-/Audio-/.aep-Dateien ab, führt tools/health_check.py aus, commitet und pusht. Push automatisch nur, wenn der Repository-Besitzer zugestimmt hat (MOTION_AGENT_AUTO_PUBLISH=1, oder er hat darum gebeten); andernfalls committen und fragen.

7. Berichten an den Benutzer in wenigen Zeilen: wie viele Rezepte hinzugefügt wurden, welche Regeln gefördert wurden, und den Commit-Link.

Qualitätsstandard

• Ein Rezept benennt den Mechanismus und liefert Zahlen, die jemand reproduzieren kann.
• Jeder Fallstrick sagt, was kaputt ging, warum, und die Lösung.
• Keine Kunden-Assets, privaten Pfade oder unveröffentlichtes Material im öffentlichen Repository.
• Wenn das Projekt nichts Neues gelehrt hat, sag es und füge nur die Beweise zu einem bestehenden Fall hinzu.