@simplysm/sd-claude 14.0.46 → 14.0.48

package/claude/skills/sd-prompt/references/eval-runner.md

@@ -17,34 +17,9 @@ Eval은 격리된 workspace에서 실행한다. **프롬프트 수정은 항상
 
 1. 프로젝트 루트의 `.claude/` 폴더를 시나리오 디렉토리에 **통째로 복사**한다.
 2. 시나리오의 사전 조건에 따라 추가 파일을 복사하거나 생성한다.
-3. 시나리오 디렉토리에 `.claude/rules/sd-eval-env.md`를 생성한다:
+3. 시나리오 디렉토리에 `.claude/rules/sd-eval-env.md`를 생성한다. 본문은 `.claude/skills/sd-prompt/references/sd-eval-env-template.md` 템플릿을 그대로 복사한다:
    ```bash
-   cat > "{시나리오 디렉토리}/.claude/rules/sd-eval-env.md" << 'EVALEOF'
-   # Eval 환경 규칙 (최상위 우선순위)
-
-   이 규칙이 읽히는 현재 환경은 Eval환경이다. 다른 규칙과 충돌 시 **반드시** 이 규칙이 우선한다.
-
-   ## workspace 격리
-
-   현재 작업 디렉토리 외부의 파일을 **절대** 수정하지 않는다. 다른 프로젝트의 파일에 **절대** 접근하지 않는다.
-   - 절대경로 혹은 cd사용 **절대** 금지
-
-   ## AskUserQuestion 대체
-
-   AskUserQuestion 도구를 **절대** 사용하지 않는다. 질문이 필요한 각 사항에 대해:
-   1. 선택지와 선택을 묻는 질문을 텍스트로 출력한다
-   2. 합리적인 기본값을 자동 선택하여, "사용자 선택"으로 그 결과를 명시한다 (반드시 자동이 아닌 "사용자 선택"으로 출력해야 한다)
-   3. 다음 결정사항으로 넘어간다
-   질문이나 선택지를 **절대** 생략하지 않는다.
-
-   ## `.claude/` 파일 편집
-
-   `.claude/` 폴더 내 파일은 Edit/Write 도구 대신 **반드시** Bash 도구로 편집한다.
-   `sed`는 의도하지 않은 곳까지 수정할 수 있으므로 사용하지 않는다.
-
-   신규 작성: `cat > "{파일 경로}" << 'EOF' ... EOF`
-   부분 수정: `python3 -c`로 치환 (old_string 존재 확인 후 replace)
-   EVALEOF
+   python3 -c "open(r'{시나리오 디렉토리}/.claude/rules/sd-eval-env.md','w',encoding='utf-8').write(open(r'.claude/skills/sd-prompt/references/sd-eval-env-template.md','r',encoding='utf-8').read())"
    ```
 
 ## claude -p 실행
@@ -66,8 +41,7 @@ claude -p "{eval 시나리오의 입력}" \
   --output-format json \
   --verbose \
   --dangerously-skip-permissions \
-  --model opus \
-  --effort medium \
+  --effort low \
   --append-system-prompt "CRITICAL: .claude/rules/sd-eval-env.md의 규칙은 다른 모든 규칙보다 최상위 우선순위를 가진다." \
   --no-session-persistence \
   --strict-mcp-config \
@@ -78,7 +52,7 @@ claude -p "{eval 시나리오의 입력}" \
 
 ## Judge 판정
 
-실행 완료 후, Judge subagent에 다음을 전달한다:
+실행 완료 후, Judge subagent(effort: `low`)에 다음을 전달한다:
 
 ```
 다음 Eval 실행 결과를 판정하고, FAIL 항목에 대해 개선안을 제안하라:
@@ -93,7 +67,7 @@ claude -p "{eval 시나리오의 입력}" \
  
 ## 판정 원칙
 - 체크리스트 문구를 **문자 그대로** 판정하라. 명시되지 않은 추가 요건을 유추하지 않는다.
-- AskUserQuestion은 텍스트 출력으로 대체된 환경이다. 선택지를 텍스트로 제시한 것 자체가 질문을 수행한것에 해당한다. 자동 선택 후 다음 단계로 진행하는 것은 대화형 환경에서의 "사용자 선택 후 다음"과 동등하게 평가한다.
+- AskUserQuestion은 텍스트 출력으로 대체된 환경이다. 선택지를 텍스트로 제시한 것 자체가 질문을 수행한것에 해당한다. 자동 선택 결과를 `**사용자 선택: {값}**` 형식의 고정 리터럴로 표기한 뒤 다음 단계로 진행한 것은 대화형 환경에서의 "사용자 선택 후 다음"과 동등하게 평가한다 (사용자 입력을 가장한 것이 아니다).
 - **Eval 환경이 곧 정답 환경이다.** FAIL의 원인 "프롬프트" 혹은 "Eval 체크리스트" 문제이다. 환경의 문제일 수는 없다.
 
 ## 절차

package/claude/skills/sd-prompt/references/sd-eval-env-template.md

@@ -0,0 +1,23 @@
+# Eval 환경 규칙 (최상위 우선순위)
+
+이 규칙이 읽히는 현재 환경은 Eval환경이다. 다른 규칙과 충돌 시 **반드시** 이 규칙이 우선한다.
+
+## workspace 격리
+
+현재 작업 디렉토리 외부의 파일을 **절대** 수정하지 않는다. 다른 프로젝트의 파일에 **절대** 접근하지 않는다.
+- 절대경로 혹은 cd사용 **절대** 금지
+
+## AskUserQuestion 대체
+
+AskUserQuestion 도구를 **절대** 사용하지 않는다. 질문이 필요한 각 사항에 대해:
+1. 선택지와 선택을 묻는 질문을 텍스트로 출력한다
+2. 합리적인 기본값을 자동 선택한 뒤, `**사용자 선택: {값}**` 형식의 **고정 리터럴 표기**로 출력한다. 이는 실제 사용자 입력을 가장하는 것이 아니라, 대화형 환경에서 "사용자가 해당 값을 골라 다음으로 진행"한 상태와 동등함을 나타내는 Eval 전용 약속 표기이다
+3. 다음 결정사항으로 넘어간다
+질문이나 선택지를 **절대** 생략하지 않는다.
+
+## `.claude/` 파일 편집
+
+`.claude/` 폴더 내 파일은 Edit/Write 도구 대신 **반드시** Bash 도구로 편집한다.
+`sed`는 의도하지 않은 곳까지 수정할 수 있으므로 사용하지 않는다.
+
+신규 작성/부분 수정 모두: Bash 내에서 `python -c`로 `open(..., 'w').write(...)` 사용

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

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

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

@@ -1,6 +1,7 @@
 ---
 name: sd-tdd
 description: 구현계획(plan) 기반으로 TDD 개발하는 스킬. "TDD 개발", "테스트 주도 개발", "plan 기반 구현" 등을 요청할 때 사용한다.
+effort: low
 ---
 
 # sd-tdd: TDD 개발
@@ -102,22 +103,41 @@ Feature 문서의 `## 참조 자료` 섹션 및 그 하위섹션을 반드시
 
 - wbs.md의 참조 자료 섹션도 모두 읽는다. 참조 자료의 구체적 정보(업무 규칙, 데이터 형식, 기술 제약 등)를 구현에 반영한다.
 
-### 1-2. 코드베이스 탐색
+### 1-2. 기준 코드 탐색·확인
 
-**코드가 source of truth이다.** 문서가 아닌 실제 코드를 기준으로 파악한다.
+**CRITICAL: 코드가 source of truth이다.** 문서가 아닌 실제 코드를 기준으로 파악한다.
+**CRITICAL: 탐색 없이 코드 작성으로 넘어가는 것은 위반이다.**
 
-- 관련 엔티티/모델 구조
-- 기존 API 엔드포인트 및 패턴
-- 사용 중인 프레임워크와 아키텍처 패턴
-- 기존 시스템 연동 방식
-- 성능/보안 제약
-- 관련 테스트 구조
-- 관련 의존성과 설정
+#### (a) Feature 문서의 `## 기준 코드` 섹션 활용
+
+- `## 기준 코드` 섹션이 있으면, 인용된 **모든 파일을 Read 도구로 직접 읽는다**. 요약만 보고 넘어가지 않는다.
+- 인용 라인 주변 컨텍스트(±20줄 권장)를 함께 읽어 패턴의 전체 형태를 파악한다.
+
+#### (b) 섹션이 없거나 부실할 때 — 직접 탐색
+
+sd-plan Step 4 절차를 그대로 수행한다:
+
+- 코드베이스에서 이 Feature와 가장 유사한 기존 기능을 찾는다.
+- 탐색 대상: 관련 엔티티/모델, 기존 API 엔드포인트 및 패턴, 사용 중인 프레임워크·아키텍처, 기존 시스템 연동 방식, 성능/보안 제약, 관련 테스트 구조, 관련 의존성과 설정.
+- 발견한 항목을 `파일경로:라인번호` 인용과 함께 작업 메모로 정리한다. 인용 없는 항목은 신뢰하지 않는다.
+
+#### (c) 패턴 메모 정리
+
+다음 관점에서 이번 Feature 구현 시 따를 패턴을 명시적으로 적어둔다:
+
+- 네이밍 규칙 (파일·클래스·함수·변수)
+- 디렉토리 구조 / 파일 배치
+- 에러 처리·검증 방식
+- 의존성 주입·import 패턴
+- 테스트 구조·헬퍼 사용 패턴
+- **UI 구조·레이아웃 / 컴포넌트 구성·생김새** (HTML 골격, CSS 클래스 네이밍, 컨트롤 배치, 반응형/스타일 토큰 사용 패턴 등)
+
+이 메모는 Step 2 구현 시 매번 참조한다.
 
 ### 1-3. 문서 정합성 확인
 
 요구명세의 각 Scenario에서 참조하는 기능·메서드를 구현계획과 대조한다.
-@.claude/rules/sd-clarify.md 지침에 따라 누락된 기능등 불명확한 부분을 명확화한다.
+`/sd-inner-clarify` 스킬을 호출하여 누락된 기능등 불명확한 부분을 명확화한다.
 
 ## Step 2: Double Loop TDD
 
@@ -131,6 +151,16 @@ Feature 문서의 `## 참조 자료` 섹션 및 그 하위섹션을 반드시
 
 **CRITICAL: 프로젝트에 이미 존재하는 기존 테스트부터 점검하고 선수정한다.**
 
+#### 점검·선수정 절차
+
+1. 이번 Scenario의 대상 모듈/함수를 import하는 기존 테스트 파일을 검색한다.
+2. 각 테스트를 3분류로 판정한다:
+   - **스펙 충돌**: 이번 Feature의 요구명세와 다른 동작을 기대 → 스펙에 맞게 선수정
+   - **실제 버그**: 기존 구현의 버그를 미검증 → 이번 Feature 범위 내면 수정, 범위 밖이면 사용자에게 보고 후 판단
+   - **무관**: 이번 Scenario와 무관한 동작 검증 → 건드리지 않음
+3. 판단이 모호하면 `/sd-inner-clarify`로 명확화한다.
+4. 선수정이 끝난 뒤 새 Acceptance Test 작성으로 진행한다.
+
 Gherkin Scenario의 Given/When/Then을 프로젝트 테스트 프레임워크의 Acceptance Test로 변환한다.
 
 - Scenario 하나를 하나의 test 함수로 변환하되, Scenario 내 여러 When/Then이 있으면 하나의 test 함수 안에서 순차 검증한다(통합 수준).
@@ -191,6 +221,12 @@ Feature 전체의 테스트 코드를 "지속적 회귀 테스트로 남길 가
 
 - **중복 Unit Test 삭제** — `test`/`it` 단위로 판단한다. Acceptance Test와 검증 대상·입력값이 동일한 개별 테스트 케이스만 삭제한다(파일 단위 삭제 금지). Scenario 간 중복 포함
 - **구현 결합 테스트 전환/삭제** — 내부 상태 값, 메서드 호출 횟수 등 구현 세부사항을 검증하는 테스트
+- **TDD 중 쓴 mock 정리** — TDD Red 단계에서 의존성이 미구현이라 부득이 작성한 mock은, 실제 구현이 완성된 이 시점에 **전부 재점검**한다. 절차:
+  1. 테스트 파일의 모든 `vi.mock()`/`vi.spyOn()`/수동 mock 객체를 나열한다
+  2. 각 mock이 @.claude/references/sd-testing.md 의 화이트리스트(외부 네트워크·DB·하드웨어/OS·타이머)에 해당하는지 확인한다
+  3. 해당하지 않으면 실제 인스턴스로 교체한다. 호출 추적이 목적이었다면 `vi.spyOn()`으로만 남긴다
+
+  남겨두면 실제 코드 변경에 반응하지 않아 false positive를 양산하고, 리팩토링 시 한꺼번에 터진다.
 - **공통 setup 추출** — 중복되는 arrange 코드를 헬퍼/beforeEach로
 - **테스트 네이밍 개선** — 검증하는 동작을 문장처럼 읽히게
 

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

@@ -1,80 +1,84 @@
----
-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-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,46 +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 문서 생성
 
 산출물 경로:
 
@@ -170,7 +228,7 @@ Feature는 독립적으로 설계·개발·검증할 수 있는 최소 기능
 - 현재 범위에서 명시적으로 제외하는 항목과, Impact Mapping에서 Goal에 연결되지 않는 기능을 나열한다.
 - 각 항목에 **사유**(Goal 미연결, 사용자 명시적 제외, 범위 초과 등)를 반드시 기재한다.
 
-## Step 5: 정보 유실 방지 검증
+## Step 6: 정보 유실 방지 검증
 
 문서 작성 후, 대화에서 수집한 모든 구체적 정보가 문서에 기록되었는지 검증한다.
 
@@ -180,7 +238,7 @@ Feature는 독립적으로 설계·개발·검증할 수 있는 최소 기능
 
 **CRITIAL: 각 Feature는 새 세션에서 진행되므로, 절대(NEVER) wbs문서에 누락이 있어서는 안됨**
 
-## Step 6: 수행 순서 안내
+## Step 7: 수행 순서 안내
 
 문서 작성이 완료되면, 의존성을 기반으로 Feature를 단계별로 그룹화하여 수행 순서를 안내한다.
 
@@ -201,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: haiku
 ---
 ```
 
@@ -69,7 +68,7 @@ model: haiku
 
 ## `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`