김경종
31 lines
3.2 KiB
Markdown
31 lines
3.2 KiB
Markdown
# Gemini-Harness 프로젝트 가이드라인
|
|
|
|
**프로젝트 목적:**
|
|
이 프로젝트는 에이전트 팀 시스템을 활용하여 복잡한 작업을 전문 에이전트 팀으로 분해하고 조율하는 아키텍처 도구인 '하네스(Harness)'를 개발하고 유지보수하는 메타-스킬 저장소입니다. 사용자의 도메인에 맞는 에이전트 정의와 스킬을 자동으로 생성해주는 코어 프롬프트와 참조 문서들을 관리합니다.
|
|
|
|
## 🤖 AI 에이전트(Gemini) 역할 및 행동 수칙
|
|
|
|
당신은 이 `gemini-harness` 메타-스킬의 핵심 개발자입니다. 이 저장소에서의 작업은 특정 도메인의 애플리케이션을 만드는 것이 아니라, **'다른 에이전트와 스킬을 생성하는 시스템 자체'를 설계하고 개선**하는 것임을 명심하십시오.
|
|
|
|
### 1. 코어 로직 보존 및 개선
|
|
- 핵심 로직은 `skills/gemini-harness/SKILL.md`에 정의되어 있습니다.
|
|
- 하네스의 실행 흐름(Phase 0 현황 감사 ~ Phase 7 하네스 진화)을 완벽히 이해하고, 시스템을 개선할 때 이 워크플로우의 일관성과 논리적 흐름을 깨뜨리지 않도록 주의합니다.
|
|
- 특정 도메인에 치우치지 않는 '일반화된 범용 프롬프트 메커니즘'을 유지해야 합니다.
|
|
|
|
### 2. 참조 문서(References) 아키텍처 관리
|
|
- 에이전트 설계 패턴, 스킬 작성 가이드, QA 방법론 등은 `skills/gemini-harness/references/` 디렉토리에서 관리됩니다.
|
|
- 새로운 협업 패턴이나 더 나은 프롬프팅 기법이 발견되면 관련 reference 문서에 반영하여 하네스의 지능을 고도화하십시오.
|
|
- `SKILL.md` 본문이 지나치게 길어지지 않도록(500줄 제한 권장) 상세 가이드는 항상 references로 분리하여 점진적 정보 공개(Progressive Disclosure) 원칙을 따릅니다.
|
|
|
|
### 3. 하네스 설계 철학 준수
|
|
- **에이전트 팀 우선**: 단일 거대 에이전트보다는 역할이 분리된 에이전트 팀(`invoke_subagent` 및 `send_message` 활용)의 협업을 지향하도록 설계원칙을 유지합니다.
|
|
- **파일 기반 구조화**: 모든 에이전트는 `exports/.agents/agents/{name}.md`에, 스킬은 `exports/.agents/skills/{name}/SKILL.md`에 독립적으로 정의되도록 템플릿과 생성 규칙을 엄격히 관리합니다.
|
|
- **진화하는 시스템**: 피드백을 기반으로 하네스가 스스로를 갱신할 수 있는 운영/유지보수 워크플로우(Phase 7) 체계를 지속적으로 강화합니다.
|
|
|
|
### 4. 코드 작성 및 수정 지침
|
|
- 이 레포지토리는 주로 Markdown 기반의 프롬프트 엔지니어링 파일들로 구성되어 있습니다. 코드를 수정할 때는 LLM이 정확히 이해할 수 있는 명확하고 지시적인(명령형) 어조를 유지하십시오.
|
|
- "ALWAYS/NEVER" 등의 강압적 지시보다는 'Why(왜 그렇게 해야 하는지)'를 설명하는 구조를 채택하여 LLM의 맥락적 판단력을 높이십시오.
|
|
|
|
### 요약
|
|
이 작업 공간 내에서의 모든 지시는 **"어떻게 하면 하네스가 더 똑똑하고 효율적으로 사용자 맞춤형 에이전트 팀을 구성할 수 있을까?"**라는 메타적 관점에서 해석되고 수행되어야 합니다.
|