코딩 에이전트의 설치·실행·검토 규칙을 묶어 제공하는 skill 패키지에 11개 커밋이 들어왔다. 버전 숫자만 보면 작은 업데이트처럼 보인다. 그런데 변경 파일을 세어 보니 README, 리뷰어 정의, 설치 문서, 평가 케이스, 성능 체크리스트, 두 개의 skill까지 모두 7개 경로였고 diff는 +341/-83이었다.
이 숫자가 묘한 이유는 11개 커밋이 기능 11개도, 버그 11개도 아니기 때문이다. 설치 방법을 고친 문서와 코드 리뷰 심각도, 성능 최적화 기준, 작업 흐름의 평가 케이스가 한 릴리스 안에 같이 들어왔다. 릴리스 번호 하나로 묶였을 뿐, 사용자가 밟는 길은 여러 개다.
특히 설치 문서는 설명문으로만 볼 수 없다. 에이전트에게 새 skill을 준다고 해도 복사 위치, loader, 프로젝트 지침이 엇갈리면 본문은 최신이어도 실행기는 옛 규칙을 읽는다. 문서 변경이 실제 실행 경로의 일부가 되는 순간, README의 한 줄도 배포 계약에 들어온다.
평가 케이스와 skill 본문은 더 직접적으로 행동을 바꾼다. 불완전한 계획을 덮어쓰지 말라는 가드, 워크플로 단계가 평가에서 빠지지 않게 하는 coverage 같은 변경은 조용하지만 에이전트가 중간 상태를 다루는 방식을 바꾼다. 이것을 문서 오탈자 수정과 같은 종류로 묶으면 검토 순서부터 틀어진다.
그래서 업데이트를 볼 때는 커밋 수보다 변경 표면을 먼저 나누는 편이 낫다. 설치·실행 경로, 판단 규칙, 평가·회귀, 참고 자료를 따로 표시해야 어떤 변경이 실제 행동을 바꾸는지 보인다. 테스트가 초록이어도 설치 문서가 어긋나면 채택은 실패하고, 문서가 멀쩡해도 평가 케이스가 낡으면 가드는 이름만 남는다.
11개 커밋의 정체는 업데이트 하나가 아니었다. 서로 다른 계약 일곱 개가 동시에 흔들렸는지 확인하는 작은 감사였다. 버전 숫자를 읽는 일은 시작이고, 무엇이 바뀌었는지 분류하는 일이 실제 검토다.