@simplysm/sd-claude 14.0.47 → 14.0.48

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

@@ -1,80 +1,84 @@
----
-name: sd-use
-description: 자연어 요청을 적절한 sd-* 스킬로 라우팅하는 스킬. "sd-use 커밋해줘", "sd-use --help" 등을 요청할 때 사용한다.
-model: claude-haiku-4-5
----
-
-# sd-use: SD 스킬 라우터
-
-사용자의 요청을 적절한 sd-* 스킬로 라우팅한다. 개별 sd-* 스킬에 익숙하지 않은 사용자가 원하는 작업을 자연어로 설명하면, sd-use가 가장 적합한 스킬을 선택하여 실행한다.
-
-## 인자
-
-| 인자 | 설명 |
-|------|------|
-| `{request}` | 사용자가 원하는 작업의 자연어 설명 |
-| `--help` | 워크플로우 개요 및 스킬 카탈로그 표시 |
-
-## Step 1: 입력 파싱
-
-- 인자가 없거나 `--help`이면 → Step 2
-- 그 외 → Step 3
-
-## Step 2: Help 모드
-
-아래 코드 블록을 그대로 출력한 후 종료한다. Skill 도구를 호출하지 않는다.
-마크다운 표나 리스트로 변환하지 않는다. 반드시 단일 코드 블록(``` 안)으로 출력한다.
-
-````
-sd-use — SD 스킬 라우터
-
-USAGE
-  /sd-use <request>       자연어 요청을 적절한 스킬로 라우팅
-  /sd-use --help          이 도움말 표시
-
-FLOWS
-  진입점                             개발 파이프라인
-  sd-wbs    프로젝트 → Feature 분해 ─┐
-  sd-review 코드 리뷰 → 리포트 생성  ├→ sd-plan → sd-tdd
-  sd-debug  에러 → 근본 원인 분석    │  │        │
-  (없음)    바로 개발 시작          ─┘  └────────┘
-                                        sd-dev (순차 실행)
-
-SKILLS
-  개발
-    sd-dev              Feature 전체 개발 (wbs → plan → TDD → check → review)
-    sd-wbs              프로젝트 → Feature 분해 (WBS)
-    sd-plan             Feature 요구명세 + 구현계획 작성
-    sd-tdd              구현 계획 → TDD 코드 구현
-
-  품질
-    sd-check            typecheck / lint / test 실행 및 에러 수정
-    sd-review           로직 버그, 보안, 성능, 설계 이슈 리뷰
-    sd-debug            버그/에러 근본 원인 분석
-
-  Git
-    sd-commit           전체 변경사항 단일 커밋 생성
-    sd-issue            GitHub 이슈 생성
-
-  문서
-    sd-claude-docs      CLAUDE.md + README.md 생성
-    sd-doc-extract      문서에서 텍스트/이미지 추출
-    sd-deliverable      매뉴얼 & SIT 문서 생성
-
-  도구
-    sd-prompt           스킬/프롬프트 파일 생성·개선
-    sd-outlook          Outlook 메일 검색/다운로드
-    sd-apk-decompile    APK 디컴파일
-````
-
-## Step 3: 스킬 실행
-
-### 3-1. 스킬 라우팅
-
-스킬 카탈로그를 참조하여 사용자의 요청을 가장 적합한 스킬에 라우팅한다. 단일 스킬에 명확히 라우팅되지 않으면 후보 스킬들을 선택지로 제시하여 사용자에게 확인한다. (`.claude/rules/sd-options.md`를 읽고 따른다)
-
-### 3-2. 안내 및 실행
-
-선택된 스킬을 사용자에게 알리는 텍스트 메시지를 출력한 후 Skill 도구를 호출한다. 안내는 필수이다. 예시: `> **sd-commit** 스킬을 실행합니다.`
-
-선택된 스킬 이름과 함께 사용자의 원래 요청을 `args`로 전달한다.
+---
+name: sd-use
+description: 자연어 요청을 적절한 sd-* 스킬로 라우팅하는 스킬. "sd-use 커밋해줘", "sd-use --help" 등을 요청할 때 사용한다.
+model: haiku
+---
+
+# sd-use: SD 스킬 라우터
+
+사용자의 요청을 적절한 sd-* 스킬로 라우팅한다. 개별 sd-* 스킬에 익숙하지 않은 사용자가 원하는 작업을 자연어로 설명하면, sd-use가 가장 적합한 스킬을 선택하여 실행한다.
+
+## 인자
+
+| 인자 | 설명 |
+|------|------|
+| `{request}` | 사용자가 원하는 작업의 자연어 설명 |
+| `--help` | 워크플로우 개요 및 스킬 카탈로그 표시 |
+
+## Step 1: 입력 파싱
+
+- 인자가 없거나 `--help`이면 → Step 2
+- 그 외 → Step 3
+
+## Step 2: Help 모드
+
+아래 코드 블록을 그대로 출력한 후 종료한다. Skill 도구를 호출하지 않는다.
+마크다운 표나 리스트로 변환하지 않는다. 반드시 단일 코드 블록(``` 안)으로 출력한다.
+
+````
+sd-use — SD 스킬 라우터
+
+USAGE
+  /sd-use <request>       자연어 요청을 적절한 스킬로 라우팅
+  /sd-use --help          이 도움말 표시
+
+FLOWS
+  진입점                             개발 파이프라인
+  sd-wbs    프로젝트 → Feature 분해 ─┐
+  sd-review 코드 리뷰 → 리포트 생성  ├→ sd-plan → sd-tdd
+  sd-debug  에러 → 근본 원인 분석    │  │        │
+  (없음)    바로 개발 시작          ─┘  └────────┘
+                                        sd-dev (순차 실행)
+
+SKILLS
+  개발
+    sd-dev              Feature 전체 개발 (wbs → plan → TDD → check → review)
+    sd-wbs              프로젝트 → Feature 분해 (WBS)
+    sd-plan             Feature 요구명세 + 구현계획 작성
+    sd-tdd              구현 계획 → TDD 코드 구현
+
+  품질
+    sd-check            typecheck / lint / test 실행 및 에러 수정
+    sd-review           로직 버그, 보안, 성능, 설계 이슈 리뷰
+    sd-refactor         구조·설계·아키텍처 리팩토링 분석 리포트
+    sd-debug            버그/에러 근본 원인 분석
+
+  Git
+    sd-commit           전체 변경사항 단일 커밋 생성
+    sd-issue            GitHub 이슈 생성
+
+  문서
+    sd-claude-docs      CLAUDE.md + usage 문서 생성
+    sd-doc-extract      문서에서 텍스트/이미지 추출
+    sd-deliverable      매뉴얼 & SIT 문서 생성
+
+  도구
+    sd-prompt           스킬/프롬프트 파일 생성·개선
+    sd-outlook          Outlook 메일 검색/다운로드
+
+  기타
+    my-apk-decompile    APK 디컴파일 및 소스 분석
+    playwright-cli      브라우저 자동화 및 Playwright 테스트
+````
+
+## Step 3: 스킬 실행
+
+### 3-1. 스킬 라우팅
+
+스킬 카탈로그를 참조하여 사용자의 요청을 가장 적합한 스킬에 라우팅한다. 단일 스킬에 명확히 라우팅되지 않으면 후보 스킬들을 선택지로 제시하여 사용자에게 확인한다. (`.claude/rules/sd-options.md`를 읽고 따른다)
+
+### 3-2. 안내 및 실행
+
+선택된 스킬을 사용자에게 알리는 텍스트 메시지를 출력한 후 Skill 도구를 호출한다. 안내는 필수이다. 예시: `> **sd-commit** 스킬을 실행합니다.`
+
+선택된 스킬 이름과 함께 사용자의 원래 요청을 `args`로 전달한다.

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

@@ -12,7 +12,7 @@ description: 프로젝트 요구사항을 Feature 단위로 분해하는 스킬.
 기존 wbs 경로를 제공하고 수정하기를 원하는 경우, 해당 문서를 읽고 업데이트한다.
 마이그레이션 등 기존 시스템이 요구사항 원천인 경우, 기존 코드베이스를 참조하여 기능을 파악한다.
 요구사항과 함께 **프로젝트 개요**(배경, 환경, 전제조건, 기술적 제약)를 파악한다.
-@.claude/rules/sd-clarify.md 지침에 따라 명확화한다.
+`/sd-inner-clarify` 스킬을 호출하여 명확화한다.
 
 ## Step 2: Impact Mapping
 
@@ -23,7 +23,7 @@ Impact Mapping 트리(Goal → Actor → Impact → Deliverable)를 구축한다
 비즈니스 요구사항(What)에 대한 분석만 한다.
 
 - 기술적 구현 방법(How) — 인증 방식, 통신 프로토콜, 프레임워크, 아키텍처 패턴 등 — 에 대한 결정은 분석 단계에서 하지 않는다.
-- @.claude/rules/sd-clarify.md 지침에 따라 명확화한다.
+- `/sd-inner-clarify` 스킬을 호출하여 명확화한다.
 
 ### 명확화 항목
 
@@ -43,7 +43,7 @@ Impact Mapping 트리(Goal → Actor → Impact → Deliverable)를 구축한다
 ### Impact Mapping 규칙
 
 - 모든 Feature가 Goal까지 역추적 가능해야 한다 — Goal에 연결되지 않는 기능은 제외 사항으로 보낸다
-- Goal은 측정 가능하게 기술한다. "효율화"(X) → "처리 시간 30% 단축"(O)
+- Goal은 구체적 목적을 명확히 기술한다. "효율화한다"(X) → "대출·반납 기록을 시스템으로 관리하여 분실을 방지한다"(O). 수치 기반이 가능하면 좋지만 필수 아님.
 - Impact는 기능이 아닌 **행동 변화**를 기술한다. "대시보드를 본다"(X) → "업무 상태를 빠르게 파악한다"(O)
 
 ## Step 3: Feature Breakdown
@@ -54,12 +54,11 @@ Deliverable을 Epic → Feature로 구조화한다.
 
 Epic은 **사용자 관점의 기능 영역**(비즈니스 기능) 단위로 그룹화한다.
 기술 계층(서버/클라이언트), 패키지, 아키텍처 레이어별로 분류하지 않는다(NEVER).
-하나의 기능이 서버와 클라이언트에 걸쳐 있으면 하나의 Epic 안에 Feature로 나열한다.
 
 **좋은 예:**
 
-- "로깅" Epic → Feature 1: 서버 로깅 서비스, Feature 2: 클라이언트 로깅 호출
-- "인증" Epic → Feature 1: 인증 토큰 발급(서버), Feature 2: 로그인 화면(클라이언트)
+- "인증" Epic → Feature 1: 사용자 로그인, Feature 2: 비밀번호 재설정
+- "알림" Epic → Feature 1: 토스트 알림, Feature 2: 이메일 알림
 
 **나쁜 예:**
 
@@ -68,47 +67,105 @@ Epic은 **사용자 관점의 기능 영역**(비즈니스 기능) 단위로 그
 
 ### Feature 분해 원칙
 
-Feature는 독립적으로 설계·개발·검증할 수 있는 최소 기능 단위이다.
+Feature는 독립적으로 설계·개발·검증할 수 있는 최소 **기능** 단위이다.
 
-- 같은 세부기능을 공유한다는 이유로 독립 모듈을 하나의 Feature로 묶지 않는다. (예: event-bus Feature + 모달 Feature + 토스트 Feature —
-  묶지 않음)
+**CRITICAL: Feature를 아키텍처 레이어(DB/서비스/UI, 서버/클라이언트, 프론트엔드/백엔드, 패키지 등)로 분할하는 것은 절대 금지(NEVER).**
+하나의 Feature는 해당 기능을 완성하기 위한 모든 레이어(DB 스키마, API, UI 화면 등)의 산출물을 end-to-end로 포함한다.
+
+- **좋은 예:** "사용자 로그인" Feature → DB users 테이블 + 토큰 발급 API + 로그인 화면을 모두 한 Feature에 포함
+- **나쁜 예:** Feature 1 "users 테이블 스키마" / Feature 2 "로그인 API" / Feature 3 "로그인 화면" — 레이어 분할 금지
+- **나쁜 예:** Feature 1 "인증 토큰 발급(서버)" / Feature 2 "로그인 화면(클라이언트)" — 서버/클라이언트 분할 금지
+- **나쁜 예:** Feature 1 "도서 관리(관리자)" / Feature 2 "도서 조회(직원)" — 동일 도메인("도서")을 Actor(역할)로 분할 금지. "도서 관리" 단일 Feature에 관리자 화면 + 직원 화면을 함께 포함
+
+**CRITICAL: 기계적 판정 규칙 (예외 없음, 재량 금지)**
+
+아래 중 **하나라도** 해당하면 무조건(MUST) 해당 Feature들을 단일 Feature로 병합한다. "기능 성격이 다르다", "CRUD와 조회는 다르다" 같은 자체 합리화는 금지(NEVER)한다.
+
+1. **Feature 이름에 Actor(역할)가 괄호/접미사로 포함된 경우** (예: "(관리자)", "(직원)", "(고객)", "관리자용", "직원용")
+2. **동일 도메인 엔터티(예: "도서", "대출")에 대한 기능이 서로 다른 Feature에 나뉘어 등장하는 경우**
+3. **두 Feature의 범위에 동일하거나 유사한 기능명**(예: "도서 목록 조회", "주문 목록 조회")**이 각각 등장하는 경우** (뷰/필터/권한 차이는 병합 사유를 면제하지 않는다)
+
+그 외 규칙:
+
+- 같은 세부기능을 공유한다는 이유로 독립 모듈을 하나의 Feature로 묶지 않는다. (예: event-bus Feature + 모달 Feature + 토스트 Feature — 묶지 않음)
 - 범주는 Epic, 개별 기능이 Feature (예: "알림" Epic → 토스트 알림, 모달 알림, 이메일 알림 각각이 Feature)
 - 가능한한 의존성 순서로 정렬
 - **테스트 작성을 별도 Feature로 분리하지 않는다(NEVER).** 각 Feature는 `sd-tdd`로 구현될 때 테스트와 프로덕션 코드를 함께 작성한다.
 
 ### Feature 작성 규칙
 
-- **의존성**: 이 Feature의 범위(세부 기능)를 **하나씩** 검토하여, 각 세부 기능이 다른 Feature의 산출물(API, 컴포넌트, 데이터 구조, 서비스 등)을 필요로 하는지 판단한다.
-  - **판단 절차**: 세부 기능마다 "이것을 구현하려면 다른 Feature의 무엇이 먼저 존재해야 하는가?"를 질문하고, 해당하는 Feature 번호와 필요한 산출물을 명시한다.
-  - **불확실하면 의존성 있음으로 판단한다** — 의존성 누락은 병렬 수행 시 블로킹을 유발하므로, 과소 설정보다 과대 설정이 안전하다.
-  - 형식: `Feature X.Y (산출물명)` 또는 "없음"
+- **의존성**: 이 Feature의 범위(세부 기능)를 **하나씩** 검토하여, 다른 Feature와의 아래 두 종류 관계를 모두 판단한다.
+  - **(1) 산출물 참조 관계 (코드 연결성)**: 이 Feature의 세부 기능이 다른 Feature가 만든 산출물(API, 컴포넌트, 데이터 구조, 서비스, 모듈 등)을 직접 사용한다면 그 Feature에 의존.
+  - **(2) 결정 파급 관계 (CRITICAL, 자주 누락됨)**: 다른 Feature에서 내려지는 결정(명명 규칙, 공통 패턴, 레시피 스타일, 분기 구조, 공유 용어 등)이 확정되지 않으면 이 Feature의 **내용이 변할 수 있다면** 그 Feature에 의존.
+    - 예시: Feature A가 "페이지/모달 분기 패턴"을 정립하고 Feature B 레시피가 그 분기를 **복붙**해서 쓴다면, A의 분기 구조가 바뀔 때 B 레시피도 변함 → B는 A에 의존
+    - 예시: Feature A가 "레시피 작성 관용 규칙"을 정립하고 Feature B가 그 규칙을 따라야 한다면 → B는 A에 의존
+    - 예시: Feature A에서 API 이름을 확정하고 Feature B가 그 이름을 문서·레시피에 인용한다면 → B는 A에 의존
+    - "코드 간 import 없음"이 의존성 없음을 의미하지 **않는다**. 결정 파급은 signal 수준보다 **문서·규칙·명명 수준**에서 더 흔히 발생한다.
+  - **판단 절차**: 세부 기능마다 "이것을 구현·기술하려면 다른 Feature가 먼저 완료되어야 하는가? 혹은 다른 Feature의 결정이 내 내용을 바꿀 수 있는가?"를 질문하고, 해당하는 Feature 번호를 명시한다.
+  - **불확실하면 의존성 있음으로 판단한다** — 의존성 누락은 병렬 수행 시 블로킹·재작업을 유발하므로, 과소 설정보다 과대 설정이 안전하다.
+  - 형식: Feature 번호만 쉼표로 나열 (예: `1.1, 2.3`) 또는 `없음`
   - (의존성에 따라 병렬 진행할 수 있으므로 **CRITICAL**)
 - **범위**: 해당 Feature의 세부 기능을 사용자 기능(user-facing function) 수준으로 **MUST 빠짐없이** 나열한다. (절대 누락되어선 안된다. 누락된것은 다음단계에서 제외사항으로 판단될 수 있다.)
 - **경계**: 이 Feature가 **하지 않는 것** 중 다른 Feature에서 다루거나 다룰 수 있는 것을 명시한다. 인접 Feature와의 경계가 모호한 경우 특히 중요하다. (프로젝트 전체에서 제외되는 항목은 문서 하단의 "제외 사항"에 기재한다.)
 - **근거**: 범위가 도출된 근거 혹은 출처를 명시한다. (요구사항, 사용자 답변, 첨부문서 등) 개발에 필요한 참조 파일/자료 경로가 있으면 확인 목적과 함께 기록한다.
 
-각 Feature의 세부 사항을 분류하고 @.claude/rules/sd-clarify.md 지침에 따라 불명확한 부분을 명확화한다.
+각 Feature의 세부 사항을 분류하고 `/sd-inner-clarify` 스킬을 호출하여 불명확한 부분을 명확화한다.
 - **나쁜 예:** "예약 기능 포함이 결정됨 → 예약 세부규칙(대기열 정책, 미대출 시 자동취소 기간)도 확정" — 기능 포함 여부와 세부 수치/규칙은 별개다. 세부사항은 별도로 분류·질문한다.
 
-### 의존성 매트릭스 검증
+### Feature-Deliverable 역추적 강제 규칙
+
+**CRITICAL: 모든 Feature는 Impact Mapping의 특정 Deliverable에서 유래해야 한다. 근거란에 유래 Deliverable을 명시(인용)하지 못하는 Feature는 추가 금지(NEVER).**
+
+Feature를 작성하다가 "이건 시스템 동작상 당연히 필요하다"는 판단이 드는데 Impact Mapping Deliverable로 역추적 불가한 경우(예: 사용자 계정 관리, 권한 설정, 로그, 알림 설정 등 Impact Mapping에는 없지만 실행에 필요해 보이는 기능):
+
+1. **절대 혼자 추가하지 않는다(NEVER).** "당연히 필요하다"는 추측으로 Feature를 임의 추가하거나 제외 사항에 자체 결정을 기재하는 것은 금지.
+2. **반드시 `/sd-inner-clarify`를 호출**하여 해당 기능을 포함할지 질문한다. 질문 형식:
+   - 결정 대상: "{기능명}"을 시스템에 포함할지
+   - 선택지: 포함 / 미포함 / 수행 안 함
+3. **포함으로 결정되면** Step 2로 돌아가 Impact Mapping에 해당 Deliverable을 먼저 추가한 뒤, Feature를 작성한다.
+4. **미포함으로 결정되면** "제외 사항"에 기재하고 Feature는 만들지 않는다.
+
+**판단 체크:** Step 3을 마치기 전, 모든 Feature의 근거란을 훑어 **"Impact Mapping Deliverable: ..."** 인용이 **반드시** 1건 이상 존재하는지 확인한다. 없는 Feature가 있으면 위 1~4 절차로 처리한다.
+
+## Step 4: 자가검증 (Self-Refine)
+
+1차 산출된 WBS를 아래 6가지 관점으로 **MUST** 재검토하고, 필요 시 **분할·병합·순서조정·보완**을 수행하여 최종 WBS를 확정한다. 이 단계는 pass/fail 판정이 아니라 **정제(refine)**이며, 문제가 보이면 즉시 수정한다.
+
+### 검증 관점
+
+1. **Feature 크기** — 한 Feature가 과도하게 크거나 여러 목적을 겸하면 **분할**한다.
+   - 기준: 범위 항목이 지나치게 많거나(대략 7개 초과), 독립적으로 구현·검증 가능한 하위 단위로 자연스럽게 나뉘면 분할 후보.
+2. **의존성에 의한 순서** — 의존 대상이 뒤 번호에 있거나 같은 단계 내에 있으면 **번호/순서를 재정렬**한다.
+3. **Feature 중복/누락/역추적** — 요구사항(Impact Mapping의 Deliverable) 대비 **양방향** 커버리지를 점검한다.
+   - 여러 Feature가 같은 세부 기능을 중복으로 갖고 있으면 하나로 통합하거나 경계를 명확화.
+   - **정방향 (Deliverable → Feature):** 요구사항에 있는데 어떤 Feature에도 없는 항목은 추가하거나 "제외 사항"으로 사유와 함께 이동.
+   - **역방향 (Feature → Deliverable):** 모든 Feature가 Impact Mapping의 Deliverable로 역추적 가능한지 확인한다. 역추적 불가한 Feature가 있으면 Step 3의 "Feature-Deliverable 역추적 강제 규칙"에 따라 `/sd-inner-clarify`로 질문 후 처리한다. 임의 유지 금지(NEVER).
+4. **Feature 독립성 (단일 책임)** — 한 Feature의 이름과 실제 범위가 일치하는지 확인한다. 이름에 드러나지 않는 일을 몰래 수행하면 **분리**한다.
+5. **명명/범위 일관성** — Feature 경계가 Epic 분류 기준(사용자 관점 기능 영역)과 정합하는지 확인한다. 다음 케이스는 end-to-end 기능 단위로 **병합**한다.
+   - Feature가 아키텍처 레이어(DB/서비스/UI, 서버/클라이언트 등)로 쪼개져 있는 경우
+   - **동일 도메인 기능이 Actor(역할) 기준으로 여러 Feature에 분할되어 있는 경우** (예: "도서 관리(관리자)" + "도서 조회(직원)"는 "도서 관리" 단일 Feature로 병합하여 관리자 화면 + 직원 화면을 함께 포함). 범위에 동일 기능(예: "도서 목록 조회")이 뷰/권한만 다르게 다른 Feature에 반복 등장하면 이 케이스이다.
+6. **범위 항목의 검증 가능성** — 각 세부 기능이 완료 판정 가능한 구체적 표현인지 확인한다. "개선한다", "최적화한다" 같은 모호한 표현은 구체 동작으로 재작성한다.
+
+### 의존성 매트릭스
 
-모든 Feature 작성 후, 의존성 매트릭스를 생성하여 다음을 **MUST** 검증한다:
+위 2번 검증을 위해 의존성 매트릭스를 생성하고 다음을 확인한다:
 
-1. **누락 검증**: 각 Feature의 세부 기능이 참조하는 산출물이 다른 Feature에서 제공되는데 의존성에 빠져 있지 않은지 크로스체크
-2. **순환 검증**: A→B→A 같은 순환 의존성이 없는지 확인 (발견 시 Feature 분할로 해소)
+1. **누락 확인**: 각 Feature의 세부 기능이 (a) 다른 Feature의 산출물을 참조하거나 (b) 다른 Feature의 결정(명명·공통 패턴·레시피 스타일·분기 구조 등)에 의해 내용이 바뀔 수 있는데 의존성에 빠져 있지 않은지 크로스체크
+2. **순환 확인**: A→B→A 같은 순환 의존성이 없는지 확인 (발견 시 Feature 분할로 해소)
 3. **1단계 존재 확인**: 의존성이 없는 Feature가 최소 1개 이상 존재하는지 확인
 
 매트릭스 형식:
 
 ```
-| Feature | 의존 대상 | 필요 산출물 |
-|---------|----------|-----------|
-| 1.1     | 없음      | -         |
-| 1.2     | 1.1      | 공통 레이아웃 컴포넌트 |
-| 2.1     | 1.1      | API 기본 구조 |
+| Feature | 의존 대상 |
+|---------|----------|
+| 1.1     | 없음      |
+| 1.2     | 1.1      |
+| 2.1     | 1.1      |
+| 2.2     | 1.1, 2.1 |
 ```
 
-## Step 4: WBS 문서 생성
+## Step 5: WBS 문서 생성
 
 산출물 경로:
 
@@ -171,7 +228,7 @@ Feature는 독립적으로 설계·개발·검증할 수 있는 최소 기능
 - 현재 범위에서 명시적으로 제외하는 항목과, Impact Mapping에서 Goal에 연결되지 않는 기능을 나열한다.
 - 각 항목에 **사유**(Goal 미연결, 사용자 명시적 제외, 범위 초과 등)를 반드시 기재한다.
 
-## Step 5: 정보 유실 방지 검증
+## Step 6: 정보 유실 방지 검증
 
 문서 작성 후, 대화에서 수집한 모든 구체적 정보가 문서에 기록되었는지 검증한다.
 
@@ -181,7 +238,7 @@ Feature는 독립적으로 설계·개발·검증할 수 있는 최소 기능
 
 **CRITIAL: 각 Feature는 새 세션에서 진행되므로, 절대(NEVER) wbs문서에 누락이 있어서는 안됨**
 
-## Step 6: 수행 순서 안내
+## Step 7: 수행 순서 안내
 
 문서 작성이 완료되면, 의존성을 기반으로 Feature를 단계별로 그룹화하여 수행 순서를 안내한다.
 
@@ -202,7 +259,7 @@ Feature는 독립적으로 설계·개발·검증할 수 있는 최소 기능
   - Feature 2.2: 출고 처리 (← 1.1)
 ```
 
-## Step 7: 다음 단계 안내
+## Step 8: 다음 단계 안내
 
 WBS 완료 후, 개발을 위한 다음 단계를 안내한다.
 

package/{claude/references/sd-simplysm14/sd-claude/docs → docs}/assets.md

@@ -12,7 +12,7 @@ claude/
 ├── sd-check-bash.py             ← 훅 스크립트
 ├── sd-check-forbidden-files.py ← 훅 스크립트
 ├── sd-check-write.py            ← 훅 스크립트
-├── sd-session-start.sh          ← 훅 스크립트
+├── sd-subagent-start.sh         ← 훅 스크립트
 └── sd-statusline.py             ← 훅 스크립트
 ```
 
@@ -57,7 +57,6 @@ claude/
 ---
 name: sd-commit
 description: 전체 변경사항에 대한 단일 커밋을 생성하는 스킬. ...
-model: claude-haiku-4-5
 ---
 ```
 
@@ -69,7 +68,7 @@ model: claude-haiku-4-5
 
 ## `claude/rules/`
 
-Claude Code 규칙 파일. 세션 시작 시 `sd-session-start.sh`에 의해 읽기 대상으로 출력된다. 2개 파일.
+Claude Code 규칙 파일. 2개 파일.
 
 | 파일                 | Description                                                          |
 | -------------------- | -------------------------------------------------------------------- |

package/{claude/references/sd-simplysm14/sd-claude/docs → docs}/hooks.md

@@ -2,19 +2,20 @@
 
 `claude/` 디렉토리의 훅 스크립트 (총 5개). `postinstall`에 의해 `.claude/`에 설치되고, `settings.json`에 자동 등록되어 Claude Code 세션에서 실행된다.
 
-## `sd-session-start.sh`
+## `sd-subagent-start.sh`
 
-SessionStart 및 SubagentStart 훅. 세션 시작 시(startup, resume, clear, compact) `.claude/rules/*.md`와 `CLAUDE.md` 파일 경로를 출력하여 Claude가 읽도록 안내한다.
+SubagentStart 훅. subagent 시작 시 `CLAUDE.md`가 존재하면 파일 내용을 읽어 출력하여 subagent가 프로젝트 지침을 참조하도록 한다 (subagent 컨텍스트에서 CLAUDE.md가 자동 주입되지 않으므로).
 
 ```bash
 #!/bin/bash
-echo "Read the following rule files before proceeding:"
-# .claude/rules/*.md 파일 목록 출력
-# CLAUDE.md 존재 시 경로 출력
+if [ -f "CLAUDE.md" ]; then
+  echo "Project instructions from CLAUDE.md (auto-injected because subagent context omits it):"
+  echo
+  cat CLAUDE.md
+fi
 ```
 
 등록 위치:
-- `hooks.SessionStart` (matcher: `startup|resume|clear|compact`)
 - `hooks.SubagentStart` (matcher 없음)
 
 ## `sd-check-write.py`

package/{claude/references/sd-simplysm14/sd-claude/docs → docs}/scripts.md

@@ -65,14 +65,6 @@ function copySdEntries(sourceDir, targetDir, entries) → void
 | `targetDir` | `string` | 대상 디렉토리 (`.claude/`) |
 | `entries` | `string[]` | 복사할 항목의 상대 경로 배열 |
 
-#### `setupSettings(targetDir)`
-
-```javascript
-function setupSettings(targetDir) → void
-```
-
-`.claude/settings.json`에 훅 항목을 멱등적으로 등록한다.
-
 ---
 
 ## `sync.mjs`
@@ -104,7 +96,7 @@ export function forEachSdEntry(dir, callback) → void
 | `callback` | `(relativePath: string) => void` | 각 `sd-*` 항목의 상대 경로로 호출되는 콜백 |
 
 탐색 깊이는 2단계 고정:
-- 루트 레벨의 `sd-*` 항목 (예: `sd-session-start.sh`)
+- 루트 레벨의 `sd-*` 항목 (예: `sd-subagent-start.sh`)
 - 하위 디렉토리 내 `sd-*` 항목 (예: `skills/sd-commit`)
 
 ### `collectSdEntries(dir)`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "14.0.47",
+  "version": "14.0.48",
   "description": "심플리즘 패키지 - Claude Code 셋업",
   "author": "심플리즘",
   "license": "Apache-2.0",
@@ -15,7 +15,8 @@
   },
   "files": [
     "scripts",
-    "claude"
+    "claude",
+    "docs"
   ],
   "scripts": {
     "postinstall": "node scripts/postinstall.mjs"

package/scripts/sync.mjs

@@ -16,8 +16,10 @@ if (fs.existsSync(targetDir)) {
   fs.rmSync(targetDir, { recursive: true });
 }
 
-// sd-* 항목 탐색 및 settings.json 포함
-const allEntries = collectSdEntries(claudeDir);
+// sd-* 항목 탐색 및 settings.json 포함 (evals/ 제외)
+const allEntries = collectSdEntries(claudeDir).filter(
+  (rel) => !rel.replace(/\\/g, "/").startsWith("evals/"),
+);
 if (fs.existsSync(path.join(claudeDir, "settings.json"))) {
   allEntries.push("settings.json");
 }

package/claude/references/sd-simplysm14/angular/docs/bootstrap.md

@@ -1,48 +0,0 @@
-# Bootstrap
-
-## `provideSdAngular`
-
-모든 기반 설정을 제공하는 환경 프로바이더 팩토리. `bootstrapApplication`의 providers에 추가한다.
-
-```typescript
-function provideSdAngular(opt: { clientName: string }): EnvironmentProviders
-```
-
-제공하는 기능:
-- `provideZonelessChangeDetection()` - Zone 없는 변경 감지
-- `IMAGE_CONFIG` - 이미지 크기/지연 로딩 경고 비활성화
-- `provideNgIconsConfig({ strokeWidth: 1.5, size: "1.33em" })`
-- 6개 커스텀 이벤트 플러그인 등록 (sdSaveCommand, sdRefreshCommand, sdInsertCommand, sdResize, sdIntersection, option)
-- `SdGlobalErrorHandlerPlugin` - 글로벌 에러 핸들러
-- 테마 초기화 (localStorage 동기화, body 클래스 토글)
-- Service Worker 업데이트 폴링 (5분 간격, 실패 시 exponential backoff, 최대 1시간)
-- 라우터 네비게이션 busy 상태 추적
-
-| Parameter | Type | Description |
-|-----------|------|-------------|
-| `opt.clientName` | `string` | 클라이언트 이름 (localStorage 키 접두사 등에 사용) |
-
-## `SdAngularConfigProvider`
-
-`clientName` 설정을 보유하는 프로바이더. `provideSdAngular`에서 자동 설정된다.
-
-```typescript
-@Injectable({ providedIn: "root" })
-class SdAngularConfigProvider {
-  clientName!: string;
-}
-```
-
-| Field | Type | Description |
-|-------|------|-------------|
-| `clientName` | `string` | 클라이언트 이름 |
-
-## `TXT_CHANGE_IGNORE_CONFIRM`
-
-변경사항 무시 확인 메시지 문자열 상수.
-
-```typescript
-const TXT_CHANGE_IGNORE_CONFIRM: string
-```
-
-내용: `"변경사항이 있습니다. 모든 변경사항을 무시하시겠습니까?\n- 확인: 변경사항을 무시하고, 현재 요청한 작업을 수행\n- 취소: 현재 요청한 작업을 취소하고, 변경사항 재검토"`