Obsidian 작업 기록 및 릴리스 레코더

Obsidian 작업 기록 및 릴리스 레코더은(는) 무엇을 하나요?

이 스킬은 완료된 작업을 Obsidian 볼트에 영구적인 노트로 변환합니다. 의도적으로 선택적입니다. 목표는 채팅 내용 전체를 보존하는 것이 아니라, 다음 구현, 릴리스, 롤백 또는 인수인계에 도움이 될 소수의 사실만을 유지하는 것입니다.

전제 조건

경로는 설정에서 해석하며, 특정 기계에 종속되지 않습니다 (PKB의 전제 조건과 동일합니다. 여기에 기계별 경로를 작성하지 마십시오):

• 볼트 경로는 $OBSIDIAN_VAULT_PATH 또는 ~/.config/agent-skills/obsidian-vault-path에서 확인합니다. 절대 하드코딩하지 마십시오.
• 경로를 확인하는 표준 방법: python3 ../obsidian-personal-knowledge-base/scripts/vault_path.py --explain
• 기계를 변경하거나 볼트를 옮길 경우 위 두 가지 설정만 변경하면 됩니다. 이 스킬과 PKB 모두 함께 적용됩니다.

필수 시작 체크리스트

볼트에 쓰기 전에 반드시 다음을 수행해야 합니다:

1. obsidian-personal-knowledge-base/references/vault-map.md 로드 — 볼트의 디렉터리 맵과 배치 규칙입니다.
2. obsidian-personal-knowledge-base/references/writing-conventions.md 로드 — 이름 지정, 머리말, 링크, MOC 규칙입니다.
3. 단일 레벨 ls로 대상 영역 조사 (위치 결정 참조) — vault-map.md는 스냅샷일 뿐이며 권위적이지 않습니다. 충돌 시 파일 시스템이 우선합니다.

이는 제안이 아닌 필수 요구 사항입니다. obsidian-personal-knowledge-base가 설치되어 있지 않으면 사용자에게 먼저 설치하라고 알리고 중지하십시오. 볼트 구조에 대한 가정을 바탕으로 기록하지 마십시오. 이 스킬에 대한 볼트 규칙을 포크하지 마십시오 — PKB의 참조가 변경되면 이 스킬도 그 변경 사항을 상속합니다.

범위

병렬 구조를 발명하는 대신 가장 가까운 기존 프로젝트, 영역, 리소스 노트, MOC 또는 템플릿을 재사용하십시오. 주제를 소유한 기존 노트가 없을 경우 obsidian-personal-knowledge-base/references/vault-map.md의 배치 규칙을 따르십시오.

트리거 신호

다음 중 하나 이상이 해당될 때 이 스킬을 사용하십시오:

• 작업이 완료되고 구현 결정, 스크립트, 경로, 설정, 데이터베이스 변경, 환경 변수, 검증 단계, 롤백 단계 또는 릴리스 명령어가 생성되었습니다.
• 사용자가 개인 지식 베이스에 작업을 기록하도록 요청합니다.
• 사용자가 주간 릴리스 노트, 릴리스 체크리스트, 배포 기록 또는 发版文档을 요청합니다.
• 코드, SQL, 설정, 배포 또는 운영 작업 후 프로젝트 또는 영역 노트를 업데이트해야 합니다.
• 반복되는 운영 프로세스가 작업 후 명확해져서 향후 사용을 위해 보관해야 합니다.

일반적인 설명, 브레인스토밍, 추측성 계획, 일회성 채팅 요약 또는 미래 운영 가치가 없는 사소한 편집에 대해서는 트리거하지 마십시오.

요청이 확정된 작업 기록과 기존 노트 편집 또는 구성을 혼합하는 경우 (예: "发版了，帮我整理一下" 또는 "更新一下知识库里某块内容"), 추측하지 말고 행동하기 전에 사용자에게 어떤 것을 원하는지 물어보십시오. 두 의도 모두 정당하며, 사용자만이 어떤 것을 원하는지 알고 있습니다.

기록할 내용

확정된 사항만 기록하십시오. 확정된 사항이란 현재 사실이고, 실행되었으며, 변경되었거나 다른 사람이 따를 준비가 된 것입니다.

좋은 후보:

• 변경된 파일, 모듈, API, 스크립트, SQL 파일, 경로, 서비스 또는 배포 경로
• 릴리스 중에 실행되었거나 실행해야 하는 명령어
• 중요한 설정 키, 환경 변수, 포트, 서버 경로, 컨테이너 이름, 크론 작업 또는 기능 플래그
• 빌드 명령어, 스모크 테스트, API 확인, 스크린샷, 로그 또는 알려진 건너뛴 검증과 같은 검증 증거
• 롤백 또는 백업 단계
• 실행 순서 가정, 종속성, 전제 조건 및 위험
• 향후 작업에 영향을 미치는 지속적인 설계 결정

기록하지 말아야 할 것: 원시 대화; 요약만 중요한데 모든 파일을 터치한 경우; 미래의 실수를 방지하지 않는 한 실패한 실험; 사소한 서식 또는 로컬 전용 노이즈; 비밀, 토큰, 암호 또는 전체 자격 증명; 수락되지 않은 추측성 계획.

세부 사항이 민감해 보이지만 운영상 중요한 경우, 비밀 값이 아닌 변수 또는 설정 이름과 위치를 기록하십시오.

위치 결정

가장 좁은 안정적인 위치를 선택하십시오:

• 완료 기준이 있는 결과 중심 작업은 01 Projects/<project>/에 해당합니다.
• 장기적인 책임, 전달 시스템 또는 운영 지식은 02 Areas/<area>/에 해당합니다.
• 재사용 가능한 기술 지식은 03 Resources/<topic>/에 해당합니다.
• 불명확하거나 불완전한 캡처는 00 Inbox/로 가지만, 안전하게 분류할 수 있는 충분한 컨텍스트가 없는 경우에만 해당합니다.

이 스킬의 경우, 기억이 아닌 탐색을 통해 경로를 결정하십시오.

1. 쓰기 전에 후보 영역을 탐색하십시오 (ls "$VAULT/01 Projects", ls "$VAULT/02 Areas", ls "$VAULT/03 Resources").
2. 주제를 소유한 가장 좁은 기존 디렉터리를 선택하십시오.
3. 의도된 디렉터리가 존재하지 않으면 사용자에게 어디에 생성할지 물어보십시오 — 존재하지 않는 경로에 기록하지 마십시오. 예외: 사용자가 현재 라운드에서 정확한 경로를 지정한 경우 (「放到 02 Areas/05 数据平台/ 下」) → 해당 경로를 사용하고 다시 묻지 마십시오 (질문은 「어디에 둘지 모르겠다」는 것이지 「사용자의 말이 틀렸다」는 것이 아닙니다).
4. 새로운 영구 노트를 생성한 후 가장 가까운 MOC/인덱스를 업데이트하십시오.

일반적인 시나리오: 배포 및 운영 유형 릴리스

이러한 유형의 릴리스 (패키징, 업로드, 압축 해제, 설정 복사, 컨테이너 재시작, 프론트엔드 및 백엔드 개별 릴리스)는 일반적으로 02 Areas/<领域>/<子主题>/에 속합니다. 일치하는 영역이 없는 경우: 사용자에게 이전 경로가 더 이상 존재하지 않음을 알리고, 기록할 위치를 명확히 한 후 작업을 수행하십시오 — 기억 속의 이전 경로에 기록하지 말고, 특정 유형의 프로젝트에 반드시 해당 Area가 있다고 가정하지 마십시오.

모호한 표현 「이번 주에 한 일 기록해줘」: 스스로 판단하지 마십시오

이 표현은 동시에 트리거 단어(记录一下)와 제외 항목(막연한 주간 요약)에 해당합니다. 먼저 사용자에게 어떤 것을 원하는지 물어보십시오: 주간 보고서 → PKB (references/work-management.md); 이번 주에 확정된 릴리스 사실 → 이 스킬. 답변을 받기 전에는 어떤 노트도 작성하지 마십시오.

주간 릴리스 노트

작업에 릴리스 준비 또는 릴리스 관련 변경 사항이 포함된 경우, 가장 관련성이 높은 프로젝트 또는 영역 폴더에 주간 릴리스 노트 하나를 유지 관리하십시오.

기본 명명 규칙:

发版 - <系统或项目名> - YYYY-Www.md

예시: 01 Projects/<项目名>/发版 - <项目名> - 2026-W18.md 또는 02 Areas/<领域>/<子主题>/发版 - <系统或项目名> - 2026-W18.md.

사용자가 다른 릴리스 명명 규칙을 제공하지 않는 한 ISO 주 번호를 사용하십시오. 현재 주에 대한 노트가 이미 존재하면 새로 생성하는 대신 업데이트하십시오. 쓰기 전에 상위 폴더를 탐색하십시오. 존재하지 않으면 사용자에게 릴리스 노트를 어디에 둘지 물어보십시오 (위와 동일: 사용자가 이번 라운드에서 지정한 경로가 답입니다).

주간 릴리스 노트 템플릿

references/release-note-template.md를 읽고 그 구조를 사용하십시오. 단, 가까운 기존 노트에 더 강력한 지역 규칙이 있는 경우는 예외입니다.

릴리스 노트를 간결하게 유지하십시오. 전체 스크립트나 설정 스니펫은 04 发布依赖清单 아래에 두되, 사용자가 운영적 깊이를 요청하지 않는 한 노트를 상세한 런북으로 만들지 마십시오.

업데이트 워크플로우

1. 작업 결과를 식별하십시오.

   • 실제로 변경되거나 결정된 사항을 요약하십시오.
   • 확정된 사실과 추측, 옵션, 포기한 시도를 분리하십시오.

2. 노트 대상을 선택하십시오.

   • 주제를 이미 소유한 기존 프로젝트/영역/리소스 노트가 있으면 먼저 업데이트하십시오.
   • 릴리스 관련 세부 사항이 있는 경우에만 주간 릴리스 노트를 생성하십시오.
   • 새로운 영구 노트가 생성되면 가장 가까운 MOC를 업데이트하십시오.

3. 운영 가능한 가장 작은 영구 업데이트를 작성하십시오.

   • 작업 로그에는 간결한 불릿을 사용하고, 향후 실행에 정확한 명령어가 필요한 경우에만 명령어 블록을 사용하십시오.
   • 명확하지 않은 플래그, 설정 필드, 경로 및 순서 가정을 설명하십시오.
   • 실행할 내용, 위치, 영향, 확인 방법을 기록하십시오.
   • 명시적으로 건너뛴 검증을 포함하고, 알려진 경우 릴리스 노트에 백업 및 롤백 단계를 포함하십시오.

4. 링크 및 구조 무결성을 확인하십시오.

   • 새 노트가 가장 가까운 MOC 또는 상위 노트에서 연결되었는지 확인하십시오.
   • python3 scripts/check_release_note.py <笔记路径> 실행 — 이 스크립트는 이 스킬이 자체적으로 설정한 규칙 (파일 이름 형식, ISO 주 번호, 제목과 파일 이름 일치, 머리말, 템플릿의 챕터 구조, 동일 시스템 및 동일 주 중복 없음, MOC에 연결됨, 명백한 키 값 없음)을 검사합니다. 챕터 구조는 references/release-note-template.md에서 읽어오므로, 템플릿이 변경되면 함께 변경됩니다.
   • 링크 유효성 검사는 이 스크립트의 범위가 아닙니다 — 그것은 아래 PKB 스크립트의 역할입니다 (둘은 상호 보완적이며 중복되지 않습니다).
   • 노트를 생성하거나 이동한 후 python3 ../obsidian-personal-knowledge-base/scripts/check_links.py --ignore-template을 실행하십시오. 종료 코드 0을 예상합니다 (자세한 내용은 PKB의 references/structural-checks.md 참조).
   • 이 작업으로 디렉터리 구조, 파일 수 또는 후크 동작이 변경된 경우 동일한 작업에서 vault-map.md 또는 관련 SKILL.md의 설명을 업데이트하십시오 — 다음 탐색에서 발견되도록 남겨두지 마십시오.
   • 동일한 릴리스 지침을 여러 곳에 중복하여 작성하지 말고, 대신 교차 링크를 사용하십시오.

5. 간략하게 보고하십시오 — 인수인계를 짧게 유지하십시오. 가치는 노트에 있습니다.

   • 생성되거나 업데이트된 노트.
   • 기록된 확정 사항.
   • 주간 릴리스 노트가 생성 또는 업데이트되었는지 여부.
   • 모든 가정, 건너뛴 검증 또는 누락된 릴리스 세부 사항.

작성 스타일

일기가 아닌 운영 메모처럼 작성하십시오:

• 직접적이고 사실적이며 쉽게 훑어볼 수 있도록
• 중국어 우선, 표준적인 영어 기술 용어는 그대로 사용
• "第一次", "可以先这样理解", "接下来我们"와 같은 코칭 언어 사용 금지
• 부풀린 요약 금지; 정확한 명령어, 경로 및 제약 조건 선호
• 비밀 정보 없음

설치

저장소 루트에서 npx skills add huangrx6/agent-skills 명령어로 설치하십시오 (저장소 루트 README.md 참조).

먼저 obsidian-personal-knowledge-base를 설치하십시오 — 이 스킬은 references/vault-map.md와 references/writing-conventions.md에 의존하며, 이들이 없으면 기록을 거부합니다.