Council (의회)은(는) 무엇을 하나요?
모호한 결정을 위해 네 명의 조언자를 소집합니다:
- 인컨텍스트(in-context) 클로드(Claude)의 목소리
- 회의론자(Skeptic) 서브에이전트
- 실용주의자(Pragmatist) 서브에이전트
- 비평가(Critic) 서브에이전트
이는 코드 리뷰, 구현 계획, 아키텍처 설계가 아닌 모호함 속 의사결정을 위한 것입니다.
사용 시기
다음과 같은 경우 council을 사용하세요:
- 결정에 여러 신뢰할 만한 경로가 있고 명확한 승자가 없을 때
- 명시적인 트레이드오프 표면화가 필요할 때
- 사용자가 제2의 의견, 반대 의견, 또는 다양한 관점을 요청할 때
- 대화 앵커링(conversational anchoring)이 실제 위험으로 존재할 때
- 진행/중단 결정에 반론적 도전이 도움이 될 때
예시:
- 모노레포 vs 폴리레포
- 지금 출시 vs 다듬기 위해 보류
- 기능 플래그 vs 전체 롤아웃
- 범위 단순화 vs 전략적 폭 유지
사용하지 말아야 할 때
| council 대신 | 사용할 기술 |
|---|---|
| 출력이 올바른지 확인 | santa-method |
| 기능을 구현 단계로 분해 | planner |
| 시스템 아키텍처 설계 | architect |
| 버그나 보안 코드 리뷰 | code-reviewer 또는 santa-method |
| 단순 사실 질문 | 바로 답변 |
| 명확한 실행 작업 | 바로 작업 수행 |
역할
| 목소리 | 관점 |
|---|---|
| Architect | 정확성, 유지보수성, 장기적 영향 |
| Skeptic | 전제 도전, 단순화, 가정 깨기 |
| Pragmatist | 출시 속도, 사용자 영향, 운영 현실 |
| Critic | 엣지 케이스, 하방 위험, 실패 모드 |
세 개의 외부 목소리는 전체 진행 중인 대화가 아닌, 질문과 관련 맥락만을 가지고 새로운 서브에이전트로 실행되어야 합니다. 이것이 앵커링 방지 메커니즘입니다.
워크플로우
1. 실제 질문 추출하기
결정을 하나의 명시적 프롬프트로 축소하세요:
- 무엇을 결정하는가?
- 어떤 제약 조건이 중요한가?
- 무엇을 성공으로 간주하는가?
질문이 모호하다면, council을 소집하기 전에 하나의 명확화 질문을 하세요.
2. 필요한 맥락만 수집하기
결정이 코드베이스 특정적인 경우:
- 관련 파일, 스니펫, 이슈 텍스트 또는 메트릭을 수집하세요
- 간결하게 유지하세요
- 결정에 필요한 맥락만 포함하세요
결정이 전략적/일반적인 경우:
- 답을 실질적으로 바꾸지 않는 한 리포지토리 스니펫은 건너뛰세요
3. 먼저 Architect의 입장 정립하기
다른 목소리를 읽기 전에 다음을 기록하세요:
- 당신의 초기 입장
- 그 입장의 가장 강력한 세 가지 이유
- 선호하는 경로의 주요 위험
합성이 단순히 외부 목소리를 반영하지 않도록 먼저 이 작업을 수행하세요.
4. 세 개의 독립적인 목소리를 병렬로 실행하기
각 서브에이전트는 다음을 받습니다:
- 결정 질문
- 필요한 경우 간결한 맥락
- 엄격한 역할
- 불필요한 대화 기록 없음
프롬프트 형식:
당신은 4인 결정 위원회의 [역할]입니다.
질문:
[결정 질문]
맥락:
[관련 스니펫 또는 제약 조건만]
다음과 같이 응답하세요:
1. 입장 — 1-2문장
2. 근거 — 3개의 간결한 불릿
3. 위험 — 권장 사항의 가장 큰 위험
4. 놀라운 점 — 다른 목소리가 놓칠 수 있는 한 가지
직설적으로 말하세요. 얼버무리지 마세요. 300단어 미만으로 유지하세요.
역할 강조:
- Skeptic: 프레이밍에 도전하고, 가정에 의문을 제기하며, 가장 간단한 신뢰할 수 있는 대안을 제안하세요
- Pragmatist: 속도, 단순성, 실제 실행에 최적화하세요
- Critic: 하방 위험, 엣지 케이스, 계획이 실패할 수 있는 이유를 표면화하세요
5. 편향 가드레일을 사용하여 종합하기
당신은 참여자이자 종합자이므로 다음 규칙을 사용하세요:
- 이유를 설명하지 않고 외부 관점을 dismiss하지 마세요
- 외부 목소리가 당신의 권장 사항을 바꾸었다면 명시적으로 말하세요
- 거부하더라도 항상 가장 강력한 반대 의견을 포함하세요
- 두 목소리가 당신의 초기 입장에 반대한다면 그것을 실제 신호로 처리하세요
- 평결 전에 원시 입장을 볼 수 있게 유지하세요
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은 지원 부담, 기대 부채, 롤아웃 혼란에 초점을 맞출 것입니다
가치는 만장일치가 아닙니다. 가치는 선택하기 전에 불일치를 읽기 쉽게 만드는 것입니다.