Council
모호한 결정을 위해 네 명의 조언자를 소집합니다:
- 인컨텍스트 Claude의 목소리
- Skeptic(회의론자) 서브에이전트
- Pragmatist(실용주의자) 서브에이전트
- Critic(비평가) 서브에이전트
이는 불확실성 하의 의사결정을 위한 것이며, 코드 리뷰, 구현 계획, 아키텍처 설계를 위한 것이 아닙니다.
사용 시기
다음과 같은 경우 council을 사용하세요:
- 결정에 여러 신뢰할 수 있는 경로가 있고 명확한 승자가 없을 때
- 명시적인 트레이드오프 도출이 필요할 때
- 사용자가 제2의 의견, 반대 의견, 또는 다양한 관점을 요청할 때
- 대화 앵커링이 실제 위험으로 존재할 때
- 진행/중단 결정에 반론적 도전이 도움이 될 때
예시:
- 모노레포 vs 폴리레포
- 지금 출시 vs 다듬고 출시
- 기능 플래그 vs 전체 롤아웃
- 범위 단순화 vs 전략적 폭 유지
사용하지 말아야 할 때
| council 대신 | 사용할 것 |
|---|---|
| 출력이 올바른지 확인 | santa-method |
| 기능을 구현 단계로 나누기 | planner |
| 시스템 아키텍처 설계 | architect |
| 버그나 보안 검토를 위한 코드 리뷰 | code-reviewer 또는 santa-method |
| 단순한 사실 질문 | 그냥 직접 답변 |
| 명백한 실행 작업 | 그냥 작업 수행 |
역할
| 목소리 | 관점 |
|---|---|
| Architect | 정확성, 유지보수성, 장기적 영향 |
| Skeptic | 전제 도전, 단순화, 가정 파괴 |
| Pragmatist | 출시 속도, 사용자 영향, 운영 현실 |
| Critic | 엣지 케이스, 하방 위험, 실패 모드 |
세 가지 외부 목소리는 질문과 관련 맥락만을 가지고 새로운 서브에이전트로 실행되어야 하며, 전체 진행 중인 대화는 포함하지 않아야 합니다. 이것이 앵커링 방지 메커니즘입니다.
워크플로우
1. 실제 질문 추출
결정을 하나의 명시적인 프롬프트로 축소합니다:
- 우리는 무엇을 결정하는가?
- 어떤 제약 조건이 중요한가?
- 무엇을 성공으로 간주하는가?
질문이 모호하다면, council을 소집하기 전에 명확화 질문을 하나 하십시오.
2. 필요한 맥락만 수집
결정이 코드베이스 특화된 경우:
- 관련 파일, 스니펫, 이슈 텍스트, 또는 메트릭을 수집합니다
- 간결하게 유지합니다
- 결정을 내리는 데 필요한 맥락만 포함합니다
결정이 전략적/일반적인 경우:
- 답변을 실질적으로 바꾸지 않는 한, 저장소 스니펫은 건너뜁니다
3. 먼저 Architect의 입장을 수립
다른 목소리를 읽기 전에 다음을 작성하십시오:
- 당신의 초기 입장
- 이에 대한 세 가지 가장 강력한 이유
- 선호 경로의 주요 위험
이를 먼저 수행하여 종합이 단순히 외부 목소리를 반영하지 않도록 합니다.
4. 세 개의 독립적인 목소리를 병렬로 실행
각 서브에이전트는 다음을 받습니다:
- 결정 질문
- 필요한 경우 간결한 맥락
- 엄격한 역할
- 불필요한 대화 기록 없음
프롬프트 형태:
당신은 네 목소리 결정 평의회의 [역할]입니다.
질문:
[결정 질문]
맥락:
[관련 스니펫 또는 제약 조건만]
다음과 같이 응답하십시오:
1. 입장 — 1-2문장
2. 추론 — 3개의 간결한 불릿
3. 위험 — 추천에서 가장 큰 위험
4. 놀라움 — 다른 목소리가 놓칠 수 있는 한 가지
직설적으로 표현하십시오. 애매하게 말하지 마십시오. 300단어 이내로 유지하십시오.
역할 강조:
- Skeptic: 프레임에 도전하고, 가정에 의문을 제기하며, 가장 간단한 신뢰할 수 있는 대안을 제안합니다
- Pragmatist: 속도, 단순성, 실제 실행을 최적화합니다
- Critic: 하방 위험, 엣지 케이스, 계획이 실패할 수 있는 이유를 표면화합니다
5. 바이어스 방어 장치를 적용하여 종합
당신은 참여자이자 종합자이므로 다음 규칙을 사용하십시오:
- 이유 없이 외부 의견을 무시하지 마십시오
- 외부 목소리가 추천을 변경했다면 명시적으로 밝히십시오
- 거부하더라도 항상 가장 강력한 반대 의견을 포함하십시오
- 두 목소리가 당신의 초기 입장에 반대하여 일치한다면, 이를 실제 신호로 취급하십시오
- 평결 전에 원래 입장을 계속 볼 수 있게 유지하십시오
6. 간결한 평결 제시
다음 출력 형태를 사용하십시오:
## Council: [짧은 결정 제목]
**Architect:** [1-2문장 입장]
[이유 한 줄]
**Skeptic:** [1-2문장 입장]
[이유 한 줄]
**Pragmatist:** [1-2문장 입장]
[이유 한 줄]
**Critic:** [1-2문장 입장]
[이유 한 줄]
### 평결
- **합의:** [일치하는 부분]
- **가장 강력한 반대:** [가장 중요한 불일치]
- **전제 확인:** [Skeptic이 질문 자체에 도전했는가?]
- **추천:** [종합된 경로]
휴대폰 화면에서도 훑어보기 쉽게 유지하십시오.
지속성 규칙
이 스킬에서 ~/.claude/notes 또는 기타 그림자 경로에 임시 노트를 작성하지 마십시오.
Council이 추천을 실질적으로 변경한 경우:
knowledge-ops를 사용하여 교훈을 올바른 영구 위치에 저장하십시오- 또는 결과가 세션 메모리에 속한다면
/save-session을 사용하십시오 - 또는 결정이 활성 실행 진실을 변경한다면 관련 GitHub/Linear 이슈를 직접 업데이트하십시오
결정이 실제로 무언가를 변경할 때만 지속하십시오.
다중 라운드 후속 조치
기본값은 한 라운드입니다.
사용자가 추가 라운드를 원하는 경우:
- 새로운 질문에 집중하십시오
- 필요한 경우에만 이전 평결을 포함하십시오
- 앵커링 방지 가치를 보존하기 위해 Skeptic을 최대한 깨끗하게 유지하십시오
안티 패턴
- 코드 리뷰에 council 사용
- 작업이 단순히 구현 작업일 때 council 사용
- 서브에이전트에게 전체 대화 기록 제공
- 최종 평결에서 불일치 숨기기
- 중요도와 관계없이 모든 결정을 노트로 지속하기
관련 스킬
santa-method— 적대적 검증knowledge-ops— 결정 델타를 올바르게 영구 저장search-first— council 전에 외부 참고 자료 수집이 필요할 때architecture-decision-records— 결정이 장기적인 시스템 정책이 될 때 결과를 공식화
예시
질문:
ECC 2.0을 지금 알파로 출시해야 할까요, 아니면 컨트롤 플레인 UI가 더 완성될 때까지 기다려야 할까요?
예상 council 형태:
- Architect: 구조적 무결성과 혼란스러운 표면을 피해야 한다고 주장
- Skeptic: UI가 실제로 결정적 요인인지 의문 제기
- Pragmatist: 신뢰를 해치지 않고 지금 출시할 수 있는 것이 무엇인지 질문
- Critic: 지원 부담, 기대 부채, 롤아웃 혼란에 초점
가치는 만장일치가 아닙니다. 가치는 선택하기 전에 불일치를 읽을 수 있게 만드는 데 있습니다.