archive

Überblick über das archive skill

Was archive besonders gut macht

Das archive skill ist für Teams und Einzelentwickler gedacht, die einmaliges Sitzungswissen in wiederverwendbares Projektgedächtnis überführen wollen. Statt Fixes in Chat-Verläufen versanden zu lassen, speichert es Debugging-Lösungen, Deployment-Notizen und Prozesserkenntnisse als strukturiertes Markdown in .archive/YYYY-MM-DD/ und hält zusätzlich einen schlanken Index in .archive/MEMORY.md.

Für wen sich archive lohnt

Dieses archive skill ist besonders geeignet für alle, die immer wieder auf dieselben Infrastruktur-, CI-, Release- oder Debugging-Probleme stoßen und künftige Wiederherstellung bzw. Problemlösung beschleunigen möchten. Besonders nützlich ist es, wenn sich die Arbeit über mehrere Sessions, mehrere Agents oder mehrere Mitwirkende erstreckt, die ein gemeinsames „Was ist beim letzten Mal passiert?“ brauchen.

Der eigentliche Job-to-be-done

Nutzer brauchen keine weitere Notizgewohnheit. Sie brauchen einen verlässlichen Weg, hochwertigen technischen Kontext direkt nach Abschluss einer relevanten Aufgabe festzuhalten und diesen Kontext vor der nächsten ähnlichen Aufgabe wieder sichtbar zu machen. archive ist auf genau diesen Ablauf ausgelegt, nicht auf generische Dokumentation.

Warum archive sich von einem normalen Prompt unterscheidet

Ein normaler Prompt kann einer KI sagen: „Fasse zusammen, was wir gemacht haben.“ Das archive skill ergänzt dafür ein wiederholbares Ablagemuster, ein verpflichtendes Update des Memory-Index und einen Session-Start-Hook, der .archive/MEMORY.md automatisch lädt, wenn die Datei vorhanden ist. Dadurch wird archive für Knowledge Bases praktisch einsetzbar: Das Archiv wird Teil des künftigen Arbeitskontexts und nicht nur eine vergessene Markdown-Datei.

Wichtige Trade-offs vor der Installation

archive ist bewusst einfach gehalten. Es bietet keine Datenbank, keine Vektorsuche und keine automatisierte Kategorisierungspipeline. Der Nutzen entsteht durch eine disziplinierte Dateistruktur, durchsuchbare Tags und einen Memory-Index. Wenn euer Team .archive/MEMORY.md nicht pflegt, verliert das archive skill einen großen Teil seines Vorteils.

So verwendest du das archive skill

archive installieren und diese Repository-Dateien zuerst lesen

Ein praktischer archive install-Pfad ist:

1. Füge das Skill aus dem Repository ReScienceLab/opc-skills in deinem Skills-System hinzu.
2. Lies zuerst skills/archive/SKILL.md, um den Workflow zu verstehen.
3. Lies skills/archive/references/TEMPLATE.md für die erforderliche Archivstruktur.
4. Lies skills/archive/hooks/hooks.json und skills/archive/hooks/load-memory.py, wenn dich das Laden von Startkontext interessiert.
5. Prüfe skills/archive/.factory-plugin/plugin.json, um das beabsichtigte Verhalten zu bestätigen.

Wenn du nur eine unterstützende Datei überfliegst, dann nimm references/TEMPLATE.md; dort steht, wie „guter archive output“ konkret aussieht.

Welche Eingaben das archive skill braucht

Das archive skill funktioniert am besten, wenn du Folgendes mitgibst:

• die abgeschlossene Aufgabe oder den Vorfall
• das zentrale Ergebnis
• die wichtigsten unternommenen Schritte
• die entscheidenden Commands, Config-Änderungen oder Code-Entscheidungen
• die Fehlstellen und die endgültigen Fixes
• die Kategorie und wahrscheinliche Tags
• eventuell vorhandene ältere, verwandte Archiveinträge

Ohne diese Angaben bleibt das Archiv zu vage, um später wirklich zu helfen.

Wann du archive auslösen solltest

Setze archive ein nach:

• einem erfolgreichen Deployment
• einer kniffligen Debugging-Session
• einer Migration oder Infrastrukturänderung
• dem Abschluss eines größeren Features
• jeder Nutzeranweisung wie „archive this“

Verwende es nicht für jede kleine Änderung. Das Skill ist für dauerhaft nützliche Erkenntnisse gedacht, nicht für verrauschte Aktivitätsprotokolle.

Wie die archive-Nutzung in der Praxis abläuft

Der vorgesehene Workflow ist:

1. Prüfe .archive/MEMORY.md auf verwandte frühere Arbeiten.
2. Erstelle oder verwende .archive/YYYY-MM-DD/.
3. Schreibe ein Markdown-Archiv anhand der Template-Struktur und mit YAML-Frontmatter.
4. Ergänze einen einzeiligen Indexeintrag in .archive/MEMORY.md.
5. Verknüpfe verwandte Einträge über das Feld related.

Dieses Index-Update ist keine optionale Fleißarbeit. Es ist der Grund, warum spätere Nachschläge schnell funktionieren.

Ein stärkerer Prompt für das archive skill

Schwacher Prompt:

• „Archive this session.“

Besserer Prompt:

• „Use the archive skill to document today’s ECS deploy issue. Include the IAM permission error, the CloudWatch clue, the exact fix, final deploy status, tags for ecs, iam, deploy, category infrastructure, and add a one-line entry to .archive/MEMORY.md. If a related archive exists, link it.”

Die stärkere Variante gibt dem Modell genug Struktur, um etwas zu erzeugen, das sich später tatsächlich wiederverwenden lässt.

Wie du aus einem groben Ziel eine vollständige archive-Anfrage machst

Wenn dein Rohziel „save what we learned“ lautet, erweitere es um:

• was passiert ist
• warum es wichtig war
• was fehlgeschlagen ist
• was es behoben hat
• was beim nächsten Mal zuerst geprüft werden sollte
• wo das in den Kategorien hingehört
• wie jemand es später über Tags finden soll

Dieses Skill belohnt retrieval-orientiertes Schreiben, nicht erzählerisches Schreiben.

Welche archive-Template-Felder am wichtigsten sind

Aus references/TEMPLATE.md sind die wichtigsten Felder:

• tags: für grep-basierte Wiederauffindung
• category: für die Organisation des Index
• related: um Vorfälle über die Zeit miteinander zu verknüpfen

Im Textkörper sind meist diese Abschnitte am wertvollsten:

• Summary
• Issues Encountered & Solutions
• Key Changes

Wenn du die konkreten Fix-Details weglässt, wird das Archiv deutlich weniger nützlich.

Wie der Session-Start-Memory-Hook die Nutzung verändert

Der Hook lädt .archive/MEMORY.md beim Start der Session in den Kontext, sofern die Datei existiert. Das bedeutet: Das archive skill ist nicht nur zum Schreiben da; es verbessert die spätere Erinnerung automatisch. Aus Adoptionssicht ist das einer der stärksten Gründe, das Skill zu installieren, statt einfach eine ad-hoc-Notizdatei zu verwenden.

archive für Knowledge Bases und Teamgedächtnis

Für archive for Knowledge Bases kannst du .archive/MEMORY.md als Inhaltsverzeichnis verstehen und jede datierte Markdown-Datei als Vorfalls- oder Aufgabenprotokoll. Das funktioniert besonders gut für:

• wiederkehrende operative Probleme
• Release-Checklisten mit Stolperfallen
• umgebungsspezifische Fixes
• Designentscheidungen mit Folgen

Weniger geeignet ist es für breite Produktdokumentation oder nutzerorientierte Handbücher.

Praktischer Such- und Nachschlage-Workflow

Das Skill unterstützt ausdrücklich eine leichtgewichtige Suche:

• .archive/MEMORY.md durchsehen
• grep -ri "keyword" .archive/ verwenden

Für viele Engineering-Teams reicht das aus, weil die gespeicherten Inhalte eng umrissen, technisch und strukturiert sind. Verwende Tags, nach denen später tatsächlich gesucht wird: Servicenamen, Fehlermeldungsfragmente, Plattformnamen und Komponentennamen.

archive skill FAQ

Lohnt sich archive, wenn ich bereits Notizen schreibe?

Ja, wenn deine aktuellen Notizen schwer auffindbar sind oder nie wieder in den Agent-Kontext zurückgelangen. Das archive skill ist nützlich, weil es Ort, Struktur, Indexierung und das Laden des Memorys beim Session-Start standardisiert.

Ist dieses archive skill anfängerfreundlich?

Ja, größtenteils. Der Workflow besteht aus einfachem Markdown plus einer Indexdatei. Das größte Risiko für Einsteiger ist, zu abstrakte Zusammenfassungen zu schreiben. Am einfachsten ist das Skill, wenn du das Template kopierst und konkrete Fixes, Commands und Learnings ausfüllst.

Wann sollte ich archive nicht verwenden?

Verwende archive nicht für:

• triviale Änderungen
• temporäres Brainstorming
• lange Dokumentationstexte
• Wissen, das in permanente Repository-Dokumentation wie README.md oder Runbooks gehört

Wenn Informationen alle Mitwirkenden jederzeit anleiten sollen, gehören sie womöglich in die Standarddokumentation und nicht nur nach .archive/.

Worin unterscheidet sich archive von normalen Projektdokumenten?

Normale Doku beschreibt das beabsichtigte System. Die archive-Nutzung hält fest, was während einer Aufgabe oder eines Vorfalls tatsächlich passiert ist: die gescheiterten Wege, den exakten Fix und den Kontext, der sonst meist verloren geht. Es ist eine historische operative Gedächtnisschicht, kein Ersatz für kanonische Doku.

Braucht archive spezielle Tooling?

Nicht viel. Das Kernformat besteht aus Markdown-Dateien plus .archive/MEMORY.md. Das Repository enthält außerdem einen Hook, der das Memory beim Session-Start lädt; aber auch ohne diesen Hook funktioniert das archive skill weiterhin als diszipliniertes Ablagemuster.

Wo liegen die Grenzen dieses archive-Leitfadens?

Dieser archive guide bildet ab, was das Repository unterstützt: dateibasierte Archive, indiziertes Memory, einfache Kategorien, verwandte Links und Hook-basierte Wiedererinnerung. Er verspricht keine automatisierten Summarization-Pipelines, keine semantische Suche und keine Synchronisierung mit externen Knowledge Bases.

So verbesserst du das archive skill

archive-Einträge für Wiederauffindbarkeit schreiben, nicht fürs Storytelling

Der beste archive output lässt sich später schnell erfassen. Platziere Problem, Fix und kritische Commands so, dass künftige Leser sie sofort finden. Eine elegant formulierte Erzählung ist weniger wert als ein direktes, gut durchsuchbares Protokoll.

Verwende Tags, nach denen wirklich gesucht wird

Gute Tags:

• Service- oder Tool-Namen
• exakte Subsystem-Namen
• Namen von Deployment-Plattformen
• Fehler-Keywords
• Namen betroffener Umgebungen

Schlechte Tags:

• vage Wörter wie issue, work oder update

Das ist einer der wirksamsten Hebel, um die Qualität der archive-Nutzung zu verbessern.

MEMORY.md nützlich machen, nicht zeremoniell

Ein schwacher Indexeintrag lautet:

• „Fixed deployment issue“

Ein starker lautet:

• „ECS deploy failed due to missing IAM permission for secret access; resolved by updating task role policy“

Der Index sollte jemandem helfen zu entscheiden, welchen Archiveintrag er als Nächstes öffnen sollte.

Fehlversuche festhalten, wenn sie künftige Entscheidungen beeinflussen

Wenn das Team vor der richtigen Lösung zwei falsche Fixes ausprobiert hat, sollten diese enthalten sein, sofern sie helfen, wiederholte Zeitverschwendung zu vermeiden. Genau hier schlägt das archive skill oft klassische Doku: Es bewahrt die Sackgassen, die wirklich relevant sind.

Mit besseren Eingaben besseren archive output erhalten

Bevor du das Skill zum Archivieren aufforderst, sammle:

• den exakten Fehlertext
• relevante Commands
• geänderte Dateien oder Einstellungen
• den final verifizierten Zustand
• warum der endgültige Fix funktioniert hat

Diese Details verbessern Wiederverwendbarkeit und Durchsuchbarkeit später ganz erheblich.

Häufige Fehlermuster bei der archive-Nutzung

Typische Probleme sind:

• fehlendes Update von .archive/MEMORY.md
• zu generische Tags
• keine klare Kategorie
• eine Zusammenfassung ohne operative Details
• Archiveinträge ohne Bezug zu früheren Vorfällen

Die meisten schlechten Archive-Ergebnisse entstehen durch unvollständige Eingaben, nicht durch das Template selbst.

Nach dem ersten archive-Entwurf nachschärfen

Prüfe nach dem ersten Entwurf:

• Kann jemand das mit wahrscheinlichen Suchbegriffen finden?
• Nennt die Zusammenfassung Ergebnis und Ursache?
• Sind die wichtigsten Commands oder Config-Änderungen enthalten?
• Wüsste ein zukünftiger Agent, was er zuerst versuchen sollte?
• Sollte es auf einen älteren verwandten Eintrag verlinken?

Ein kurzer zweiter Durchgang steigert die archive-Qualität meist deutlich.

archive ergänzend einsetzen, nicht statt permanenter Doku

Wenn aus der Session eine dauerhafte Regel hervorgegangen ist, aktualisiere zusätzlich die kanonische Dokumentation. Das archive skill sollte Wissen auf Ereignisebene bewahren; es sollte nicht der einzige Ort werden, an dem kritische Teamhinweise leben.

archive-Einführung mit klaren Team-Triggern verbessern

Teams erzielen bessere Ergebnisse, wenn sie explizite Auslöser definieren, etwa:

• jedes Production-Deployment mit Überraschungen
• jeder Vorfall mit nicht offensichtlichem Fix
• jede Migration
• jede Nutzeranweisung wie „save this for next time“

So bleibt das Archiv wertvoll, ohne mit Rauschen gefüllt zu werden.