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. 세 개의 독립적인 목소리를 병렬로 실행
각 하위 에이전트는 다음을 제공받습니다:
- 결정 질문
- 필요한 경우 간결한 컨텍스트
- 엄격한 역할
- 불필요한 대화 기록 없음
프롬프트 형식:
당신은 4인 결정 위원회의 [역할]입니다.
질문:
[결정 질문]
컨텍스트:
[관련 코드 조각 또는 제약 조건만]
응답:
1. 입장 — 1-2문장
2. 근거 — 간결한 3개의 불릿
3. 위험 — 권장 사항의 가장 큰 위험
4. 놀라운 점 — 다른 목소리가 놓칠 수 있는 한 가지
직설적으로 답변하세요. 애매모호함 없이. 300단어 미만으로 유지.
역할 강조:
- Skeptic: 프레이밍에 도전하고, 가정에 의문을 제기하며, 가장 단순한 신뢰할 수 있는 대안을 제안
- Pragmatist: 속도, 단순성, 현실적 실행을 최적화
- Critic: 하방 위험, 예외 상황, 계획이 실패할 수 있는 이유를 표면화
5. 편향 방지 장치를 사용한 종합
당신은 참여자이자 종합자이므로 다음 규칙을 사용하세요:
- 이유를 설명하지 않고 외부 의견을 무시하지 마세요
- 외부 목소리가 권장 사항을 변경했다면 명시적으로 언급하세요
- 거부하더라도 항상 가장 강력한 반대 의견을 포함하세요
- 두 목소리가 초기 입장에 반대하여 일치한다면 그것을 진짜 신호로 처리하세요
- 평결 전에 원시 입장을 볼 수 있게 유지하세요
6. 간결한 평결 제시
다음 출력 형식을 사용하세요:
## Council: [짧은 결정 제목]
**Architect:** [1-2문장 입장]
[이유 1줄]
**Skeptic:** [1-2문장 입장]
[이유 1줄]
**Pragmatist:** [1-2문장 입장]
[이유 1줄]
**Critic:** [1-2문장 입장]
[이유 1줄]
### 평결
- **합의:** [일치하는 부분]
- **가장 강한 반대:** [가장 중요한 의견 차이]
- **전제 확인:** [Skeptic이 질문 자체에 도전했는가?]
- **권장 사항:** [종합된 경로]
휴대폰 화면에서도 읽기 쉽게 유지하세요.
지속성 규칙
이 스킬에서 ~/.claude/notes 또는 기타 섀도 경로에 임시 메모를 작성하지 마세요.
council이 권장 사항을 실질적으로 변경한 경우:
knowledge-ops를 사용하여 적절한 내구성 위치에 교훈 저장- 또는
/save-session을 사용하여 세션 메모리에 결과 저장 - 또는 결정이 활성 실행 상태를 변경하는 경우 관련 GitHub/Linear 이슈를 직접 업데이트
실제로 무언가를 변경할 때만 결정을 지속하세요.
다중 라운드 후속 조치
기본값은 1라운드입니다.
사용자가 추가 라운드를 원하는 경우:
- 새로운 질문에 집중
- 필요한 경우에만 이전 평결 포함
- 앵커링 방지 가치를 유지하기 위해 Skeptic을 가능한 한 깨끗하게 유지
안티 패턴
- 코드 리뷰에 council 사용
- 단순히 구현 작업인 경우 council 사용
- 하위 에이전트에 전체 대화 기록 제공
- 최종 평결에서 의견 차이 숨기기
- 중요도에 관계없이 모든 결정을 메모로 지속
관련 스킬
santa-method— 적대적 검증knowledge-ops— 내구성 있는 결정 델타를 올바르게 지속search-first— 필요시 council 전에 외부 참고 자료 수집architecture-decision-records— 결정이 장기 시스템 정책이 될 때 결과를 공식화
예시
질문:
ECC 2.0을 지금 알파로 출시해야 할까요, 아니면 컨트롤 플레인 UI가 더 완성될 때까지 기다려야 할까요?
예상 council 구성:
- Architect는 구조적 완결성과 혼란스러운 표면을 피해야 한다고 주장
- Skeptic은 UI가 실제로 걸림돌인지 의문 제기
- Pragmatist는 신뢰를 해치지 않으면서 지금 무엇을 출시할 수 있는지 질문
- Critic은 지원 부담, 기대 부채, 롤아웃 혼란에 초점
가치는 만장일치가 아닙니다. 가치는 선택하기 전에 의견 차이를 명확히 하는 데 있습니다.