llm-wiki/.agents/workflows/branch.md

description

description
새 브랜치 작업 노트를 raw/branch-notes/에 스캐폴딩

사용자가 /branch <브랜치 이름> 를 입력하면 아래 절차를 수행한다.

브랜치 1개 단위의 작업 노트를 생성합니다.

브랜치 이름: <브랜치 이름>

작업 절차

1. 인자 검증

   • 인자가 비어 있으면 사용자에게 브랜치 이름 요청
   • prefix 4종 (feature- / fix- / chore- / experiment-) + 구현 내용 4~8단어 kebab-case 슬러그
   • 상세는 rules/naming-conventions.md §2.1 — 위반은 린터가 생성 시점 차단 (wiki_structure_lint.py NAMING_VIOLATION)

2. 파일 존재 확인

   • raw/branch-notes/<branch-name>.md가 이미 있으면 덮어쓰지 말 것. 기존 경로만 안내하고 종료.

3. 스캐폴딩

   • templates/branch-note-template.md 복사 → raw/branch-notes/<branch-name>.md
   • 템플릿의 ## Decision Evidence Map 과 ## Claims To Verify 섹션을 보존
   • 사용자가 Sources/Claim ID 를 제공했다면 Decision ID 와 Supporting Claims 를 즉시 연결
   • 근거가 아직 없으면 중요한 결정은 UNSUPPORTED_DECISION 으로 남기고 추측해서 채우지 않음
   • frontmatter title, branch, created(오늘 날짜) 치환
   • 본문 # branch: {{branch-name}} 헤더 치환
   • status_label은 in-progress로 기본

4. 오늘 daily 노트 연결 (있다면)

   • raw/daily-notes/YYYY-MM-DD.md 파일이 존재하면, "활성 브랜치" 섹션에 이 브랜치 항목을 추가
   • daily 파일이 없으면 건드리지 않음 (사용자가 /daily 실행할 때 자동 반영하지 않음)

5. 사용자 안내

   • 파일 경로 출력
   • "목표/범위/TODO부터 채워주세요" 안내
   • "/branch-spec <slug> 로 채우세요 (끝에 depth+coverage 자동)" 안내

규칙

• 스캐폴딩만. 내용을 추측해서 채우지 말 것.
• Decision Evidence Map 을 삭제하지 말 것. 비어 있더라도 나중에 Claim ID 를 연결할 구조로 유지.
• 브랜치 머지/종료 후 /ingest raw/branch-notes/<branch-name>.md로 verified 결과를 wiki/projects/에 추출.
• 머지 후에도 branch-note는 raw에 영구 보관 (삭제 X). 면접/회고 시 결정 사항 근거가 됨.
• wiki/log.md는 기록하지 않음 (브랜치 생성은 빈번, 로그가 노이즈).