Harness Evolve, 하네스 진화 메커니즘

하네스는 고정물이 아니라 진화하는 시스템이다. 이 스킬은 "무엇이 먹혔고 무엇이 안 먹혔는가"의 델타를 포착해 하네스에 되먹여, 다음 실행이 측정 가능하게 더 나아지도록 한다.

초기 하네스 ──▶ 실 프로젝트 사용 ──▶ 현재 하네스
                                        │
                                        ▼ (evolve로 델타 포착)
                                  피드백 일반화 → 에이전트·스킬·오케스트레이터 반영
                                        │
                                        ▼
                                  변경 이력 갱신 → 다음 실행은 더 나은 초안에서 시작

워크플로우

Phase 1: 델타 수집

1. .claude/agents/, .claude/skills/, CLAUDE.md(변경 이력 테이블)를 읽는다
2. git 저장소라면 하네스 파일들의 변경 이력을 조회한다 (git log --oneline -- .claude/ CLAUDE.md), 초기 구성 대비 무엇이 언제 왜 바뀌었는지 파악
3. _workspace/가 있으면 최근 실행의 중간 산출물을 훑어 실제 실행 흔적을 확인한다:
   • 오케스트레이터가 정의한 경로에 산출물이 실제로 있는가 (없으면 워크플로우가 우회되었거나 죽은 코드)
   • 산출물 품질이 스킬이 명시한 형식/기준을 따르는가
4. 사용자에게 피드백을 요청한다 (이미 피드백을 제공했다면 생략):
   • "결과에서 개선할 부분이 있나요?"
   • "에이전트 구성이나 워크플로우에 바꾸고 싶은 점이 있나요?"
   • 피드백이 없으면 강요하지 않는다. 단, 아래 관찰 신호가 있으면 선제적으로 개선을 제안한다

관찰 기반 진화 신호 (피드백이 없어도 제안):

• 같은 유형의 수정 요청이 2회 이상 반복된 흔적
• 에이전트가 반복적으로 실패/재시도한 패턴
• 사용자가 오케스트레이터를 우회해 수동으로 작업한 흔적 (오케스트레이터 트리거 실패 의심 → description 확장 후보)
• 오케스트레이터에 v1 유물(TeamCreate/TeamDelete/실험 플래그)이 남아 있음 → harness 스킬의 마이그레이션 절차 안내

Phase 2: 피드백 유형 분류 및 수정 대상 매핑

피드백 유형	수정 대상	예시
결과물 품질	해당 에이전트의 스킬	"분석이 너무 피상적" → 스킬에 깊이 기준 추가
에이전트 역할	에이전트 정의 .md	"보안 검토도 필요" → harness 스킬로 에이전트 추가 안내
워크플로우 순서	오케스트레이터 스킬	"검증을 먼저 해야" → Phase 순서 변경
팀 구성	오케스트레이터 + 에이전트	"이 둘은 합쳐도 될 듯" → 에이전트 병합
트리거 누락	스킬 description	"이 표현으로 하면 작동 안 함" → description 확장
실행 모드 부적합	오케스트레이터	"매번 같은 팬아웃인데 느려" → 워크플로우 모드 전환
규모/비용	오케스트레이터	"토큰을 너무 써" → 기본 규모 축소, 버짓 연동 추가

범위 판단: 에이전트 신규 추가/삭제나 아키텍처 재설계가 필요하면 이 스킬에서 직접 하지 않고 harness 스킬(0단계의 기존 구성 확장 절차)로 안내한다. evolve는 기존 구성의 조정에 집중한다.

Phase 3: 일반화 및 반영