지피티 프로랑 심층리서치 돌아가는 내용보고 코덱스용 스킬로 흉내내봤음
---
name: oinhoe
deion: exact `!오인회`로 시작하는 요청이나 실제 5개 sub-agent 전문가가 3라운드 회의를 진행해 최선안을 도출해야 할 때 사용한다. 보고서 형식만 흉내 내지 않고 round별 worker 응답, 증거, blocker를 분리한다.
---
# 오인회
사용자의 문제를 범위 안에서만 다루고, 문제 성격에 맞는 5인 전문가 위원회를 실제 sub-agent로 구성해 `Round 1 -> Round 2 -> Round 3` 회의를 진행한다.
3회차는 출력 목차가 아니라 실제 실행 단계다. 각 회차의 위원 의견은 실제 sub-agent 응답, timeout, blocker, partial, weak-evidence 상태에서만 생성한다. 단일 컨텍스트 안에서 5인 위원회를 역할극으로 흉내 내지 않는다.
## Trigger / Non-trigger
- `!오인회`로 시작하는 요청은 explicit sub-agent delegation 요청이다.
- `!오인회 !멀티`가 함께 오면 별도 fan-out을 중복 생성하지 않고, 이 스킬의 5인 3라운드 회의 흐름 하나로 처리한다.
- 사용자가 단순 요약, 일반 조언, 계획 초안, 또는 read-only 상태 확인만 요청했고 `!오인회`나 실제 회의형 전문가 검토를 요구하지 않았다면 이 스킬을 호출하지 않는다.
- 실제 sub-agent 도구가 없거나 안전하게 분해할 수 없으면 보고서 형식으로 대체하지 않고 blocker를 보고한다.
## 실행 계약
main agent는 chair/router다. scope, 최종 종합, 충돌 조정, 검증 책임은 main agent가 유지한다. sub-agent는 각 전문가 관점의 독립 판단만 담당하며 nested delegation은 금지한다.
실행 전에 main agent는 `vowline`으로 목표, 입력, 출력 표면, 허용 write, 제외 범위, 성공 기준을 고정하고, 얇은 `grill-me` 체크로 핵심 전제, 범위 확장 위험, owner/routing 충돌, 검증 공백을 확인한다.
이 스킬의 round continuation은 `oinhoe` 내부 회의 프로토콜이다. 새 spawn authority와 일반 multi-agent routing 원칙은 `multi-agent-trigger-routing`이 소유한다. Stage 1 적용에서는 `multi-agent-trigger-routing`, `AGENTS.md`, `config.toml`, memory를 수정하지 않는다. routing 충돌이 실제로 재현되면 별도 승인 대상으로 보고한다.
## 실행 가능성 Gate
각 실행 전에 아래를 짧게 고정한다.
| 항목 | 기준 |
| --- | --- |
| `sub_agent_support` | 현재 세션에 실제 sub-agent 도구가 있는가 |
| `safe_decomposition` | 5개 전문가 관점이 독립적으로 조사·판단 가능한가 |
| `meeting_mode` | 기본값 `strict_three_rounds`; 사용자 명시 또는 도구 제약 시 낮춘 사유 |
| `allowed_reads` | 각 worker가 읽을 수 있는 파일, 자료, 최신정보 범위 |
| `allowed_writes` | 기본값 `none`; 사용자가 명시하고 role별 write scope가 겹치지 않을 때만 허용 |
| `file_locks` | 같은 파일 병렬 편집 금지 또는 role별 write scope |
| `startup_cost_risk` | 읽어야 할 지침, 파일, 자료, 대기·비용 부담 |
| `quorum_timeout_policy` | timeout, 미응답, 부분 응답을 낮춰 표시하는 기준 |
| `meeting_end_condition` | Round 3 응답 또는 명시 blocker 이후에만 최종 종합 |
Hard stop:
- 실제 sub-agent tool 없음 -> `blocked: 실제 sub-agent tool 없음`
- 안전한 분해 실패 -> `blocked: safe decomposition 실패`
- 민감 자료 전문 읽기, 권한·비용·계정 변경, 불명확한 write scope -> blocker 또는 사용자 승인 대기
- 같은 파일 병렬 편집이 필요한 요청 -> blocker 또는 순차 처리 전환
- nested delegation 또는 persona 간 재호출 -> 금지
## 위원 구성
문제에 필요한 관점 5개를 고르고 겹치는 역할을 피한다. 각 전문가는 `role_key`, `역할명`, `전문 분야`, `문제에서의 관점`, `예상 기여`, `최신정보 확인 범위`, `owned_scope`를 가진다.
- 기술·제품: 기술 책임자, 보안·데이터 전문가, 운영 책임자, 사용자 대표, 사업·리스크 전문가
- 사업·재무: 재무 전략가, 시장 분석가, 운영 책임자, 고객·사용자 대표, 법률·리스크 전문가
- 법률·정책: 법률 전문가, 정책·규제 전문가, 현장 운영자, 이해관계자 대표, 윤리·공공성 전문가
- 조직·운영: 운영 설계자, 현장 관리자, 인사·변화관리 전문가, 사용자·고객 대표, 리스크 관리자
- 문서·프롬프트·지침: 프롬프트 설계자, 도메인 전문가, 최종 사용자 대표, 품질검수자, 리스크·운영 전문가
- 창작·콘텐츠: 기획·서사 전문가, 독자·사용자 대표, 편집·품질 전문가, 플랫폼·시장 전문가, 윤리·리스크 전문가
특정 축이 문제와 무관하면 억지로 넣지 않는다. 실제 판단을 바꿀 관점을 우선한다.
## 3라운드 실제 회의 프로토콜
`exact !오인회`의 기본값은 strict 3 actual rounds다. 토큰 절감은 라운드 수를 줄이는 방식이 아니라 Round 2/3 입력을 압축하는 방식으로 한다. 사용자가 `간단히`, `압축`, `2회만`, `경량`을 명시하거나 도구·비용·timeout 제약이 있으면 라운드를 낮출 수 있지만, 그 사유와 빠진 회차를 `execution_evidence`에 남긴다.
### Round 0: 회의 준비
main agent가 문제를 3~5문장으로 재정리하고, 범위, 이해관계자, 제약조건, 기대 결과, 핵심 문제 1~3개, 최신정보 필요성을 고정한다.
최신정보가 결론에 영향을 주면 가능한 공식기관, 법령·규정, 연구자료, 통계, 업계 보고서, 신뢰 가능한 보도자료를 우선 확인한다. 확인할 수 없거나 근거가 약하면 `확인 필요` 또는 `자료 부족`으로 낮춘다.
### Round 1: 독립 문제 정의와 원인 분석
5개 sub-agent를 병렬 실행한다. Round 1에는 필요한 원자료, 지침, locator를 가장 넓게 제공할 수 있다.
각 worker prompt에는 아래를 포함한다.
- `role_key`, `역할명`, `전문 분야`, `문제에서의 관점`
- `round_id: R1`
- `round_objective: 문제 정의와 원인 분석`
- `owned_scope`
- `allowed_reads`, `allowed_writes`, `file_locks`
- `확인할 자료 또는 최신정보 범위`
- `명시적 제외 범위`
- `expected_output`
- `evidence_required`
- `confidence_required`
- `residual_risk_required`
- `vowline` 사용 지시
- thin `grill-me` 체크 지시
- nested delegation 금지
Round 1 이후 main agent는 최종 결론을 쓰지 않는다. `prior_round_digest`와 `conflict_matrix`만 만든다.
### Round 2: 충돌 조정과 대안 검토
가능하면 Round 1과 같은 worker에 `send_input`으로 이어 보낸다. 동일 worker identity를 유지할 수 없으면 같은 `role_key`의 stable role label에 `prior_round_digest`, `conflict_matrix`, Round 1 요약 packet을 전달하고 `tool limitation: 동일 worker identity 유지 불가`를 기록한다.
Round 2에는 원자료 전문을 재전송하지 않는다. 입력은 다음으로 제한한다.
- `prior_round_digest`
- `conflict_matrix`
- 핵심 문제 1~3개
- 후보 대안 1~3개 또는 대안 도출 질문
- `response_obligation`: 동의, 반박, 수정, 탈락 사유 중 반드시 답할 항목
- 필요한 evidence locator
Round 2 이후 main agent는 `shortlist`, 탈락 사유, 남은 충돌, 확인 필요 항목을 만든다.
### Round 3: 최종 판단과 실행 가능성 검토
가능하면 같은 worker 또는 같은 `role_key` continuation에 Round 2 `shortlist`와 남은 충돌만 전달한다.
Round 3 worker는 최종 권고안, 반대 의견, 실행 가능성, 남은 검증 공백, 실패 가능성을 짧게 판단한다. Round 3 응답 또는 명시 blocker가 모인 뒤에만 main agent가 최종 결론을 병합한다.
## Worker 출력 형식
각 worker는 라운드마다 아래 형식으로 짧게 보고한다.
```text
role_key:
역할명:
round_id:
status: complete | partial | blocked | timeout | weak_evidence
핵심 판단:
확인된 사실:
가정:
전문가 판단:
동의/반박/수정:
확인 필요:
근거 위치:
확신도:
residual risk:
handoff_to_main:
```
worker 보고가 locator, 검증 상태, residual risk를 누락하면 weak evidence로 낮춘다.
## Main Agent 병합 규칙
- main agent는 sub-agent가 담당한 조사를 중복 수행하지 않고 회의 진행, 입력 압축, 충돌표, 최종 병합만 맡는다.
- Round 1 결과를 3회차 보고서 형식으로 재배치하는 것만으로는 실패다.
- Round 2/3의 판단은 실제 worker 응답 또는 명시 blocker에서만 나온다.
- worker 실패, timeout, 부분 응답, 증거 누락은 정상 의견처럼 취급하지 않는다.
- 최종 결론은 현재 증거, 가정, 전문가 판단, 확인 필요, residual risk를 분리한다.
## 최종 보고서 형식
짧은 답변이 필요해도 실제 실행 증거와 3라운드 상태는 생략하지 않는다. 단, 위원별 장문 발언, 역할 소개 반복, 회차별 동일 근거 반복, 형식용 다음 과제, 최신정보가 불필요한 조사 섹션은 압축한다.
### 0. execution_evidence
- `sub_agent_support_checked`
- `spawn_decision`
- `worker_labels_or_ids`
- `stable_role_labels`
- `rounds_executed`
- `per_worker_status`
- `round_input_packet_types`
- `evidence_locators`
- `main_merge_actions`
- `blocked_or_skipped_checks`
- `tool_limitations`
- `residual_risk`
### 1. 입력 문제 정리
- 문제 요약
- 범위
- 이해관계자
- 제약조건
- 기대 결과
- 불명확한 부분
- 해결 목표
- 성공 기준과 실패 기준
- 핵심 문제 1~3개
### 2. 전문가 위원회 구성
| role_key | 역할명 | 전문 분야 | 문제에서의 관점 | owned_scope | 최신정보 확인 범위 |
| --- | --- | --- | --- | --- | --- |
### 3. 최신정보 조사 요약
최신정보가 핵심이 아니면 `최신정보 조사 불필요: 이유`로 짧게 처리한다. 필요한 경우에는 출처, 기준일, 결론에 영향을 준 사실, 자료 부족 항목을 분리한다.
### 4. Round 1 회의: 문제 정의 및 원인 분석
- 위원별 핵심 판단
- 합의된 원인
- 충돌 지점
- Round 2로 넘긴 질문
### 5. Round 2 회의: 대안 도출 및 타당성 검토
| 대안 | 장점 | 단점 | 전제조건 | 주요 리스크 | 근거자료 | 판정 |
| --- | --- | --- | --- | --- | --- | --- |
- 위원별 동의/반박/수정
- shortlist
- 탈락 사유
- Round 3로 넘긴 확인 필요
### 6. Round 3 회의: 최종 결정 및 실행 가능성
| 담당 | 기한 | 할 일 | 완료 기준 | 점검 방식 |
| --- | --- | --- | --- | --- |
- 최종 권고안
- 반대 의견과 대응
- 예상 리스크
- 성과 지표 또는 피드백 방식
- 위원별 최종 실행 가능성 평가
### 7. 결론
- 최종 합의사항
- 실행 우선순위
- 남은 확인 필요 사항
- 사용자 결정사항
## 실패 상태 보고
- `blocked: 실제 sub-agent tool 없음`
- `blocked: safe decomposition 실패`
- `partial: worker timeout/미응답`
- `weak evidence: locator/검증 누락`
- `tool limitation: 동일 worker identity 유지 불가`
- `candidate only: live 미반영`
실패나 부분 실행을 3회차 완료처럼 말하지 않는다.
## 검증 기준
완료를 말하기 전에 다음을 확인한다.
- 실제 sub-agent 실행 여부 또는 blocker가 보고되었는가
- Round 1/2/3 각각 실제 worker 응답, partial, timeout, blocker 중 하나가 있는가
- Round 2/3 입력이 원자료 전문 재전송이 아니라 digest, conflict matrix, shortlist, decision question 중심인가
- roleplay, nested delegation, 같은 파일 병렬 편집이 없었는가
- 최종 보고서에 `execution_evidence`, weak evidence, residual risk가 남았는가
superpowers에 브레인스토밍있긴한데