Obsidian Arbeitsprotokoll und Release-Recorder

Was macht Obsidian Arbeitsprotokoll und Release-Recorder?

Dieses Skill wandelt abgeschlossene Arbeit in dauerhafte Obsidian-Notizen um. Es ist bewusst selektiv: Ziel ist nicht, das Chat-Transkript zu erhalten, sondern die kleine Menge an Fakten zu bewahren, die bei der nächsten Implementierung, dem nächsten Release, Rollback oder der Übergabe helfen.

Voraussetzungen

Pfade werden aus der Konfiguration aufgelöst, nicht an den Rechner gebunden (identisch mit den PKB-Voraussetzungen; hier keine maschinenspezifischen Pfade angeben):

• Vault-Pfad wird aus $OBSIDIAN_VAULT_PATH oder ~/.config/agent-skills/obsidian-vault-path aufgelöst — niemals hartcodieren.
• Standardmethode zur Pfadermittlung: python3 ../obsidian-personal-knowledge-base/scripts/vault_path.py --explain
• Bei Rechnerwechsel oder Vault-Umzug genügt es, die beiden obigen Konfigurationen zu ändern; dieses Skill und PKB folgen automatisch.

Obligatorische Start-Checkliste

Bevor Sie etwas in den Vault schreiben, müssen Sie:

1. obsidian-personal-knowledge-base/references/vault-map.md laden — die Verzeichnisstruktur und Platzierungskonventionen des Vaults.
2. obsidian-personal-knowledge-base/references/writing-conventions.md laden — Namensgebung, Frontmatter, Link- und MOC-Konventionen.
3. Den Zielbereich mit einem einstufigen ls überprüfen (siehe Ortsentscheidung) — vault-map.md ist eine Momentaufnahme, nicht autoritativ; das Dateisystem gewinnt bei Konflikten.

Dies sind harte Anforderungen, keine Vorschläge. Wenn obsidian-personal-knowledge-base nicht installiert ist, teilen Sie dem Benutzer mit, dass er es zuerst installieren muss, und brechen Sie ab. Schreiben Sie nicht auf der Grundlage von Annahmen über die Vault-Struktur in den Vault. Forken Sie die Vault-Konventionen nicht in dieses Skill — wenn sich die PKB-Referenzen ändern, übernimmt dieses Skill die Änderung.

Umfang

Verwenden Sie die nächstgelegene vorhandene Projekt-, Bereichs-, Ressourcen-Notiz, MOC oder Vorlage wieder, anstatt eine parallele Struktur zu erfinden. Wenn keine vorhandene Notiz das Thema abdeckt, befolgen Sie die Platzierungsregeln in obsidian-personal-knowledge-base/references/vault-map.md.

Triggersignale

Verwenden Sie dieses Skill, wenn eine oder mehrere der folgenden Bedingungen zutreffen:

• eine Aufgabe wurde abgeschlossen und hat Implementierungsentscheidungen, Skripte, Pfade, Konfigurationen, Datenbankänderungen, Umgebungsvariablen, Validierungsschritte, Rollback-Schritte oder Release-Befehle hervorgebracht
• der Benutzer bittet darum, Arbeit im persönlichen Wissensspeicher festzuhalten
• der Benutzer bittet um eine wöchentliche Release-Notiz, Release-Checkliste, Deployment-Aufzeichnung oder ein 发版文档 (Release-Dokument)
• eine Projekt- oder Bereichsnotiz muss nach Code-, SQL-, Konfigurations-, Deployment- oder Betriebsarbeit aktualisiert werden
• ein wiederkehrender Betriebsablauf wird nach einer Aufgabe klarer und sollte für die zukünftige Verwendung aufbewahrt werden

Nicht auslösen bei gewöhnlichen Erklärungen, Brainstorming, spekulativen Plänen, einmaligen Chat-Zusammenfassungen oder winzigen Änderungen ohne zukünftigen Betriebswert.

Wenn die Anfrage das Festhalten abgeschlossener Arbeit mit dem Bearbeiten oder Organisieren vorhandener Notizen vermischt (z.B. „发版了，帮我整理一下“ oder „更新一下知识库里某块内容“), fragen Sie den Benutzer, was er möchte, bevor Sie handeln, anstatt zu raten. Beide Absichten sind legitim; nur der Benutzer weiß, welche gemeint ist.

Was aufgezeichnet werden soll

Zeichnen Sie nur gelandete Punkte auf. Ein gelandeter Punkt ist etwas, das jetzt wahr ist, ausgeführt wurde, geändert wurde oder bereit ist, von einer anderen Person befolgt zu werden.

Gute Kandidaten:

• Dateien, Module, APIs, Skripte, SQL-Dateien, Routen, Dienste oder Deployment-Pfade, die geändert wurden
• Befehle, die ausgeführt wurden oder während des Releases ausgeführt werden müssen
• Konfigurationsschlüssel, Umgebungsvariablen, Ports, Serverpfade, Containernamen, Cron-Jobs oder Feature-Flags, die von Bedeutung sind
• Validierungsnachweise wie Build-Befehle, Smoke-Tests, API-Prüfungen, Screenshots, Logs oder bekannte übersprungene Prüfungen
• Rollback- oder Backup-Schritte
• Annahmen zur Ausführungsreihenfolge, Abhängigkeiten, Vorbedingungen und Risiken
• Dauerhafte Designentscheidungen, die zukünftige Arbeit beeinflussen

Nicht aufzeichnen: rohes Gespräch; jede berührte Datei, wenn nur eine Zusammenfassung wichtig ist; fehlgeschlagene Experimente, es sei denn, sie verhindern zukünftige Fehler; triviale Formatierung oder lokales Rauschen; Geheimnisse, Token, Passwörter oder vollständige Anmeldedaten; spekulative Pläne, die nicht akzeptiert wurden.

Wenn ein Detail vertraulich, aber betrieblich wichtig erscheint, zeichnen Sie den Variablen- oder Konfigurationsnamen und -ort auf, nicht den Geheimniswert.

Ortsentscheidung

Wählen Sie das engste stabile Zuhause:

• Ergebnisorientierte Arbeit mit einem Zieltermin geht unter 01 Projects/<projekt>/.
• Langfristige Verantwortlichkeiten, Auslieferungssysteme oder Betriebswissen geht unter 02 Areas/<bereich>/.
• Wiederverwendbares technisches Wissen geht unter 03 Resources/<thema>/.
• Unklare oder unvollständige Erfassung geht unter 00 Inbox/, aber nur, wenn nicht genügend Kontext für eine sichere Klassifizierung vorhanden ist.

Für dieses Skill: Lösen Sie Pfade durch Sondieren auf, nicht aus dem Gedächtnis.

1. Sondieren Sie den Kandidatenbereich vor dem Schreiben (ls "$VAULT/01 Projects", ls "$VAULT/02 Areas", ls "$VAULT/03 Resources").
2. Wählen Sie das engste vorhandene Verzeichnis, das das Thema abdeckt.
3. Wenn das beabsichtigte Verzeichnis nicht existiert, fragen Sie den Benutzer, wo es erstellt werden soll — schreiben Sie nicht in einen nicht existierenden Pfad. Ausnahme: Der Benutzer hat in dieser Runde bereits einen genauen Pfad genannt („Lege es unter 02 Areas/05 数据平台/ ab“) → verwenden Sie diesen Pfad, fragen Sie nicht noch einmal (es geht darum, „weiß nicht, wohin“, nicht „die Aussage des Benutzers zählt nicht“).
4. Aktualisieren Sie den nächstgelegenen MOC/Index nach dem Erstellen einer neuen dauerhaften Notiz.

Häufiges Szenario: Deployment- und Betriebsrelease

Diese Art von Release (Packen, Hochladen, Entpacken, Konfigurationskopie, Container-Neustart, getrenntes Frontend/Backend-Release) gehört normalerweise unter 02 Areas/<bereich>/<unterthema>/. Wenn kein passender Bereich vorhanden ist: Teilen Sie dem Benutzer mit, dass der historische Pfad nicht mehr existiert, fragen Sie, wo die Aufzeichnung abgelegt werden soll, und handeln Sie dann – schreiben Sie nicht in einen alten, erinnerten Pfad und gehen Sie nicht davon aus, dass eine bestimmte Projektart immer einen entsprechenden Bereich hat.

Vage Anfragen wie „Halte die Arbeit dieser Woche fest“: Nicht selbst entscheiden

Es trifft gleichzeitig auf Triggerwörter („festhalten“) und Ausschlusskriterien (vage wöchentliche Zusammenfassung) zu. Fragen Sie zuerst den Benutzer, welche Art er möchte: Wochenbericht → PKB (references/work-management.md); diese Woche gelandete Release-Fakten → dieses Skill. Schreiben Sie keine Notizen, bevor die Antwort vorliegt.

Wöchentliche Release-Notiz

Wenn die Aufgabe die Release-Vorbereitung oder release-relevante Änderungen umfasst, pflegen Sie eine wöchentliche Release-Notiz im relevantesten Projekt- oder Bereichsordner.

Standardbenennung:

发版 - <System- oder Projektname> - YYYY-Www.md

Beispiele: 01 Projects/<projektname>/发版 - <projektname> - 2026-W18.md oder 02 Areas/<bereich>/<unterthema>/发版 - <system- oder projektname> - 2026-W18.md.

Verwenden Sie die ISO-Wochennummerierung, es sei denn, der Benutzer gibt eine andere Release-Benennungskonvention vor. Wenn bereits eine Notiz für die aktuelle Woche existiert, aktualisieren Sie diese, anstatt eine neue zu erstellen. Sondieren Sie den übergeordneten Ordner vor dem Schreiben; wenn er nicht existiert, fragen Sie den Benutzer, wo die Release-Notiz abgelegt werden soll (wie oben: Der in dieser Runde vom Benutzer genannte Pfad ist die Antwort).

Vorlage für wöchentliche Release-Notiz

Lesen Sie references/release-note-template.md und verwenden Sie dessen Struktur, es sei denn, eine nahe gelegene vorhandene Notiz hat eine stärkere lokale Konvention.

Halten Sie Release-Notizen kurz. Fügen Sie vollständige Skripte oder Konfigurationsausschnitte unter 04 发布依赖清单 ein, aber vermeiden Sie es, die Notiz in ein detailliertes Runbook zu verwandeln, es sei denn, der Benutzer wünscht betriebliche Tiefe.

Aktualisierungsworkflow

1. Identifizieren Sie das Aufgabenergebnis.

   • Fassen Sie zusammen, was sich tatsächlich geändert oder entschieden wurde.
   • Trennen Sie gelandete Fakten von Vermutungen, Optionen und aufgegebenen Versuchen.

2. Wählen Sie die Notizziele.

   • Aktualisieren Sie zuerst eine vorhandene Projekt-/Bereichs-/Ressourcennotiz, wenn diese das Thema bereits abdeckt.
   • Erstellen Sie die wöchentliche Release-Notiz nur, wenn release-relevante Details vorhanden sind.
   • Aktualisieren Sie den nächstgelegenen MOC, wenn eine neue dauerhafte Notiz erstellt wird.

3. Schreiben Sie das kleinste dauerhafte Update, das betrieblich bleibt.

   • Kompakte Aufzählungspunkte für Arbeitsprotokolle; Befehlsblöcke nur, wenn die zukünftige Ausführung genaue Befehle benötigt.
   • Erklären Sie nicht offensichtliche Flags, Konfigurationsfelder, Pfade und Annahmen zur Reihenfolge.
   • Halten Sie fest, was ausgeführt werden soll, wo, was es beeinflusst und wie es zu überprüfen ist.
   • Fügen Sie explizit übersprungene Validierungen sowie Backup- und Rollback-Schritte für Release-Notizen hinzu, wenn bekannt.

4. Überprüfen Sie die Link- und Strukturintegrität.

   • Stellen Sie sicher, dass neue Notizen vom nächstgelegenen MOC oder der übergeordneten Notiz verlinkt sind.
   • Führen Sie python3 scripts/check_release_note.py <notizpfad> aus – es prüft die von diesem Skill selbst festgelegten Regeln (Dateinamenformat, ISO-Wochennummer, Übereinstimmung von Titel und Dateiname, Frontmatter, Kapitelgerüst aus der Vorlage, keine Dubletten für dasselbe System und dieselbe Woche, Verknüpfung mit MOC, keine offensichtlichen Schlüsselwerte). Das Kapitelgerüst wird aus references/release-note-template.md gelesen; wenn die Vorlage geändert wird, ändert es sich entsprechend.
   • Ob Links ungültig sind, prüft es nicht – das ist Aufgabe des folgenden PKB-Skripts (beide ergänzen sich, überschneiden sich nicht).
   • Führen Sie python3 ../obsidian-personal-knowledge-base/scripts/check_links.py --ignore-template nach dem Erstellen oder Verschieben von Notizen aus; erwarten Sie Exit 0 (Details in PKBs references/structural-checks.md).
   • Wenn dieser Vorgang die Verzeichnisstruktur, Dateianzahl oder das Hook-Verhalten geändert hat, aktualisieren Sie die Beschreibung davon in vault-map.md oder der relevanten SKILL.md im selben Vorgang – hinterlassen Sie es nicht, damit die nächste Sondierung es entdeckt.
   • Vermeiden Sie es, dieselben Release-Anweisungen an mehreren Stellen zu duplizieren; verlinken Sie stattdessen.

5. Melden Sie kurz zurück – halten Sie die Übergabe kurz; der Wert liegt in den Notizen.

   • Welche Notizen erstellt oder aktualisiert wurden.
   • Welche gelandeten Punkte aufgezeichnet wurden.
   • Ob eine wöchentliche Release-Notiz erstellt oder aktualisiert wurde.
   • Alle Annahmen, übersprungenen Validierungen oder fehlenden Releasetails.

Schreibstil

Schreiben Sie wie ein Betriebsgedächtnis, nicht wie ein Tagebuch:

• direkt, sachlich und leicht zu überfliegen
• zuerst Chinesisch, mit englischen Fachbegriffen, wo sie kanonisch sind
• keine anleitende Sprache wie „第一次“, „可以先这样理解“ oder „接下来我们“
• keine aufgeblähten Zusammenfassungen; bevorzugen Sie genaue Befehle, Pfade und Einschränkungen
• keine Geheimnisse

Installation

Installieren Sie über das Repo-Root npx skills add huangrx6/agent-skills (siehe Repo-Root README.md).

Installieren Sie zuerst obsidian-personal-knowledge-base – dieses Skill ist abhängig von dessen references/vault-map.md und references/writing-conventions.md und weigert sich zu schreiben, wenn diese nicht verfügbar sind.