huangrx6/obsidian-work-log-release-recorder

Obsidian Work Log And Release Recorder

Cette compétence transforme le travail terminé en notes Obsidian durables. Elle est intentionnellement sélective : l'objectif n'est pas de conserver la transcription du chat, mais de garder le petit ensemble de faits qui aidera la prochaine implémentation, release, rollback ou passation.

Prérequis

Le chemin est résolu à partir de la configuration, non lié à la machine (identique aux prérequis de PKB ; n'écrivez aucun chemin spécifique à une machine ici) :

• Le chemin du vault est résolu à partir de $OBSIDIAN_VAULT_PATH ou ~/.config/agent-skills/obsidian-vault-path — ne jamais le coder en dur
• Méthode standard pour obtenir le chemin : python3 ../obsidian-personal-knowledge-base/scripts/vault_path.py --explain
• Changer de machine ou déplacer le vault nécessite uniquement de modifier les deux éléments ci-dessus ; cette compétence et PKB suivent le mouvement.

Liste de contrôle de démarrage obligatoire

Avant d'écrire quoi que ce soit dans le vault, vous devez :

1. Charger obsidian-personal-knowledge-base/references/vault-map.md — la carte du répertoire du vault et ses conventions de placement.
2. Charger obsidian-personal-knowledge-base/references/writing-conventions.md — conventions de nommage, frontmatter, liens et MOC.
3. Explorer la zone cible avec un simple ls (voir Décision d'emplacement) — vault-map.md est un instantané, pas une autorité ; le système de fichiers prime en cas de conflit.

Ces exigences sont impératives, pas des suggestions. Si obsidian-personal-knowledge-base n'est pas installé, dites à l'utilisateur de l'installer d'abord et arrêtez-vous. N'écrivez pas dans le vault en vous basant sur des hypothèses concernant sa structure. Ne dupliquez pas les conventions du vault dans cette compétence — lorsque les références de PKB changent, cette compétence hérite du changement.

Périmètre

Réutilisez la note de projet, de domaine, de ressource, MOC ou modèle existant la plus proche plutôt que d'inventer une structure parallèle. Lorsqu'aucune note existante ne couvre le sujet, suivez les règles de placement dans obsidian-personal-knowledge-base/references/vault-map.md.

Signaux de déclenchement

Utilisez cette compétence lorsqu'une ou plusieurs de ces conditions sont vraies :

• une tâche a été terminée et a produit des décisions d'implémentation, des scripts, des chemins, des configurations, des changements de base de données, des variables d'environnement, des étapes de validation, des étapes de rollback ou des commandes de release
• l'utilisateur demande d'enregistrer le travail dans la base de connaissances personnelle
• l'utilisateur demande une note de version hebdomadaire, une checklist de release, un enregistrement de déploiement ou un document de release (发版文档)
• une note de projet ou de domaine doit être mise à jour après du code, SQL, de la configuration, un déploiement ou des opérations
• un processus opérationnel récurrent devient plus clair après une tâche et doit être conservé pour une utilisation future

Ne vous déclenchez pas pour des explications ordinaires, du brainstorming, des plans spéculatifs, des résumés de chat ponctuels ou des modifications mineures sans valeur opérationnelle future.

Si la demande mélange l'enregistrement du travail terminé avec la modification ou l'organisation de notes existantes (par exemple "la release est faite, aide-moi à organiser" ou "mets à jour telle partie dans la base de connaissances"), demandez d'abord ce que l'utilisateur souhaite avant d'agir au lieu de deviner. Les deux intentions sont légitimes ; seul l'utilisateur sait laquelle.

Que enregistrer

N'enregistrez que les points concrets. Un point concret est quelque chose qui est maintenant vrai, qui a été exécuté, qui a été changé, ou qui est prêt à être suivi par une autre personne.

Bons candidats :

• fichiers, modules, API, scripts, fichiers SQL, routes, services ou chemins de déploiement qui ont changé
• commandes qui ont été exécutées ou qui doivent l'être pendant la release
• clés de configuration, variables d'environnement, ports, chemins serveur, noms de conteneurs, tâches cron ou feature flags qui comptent
• preuves de validation telles que commandes de build, tests de fumée, vérifications API, captures d'écran, logs ou vérifications ignorées connues
• étapes de rollback ou de sauvegarde
• hypothèses d'ordre d'exécution, dépendances, conditions préalables et risques
• décisions de conception durables qui affectent le travail futur

N'enregistrez pas : la conversation brute ; chaque fichier touché alors qu'un résumé suffit ; les expériences ratées sauf si elles évitent de futures erreurs ; le bruit de formatage trivial ou local uniquement ; les secrets, jetons, mots de passe ou identifiants complets ; les plans spéculatifs qui n'ont pas été acceptés.

Si un détail a l'air sensible mais est important sur le plan opérationnel, enregistrez le nom de la variable ou du fichier de configuration et son emplacement, pas la valeur secrète.

Décision d'emplacement

Choisissez le dossier stable le plus précis :

• Le travail orienté résultat avec une ligne d'arrivée va dans 01 Projects/<projet>/.
• Les responsabilités à long terme, les systèmes de livraison ou les connaissances opérationnelles vont dans 02 Areas/<domaine>/.
• Les connaissances techniques réutilisables vont dans 03 Resources/<sujet>/.
• Les captures peu claires ou incomplètes vont dans 00 Inbox/, mais seulement lorsqu'il n'y a pas assez de contexte pour classifier de manière sûre.

Pour cette compétence, résolvez les chemins en explorant, pas de mémoire.

1. Explorez la zone candidate avant d'écrire (ls "$VAULT/01 Projects", ls "$VAULT/02 Areas", ls "$VAULT/03 Resources").
2. Choisissez le dossier existant le plus précis qui couvre le sujet.
3. Si le dossier visé n'existe pas, demandez à l'utilisateur où le créer — n'écrivez pas dans un chemin inexistant. Exception : l'utilisateur a déjà explicitement indiqué le chemin dans cette session ("mets-le dans 02 Areas/05 数据平台/") → utilisez ce chemin, ne demandez pas à nouveau (la question est "je ne sais pas où le mettre", pas "l'utilisateur n'a pas son mot à dire").
4. Mettez à jour le MOC/index le plus proche après avoir créé une nouvelle note durable.

Scénario courant : release de déploiement et d'exploitation

Ce type de release (packaging, upload, décompression, copie de configuration, redémarrage de conteneur, release séparée frontend/backend) est généralement classé dans 02 Areas/<domaine>/<sous-thème>/. Si aucun domaine ne correspond : informez l'utilisateur que le chemin historique n'existe plus, demandez où enregistrer avant d'agir — n'écrivez pas dans un ancien chemin mémorisé, et ne présumez pas qu'un certain type de projet a nécessairement une Area correspondante.

Demande floue "enregistre ce que j'ai fait cette semaine" : ne décidez pas vous-même

Elle correspond à la fois au déclencheur (enregistrer) et à l'exclusion (résumé hebdomadaire vague). Demandez d'abord à l'utilisateur quel type il veut : rapport hebdomadaire → PKB (references/work-management.md) ; faits de release concrets de la semaine → cette compétence. N'écrivez aucune note avant la réponse.

Note de version hebdomadaire

Lorsque la tâche inclut la préparation d'une release ou des changements pertinents pour la release, maintenez une note de version hebdomadaire dans le dossier de projet ou de domaine le plus pertinent.

Nom par défaut :

发版 - <système ou nom de projet> - YYYY-Www.md

Exemples : 01 Projects/<nom du projet>/发版 - <nom du projet> - 2026-W18.md ou 02 Areas/<domaine>/<sous-thème>/发版 - <système ou nom de projet> - 2026-W18.md.

Utilisez la numérotation ISO des semaines sauf si l'utilisateur fournit une convention de nommage différente pour les releases. Si une note pour la semaine en cours existe déjà, mettez-la à jour au lieu d'en créer une nouvelle. Explorez le dossier parent avant d'écrire ; s'il n'existe pas, demandez à l'utilisateur où la note de release doit vivre (comme ci-dessus : le chemin déjà indiqué par l'utilisateur dans cette session est la réponse).

Modèle de note de version hebdomadaire

Lisez references/release-note-template.md et utilisez sa structure, sauf si une note existante proche a une convention locale plus forte.

Gardez les notes de release courtes. Mettez les scripts complets ou les extraits de configuration sous 04 发布依赖清单, mais évitez de transformer la note en un runbook détaillé sauf si l'utilisateur demande de la profondeur opérationnelle.

Flux de mise à jour

1. Identifiez le résultat de la tâche.

   • Résumez ce qui a réellement changé ou a été décidé.
   • Séparez les faits concrets des hypothèses, options et tentatives abandonnées.

2. Choisissez les destinations des notes.

   • Mettez d'abord à jour une note existante de projet/domaine/ressource lorsqu'elle couvre déjà le sujet.
   • Créez la note de version hebdomadaire uniquement lorsque des détails pertinents pour la release existent.
   • Mettez à jour le MOC le plus proche lorsqu'une nouvelle note durable est créée.

3. Écrivez la mise à jour la plus petite et durable qui reste opérationnelle.

   • Puces compactes pour les logs de travail ; blocs de commande uniquement lorsque l'exécution future a besoin de commandes exactes.
   • Expliquez les drapeaux non évidents, les champs de configuration, les chemins et les hypothèses d'ordre.
   • Enregistrez quoi exécuter, où, ce que cela affecte et comment le vérifier.
   • Incluez explicitement les validations ignorées, ainsi que les étapes de sauvegarde et de rollback pour les notes de release lorsqu'elles sont connues.

4. Vérifiez l'intégrité des liens et de la structure.

   • Assurez-vous que les nouvelles notes sont liées depuis le MOC ou la note parente la plus proche.
   • Exécutez python3 scripts/check_release_note.py <chemin de la note> — il vérifie les règles que cette compétence s'est elle-même fixées (format du nom de fichier, numéro ISO de semaine, cohérence titre/nom de fichier, frontmatter, squelette des sections du modèle, pas de doublon pour le même système et la même semaine, déjà lié au MOC, pas de valeur de clé évidente). Le squelette des sections est lu depuis references/release-note-template.md ; si le modèle change, il change avec lui.
   • Les liens brisés ne sont pas de son ressort — c'est le travail du script PKB suivant (les deux sont complémentaires, pas redondants).
   • Exécutez python3 ../obsidian-personal-knowledge-base/scripts/check_links.py --ignore-template après avoir créé ou déplacé des notes ; attendez un code de sortie 0 (détails dans references/structural-checks.md de PKB).
   • Si cette opération a modifié la structure des répertoires, le nombre de fichiers ou le comportement des hooks, mettez à jour la description correspondante dans vault-map.md ou le SKILL.md pertinent dans la même opération — ne laissez pas cela à découvrir lors de la prochaine exploration.
   • Évitez de dupliquer les mêmes instructions de release à plusieurs endroits ; faites plutôt des liens croisés.

5. Rapportez brièvement — gardez la passation courte ; la valeur réside dans les notes.

   • Quelles notes ont été créées ou mises à jour.
   • Quels points concrets ont été enregistrés.
   • Si une note de version hebdomadaire a été créée ou mise à jour.
   • Toutes hypothèses, validations ignorées ou détails de release manquants.

Style d'écriture

Écrivez comme une mémoire opérationnelle, pas un journal intime :

• direct, factuel et facile à parcourir
• priorité au chinois, avec des termes techniques anglais lorsqu'ils sont canoniques
• pas de langage d'accompagnement comme "第一次", "可以先这样理解" ou "接下来我们"
• pas de résumés gonflés ; préférez les commandes, chemins et contraintes exacts
• pas de secrets

Installation

Installez via npx skills add huangrx6/agent-skills à la racine du dépôt (voir le README.md racine).

Installez d'abord obsidian-personal-knowledge-base — cette compétence dépend de ses references/vault-map.md et references/writing-conventions.md, et refuse d'écrire lorsqu'elles ne sont pas disponibles.