메뉴
하네스를 구성합니다. 전문 에이전트를 정의하며, 해당 에이전트가 사용할 스킬을 생성하는 메타 스킬. (1) '하네스 구성해줘', '하네스 구축해줘' 요청 시, (2) '하네스 설계', '하네스 엔지니어링' 요청 시, (3) 새로운 도메인/프로젝트에 대한 하네스 기반 자동화 체계를 구축할 때, (4) 하네스 구성을 재구성하거나 확장할 때 사용.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
AI-powered legacy site rebuilding workflow. Captures screenshots, analyzes source code, and generates modern frontend/backend code. Claude Code reads screenshots and writes actual code. Use when rebuilding legacy PHP, WordPress, or similar sites to Next.js, React, or other modern frameworks.
Leader agent role guide for jikime team orchestration. Covers task distribution, plan approval, worker monitoring, and team shutdown. Use when spawned as the leader role in a jikime team.
Reviewer agent role guide for jikime team orchestration. Covers plan review, quality assessment, acceptance criteria validation, and feedback delivery via team inbox. Use when spawned as the reviewer role in a jikime team.
Use this skill when the user asks to "jikime team을 사용해줘", "팀 만들어줘", "에이전트 생성해줘", "멀티 에이전트로 작업해줘", "병렬로 에이전트 실행해줘", "여러 에이전트 조율해줘", "작업을 여러 에이전트에게 분배해줘", "team status 확인해줘", "task 만들어줘", "inbox 확인해줘", or mentions "jikime team", "multi-agent coordination", "spawn agents", "team tasks", "agent inbox", "task board", "team leader", "team worker". Also trigger when the scope of work is large enough to benefit from splitting into parallel subtasks — for example "전체 코드베이스 리팩토링", "여러 기능 동시에 구현", "대규모 분석", "full-stack app 만들어줘". Provides comprehensive guidance for using the jikime team CLI to orchestrate multi-agent teams with task management, messaging, and monitoring.
Claude Code skill for operating as part of a jikime multi-agent team (swarm). Provides command reference, coordination protocols, and role-specific workflows for leader, worker, and reviewer agents. Triggers when the task involves multi-agent coordination, spawning workers, assigning tasks, monitoring team progress, or when the scope exceeds what a single agent can efficiently handle (e.g., "build a full-stack app", "implement multiple features in parallel", "refactor the entire codebase"). Also triggers on keywords: "create a team", "spawn agents", "assign tasks", "team status", "board attach", "agent inbox", "multi-agent", "swarm", "jikime team".
Worker agent role guide for jikime team orchestration. Covers task claiming, execution, plan submission, and completion reporting. Use when spawned as a worker role in a jikime team.
| name | revfactory-harness |
| description | 하네스를 구성합니다. 전문 에이전트를 정의하며, 해당 에이전트가 사용할 스킬을 생성하는 메타 스킬. (1) '하네스 구성해줘', '하네스 구축해줘' 요청 시, (2) '하네스 설계', '하네스 엔지니어링' 요청 시, (3) 새로운 도메인/프로젝트에 대한 하네스 기반 자동화 체계를 구축할 때, (4) 하네스 구성을 재구성하거나 확장할 때 사용. |
도메인/프로젝트에 맞는 하네스를 구성하고, 각 에이전트의 역할을 정의하며, 에이전트가 사용할 스킬을 생성하는 메타 스킬.
핵심 원칙:
.claude/agents/)와 스킬(.claude/skills/)을 생성한다.기본값은 에이전트 팀이다. 2개 이상의 에이전트가 협업할 때는 에이전트 팀을 우선 고려한다. 팀원 간 직접 통신(SendMessage)과 공유 작업 목록(TaskCreate)으로 자체 조율하며, 발견 공유·상충 토론·누락 보완이 결과 품질을 높인다.
서브 에이전트는 에이전트가 1개뿐이거나, 에이전트 간 통신이 불필요한 구조(결과 전달만 필요)일 때 선택한다.
비교표와 의사결정 트리는
references/agent-design-patterns.md의 "실행 모드" 섹션 참조.
references/agent-design-patterns.md 참조)
전문성·병렬성·컨텍스트·재사용성 4축으로 판단한다. 상세 기준표는 references/agent-design-patterns.md의 "에이전트 분리 기준" 참조.
모든 에이전트는 반드시 프로젝트/.claude/agents/{name}.md 파일로 정의한다. 에이전트 정의 파일 없이 Agent 도구의 prompt에 역할을 직접 넣는 것은 금지한다. 이유:
빌트인 타입(general-purpose, Explore, Plan)을 사용하더라도 에이전트 정의 파일은 생성한다. 빌트인 타입은 Agent 도구의 subagent_type 파라미터로 지정하고, 에이전트 정의 파일에는 역할·원칙·프로토콜을 담는다.
모델 설정: 모든 에이전트는 model: "opus"를 사용한다. Agent 도구 호출 시 반드시 model: "opus" 파라미터를 명시한다. 하네스의 품질은 에이전트의 추론 능력에 직결되며, opus가 최고 품질을 보장한다.
팀 재구성: 에이전트 팀은 세션당 한 팀만 활성화할 수 있지만, Phase 간에 팀을 해체하고 새 팀을 구성할 수 있다. 파이프라인 패턴처럼 Phase별로 다른 전문가 조합이 필요하면, 이전 팀의 산출물을 파일로 저장한 뒤 팀을 정리하고 새 팀을 생성한다.
각 에이전트를 프로젝트/.claude/agents/{name}.md에 정의한다. 필수 섹션: 핵심 역할, 작업 원칙, 입력/출력 프로토콜, 에러 핸들링, 협업. 에이전트 팀 모드에서는 ## 팀 통신 프로토콜 섹션을 추가하여 메시지 수신/발신 대상과 작업 요청 범위를 명시한다.
정의 템플릿과 실제 파일 전문은
references/agent-design-patterns.md의 "에이전트 정의 구조" +references/team-examples.md참조.
QA 에이전트 포함 시 필수 사항:
general-purpose 타입을 사용하라 (Explore는 읽기 전용이므로 검증 스크립트 실행 불가)references/qa-agent-guide.md 참조각 에이전트가 사용할 스킬을 프로젝트/.claude/skills/{name}/skill.md에 생성한다. 상세 작성 가이드는 references/skill-writing-guide.md 참조.
skill-name/
├── skill.md (필수)
│ ├── YAML frontmatter (name, description 필수)
│ └── Markdown 본문
└── Bundled Resources (선택)
├── scripts/ - 반복/결정적 작업용 실행 코드
├── references/ - 조건부 로딩하는 참조 문서
└── assets/ - 출력에 사용되는 파일 (템플릿, 이미지 등)
description은 스킬의 유일한 트리거 메커니즘이다. Claude는 트리거를 보수적으로 판단하는 경향이 있으므로, description을 **적극적("pushy")**으로 작성한다.
나쁜 예: "PDF 문서를 처리하는 스킬"
좋은 예: "PDF 파일 읽기, 텍스트/테이블 추출, 병합, 분할, 회전, 워터마크, 암호화, OCR 등 모든 PDF 작업을 수행. .pdf 파일을 언급하거나 PDF 산출물을 요청하면 반드시 이 스킬을 사용할 것."
핵심: 스킬이 하는 일 + 구체적 트리거 상황을 모두 기술하고, 유사하지만 트리거하면 안 되는 경우와 구분되도록 작성.
| 원칙 | 설명 |
|---|---|
| Why를 설명하라 | "ALWAYS/NEVER" 같은 강압적 지시 대신, 왜 그렇게 해야 하는지 이유를 전달한다. LLM은 이유를 이해하면 엣지 케이스에서도 올바르게 판단한다. |
| Lean하게 유지 | 컨텍스트 윈도우는 공공재다. skill.md 본문은 500줄 이내를 목표로, 무게를 벌지 않는 내용은 삭제하거나 references/로 이동한다. |
| 일반화하라 | 특정 예시에만 맞는 좁은 규칙보다, 원리를 설명하여 다양한 입력에 대응할 수 있게 한다. 오버피팅 금지. |
| 반복 코드는 번들링 | 테스트 실행에서 에이전트들이 공통으로 작성하는 스크립트가 발견되면 scripts/에 미리 번들링한다. |
| 명령형으로 작성 | "~한다", "~하라" 형태의 명령형/지시형 어조를 사용한다. |
스킬은 3단계 로딩 시스템으로 컨텍스트를 관리한다:
| 단계 | 로딩 시점 | 크기 목표 |
|---|---|---|
| Metadata (name + description) | 항상 컨텍스트에 존재 | ~100단어 |
| skill.md 본문 | 스킬 트리거 시 | <500줄 |
| references/ | 필요할 때만 | 무제한 (스크립트는 로딩 없이 실행 가능) |
크기 관리 규칙:
cloud-deploy/
├── skill.md (워크플로우 + 선택 가이드)
└── references/
├── aws.md ← AWS 선택 시만 로드
├── gcp.md
└── azure.md
상세 작성 패턴, 예시, 데이터 스키마 표준은
references/skill-writing-guide.md참조.
오케스트레이터는 스킬의 특수한 형태로, 개별 에이전트와 스킬을 하나의 워크플로우로 엮어 팀 전체를 조율한다. Phase 4에서 생성한 개별 스킬이 "각 에이전트가 무엇을 어떻게 하는가"를 정의한다면, 오케스트레이터는 "누가 언제 어떤 순서로 협업하는가"를 정의한다. 구체적 템플릿은 references/orchestrator-template.md 참조.
실행 모드에 따라 오케스트레이터 패턴이 달라진다:
에이전트 팀 모드 (기본):
오케스트레이터가 TeamCreate로 팀을 구성하고, TaskCreate로 작업을 할당한다. 팀원들은 SendMessage로 직접 통신하며 자체 조율한다. 리더(오케스트레이터)는 진행 상황을 모니터링하고 결과를 종합한다.
[오케스트레이터/리더]
├── TeamCreate(team_name, members)
├── TaskCreate(tasks with dependencies)
├── 팀원들이 자체 조율 (SendMessage)
├── 결과 수집 및 종합
└── 팀 정리
서브 에이전트 모드:
오케스트레이터가 Agent 도구로 서브 에이전트를 직접 호출한다. 서브 에이전트는 결과를 메인에게만 반환한다.
[오케스트레이터]
├── Agent(agent-1, run_in_background=true)
├── Agent(agent-2, run_in_background=true)
├── 결과 대기 및 수집
└── 통합 산출물 생성
오케스트레이터 내에 에이전트 간 데이터 전달 방식을 명시한다:
| 전략 | 방식 | 실행 모드 | 적합한 경우 |
|---|---|---|---|
| 메시지 기반 | SendMessage로 팀원 간 직접 통신 | 에이전트 팀 | 실시간 조율, 피드백 교환, 가벼운 상태 전달 |
| 태스크 기반 | TaskCreate/TaskUpdate로 작업 상태 공유 | 에이전트 팀 | 진행상황 추적, 의존 관계 관리, 작업 자체 요청 |
| 파일 기반 | 약속된 경로에 파일을 쓰고 읽음 | 둘 다 | 대용량 데이터, 구조화된 산출물, 감사 추적 필요 |
에이전트 팀 모드에서 권장 조합: 태스크 기반(조율) + 파일 기반(산출물) + 메시지 기반(실시간 소통)
파일 기반 전달 시 규칙:
_workspace/ 폴더를 만들어 중간 산출물 저장{phase}_{agent}_{artifact}.{ext} (예: 01_analyst_requirements.md)_workspace/)은 보존 (사후 검증·감사 추적용)오케스트레이터 내에 에러 처리 방침을 포함한다. 핵심 원칙: 1회 재시도 후 재실패 시 해당 결과 없이 진행(보고서에 누락 명시), 상충 데이터는 삭제하지 않고 출처 병기.
에러 유형별 전략표와 구현 상세는
references/orchestrator-template.md의 "에러 핸들링" 참조.
| 작업 규모 | 권장 팀원 수 | 팀원당 작업 수 |
|---|---|---|
| 소규모 (5~10개 작업) | 2~3명 | 3~5개 |
| 중규모 (10~20개 작업) | 3~5명 | 4~6개 |
| 대규모 (20개+ 작업) | 5~7명 | 4~5개 |
팀원이 많을수록 조율 오버헤드가 커진다. 3명의 집중된 팀원이 5명의 산만한 팀원보다 낫다.
생성된 하네스를 검증한다. 상세 테스트 방법론은 references/skill-testing-guide.md 참조.
생성된 각 스킬에 대해 실제 실행 테스트를 수행한다:
테스트 프롬프트 작성 — 각 스킬에 대해 2~3개의 현실적인 테스트 프롬프트를 작성한다. 실제 사용자가 입력할 법한 구체적이고 자연스러운 문장으로 작성한다.
With-skill vs Without-skill 비교 실행 — 가능하면 스킬 있는 실행과 없는 실행을 병렬로 수행하여 스킬의 부가가치를 확인한다. 서브에이전트를 두 개씩 스폰한다:
결과 평가 — 산출물의 품질을 정성적(사용자 리뷰) + 정량적(assertion 기반) 으로 평가한다. 산출물이 객관적으로 검증 가능한 경우(파일 생성, 데이터 추출 등) assertion을 정의하고, 주관적인 경우(문체, 디자인) 사용자 피드백에 의존한다.
반복 개선 루프 — 테스트 결과에서 문제가 발견되면:
반복 패턴 번들링 — 테스트 실행에서 에이전트들이 공통으로 작성하는 코드(예: 모든 테스트에서 동일한 헬퍼 스크립트를 생성)가 발견되면, 해당 코드를 scripts/에 미리 번들링한다.
각 스킬의 description이 올바르게 트리거되는지 검증한다:
near-miss 작성 핵심: "피보나치 함수 작성" 같이 명백히 무관한 쿼리는 테스트 가치가 없다. "이 엑셀 파일의 차트를 PNG로 추출해줘" (xlsx 스킬 vs 이미지 변환)처럼 경계가 모호한 쿼리가 좋은 테스트 케이스다.
기존 스킬과의 트리거 충돌도 이 단계에서 확인한다.
## 테스트 시나리오 섹션 추가생성 완료 후 확인:
프로젝트/.claude/agents/ — 에이전트 정의 파일 필수 생성 (빌트인 타입이라도 파일 생성 필수)프로젝트/.claude/skills/ — 스킬 파일들 (skill.md + references/)model: "opus" 파라미터 명시.claude/commands/ — 아무것도 생성하지 않음references/agent-design-patterns.mdreferences/team-examples.mdreferences/orchestrator-template.mdreferences/skill-writing-guide.md — 작성 패턴, 예시, 데이터 스키마 표준references/skill-testing-guide.md — 테스트/평가/반복 개선 방법론references/qa-agent-guide.md — 빌드 하네스에 QA 에이전트를 포함할 때 참조. 통합 정합성 검증 방법론, 경계면 버그 패턴, QA 에이전트 정의 템플릿 포함. 실제 프로젝트에서 발견된 7개 버그 사례 기반.