/harness

name: harness
description: "프로젝트에 맞는 하네스를 설계하고, 전문 에이전트와 각 에이전트가 사용할 스킬을 만든다. 사용자가 '하네스 구성해줘', '하네스 구축해줘', '하네스 설계', '하네스 엔지니어링', '에이전트 팀 만들어줘'라고 요청할 때 사용한다. 새로운 분야나 프로젝트의 자동화 체계를 구축하거나 기존 하네스를 재구성·확장할 때도 사용한다. '하네스 점검', '하네스 감사', '하네스 현황', '에이전트/스킬 동기화'처럼 기존 하네스를 운영하거나 유지 보수하는 요청에도 사용한다. 실행 결과를 회고하고 피드백을 반영하는 작업에는 harness:evolve 스킬을 사용한다."

Harness v2 — 에이전트 팀과 스킬 설계

프로젝트에 맞는 하네스를 설계한다. 각 에이전트의 역할을 정의하고, 에이전트가 작업할 때 따를 스킬을 만든다.

핵심 원칙

1. 에이전트 정의는 `프로젝트/.claude/agents/`에, 스킬은 `프로젝트/.claude/skills/`에 만든다. 에이전트에는 누가 일하는지를, 스킬에는 그 일을 어떻게 하는지를 적는다. 2. 작업 흐름에 따라 실행 모드를 고른다. 순서와 반복 조건을 코드로 정할 수 있으면 워크플로로 조율한다. 같은 전문가와 피드백을 주고받아야 하면 지속형 에이전트를 쓴다. 결과를 한 번만 받으면 되는 작업은 서브에이전트에 맡긴다. 자세한 선택 기준은 2단계에서 다룬다. 3. 업무의 복잡도, 작업 기간, 자율성, 응답 속도에 맞춰 모델을 고른다. 계획을 세워 장기간 자율적으로 실행해야 하는 최고 난도 업무에는 fable, 설계·코드 생성·복잡한 분석·교차 검증에는 opus, 로그 분석·형식 변환·단순 수집 같은 일상 업무에는 sonnet을 쓴다. 자세한 기준은 3단계에서 다룬다. 4. 새 세션에서도 오케스트레이터 스킬을 불러올 수 있도록 `CLAUDE.md`에 호출 조건과 변경 이력만 기록한다. 5. 실행 결과에서 배운 내용을 에이전트·스킬·`CLAUDE.md`에 계속 반영한다. 회고하고 변경 사항을 찾아내는 작업은 `harness:evolve` 스킬이 맡는다. 6. 생성하는 에이전트 정의, 스킬, 오케스트레이터, `CLAUDE.md` 기록은 사용자가 대화에 쓰는 언어로 작성한다. 이 스킬 문서와 `references/`의 템플릿이 한국어로 쓰였다는 이유로 산출물을 한국어로 쓰지 않는다. 템플릿의 제목과 예시 문구도 그 언어로 옮긴다. 사용자가 언어를 따로 정하면 그 언어를 따르고, 따로 정하지 않은 채 기존 하네스를 확장하면 기존 파일의 언어를 따른다.

진행 절차

0단계: 현재 상태 점검

하네스 스킬을 불러오면 기존 구성을 먼저 확인한다.

1. `프로젝트/.claude/agents/`, `프로젝트/.claude/skills/`, `프로젝트/CLAUDE.md`를 읽는다. 2. 현재 상태에 따라 진행할 절차를 고른다.

• **새로 구축**: 에이전트나 스킬 디렉터리가 없거나 비어 있으면 1단계부터 모두 실행한다.
• **기존 구성 확장**: 기존 하네스에 에이전트나 스킬을 추가해야 하면 아래 표에서 필요한 단계만 실행한다.
• **운영·유지 보수**: 기존 하네스를 점검·수정·동기화해야 하면 7단계의 운영 절차로 이동한다.

| 변경 내용 | 1단계 | 2단계 | 3단계 | 4단계 | 5단계 | 6단계 | | --- | --- | --- | --- | --- | --- | --- | | 에이전트 추가 | 생략하고 0단계 결과 사용 | 어떤 실행 모드에서 어느 팀과 단계에 둘지만 결정 | 필수 | 전용 스킬이 필요할 때 | 오케스트레이터 수정 | 필수 | | 스킬 추가·수정 | 생략 | 생략 | 생략 | 필수 | 연결이 바뀔 때 | 필수 | | 구조·실행 모드 변경 | 생략 | 필수 | 영향을 받는 에이전트만 | 영향을 받는 스킬만 | 필수 | 필수 |

3. 기존 오케스트레이터에 `TeamCreate`, `TeamDelete`, `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`가 있으면 v1 산출물이다. 현재 실행 환경에서는 작동하지 않으므로 v2로 옮기자고 제안한다. 자세한 방법은 `references/execution-modes.md`의 「v1에서 v2로 전환」을 따른다. 4. 실제 에이전트·스킬 목록과 `CLAUDE.md` 기록을 대조해 불일치를 찾는다. 5. 점검 결과와 실행 계획을 사용자에게 알리고 확인받는다.

1단계: 분야와 작업 분석

1. 사용자 요청에서 프로젝트의 분야와 목표를 파악한다. 2. 생성, 검증, 편집, 분석처럼 필요한 작업의 종류를 나눈다. 3. 실행 모드를 고를 수 있도록 작업 흐름을 확인한다.

• 처리할 목록을 미리 나열할 수 있는가? 예: 파일 N개를 옮기거나 관점 M개를 검토하는 작업
• 산출물을 검증하고 다시 고치는 반복 절차가 필요한가?
• 에이전트가 서로 의견을 주고받아야 결과가 좋아지는가?
• 한 세션 안에서 같은 전문가와 계속 대화해야 하는가?

4. 0단계에서 확인한 기존 에이전트·스킬과 겹치거나 충돌하는 부분을 찾는다. 5. 코드베이스를 살펴 기술 스택, 데이터 모델, 주요 모듈을 파악한다. 6. 사용자가 쓰는 용어와 질문 수준을 보고 설명의 난이도를 맞춘다. 코딩 경험이 적은 사용자에게 검증 조건(assertion), JSON 스키마(JSON Schema) 같은 용어를 설명 없이 쓰지 않는다.

2단계: 실행 모드와 팀 구조 설계

2-1. 실행 모드 선택

Harness v2는 Claude Code의 멀티에이전트 기능 세 가지를 사용한다. 작업 흐름에 맞춰 다음 모드 가운데 하나를 고른다.

| 실행 모드 | 사용하는 기능 | 알맞은 작업 | | --- | --- | --- | | **워크플로 조율** | `Workflow` 스크립트의 `agent()`, `pipeline()`, `parallel()`, `phase()` | 처리 목록, 검증 절차, 반복 횟수를 코드로 정할 수 있는 작업. 스키마에 맞춘 결과가 필요하거나 `Agent`를 수십 번 이상 호출해야 하는 작업 | | **지속형 에이전트 협업** | `Agent(name:)`, `SendMessage`, `TaskCreate`, `TaskUpdate` | 이름 있는 전문가가 대화 맥락을 유지하면서 피드백·협상·공동 편집을 반복해야 하는 작업 | | **서브에이전트 위임** | `Agent` 한 번 호출. 기본적으로 백그라운드에서 실행하며 병렬 호출 가능 | 에이전트끼리 대화할 필요가 없고 결과만 한 번 받으면 되는 작업 |

다음 순서로 결정한다.

1. 처리 목록, 검증 기준, 반복 조건을 미리 코드로 표현할 수 있으면 워크플로를 사용한다. 정해진 흐름을 모델의 그때그때 판단에 맡기지 않아야 같은 방식으로 다시 실행할 수 있다. 2. 코드로 정하기 어렵고, 에이전트끼리 대화하거나 이전 맥락을 기억해야 하면 지속형 에이전트를 사용한다. 3. 두 조건에 해당하지 않고 결과만 필요하면 서브에이전트에 맡긴다. 4. 단계마다 작업 성격이 다르면 혼합 모드로 구성한다. 오케스트레이터에 각 단계의 실행 모드를 적는다.

`Workflow` 도구를 쓰려면 사용자가 명시적으로 동의해야 한다. 사용자가 직접 워크플로 실행을 요청했거나, `Workflow` 호출을 지시하는 오케스트레이터 스킬을 사용자가 불러왔다면 동의한 것으로 본다. 기본 실행은 에이전트 몇 명으로 제한하고, 사용자가 "철저히", "전수"처럼 넓은 조사를 요구했을 때만 대규모로 늘린다.

> 실행 모드 비교와 동시 실행 상한, 스키마, 토큰 예산, 재개 조건은 `references/execution-modes.md`에서 확인한다.

2-2. 팀 구성 방식 선택

1. 작업을 전문 분야별로 나눈다. 2. 아래 여섯 가지 방식 가운데 작업에 맞는 구성을 고른다. 자세한 기준은 `references/team-patterns.md`에 있다.

• **파이프라인**: 앞 단계의 결과를 받아 순서대로 처리한다. `pipeline()`에 알맞다.
• **분산·통합(팬아웃/팬인)**: 독립 작업을 병렬로 처리한 뒤 결과를 합친다. `pipeline()`과 필요할 때만 `parallel()`을 쓴다.
• **전문가 풀**: 입력에 맞는 전문가만 골라 호출한다. 서브에이전트나 지속형 에이전트에 알맞다.
• **생성·검증**: 한 에이전트가 만들고 다른 에이전트가 검토한다. 워크플로의 적대적 검증이나 지속형 에이전트 한 쌍을 쓴다.
• **감독자**: 중앙 에이전트가 진행 상황을 보고 작업을 다시 배분한다. 지속형 에이전트와 공유 작업 목록을 쓴다.
• **계층형 위임**: 상위 에이전트가 하위 에이전트에 다시 맡긴다. 두 단계 안에서만 사용하고, 워크플로 중첩은 한 단계로 제한한다.

3. 산출물의 정확성이 중요하면 다음 검증 방식을 조합한다.

• **적대적 검증**: 찾은 항목 한 건마다 N명의 적대적 검증 에이전트를 붙이고, 과반이 근거가 충분하다고 `confirmed`로 판정한 항목만 통과시킨다. `refuted`나 `uncertain` 판정은 통과로 세지 않는다.
• **심사위원단**: N개의 시안을 따로 만든 뒤 병렬로 심사하고, 가장 좋은 시안을 바탕으로 최종본을 만든다.
• **새 항목이 없을 때까지 반복(Loop-until-dry)**: 새로 찾은 항목이 K회 연속 0건이 될 때까지 탐색한다.
• **여러 기준으로 탐색**: 컨테이너, 내용, 개체, 시간처럼 서로 다른 기준으로 병렬 조사한다.
• **누락 검토자**: 마지막 에이전트에는 빠진 내용만 찾게 한다.

2-3. 에이전트를 나누는 기준

필요한 전문 지식, 병렬 처리 가능 여부, 유지해야 할 대화 맥락, 다시 쓸 가능성을 기준으로 에이전트를 나눈다. 자세한 표는 `references/team-patterns.md`의 「에이전트 분리 기준」에서 확인한다.

3단계: 에이전트 정의 작성

여러 세션에서 재사용할 전문 에이전트는 `프로젝트/.claude/agents/{name}.md` 파일로 정의한다. 반복해서 사용할 역할을 `Agent` 도구의 `prompt`에만 직접 넣지 않는다.

• 파일로 정의해야 다음 세션에서도 재사용할 수 있다. `Agent` 도구에서는 `subagent_type: "{name}"`, `Workflow`에서는 `agentType: "{name}"`으로 부른다.
• 에이전트가 주고받을 내용을 미리 정해야 협업 결과가 안정적이다.
• 에이전트에는 누가 일하는지를, 스킬에는 그 일을 어떻게 하는지를 적어 서로 섞이지 않게 한다.

재사용할 전문가 역할은 사용자 정의 유형으로 파일에 만들고, 호출할 때 그 파일의 이름을 `subagent_type`이나 `agentType`에 지정한다. `general-purpose`, `Explore`, `Plan` 같은 기본 제공 유형을 그대로 쓰는 단발 작업에는 별도 정의 파일을 만들지 않는다.

기존 에이전트와 겹치는지 확인

새 에이전트 파일을 만들기 전에 `프로젝트/.claude/agents/`의 기존 에이전트와 역할이 겹치는지 확인한다. 1단계를 생략하고 에이전트만 추가할 때도 이 확인은 건너뛰지 않는다. 하네스를 여러 번 구축하거나 확장하면 같은 역할의 에이전트가 이름만 달리해 쌓일 수 있기 때문이다. 겹치면 새 이름으로 만들지 말고 기존 에이전트를 그대로 쓰거나 확장한다. 판단 기준과 예외(도메인을 의도적으로 특화한 경우)는 `references/team-patterns.md`의 「에이전트 재사용 설계」에서 확인한다.

모델 선택 기준

업무의 복잡도, 작업 기간, 자율성, 응답 속도를 기준으로 에이전트마다 모델을 고른다. YAML 프론트매터(머리말)의 `model:`이나 호출 인자인 `model`, `opts.model`에 지정하고, 선택 이유를 에이전트 정의나 오케스트레이터에 주석으로 남긴다.

| 모델 | 선택 기준 | 대표 업무 | | --- | --- | --- | | **fable** | 스스로 계획하고 여러 단계를 연결해 장기간