@simplysm/sd-claude 14.0.59 → 14.0.60

package/claude/references/sd-simplysm-v14/orm-common/schema-builders/table.md

@@ -91,6 +91,14 @@ const UserRole = Table("UserRole")
 
 ## 권장사항
 
+### 컬럼 네이밍
+
+- 컬럼명만으로 저장되는 값의 성격을 알 수 있어야 한다.
+- 엔터티명 단독 사용 금지 → 역할을 나타내는 접미어를 붙인다.
+  - `subCustomer` ✗ → `subCustomerName` / `subCustomerId` ✓
+  - `company` ✗ → `companyName` / `companyId` ✓
+- 흔히 쓰이는 접미어: `Id`, `Name`, `Code`, `Type`, `Date`(date), `DateTime`(datetime), `Count`, `Rate`
+
 ### `isDeleted` 컬럼
 
 - **기초정보(마스터 데이터) 테이블**: `isDeleted: c.boolean().default(false)` 컬럼을 포함한다. 삭제 시 `isDeleted: true`로 soft-delete하고, 복구 기능을 제공한다.

package/claude/rules/sd-clarify.md

@@ -1,17 +1,43 @@
 # sd-clarify: 명확화 지침
 
-명확화 대상 정보의 명확성을 분류하고, 불명확한 항목은 사용자 질문을 통해 명확화한다.
+결정 사안의 명확성을 분류하고, 불명확한 항목은 사용자 질문을 통해 명확화한다.
 
-## 적용 대상 (예외 없음)
+결정 사안 = 작업 수행을 위해 확정해야 하는 개별 결정 항목 (의도, 방식, 동작, 값 등).
 
-**CRITICAL: 사용자에게 질문·제안·확인 등 응답이 필요한 모든 출력에 적용한다.**
+## 전체 흐름
 
-- "이 정도 질문은 과하다", "단순 확인이니 생략"은 위반이다.
-- 단일 경로만 합리적이라 느껴질 때도, "수행 안 함"을 포함한 선택지 구조로 제시한다.
+```
+Step 1: 결정 사안 식별
+  ├─ 결정 사안 있음 → Step 2: 명확화 (근거 확인 → 분류 → 재분석 → 보고)
+  │                     └─ 불명확 항목 → Step 3: 질문 진행
+  └─ 결정 사안 없음 ────→ Step 3: 질문 진행 (질문할 것이 있을 때만)
+```
+
+## Step 1: 결정 사안 식별
+
+다음 조건에 해당하는 결정 사안이 있는지 판별한다.
+
+- 의도/가정 불명: 사용자 요청의 의도, 또는 응답 작성 시 채워넣어야 할 가정이 불명확한 경우
+- 구현 방식 결정: 구현 방식 후보가 2개 이상이거나 새 개념(내부 모드/플래그/래퍼/호환 계층/파일 삭제·이동/호출 흐름 변경) 도입이 필요한 경우
+- 사용성 변경 가능: 사용자 흐름·화면 동작·문구·기본값·옵션 의미·공개 API 동작이 변할 가능성이 있는 경우
+
+추측 즉시 식별:
+
+- 응답 작성 중 가정·추측으로 값을 채워넣는 순간, 해당 항목은 결정 사안으로 즉시 식별한다.
+- 사용자가 명확화를 요청했는지 여부와 무관하다. 추측이 발생하면 무조건 결정 사안이다.
+
+분기:
+
+- 결정 사안 있음 → Step 2로 진행한다.
+- 결정 사안 없음 → Step 2를 건너뛰고, 질문할 것이 있으면 Step 3으로 진행한다.
 
-## 근거 확인
+## Step 2: 명확화
 
-대상의 근거를 다음 출처에서 확인한다 (해당 출처를 모두 검색하기 전 종결 금지).
+결정 사안에 대해 근거 확인 → 분류 → 재분석 → 보고를 순차 수행한다.
+
+### 2-1. 근거 확인
+
+결정 사안의 근거를 다음 출처에서 확인한다 (해당 출처를 모두 검색하기 전 종결 금지).
 
 - 누적 맥락: 사용자 발언, 호출자 인자, 기존 tool 결과, 세션 산출물
 - 타겟 자료: 코드베이스, 프로젝트 룰·참조 문서, 사용자 제공 원본, 공식 문서·표준·규격, 도메인 관행·외부 패턴
@@ -25,9 +51,9 @@ UI 구조·메뉴/네비게이션·라우팅·도메인 엔터티·네이밍·
 - 미확인 출처(예: "~~ 문서에 있을 것", "보통 ~~ 패턴이니")로 VERIFIED/INFERRED-High 분류 금지.
 - "어차피 모를 것"이라는 판단으로 근거 확인을 건너뛰는 것 금지.
 
-## 명확성 분류
+### 2-2. 명확성 분류
 
-명확화 대상을 다음 기준으로 분류한다.
+결정 사안을 다음 기준으로 분류한다.
 
 - VERIFIED: 다음 중 하나에 명시된 항목
   - 사용자 직접 발언(현재/이전 턴), 사용자 제공 외부 자료(첨부 문서·회의록·메일 등)
@@ -44,70 +70,59 @@ UI 구조·메뉴/네비게이션·라우팅·도메인 엔터티·네이밍·
   - Low: 약한 유추나 제한적 근거에 기반한 추론
 - ASSUMED: 추측에 해당
 
-## 근거 재확인
+### 2-3. 근거 재분석
 
-분류 결과가 다음 분류로 남은 항목은 분류 보고 전에 재확인한다.
+INFERRED-Medium, INFERRED-Low, ASSUMED로 분류된 항목 전부를 재분석한다 (일부만 적용 금지).
+항목별 1건씩 처리한다 (그룹·묶음 일괄 처리 금지).
 
-- 대상: INFERRED-Medium, INFERRED-Low, ASSUMED 분류 전부 (일부만 적용 금지)
-- 단위: 항목별 1건씩 (그룹·묶음 일괄 처리 금지)
+목적: 초기 분류가 부실한 분석에 기반했을 수 있다. 누적 맥락에서 이미 아는 것 이상으로, 해당 건의 근거가 될 수 있는 원본을 완독하여 실제 상황을 파악한 뒤 재분류한다.
 
-각 항목마다 다음 절차를 반복한다.
+각 항목마다 다음을 수행한다.
 
-- 핵심 키워드 3개 이상(동의어·관련어 포함)을 추출한다.
-  - 추상 개념(예: "정적 자원 처리")과 실제 코드 패턴(호출 함수명·확장자·디렉토리명·MIME 타입 등)을 함께 추출한다.
-  - 추상 개념만 추출해 실제 구현 좌표를 놓치는 것 금지.
-- 코드베이스에 동일/유사 기능 사례가 이미 있는지 키워드 검색과 별개로 탐색한다.
-  - 키워드 일치 검색만으로 종결 금지. 기능 단위(예: "양식 기반 엑셀 다운로드")로 사례를 뒤진다.
-- 누적 맥락(사용자 메시지·호출자 인자·기존 tool 결과·세션 산출물)과 타겟 자료(코드베이스, 참조 문서, 사용자 제공 원본, 공식 문서)에서 키워드를 검색한다.
-  - 검색 범위를 `src/`만으로 한정 금지. 도메인 통상 위치(`public/`·`assets/`·`static/`·루트 설정 파일)를 함께 본다.
-- 사용자 발언이 가능성 시사("이미 ~~ 있을 것", "보통 ~~ 일 것")를 포함하면 코드베이스 재검색을 트리거한다.
-  - 시사 발언을 신규 라이브러리·신규 구조 도입의 근거로 삼지 않는다.
-- 발견 시 분류를 VERIFIED 또는 INFERRED-High로 격상한다.
-- 부재 시 어디를 봤는지(누적 맥락 + 타겟 자료의 구체 좌표) 항목 단위로 기록한다.
+- 누적 맥락(사용자 발언, 호출자 인자, 기존 tool 결과, 세션 산출물)에서 이미 아는 것을 정리한다.
+- 이미 아는 것만으로 확정할 수 없는 부분을 식별한다.
+- 그 부분의 근거가 될 수 있는 원본을 tool로 완독한다. 발췌·부분 읽기가 아니라 해당 원본 전체를 읽는다.
+- 완독한 실제 상황을 기반으로 2-2 기준에 따라 재분류한다.
+  - 근거 발견 시 VERIFIED 또는 INFERRED-High로 격상한다.
+  - 격상 불가 시 ASSUMED를 유지하되, 완독 과정에서 파악한 실제 상황을 기반으로 선택지를 구성한다.
 
-검색 흔적은 분류 보고와 질문 컨텍스트에 그대로 노출한다.
-추출한 키워드, 검색한 출처 좌표(부재 좌표 포함)를 명시하지 않은 ASSUMED 분류는 위반.
+금지:
 
-"어차피 모를 것"이라는 판단으로 재확인을 건너뛰는 것 금지.
-검색하면 바로 알 수 있는 내용을 검색 없이 ASSUMED로 분류해 사용자에게 묻는 것은 위반.
+- "어차피 모를 것"이라는 판단으로 재분석을 건너뛰는 것.
+- 확인하면 바로 알 수 있는 내용을 확인 없이 ASSUMED로 분류해 사용자에게 묻는 것.
+- 사용자 발언의 가능성 시사("이미 ~~ 있을 것")를 완독 없이 신규 구조 도입의 근거로 삼는 것.
 
-## 분류 보고
+### 2-4. 분류 보고
 
-명확화 대상별로 (재확인 후) 최종 분류 결과를 다음 표 양식으로 보고한 뒤 상황에 따라 분기한다.
+결정 사안별로 (재확인 후) 최종 분류 결과를 다음 표 양식으로 보고한다.
 
-| 대상 | 원분류 | 재확인분류 | 인용 |
+| 대상 | 원분류 | 재분석분류 | 인용 |
 |---|---|---|---|
 | {식별자/경로:라인} | INFERRED-Low | VERIFIED | path/file.ts:42 — "..." |
 | {식별자2} | ASSUMED | ASSUMED | (없음 — 질문 대기열 등록) |
 
 - 원분류: 근거 확인 직후 분류 결과.
-- 재확인분류: 근거 재확인 후 분류 결과 (격상 또는 유지).
+- 재분석분류: 근거 재분석 후 분류 결과 (격상 또는 유지).
 - 인용: VERIFIED / INFERRED-High만 출처 인용 작성.
   - ASSUMED는 "(없음 — 질문 대기열 등록)" 표기.
 
-- **근거 명확(VERIFIED / INFERRED-High)**: 출처 인용(파일경로:라인 또는 URL + 1~2문장)을 호출자에게 보고하고 종료.
-- **근거 불명확(INFERRED-Medium/Low / ASSUMED)**: 질문 대기열에 등록하고 아래 "질문 진행" 절차에 따라 명확화한다.
-  - 답변을 호출자에게 보고하고 종료한다.
+결정 사안이 다건이면 항목별로 각각 분류하고, 명확/불명확을 한 번에 일괄 보고한다.
 
-대상이 다건이면 다음 절차로 처리한다.
+분기:
 
-- 항목별로 각각 분류한다.
-- 명확/불명확을 한 번에 일괄 보고한다.
-- 불명확 항목만 질문 대기열에 넣는다.
+- 근거 명확(VERIFIED / INFERRED-High)만 있음: 출처 인용을 호출자에게 보고하고 종료.
+- 근거 불명확(INFERRED-Medium/Low / ASSUMED) 항목 있음: 질문 대기열에 등록하고 Step 3으로 진행한다.
 
-### 인용 형식
+## Step 3: 질문 진행
 
-분류 보고의 인용/요약에 사용한다.
+사용자에게 질문하는 모든 출력에 적용한다 (Step 2 발동 여부와 무관).
 
-- 정형 문서: `파일경로:라인` 또는 `문서명 p.N` / `섹션명`
-- 비정형 자료:
-  - 메일: `메일 [제목] / 발신자 / 일시 — "..."`
-  - 회의 대본: `회의록 [회의명] / 발화자 / 시점 또는 라인 — "..."`
-  - 메시지 본문: `사용자 메시지 ({n}번째 턴) — "..."`
-- 인용은 1~2문장으로 의미가 드러나야 한다.
-- 좌표만 적고 인용 생략 금지.
+필수 의무:
 
-## 질문 진행
+- "이 정도 질문은 과하다", "단순 확인이니 생략"은 위반이다.
+- 단일 경로만 합리적이라 느껴질 때도, "수행 안 함"을 포함한 선택지 구조로 제시한다.
+
+질문 운영:
 
 - 질문 대기열 우선: 사용자 답변이 필요한 항목이 있으면 질문 대기열에 등록한다.
   - 사용자 답변으로 새 질문이 생기면 후속 프로세스를 시작하지 말고 질문 대기열에 추가한다.
@@ -126,21 +141,27 @@ UI 구조·메뉴/네비게이션·라우팅·도메인 엔터티·네이밍·
   - 한 묶음을 모두 소진한 뒤 다음 묶음으로 넘어간다.
   - 진행 중 묶음 내에서 발견된 새 질문은 해당 묶음 끝에 추가한다.
   - 묶음 간 순서는 의존성·상위→하위 순으로 한다.
-- 도구 호출 의무: 선택지 출력 후 즉시 `AskUserQuestion` tool을 호출하여 응답을 종료한다.
+
+도구 호출:
+
+- 선택지 출력 후 즉시 `AskUserQuestion` tool을 호출하여 응답을 종료한다.
   - 텍스트로 "진행할까요?" 묻고 응답 대기하면 위반.
   - `AskUserQuestion`이 deferred tool로 표시되어 있으면 먼저 `ToolSearch query="select:AskUserQuestion"`로 스키마를 로드한 뒤 호출한다.
   - `AskUserQuestion`의 선택지(`options`)는 평균 점수 내림차순으로 정렬하여 전달한다. 동점이면 추천안을 우선 배치한다.
+
+점수 산정:
+
 - 사용자 원안 보호: 사용자가 직접 제시한 안은 변형안과 동등 이상 점수를 기본값으로 한다.
   - 깎으려면 깎이는 구체 시나리오 인용 필수.
 - 추상가치 깎기 금지: `일관성`·`직관성`·`보존`·`확장성` 같은 추상명사 단독으로 점수 깎지 않는다.
   - 깎으려면 구체 시나리오 1개 이상 인용.
 - 변형안 도입 책임: 원안 외 변형안을 추가할 때 "원안의 어떤 결함을 어떤 메커니즘으로 해결하는가"를 한 줄로 명시한다.
 
-## 선택지 제시 형식
+## Step 4: 선택지 제시 형식
 
-각 질문은 다음 형식으로 제시한다.
+Step 3의 각 질문은 다음 형식으로 제시한다.
 
-- 결정 대상 헤더: 첫 줄 `결정 대상 {번호}/{전체}: {대상 식별자/경로:라인}` (단일 결정사항이면 `결정 대상: {대상 식별자/경로:라인}`).
+- 결정 대상 헤더: markdown `###` 헤더로 작성. 형식 `### 결정 대상 {번호}/{전체}: {대상 식별자/경로:라인}` (단일 결정사항이면 `### 결정 대상: {대상 식별자/경로:라인}`).
 - 하나의 선택지를 추천하고 사유 한 줄 요약.
 - 결정 묶음 자기 완결: 결정 묶음마다 `결정 대상 헤더 → 컨텍스트 → 선택지 → 평가표` 순서로 자기 완결 블록을 작성한다.
   - 컨텍스트는 결정 대상 헤더 직후에 풀로 기술한다.
@@ -149,7 +170,7 @@ UI 구조·메뉴/네비게이션·라우팅·도메인 엔터티·네이밍·
     - 현재 상태 인용(파일경로:라인 + 코드/문서 발췌)
     - 발견 요지(왜 이 결정이 필요한지)
     - 결정해야 할 사안(무엇을 묻는지를 풀어서 기술)
-    - 현재 분류 결과 -> 근거 재확인 결과(+변경 혹은 미변경의 사유).
+    - Step 2를 거쳤으면: 분류 결과 → 재분석 결과(+변경 혹은 미변경의 사유).
   - 기준: 사용자가 결정 묶음 위쪽으로 스크롤하지 않고도, 결정 묶음 안의 컨텍스트만으로 각 선택지가 무엇을 의미하는지 이해할 수 있어야 한다.
   - 발견사항 N건의 통합 분석을 결정 묶음 위쪽에 길게 몰아 쓰지 않는다.
     - 통합 요약이 필요하면 1~3줄 개괄만 허용한다.
@@ -171,7 +192,19 @@ UI 구조·메뉴/네비게이션·라우팅·도메인 엔터티·네이밍·
     ```
     | 선택지 | 일관성 | 직관성 | 워크플로 보존 | 평균 |
     |---|---|---|---|---|
-    | A. xxx | 10 | 10 | 7 | **9.0** |
-    | B. yyy | 6 | 7 | 9 | **7.3** |
-    | C. 수행 안 함 | 2 | 10 | 5 | **5.7** |
+    | A. xxx | 10 | 10 | 7 | `9.0` |
+    | B. yyy | 6 | 7 | 9 | `7.3` |
+    | C. 수행 안 함 | 2 | 10 | 5 | `5.7` |
     ```
+
+## 인용 형식
+
+분류 보고(Step 2-4)와 질문 컨텍스트(Step 4)에서 사용한다.
+
+- 정형 문서: `파일경로:라인` 또는 `문서명 p.N` / `섹션명`
+- 비정형 자료:
+  - 메일: `메일 [제목] / 발신자 / 일시 — "..."`
+  - 회의 대본: `회의록 [회의명] / 발화자 / 시점 또는 라인 — "..."`
+  - 메시지 본문: `사용자 메시지 ({n}번째 턴) — "..."`
+- 인용은 1~2문장으로 의미가 드러나야 한다.
+- 좌표만 적고 인용 생략 금지.

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

@@ -14,11 +14,10 @@
   - 사용자 발언을 그대로 받아쓰는 것은 의도 파악 실패로 간주한다.
 - 내장 도구 적극 활용 (Read/Grep/Glob/Bash/WebFetch/WebSearch/Skill/TaskCreate 등)
 - 사용자 요청의 의도가 불명확할 때는 `sd-clarify` 지침에 따라 명확화한다.
-- 맥락에 맞는 용어 사용
-  - 업무 기능·요구사항 논의 → 업무 용어 (사용자가 화면에서 뭘 하는지)
-  - DB 스키마 설계 → 테이블·컬럼명
-  - 코드 구현 → 함수·클래스명
-- 한국 개발 현장 통용 용어 사용
+- 사용자에게 출력하는 글은 사용자(최종고객) 업무 도메인 어휘(표현방식)로 끌어올려 쓴다.
+  - 시스템 내부 용어(행·컬럼·필드·메타 분류·코드 식별자 등) 노출 금지. 
+  - 사용자가 일상 업무에서 부르는 이름·동사로 바꾼다.
+  - 정독·검색 없이 1회독으로 이해되는지로 점검한다.
 - **CRITICAL**: 사용자가 명시하지 않은 행동을 추측으로 진행 하지 말것
   - 명시적 요청없이 다음 단계를 추측하여 바로 작업 하지 말것
   - 명시적 요청없이 코드/문서등을 바로 수정하지 말것

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

@@ -7,13 +7,13 @@
 ## 구조
 
 - 결론 우선: 답변 첫 줄에 결론을 둔다. 근거·세부는 그 아래에 배치.
-- 헤더로 분리: 응답이 3개 이상 논점/단계로 구성되면 `##`/`###` 헤더로 섹션을 나눈다. 짧은 답변(1~2단락)에는 헤더 금지. 헤더는 색상 강조보다 "섹션 분리" 용도다.
+- 헤더로 분리: 응답이 3개 이상 논점/단계로 구성되면 `##`/`###` 헤더로 섹션을 나눈다. 헤더는 색상 강조보다 "섹션 분리" 용도다.
 - 가로선 분리: 큰 논리 블록(예: 결론 → 분석 → 변경안 → 결정 요청) 사이에 유니코드 가로선 `────────────────────────────────────────` (U+2500 반복, 40자 권장)을 삽입. markdown `---` HR은 Claude Code 터미널에서 가로선으로 렌더링되지 않으므로 사용 금지.
 - 불릿 우선: 항목이 2개 이상이거나 병렬 구조면 산문 대신 불릿 리스트 사용. 3줄 이상 텍스트가 이어지면 빈 줄 또는 리스트로 끊는다.
 - 표 활용: 대비·비교·다축 평가는 표(table)로 정돈. 정렬·가시성 우수.
 - 코드블록 활용: 명령어 1줄 이상, 코드 인용, 파일 내용 발췌, 변경 전후 본문은 fenced code block으로 분리.
 - 꼬리 요약: 응답이 30줄 이상이면 마지막에 가로선 분리 후 `## 요약` 헤더 + 핵심 불릿 3~5개를 출력한다. 30줄 미만이면 출력 금지.
-- `AskUserQuestion` 도구 호출시: 호출 직전 응답 본문 끝에 "---"를 추가 송출한 뒤 도구를 호출한다. `AskUserQuestion` 도구가 직전 메시지 마지막 2줄을 가리는 현상 회피용.
+- `AskUserQuestion` 도구 호출시: 호출 직전 응답 본문 끝에 유니코드 가로선(`────────────────────────────────────────`)을 추가 송출한 뒤 도구를 호출한다. `AskUserQuestion` 도구가 직전 메시지 마지막 2줄을 가리는 현상 회피용.
 
 ## 색상 활용 (Claude Code 터미널 기준)
 

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

@@ -121,7 +121,7 @@ typecheck 명령어를 실행한다. (`출력 캡처 규칙`에 따라 파일로
    - **테스트 데이터 갱신 누락**: snapshot/expected/golden 출력만 달라진 경우 변경 의도 확인 후 해당 테스트 데이터 수정.
    - **무관한 기존 실패**: `에러 처리 범위`에 따라 조용히 스킵.
    - **원인 특정 불가**: 에스컬레이션 규칙에 따라 즉시 보고.
-6. 1차 분류된 항목별로 `sd-clarify` 지침에 따라 분류와 처리 방향의 명확성을 판정한다. sd-check가 자체 판단으로 명확한 항목을 제외하고 보내지 않는다.
+6. 1차 분류된 항목을 `sd-clarify` 지침에 따라 명확화 한다.
 7. 위 판정 결과가 명확하면 즉시 처리한다:
    - **구현 버그가 명확함**: 코드 수정.
    - **테스트 변경 누락이 명확함**: 테스트, fixture, expected/golden 수정.

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

@@ -30,7 +30,7 @@ sd-wbs → sd-plan → sd-tdd → sd-check → sd-review를 순차 진행하는
 ## Step 3: sd-plan
 
 `/sd-plan` 스킬을 즉시 수행한다.
-단, Task 문서의 Scenario 수가 10개를 초과하면 Step 4~7을 모두 스킵하고 `/sd-dev {Task파일경로}`로 새 세션에서 진행하도록 안내 후 즉시 종료한다. 이 경우 Step 7 완료 보고는 출력하지 않는다.
+단, Task 문서의 Scenario 수가 2개를 초과하면 Step 4~7을 모두 스킵하고 `/sd-dev {Task파일경로}`로 새 세션에서 진행하도록 안내 후 즉시 종료한다. 이 경우 Step 7 완료 보고는 출력하지 않는다.
 
 ## Step 4: sd-tdd
 

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

@@ -28,7 +28,7 @@ WBS Task 한 개를 대상으로, Story별 비즈니스 규칙과 코드베이
 - **Rule**: WBS Story 근거를 출발점으로 도출한 세부 비즈니스 규칙·정책·검증 조건
 - **Scenario**: Rule 내 입력 → 결과 (긍정/부정/경계)
 
-모든 사항은 `sd-clarify` 지침에 따라 즉시 명확화한다.
+모든 항목은 `sd-clarify` 지침에 따라 명확화한다.
 
 | 기법                          | 적용 시점           | 방법                                              |
 | ----------------------------- | ------------------- | ------------------------------------------------- |

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

@@ -28,7 +28,7 @@ description: 스킬/프롬프트 파일의 작성·개선을 위한 EDD 스킬.
 
 ## Step 1: 의도 정의
 
-다음 4요소 파악 중 의문이 발생하면 의문 1건마다 `sd-clarify` 지침에 따라 즉시 명확화한다. 명확화 결과는 해당 요소에 반영한다.
+모든 항목은 `sd-clarify` 지침에 따라 명확화한다.
 
 프롬프트 작성 전에 다음을 파악한다:
 
@@ -39,7 +39,7 @@ description: 스킬/프롬프트 파일의 작성·개선을 위한 EDD 스킬.
 
 ## Step 2: Eval 시나리오 정의
 
-체크리스트·rubric 도출 중 의문이 발생하면 의문 1건마다 `sd-clarify` 지침에 따라 즉시 명확화한다. 명확화 결과는 해당 시나리오·체크 항목에 반영한다.
+모든 항목은 `sd-clarify` 지침에 따라 명확화한다.
 
 ### Eval 유형
 
@@ -161,7 +161,7 @@ Judge는 아래 **두 가지만** 볼 수 있다. 체크리스트의 모든 항
 
 FAIL이 1개라도 있으면 다음 단계로 진행할 수 없다. 이유를 불문하고 수정 없이 다음 단계로 넘어가는 것은 금지한다.
 
-1. Judge의 FAIL 항목별로 `sd-clarify` 지침에 따라 진짜 문제인지, 제안된 수정 방향이 맞는지 재검증한다. 문제 인식은 맞아도 제안이 틀릴 수 있으므로 제안 측면에 무게를 둔다.
+1. 모든 항목은 `sd-clarify` 지침에 따라 명확화한다.
    - FAIL 판정이유 및 해당하는 부분의 실제 출력을 포함해야한다.
 2. `sd-clarify` 결과에 따라 작성 원칙에 맞추어 수정한다.
 3. 수정 범위에 따라 분기하여 재실행한다.
@@ -172,7 +172,7 @@ FAIL이 1개라도 있으면 다음 단계로 진행할 수 없다. 이유를
 
 전체 Eval PASS 후, 개선 루프에서 누적된 패치를 정리하여 정돈된 프롬프트를 만든다.
 
-아래 Smell 종류를 모두 탐지한 뒤, 탐지된 Smell 항목 1건마다 `sd-clarify` 지침에 따라 명확화한 뒤 리팩터링한다. 프롬프트 재작성이 필요하면 Step 3로 되돌아간다.
+모든 항목은 `sd-clarify` 지침에 따라 명확화한 후, 리팩터링한다. 프롬프트 재작성이 필요하면 Step 3로 되돌아간다.
 
 ### Prompt Smell 탐지
 

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

@@ -16,7 +16,7 @@ sd-refactor는 "구조 개선 방향 제안"(패키지/아키텍처 수준)에
 - **린터/타입체커 영역**: 타입 누락, `any` 사용, 미사용 변수, 코드 스타일
 - **거짓 양성**: 프레임워크가 요구하는 패턴, 프로젝트 컨벤션에 의한 의도적 구조
 
-이슈가 의도된 설계인지 불확실하거나, 제안이 기존 기능의 동작 변경을 수반하는 경우 `sd-clarify` 지침에 따라 명확화한다. 사용자 확인 없이 기능 변경을 리포트에 포함하지 않는다.
+모든 항목은 `sd-clarify` 지침에 따라 명확화한다.
 
 ## Step 1: 대상 결정
 

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

@@ -146,7 +146,7 @@ Step 3에서 탐지된 이슈를 하나씩 순회하며, 해당 위치의 코드
 
 ## Step 5: 남은 이슈 명확화
 
-Step 4를 통과한 이슈별로 `sd-clarify` 지침에 따라 거짓양성 여부와 유효성을 명확화한 뒤 최종 이슈로 확정한다.
+Step 4를 통과한 모든 이슈(Low포함)을 `sd-clarify` 지침에 따라 명확화한 뒤 최종 이슈로 확정한다.
 
 ## Step 6: 이슈 정리
 

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

@@ -1,7 +1,6 @@
 ---
 name: sd-tdd
 description: 구현계획(plan) 기반으로 TDD 개발하는 스킬
-model: claude-opus-4-6[1m]
 ---
 
 # sd-tdd: TDD 개발

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

@@ -46,7 +46,7 @@ WBS는 고객 중심으로 **무엇을 만들어야 하는지(What)** 를 확정
 - 기존 체크박스 상태(`[ ]`/`[x]`), Activity·Task·Story 번호, 사용자 메모, 이미 확정된 제외 사항을 임의 초기화·삭제하지 않는다.
 - 번호 변경이 필요한 경우 기존 번호 → 새 번호 매핑과 변경 사유를 문서에 남긴다.
 
-### 1-1. 원본 완독
+### 원본 완독
 
 - 모든 원본(첨부 파일, 메시지 본문, 메일 thread, 회의 대본)을 끝까지 읽는다. 키워드 검색만 종결 금지.
 - 자료별 분량(페이지/라인/통수)을 보고에 명시하여 부분 독해를 표면화한다.
@@ -79,6 +79,23 @@ Impact Mapping 트리(Goal → Actor → Impact → Deliverable)를 도출한다
 - Goal은 구체적 목적을 명확히 기술한다. "효율화한다"(X) → "대출·반납 기록을 시스템으로 관리하여 분실을 방지한다"(O). 수치 기반이 가능하면 좋지만 필수 아님.
 - Impact는 기능이 아닌 **행동 변화**를 기술한다. "대시보드를 본다"(X) → "업무 상태를 빠르게 파악한다"(O)
 
+### Impact Mapping 결과 보고
+
+명확화 완료 후, 도출된 Impact Mapping 트리를 사용자에게 보고한다. 보고 후 사용자 응답을 기다리지 않고 Step 3으로 진행한다.
+
+출력 형식:
+
+```
+## Impact Mapping 결과
+
+- **Goal:** {목표}
+  - **Actor:** {이해관계자}
+    - **Impact:** {행동 변화}
+      - **Deliverable:** {산출물}
+
+- **제외 사항:** {사용자가 제외를 확정한 항목 — 없으면 생략}
+```
+
 ## Step 3: USM Breakdown
 
 Deliverable을 Activity → Task → Story로 구조화한다.
@@ -89,11 +106,11 @@ Deliverable을 Activity → Task → Story로 구조화한다.
 
 USM의 모든 단위는 **사용자 동작 단위**이다. 다음 분할은 절대 금지.
 
-| 금지 분할 | 사유 | 대신 |
-|---|---|---|
-| 아키텍처 레이어 (DB/서비스/UI, 서버/클라이언트, 패키지, 백엔드/프론트엔드) | end-to-end 수직 슬라이스 위배 | 각 Task가 모든 레이어를 포함 |
-| Actor(관리자/직원/고객) 별 동일 도메인 분할 | 동일 활동을 권한으로 쪼개면 사용자 여정이 분절됨 | Story 안에 Actor·권한 표기 |
-| 테스트 단위 분리 | 검증은 구현과 동시 작성 | 후속 `/sd-tdd`에서 함께 처리 |
+| 금지 분할                                                                  | 사유                                             | 대신                         |
+| -------------------------------------------------------------------------- | ------------------------------------------------ | ---------------------------- |
+| 아키텍처 레이어 (DB/서비스/UI, 서버/클라이언트, 패키지, 백엔드/프론트엔드) | end-to-end 수직 슬라이스 위배                    | 각 Task가 모든 레이어를 포함 |
+| Actor(관리자/직원/고객) 별 동일 도메인 분할                                | 동일 활동을 권한으로 쪼개면 사용자 여정이 분절됨 | Story 안에 Actor·권한 표기   |
+| 테스트 단위 분리                                                           | 검증은 구현과 동시 작성                          | 후속 `/sd-tdd`에서 함께 처리 |
 
 **좋은 예:**
 
@@ -136,7 +153,7 @@ Task는 Activity 안의 사용자 작업이다. 후속 스킬(`/sd-plan`, `/sd-t
 
 처음 만들 때 정의(end-to-end 수직 슬라이스, 1 사용자 작업 단위)를 지키면서 최소 단위로 만든다.
 
-- 기본 동작과 확장 동작이 자연스럽게 구분되면 처음부터 별도 Task로 분리한다
+- 기본 동작과 확장 동작의 구분이 가능하면 별도 Task로 분리한다
 - 네이밍: `{기능명} — {범위 설명}` (예: "도서 관리 — 기본 CRUD", "도서 관리 — 추천/통계")
 - 확장 Task는 기본 Task에 대한 의존성을 명시한다
 - 기본 Task만으로 해당 기능의 핵심 동작이 완성되어야 한다
@@ -168,15 +185,10 @@ Story는 Task 안의 한 사용자 시나리오이다. 한 줄 사용자 동작
 - "도서 목록 개선" — 완료 판정 불가
 - "회원이 검색한다" — 대상·결과 누락
 
-항목별 근거가 없는 Story는 Task에 포함하지 않는다. 필요해 보이지만 근거가 없는 항목은 Story 후보 목록에 등록한다.
-
-#### 미확정·근거 없는 항목 처리
-
-**미확정 항목은 단 하나도 wbs.md에 남기지 않는다.** Story·Task·Activity 본문에는 확정된 고객 동작과 업무 규칙만 남긴다.
+항목별 근거가 없는 Story는 Task에 포함하지 않는다. 근거가 없는 항목은 `sd-clarify` 지침에 따라 포함 여부를 명확화한다.
 
-- 원문에 미확정이거나 Impact Mapping Deliverable로 역추적 불가한 항목(원문에 없지만 "당연히 필요해 보이는" 기능 포함)은 Story 후보 목록에 등록한다. 추정 진행, "추후 결정" fallback, 자체 추가는 금지.
-- 포함으로 확정되면 Impact Mapping에 Deliverable 보강 후 Story 작성. 미포함이면 "제외 사항"에 기재.
-- "후속 확정/보류/추후 결정/협의 필요" 같은 미확정 표현 본문 사용 금지.
+- 추정 진행, "추후 결정" fallback, 자체 추가 금지.
+- wbs.md 본문에 "후속 확정/보류/추후 결정/협의 필요" 같은 미확정 표현 사용 금지.
 
 ## Step 4: 자가검증 (Self-Refine)
 
@@ -190,8 +202,8 @@ Backbone 흐름·Story 단위 적정성·양방향 커버리지는 Step 6 격리
 
 1. **의존성 순서** — 의존 대상이 뒤 번호에 있거나 같은 단계 내에 있으면 번호/순서 재정렬.
 2. **분해 원칙 준수** — Step 3 분해 원칙(레이어 분할 금지, Actor 분할 금지, 테스트 단위 분리 금지) 위반이 없는지 확인.
-3. **미루기 표현 제거** — "후속 확정/보류/추후 결정/협의 필요/plan에서 결정/구현 시 결정/별도 확정" 등 본문 미루기 표현 점검. 발견 시 What이면 Story 후보 목록에 등록, How이면 본문에서 제거.
-4. **항목별 근거 확인** — 모든 Story 끝에 `(근거: ...)`가 있는지 확인. 발견 시 근거를 보강하거나 Story 후보 목록으로 이동.
+3. **미루기 표현 제거** — "후속 확정/보류/추후 결정/협의 필요/plan에서 결정/구현 시 결정/별도 확정" 등 본문 미루기 표현 점검. 발견 시 What이면 `sd-clarify` 지침에 따라 명확화, How이면 본문에서 제거.
+4. **항목별 근거 확인** — 모든 Story 끝에 `(근거: ...)`가 있는지 확인. 근거가 없으면 `sd-clarify` 지침에 따라 명확화.
 
 ### 의존성 매트릭스
 
@@ -275,8 +287,8 @@ Backbone 흐름·Story 단위 적정성·양방향 커버리지는 Step 6 격리
 ## 의존성 매트릭스
 
 | Task | 의존 대상 |
-|------|----------|
-| 1.1  | 없음     |
+| ---- | --------- |
+| 1.1  | 없음      |
 ```
 
 **진행 상황:** Task별 `[ ]` 체크박스로 진행을 추적한다.
@@ -285,7 +297,7 @@ Backbone 흐름·Story 단위 적정성·양방향 커버리지는 Step 6 격리
 
 - 사용자가 명시적으로 "포함 안 함"으로 결정한 항목과 Impact Mapping에서 Goal에 연결되지 않는 기능을 나열한다.
 - 각 항목은 `제외 항목 — 사유: ... / 출처: ... / 재검토 조건: ...` 형식으로 작성한다.
-- 사유에는 Goal 미연결, 사용자 명시적 제외, 범위 초과 중 하나를 사용한다. "미확정"은 사유로 사용하지 않는다 (미확정 항목은 Story 후보 목록에 등록하여 Step 3 종료 명확화로 확정).
+- 사유에는 Goal 미연결, 사용자 명시적 제외, 범위 초과 중 하나를 사용한다. "미확정"은 사유로 사용하지 않는다.
 
 ## Step 6: 격리 검증 (정보 유실·누락 점검)
 
@@ -310,9 +322,10 @@ subagent에 부여할 제약: "보고만 수행. wbs.md를 수정하지 말 것.
 #### 검증 항목
 
 1. **정량 매핑 표 (양방향 커버리지)** — 원본에서 카테고리별 사실 항목을 추출하여 wbs.md 위치(Story 번호/프로젝트 개요)에 1:1 매핑.
-   - 추출 카테고리: 수치(최대/최소/기본값/허용 범위, 기간, 시간대, 경계값) / 열거값(상태, 권한, 역할, 옵션 후보) / 업무 규칙·정책 / 제약 조건 / 권한·역할(Actor) / 상태 전이 / 예외 흐름·분기 조건 / 참조 자료 경로 + 확인 목적
-   - 누락: 원본에 있는데 매핑되지 않은 항목
-   - 근거 없는 추가: wbs.md에 있는데 원본/근거에서 추적 불가한 항목
+
+- 추출 카테고리: 수치(최대/최소/기본값/허용 범위, 기간, 시간대, 경계값) / 열거값(상태, 권한, 역할, 옵션 후보) / 업무 규칙·정책 / 제약 조건 / 권한·역할(Actor) / 상태 전이 / 예외 흐름·분기 조건 / 참조 자료 경로 + 확인 목적
+- 누락: 원본에 있는데 매핑되지 않은 항목
+- 근거 없는 추가: wbs.md에 있는데 원본/근거에서 추적 불가한 항목
 
 2. **의역 변형 검출** — 원문이 구체적인데 wbs.md가 추상화된 사례 (예: 원문 "최대 100건" → wbs "다수 항목")
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "14.0.59",
+  "version": "14.0.60",
   "description": "심플리즘 패키지 - Claude Code 셋업",
   "author": "심플리즘",
   "license": "Apache-2.0",