@simplysm/sd-claude 14.0.41 → 14.0.43

package/claude/{references/sd-debug.md → skills/sd-inner-debug/SKILL.md}

@@ -1,4 +1,9 @@
-# sd-debug: 근본 원인 분석
+---
+name: sd-inner-debug
+description: (내부 전용) 근본 원인 분석(ACH) 로직. sd-debug, sd-check 등에서 호출된다. 직접 호출하지 않는다.
+---
+
+# sd-inner-debug: 근본 원인 분석
 
 ## 공통 규칙
 
@@ -57,7 +62,7 @@
 - **위치** — 에러 발생 파일:라인 또는 관련 기능/화면
 - **재현 절차** — 문제가 발생하는 구체적 조작 순서
 
-@.claude/references/sd-clarify.md 에 따라 명확화한다.
+@.claude/rules/sd-clarify.md 지침에 따라 명확화한다.
 
 ## Step 2: 근본 원인 추적 (ACH)
 
@@ -124,26 +129,17 @@
 
 ## Step 3: 방안 제시
 
-`.claude/rules/sd-options.md` 의 지침에 따라, 사용자에게 해결책을 제시하여 선택을 받는다.
+### 출력 규칙
+
+- **폐기된 가설 제외**: Step 2에서 I(불일치)로 폐기된 가설은 방안 제시에 포함하지 않는다. 살아남은 가설의 해결방안만 선택지로 제시한다.
+- **ACH 매트릭스 비출력**: 매트릭스 전체를 사용자에게 출력하지 않는다. 분석 결과는 살아남은 원인과 그 근거만 간결하게 요약한다.
 
-원인별 해결 방안을 묶어 선택지로 제시한다. 각 "원인X.방안Y"가 하나의 선택지이다.
+### 선택지 구성
 
-**모든 선택지에 반론 필수**
+살아남은 원인별 해결방안을 선택지로 구성한다. 원인이 1개면 해당 원인의 방안들이 선택지가 되고, 원인이 복수면 각 "원인X.방안Y"가 선택지가 된다.
 
-```
-원인 1: {원인 요약}
-  반론: {이 원인이 아닐 수 있는 이유}
-  - 1.1 {해결방안}: {설명}
-    장점: ... / 반론: ...
-    점수: {관점별} → 평균 {N}/10
-  - 1.2 {해결방안}: {설명}
-    장점: ... / 반론: ...
-    점수: {관점별} → 평균 {N}/10
+각 선택지에는 **반론**(이 원인/방안이 틀릴 수 있는 이유)을 반드시 포함한다.
 
-원인 2: {원인 요약}
-  반론: {이 원인이 아닐 수 있는 이유}
-  - 2.1 {해결방안}: {설명}
-    장점: ... / 반론: ...
-    점수: {관점별} → 평균 {N}/10
-```
+### 양식
 
+@.claude/rules/sd-options.md 를 그대로 따른다. 별도 양식을 사용하지 않는다.

package/claude/{references/sd-review.md → skills/sd-inner-review/SKILL.md}

@@ -1,11 +1,16 @@
-# sd-review: 코드 리뷰
+---
+name: sd-inner-review
+description: (내부 전용) 코드 리뷰 분석 로직. sd-review, sd-dev 등에서 호출된다. 직접 호출하지 않는다.
+---
+
+# sd-inner-review: 코드 리뷰 분석
 
 ## Step 1: 대상 결정
 
 인자로 경로가 지정되면 해당 경로, 미지정이면 프로젝트 전체를 분석한다.
 
-- `/sd-review src/services` → `src/services` 하위만
-- `/sd-review` → 프로젝트 루트 전체
+- `/sd-inner-review src/services` → `src/services` 하위만
+- `/sd-inner-review` → 프로젝트 루트 전체
 
 ## Step 2: 컨텍스트 수집
 
@@ -101,7 +106,7 @@ Step 3에서 탐지된 이슈를 하나씩 순회하며, 해당 위치의 코드
 3. 위 판단 기준에 해당하는지 평가
 4. 거짓양성이면 사유를 기록하고 제외, 아니면 이슈 유지
 
-불확실한 경우, `.claude/rules/sd-options.md` 의 지침에 따라 사용자에게 질문하여 명확화 한다.
+불확실한 경우, @.claude/rules/sd-options.md 의 지침에 따라 사용자에게 질문하여 명확화 한다.
 
 ## Step 5: 이슈 정리
 

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

@@ -1,6 +1,8 @@
 ---
 name: sd-issue
 description:  simplysm 라이브러리에 대한 GitHub 이슈를 생성하는 스킬. "이슈 생성", "이슈 등록", "버그 리포트" 등을 요청할 때 사용한다.
+model: sonnet
+effort: low
 ---
 
 # sd-issue: simplysm 이슈 생성

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

@@ -1,6 +1,8 @@
 ---
 name: sd-outlook
 description: Microsoft Graph API를 통해 Outlook 메일을 검색·다운로드하는 스킬. "메일 조회", "메일 검색", "특정 업체 메일 수집", "outlook" 등을 요청할 때 사용한다.
+model: sonnet
+effort: low
 ---
 
 # sd-outlook: Outlook 메일 검색/다운로드

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

@@ -63,7 +63,7 @@ Question 도출 기법 — Feature 성격에 맞게 **하나 이상** 선택하
 
 ### 2-3. 명확화
 
-`.claude/references/sd-clarify.md`를 읽고 범위, Question, 기타 불명확한 부분을 명확화한다.
+@.claude/rules/sd-clarify.md 지침에 따라 범위, Question, 기타 불명확한 부분을 명확화한다.
 답변에 따라 Rule/Example/Question을 갱신하며, 모든 Question이 해소될 때까지 **MUST** 반복한다. (추가 Question 발생 가능)
 - **나쁜 예:** "예약 기능 포함이 결정됨 → 예약 세부규칙(대기열 정책, 미대출 시 자동취소 기간)도 확정" — 기능 포함 여부와 세부 수치/규칙은 별개다. 세부사항은 별도로 분류·질문한다.
 

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

@@ -29,7 +29,7 @@ description: 스킬/프롬프트 파일의 작성·개선을 위한 EDD 스킬.
 - **입력**: 무엇을 받는가
 - **출력**: 무엇을 내놓는가
 
-`.claude/references/sd-clarify.md`를 읽고 명확화한다.
+@.claude/rules/sd-clarify.md 지침에 따라 명확화한다.
 
 ## Step 2: Eval 시나리오 정의
 
@@ -171,7 +171,7 @@ Judge 보고서의 개선 제안을:
 | **상충 지시** — 서로 모순/충돌          | 우선순위 결정 후 통합 또는 삭제 |
 | **구조 산만** — 관련 지시가 흩어져 있음     | 재배치                |
 
-발견된 Prompt Smell에 대해 `.claude/references/sd-clarify.md`를 읽고 진행여부와 방법을 명확화하여 수정한다.
+발견된 Prompt Smell에 대해 `.claude/rules/sd-clarify.md` 지침에 따라 진행여부와 방법을 명확화하여 수정한다.
 
 ### Regression Guard
 

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

@@ -16,7 +16,7 @@ sd-refactor는 "구조 개선 방향 제안"(패키지/아키텍처 수준)에
 - **린터/타입체커 영역**: 타입 누락, `any` 사용, 미사용 변수, 코드 스타일
 - **거짓 양성**: 프레임워크가 요구하는 패턴, 프로젝트 컨벤션에 의한 의도적 구조
 
-이슈가 의도된 설계인지 불확실하거나, 제안이 기존 기능의 동작 변경을 수반하는 경우 `.claude/references/sd-clarify.md`를 읽고 명확화한다. 사용자 확인 없이 기능 변경을 리포트에 포함하지 않는다.
+이슈가 의도된 설계인지 불확실하거나, 제안이 기존 기능의 동작 변경을 수반하는 경우 @.claude/rules/sd-clarify.md 지침에 따라 명확화한다. 사용자 확인 없이 기능 변경을 리포트에 포함하지 않는다.
 
 ## Step 1: 대상 결정
 
@@ -95,7 +95,7 @@ Step 3에서 탐지된 이슈를 사용자에게 제시하기 전에 거짓 양
 각 이슈에 대해:
 1. **코드 재대조**: 해당 위치의 코드를 Read 도구로 **반드시 다시 읽고**, 이슈가 실제로 존재하는지 확인한다. 거짓 양성으로 판단된 이슈는 제거한다.
 2. **중복 이슈 병합**: 동일 근본 원인에서 파생된 이슈를 하나로 병합한다.
-3. **명확화 판단**: 코드 주석·변수명 등에 의도적 설계를 시사하는 표현("의도적", "팀 규칙", "컨벤션" 등)이 있는 경우, 해당 이슈를 제외하기 전에 반드시 `.claude/references/sd-clarify.md`를 읽고 분류를 수행한다. 코드 주석만으로는 VERIFIED가 아니며, CLAUDE.md나 공식 문서에 근거가 없으면 INFERRED Medium 이하로 분류한다.
+3. **명확화 판단**: 코드 주석·변수명 등에 의도적 설계를 시사하는 표현("의도적", "팀 규칙", "컨벤션" 등)이 있는 경우, 해당 이슈를 제외하기 전에 반드시 `.claude/rules/sd-clarify.md` 지침에 따라 분류를 수행한다. 코드 주석만으로는 VERIFIED가 아니며, CLAUDE.md나 공식 문서에 근거가 없으면 INFERRED Medium 이하로 분류한다.
 
 검증을 통과한 이슈만 Step 5로 진행한다.
 

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

@@ -8,7 +8,7 @@ description: 정적 분석이 잡지 못하는 관점(로직 버그, 일관성,
 
 ## Step 1: 코드 리뷰
 
-@.claude/references/sd-review.md 를 읽고 따른다.
+`/sd-inner-review` 스킬을 호출한다.
 
 ## Step 2: 문서 기록
 

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

@@ -19,9 +19,9 @@ Feature 문서(요구명세 + 구현계획)를 기반으로, Double Loop TDD로
 1. **해당 구현을 중단**한다.
 2. `.claude/rules/sd-options.md` 의 지침에 따라, 사용자에게 대안을 제시한다.
 3. 사용자가 결정하면
-  - 해당 결정을 Feature 문서의 `### 설계 결정` 섹션에 역방향 피드백으로 기록한다
-  - 결정에 따라 구현계획을 갱신한다
-  - 갱신된 Feature 문서로 구현을 재개한다
+- 해당 결정을 Feature 문서의 `### 설계 결정` 섹션에 역방향 피드백으로 기록한다
+- 결정에 따라 구현계획을 갱신한다
+- 갱신된 Feature 문서로 구현을 재개한다
 
 설계 결정의 변경은 사용자만이 할 수 있다.
 sd-tdd는 설계를 그대로 구현하는 역할이므로, 문서(요구명세·구현계획·설계 결정)를 사용자 결정 없이 독자적으로 변경하지 않는다(NEVER).
@@ -117,11 +117,11 @@ Feature 문서의 `## 참조 자료` 섹션 및 그 하위섹션을 반드시
 ### 1-3. 문서 정합성 확인
 
 요구명세의 각 Scenario에서 참조하는 기능·메서드를 구현계획과 대조한다.
-@.claude/references/sd-clarify.md 를 읽고 누락된 기능등 불명확한 부분을 명확화한다.
+@.claude/rules/sd-clarify.md 지침에 따라 누락된 기능등 불명확한 부분을 명확화한다.
 
 ## Step 2: Double Loop TDD
 
-테스트 작성 시 @.claude/references/sd-testing.md 를 읽고 따른다.
+테스트 작성 시 @.claude/references/sd-testing.md 를 읽고 따른다. (특히, mock 남발 금지)
 
 구현계획의 Slice 순서대로 진행한다. 각 Slice 내에서 Scenario를 하나씩 처리한다.
 각 Scenario 시작 시 **테스트 분류 기준**에 따라 검증 항목을 분류한다.
@@ -153,8 +153,8 @@ Acceptance Test를 통과시키기 위해 **반드시 Unit Test를 먼저 작성
 1. **Unit Test 작성 (Red)** — Acceptance Test와 별개의 도구 호출(Write/Edit)로 작성한다
 2. **최소 구현 (Green)** — Unit Test를 통과시키는 최소한의 코드를 작성한다
 3. **Refactor**
-   - 방금 작성한 코드 범위에서 중복 제거, 하드코딩 제거(Fake It → 실제 구현), 네이밍 개선, Extract Variable/Method.
-   - 모듈·아키텍처 수준 정리는 여기서 하지 않는다 — 그것은 `Outer Loop Refactor`의 영역이다.
+  - 방금 작성한 코드 범위에서 중복 제거, 하드코딩 제거(Fake It → 실제 구현), 네이밍 개선, Extract Variable/Method.
+  - 모듈·아키텍처 수준 정리는 여기서 하지 않는다 — 그것은 `Outer Loop Refactor`의 영역이다.
 
 Acceptance Test가 성공할때 까지 반복한다.
 

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

@@ -1,6 +1,8 @@
 ---
 name: sd-use
 description: 자연어 요청을 적절한 sd-* 스킬로 라우팅하는 스킬. "sd-use 커밋해줘", "sd-use --help" 등을 요청할 때 사용한다.
+model: sonnet
+effort: low
 ---
 
 # sd-use: SD 스킬 라우터

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

@@ -9,10 +9,10 @@ description: 프로젝트 요구사항을 Feature 단위로 분해하는 스킬.
 
 사용자가 제공한 요구사항에 대한 분석을 시작한다.
 문서 파일(docx, xlsx, pdf 등)이 제공된 경우, `/sd-doc-extract`로 내용을 추출하여 분석한다.
-기존 wbs 경로가 제공하고 수정하기로 한 경우, 해당 문서를 읽고 업데이트한다.
+기존 wbs 경로를 제공하고 수정하기를 원하는 경우, 해당 문서를 읽고 업데이트한다.
 마이그레이션 등 기존 시스템이 요구사항 원천인 경우, 기존 코드베이스를 참조하여 기능을 파악한다.
 요구사항과 함께 **프로젝트 개요**(배경, 환경, 전제조건, 기술적 제약)를 파악한다.
-@.claude/references/sd-clarify.md 지침에 따라 명확화한다.
+@.claude/rules/sd-clarify.md 지침에 따라 명확화한다.
 
 ## Step 2: Impact Mapping
 
@@ -23,7 +23,7 @@ Impact Mapping 트리(Goal → Actor → Impact → Deliverable)를 구축한다
 비즈니스 요구사항(What)에 대한 분석만 한다.
 
 - 기술적 구현 방법(How) — 인증 방식, 통신 프로토콜, 프레임워크, 아키텍처 패턴 등 — 에 대한 결정은 분석 단계에서 하지 않는다.
-- @.claude/references/sd-clarify.md 지침에 따라 명확화한다.
+- @.claude/rules/sd-clarify.md 지침에 따라 명확화한다.
 
 ### 명확화 항목
 
@@ -77,14 +77,36 @@ Feature는 독립적으로 설계·개발·검증할 수 있는 최소 기능
 
 ### Feature 작성 규칙
 
-- **의존성**: 이 Feature의 범위(세부 기능)를 하나씩 검토하여, 해당 기능을 구현하려면 다른 어떤 Feature가 먼저 완료돼야 하는지 판단한다. 선행 Feature가 있으면 명시하고, 없으면 "없음". (의존성에 따라 병렬 진행할 수 있으므로 중요)
+- **의존성**: 이 Feature의 범위(세부 기능)를 **하나씩** 검토하여, 각 세부 기능이 다른 Feature의 산출물(API, 컴포넌트, 데이터 구조, 서비스 등)을 필요로 하는지 판단한다.
+  - **판단 절차**: 세부 기능마다 "이것을 구현하려면 다른 Feature의 무엇이 먼저 존재해야 하는가?"를 질문하고, 해당하는 Feature 번호와 필요한 산출물을 명시한다.
+  - **불확실하면 의존성 있음으로 판단한다** — 의존성 누락은 병렬 수행 시 블로킹을 유발하므로, 과소 설정보다 과대 설정이 안전하다.
+  - 형식: `Feature X.Y (산출물명)` 또는 "없음"
+  - (의존성에 따라 병렬 진행할 수 있으므로 **CRITICAL**)
 - **범위**: 해당 Feature의 세부 기능을 사용자 기능(user-facing function) 수준으로 **MUST 빠짐없이** 나열한다. (절대 누락되어선 안된다. 누락된것은 다음단계에서 제외사항으로 판단될 수 있다.)
 - **경계**: 이 Feature가 **하지 않는 것** 중 다른 Feature에서 다루거나 다룰 수 있는 것을 명시한다. 인접 Feature와의 경계가 모호한 경우 특히 중요하다. (프로젝트 전체에서 제외되는 항목은 문서 하단의 "제외 사항"에 기재한다.)
 - **근거**: 범위가 도출된 근거 혹은 출처를 명시한다. (요구사항, 사용자 답변, 첨부문서 등) 개발에 필요한 참조 파일/자료 경로가 있으면 확인 목적과 함께 기록한다.
 
-각 Feature의 세부 사항을 분류하고 @.claude/references/sd-clarify.md 지침에 따라 불명확한 부분을 명확화한다.
+각 Feature의 세부 사항을 분류하고 @.claude/rules/sd-clarify.md 지침에 따라 불명확한 부분을 명확화한다.
 - **나쁜 예:** "예약 기능 포함이 결정됨 → 예약 세부규칙(대기열 정책, 미대출 시 자동취소 기간)도 확정" — 기능 포함 여부와 세부 수치/규칙은 별개다. 세부사항은 별도로 분류·질문한다.
 
+### 의존성 매트릭스 검증
+
+모든 Feature 작성 후, 의존성 매트릭스를 생성하여 다음을 **MUST** 검증한다:
+
+1. **누락 검증**: 각 Feature의 세부 기능이 참조하는 산출물이 다른 Feature에서 제공되는데 의존성에 빠져 있지 않은지 크로스체크
+2. **순환 검증**: A→B→A 같은 순환 의존성이 없는지 확인 (발견 시 Feature 분할로 해소)
+3. **1단계 존재 확인**: 의존성이 없는 Feature가 최소 1개 이상 존재하는지 확인
+
+매트릭스 형식:
+
+```
+| Feature | 의존 대상 | 필요 산출물 |
+|---------|----------|-----------|
+| 1.1     | 없음      | -         |
+| 1.2     | 1.1      | 공통 레이아웃 컴포넌트 |
+| 2.1     | 1.1      | API 기본 구조 |
+```
+
 ## Step 4: WBS 문서 생성
 
 산출물 경로:
@@ -158,24 +180,25 @@ Feature는 독립적으로 설계·개발·검증할 수 있는 최소 기능
 
 **CRITIAL: 각 Feature는 새 세션에서 진행되므로, 절대(NEVER) wbs문서에 누락이 있어서는 안됨**
 
-## Step 6: 의존성 요약 테이블 출력
+## Step 6: 수행 순서 안내
 
-문서 작성이 완료되면, 전체 Feature의 의존성 관계를 한눈에 볼 수 있도록 테이블을 출력한다.
+문서 작성이 완료되면, 의존성을 기반으로 Feature를 단계별로 그룹화하여 수행 순서를 안내한다.
+
+- 의존성이 없는 Feature들을 1단계로 묶는다
+- 이전 단계의 Feature에만 의존하는 Feature들을 다음 단계로 묶는다
+- 같은 단계 내 Feature는 병렬 수행 가능함을 표시한다
+- 각 Feature의 선행 의존성을 `(← ...)` 형태로 명시한다
 
 예시:
 
 ```
-┌─────┬─────────────────────────────┬────────┐
-│  #  │           Feature           │ 의존성 │
-├─────┼─────────────────────────────┼────────┤
-│ 1.1 │ 공통 프로바이더 & 플러그인  │ 없음   │
-├─────┼─────────────────────────────┼────────┤
-│ 1.2 │ 홈 레이아웃 & 사이드바 메뉴 │ 1.1    │
-├─────┼─────────────────────────────┼────────┤
-│ 2.1 │ 입고 처리                   │ 1.1    │
-├─────┼─────────────────────────────┼────────┤
-│ 2.2 │ 출고 처리                   │ 1.1    │
-└─────┴─────────────────────────────┴────────┘
+1단계 (병렬 수행 가능)
+  - Feature 1.1: 공통 프로바이더 & 플러그인
+
+2단계 (병렬 수행 가능)
+  - Feature 1.2: 홈 레이아웃 & 사이드바 메뉴 (← 1.1)
+  - Feature 2.1: 입고 처리 (← 1.1)
+  - Feature 2.2: 출고 처리 (← 1.1)
 ```
 
 ## Step 7: 다음 단계 안내

package/package.json

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