@simplysm/sd-claude 14.0.63 → 14.0.64

package/claude/references/sd-simplysm-v14/sd-claude/assets.md

@@ -67,12 +67,13 @@ description: 전체 변경사항에 대한 단일 커밋을 생성하는 스킬.
 
 ## `claude/rules/`
 
-Claude Code 규칙 파일. 2개 파일.
+Claude Code 규칙 파일. 3개 파일.
 
 | 파일                 | Description                                                          |
 | -------------------- | -------------------------------------------------------------------- |
 | `sd-claude-rules.md` | 금지 명령어, 도구 사용 규칙, 코딩 규칙, 대화 규칙, 패키지 참조 규칙 |
-| `sd-clarify.md`      | 명확화 절차(근거 확인·분류·보고)와 질문 형식(선택지·평가표·도구 호출) |
+| `sd-clarify.md`      | 결정 사안 명확화 절차 (근거 확인·분류·재분석·보고)                  |
+| `sd-ask.md`          | 사용자 질문/선택지 제시 형식 (5블록·평가표·도구 호출)                |
 
 ## `claude/references/`
 

package/claude/rules/sd-ask.md

@@ -0,0 +1,242 @@
+# sd-ask: 사용자 질문/선택지 제시 형식
+
+사용자에게 질문하거나 선택지를 제시할 때 본 지침을 적용한다.
+
+## 필수 의무
+
+- 다음 사유로 질문을 생략하지 않는다: "이 정도 질문은 과하다", "단순 확인이니 생략".
+- 단일 경로만 합리적이라 느껴질 때도, "수행 안 함"을 포함한 선택지 구조로 제시한다.
+
+## 질문 운영
+
+- 질문 대기열 우선: 사용자 답변이 필요한 항목이 있으면 질문 대기열에 등록한다.
+  - 사용자 답변으로 새 질문이 생기면 후속 프로세스를 시작하지 말고 질문 대기열에 추가한다.
+- 한 번에 하나씩: 질문은 한 번에 하나씩 제시한다.
+  - 각 질문마다 사용자 답변을 받은 뒤 다음 질문을 제시한다.
+- 결정 대상 분리: 한 질문은 하나의 결정 대상만 다룬다.
+  - 결정 대상이 N개면 질문 N개로 분리한다.
+  - 여러 결정 대상을 조합·번들 옵션(예: "A+B+C 모두 수정" vs "A만" vs "B만")으로 묶어 제시 금지.
+- 답변 누적: 앞선 질문의 답변은 저장된 결정으로 취급한다.
+  - 다음 질문을 하거나 전체 답변 수집을 완료하기 전까지, 앞선 답변에 따른 수정·실행·해결 프로세스를 시작하지 않는다.
+- 실행 시작 조건: 질문 대기열이 비고 모든 필수 질문의 답변을 받은 뒤에만 수정·실행·검증 등 후속 프로세스를 시작한다.
+- 누락 답변 처리: 사용자가 현재 질문에 답하지 않으면 같은 질문을 다시 묻는다.
+  - 누락 항목을 임의 추천안으로 처리하지 않는다.
+- 추가 질문 처리: 답변 수집 중 또는 작업 중 새로 물어봐야 할 항목이 발견되면 질문 대기열에 추가하고, 다시 한 번에 하나씩 질문한다.
+- 질문 정렬: 의존성 → 정보이득 → 발견 출처 순.
+  - 의존성 우선: 상위 결정이 하위에 영향을 미치면 상위 먼저.
+  - 정보이득 내림차순: 동일 의존성 내에서 상→중→하.
+    - 상: 라우터·스키마·아키텍처 등 광범위 영향
+    - 중: 모듈/컴포넌트 내 영향
+    - 하: 단일 위치 영향
+  - 발견 출처 묶음: 동일 정보이득 내에서 Step/Feature 번호·대상 식별자 단위로 묶음. 한 묶음 소진 후 다음 묶음. 진행 중 묶음에서 발견된 새 질문은 해당 묶음 끝에 추가.
+
+## 도구 호출
+
+- 5블록 형식 출력 후 즉시 `AskUserQuestion` tool을 호출하여 응답을 종료한다.
+  - 텍스트로 "진행할까요?" 묻고 응답을 대기하지 않는다.
+  - `AskUserQuestion`이 deferred tool로 표시되어 있으면 먼저 `ToolSearch query="select:AskUserQuestion"`로 스키마를 로드한 뒤 호출한다.
+  - `AskUserQuestion`의 선택지는 평균 점수 내림차순으로 정렬하여 전달한다. 동점이면 추천안을 우선 배치한다.
+  - 선택지는 5블록 선택지 헤더의 prefix(`A.`, `B.`, `C.`, `D.`)와 평균점수를 포함하여 전달한다 (예: `A. 모달 차단 (8.6)`). prefix는 정렬 후 재부여하지 않고 5블록 헤더에 부여한 값을 그대로 유지한다.
+
+## 선택지 제시 형식 (5블록)
+
+각 질문은 다음 5개 블록을 순서대로 출력한다.
+
+1. 결정 대상 헤더 (`### 결정 대상: ...`)
+2. 컨텍스트 블록 (`#### 컨텍스트`)
+3. 선택지 블록 (`#### 선택지` + 각 선택지 `##### A. ...`)
+4. 평가표 블록 (`#### 평가표`)
+5. 예시 블록 (`#### 예시`)
+
+단, 5번 예시 블록은 조건 충족 시에만 출력한다 (조건은 5번 블록 정의 참조).
+
+모든 블록 헤더는 백틱으로 감싼 텍스트로 작성한다 (sd-response-format 헤더 표기 룰).
+
+블록마다 자기 완결: 사용자가 위쪽으로 스크롤하지 않고도 해당 블록 내용만으로 판단 가능해야 한다.
+발견사항 N건의 통합 분석을 위쪽에 길게 몰아 쓰지 않는다 (필요 시 1~3줄 개괄만 허용).
+
+사용자 출발선 자기완결: 5블록 전체 텍스트는 사용자가 이미 본 정보만으로 의미가 통해야 한다.
+- 허용 출처: 누적 맥락(사용자 발언·기존 tool 결과·세션 산출물), 인용된 코드·문서, 일반 도메인 어휘.
+- 금지: Claude 사고과정에서만 도출된 중간 개념·용어·전제·약어를 그대로 노출하는 것.
+- 사고과정 산물을 꼭 써야 하면 그 개념을 만드는 과정 자체를 컨텍스트 블록에 풀어 설명한다. 풀이 불가능하면 그 개념 자체를 별도 결정 대상으로 끌어올린다.
+
+### 1. 결정 대상 헤더
+
+- 다건: `### 결정 대상 {번호}/{전체}: {대상 식별자/경로:라인}`
+- 단건: `### 결정 대상: {대상 식별자/경로:라인}`
+
+### 2. 컨텍스트 블록
+
+결정 대상 헤더 직후에 풀로 기술한다. 다음을 모두 포함한다.
+
+- 현재 상태 인용 (파일경로:라인 + 코드/문서 발췌)
+- 발견 요지 (왜 이 결정이 필요한지)
+- 결정해야 할 사안 (무엇을 묻는지를 풀어서 기술)
+- (sd-clarify Step 2를 거친 경우) 해당 건의 분류 결과 → 재분석 결과 (+변경 혹은 미변경의 사유)
+
+다음 형태로 대체 금지: "핵심 질문: ..." 한 줄 요약, "{대상} 처리" 축약, 위쪽 통합 분석 참조("발견 1 처리" 등).
+
+### 3. 선택지 블록
+
+각 선택지를 다음 관점으로 제시한다.
+
+- 변경 후 모습: 각 선택지를 동일 관점의 코드블록·구조도·시그니처로 나란히 제시 (정/부 대비는 ```diff 블록 권장).
+- 영향 범위: 파급되는 파일·모듈·API (구현·작업 비용도 여기 서술).
+
+원칙: 사용자가 원문을 찾지 않아도 이 출력만으로 판단 가능해야 한다.
+
+### 4. 평가표 블록
+
+평가축 3개 이상 선정 후 단일 매트릭스 표 1개로 표시한다.
+
+- 평가축은 결정 결과의 사용자 가치만 측정 (구현·작업 비용은 3. 선택지 블록 영향 범위에 서술).
+- 모든 평가축은 "높을수록 좋음" 방향으로 통일.
+- 행 = 선택지(평균 내림차순), 열 = 평가축 + 평균.
+- 축별 점수를 반드시 노출한 뒤 평균을 10점 만점으로 병기 (최종 점수만 표기 금지).
+- 표 직후 인용블록으로 추천을 한 줄 명시: `> 추천: {선택지} — {사유 한 줄}`.
+
+점수 산정:
+
+- 사용자 원안 보호: 사용자가 직접 제시한 안은 변형안과 동등 이상 점수를 기본값으로 한다.
+  - 깎으려면 깎이는 구체 시나리오 인용 필수.
+- 추상가치 깎기 금지: `일관성`·`직관성`·`보존`·`확장성` 같은 추상명사 단독으로 점수 깎지 않는다.
+  - 깎으려면 구체 시나리오 1개 이상 인용.
+- 변형안 도입 책임: 원안 외 변형안을 추가할 때 "원안의 어떤 결함을 어떤 메커니즘으로 해결하는가"를 한 줄로 변형안의 선택지 헤더 직후에 명시한다.
+
+예시:
+
+| 선택지 | 일관성 | 직관성 | 워크플로 보존 | 평균 |
+|---|---|---|---|---|
+| A. xxx | 10 | 10 | 7 | `9.0` |
+| B. yyy | 6 | 7 | 9 | `7.3` |
+| C. 수행 안 함 | 2 | 10 | 5 | `5.7` |
+
+> 추천: A — 워크플로 보존이 1단계 낮지만 일관성·직관성이 모두 최상
+
+### 5. 예시 블록
+
+다음 조건 중 하나에 해당할 때만 평가표 블록 직후 출력한다.
+
+- 옵션 라벨만으로 결과 차이를 추정하기 어려운 경우
+- 추상 정책·UX 변경 등 구체 입력값으로 환원해야 이해 가능한 경우
+
+`AskUserQuestion` 호출 직전에만 가로선을 둔다 (4와 5 사이 가로선 없음).
+목적: 사용자가 이 블록만 읽어도 결정 가능하도록 한다.
+
+양식은 자유. 다음 원칙만 지킨다.
+
+- 구체 입력값/상황으로 환원해 결과를 보여줄 것
+- 추상 옵션 라벨을 그대로 반복하지 말 것
+- 결정의 성격(코드 비교·수치 대비·정책 풀이 등)에 맞는 가장 직관적인 형식을 선택할 것
+
+양식 예시:
+
+- 코드 비교: 변경 전후 `diff` 블록 1쌍
+- 수치 비교: 입력값별 결과를 짧은 불릿 1~2줄로 정리
+- 정책 풀이: 옵션 라벨 없이 시나리오 결과만 풀어쓴 1~2문단
+- 옵션 나열: 옵션 라벨 + 결과 불릿 (적용 예시 참조)
+
+금지:
+
+- 표 사용: 평가표(4번)와 형식 중복.
+- 시간 순서 시나리오 흐름: "X 입력 → 모달 → 닫기 → 재입력" 같은 흐름이 아니라 결과 자체를 정리.
+- AskUserQuestion 옵션과 단순 중복: 라벨·설명만 반복하지 말고 그것이 보여주지 못하는 구체 결과값으로 환원.
+
+어휘:
+
+- 최종 사용자(최종고객) 업무 도메인 표현으로 작성한다.
+- 시스템 내부 용어(코드 식별자·메타 분류·내부 변수명·파일 경로 등) 노출 금지.
+
+## 적용 예시
+
+가상의 결정 1건을 5블록 형식으로 풀어쓴 예시. 헤더는 차례로 1. 결정 대상 헤더 → 2. 컨텍스트 → 3. 선택지 → 4. 평가표 → 5. 예시에 대응한다.
+
+````markdown
+`### 결정 대상: 발주 입력 시점 재고 부족 표시 방식`
+
+`#### 컨텍스트`
+
+현재 상태 인용 — `packages/order-app/src/pages/OrderPage.tsx:142`:
+
+```ts
+async function onQtyChange(itemId: string, qty: number) {
+  await orderStore.setQty(itemId, qty);
+  // 재고 부족 시 별도 처리 없음
+}
+```
+
+발견 요지: 재고보다 많은 수량을 입력해도 입력이 그대로 통과되어 결제 진입 시점에야 차단된다. 사용자는 입력 시점에 부족 사실을 알 수 없다.
+
+결정 사안: 입력 시점에 어떤 방식으로 부족을 알릴 것인가.
+
+분류: 추측 유지 (UX 정책 결정 필요).
+
+`#### 선택지`
+
+`##### A. 모달 팝업 차단`
+
+결제 도달 전 입력 시점에 즉시 부족 차단.
+
+```diff
+ async function onQtyChange(itemId: string, qty: number) {
++  const stock = await stockStore.get(itemId);
++  if (qty > stock) {
++    await alertModal.show(`재고가 ${stock}개 남았어요. 수량을 줄여주세요.`);
++    return;
++  }
+   await orderStore.setQty(itemId, qty);
+ }
+```
+
+`##### B. 인라인 경고 + 입력 유지`
+
+결제 도달 전 부족 인지 + 입력 흐름 보존.
+
+```diff
+ async function onQtyChange(itemId: string, qty: number) {
++  const stock = await stockStore.get(itemId);
+   await orderStore.setQty(itemId, qty);
++  if (qty > stock) showInlineWarning(itemId, `재고 ${stock}개`);
++  else clearInlineWarning(itemId);
+ }
+```
+
+`##### C. 수행 안 함`
+
+현 동작 유지. 결제 진입 시점 차단만 작동.
+
+영향 범위:
+- A: 모달 컴포넌트 추가, `onQtyChange`만 수정
+- B: 자재 입력 행 경고 슬롯 + 결제 버튼 활성화 조건 — 3곳 수정
+- C: 없음
+
+`#### 평가표`
+
+| 선택지 | 부족 인지 속도 | 입력 흐름 보존 | 실수 방지 | 평균 |
+|---|---|---|---|---|
+| B. 인라인 경고 | 8 | 10 | 9 | `9.0` |
+| A. 모달 차단 | 10 | 4 | 10 | `8.0` |
+| C. 수행 안 함 | 2 | 10 | 4 | `5.3` |
+
+> 추천: B — 입력 흐름을 끊지 않으면서도 부족 사실이 즉시 인지됨
+
+`#### 예시`
+
+사용자가 발주 화면에서 X(재고 5개), Y(재고 10개), Z(재고 3개)에 각각 7, 8, 5 입력을 시도 했음.
+
+질문: 입력 시점에 재고 부족을 어떻게 표시할까?
+
+옵션 A) 모달 팝업 차단
+- X 입력 시 모달, Y 통과, Z 입력 시 모달
+- 모달 2번 떠, X·Z를 따로 닫고 재입력 해야하여 비효율
+
+옵션 B) 인라인 경고 + 입력 유지
+- X 옆 `재고 5개` 배지, Z 옆 `재고 3개` 배지 동시 표시
+- 담당자가 한 화면에서 X·Z를 한 번에 수정할 수 있음
+
+옵션 C) 수행 안 함
+- X·Y·Z 입력 모두 통과 → 결제 클릭 시 "부족" 알림
+- 어떤 자재가 부족한지 입력 화면 가서 다시 확인해야함
+````
+
+(이 직후 `AskUserQuestion` 호출)

package/claude/rules/sd-clarify.md

@@ -1,16 +1,19 @@
 # sd-clarify: 명확화 지침
 
+명확화가 필요한 사안이 있을 때 본 지침을 적용한다.
 결정 사안의 명확성을 분류하고, 불명확한 항목은 사용자 질문을 통해 확정한다.
 
 결정 사안 = 작업 수행을 위해 확정해야 하는 개별 결정 항목 (의도, 방식, 동작, 값 등).
+결정 대상 = 결정 사안의 식별자/타깃 (헤더·표에 노출되는 이름).
 
 ## 전체 흐름
 
 ```
 Step 1: 결정 사안 식별
   ├─ 결정 사안 있음 → Step 2: 명확화 (근거 확인 → 분류 → 재분석 → 보고)
-  │                     └─ 불명확 항목 → Step 3: 질문 진행
-  └─ 결정 사안 없음 ────→ Step 3: 질문 진행 (질문할 것이 있을 때만)
+  │                     ├─ 모두 명확 → 분류 보고 후 종료
+  │                     └─ 불명확 항목 있음 → sd-ask 적용
+  └─ 결정 사안 없음 → 종료
 ```
 
 ## Step 1: 결정 사안 식별
@@ -29,7 +32,7 @@ Step 1: 결정 사안 식별
 분기:
 
 - 결정 사안 있음 → Step 2로 진행한다.
-- 결정 사안 없음 → Step 2를 건너뛰고, 질문할 것이 있으면 Step 3으로 진행한다.
+- 결정 사안 없음 → 본 지침을 종료한다.
 
 ## Step 2: 명확화
 
@@ -48,7 +51,7 @@ UI 구조·메뉴/네비게이션·라우팅·도메인 엔터티·네이밍·
 근거 추측 금지:
 
 - 출처 인용은 실제 읽은 좌표만 허용한다.
-- 미확인 출처(예: "~~ 문서에 있을 것", "보통 ~~ 패턴이니")로 확정 또는 추론 90% 이상으로 분류 금지.
+- 미확인 출처(예: "~~ 문서에 있을 것", "보통 ~~ 패턴이니")로 90% 이상 분류 금지.
 - "어차피 모를 것"이라는 판단으로 근거 확인을 건너뛰는 것 금지.
 
 ### 2-2. 명확성 분류
@@ -69,17 +72,17 @@ UI 구조·메뉴/네비게이션·라우팅·도메인 엔터티·네이밍·
     - 그 외 약한 유추나 제한적 근거
 - 추측 (0%): 근거 없는 가정
 
-추론 % 사용 규칙:
+% 사용 규칙:
 
 - 미세 차등(±10% 내)으로 의사결정을 분기하지 않는다.
 - 임계값 1개로만 이진 판단을 한다.
-  - 추론 90% 이상 → 진행
-  - 추론 90% 미만 → 질문 대기열 등록
+  - 90% 이상 → 진행
+  - 90% 미만 → 질문 대기열 등록
 - 임계값을 미세 조정해 질문을 회피하지 않는다.
 
 ### 2-3. 근거 재분석
 
-추론 90% 미만 또는 추측으로 분류된 항목 전부를 재분석한다 (일부만 적용 금지).
+90% 미만으로 분류된 항목 전부를 재분석한다 (일부만 적용 금지).
 항목별 1건씩 처리한다 (그룹·묶음 일괄 처리 금지).
 
 목적: 초기 분류가 부실한 분석에 기반했을 수 있다. 누적 맥락에서 이미 아는 것 이상으로, 해당 건의 근거가 될 수 있는 원본을 완독하여 실제 상황을 파악한 뒤 재분류한다.
@@ -90,8 +93,8 @@ UI 구조·메뉴/네비게이션·라우팅·도메인 엔터티·네이밍·
 - 이미 아는 것만으로 확정할 수 없는 부분을 식별한다.
 - 그 부분의 근거가 될 수 있는 원본을 tool로 완독한다. 발췌·부분 읽기가 아니라 해당 원본 전체를 읽는다.
 - 완독한 실제 상황을 기반으로 2-2 기준에 따라 재분류한다.
-  - 근거 발견 시 분류를 갱신한다 (확정 또는 추론 % 로 갱신).
-  - 근거 미발견 시 기존 분류를 유지하되, 완독 과정에서 파악한 실제 상황을 기반으로 선택지를 구성한다.
+  - 근거 발견 시 % 를 갱신한다.
+  - 근거 미발견 시 기존 % 를 유지하되, 완독 과정에서 파악한 실제 상황을 기반으로 선택지를 구성한다.
 
 금지:
 
@@ -103,131 +106,20 @@ UI 구조·메뉴/네비게이션·라우팅·도메인 엔터티·네이밍·
 
 결정 사안별로 (재확인 후) 최종 분류 결과를 다음 표 양식으로 보고한다.
 
-| 대상 | 원분류 | 재분석분류 | 인용 |
-|---|---|---|---|
-| {식별자/경로:라인} | 추론 60% | 확정 | path/file.ts:42 — "..." |
-| {식별자2} | 추측 | 추측 | (없음 — 질문 대기열 등록) |
+| 대상 | 분류 | 인용 |
+|---|---|---|
+| {식별자/경로:라인} | 60% → 100% | path/file.ts:42 — "..." |
+| {식별자2} | 0% | (없음 — 질문 대기열 등록) |
 
-- 원분류: 근거 확인 직후 분류 결과.
-- 재분석분류: 근거 재분석 후 분류 결과 (갱신 또는 유지).
-- 인용: 확정 / 추론 90% 이상만 출처 인용 작성.
-  - 추측은 "(없음 — 질문 대기열 등록)" 표기.
+- 분류는 % 로만 표기한다 (확정/추론/추측 라벨 노출 금지).
+  - 100% = 확정, 0% = 추측, 그 외 = 추론.
+- 분류 표기: 재분석으로 변화가 있으면 `원% → 재분석%` 형식. 변화 없으면 단일 % 표기.
+- 인용: 90% 이상만 출처 인용 작성. 좌표 + 1~2문장 발췌가 드러나도록 작성한다.
+  - 0%는 "(없음 — 질문 대기열 등록)" 표기.
 
 결정 사안이 다건이면 항목별로 각각 분류하고, 명확/불명확을 한 번에 일괄 보고한다.
 
 분기:
 
-- 근거 명확(확정 / 추론 90% 이상)만 있음: 출처 인용을 호출자에게 보고하고 종료.
-- 근거 불명확(추론 90% 미만 / 추측) 항목 있음: 질문 대기열에 등록하고 Step 3으로 진행한다.
-
-## Step 3: 질문 진행
-
-사용자에게 질문하는 모든 출력에 적용한다 (Step 2 발동 여부와 무관).
-
-필수 의무:
-
-- "이 정도 질문은 과하다", "단순 확인이니 생략"은 위반이다.
-- 단일 경로만 합리적이라 느껴질 때도, "수행 안 함"을 포함한 선택지 구조로 제시한다.
-
-질문 운영:
-
-- 질문 대기열 우선: 사용자 답변이 필요한 항목이 있으면 질문 대기열에 등록한다.
-  - 사용자 답변으로 새 질문이 생기면 후속 프로세스를 시작하지 말고 질문 대기열에 추가한다.
-- 한 번에 하나씩: 질문은 한 번에 하나씩 제시한다.
-  - 각 질문마다 사용자 답변을 받은 뒤 다음 질문을 제시한다.
-- 결정 대상 분리: 한 질문은 하나의 결정 대상만 다룬다.
-  - 결정 대상이 N개면 질문 N개로 분리한다.
-  - 여러 결정 대상을 조합·번들 옵션(예: "A+B+C 모두 수정" vs "A만" vs "B만")으로 묶어 제시 금지.
-- 답변 누적: 앞선 질문의 답변은 저장된 결정으로 취급한다.
-  - 다음 질문을 하거나 전체 답변 수집을 완료하기 전까지, 앞선 답변에 따른 수정·실행·해결 프로세스를 시작하지 않는다.
-- 실행 시작 조건: 질문 대기열이 비고 모든 필수 질문의 답변을 받은 뒤에만 수정·실행·검증 등 후속 프로세스를 시작한다.
-- 누락 답변 처리: 사용자가 현재 질문에 답하지 않으면 같은 질문을 다시 묻는다.
-  - 누락 항목을 임의 추천안으로 처리하지 않는다.
-- 추가 질문 처리: 답변 수집 중 또는 작업 중 새로 물어봐야 할 항목이 발견되면 질문 대기열에 추가하고, 다시 한 번에 하나씩 질문한다.
-- 질문 정렬: 의존성 → 정보이득 → 발견 출처 순으로 정렬한다.
-  1. 의존성 우선: 상위 결정이 하위에 영향을 미치면 상위 먼저.
-  2. 동일 의존성 내에서 정보이득 상/중/하 내림차순.
-     - 정보이득 = 응답이 후속 작업의 분기·영향 범위를 가르는 정도.
-       - 상: 라우터·스키마·아키텍처 등 광범위 영향
-       - 중: 모듈/컴포넌트 내 영향
-       - 하: 단일 위치 영향
-  3. 동일 정보이득 내에서 발견 출처(Step/Feature 번호/대상 식별자) 단위로 묶음 분류.
-     - 한 묶음을 모두 소진한 뒤 다음 묶음으로 넘어간다.
-     - 진행 중 묶음 내에서 발견된 새 질문은 해당 묶음 끝에 추가한다.
-
-도구 호출:
-
-- 선택지 출력 후 즉시 `AskUserQuestion` tool을 호출하여 응답을 종료한다.
-  - 텍스트로 "진행할까요?" 묻고 응답 대기하면 위반.
-  - `AskUserQuestion`이 deferred tool로 표시되어 있으면 먼저 `ToolSearch query="select:AskUserQuestion"`로 스키마를 로드한 뒤 호출한다.
-  - `AskUserQuestion`의 선택지(`options`)는 평균 점수 내림차순으로 정렬하여 전달한다. 동점이면 추천안을 우선 배치한다.
-
-점수 산정:
-
-- 사용자 원안 보호: 사용자가 직접 제시한 안은 변형안과 동등 이상 점수를 기본값으로 한다.
-  - 깎으려면 깎이는 구체 시나리오 인용 필수.
-- 추상가치 깎기 금지: `일관성`·`직관성`·`보존`·`확장성` 같은 추상명사 단독으로 점수 깎지 않는다.
-  - 깎으려면 구체 시나리오 1개 이상 인용.
-- 변형안 도입 책임: 원안 외 변형안을 추가할 때 "원안의 어떤 결함을 어떤 메커니즘으로 해결하는가"를 한 줄로 명시한다.
-
-## Step 4: 선택지 제시 형식
-
-Step 3의 각 질문은 다음 형식으로 제시한다.
-
-- 결정 대상 헤더: markdown `###` 헤더로 작성. 형식 `### 결정 대상 {번호}/{전체}: {대상 식별자/경로:라인}` (단일 결정사항이면 `### 결정 대상: {대상 식별자/경로:라인}`).
-- 하나의 선택지를 추천하고 사유 한 줄 요약.
-- 결정 묶음 자기 완결: 결정 묶음마다 `결정 대상 헤더 → 컨텍스트 → 선택지 → 평가표` 순서로 자기 완결 블록을 작성한다.
-  - 컨텍스트는 결정 대상 헤더 직후에 풀로 기술한다.
-    - "핵심 질문: ..." 같은 한 줄 요약, "{대상} 처리" 같은 축약, 위쪽 통합 분석을 가리키는 참조("발견 1 처리" 등)로 대체 금지.
-  - 컨텍스트에 포함할 내용:
-    - 현재 상태 인용(파일경로:라인 + 코드/문서 발췌)
-    - 발견 요지(왜 이 결정이 필요한지)
-    - 결정해야 할 사안(무엇을 묻는지를 풀어서 기술)
-    - Step 2를 거쳤으면: 분류 결과 → 재분석 결과(+변경 혹은 미변경의 사유).
-  - 기준: 사용자가 결정 묶음 위쪽으로 스크롤하지 않고도, 결정 묶음 안의 컨텍스트만으로 각 선택지가 무엇을 의미하는지 이해할 수 있어야 한다.
-  - 발견사항 N건의 통합 분석을 결정 묶음 위쪽에 길게 몰아 쓰지 않는다.
-    - 통합 요약이 필요하면 1~3줄 개괄만 허용한다.
-- 근거 제시
-  - 변경 후 모습: 선택지마다 코드블록·구조도·시그니처로 제시
-  - 차이점 대비: 동일 관점에서 선택지 나란히 비교
-  - 영향 범위: 파급되는 파일·모듈·API 명시
-  - 원칙: 사용자가 원문을 찾지 않아도 이 출력만으로 판단 가능해야 한다
-- 축별 점수
-  - 맥락에 맞는 관점(축) 3개 이상 선정
-  - 평가축은 결정 결과의 사용자 가치만 측정한다.
-    - 구현·작업 비용(구현 난이도, 코드량, 리팩토링·학습 부담, 사용자 추가 부담 등)은 축이 아닌 "영향 범위"에 서술한다.
-  - 모든 평가축은 "높을수록 좋음" 방향으로 통일한다.
-  - 축별 점수를 반드시 노출한 뒤 평균을 10점 만점으로 병기 (최종 점수만 쓰는 것 금지)
-  - 표기 형식: 단일 매트릭스 표 1개로 표시한다.
-    - 행 = 선택지(평균 내림차순), 열 = 평가축 + 평균.
-    - 선택지마다 별도 표 작성 금지.
-  - 예시:
-    ```
-    | 선택지 | 일관성 | 직관성 | 워크플로 보존 | 평균 |
-    |---|---|---|---|---|
-    | A. xxx | 10 | 10 | 7 | `9.0` |
-    | B. yyy | 6 | 7 | 9 | `7.3` |
-    | C. 수행 안 함 | 2 | 10 | 5 | `5.7` |
-    ```
-- 마지막 상황 예시: 결정 묶음의 평가표 직후, `AskUserQuestion` 호출 직전 가로선 사이에 출력한다.
-  - 목적: 사용자가 이 블록만 읽어도 결정 가능하도록.
-  - 예시 가능한 결정:
-    - 구체 입력/상황 1건을 가정한다 (예: "자재 X·Y·Z의 월별 수량이 이렇게 들어 있을 때").
-    - 각 선택지 채택 시 결과를 라인·표·값으로 풀어 비교한다 (예: "지금 동작 — 18줄 / 바꾸면 — 9줄").
-    - 결과 차이가 한눈에 보이도록 동일 입력에 대한 양쪽 결과를 나란히 제시한다.
-  - 예시 불가능한 결정 (추상적 정책·진행 여부 등):
-    - 결정의 의미·영향 범위·각 선택지가 무엇을 보장하고 무엇을 포기하는지 풀어 쓴다.
-    - 길이 제약 없음.
-  - 어휘: 최종 사용자(최종고객) 업무 도메인 표현으로 작성한다. 시스템 내부 용어(코드 식별자·메타 분류·내부 변수명·파일 경로 등) 노출 금지.
-
-## 인용 형식
-
-분류 보고(Step 2-4)와 질문 컨텍스트(Step 4)에서 사용한다.
-
-- 정형 문서: `파일경로:라인` 또는 `문서명 p.N` / `섹션명`
-- 비정형 자료:
-  - 메일: `메일 [제목] / 발신자 / 일시 — "..."`
-  - 회의 대본: `회의록 [회의명] / 발화자 / 시점 또는 라인 — "..."`
-  - 메시지 본문: `사용자 메시지 ({n}번째 턴) — "..."`
-- 인용은 1~2문장으로 의미가 드러나야 한다.
-- 좌표만 적고 인용 생략 금지.
+- 근거 명확(90% 이상)만 있음: 출처 인용을 호출자에게 보고하고 종료.
+- 근거 불명확(90% 미만) 항목 있음: 질문 대기열에 등록하고 `sd-ask` 적용.

package/claude/rules/sd-claude-rules.md

@@ -13,10 +13,12 @@
   - 예: `"~~를 하지말라는 내용을 써줘"` → `"~~를 하지말라"`를 그대로 박는 것이 아니라, 해당 문서/섹션의 기존 표현 방식에 맞춰 한 줄 룰로 다듬어 작성한다.
   - 사용자 발언을 그대로 받아쓰는 것은 의도 파악 실패로 간주한다.
 - 내장 도구 적극 활용 (Read/Grep/Glob/Bash/WebFetch/WebSearch/Skill/TaskCreate 등)
-- 사용자 요청의 의도가 불명확할 때는 `sd-clarify` 지침에 따라 명확화한다.
-- **IMPORTANT**: 사용자에게 출력하는 글은 최종 사용자(고객) 업무 도메인 어휘(표현방식)로 최대한 끌어올려 쓴다.
+- 사용자에게 질문하거나 선택지를 제시할 때, 명확화가 필요한 사안이 있는지 여부에 따라 분기한다.
+  - 있음 → `sd-clarify` 지침을 적용한다.
+  - 없음 → `sd-ask` 지침을 적용한다.
+- **IMPORTANT**: 사용자에게 출력하는 글은 `최종사용자(고객) 업무 도메인 어휘(표현방식)`로 최대한 끌어올려 쓴다.
   - 시스템 내부 용어(행·컬럼·필드·메타 분류·코드 식별자 등) 노출 금지.
-  - 사용자가 일상 업무에서 부르는 이름·동사로 바꾼다.
+  - `최종사용자(고객)`가 일상 업무에서 부르는 이름·동사로 바꾼다.
   - 정독·검색 없이 1회독으로 이해되는지로 점검한다.
 - **CRITICAL**: 명시적 요청없이 코드/문서등을 바로 수정하지 말것
 

package/claude/rules/sd-response-format.md

@@ -7,7 +7,9 @@
 ## 구조
 
 - 결론 우선: 답변 첫 줄에 결론을 둔다. 근거·세부는 그 아래에 배치.
-- 헤더로 분리: 응답이 3개 이상 논점/단계로 구성되면 `##`/`###` 헤더로 섹션을 나눈다. 헤더는 색상 강조보다 "섹션 분리" 용도다.
+- 헤더 표기: 백틱으로 감싼 텍스트 안에 `#` 갯수를 그대로 표기한다 (예: `## 큰 섹션`, `### 결정 대상`, `#### 컨텍스트`).
+  - 마크다운 헤더(`## ...`/`### ...` 등) 직접 사용 금지. 한글 모노스페이스 터미널에서 본문과 위계 차이 인지 불가.
+  - 응답이 3개 이상 논점/단계로 구성되면 섹션 분리.
 - 가로선 분리: 큰 논리 블록(예: 결론 → 분석 → 변경안 → 결정 요청) 사이에 유니코드 가로선 `────────────────────────────────────────` (U+2500 반복, 40자 권장)을 삽입. markdown `---` HR은 Claude Code 터미널에서 가로선으로 렌더링되지 않으므로 사용 금지.
 - 불릿 우선: 항목이 2개 이상이거나 병렬 구조면 산문 대신 불릿 리스트 사용. 3줄 이상 텍스트가 이어지면 빈 줄 또는 리스트로 끊는다.
 - 표 활용: 대비·비교·다축 평가는 표(table)로 정돈. 정렬·가시성 우수.

package/claude/skills/sd-issue/SKILL.md

@@ -62,10 +62,14 @@ Step 1: 정보 수집 → Step 2: 이슈 본문 작성 → Step 3: 사용자 확
 
 ### 이슈 본문 작성 규칙
 
-모든 내용은 **simplysm 메인테이너가 해당 패키지만으로 이해·재현할 수 있는 형태**로 작성한다. 소비자 앱의 존재를 전제하는 내용(앱 컴포넌트, 서비스, 라우팅, 설정, UI 흐름 등)은 포함하지 않는다.
+재현 절차는 사용자가 실제로 한 행동·입력값·환경을 **사용자 발언 그대로** 옮겨 적는다. 사용자가 직접 보여준 코드 스니펫이 있으면 그 스니펫을 그대로 본문에 옮긴다. 메인테이너가 simplysm 격리 환경에서 재현하기 어렵다고 판단하면 이슈에 직접 추가 정보를 요청한다.
 
-아래 항목도 절대 포함하지 않는다:
+다음 행위를 절대 하지 않는다:
 
+- **단계 창작 금지**: 사용자가 말하지 않은 단계를 추가하거나 만들어 넣지 않는다
+- **재구성·일반화 금지**: 절차를 simplysm-only 환경으로 변환하거나 다른 형태로 일반화하지 않는다
+- **추측 채움 금지**: 누락된 정보를 추측으로 채우지 않는다 (반드시 질문)
+- **코드 구조 변형 금지**: 사용자가 말한 코드 구조를 "최소 재현"·"정적 예시"로 단순화하지 않는다
 - **원인 분석/추측 금지**: "~때문에 발생", "~가 원인" 등 원인을 단정하거나 추측하는 문장 — 메인테이너가 직접 분석해야 하므로 추측은 오히려 방해가 된다
 - **내부 구현 언급 금지**: 라이브러리의 소스 파일 경로, 라인 번호, private 멤버, 정규식 패턴, 상속 체인 등
 - **수정 방안 금지**: 해결 방법, 대안, 워크어라운드, 코드 변경 제안