huangrx6/obsidian-work-log-release-recorder

Gravador de Registro de Trabalho e Release do Obsidian

Esta skill transforma trabalho concluído em notas Obsidian duráveis. Ela é intencionalmente seletiva: o objetivo não é preservar a transcrição do chat, mas manter o pequeno conjunto de fatos que ajudarão na próxima implementação, release, rollback ou handoff.

Pré-requisitos

O caminho é resolvido a partir da configuração, não vinculado à máquina local (consistente com os Pré-requisitos do PKB; não escreva nenhum caminho específico de máquina aqui):

• O caminho do vault é resolvido de $OBSIDIAN_VAULT_PATH ou ~/.config/agent-skills/obsidian-vault-path — nunca codifique-o diretamente
• Forma canônica de obter o caminho: python3 ../obsidian-personal-knowledge-base/scripts/vault_path.py --explain
• Trocar de máquina ou mover o vault requer apenas alterar as duas configurações acima; esta skill e o PKB acompanham

Lista de verificação obrigatória para inicialização

Antes de escrever qualquer coisa no vault, você deve:

1. Carregar obsidian-personal-knowledge-base/references/vault-map.md — o mapa de diretórios e convenções de posicionamento do vault.
2. Carregar obsidian-personal-knowledge-base/references/writing-conventions.md — convenções de nomenclatura, frontmatter, links e MOC.
3. Sondar a área alvo com um ls de nível único (consulte Decisão de Localização) — vault-map.md é um instantâneo, não autoritativo; o sistema de arquivos prevalece em caso de conflito.

Estes são requisitos rígidos, não sugestões. Se obsidian-personal-knowledge-base não estiver instalado, informe o usuário para instalá-lo primeiro e pare. Não escreva no vault com base em suposições sobre sua estrutura. Não bifurque as convenções do vault para esta skill — quando as referências do PKB mudarem, esta skill herda a mudança.

Escopo

Reutilize a nota de projeto, área, recurso, MOC ou modelo existente mais próxima, em vez de inventar uma estrutura paralela. Quando nenhuma nota existente cobrir o tópico, siga as regras de posicionamento em obsidian-personal-knowledge-base/references/vault-map.md.

Sinais de Gatilho

Use esta skill quando uma ou mais das seguintes condições forem verdadeiras:

• uma tarefa foi concluída e produziu decisões de implementação, scripts, caminhos, configurações, alterações de banco de dados, variáveis de ambiente, etapas de validação, etapas de rollback ou comandos de release
• o usuário pede para registrar o trabalho no knowledge base pessoal
• o usuário pede uma nota de release semanal, checklist de release, registro de deployment ou documento de lançamento (发版文档)
• uma nota de projeto ou área precisa ser atualizada após trabalho de código, SQL, configuração, deployment ou operações
• um processo operacional recorrente se torna mais claro após uma tarefa e deve ser mantido para uso futuro

Não dispare para explicações comuns, brainstorming, planos especulativos, resumos de chat pontuais ou pequenas edições sem valor operacional futuro.

Se a solicitação misturar o registro de trabalho concluído com a edição ou organização de notas existentes (por exemplo, "lancei a versão, me ajude a organizar" ou "atualize um conteúdo no knowledge base"), pergunte ao usuário qual ele deseja antes de agir em vez de adivinhar. Ambas as intenções são legítimas; apenas o usuário sabe qual é.

O Que Registrar

Registre apenas pontos concretizados. Um ponto concretizado é algo que agora é verdade, foi executado, foi alterado ou está pronto para ser seguido por outra pessoa.

Bons candidatos:

• arquivos, módulos, APIs, scripts, arquivos SQL, rotas, serviços ou caminhos de deployment que mudaram
• comandos que foram executados ou devem ser executados durante o release
• chaves de configuração, variáveis de ambiente, portas, caminhos de servidor, nomes de contêiner, tarefas cron ou flags de recurso que importam
• evidências de validação, como comandos de build, testes de fumaça, verificações de API, capturas de tela, logs ou verificações ignoradas conhecidas
• etapas de rollback ou backup
• suposições de ordem de execução, dependências, pré-condições e riscos
• decisões de design duráveis que afetam o trabalho futuro

Não registre: conversa bruta; todo arquivo tocado quando apenas um resumo importa; experimentos fracassados, a menos que evitem erros futuros; formatação trivial ou ruído local apenas; segredos, tokens, senhas ou credenciais completas; planos especulativos que não foram aceitos.

Se um detalhe parecer sensível, mas operacionalmente importante, registre o nome da variável ou configuração e sua localização, não o valor do segredo.

Decisão de Localização

Escolha o lar estável mais específico:

• Trabalho orientado a resultados com uma linha de chegada vai em 01 Projects/<projecto>/.
• Responsabilidades de longo prazo, sistemas de entrega ou conhecimento operacional vai em 02 Areas/<área>/.
• Conhecimento técnico reutilizável vai em 03 Resources/<tópico>/.
• Captura pouco clara ou incompleta vai em 00 Inbox/, mas apenas quando não houver contexto suficiente para classificar com segurança.

Para esta skill, resolva caminhos sondando, não pela memória.

1. Sondar a área candidata antes de escrever (ls "$VAULT/01 Projects", ls "$VAULT/02 Areas", ls "$VAULT/03 Resources").
2. Escolha o diretório existente mais específico que seja dono do tópico.
3. Se o diretório pretendido não existir, pergunte ao usuário onde criá-lo — não escreva em um caminho inexistente. Exceção: o usuário já especificou o caminho exato nesta rodada ("coloque em 02 Areas/05 数据平台/") → use esse caminho, não pergunte novamente (a pergunta é "não sei onde colocar", não "o que o usuário disse não conta").
4. Atualize o MOC/índice mais próximo após criar uma nova nota durável.

Cenário comum: releases de deploy e operações

Este tipo de release (empacotar, fazer upload, descompactar, copiar configurações, reiniciar contêiner, deploy separado de frontend e backend) geralmente pertence a 02 Areas/<domínio>/<subtópico>/. Quando não houver domínio correspondente: informe ao usuário que o caminho histórico não existe mais, pergunte onde registrar e só então aja — não escreva em caminhos antigos da memória, nem presuma que um certo tipo de projeto sempre tenha uma Área correspondente.

Pedido vago "registre o que fiz esta semana": não decida sozinho

Ele aciona simultaneamente a palavra de gatilho (registrar) e o item de exclusão (resumo genérico da semana). Primeiro pergunte ao usuário qual ele quer: relatório semanal → PKB (references/work-management.md); fatos de release concretizados esta semana → esta skill. Não escreva nenhuma nota antes da resposta.

Nota Semanal de Release

Quando a tarefa incluir preparação de release ou alterações relevantes para release, mantenha uma nota semanal de release na pasta de projeto ou área mais relevante.

Nomenclatura padrão:

发版 - <sistema ou nome do projeto> - YYYY-Www.md

Exemplos: 01 Projects/<nome do projeto>/发版 - <nome do projeto> - 2026-W18.md ou 02 Areas/<domínio>/<subtópico>/发版 - <sistema ou nome do projeto> - 2026-W18.md.

Use numeração de semana ISO, a menos que o usuário forneça uma convenção de nomenclatura diferente para releases. Se uma nota para a semana atual já existir, atualize-a em vez de criar outra. Sonde a pasta pai antes de escrever; se ela não existir, pergunte ao usuário onde a nota de release deve ficar (como acima: o caminho já especificado pelo usuário nesta rodada é a resposta).

Modelo da Nota Semanal de Release

Leia references/release-note-template.md e use sua estrutura, a menos que uma nota existente próxima tenha uma convenção local mais forte.

Mantenha as notas de release curtas. Coloque scripts completos ou trechos de configuração em 04 发布依赖清单, mas evite transformar a nota em um runbook detalhado, a menos que o usuário solicite profundidade operacional.

Fluxo de Trabalho de Atualização

1. Identifique o resultado da tarefa.

   • Resuma o que realmente mudou ou foi decidido.
   • Separe fatos concretizados de palpites, opções e tentativas abandonadas.

2. Escolha os destinos das notas.

   • Atualize uma nota existente de projeto/área/recurso primeiro, quando uma já for dona do tópico.
   • Crie a nota semanal de release apenas quando houver detalhes relevantes para release.
   • Atualize o MOC mais próximo quando uma nova nota durável for criada.

3. Escreva a menor atualização durável que permaneça operacional.

   • Marcadores compactos para registros de trabalho; blocos de comando apenas quando a execução futura precisar de comandos exatos.
   • Explique flags não óbvias, campos de configuração, caminhos e suposições de ordenação.
   • Registre o que executar, onde, o que afeta e como verificar.
   • Inclua validação ignorada explicitamente, além de etapas de backup e rollback para notas de release, quando conhecidas.

4. Verifique a integridade dos links e da estrutura.

   • Garanta que novas notas estejam vinculadas ao MOC ou nota pai mais próximo.
   • Execute python3 scripts/check_release_note.py <caminho da nota> — ele verifica as regras que esta skill estabelece para si mesma (formato do nome do arquivo, número da semana ISO, título consistente com o nome do arquivo, frontmatter, esqueleto de seções do modelo, mesma semana não duplicada para o mesmo sistema, já vinculado ao MOC, sem valores de chave sensíveis). O esqueleto de seções é lido de references/release-note-template.md; se o modelo mudar, ele acompanha.
   • Links quebrados não são de sua responsabilidade — isso é tarefa do script PKB abaixo (eles são complementares, não sobrepostos).
   • Execute python3 ../obsidian-personal-knowledge-base/scripts/check_links.py --ignore-template após criar ou mover notas; espere saída 0 (detalhes em references/structural-checks.md do PKB).
   • Se esta operação alterou a estrutura de diretórios, contagem de arquivos ou comportamento do hook, atualize sua descrição em vault-map.md ou no SKILL.md relevante na mesma operação — não deixe para a próxima sonda descobrir.
   • Evite duplicar as mesmas instruções de release em vários lugares; faça referência cruzada.

5. Relate brevemente — mantenha o handoff curto; o valor está nas notas.

   • Quais notas foram criadas ou atualizadas.
   • Que pontos concretizados foram registrados.
   • Se uma nota semanal de release foi criada ou atualizada.
   • Quaisquer suposições, validação ignorada ou detalhes de release ausentes.

Estilo de Escrita

Escreva como uma memória operacional, não um diário:

• direto, factual e fácil de escanear
• chinês primeiro, com termos técnicos em inglês onde são canônicos
• sem linguagem de coaching como "primeira vez", "pode entender assim por enquanto" ou "a seguir, nós"
• sem resumos inflados; prefira comandos exatos, caminhos e restrições
• sem segredos

Instalação

Instale via npx skills add huangrx6/agent-skills na raiz do repositório (veja o README.md na raiz).

Instale obsidian-personal-knowledge-base primeiro — esta skill depende de suas referências references/vault-map.md e references/writing-conventions.md, e se recusa a escrever quando elas não estão disponíveis.