Braintrust

Skill cubha/claude-workflow-plugins/plugins/braintrust/skills/braintrust

Curated marketplace of production-grade Claude Code skills & plugins — planning, parallel dev, debugging, design linting, adversarial review

Install

npx -y skills add cubha/claude-workflow-plugins --skill braintrust

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

현재 세션에서 합의·작성한 설계·계획·결정·산출물을 3~5개 독립 fork 에이전트가 서로 다른 렌즈로 적대적으로 검토(adversarial review)하고 충돌조정·종합하는 인-세션 패널. "적대검토", "패널 검토", "다중 에이전트로 검토", "여러 관점으로 뜯어봐", "집단지성", "브레인스토밍 패널", "red-team", "fork 패널", "최종검토 돌려줘" 등을 언급하거나, 중대한 설계/계획/결정을 굳히기 직전 교차검증이 필요할 때 반드시 사용한다. 단일 외부검증(advisor)·코드 diff 리뷰(/code-review)와는 역할이 다르며 그쪽이 맞으면 위임한다(아래 "언제 쓰나/안 쓰나").

SKILL.md

6.7 KB, as published. Nobody here has run it

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 호출로 동시 배포한다(병렬 실행).

Agent({ subagent_type: "fork", name: "Lens-<렌즈명>", description: "<렌즈> 검토", prompt: <3번 규약> })

fork는 컨텍스트 + 메인 모델을 상속하므로 model 지정·대상 재설명 불필요. 프롬프트엔 렌즈와 산출 규약만 담는다 — 검토 대상을 복붙하지 말 것(컨텍스트에 이미 있고, 복붙하면 저자 프레이밍이 샌다).

3. fork 프롬프트 규약 (각 에이전트) — 형식적 검토(theater)를 막는 장치

이 렌즈로만 적대적으로 검토하라. 다른 렌즈는 다른 에이전트 몫.
일반론·칭찬 금지, 구체적 보완·첨삭만. 항목별 [심각도 高/中/低][구체적 수정 문구].
가능하면 실측 근거(파일·라인·재현 경로)를 대고, 추정과 사실을 구분하라.
없으면 "없음 + 이유"를 명시하라 — 없는 결함을 지어내지 말 것(거짓 양성이 종합을 오염시킨다).
read-only, 검토 보고만 (코드 수정 금지).
(적대성 강화가 필요하면: "기본값을 '문제 있음'으로 두고 반증하라"는 refute-first 프레이밍.)

4. 종합

중복 제거 — 여러 렌즈가 같은 지점을 짚으면 합치되, 합의 강도(몇 명이 짚었나)는 신호로 남긴다.
충돌 조정 — 렌즈 간 상충은 근거로 판정한다(어느 제약이 우선인지). 상충 자체를 사용자에게 드러내는 게 가치다 — 묻어두지 말 것.
우선순위화 — 심각도 × 합의강도로 정렬. CRITICAL/다수합의가 먼저.
산출 — 보완/첨삭 목록 + (수정한다면) 최종 합의안. 무엇을 채택/기각했는지와 근거를 남긴다.

중대 결정이면 종합 후 advisor 1회로 외부검증을 덧대도 좋다(패널=내부 다수, advisor=독립 1인, 보완적).

규모 조절

"가볍게 봐줘" → 3 렌즈, 단일 라운드. "철저히/최종검토" → 4~5 렌즈 + 핵심 발견을 별도 fork로 반증(2차). 대상이 좁으면 렌즈를 줄인다 — 억지로 5개 만들지 말 것.

Known Pitfalls (위에서 안 다룬 것만)

모델 동질 편향. 모든 fork가 같은 모델이라 상관된 편향(같은 맹점 공유)이 남는다. 독립성이 정말 중요한 결정이면 한 렌즈를 다른 벤더(Codex/Gemini, 외부 키 필요)에 맡기는 cross-vendor 검토를 사용자와 논의하라 — 기본은 동질 패널이되 이 한계를 인지한다.
가치는 artifact가 아니라 독립성에서 난다. 보고서 모양만 그럴듯하고 렌즈가 비직교거나 대상을 복붙했거나 "뭐든 찾아내라"고 압박하면 theater가 된다(각각 절차 1·2·3에서 차단).

예시

"이 설계 최종검토 돌려줘" → 정합성/실패모드/실행가능성/운영 4 렌즈 fork 병렬 → 종합.
"이 정책 여러 관점으로 뜯어봐" → 도메인 맞춤 렌즈 3~5개 → 병렬 → 충돌조정 종합.
"코드 바뀐 거 적대적으로 봐줘" → 위임: /code-review(diff 전용)가 맞다고 안내.