Harness를 이해하려면 Claude Code 플러그인이라는 표면 분류보다, 이 저장소가 어디에 놓였는지를 먼저 봐야 한다. README는 스스로를 L3 Meta-Factory의 Team-Architecture Factory라고 규정한다. 즉 어떤 작업을 시키는 개별 에이전트를 만드는 것이 아니라, 어떤 도메인에 어떤 팀 구조가 맞는지부터 선택하는 층위다.
입력은 짧다. 사용자는 프로젝트나 도메인을 한 문장으로 설명한다. 하지만 출력은 단순하지 않다. Harness는 그 설명을 바탕으로 6가지 팀 아키텍처 패턴 가운데 하나를 고른다. Pipeline은 순차 의존 작업에, Fan-out/Fan-in은 병렬 독립 작업에, Expert Pool은 상황별 선택 호출에, Producer-Reviewer는 생성 후 검수에, Supervisor는 중앙 분배에, Hierarchical Delegation은 상하위 재귀 위임에 맞춘다. 핵심은 기능 나열이 아니라, 작업을 어떤 협업 구조로 분해할 것인가를 먼저 설계한다는 점이다.
그 설계는 실제 파일 구조로 이어진다. Harness는 `.claude/agents/`와 `.claude/skills/`를 생성해 에이전트 정의와 스킬 문서를 남긴다. 다시 말해 팀 설계가 말로만 끝나지 않고 실행 자산으로 굳어진다. 여기에 Agent Teams와 Subagents를 구분하는 실행 모드까지 붙는다. 여러 에이전트가 상호작용해야 하면 Agent Teams, 단발성 작업이면 Subagents라는 식으로 구조의 무게를 조절한다.
이 저장소를 더 흥미롭게 만드는 건 마지막 단계다. `/harness:evolve`는 실제 프로젝트에서 초기 설계와 최종 shipped 상태 사이에 생긴 델타를 다시 factory로 되먹인다. 그래서 다음번 비슷한 도메인에 대한 생성은 더 나은 출발점에서 시작한다. 많은 생성 도구가 첫 산출물의 그럴듯함에 머무는 반면, Harness는 팀 설계의 다음 세대를 개선하는 루프를 내장한다.
결국 Harness의 가치는 에이전트를 많이 만드는 데 있지 않다. 도메인 문장 하나를 협업 구조, 파일 산출물, 검증 흐름, 진화 루프로 연결해 재사용 가능한 팀 설계 시스템으로 바꾼다는 데 있다. 그래서 이 repo는 플러그인이라기보다 공장에 가깝다.