---
name: agent-meeting
description: "Agent 미팅 진행: 여러 페르소나를 소집해 의견 수집 → 합의 → 기록"
triggers:
  - "agent 미팅"
  - "Agent 미팅"
  - "페르소나 소집"
  - "미팅 소집"
  - "보리스 사이클"
  - "어노테이션 사이클"
usage: "/agent-meeting <주제> [--mode sequential|independent|hybrid] [--depth concise|thorough]"
---

# Agent 미팅 스킬

> 이 스킬은 아누(개발실장)가 여러 페르소나를 소집해 전문 의견을 수집하고, 보리스 워크플로우(Annotation Cycle)를 통해 합의에 도달한 뒤, 결과를 3문서에 반영하는 전체 절차를 정의한다.

---

## 1. 미팅 전 준비

아누는 미팅 소집 전에 반드시 다음을 완료해야 한다.

1. **안건 명확화**: 미팅 주제를 한 문장으로 정의한다. 모호한 주제로 소집 금지.
2. **리서치 선행 확인**: `memory/research/` 디렉토리를 확인한다. 충분히 조사되지 않은 상태에서 미팅 소집 금지. (아누 가이드 Section 2.4)
3. **필요 페르소나 선택**: 안건과 직접 관련된 전문성을 가진 페르소나만 소집. 모든 페르소나 일괄 소집 금지.
4. **조직도 참조**: `/home/jay/workspace/memory/organization-structure.json`

**금지**: 아누가 충분히 파악하지 않은 상태에서 미팅을 소집하는 것은 시간 낭비이며 환각 위험을 높인다.

---

## 1.5 미팅 파라미터 설정

모든 파라미터는 선택적이다. 지정하지 않으면 기본값으로 동작하며, 기존 호출(`/agent-meeting <주제>`)과 완전히 호환된다.

### 미팅 모드 (`--mode`)

페르소나 간 의견 전달 방식을 결정한다.

- **`independent`**: 각 페르소나에게 원본 질문만 전달하여 독립적으로 의견 수집. 이전 의견을 제공하지 않음. 그룹싱크(Groupthink) 방지에 최적.
- **`sequential`**: 페르소나를 순서대로 실행하며, 이전 페르소나의 의견을 "이전 의견:" 섹션으로 다음 페르소나에게 전달. 점진적 심화에 최적. 앵커링 효과 주의.
- **`hybrid`** (기본값): 1차 라운드 independent(다양성 확보) → 결과 취합 → 2차 라운드부터 sequential(심화). 다양성과 심화를 모두 달성.

**기본값**: `hybrid`

**모드별 실행 방식:**

```
independent:
  모든 라운드에서 Task tool 병렬 소집
  → 각 페르소나: 원본 질문만 수신 (이전 의견 차단)
  → 결과 취합

sequential:
  1명씩 순차 실행
  → 1번 페르소나: 원본 질문 수신 → 의견 제출
  → 2번 페르소나: 원본 질문 + "이전 의견:" 섹션으로 1번 의견 수신 → 의견 제출
  → 3번 페르소나: 원본 질문 + "이전 의견:" 섹션으로 1~2번 의견 수신 → 의견 제출
  → ... 순서 권장: 일반론 → 전문 → 비판 → 종합

hybrid (기본값):
  [라운드 1] independent — Task tool 병렬 소집
  → 각 페르소나: 원본 질문만 수신 (이전 의견 차단)
  → 결과 취합 → "라운드 1 종합"으로 정리
  [라운드 2+] sequential — 순차 실행
  → 각 페르소나: 원본 질문 + "이전 라운드 종합:" + 이전 페르소나 의견 수신
  → 점진적 심화
```

### 토론 깊이 (`--depth`)

페르소나의 답변 깊이를 조절한다.

- **`concise`**: 페르소나 프롬프트에 다음 지시를 추가한다:
  > "핵심 포인트 2-3개만 간결하게 답변하세요. 불필요한 배경 설명은 생략하고, 결론과 근거만 제시하세요."
  - Lv.1-2 작업에 적합 (비용/시간 절약)
  - DA와 비관습적 대안은 **선택적** (Lv.2에서 팀 판단)

- **`thorough`** (기본값): 페르소나 프롬프트에 다음 지시를 추가한다:
  > "종합적으로 추론하세요. Devil's Advocate 관점을 포함하고, 비관습적 대안도 반드시 제시하세요. 근거와 엣지 케이스를 빠짐없이 다루세요."
  - Lv.3-4 작업에 적합 (품질 우선)
  - DA와 비관습적 대안은 **필수** (Lv.3-4 기존 규칙 유지)

**기본값 결정 우선순위** (높은 것이 우선):
1. 명시적 `--depth` 지정 → 지정된 값 사용 (오버라이드)
2. 작업 레벨 자동 연동 → Lv.1-2: `concise`, Lv.3-4: `thorough`
3. 작업 레벨 정보 없음 → `thorough` (fallback 기본값)

---

## 2. 페르소나 소집 가이드

### 페르소나 목록

개발 관련 미팅 시 안건과 직접 관련된 전문성을 가진 페르소나만 소집한다.
모든 페르소나 일괄 소집 금지.

#### 개발 관련 페르소나

| 페르소나 | 팀 | 전문성 관점 |
|---------|-----|-----------|
| 토르 (Thor) | 개발2팀 / 백엔드 | 고성능 서버, 비동기, 실시간 데이터 |
| 불칸 (Vulcan) | 개발1팀 / 백엔드 | API 설계, 안정성, 에러 핸들링 |
| 프레이야 (Freya) | 개발2팀 / 프론트 | 인터랙티브 UI, 마이크로 인터랙션 |
| 이리스 (Iris) | 개발1팀 / 프론트 | 컴포넌트 설계, React, 접근성 |
| 미미르 (Mimir) | 개발2팀 / UX | 데이터 기반 UX, 정보 아키텍처 |
| 아테나 (Athena) | 개발1팀 / UX | 유저 플로우, 사용자 시나리오 |
| 헤임달 (Heimdall) | 개발2팀 / 테스트 | 보안 중심 QA, 인증 플로우 |
| 아르고스 (Argos) | 개발1팀 / 테스트 | 엣지 케이스, 리그레션 |
| 로키 (Loki) | 레드팀 | 보안 취약점, 해커 마인드 |
| 야누스 (Janus) | DevOps 센터 | 인프라, 배포, CI/CD |
| 마아트 (Ma'at) | QC 센터 | 독립 품질 검증 |
| 비너스 (Venus) | 디자인 센터 | 디자인 방향성, Gemini 관점 세컨드 오피니언 |
| 오딘 (Odin) | 개발2팀장 | 아키텍처, 기술 부채, 장기 관점 |
| 헤르메스 (Hermes) | 개발1팀장 | 풀스택, 태스크 분해, 실행 계획 |

#### 소집 방식

Task tool을 활용하여 여러 페르소나를 **병렬** 소집 (독립적 의견 수집).
페르소나 간 의견이 오염되지 않도록 각자 독립적으로 질문한다.

#### 조직도 전체 참조

`/home/jay/workspace/memory/organization-structure.json`

### 필수 참석자 (예외 없음)
- **로키 (Loki)** — 레드팀, Opus 모델 고정
  - 모든 Agent 미팅에 무조건 참석
  - critical/security 레벨 작업에서는 DA 역할 우선 배정
  - 보안 취약점, 해커 마인드 관점 검증

소집 방식: 미팅 모드(`--mode`)에 따라 달라진다.

- **`independent` / `hybrid` 1차 라운드**: Task tool로 병렬 소집 (독립적 의견 수집). 각 페르소나에게 이전 의견을 전달하지 않는다.
- **`sequential` / `hybrid` 2차+ 라운드**: Task tool로 순차 소집. 이전 페르소나의 의견을 "이전 의견:" 섹션에 포함하여 전달한다.

### 질문 템플릿

#### 기본 템플릿

```
[페르소나명]에게 묻기:
"[안건]에 대해 [페르소나 전문성] 관점에서 의견을 주세요.
특히 [구체적 질문 포인트]에 초점을 맞춰 주세요."
```

#### 예시

```
토르에게 묻기:
"실시간 알림 시스템 도입에 대해 고성능 서버/비동기 처리 관점에서 의견을 주세요.
특히 WebSocket vs SSE 선택과 Redis 연동 방식에 초점을 맞춰 주세요."
```

#### Devil's Advocate 질문 템플릿 (Lv.3~4 필수)

매 사이클마다 소집된 페르소나 중 1명을 **그 사이클의 devil's advocate로 지정**한다.
지정은 돌아가며 순환. 같은 사람이 연속 2회 지정 금지.

```
[페르소나명]에게 Devil's Advocate로 묻기:
"당신은 이번 사이클의 devil's advocate입니다.
지금까지 논의된 [합의안/설계안]에 대해 의도적으로 반대 입장에서 답해주세요.

반드시 아래 3가지 질문에 답하세요:
1. 이 설계가 실패하는 가장 현실적인 시나리오는?
2. 6개월 후 이 결정을 후회할 이유가 있다면?
3. 우리가 놓치고 있는 더 단순한 대안은?

찬성 금지. 문제를 찾아야 합니다."
```

#### Devil's Advocate 규칙
- **Lv.3~4 미팅에서 필수 발동** (Lv.2는 아누 판단으로 선택적)
- devil's advocate가 제기한 문제에 **납득할 만한 반박**이 나와야 합의 성립
- 반박 없이 "괜찮을 것 같다"로 넘기기 금지 → 다음 사이클에서 재논의
- devil's advocate의 우려가 타당하면 설계 수정 후 다음 사이클 진행

### Sequential 모드 질문 전달 형식

Sequential 또는 Hybrid 2차+ 라운드에서 이전 의견을 전달할 때 아래 형식을 사용한다:

```
[페르소나명]에게 묻기:
"[안건]에 대해 [페르소나 전문성] 관점에서 의견을 주세요.
특히 [구체적 질문 포인트]에 초점을 맞춰 주세요.

---
이전 의견:
[페르소나A]: [의견 요약]
[페르소나B]: [의견 요약]
---
위 의견들을 참고하되, 동의할 필요는 없습니다. 부족한 점이나 다른 관점이 있으면 자유롭게 제시하세요."
```

### Depth별 질문 접두 지시

페르소나에게 질문할 때, depth에 따라 아래 지시를 질문 앞에 추가한다:

- **`concise`**: "핵심 포인트 2-3개만 간결하게 답변하세요. 불필요한 배경 설명은 생략하고, 결론과 근거만 제시하세요."
- **`thorough`**: "종합적으로 추론하세요. Devil's Advocate 관점을 포함하고, 비관습적 대안도 반드시 제시하세요. 근거와 엣지 케이스를 빠짐없이 다루세요."

---

## 3. 보리스 워크플로우 (Annotation Cycle)

아누 가이드 Section 2.2의 핵심 반복 구조. 미팅 모드(`--mode`)와 토론 깊이(`--depth`)에 따라 실행 방식이 달라진다.

### 모드별 사이클 실행

```
[independent 모드]
Cycle 1~N:
  → 아누: 분석 + 고민 정리 (환각 방지: 근거 인용 필수)
  → 페르소나들: Task tool 병렬 소집 → 각자 독립적 의견 (이전 의견 차단)
  → 아누: 의견 통합

[sequential 모드]
Cycle 1~N:
  → 아누: 분석 + 고민 정리
  → 페르소나들: 순차 실행 (1명씩, 이전 의견 누적 전달)
    → 페르소나 A: 원본 질문 → 의견
    → 페르소나 B: 원본 질문 + A 의견 → 의견
    → 페르소나 C: 원본 질문 + A,B 의견 → 의견
  → 아누: 의견 통합

[hybrid 모드] (기본값)
Cycle 1:
  → 아누: 1차 분석 + 고민 정리 (환각 방지: 근거 인용 필수)
  → 페르소나들: Task tool 병렬 소집 → 각자 독립적 의견 (Independent)
  → 아누: 의견 통합 + "라운드 1 종합" 정리

Cycle 2+:
  → 핵심 쟁점 재논의 (전 사이클 미해결 항목 중심)
  → 페르소나들: 순차 실행 (Sequential) + "이전 라운드 종합" 전달
  → 아누: 최종 통합

... 최대 6사이클 반복

종료 조건:
  - 더 고민할 게 없을 때 (합의 달성)
  - 6사이클 초과 시 → 강제 종료, 미해결 항목 별도 기록
```

### 깊이별 사이클 운영

- **`concise`**: 각 페르소나의 의견은 핵심 2-3 포인트로 제한. DA와 비관습적 대안은 Lv.2에서 선택적.
- **`thorough`**: 종합적 추론 필수. DA(3.1)와 비관습적 대안(3.2)은 Lv.3-4에서 필수.

**원칙:**
- 아누가 직접 답을 내고 페르소나 의견을 생략하는 것 금지
- 형식적 동의만 수집 금지 — 실제 전문성 기반 의견 필요
- 6사이클 초과 강제 진행 금지

### 3.1 Devil's Advocate (Lv.3~4 필수, Lv.2 선택)

매 사이클 종료 전, 소집된 페르소나 중 1명을 **devil's advocate로 지정**한다.

```
사이클 흐름 (DA 포함):
  → 아누 분석 → 페르소나 의견 수집 → 아누 통합
  → ★ Devil's Advocate 지정 (순환, 연속 2회 금지)
  → DA가 3대 질문에 답변:
    1. 이 설계가 실패하는 가장 현실적인 시나리오는?
    2. 6개월 후 이 결정을 후회할 이유가 있다면?
    3. 우리가 놓치고 있는 더 단순한 대안은?
  → 반박 → 판정 (반박 수용 / 설계 수정)
  → 합의 or 다음 사이클
```

**DA 규칙:**
- DA는 **찬성 금지**. 반드시 문제를 찾아야 함
- DA가 제기한 문제에 **납득할 반박**이 나와야 합의 성립
- 반박 없이 "괜찮을 것 같다"로 넘기기 금지
- DA 질문 템플릿: 섹션 2 "질문 템플릿" 참조
- DA 기록 형식: 섹션 5 "사이클별 기록 형식" 참조
- 작업 레벨 시스템: `memory/specs/work-level-system.md` 참조

### 3.2 비관습적 대안 의무 (Unconventional Alternative Mandate) (Lv.3~4 필수, Lv.2 선택)

> creativity-sampler의 핵심 아이디어를 차용: 탐색 공간을 의도적으로 넓혀, 확률이 낮지만 가치 있는 방향을 놓치지 않는다.

**DA와의 관계:**
- Devil's Advocate(3.1)가 "기존 결론의 약점을 공격"하는 역할이라면,
- 비관습적 대안은 "전혀 다른 방향의 가능성을 탐색"하는 역할이다.
- 둘은 상호 보완적이며, 같은 사이클 내에서 병행 적용한다.

**의무:**

매 사이클에서, 소집된 페르소나 중 1명은 반드시 **비관습적/비직관적 대안 1개**를 제시해야 한다.

```
비관습적 대안 조건:
  - 현장에서 즉시 채택 확률 < 10% 수준의 비전형적 접근법
  - 품질이 낮은 것이 아니라, 탐색 가치가 높은 것
  - "왜 이 방향을 아무도 안 가나?"에 답할 수 있어야 함
  - 기존 결론의 연장선이 아닌, 다른 축(기술, 구조, 방법론, 비즈니스 모델 등)에서 출발
```

**각 비관습적 대안에 대해 반드시 평가해야 할 5개 항목:**

1. **최강 지지 논거**: 이 대안이 옳다면 그 이유는 무엇인가? (가장 강력한 근거 1개)
2. **최강 반론**: 이 대안의 가장 치명적인 약점은 무엇인가?
3. **이상적 사용 시나리오**: 어떤 조건이 충족될 때 이 대안이 정답이 되는가?
4. **노력 수준**: 구현/적용에 필요한 리소스 (낮음 / 중간 / 높음 / 매우 높음)
5. **리스크 등급**: 채택 시 발생 가능한 리스크 (낮음 / 중간 / 높음 / 치명적)

**사이클 흐름 (비관습적 대안 포함):**

```
  → 아누 분석 → 페르소나 의견 수집 → DA 단계 (3.1)
  → ★ 비관습적 대안 제시자 지정 (DA와 같은 사람이어도 무방)
  → 지정된 페르소나: 비관습적 대안 1개 제시 + 5개 항목 평가
  → 나머지 페르소나: 해당 대안의 채택 여부 또는 부분 참조 가능성 판단
  → 아누: 채택 / 기각 / 일부 반영 결정 + 사유 명시
  → 합의 or 다음 사이클
```

**규칙:**
- 비관습적 대안 없이 사이클을 종료하는 것은 **합의 불성립** (Lv.3~4)
- "비관습적인 척"하는 기존 결론의 변형은 인정하지 않음 — 아누가 판정
- 채택되지 않더라도 기각 사유는 반드시 기록 (섹션 5 "사이클별 기록 형식" 참조)
- 비관습적 대안이 DA의 반론에 대한 답이 될 경우, DA 판정 전에 먼저 검토 가능

**적용 범위:**
- Lv.3~4: 필수 (DA와 동일)
- Lv.2: 선택 (팀 판단에 따라 적용)
- Lv.1: 해당 없음

---

## 4. Temporal Interrogation (시간대별 결정사항 선제 해결)

> gstack A5 기법 도입: 구현 시간대별 결정사항을 사전에 식별하여 기획→구현 핸드오프 갭을 제거한다.

### 적용 시점
- Agent 미팅 최종 사이클에서, 합의 도달 후 반드시 실행
- 3문서 정리 직전 단계

### 절차

미팅 합의 후, 아누는 다음 4개 시간대에 대해 **각각 구현 시 부딪힐 결정사항**을 페르소나에게 질문한다:

```
[HOUR 1] 작업 시작 첫 1시간:
- 어떤 파일을 먼저 만져야 하는가?
- 환경 설정/의존성에서 결정할 것은?
- 기존 코드와의 충돌 가능성은?

[HOUR 2-3] 핵심 구현 중반:
- 데이터 구조/API 설계에서 결정할 것은?
- 엣지 케이스 중 지금 결정해야 할 것은?
- 다른 팀/모듈과의 인터페이스 결정 사항은?

[HOUR 4-5] 구현 후반 + 통합:
- 테스트 전략에서 결정할 것은?
- 성능/보안 관련 결정 사항은?
- 기존 테스트와의 호환성 이슈는?

[HOUR 6+] 마무리 + QC:
- 문서화 범위 결정은?
- 배포/머지 전략은?
- 후속 작업 범위 결정은?
```

### 기록 규칙
- 각 시간대에서 식별된 결정사항은 **맥락노트**에 기록
- 미팅에서 해결된 결정 → `[RESOLVED]` 태그
- 구현 중 해결 필요 → `[OPEN]` 태그 + 담당자 지정
- 결정사항 0건은 비현실적 → 최소 3건 이상 식별 필수

### 예시
```
[HOUR 1] 환경 설정
- [RESOLVED] Python 3.11+ 필수 (asyncio 기능 사용)
- [OPEN] config 파일 위치 — 팀장이 결정 (scripts/ vs config/)

[HOUR 2-3] 핵심 구현
- [RESOLVED] JSON 스키마 사용 (Pydantic 모델 기반)
- [OPEN] 외부 API 호출 시 타임아웃 값 — 3초 vs 5초
```

---

## 5. 사이클별 기록 형식

각 사이클마다 아래 형식으로 기록한다.

```markdown
## Cycle N

### 아누 분석
[아누의 분석/정리 — 근거(코드 위치, 문서, 테스트 결과) 인용 포함]

### 페르소나 의견
**[페르소나명]**: [의견 요약 — 전문성 기반, 근거 포함]
**[페르소나명]**: [의견 요약]
...

### Devil's Advocate (Lv.3~4 필수)
**지정**: [이번 사이클 devil's advocate 페르소나명]
1. **실패 시나리오**: [...]
2. **후회 이유**: [...]
3. **더 단순한 대안**: [...]

**반박**: [다른 페르소나 또는 아누의 반박 — 근거 포함]
**판정**: [반박 수용 / 설계 수정 필요]

### 합의/결론
[이번 사이클에서 합의된 내용]

### 미해결 항목
- [다음 사이클로 넘길 쟁점들]
```

**환각 방지 게이트**: 아누 분석의 모든 결정은 근거를 인용해야 한다. 근거 없는 판단 = 환각.

**Devil's Advocate 게이트**: Lv.3~4에서 devil's advocate 단계가 빠진 사이클은 합의 불성립.

---

## 6. 미팅 기록 저장

**경로**: `memory/meetings/YYYY-MM-DD-<주제 kebab-case>.md`

### 미팅 파일 구조 템플릿

날짜는 `currentDate` 컨텍스트 또는 시스템 시각 기준.
주제는 영문 kebab-case로 변환 (예: "실시간 알림 도입" → `realtime-notification`).

```markdown
# Agent 미팅: <주제>

**날짜**: YYYY-MM-DD
**소집 이유**: [왜 이 미팅이 필요한가]
**참여 페르소나**: [목록]
**미팅 모드**: hybrid | sequential | independent
**토론 깊이**: thorough | concise
**총 사이클 수**: N

---

## Cycle 1
[사이클별 기록 형식 — 섹션 5 참조]

## Cycle N
[...]

---

## 최종 합의 사항
[합의된 내용 목록 — 번호 매기기]

## 미해결 항목
[다음 미팅 또는 3문서에 반영할 항목]

## 다음 단계
[합의 결과를 3문서(계획서/맥락노트/체크리스트)에 반영하는 방법]

### 합의 사항 → 3문서 매핑 가이드
- 합의 사항 중 "무엇을 할 것인가" → 계획서(plan.md)의 '목표', '범위/포함'
- 합의 사항 중 "무엇을 하지 않을 것인가" → 계획서의 '범위/제외'
- 합의 사항 중 "왜 이렇게 결정했는가" → 맥락노트(context-notes.md)의 '결정 근거'
- 기각된 대안과 사유 → 맥락노트의 '결정 근거'에 별도 기록
- 합의 사항 중 구체적 실행 항목 → 체크리스트(checklist.md)의 Phase별 항목
- 미해결 항목 → 맥락노트의 '주의사항' + 체크리스트에 [미해결] 태그 항목
- 위임 대상 팀 결정 → 계획서의 '위임 계획'
- 검증 기준 합의 → 계획서의 '검증 기준'
```

**필수 기록 항목**: 미팅 기록 파일의 헤더에 사용된 모드와 깊이를 반드시 기록한다:
```
**미팅 모드**: hybrid | sequential | independent
**토론 깊이**: thorough | concise
```
이 정보는 향후 미팅 효과 추적 및 비용 분석에 사용된다.

---

## 7. 미팅 완료 후 액션

### 7.1 3문서 반영

> **3문서 반영은 선택이 아닌 필수**. 3문서 미작성 시 미팅 기록은 불완전 처리된다.

미팅 결과를 즉시 3문서에 반영:

| 문서 | 반영 내용 |
|------|---------|
| **계획서** | 합의된 설계 결정, 변경된 방향 |
| **맥락노트** | 왜 이 결정을 했는지, 기각된 대안과 사유 |
| **체크리스트** | 합의에서 나온 신규 태스크, 완료된 항목 |

**3문서 적용 조건:**
- 새로운 시스템/프로젝트 설계 = 3문서 **필수**
- 기능 수정/버그 = 3문서 **불필요**

### 7.2 핵미사일 발사 판단
- 충분한 결론이 나왔고 3문서가 정리된 경우 → `/nuclear-approval` 스킬로 제이회장님 승인 요청
- 미해결 항목이 많은 경우 → 다음 사이클 예약 또는 추가 리서치 (`memory/research/` 업데이트)

### 7.3 감사 추적 (Audit Trail)
미팅 기록 저장 후 수정 이력:
```
[아누/Agent미팅] [시각] [memory/meetings/YYYY-MM-DD-<주제>.md] [신규생성] [<안건> 미팅 결과 기록]
```

---

## 8. 금지사항

1. **아누 직접 답변 금지**: 아누가 혼자 결론 내고 페르소나 의견 생략 금지
2. **형식적 동의 금지**: "네, 좋습니다" 수준의 의견 수집 금지. 실제 전문성 기반 의견 필수
3. **6사이클 초과 금지**: 6사이클 후에도 합의 불가 시 강제 종료 + 미해결 항목 기록
4. **리서치 없이 소집 금지**: `memory/research/` 확인 전 미팅 소집 금지
5. **불필요한 페르소나 소집 금지**: 안건과 무관한 페르소나를 형식상 포함하는 것 금지
6. **근거 없는 판단 금지**: 아누 분석에 근거 없는 결정 포함 금지 (환각 방지 게이트)
7. **DA 생략 금지 (Lv.3~4)**: 작업 레벨 3~4에서 DA 단계가 빠진 사이클은 합의 불성립
8. **페르소나 드리프팅 금지 (Anti-Drift)**: 페르소나는 선택된 역할에 commit한다. 소집 시 지정된 전문 영역 밖으로 의견이 흘러가는 것을 금지한다. 예: UX 전문가가 백엔드 아키텍처에 대해 장황하게 의견을 제시하는 것은 드리프팅이다. 아누가 드리프팅을 감지하면 즉시 "역할로 돌아가세요"라고 리다이렉트한다.

---

## 9. 빠른 참조

- **페르소나 목록**: 섹션 2 참조
- **질문 템플릿**: 섹션 2 참조
- **사이클 기록 형식**: 섹션 5 참조
- **미팅 파일 템플릿**: 섹션 6 참조
- **조직도**: `/home/jay/workspace/memory/organization-structure.json`
- **아누 가이드**: `/home/jay/workspace/memory/specs/anu-guide.md` (Section 2.2 핵심)
- **미팅 기록 디렉토리**: `/home/jay/workspace/memory/meetings/`
- **리서치 디렉토리**: `/home/jay/workspace/memory/research/`
- **미팅 기록 예시**: `/home/jay/workspace/memory/meetings/2026-03-02-anu-guide-gap-analysis.md`

---

**스킬 버전**: v1.6
**작성일**: 2026-03-02
**수정일**: 2026-03-07 (Hybrid 미팅 모드 + Discussion Depth 파라미터 추가 — Synode TOP 5 Phase A) 2026-03-15 (gstack A5 Temporal Interrogation + A11 Anti-Drift 추가 — task-566.1) 2026-04-11 (references/ 4개 파일 SKILL.md 인라인 통합 + 로키 필수 참석 규칙 + 3문서 연결 강화 — task-1634.1)
**수정 이력**:
- 2026-03-05: Devil's Advocate 시스템 추가 (제이회장님 지시)
- 2026-03-06: 비관습적 대안 의무 (Unconventional Alternative Mandate) 추가 (미미르)
- 2026-03-07: `--mode` (sequential/independent/hybrid) + `--depth` (concise/thorough) 파라미터 추가 (오딘, task-368.1)
- 2026-03-15: Temporal Interrogation(A5) 시간대별 결정사항 섹션 추가 + Anti-Drift(A11) 페르소나 고정 규칙 추가 (헤르메스, task-566.1)
- 2026-04-11: references/ 4개 파일 SKILL.md 통합 인라인, 로키(레드팀) 필수 참석 규칙 추가, 3문서 반영 필수/적용 조건 강화 (다그다, task-1634.1)
**작성자**: 미미르 (개발2팀 UX/UI 설계자)
**지시자**: 오딘 (개발2팀장)
**참조**: 아누 가이드 v1.1 Section 2.2, 조직도 v2.0, 기존 미팅 기록, creativity-sampler 스킬, Synode 비교분석 (task-344.1)