huangrx6/obsidian-work-log-release-recorder

Observación de Registro de Trabajo y Grabador de Lanzamiento (Obsidian Work Log And Release Recorder)

Esta skill convierte el trabajo completado en notas duraderas de Obsidian. Es intencionalmente selectiva: el objetivo no es preservar la transcripción del chat, sino mantener el pequeño conjunto de hechos que ayudarán en la próxima implementación, lanzamiento, reversión o traspaso.

Prerrequisitos

La ruta se resuelve desde la configuración, no está vinculada a la máquina local (coincide con los Prerrequisitos de PKB; no escribas ninguna ruta específica de la máquina aquí):

• La ruta de la bóveda se resuelve desde $OBSIDIAN_VAULT_PATH o ~/.config/agent-skills/obsidian-vault-path — nunca la codifiques
• Forma estándar de obtener la ruta: python3 ../obsidian-personal-knowledge-base/scripts/vault_path.py --explain
• Si cambias de máquina o mueves la bóveda, solo necesitas modificar los dos elementos anteriores; esta skill y PKB te seguirán

Lista de verificación obligatoria al inicio

Antes de escribir cualquier cosa en la bóveda, debes:

1. Cargar obsidian-personal-knowledge-base/references/vault-map.md — el mapa de directorios de la bóveda y las convenciones de colocación.
2. Cargar obsidian-personal-knowledge-base/references/writing-conventions.md — convenciones de nomenclatura, frontmatter, enlaces y MOC.
3. Explorar el área objetivo con un ls de un solo nivel (consulta Decisión de Ubicación) — vault-map.md es una instantánea, no autoritativa; el sistema de archivos tiene prioridad en caso de conflicto.

Estos son requisitos estrictos, no sugerencias. Si obsidian-personal-knowledge-base no está instalado, dile al usuario que lo instale primero y detente. No escribas en la bóveda basándote en suposiciones sobre su estructura. No bifurques las convenciones de la bóveda en esta skill — cuando las referencias de PKB cambien, esta skill hereda el cambio.

Alcance

Reutiliza la nota de proyecto, área, recurso, MOC o plantilla existente más cercana en lugar de inventar una estructura paralela. Cuando ninguna nota existente cubra el tema, sigue las reglas de colocación en obsidian-personal-knowledge-base/references/vault-map.md.

Señales de Activación

Usa esta skill cuando una o más de las siguientes condiciones sean ciertas:

• se ha completado una tarea y ha producido decisiones de implementación, scripts, rutas, configuraciones, cambios en la base de datos, variables de entorno, pasos de validación, pasos de reversión o comandos de lanzamiento
• el usuario pide registrar el trabajo en la base de conocimiento personal
• el usuario pide una nota de lanzamiento semanal, lista de verificación de lanzamiento, registro de despliegue o documento de lanzamiento (发版文档)
• una nota de proyecto o área necesita ser actualizada después de trabajo de código, SQL, configuración, despliegue u operaciones
• un proceso operativo recurrente se vuelve más claro después de una tarea y debe conservarse para uso futuro

No te actives para explicaciones ordinarias, lluvia de ideas, planes especulativos, resúmenes de chat únicos o ediciones pequeñas sin valor operativo futuro.

Si la solicitud mezcla el registro de trabajo realizado con la edición u organización de notas existentes (por ejemplo, “发版了，帮我整理一下” o “更新一下知识库里某块内容”), pregunta al usuario cuál de las dos quiere antes de actuar en lugar de adivinar. Ambas intenciones son legítimas; solo el usuario sabe cuál.

Qué Registrar

Registra solo puntos concretos. Un punto concreto es algo que ahora es verdad, se ejecutó, se cambió o está listo para que otra persona lo siga.

Buenos candidatos:

• archivos, módulos, APIs, scripts, archivos SQL, rutas, servicios o rutas de despliegue que cambiaron
• comandos que se ejecutaron o deben ejecutarse durante el lanzamiento
• claves de configuración, variables de entorno, puertos, rutas de servidor, nombres de contenedores, trabajos cron o flags de funcionalidad que importan
• evidencia de validación como comandos de compilación, pruebas de humo, verificaciones de API, capturas de pantalla, registros o comprobaciones omitidas conocidas
• pasos de reversión o respaldo
• supuestos sobre el orden de ejecución, dependencias, condiciones previas y riesgos
• decisiones de diseño duraderas que afecten el trabajo futuro

No registres: conversación sin procesar; cada archivo tocado cuando solo importa un resumen; experimentos fallidos a menos que eviten errores futuros; ruido trivial de formato o solo local; secretos, tokens, contraseñas o credenciales completas; planes especulativos que no fueron aceptados.

Si un detalle parece sensible pero es importante operativamente, registra el nombre de la variable o configuración y su ubicación, no el valor secreto.

Decisión de Ubicación

Elige el hogar estable más específico:

• El trabajo orientado a resultados con una línea de meta va bajo 01 Projects/<proyecto>/.
• Las responsabilidades de largo plazo, sistemas de entrega o conocimiento operativo van bajo 02 Areas/<área>/.
• El conocimiento técnico reutilizable va bajo 03 Resources/<tema>/.
• La captura poco clara o incompleta va bajo 00 Inbox/, pero solo cuando no hay suficiente contexto para clasificar de forma segura.

Para esta skill, resuelve las rutas explorando, no de memoria.

1. Explora el área candidata antes de escribir (ls "$VAULT/01 Projects", ls "$VAULT/02 Areas", ls "$VAULT/03 Resources").
2. Elige el directorio existente más específico que sea dueño del tema.
3. Si el directorio previsto no existe, pregunta al usuario dónde crearlo — no escribas en una ruta que no existe. Excepción: el usuario ya ha indicado la ruta exacta en esta misma interacción (por ejemplo «ponlo bajo 02 Areas/05 数据平台/») → usa esa ruta, no preguntes de nuevo (la pregunta es «no sé dónde ponerlo», no «lo que el usuario dice no cuenta»).
4. Actualiza el MOC/índice más cercano después de crear una nota duradera nueva.

Escenario común: Lanzamientos de despliegue y operaciones

Este tipo de lanzamiento (empaquetado, subida, descompresión, copia de configuración, reinicio de contenedor, despliegue separado de frontend y backend) normalmente va bajo 02 Areas/<dominio>/<subtema>/. Cuando no haya un dominio que coincida: informa al usuario de que la ruta histórica ya no existe, pregunta dónde registrar el contenido y luego actúa — no escribas en rutas antiguas de memoria, ni asumas que cierto tipo de proyecto tiene necesariamente un Área correspondiente.

Frase vaga «registra lo que hice esta semana»: No decidas por tu cuenta

Activa tanto la palabra de activación (记一下) como la exclusión (resumen semanal general). Primero pregunta al usuario qué tipo quiere: informe semanal → PKB (references/work-management.md); hechos concretos de lanzamiento de esta semana → esta skill. No escribas ninguna nota antes de la respuesta.

Nota de Lanzamiento Semanal

Cuando la tarea incluya preparación de lanzamiento o cambios relevantes para el lanzamiento, mantén una nota de lanzamiento semanal en la carpeta de proyecto o área más relevante.

Nomenclatura predeterminada:

发版 - <sistema o nombre del proyecto> - YYYY-Www.md

Ejemplos: 01 Projects/<nombre del proyecto>/发版 - <nombre del proyecto> - 2026-W18.md o 02 Areas/<dominio>/<subtema>/发版 - <sistema o nombre del proyecto> - 2026-W18.md.

Usa la numeración de semana ISO a menos que el usuario proporcione una convención de nomenclatura diferente. Si ya existe una nota para la semana actual, actualízala en lugar de crear otra. Explora la carpeta padre antes de escribir; si no existe, pregunta al usuario dónde debe vivir la nota de lanzamiento (igual que arriba: la ruta ya indicada por el usuario en esta interacción es la respuesta).

Plantilla de Nota de Lanzamiento Semanal

Lee references/release-note-template.md y usa su estructura a menos que una nota existente cercana tenga una convención local más fuerte.

Mantén las notas de lanzamiento cortas. Coloca los scripts completos o fragmentos de configuración bajo 04 发布依赖清单, pero evita convertir la nota en un manual detallado a menos que el usuario lo solicite.

Flujo de Trabajo de Actualización

1. Identifica el resultado de la tarea.

   • Resume lo que realmente cambió o se decidió.
   • Separa los hechos concretos de suposiciones, opciones e intentos abandonados.

2. Elige los destinos de la nota.

   • Actualiza primero una nota de proyecto/área/recurso existente cuando ya sea dueña del tema.
   • Crea la nota de lanzamiento semanal solo cuando existan detalles relevantes para el lanzamiento.
   • Actualiza el MOC más cercano cuando se cree una nota duradera nueva.

3. Escribe la actualización duradera más pequeña que siga siendo operativa.

   • Viñetas compactas para registros de trabajo; bloques de comando solo cuando la ejecución futura necesite comandos exactos.
   • Explica flags no obvios, campos de configuración, rutas y supuestos de orden.
   • Registra qué ejecutar, dónde, qué afecta y cómo verificarlo.
   • Incluye explícitamente la validación omitida, más los pasos de respaldo y reversión para las notas de lanzamiento cuando se conozcan.

4. Verifica la integridad de enlaces y estructura.

   • Asegúrate de que las notas nuevas estén enlazadas desde el MOC o la nota padre más cercana.
   • Ejecuta python3 scripts/check_release_note.py <ruta de la nota> — verifica las reglas que esta skill misma establece (formato de nombre de archivo, número de semana ISO, título coherente con el nombre de archivo, frontmatter, esqueleto de secciones de la plantilla, sin duplicados para el mismo sistema y semana, enlazado al MOC, sin valores secretos evidentes). El esqueleto de secciones se lee desde references/release-note-template.md; si la plantilla cambia, esta comprobación se adapta.
   • La verificación de enlaces rotos no es su responsabilidad — eso es tarea del script de PKB a continuación (ambos se complementan, no se superponen).
   • Ejecuta python3 ../obsidian-personal-knowledge-base/scripts/check_links.py --ignore-template después de crear o mover notas; espera un código de salida 0 (detalles en references/structural-checks.md de PKB).
   • Si esta operación ha cambiado la estructura de directorios, el recuento de archivos o el comportamiento de hooks, actualiza la descripción correspondiente en vault-map.md o en el SKILL.md relevante en la misma operación — no lo dejes para que la próxima exploración lo descubra.
   • Evita duplicar las mismas instrucciones de lanzamiento en varios lugares; enlaza de forma cruzada.

5. Informa brevemente — mantén el traspaso corto; el valor está en las notas.

   • Qué notas se crearon o actualizaron.
   • Qué puntos concretos se registraron.
   • Si se creó o actualizó una nota de lanzamiento semanal.
   • Cualquier suposición, validación omitida o detalle de lanzamiento faltante.

Estilo de Escritura

Escribe como una memoria operativa, no un diario:

• directo, factual y fácil de escanear
• chino principalmente, con términos técnicos en inglés cuando son canónicos
• sin lenguaje didáctico como "第一次", "可以先这样理解" o "接下来我们"
• sin resúmenes inflados; prefiere comandos exactos, rutas y restricciones
• sin secretos

Instalación

Instala mediante npx skills add huangrx6/agent-skills desde la raíz del repositorio (consulta el README.md de la raíz).

Instala obsidian-personal-knowledge-base primero — esta skill depende de sus references/vault-map.md y references/writing-conventions.md, y se niega a escribir cuando no están disponibles.