# Stack-Skills 도입 검토 미팅 기록

- **일시**: 2026-03-06
- **참석자**: 오딘(팀장), 토르(백엔드), 프레이야(프론트엔드), 미미르(UX/UI), 헤임달(테스터)
- **안건**: whynowlab/stack-skills 7개 메타인지 스킬 도입 검토
- **레포지토리**: https://github.com/whynowlab/stack-skills

---

## 1. 스킬별 평가 결과

### 1.1 cross-verified-research (4단계 검증 리서치)

**평가 점수**
- 유용성: 토르 4, 프레이야 3, 미미르 4, 헤임달 4 → **평균 3.75**
- 호환성: 토르 5, 프레이야 4, 미미르 4, 헤임달 3 → **평균 4.0**

**주요 의견**
- 토르: 기존 스킬 중 리서치 전용 파이프라인이 없어 공백을 직접 메움. WebSearch/WebFetch 기반으로 Claude Code 즉시 연결 가능
- 프레이야: BLUF 출력이 Telegram 환경에 적합. 단, "research" 트리거가 기존 `research-prompt`와 충돌 위험
- 미미르: PDP 기획/리스크 단계에서 근거 없는 가정 기반 설계 방지. Lv.3 이상에만 의무 적용 권장
- 헤임달: 검증 매트릭스(Verified/Unverified/Contested)를 QC 판정 포맷에 차용 가능

**합의: 도입 우선순위 높음**
- 도입 방안: 커스터마이징 설치
- 조건: 트리거를 "cross-verify", "교차검증"으로 변경하여 `research-prompt` 충돌 방지
- 적용 범위: 아누 Lv.3 이상 작업에 의무, Lv.1~2는 선택

---

### 1.2 creativity-sampler (5개 확률 가중 옵션)

**평가 점수**
- 유용성: 토르 3, 프레이야 4, 미미르 3, 헤임달 2 → **평균 3.0**
- 호환성: 토르 4, 프레이야 4, 미미르 3, 헤임달 2 → **평균 3.25**

**주요 의견**
- 토르: 에이전트 미팅과 부분 중복. 확률 가중치 + 비관습적 대안 강제 로직만 차용 권장
- 프레이야: 트리거 충돌 없음. agent-meeting 전 "아이디어 정리" 용도로 자연스러운 위치
- 미미르: 비관습적 대안 강제 메커니즘만 추출하여 미팅 어젠다에 내재화 권장
- 헤임달: QC/테스트 직접 효용 낮음. 테스트 케이스 발굴 브레인스토밍 보조 정도

**합의: 도입 우선순위 중간**
- 도입 방안: 아이디어 차용
- "비관습적 대안 1개 의무 포함" 규칙을 에이전트 미팅 어젠다에 내재화
- 전체 스킬 독립 설치보다 핵심 로직만 기존 프로세스에 흡수

---

### 1.3 adversarial-review (3벡터 Devil's Advocate)

**평가 점수**
- 유용성: 토르 5, 프레이야 4, 미미르 5, 헤임달 5 → **평균 4.75**
- 호환성: 토르 5, 프레이야 3, 미미르 5, 헤임달 4 → **평균 4.25**

**주요 의견**
- 토르: 로키 레드팀과 역할 분리 명확 — adversarial-review는 로직/품질, 로키는 보안. 직렬 연결이 최적
- 프레이야: "devil's advocate" 트리거가 agent-meeting DA 시스템과 직접 충돌. 반드시 트리거 리네이밍 필요
- 미미르: 에이전트 미팅이 "발산→수렴"이라면 이 스킬은 "수렴된 결론의 스트레스 테스트"로 프로세스 완성
- 헤임달: normal/critical 레벨 사전 필터로 포지셔닝하면 security 에스컬레이션 빈도 감소

**합의: 도입 우선순위 높음 (최우선)**
- 도입 방안: 커스터마이징 설치
- 조건 1: "devil's advocate" 트리거 제거 → "stress-test", "코드리뷰", "아키텍처 검토"로 변경
- 조건 2: 심각도 등급을 QC 레벨과 매핑 (Critical→security, Major→critical, Minor→normal)
- 조건 3: 로키와 역할 분리 명문화 (adversarial-review = 로직/설계, 로키 = 보안/위협)

**특별 검토 결과 — 로키 역할**
- 대체 불가, **분업 구조가 최적**
- adversarial-review → 로키 감사 직렬 연결로 품질 + 보안 이중 검증 체계 완성

---

### 1.4 skill-composer (스킬 파이프라인 체이닝)

**평가 점수**
- 유용성: 토르 4, 프레이야 3, 미미르 4, 헤임달 4 → **평균 3.75**
- 호환성: 토르 3, 프레이야 2, 미미르 4, 헤임달 5 → **평균 3.5**

**주요 의견**
- 토르: dispatch.py와 기능 영역 겹침. 독립 설치보다 dispatch.py 리팩토링 참조 아키텍처로 활용
- 프레이야: "workflow" 트리거 너무 광범위. project-kickoff와 혼동 위험. 학습 비용 가장 높은 스킬
- 미미르: 3문서 시스템 체크리스트와 파이프라인이 병렬 워크플로우 관리로 충돌 위험. Fork-Join은 멀티팀 병렬 작업에 유용
- 헤임달: Quality Gate 패턴이 qc_verify.py 확장 기준으로 유용. QC 에스컬레이션 로직 명문화에 효과적

**합의: 도입 우선순위 중간**
- 도입 방안: 아이디어 차용 (dispatch.py 개선에 반영)
- Fork-Join 패턴을 dispatch.py의 멀티팀 병렬 라우팅에 참조
- Quality Gate 패턴을 qc_verify.py 에스컬레이션 로직에 적용
- 독립 스킬 설치는 dispatch.py와의 경합 조건 위험으로 보류

**특별 검토 결과 — dispatch.py 시너지**
- 완전 통합보다 **부분 흡수가 안전**
- 단일 진입점(dispatch.py) 원칙 유지하면서 설계 패턴만 참조

---

### 1.5 persona-architect (5레이어 페르소나 DNA)

**평가 점수**
- 유용성: 토르 3, 프레이야 2, 미미르 3, 헤임달 2 → **평균 2.5**
- 호환성: 토르 4, 프레이야 2, 미미르 3, 헤임달 2 → **평균 2.75**

**주요 의견**
- 토르: 기존 페르소나가 이미 운영 중. 신규 에이전트 생성 시 참조 표준으로만 활용
- 프레이야: 가장 위험한 스킬. 임의 페르소나 생성 시 dispatch.py-hooks-조직도 정합성이 깨짐
- 미미르: 5레이어 중 "바이어스 명시" 레이어만 추출 가치. 전체 설치 불필요
- 헤임달: QC 파이프라인과 직접 통합 지점 없음

**합의: 도입 우선순위 낮음**
- 도입 방안: 아이디어 차용 (5레이어 DNA를 페르소나 설계 참조 템플릿으로만 활용)
- 스킬 자체 설치는 시스템 정합성 리스크로 **비권장**

---

### 1.6 deep-dive-analyzer (3모드 심층 분석)

**평가 점수**
- 유용성: 토르 4, 프레이야 4, 미미르 4, 헤임달 4 → **평균 4.0**
- 호환성: 토르 5, 프레이야 3, 미미르 4, 헤임달 3 → **평균 3.75**

**주요 의견**
- 토르: 3docs-create의 상위 단계로 직렬 연결 가능. 아키텍처 결정 기록(ADR) 표준 프로세스로 채택 가능
- 프레이야: "deep dive" 트리거는 직관적. "analyze" 트리거가 insight-extractor와 충돌 가능
- 미미르: PDP 리스크/회고 단계에서 근본 원인 분석 역량 강화. qc_verify.py 실패 시 자동 트리거 가능
- 헤임달: Code 모드의 SRP/커플링 분석이 구조적 결함 탐지에 유효. 계약 테스트 의존성 분석에도 활용

**합의: 도입 우선순위 높음**
- 도입 방안: 커스터마이징 설치
- 조건 1: "analyze" 트리거를 "deep-analyze"로 변경 (insight-extractor 충돌 방지)
- 조건 2: Telegram용 압축 출력 모드 추가
- 연결: deep-dive-analyzer → adversarial-review 직렬 파이프라인으로 분석+비평 듀얼 검증

---

### 1.7 tiered-test-generator (3티어 지식 검증)

**평가 점수**
- 유용성: 토르 3, 프레이야 3, 미미르 2, 헤임달 5 → **평균 3.25**
- 호환성: 토르 4, 프레이야 4, 미미르 2, 헤임달 4 → **평균 3.5**

**주요 의견**
- 토르: 지식 퀴즈 목적이라 소프트웨어 QA와 도메인이 다름. 재목적화 필요
- 프레이야: 트리거 충돌 없음. 9문제 일괄 출력은 Telegram에서 너무 길어 분할 필요
- 미미르: 현재 워크플로우 우선순위와 맞지 않음. 온보딩/UAT 시나리오에만 제한 활용
- 헤임달: Bloom 분류 기반 3티어를 pytest 테스트 계층(단위/통합/계약)에 매핑하면 커버리지 의미 전환 가능

**합의: 도입 우선순위 낮음**
- 도입 방안: 커스터마이징 후 나중에 도입
- T1→단위 테스트, T2→통합 테스트, T3→계약/엣지 매핑으로 재목적화 필요
- 즉시 도입보다 헤임달 주도 커스터마이징 후 2차 도입 검토

**특별 검토 결과 — 헤임달 역할 강화**
- 직접 강화보다 **간접 보조**
- Bloom 분류 체계의 "인지 깊이" 개념은 테스트 설계 템플릿에 차용 가치 있음

---

## 2. 종합 점수표

| 스킬 | 유용성(평균) | 호환성(평균) | 도입 우선순위 | 도입 방안 |
|------|:---:|:---:|:---:|---|
| adversarial-review | 4.75 | 4.25 | **높음(최우선)** | 커스터마이징 설치 |
| cross-verified-research | 3.75 | 4.00 | **높음** | 커스터마이징 설치 |
| deep-dive-analyzer | 4.00 | 3.75 | **높음** | 커스터마이징 설치 |
| skill-composer | 3.75 | 3.50 | 중간 | 아이디어 차용 |
| creativity-sampler | 3.00 | 3.25 | 중간 | 아이디어 차용 |
| tiered-test-generator | 3.25 | 3.50 | 낮음 | 커스터마이징 후 2차 검토 |
| persona-architect | 2.50 | 2.75 | 낮음 | 아이디어 차용 |

---

## 3. 최종 결론 및 도입 로드맵

### Phase 1: 즉시 도입 (3개)

1. **adversarial-review** — 커스터마이징 설치
   - 트리거: "stress-test", "코드리뷰", "아키텍처 검토"
   - 로키와 분업 (로직/설계 vs 보안)
   - QC 심각도 등급 매핑

2. **cross-verified-research** — 커스터마이징 설치
   - 트리거: "cross-verify", "교차검증"
   - Lv.3+ 작업에 의무 적용
   - 소스 등급 S/A/B/C 채택

3. **deep-dive-analyzer** — 커스터마이징 설치
   - 트리거: "deep-dive", "deep-analyze", "심층분석"
   - Telegram 압축 출력 모드 추가
   - adversarial-review와 직렬 파이프라인 연결

### Phase 2: 아이디어 차용 (2개)

4. **skill-composer** — dispatch.py 개선 시 참조
   - Fork-Join/Iterative 패턴 → dispatch.py 리팩토링
   - Quality Gate 패턴 → qc_verify.py 에스컬레이션 명문화

5. **creativity-sampler** — 에이전트 미팅 프로세스에 내재화
   - "비관습적 대안 1개 의무" 규칙 미팅 어젠다에 추가

### Phase 3: 장기 검토 (2개)

6. **tiered-test-generator** — 헤임달 주도 커스터마이징 후 재검토
   - Bloom 분류 → pytest 테스트 계층 매핑 PoC 선행

7. **persona-architect** — 페르소나 설계 참조 템플릿으로만 활용
   - 5레이어 DNA 구조를 persona-list.md 업데이트 시 참고

### 공통 도입 조건
- 모든 스킬: 한국어 트리거 병기 필수
- Telegram 환경 최적화 (긴 출력 단계적 분할, 테이블 → 목록)
- 기존 스킬 트리거와 충돌 검증 후 설치

---

## 4. 특별 검토 포인트 결론

| 검토 사항 | 결론 |
|-----------|------|
| adversarial-review ↔ 로키 | **대체 불가, 분업 최적.** 직렬 연결(adversarial → 로키)로 이중 검증 |
| cross-verified-research ↔ 리서치 작업 | **Lv.3+ 작업에 의무 적용.** 소스 등급 체계가 핵심 가치 |
| skill-composer ↔ dispatch.py | **독립 설치 보류.** 설계 패턴만 dispatch.py 개선에 참조 |
| tiered-test-generator ↔ 헤임달 | **간접 보조.** Bloom 분류 → 테스트 계층 매핑 재목적화 필요 |

---

*미팅 기록 작성: 오딘(개발2팀장)*
*참석자 전원 검토 완료*