Agent skill · product strategy · aiskillstore
braintrust
현재 세션에서 합의·작성한 설계·계획·결정·산출물을 3~5개 독립 fork 에이전트가 서로 다른 렌즈로 적대적으로 검토(adversarial review)하고 충돌조정·종합하는 인-세션 패널. "적대검토", "패널 검토", "다중 에이전트로 검토", "여러 관점으로 뜯어봐", "집단지성", "브레인스토밍 패널", "red-team", "fork 패널", "최종검토 돌려줘" 등을 언급하거나, 중대한 설계/계획/결정을 굳히기 직전 교차검증이 필요할 때 반드시 사용한다. 단일 외부검증(advisor)·코드 diff 리뷰(/code-review)와는 역할이 다르며 그쪽이 맞으면 위임한다(아래 "언제 쓰나/안 쓰나").
Why this skill is useful
Provides a structured framework for adversarial review that enhances decision-making processes by incorporating diverse perspectives.
What it needs
About 3k tokens when loaded. Last updated 2026-08-07. 405 stars on the source repository.
What this skill does
Braintrust — 인-세션 적대검토 패널 (집단지성) 핵심 아이디어 (왜) 설계·계획을 만든 그 사고는 자기 맹점을 못 본다(self-confirming). 진짜 레버는 저자의 추론을 공유하지 않는 독립 검토자 여럿 — 한 명(advisor)보다 N명이, 같은 렌즈 N개보다 서로 다른 렌즈 N개가 실패모드를 더 잡는다(diversity > redundancy). 결정적 우위는 fork 에이전트가 현재 대화 컨텍스트를 통째 상속한다는 것. 검토 대상을 프롬프트로 재직렬화할 필요 없이 "지금 합의한 것"을 그대로 검토한다. (fresh 에이전트는 매번 맥락을 붙여야 하고 그 과정에 저자 프레이밍이 샌다 — fork는 그 누수가 없다.) 언제 쓰나 / 안 쓰나 (역할 경계 — 단일 소스) 전제: 검토 대상이 현재 세션 컨텍스트에 있어야 한다(fork 상속이 전부니까). 없으면 먼저 대상을 받는다. 쓴다: 중대한 설계·아키텍처·계획·정책을 굳히기 직전 / 사용자가 "적대검토·패널·여러 관점·red-team" 요청 / 자기검토가 미덥지 않은 비가역·고영향 결정. 위임한다(안티-트리거) — 아래와 역할이 다르다: 코드 diff 리뷰 → /code-review (ultra=클라우드 멀티에이전트) 단일 외부검증 한 번이면 충분 → advisor 수정안의 파급반경/경계 판정만 → 별도의 범위 검토 에이전트가 설치돼 있으면 활용 대규모(≈8+) fan-out·결정론 파이프라인 → 별도의 대량 fan-out 워크플로우 고유 니치 = 소수 렌즈(3~5)·현재 세션·설계/계획/결정·fork 상속·종합까지. 위가 더 맞으면 패널을 띄우지 말고 위임하라 — 도구 중복은 부담만 는다(비중복 슬롯에만 도구를 둔다). 절차 1. 렌즈 선정 (3~5개, 직교하게) 검토 대상에 맞춰 겹치지 않는 비판 축을 고른다. 디폴트 메뉴(도메인 맞춤 가능): 렌즈 묻는 것 --- --- 정합성/원칙 내부 논리·기존 원칙·제약과 충돌하나? 빠진 규칙은? 실패모드(적대) 시간경과·게이밍·엣지케이스로 어떻게 깨지나? 데이터 손실은? 실행가능성 실제로 강제·구현 가능한가? 결정론 가능 vs 사람/모델 규율 의존? 운영 현실성 누가·언제 실제로 수행하나? 6개월 뒤에도 작동하나? 측정 가능한가? 대안/기회비용 더 단순한/검증된 방법이 이미 있나? 기존 자산과 중복인가? 렌즈는 직교해야 한다 — 같은 렌즈 5개면 N명이 같은 말을 반복할 뿐이다. 대상이 한 방향으로만 깨질 수 있으면 그 축에 검토자를 더 붙이되, 보통은 직교 렌즈로 펼친다. 2. 병렬 fork 배포 렌즈마다 fork 1개씩, 한 메시지에 여러 Agent 호출로 동시 배포한다(병렬 실행). fork는 컨텍스트 + 메인 모델을 상속하므로 model 지정·대상 재설명 불필요. 프롬프트엔 렌즈와 산출 규약만 담는다 — 검토 대상을 복붙하지 말 것(컨텍스트에 이미 있고, 복붙하면 저자 프레이밍이 샌다). 3. fork 프롬프트 규약 (각 에이전트) — 형식적 검토(theater)를 막는 장치 이 렌즈로만 적대적으로 검토하라. 다른 렌즈는 다른 에이전트 몫. 일반론·칭찬 금지, 구체적 보완·첨삭만. 항목별 [심각도 高/中/低][구체적 수정 문구]. 가능하면 실측 근거(파일·라인·재현 경로)를 대고, 추정과 사실을 구분하라. 없으면 "없음 + 이유"를 명시하라 — 없는 결함을 지어내지 말 것(거짓 양성이 종합을 오염시킨다). read-only, 검토 보고만 (코드 수정 금지). (적대성 강화가 필요하면: "기본값을 '문제 있음'으로 두고 반증하라"는 refute-first 프레이밍.) 4. 종합 1. 중복 제거 — 여러 렌즈가 같은 지점을 짚으면 합치되, 합의 강도(몇 명이 짚었나)는 신호로 남긴다. 2. 충돌 조정 — 렌즈 간 상충은 근거로 판정한다(어느 제약이 우선인지). 상충 자체를 사용자에게 드러내는 게 가치다 — 묻어두지 말 것. 3. 우선순위화 — 심각도 × 합의강도로 정렬. CRITICAL/다수합의가 먼저. 4. 산출 — 보완/첨삭 목록 + (수정한다면) 최종 합의안. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aiskillstore/braintrust