Harness Evolve — 하네스 진화

하네스는 고정물이 아니다. 사용 중 받은 피드백을 원리 수준으로 일반화해 지침에 되먹여, 다음 작업이 더 나은 초안에서 시작되게 한다.

실행 워크플로우

Step 1: 델타 파악

1. .claude/HARNESS_CHANGELOG.md를 읽어 지금까지의 변경 맥락을 파악한다
2. git log --oneline -10 -- .claude/ CLAUDE.md로 최근 하네스 변경을 확인한다 (리뷰 가이드 등 하네스와 짝을 이루는 문서가 따로 있으면 경로를 함께 넣는다)
3. 사용자 피드백이 이미 주어졌다면 그대로 사용하고, 없다면 관찰 신호(같은 지적 반복, 파이프라인 우회 흔적, 스킬 미트리거)를 근거로 개선을 제안한다

Step 2: 수정 대상 매핑

Step 3: 일반화하여 반영

1. 원리 수준으로 일반화한다. 사례 1:1 규칙 추가는 오버피팅이다 — "왜 그 문제가 생겼는가"를 찾아 원인 수준에서 고친다. (예: "이번에 파일 개수가 틀렸다" → 개수를 갱신하는 게 아니라, 썩는 정보인 개수 자체를 지침에서 제거)
2. 이유(Why)를 병기한다. 이유를 알면 엣지 케이스에서도 올바르게 판단할 수 있다.
3. 한 번에 하나씩 적용한다. 몰아서 바꾸면 어떤 변경이 효과였는지 알 수 없다.
4. 퇴행 방지: 이번 수정이 CHANGELOG의 과거 수정을 되돌리는 방향이면, 상충을 알리고 사용자 확인을 받는다. 둘 다 만족하는 기준을 찾는 것이 정답이다.

Step 4: 이력 갱신 및 동기화

1. .claude/HARNESS_CHANGELOG.md에 기록: 날짜 / 변경 내용 / 대상 / 사유(피드백 원문 요지)
2. 같은 기준을 담은 다른 문서(CI의 AI 리뷰 가이드, 팀 위키, README 등)가 있으면 어긋나지 않는지 확인하고 같은 커밋에서 동기화한다 — 기준이 두 곳에 갈라지면 둘 다 신뢰를 잃는다
3. 수정한 스킬의 frontmatter와 파일 간 참조가 유효한지 확인한다

Step 5: 보고

반영한 변경과 일반화 근거, 반영하지 않은 피드백과 그 이유, 다음 작업에서 기대되는 개선을 요약한다.

원칙

• 이력은 자산이다 — CHANGELOG를 지우지 않는다. 쌓일수록 "왜 지금 이 모양인가"의 답이 된다.
• 하네스 수정도 검증 대상이다 — description을 바꿨으면 트리거 시나리오(써야 할 표현 3개 + 쓰면 안 되는 유사 표현 3개)를 점검한다.