discussion

name	discussion
description	This skill should be used when the user asks to "discuss", "discussion", "토론", "토론하자", "let's discuss", "brainstorm", "논의", "의견 나누기", or wants a structured iterative discussion with research support.
version	1.4.4

discussion

Goal

구조화된 반복 토론으로 주제를 좁히고, 필요한 맥락을 수집하며, 최종적으로 _sdd/discussion/<YYYY-MM-DD>_discussion_<slug>.md에 토론 요약을 저장한다. 구현이나 스펙 수정은 하지 않고, 후속 스킬이 사용할 수 있는 결정과 open question을 정리하는 데 집중한다.

Acceptance Criteria

완료 전 아래 기준을 자체 검증한다. 미충족 항목이 있으면 해당 단계로 돌아가 수정한다.

• AC1: 토론 주제와 범위를 명확히 했다.
• AC2: 필요한 로컬 맥락 또는 최신 외부 사실을 수집했다.
• AC3: 반복 토론 중간에 핵심 논점, 결정, 미결 질문을 추적했다.
• AC4: _sdd/discussion/<YYYY-MM-DD>_discussion_<slug>.md를 생성했다.
• AC5: 최종 요약에 토론 배경/초기 콘텍스트, 논점, 결정, open question, action item이 포함되었다.

Companion Assets

• references/discussion-question-guide.md
• examples/sample-discussion-session.md

Hard Rules

1. 이 스킬은 interactive-only다. request_user_input을 사용할 수 없으면 즉시 중단한다.
2. 코드, 스펙, 설정 파일은 수정하지 않는다. 생성 가능한 파일은 _sdd/discussion/<YYYY-MM-DD>_discussion_<slug>.md 하나뿐이다.
3. Step 1-3은 읽기 전용 탐색만 사용한다.
4. 모든 질문에는 정리/종료 성격의 선택지를 넣는다.
5. 라운드당 질문은 정확히 1개만 한다.
6. 최신성이나 사실 검증이 필요한 내용은 웹 또는 로컬 근거로 먼저 확인한다.
7. 출력 언어와 저장 파일 언어는 사용자의 활성 입력 언어를 따른다.
8. in-scope 미결 종료 차단: 카테고리가 out-of-scope나 deferred-deliberately가 아닌 미결(이하 "in-scope open_questions")이 남은 상태로는 Gate 3→4 외 어떤 경로(수렴 신호, stagnation fallback 등)로도 토론을 종료하지 않는다.

Key Principles

Process의 모든 단계에서 횡단 적용되는 원칙. Hard Rules가 강제 금지라면, Key Principles는 판단 지침이다.

• One question at a time: 한 라운드에 여러 질문을 묶지 않는다. 한 주제가 깊이를 요구하면 여러 라운드로 쪼갠다.
• Multiple choice preferred: 가능하면 MC 형식이 우선. 자유 서술은 사용자가 카테고리로 압축 불가능할 때만 사용.
• YAGNI ruthlessly: 요구사항/범위가 부풀 때 적극적으로 쳐낸다. "지금 필요한가?"를 비판적 개입(3.2.2)의 기본 질문으로 삼는다.
• Explore alternatives (2-3안 + 권장안): Analysis 페이즈에서 AI가 능동적으로 2-3개 구별되는 접근을 제시하고 권장안을 먼저 말한다. 상세는 Step 3.2.1 참조.
• Incremental validation: 수렴은 한 번에 이뤄지지 않는다. 3라운드마다(3.4) 중간 요약으로 이해도를 확인하고, 수렴 신호(3.5)가 감지되면 종료를 권유.
• Be flexible: 새 정보가 기존 결론을 흔들면 페이즈를 되돌린다. 깊이 신호(3.2) 감지 시 phase 무시.
• Respect existing patterns, contain scope: 토론에서 제안되는 변경안은 기존 코드베이스/문서 패턴을 먼저 이해하고 따라야 한다. 작업과 관련된 개선은 토론에 포함하되, 관련 없는 리팩터링/확장 제안은 배제. 범위 드리프트를 감지하면 원래 토픽으로 리마인드.

Process

Step 1: Define the Topic

• 사용자 요청에서 토픽이 이미 있으면 재진술 후 범위를 좁히는 질문 1개를 한다.
• 불명확하면 카테고리 수준에서 묻고, 최대 2라운드 안에 범위를 정한다.
• 범위를 정하지 못하면 이유를 설명하고 중단한다.
• Scope atomicity 점검: 토픽이 다중 독립 서브시스템 묶음(예: "플랫폼 전체", 3개 이상의 독립 영역 나열)이면 서브프로젝트 분해를 제안하고, 사용자와 함께 첫 번째 서브프로젝트만 토론 대상으로 좁힌다. 단일 단위면 이 단계를 건너뛴다.

Decision Gate 1 -> 2: topic_defined AND scope_clear AND scope_is_atomic -> Step 2 진행. ELSE -> 보완 질문 (최대 2라운드). 다중 서브시스템이면 분해 후 단일 서브프로젝트로 좁힌 뒤 게이트 재평가.

Step 2: Gather Context

토픽 유형에 따라 필요한 맥락을 수집한다.

• 코드베이스 관련: 관련 파일, 패턴, 의존성
• 아키텍처/기술 선택: 로컬 구조 + 공식 자료/1차 자료
• 기타 주제: 사용자 맥락 기준으로 탐색

이후 짧은 context summary를 제시한다.

2.1 Initial Context Capture (필수)

Step 2에서 수집한 맥락은 사용자에게 보여주는 일회성 요약으로 끝내지 않고, 최종 요약에 재사용할 수 있도록 initial_context 내부 상태에 보존한다.

initial_context에는 아래를 간결하게 기록한다:

• 사용자 문제 제기: 사용자가 처음 어떤 필요/불편/질문으로 토론을 시작했는지
• 토론을 시작한 배경: 왜 지금 이 토론이 필요한지, 어떤 후속 작업이나 의사결정과 연결되는지
• 현재 상태: 코드베이스/문서/운영 상황 등 확인된 현황
• 범위와 제외 범위: 이번 토론에서 다루기로 한 것과 명시적으로 미룬 것
• 수집한 근거: 로컬 파일, 문서, 외부 자료 등 토론 전제에 영향을 준 자료

이 항목은 결정이나 논점과 중복되더라도 삭제하지 않는다. 목적은 "무엇을 결정했는가"가 아니라 "왜 이 토론이 열렸는가"를 후속 독자가 복원할 수 있게 하는 것이다.

Decision Gate 2 -> 3: context_available AND topic_still_valid -> Step 3 진행. 맥락 없으면 사용자에게 확인. 토픽 무효화 시 Step 1 복귀.

Step 3: Run Iterative Discussion

3.1 토론 루프 구조

내부 상태 추적:
  key_points, decisions, open_questions, action_items, conversation_log, initial_context
  round = 0

  coverage:
    exploration:
      motivation, current_state, constraints, ideal_outcome
    analysis:
      alternatives, tradeoffs, priorities, critical_review
    convergence:
      conclusion, risks, action_items

LOOP:
  round += 1
  1. 질문 선택 (아래 3.2 전략)
  2. ask로 질문 제시 (옵션 2-3개 + "토론 종료")
  3. 사용자 응답 분석 → 내부 상태 + coverage 업데이트
  4. 필요 시 mid-discussion 리서치 수행
  5. 수렴 신호 감지 시 → 종료 권유 (아래 3.5)

  IF 사용자가 "토론 종료" 선택 OR "정리해줘" 입력 → Gate 3→4

3.2 질문 선택 전략 (커버리지 기반 하이브리드)

라운드 번호가 아닌 커버리지 달성도가 페이즈를 결정한다.

매 라운드 질문 선택 로직:

1. 직전 답변에서 "깊이 신호" 감지?
   → YES: 페이즈를 무시하고 후속 질문 (깊이 우선)
   → NO:  2단계로

2. 커버리지 맵에서 현재 페이즈 판정:
   - exploration 미확인 항목 있음 → 탐색 질문
   - exploration 완료, analysis 미확인 있음 → 분석 질문
   - 둘 다 완료 → 수렴 질문

깊이 신호 (페이즈 무시하고 파고드는 트리거):

신호	예시
모순 발견	"빠르게 만들고 싶은데 확장성도 중요해요"
불확실성 표현	"잘 모르겠는데...", "아마..."
새 제약조건 등장	"아, 근데 레거시 API랑 호환돼야 해요"
강한 의견	"이건 절대 안 돼요" → 이유를 파고들기

수렴 전 안전장치: 수렴 페이즈 진입 전 exploration/analysis에 미확인 항목이 있으면 사용자에게 "아직 [항목]을 다루지 않았는데, 넘어가도 괜찮을까요?" 확인.

3.2.1 Alternatives Initiation (필수)

Analysis 페이즈 진입 직후 첫 라운드에, AI는 다음을 반드시 수행한다:

1. 2-3개의 구별되는 접근을 능동적으로 제시. 사용자가 먼저 대안을 꺼낼 때까지 기다리지 않는다.
2. 각 접근에 대해 1-2줄 트레이드오프를 명시.
3. 권장안을 먼저 제시하고 이유를 붙인다. 중립 나열만 하지 않는다.
4. request_user_input의 옵션으로 각 접근을 제시하거나, 텍스트로 제시한 뒤 후속 request_user_input으로 선택을 유도.

단, 사용자가 이미 명시적으로 특정 방향을 고정했다면 이 단계를 건너뛰고 바로 비판적 개입(3.2.2)으로 진행한다.

커버리지 체크: alternatives 항목은 이 능동 제시가 수행되고 사용자 응답이 있은 뒤에만 완료로 표시한다.

3.2.2 비판적 개입 (Critical Review)

분석 페이즈에서는 최소 1회 비판적 질문으로 약점이나 숨은 가정을 검증한다.

• 사용자가 특정 방향에 합의/선호를 표현하면 그 방향에 대해 비판적 질문을 우선 제시한다.
• 사용자가 끝까지 중립 비교 상태라면, 현재 가장 가능성이 높은 방향이나 공통 가정을 임시 가설로 잡고 비판적 질문을 1회 수행한다.
• 임시 가설도 성립하지 않으면 "가장 우려되는 실패 시나리오" 또는 "지금 가정이 틀리면 무엇이 깨지는지"를 묻는 방식으로 critical_review를 충족한다.

비판적 개입 유형:

유형	언제	예시
약점 지적	방향이 정해졌을 때	"이 방식이면 X 상황에서 문제가 될 수 있는데, 어떻게 생각하세요?"
반례 제시	장점만 언급될 때	"비슷한 접근을 한 Y 사례에서는 Z 문제가 있었어요"
숨은 가정 질문	전제가 검증 안 됐을 때	"이건 A라는 가정 위에 서 있는데, 그게 깨지면요?"
대안 제안	탐색 범위가 좁을 때	"다른 관점에서 보면 이런 접근도 가능한데, 고려해 보셨나요?"
스케일 도전	현재 규모만 고려할 때	"지금은 괜찮지만 10배 커지면 이 구조가 버틸까요?"
YAGNI / 범위 축소	요구사항이 부풀 때	"이 기능이 지금 꼭 필요한가요? 없으면 무엇이 깨지나요?"

강도 조절 규칙:

1. 연속 2라운드 이상 비판 금지 → 반드시 건설적 질문 삽입
2. 비판 후에는 대안이나 보완책을 함께 제시
3. 사용자가 이미 반박한 약점은 재차 제기하지 않음
4. 비판은 "질문" 형태로 — 단정이 아니라 탐색 유도

커버리지 체크: critical_review는 분석 페이즈에서 최소 1회 비판적 개입이 이루어지고 사용자가 응답했을 때 완료로 표시한다. 선호가 없는 비교형 토론도 fallback 비판 질문으로 완료 가능해야 한다. 비판적 검토 없이 수렴으로 넘어가는 것을 방지한다.

3.2.3 Soft Deferral Handling (묵시적 떠넘김 차단)

사용자가 토론 중 묵시적 deferral 신호(예: "나중에 보죠", "그건 구현하면서", "지금은 모르겠는데", "일단 넘어가요")를 보이면, AI는 메타-분류 질문을 사용자에게 노출하지 않고 내부적으로 다음 분류를 수행한다.

분류	조건	AI 처리
(a) 지금 답 가능	한 가지 구체 질문으로 좁히면 사용자가 토론 내에서 답할 수 있다	좁힌 1회 재질문(1라운드 한정, 3.2.2 비판 카운트에서 제외). 그래도 답 못 하면 (b)로 강등
(b) 토론 외부 deferred	다른 작업/외부 데이터 대기/명확한 분리가 정당함	open_questions에 카테고리 deferred-deliberately 또는 needs-data로 조용히 기록
(c) 다른 미결 의존	동일 토론 내 다른 미결 질문이 풀려야 답 가능	blocked-by:Q<n> 라벨로 기록하고, 의존하는 Q를 다음 라운드 우선 주제로 채택

규칙:

1. 분류는 AI 내부 추론으로만. "이거 (a/b/c) 중 뭐죠?" 같은 메타 질문을 표면에 노출하지 않는다 (fatigue 방지).
2. 묵시적 deferral을 그냥 받아 open_questions에 in-scope로 적재하는 행위는 금지. 반드시 위 분류를 거친다.

3.3 Mid-Discussion Research

토론 중 근거가 필요하면 리서치를 즉시 수행:

트리거	액션
"추가 리서치 필요" 선택	웹/외부 자료 검색
코드베이스 확인 필요	로컬 파일 탐색
사실 확인 필요한 주장	공식 문서/1차 자료 확인

독립적인 리서치 2건 이상이면 병렬 수행.

3.4 중간 상태 추적

매 3라운드마다 (또는 사용자 요청 시) 핵심 논점/결정 사항/미결 질문/실행 항목 카운트를 중간 요약 테이블로 제시.

3.5 수렴 신호 감지 및 종료 유도

라운드 수 제한 없이, 아래 수렴 신호가 충분히 감지되면 종료를 권유한다.

수렴 신호:

신호	감지 기준
반복 합의	사용자가 연속 2라운드 이상 동의/확인 응답
새 정보 없음	직전 라운드에서 key_points/decisions에 추가된 항목 없음
명시적 만족	"좋아요", "그걸로 하죠", "충분해요" 등
커버리지 충족	exploration + analysis 항목 모두 완료

2개 이상 신호 동시 감지 시:

"지금까지 [N]개 논점을 다루고 [M]개 결정을 내렸습니다.
 정리해도 좋을 것 같은데, 더 논의할 내용이 있으신가요?"
 1) "정리해줘"
 2) "[추가 논의 주제 제안]"

사용자가 추가 논의를 선택하면 계속 진행한다. 종료를 강제하지 않는다.

가드: in-scope open_questions이 1건 이상이면 위 수렴 신호가 충족돼도 종료 권유 메시지를 발화하지 않는다. 대신 해당 미결을 다음 라운드 주제로 자동 채택한다 (blocked-by:Q<n> 의존이 있으면 의존하는 Q를 우선).

3.5.1 Stagnation Fallback

토론이 길어지더라도 단순 라운드 수로 종료하지 않는다. 대신 아래 정체(stagnation) 신호를 본다.

stagnation 신호:

신호	감지 기준
새 정보 없음	연속 라운드에서 key_points나 decisions가 늘지 않음
미결 질문 정체	같은 open question이 재진술되지만 진전이 없음
반복 유보	사용자가 연속적으로 모호한 답변, 유보, "더 봐야 할 것 같아요" 류 응답을 함

stagnation 대응 규칙:

1. stagnation 신호가 2회 연속 감지되면 질문 범위를 강제로 좁힌다.

2. 이때 노출할 옵션은 in-scope open_questions 유무에 따라 다르다. 중요: "남은 미결 1개만 더 논의" 옵션을 제시할 때는 generic 문구만 단독으로 쓰지 않고, 반드시 대상 미결 질문의 짧은 요약을 옵션 라벨이나 질문 본문에 함께 노출한다.

   상태	노출 옵션
   in-scope open_questions 0건	"지금까지 정리" / "남은 미결 1개만 더 논의: [질문 요약]"
   in-scope open_questions 1건+	"남은 미결 1개만 더 논의: [질문 요약]" 만

3. 여기서 [질문 요약]은 사용자가 눌러보기 전에도 무엇을 더 논의하는지 알 수 있을 정도로 구체적이어야 한다. 미결이 여러 개면 다음 우선순위로 1개를 고른다: blocked-by로 다른 질문들을 막고 있는 선행 질문 > 가장 최근 라운드에서 반복 정체된 질문 > 범위를 가장 많이 줄일 수 있는 질문.

4. "남은 미결 1개만 더 논의: [질문 요약]"를 선택했는데 다음 라운드도 stagnation이면, 남은 쟁점을 open question으로 기록하고 Gate 3→4로 이동한다 (Step 4 직행 금지 — 카테고리 라벨링이 필요하다).

5. 이 fallback은 토론을 강제로 닫기 위한 것이 아니라, 진전 없는 반복을 요약 가능한 상태로 전환하기 위한 것이다.

Gate 3→4: 미결 질문(open_questions)을 확인한다.

• 0건 → Step 4 진행
• 1건+ → 미결 질문 목록을 짧은 요약과 함께 제시하고 request_user_input으로 추가 논의 여부를 확인한다. 이때 추가 논의 옵션도 generic 문구 대신 "이 질문 더 논의: [질문 요약]" 형식으로 노출한다. 추가 논의 선택 시 Step 3 루프 복귀, "그대로 정리(미결로 기록)" 선택 시 카테고리 라벨링 강제 후 Step 4 진행.

카테고리 라벨링 강제 절차 ("그대로 정리" 선택 시):

1. 모든 미결 질문에 대해 카테고리를 부여한다. 각 미결 질문은 request_user_input의 별도 단일선택 질문으로 제시하며, 한 번 호출에는 최대 3개 질문만 담는다. 미결 질문이 4개 이상이면 여러 번 순차 호출해 모두 라벨링한다. 카테고리는 다음 4종 고정:
   • out-of-scope — 이 토론 범위 밖이며 별도 토론으로 분리 예정
   • needs-data — 외부 데이터/벤치마크/실측이 있어야 답 가능
   • deferred-deliberately — 의도적 보류 (후속 작업/이해관계자 대기 등)
   • blocked-by:Q<n> — 동일 토론 내 다른 미결 질문 번호 의존
2. 사용자가 일부 항목 라벨을 비워두면, AI가 토론 맥락에서 가장 가능성 높은 카테고리를 추정해 기본값으로 채우되, 반드시 Step 4 요약의 해당 행에 (auto-labeled, please review) 노트를 붙인다.
3. 카테고리 없는 미결 질문이 단 1건이라도 남으면 Step 4로 진행하지 않는다.
4. 카테고리 라벨링 후 in-scope open_questions이 여전히 있으면 사용자에게 한 번 더 "in-scope 미결이 N건 남아 있습니다. 정말 그대로 종료하시겠어요?"를 확인하고, 사용자가 명시적으로 동의해야 종료한다 (Gate 3→4의 user-confirm 단계).

Step 4: Write the Discussion Summary

_sdd/discussion/<YYYY-MM-DD>_discussion_<slug>.md에 아래를 저장한다.

• 토론 배경 및 초기 콘텍스트
• 핵심 논점
• 결정 사항
• 미결 질문
• 실행 항목
• 리서치 결과 요약
• sources
• 토론 흐름

파일명은 영문 slug를 사용하고, _sdd/discussion/가 없으면 생성한다.

Output Contract

기본 산출물: _sdd/discussion/<YYYY-MM-DD>_discussion_<slug>.md

파일명은 <YYYY-MM-DD>_discussion_<slug>.md 패턴을 사용한다. slug는 영문 소문자, 특수문자는 _로 대체, 최대 50자 (예: "인증 시스템 설계" → 2026-04-10_discussion_auth_system_design.md).

요약 출력 형식

# 토론 요약: [토픽]

**날짜**: YYYY-MM-DD
**라운드 수**: N
**참여 방식**: 구조화된 토론 (discussion skill)

## 토론 배경 및 초기 콘텍스트 (Background / Initial Context)
- **사용자 문제 제기**: [사용자가 처음 제기한 필요, 불편, 질문]
- **토론을 시작한 배경**: [왜 지금 이 토론이 필요한지 / 어떤 후속 작업과 연결되는지]
- **현재 상태**: [토론 전에 확인한 코드베이스, 문서, 운영 상황 등]
- **범위와 제외 범위**: [이번 토론에서 다룬 범위와 의도적으로 미룬 범위]
- **수집한 근거**: [토론 전제에 영향을 준 로컬 파일, 문서, 외부 자료]

## 핵심 논점 (Key Discussion Points)
1. [논점 1]: [요약]
2. [논점 2]: [요약]

## 결정 사항 (Decisions Made)
| # | 결정 | 근거 | 관련 논점 |
|---|------|------|----------|
| 1 | ... | ... | ... |

## 미결 질문 (Open Questions)
| # | 질문 | 카테고리 | 맥락 / 의존 |
|---|------|----------|-------------|
| 1 | [질문 1] | needs-data | [맥락] |
| 2 | [질문 2] | blocked-by:Q1 | Q1이 풀려야 답 가능 |

> 카테고리: `out-of-scope` / `needs-data` / `deferred-deliberately` / `blocked-by:Q<n>` 중 하나. AI가 자동 부여한 항목은 `(auto-labeled, please review)` 표기.

## 실행 항목 (Action Items)
| # | 항목 | 우선순위 | 담당 |
|---|------|---------|------|
| 1 | ... | High/Medium/Low | ... |

## 리서치 결과 요약 (Research Findings)
- [수집 항목 1]: [핵심 발견]

## 토론 흐름 (Discussion Flow)
Round 1: [주제] → [결론/방향]
...

## 부록: 대화 로그 (Conversation Log)

### Round 1
**Q**: [질문 내용]
**Options**: 1) ... 2) ... 3) ... 4) 토론 종료
**A**: [사용자 응답 요약]
**Follow-up**: [AI 분석/코멘트 요약]
...

Error Handling

상황	대응
request_user_input 불가	즉시 중단
토픽 불명확	최대 2라운드 범위 질문 후 중단
로컬 맥락 부족	범위를 좁히거나 현재 정보 기준으로 계속할지 확인
외부 리서치 실패	실패 사실을 밝히고 수집된 맥락만으로 진행
토론이 지나치게 길어짐	stagnation 신호를 확인하고 "지금 정리 / 미결 1개만 더 논의"로 범위를 축소

Final Check

Acceptance Criteria가 모두 만족되었나 검증한다. 미충족 항목이 있으면 해당 단계로 돌아가 수정한다.