@simplysm/sd-claude 14.0.55 → 14.0.57

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

@@ -40,41 +40,52 @@ Step 1~5는 장기 프로세스이다. 스킬 시작 시점에 각 Step을 `Task
 
 ### Eval 유형
 
-| Eval 유형         | 설명                                      | 판정 방식                 |
-| ----------------- | ----------------------------------------- | ------------------------- |
-| **행동 Eval**     | 이 입력에서 출력이 충족해야 할 체크리스트 | 객관적 항목 + LLM 판단    |
-| **안티패턴 Eval** | 출력에 나타나면 안 되는 것들              | 행동/결과 확인 + LLM 판단 |
+| Eval 유형         | 설명                                                    | 판정 방식                 |
+| ----------------- | ------------------------------------------------------- | ------------------------- |
+| **행동 Eval**     | 특정 입력·환경에서 대상 프롬프트가 지켜야 하는 행동 계약 | Rubric 기반 LLM 판단      |
+| **안티패턴 Eval** | 대상 프롬프트가 만들면 안 되는 실패 모드                 | 행동/결과 확인 + LLM 판단 |
 
 ### 체크리스트 작성 원칙
 
-Judge의 정확도는 체크리스트의 품질에 달려있다. 다음 원칙을 따른다:
+Judge의 정확도는 Eval이 대상 프롬프트의 실제 성공 조건을 얼마나 잘 모델링하는지에 달려있다. 다음 원칙을 따른다:
 
-- **CRITICAL**: 체크리스트의 모든 항목은 사용자의 명시적 요청 및 답변에서 도출되어야 한다.
-- 객관적 기준으로 작성한다.
+- **CRITICAL**: 체크리스트의 모든 항목은 사용자 요청, 사용자 답변, 대상 프롬프트, 적용 규칙·참조 문서에서 도출되어야 한다.
+- 체크리스트는 파일·문자열 존재 여부보다 먼저 대상 프롬프트의 행동 계약을 평가한다.
+- 객관적 기준과 Rubric을 함께 작성한다.
 - 하나의 항목은 하나만 평가한다.
-- Judge를 통해 도출할 수 있는 내용만 작성한다.
+- Judge가 관찰 가능 소스에서 PASS/FAIL을 판정할 수 있는 내용만 작성한다.
 - **조건부 행동을 체크리스트에 넣지 않는다** — 입력·상태에 따라 발생할 수도, 안 할 수도 있는 행동은 체크 항목으로 부적합하다. 해당 입력에서 **반드시 발생하는 행동**만 넣는다.
+- 파일 존재, 섹션 존재, 특정 문자열 포함/미포함은 보조 assertion으로만 사용한다. 이것만으로 행동 Eval을 구성하지 않는다.
+- `run-output.json`을 체크리스트의 평가 대상명으로 직접 쓰지 않는다. `run-output.json`은 Judge가 행동을 판정하기 위해 참고하는 실행 로그일 뿐이다.
 
 #### Judge 관찰 가능 소스
 
-Judge는 아래 **두 가지만** 볼 수 있다. 체크리스트의 모든 항목은 이 소스에서 PASS/FAIL을 판정할 수 있어야 한다.
+Judge는 아래 **두 가지만** 볼 수 있다. 체크리스트의 모든 항목은 이 소스에서 PASS/FAIL을 판정할 수 있어야 하지만, 항목 문구는 사용자 관점의 행동·결과를 기준으로 작성한다.
 
 | 소스               | 설명                                               | 판정 가능 예시                                          |
 | ------------------ | -------------------------------------------------- | ------------------------------------------------------- |
 | **workspace 파일** | 스킬 실행 후 workspace에 생성·수정된 파일          | 파일 존재 여부, 파일 내 특정 문자열·구조·섹션 포함 여부 |
-| **텍스트 출력**    | `run-output.json`에 기록된 assistant의 텍스트 출력 | 출력에 특정 문구 포함/미포함 여부, 출력 구조            |
+| **실행 로그**      | `run-output.json`에 기록된 `claude -p --output-format json --verbose` 결과와 stderr | 사용자에게 제시한 질문·선택지·보고·최종 응답의 행동 흐름, 실행 오류 |
 
 **Judge가 볼 수 없는 것:** 도구 호출 여부/순서, 내부 추론, 파일을 "읽었는지" 여부. 이런 것은 체크 항목으로 넣지 않는다.
+**Judge가 봐야 하는 것:** 입력 대비 결과의 의미적 정확성, 금지된 행동의 부재, 필요한 질문/중단/수정/생성의 수행 여부, 산출물의 업무 규칙 준수 여부.
 
 #### 자가검증
 
-각 체크 항목을 작성한 후, "Judge가 workspace 파일 또는 텍스트 출력만 보고 이 항목의 PASS/FAIL을 판정할 수 있는가?"를 자문한다. "아니오"이면 재작성하거나 삭제한다.
+각 체크 항목을 작성한 후 아래 질문을 모두 통과해야 한다.
+
+- 이 항목은 대상 프롬프트의 성공 행동이나 실패 모드를 평가하는가?
+- Judge가 workspace 파일 또는 실행 로그를 근거로 PASS/FAIL을 판정할 수 있는가?
+- 파일명, 섹션명, 문자열 검색 같은 표면 검사가 아니라 의미적 행동 계약을 평가하는가?
+- 단순 표면 검사가 필요한 경우, 행동 계약을 보조하는 assertion으로만 쓰였는가?
+
+"아니오"가 하나라도 있으면 재작성하거나 삭제한다.
 
 ### Eval 파일 형식
 
 #### 입력 작성 원칙
 
-- **스킬:** 반드시(MUST) 실제 호출 방식인 `/{skill-name}`(슬래시 커맨드)을 입력으로 사용한다.
+- **스킬:** 반드시(MUST) 실제 호출 방식인 `/{skill-name}`(슬래시 커맨드)을 입력으로 사용한다. 예: `/sd-prompt .claude/skills/foo/SKILL.md`
 - **프롬프트:** 프롬프트가 적용되어야 하는 상황의 자연어 발화를 입력으로 사용한다.
 
 ```markdown
@@ -84,22 +95,35 @@ Judge는 아래 **두 가지만** 볼 수 있다. 체크리스트의 모든 항
 
 ### 시나리오 1: {이름}
 
-- 입력: "/{skill-name} (스킬입력)" (스킬)
-- 체크리스트:
-  - [ ] {객관적 판정 기준 1}
-  - [ ] {객관적 판정 기준 2}
+- 입력: "/sd-prompt .claude/skills/foo/SKILL.md 개선" (스킬)
+- 성공 행동:
+  - [ ] {대상 프롬프트가 이 입력에서 반드시 수행해야 하는 의미적 행동 1}
+  - [ ] {대상 프롬프트가 이 입력에서 반드시 수행해야 하는 의미적 행동 2}
+- 보조 assertion:
+  - [ ] {성공 행동을 뒷받침하는 파일/구조/문자열 검증 1}
+- Judge rubric:
+  - PASS: {성공으로 볼 구체 조건}
+  - FAIL: {실패로 볼 구체 조건}
 
 ### 시나리오 2: {이름}
 
 - 입력: "{자연어 발화}" (프롬프트)
-- 체크리스트:
-  - [ ] {객관적 판정 기준 1}
-  - [ ] {객관적 판정 기준 2}
+- 성공 행동:
+  - [ ] {대상 프롬프트가 이 입력에서 반드시 수행해야 하는 의미적 행동 1}
+  - [ ] {대상 프롬프트가 이 입력에서 반드시 수행해야 하는 의미적 행동 2}
+- 보조 assertion:
+  - [ ] {성공 행동을 뒷받침하는 파일/구조/문자열 검증 1}
+- Judge rubric:
+  - PASS: {성공으로 볼 구체 조건}
+  - FAIL: {실패로 볼 구체 조건}
 
 ## 안티패턴 Eval
 
-- [ ] {하면 안 되는 행동 1}
-- [ ] {하면 안 되는 행동 2}
+모든 시나리오에 공통으로 적용되는 금지 기준만 작성한다.
+특정 시나리오에서만 금지되는 행동은 해당 시나리오의 체크리스트에 작성한다.
+
+- [ ] {공통으로 하면 안 되는 실패 행동 1}
+- [ ] {공통으로 하면 안 되는 실패 행동 2}
 ```
 
 ## Step 3: 프롬프트 작성
@@ -112,12 +136,17 @@ Judge는 아래 **두 가지만** 볼 수 있다. 체크리스트의 모든 항
 
 프론트매터가 필요하지 않으며, 자유양식으로 작성
 
+### 스킬 작성 규칙
+
+스킬을 작성하거나 개선할 때는 간결성보다 정확성을 최우선 가치로 둔다.
+부정확한 결과를 낼 가능성이 있다면, 과하더라도 질문, 근거 확인, 검증, 중단을 선택하도록 스킬을 작성한다.
+
 ### 품질 원칙
 
 - **금지에는 대안을 함께 제시한다** — "`Buffer` 사용 금지"만으로는 불충분. "`Buffer` 금지 — `Uint8Array`를 사용한다"로 작성한다
 - **강한 규칙에 키워드를 구분한다** — `반드시(MUST)`, `절대(NEVER)`, `항상(ALWAYS)`, `CRITICAL`, `IMPORTANT`. IMPORTANT/CRITICAL은 진짜 중요한 규칙에만 사용한다.
 - **모호한 표현을 제거한다** — "적절하게", "필요시", "경우에 따라" 등은 LLM이 추측하게 만든다. 구체적인 조건과 행동으로 바꾸거나 AskUserQuestion을 활용한다.
-- **간결하게 유지한다** — SKILL.md는 200줄 이하를 목표로 한다. 200줄이 넘을 경우 "Progressive Disclosure" 원칙에 따라 파일을 분리한다.
+- **정확성을 유지한 범위에서 간결하게 유지한다** — 핵심 규칙과 전체 Step 흐름은 SKILL.md에 남긴다. 상세 절차·템플릿·긴 예시는 명시적 참조 경로를 두고 "Progressive Disclosure" 원칙에 따라 분리한다.
 
 ## Step 4: Eval 실행 & 판정
 
@@ -133,7 +162,9 @@ Judge 보고서의 개선 제안에 대해:
 1. @.claude/rules/sd-options.md 를 읽고 사용자에게 질문한다.
    - FAIL 판정이유 및 해당하는 부분의 실제 출력을 포함해야한다.
 2. 승인된 제안에 따라 작성 원칙에 맞추어 수정한다.
-3. 수정 후 workspace를 재구성하여 Eval을 재실행한다. (Eval만 수정된 경우, eval을 복사하고, Judge만 재수행)
+3. 수정 범위에 따라 분기하여 재실행한다.
+   - **프롬프트 본문이 수정된 경우:** workspace를 재구성하고 시나리오부터 Eval을 다시 실행한다.
+   - **Eval만 수정된 경우:** 기존 `run-output`을 그대로 두고, 수정된 Eval을 복사하여 Judge만 다시 실행한다.
 
 ## Step 5: 프롬프트 리팩터링 (Refactor)
 
@@ -143,6 +174,8 @@ Judge 보고서의 개선 제안에 대해:
 
 각 Smell은 아래 **탐지 규칙**에 해당할 때만 리포트한다. **예외 조건**에 해당하면 Smell로 치지 않는다. 리포트 시 **원문 라인 인용**(`파일경로:라인`)을 반드시 포함한다 — 근거를 댈 수 없으면 리포트 금지.
 
+대상 프롬프트가 다른 스킬을 호출하면, 호출 대상 스킬의 `SKILL.md`도 함께 읽고 책임 경계를 비교한다. 호출자 스킬에는 호출 조건·전달 입력·결과 사용 방식만 남기고, 호출 대상 스킬의 내부 절차를 복제하지 않는다.
+
 #### 중복 지시
 - 탐지: 동일 지시(동사+목적어 수준)가 2곳 이상에 등장
 - 예외: 양쪽 모두 `CRITICAL`/`MUST`/`절대`/`반드시` 등 강조 키워드가 붙어 있고, 서로 다른 Step·섹션 경계에서 **의도적 강조**로 읽히는 경우
@@ -173,7 +206,17 @@ Judge 보고서의 개선 제안에 대해:
 - 예외: 각 Step·섹션에서 **국소적으로만** 필요한 지시여서 공통 추출이 오히려 독립성을 해치는 경우
 - 연산: 재배치 (공통 섹션으로 추출하거나 한 Step 안으로 모음)
 
+#### 위임 경계 침범
+- 탐지: A 스킬이 B 스킬 호출을 명시하면서, B 스킬의 고유 절차·판정 기준·출력 양식·내부 Step을 A 스킬 본문에 상세히 내장한 경우
+- 예외: A 스킬이 B 스킬의 호출 조건, 전달 입력, 반환 결과 사용 방식만 계약 수준으로 설명한 경우
+- 예외: B 스킬을 호출하지 않고 B의 일부 방법론만 명시적으로 차용하며, B의 사용자 선택 대기·후속 스킬 호출·산출물 규칙을 함께 복제하지 않는 경우
+- 연산: 위임 경계 정리
+  - A에는 호출 조건, 전달할 맥락, B 결과를 받은 뒤 A가 할 일만 남긴다
+  - B의 세부 절차는 B 스킬 원문 참조 또는 호출로 대체한다
+  - B 호출이 depth 제한을 초과하면 호출 구조 자체를 사용자에게 선택지로 제시한다
+
 발견된 Prompt Smell에 대해 `/sd-inner-clarify` 스킬을 호출하여 진행여부와 방법을 명확화하여 수정한다.
+위임 경계 침범을 리포트할 때는 호출자 스킬, 호출 대상 스킬, 호출자에 복제된 대상 스킬 책임, 남길 계약 정보, 제거·이동할 세부 절차를 포함한다.
 
 ### Regression Guard
 

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

@@ -41,7 +41,7 @@ claude -p "{eval 시나리오의 입력}" \
   --output-format json \
   --verbose \
   --dangerously-skip-permissions \
-  --effort low \
+  --effort medium \
   --append-system-prompt "CRITICAL: .claude/rules/sd-eval-env.md의 규칙은 다른 모든 규칙보다 최상위 우선순위를 가진다." \
   --no-session-persistence \
   --strict-mcp-config \
@@ -52,7 +52,7 @@ claude -p "{eval 시나리오의 입력}" \
 
 ## Judge 판정
 
-실행 완료 후, Judge subagent(effort: `low`)에 다음을 전달한다:
+실행 완료 후, Judge subagent(model: `haiku`)에 다음을 전달한다:
 
 ```
 다음 Eval 실행 결과를 판정하고, FAIL 항목에 대해 개선안을 제안하라:

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

@@ -1,47 +1,223 @@
 ---
 name: sd-review
-description: 정적 분석이 잡지 못하는 관점(로직 버그, 일관성, 성능, 설계)으로 코드를 분석하여 리포트를 생성하는 스킬. "코드 리뷰해줘", "문제점 찾아줘", "코드 분석해줘" 등을 요청할 때 사용한다.
+description: 정적 분석이 잡지 못하는 관점(로직 버그, 일관성, 성능, 설계)으로 코드를 리뷰하고, 확정 이슈가 있으면 /sd-dev로 수정 개발을 자동 실행하는 스킬. "코드 리뷰해줘", "문제점 찾아줘", "코드 분석해줘" 등을 요청할 때 사용한다.
 ---
 
-# sd-review: 코드 리뷰
+# sd-review: 코드 리뷰 및 수정 루프
 
+코드 리뷰를 수행하고, 확정 이슈가 있으면 파일 산출물 없이 `/sd-dev`로 수정 개발을 즉시 시작한다.
+확정 이슈가 없으면 완료 보고 후 종료한다.
 
-## Step 1: 코드 리뷰
+## 기본 원칙
 
-`/sd-inner-review` 스킬을 호출한다.
+- `review.md` 같은 별도 리뷰 파일을 생성하지 않는다.
+- 확정 이슈 목록은 대화 맥락으로 `/sd-dev`에 전달한다.
+- `/sd-dev`의 마지막 단계에서 호출된 경우, 기존 `/sd-dev` 실행은 `/sd-review` 호출 시점에 종료된 것으로 본다.
+- 이슈 여부가 명확하지 않으면 `/sd-inner-clarify`로 명확화하고, 해소되지 않은 항목은 확정 이슈로 넘기지 않는다.
 
-## Step 2: 문서 기록
+## Step 1: 대상 결정
 
-분석 결과를 문서에 기록한다.
+인자로 경로가 지정되면 해당 경로를 리뷰한다.
+인자가 없으면 대화 맥락에서 사용자가 지정했거나 직전 작업으로 특정 가능한 범위를 우선 리뷰한다.
+인자도 없고 대화 맥락에서 특정 가능한 범위도 없으면 프로젝트 전체 큰그림 리뷰를 수행한다.
 
-### 출력 경로
+- `/sd-review src/services` → `src/services` 하위만
+- `/sd-review` → 대화 맥락상 특정 가능한 범위, 없으면 프로젝트 전체 큰그림 리뷰
 
-산출물 경로: `.tasks/{timestamp}_review-{topic}/review.md`
+**CRITICAL: git 명령 사용 금지.** `git diff`, `git status`, `git log`, `git show` 등 git 명령으로 대상 파일을 결정하지 않는다. 리뷰 대상은 오직 인자로 지정된 경로 또는 대화 맥락에서 사용자가 지정한 범위이다. "최근 변경 파일", "커밋된 파일" 등의 개념으로 대상을 좁히지 않는다.
 
-- `{yyMMddHHmmss}` — Bash `date +%y%m%d%H%M%S`로 취득. LLM이 생성한 타임스탬프 금지
-- `{topic}` — 에러/이슈의 핵심을 나타내는 간결한 키워드 (예: `null-ref`, `race-condition`, `async-init`)
+## Step 2: 컨텍스트 수집
 
-### review.md 형식
+프로젝트의 기술 스택, 컨벤션등의 규칙을 파악한다.
 
-```markdown
-# 코드 리뷰: {topic}
+### 소스 수집
 
-## {id} [{severity}] {한 줄 요약}
+대상 경로 유형에 따라 소스를 수집한다.
 
-- **위치:** {파일경로}:{라인번호}
+- **패키지 디렉토리** (경로 내 `src/` 존재): `merge-source.py`로 병합하여 `.tmp/review/{yyMMddHHmmss}.txt` 파일로 저장한 뒤 읽는다.
+  - `{yyMMddHHmmss}`는 Bash `date +%y%m%d%H%M%S`로 취득한다. LLM이 생성한 타임스탬프 금지.
+  - 실행 시 현재 셸에서 사용 가능한 Python 실행기(`python`, `python3`, `py`)로 `.claude/skills/sd-review/merge-source.py <출력파일> --dir <디렉토리경로>`를 호출한다.
+- **개별 파일 목록**:
+  - **5개 미만**: 각 파일을 개별 Read로 읽는다.
+  - **5개 이상**: `merge-source.py`로 병합하여 `.tmp/review/{yyMMddHHmmss}.txt` 파일로 저장한 뒤 읽는다.
+    - `.claude/skills/sd-review/merge-source.py <출력파일> --files <파일1> <파일2> ...`
+- **프로젝트 전체 큰그림 리뷰**:
+  - 모든 파일을 정밀 병합해 읽지 않는다.
+  - 우선 `packages/*/CLAUDE.md`, `packages/*/package.json`, 루트 핵심 설정(`package.json`, `pnpm-workspace.yaml`, `tsconfig.json`, `eslint.config.ts`, `sd.config.ts`)을 읽어 패키지 경계와 의존 방향을 파악한다.
+  - 필요하면 `rg --files packages tests`로 파일 목록을 확인하고, 의심되는 패키지·테스트·공개 진입점만 좁혀 읽는다.
+  - 패키지 경계, 의존 방향, 공개 계약, 반복 패턴, 테스트 공백, 루트 설정 충돌, 유지보수 위험을 우선 확인한다.
 
-{왜 문제인지 — 의도와 실제 동작의 차이를 자연어로 서술}
+## Step 3: 분석
 
-**개선 방향:** {개선 방향}
+대상 파일을 읽고 관점별 체크리스트로 이슈를 탐지한다.
 
----
-```
+### 분석 절차
+
+각 함수/모듈에 대해:
+
+1. **의도 파악** — 함수명, 변수명, 주석에서 의도를 기술
+2. **수식·계산 검증** — 구체적 숫자를 대입하여 중간 결과 추적
+3. **부작용 열거** — 의도상 있어야 하지만 코드에 없는 부작용 탐지
+4. **에지케이스 시뮬레이션** — 빈 값, 경계값, 이례적 입력 추적
+
+### 체크리스트
+
+아래 관점별 체크리스트로 이슈를 식별한다.
+
+#### 요구사항 대비 (SPEC) — 요구사항 원천이 제공된 경우에만
+
+요구사항 원천이 있으면 이를 기준으로 코드와 대조한다. 원천은 형식을 가리지 않는다:
+
+검증 항목:
+
+- 요구사항 미구현: 원천에 명시된 동작·규칙이 실제 코드에 반영되지 않음
+- 요구사항 위반: 원천의 규칙·결정과 다르게 구현
+- 경계 초과(스코프 크립): 원천에 "제외"/"다루지 않음"으로 명시된 항목이 구현됨
+- 진행 상태 불일치(체크박스·상태표가 있는 경우): 문서상 완료인데 산출물 없음 또는 그 반대
+
+근거 태그: `[근거: 사용자 요청 "..."]`, `[근거: 이메일 {제목}]`, `[근거: wbs Feature X.Y 경계]`, `[근거: Feature X.Y Scenario "..."]`, `[근거: 설계 결정 D2]` 등 출처 형식에 맞춰 명시
+
+#### 로직 버그 (LOGIC)
+
+실행은 되지만 결과가 틀린 이슈:
+
+- 의도-구현 불일치: 함수명/주석이 암시하는 동작과 실제 구현이 다른 경우 (예: 합산해야 하는데 덮어쓰기)
+- 비즈니스 로직 오류: 잘못된 계산 순서, 잘못된 조건, 잘못된 수식 (예: 할인 후 세금 vs 세금 후 할인)
+- 누락된 단계: 프로세스에 반드시 있어야 하는 단계가 빠짐. 함수가 하는 일의 부작용(side effect)을 나열하고, 빠진 부작용이 없는지 확인한다 (예: 주문 생성 → DB 삽입은 있지만 재고 차감/결제 처리가 없음)
+- 상태 전이 오류: 허용되지 않아야 하는 상태 변경이 가능 (예: 배송 완료된 주문 취소 가능)
+- 데이터 정합성: 한쪽은 업데이트하고 다른 쪽은 안 하는 부분 업데이트
+- 에지케이스 논리 오류: 도메인 수준의 경계값 처리 누락 (예: 생일 지남 여부를 고려하지 않는 나이 계산)
+
+#### 일관성/통일성 (CONSIST)
+
+같은 코드베이스 내에서 같은 개념이 다른 방식으로 표현된 이슈:
+
+- 네이밍 불일치: 같은 개념에 대해 파일/모듈마다 다른 이름 사용 (예: `userId` vs `userIdx` vs `uid`)
+- 파라미터 순서 불일치: 유사한 함수들 간 파라미터 순서가 다름 (예: `update(id, name)` vs `update(name, id)`)
+- 반환 구조 불일치: 같은 종류의 함수/API인데 반환 형태가 다름 (예: 어떤 건 raw 객체, 어떤 건 `{ items, total }` 래핑)
+- 패턴 불일치: 같은 역할의 코드가 파일마다 다른 패턴으로 구현됨 (예: 에러 처리 방식, 초기화 방식이 제각각)
+- 디렉토리/파일 구조 불일치: 같은 성격의 모듈인데 파일 배치나 구조가 다름
+
+#### 성능 (PERF)
+
+- O(n^2) 이상의 중첩 루프 (같은 컬렉션을 반복 순회)
+- N+1 쿼리 패턴 (루프 내 DB/API 호출)
+- 불필요한 직렬 await (Promise.all로 병렬화 가능한 독립 호출)
+
+#### 설계 (DESIGN)
+
+- 함수명/변수명과 실제 동작의 괴리 (의미론적 네이밍 문제)
+- 한 함수가 너무 많은 책임 (단일 책임 원칙 위반)
+- 호출 그래프 중복 실행: 명시적 호출과 간접 호출(이벤트 구독 등)을 통해 동일 로직이 여러 경로로 중복 실행되는 경우
+- 에러 발생 가능한 호출(DB, 네트워크, JSON.parse 등)에 에러 처리 없음
+- 에러 삼킴 (빈 catch 블록)
+- 리소스 미해제 / 메모리 릭 패턴:
+  - 해제되지 않는 구독: Observable subscribe 후 unsubscribe/destroy 누락, addEventListener 후 removeEventListener 누락
+  - 해제되지 않는 타이머: setInterval/setTimeout을 등록하고 clear하지 않음
+  - 무한 축적 컬렉션: Map/Set/Array에 항목을 추가만 하고 제거·초기화하지 않아 무한히 커지는 패턴
+  - 스트림/커넥션 미닫힘: 파일 스트림, DB 커넥션 등 열고 닫지 않음
+- 경계 타입 혼용: 한 타입이 내부 처리용과 외부 전달용(Worker, IPC, API 응답, 레이어 간 반환 등) 역할을 겸하여, 소비자가 쓰지 않는 필드가 노출되거나 역할이 모호해짐
+- dead code: 선언·정의되어 있지만 실제로 사용되지 않는 코드. 사용되지 않는 파라미터/옵션 프로퍼티, 도달하지 않는 분기, 할당만 하고 이후 로직에 영향을 주지 않는 값 등 — 린터가 잡지 못하지만 존재함으로써 유지보수 부담을 높이거나 호출자에게 잘못된 기대를 심어줌
+
+### Severity 기준
+
+| Severity     | 기준                                   | 예시                               |
+| ------------ | -------------------------------------- | ---------------------------------- |
+| **Critical** | 데이터 손실/손상, 잘못된 비즈니스 결과 | 합산 대신 덮어쓰기, 상태 전이 오류 |
+| **Medium**   | 특정 조건에서 잘못된 동작, 누락된 처리 | 상태 체크 누락, 에러 처리 부재     |
+| **Low**      | 개선하면 좋지만 당장 오동작하지는 않음 | 성능 비효율, 설계 개선 제안        |
+
+## Step 4: 거짓양성 필터링
+
+Step 3에서 탐지된 이슈를 하나씩 순회하며, 해당 위치의 코드와 관련 컨텍스트(호출자, 프레임워크 패턴, 프로젝트 컨벤션 등)를 다시 읽고 실제로 문제가 맞는지 검증한다. 거짓양성으로 판단되면 사유와 함께 제외한다.
+
+### 거짓양성 판단 기준
+
+다음 중 하나에 해당하면 거짓양성으로 판단한다:
+
+- **프레임워크/라이브러리 의도된 패턴**: 프레임워크가 권장하거나 요구하는 방식으로 작성된 코드 (예: Angular의 lifecycle hook 호출 순서, RxJS의 구독 패턴)
+- **상위 레이어에서 이미 처리**: 이슈로 지적한 누락이 호출자·미들웨어·프레임워크 레벨에서 이미 처리되고 있는 경우
+- **의도적 설계 결정**: 코드베이스 내 동일 패턴이 일관되게 사용되어 의도적 선택임이 확인되는 경우
+- **실행 경로 도달 불가**: 실제 호출 흐름상 해당 조건에 도달할 수 없는 경우 (타입 시스템, 선행 검증 등으로 보장)
+- **외부 의존성 제약**: 외부 라이브러리/API의 동작 특성상 불가피한 코드이며, 대안이 없는 경우
+
+### 검증 절차
+
+각 이슈에 대해:
+
+1. 해당 코드의 **호출자(caller)** 를 추적하여 실제 사용 맥락 확인
+2. 코드베이스 내 **동일 패턴의 다른 사례**가 있는지 검색
+3. 위 판단 기준에 해당하는지 평가
+4. 거짓양성이면 사유를 기록하고 제외, 아니면 이슈 유지
+
+불확실한 경우, `.claude/rules/sd-options.md`를 읽고 그 지침에 따라 사용자에게 질문하여 명확화 한다.
+
+## Step 5: 남은 이슈 명확화
+
+Step 4를 통과한 이슈를 최종 이슈로 확정하기 전에 `/sd-inner-clarify`에 전달한다.
+명확성 분류, 근거 탐색, 재분류 보고, 사용자 질문 여부는 `/sd-inner-clarify`의 기준을 따른다.
+
+### 전달 내용
+
+각 이슈는 판단에 필요한 최소 맥락과 함께 전달한다:
+
+- 이슈 요약
+- 위치: 파일경로와 라인번호
+- 카테고리: SPEC / LOGIC / CONSIST / PERF / DESIGN
+- Severity 후보: Critical / Medium / Low
+- Step 4에서 확인한 검증 근거와 남은 불확실성
+
+`/sd-inner-clarify` 결과 사용자가 제외하기로 선택한 이슈는 Step 6 최종 이슈 목록에서 제거한다.
+이슈 여부가 해소되지 않은 항목이 남아 있으면 Step 6으로 진행하지 않는다.
+
+## Step 6: 이슈 정리
+
+Step 5에서 최종 대상으로 유지된 이슈들을 `/sd-dev` 전달 품질을 위해 정리한다.
+
+### 동일 근본 원인 통합
+
+서로 다른 위치에서 탐지되었지만 동일한 근본 원인을 공유하는 이슈들을 하나로 통합한다:
+
+- 같은 잘못된 가정/오해에서 파생된 여러 이슈 → 근본 원인 1건으로 병합, 개별 발현 위치는 하위 목록으로 기재
+- 같은 패턴이 여러 파일에 반복된 이슈 → 대표 사례 1건 + "동일 패턴 N건" 표기
+
+### 중복 제거
+
+- 동일 위치·동일 내용의 이슈가 다른 카테고리로 중복 탐지된 경우, 가장 적합한 카테고리 1건만 유지
+- 상위 이슈가 하위 이슈를 포함하는 경우(예: 설계 이슈가 해결되면 로직 이슈도 해소), 상위 이슈만 유지
+
+### Severity 재조정
+
+전체 이슈 목록이 확정된 시점에서 severity를 재평가한다:
+
+- 통합으로 영향 범위가 넓어진 이슈 → severity 상향 검토
+- 단독으로 보면 Medium이지만 다른 이슈와 결합 시 Critical이 되는 경우 → 상향
+- 초기 분석 시 과대평가된 이슈 → 하향
+
+### 우선순위 정렬
+
+최종 이슈 목록을 다음 기준으로 정렬한다:
+
+1. Severity (Critical → Medium → Low)
+2. 동일 severity 내에서는 영향 범위가 넓은 순
+3. 동일 영향 범위 내에서는 카테고리 순 (LOGIC → CONSIST → PERF → DESIGN)
+
+## Step 7: 완료 후 행동
+
+### 확정 이슈가 없는 경우
 
-- `{id}`: `{카테고리약자}-{순번}` (예: LOGIC-001, CONSIST-002)
-- `{severity}`: Critical | Medium | Low
-- 이슈 간 `---` 구분선으로 분리
+- `/sd-dev`에서 위임받은 최종 리뷰라면 `/sd-dev`의 완료 보고 양식으로 결과를 출력한다.
+- WBS 문서 경로가 있으면 완료 보고 출력 직전에 반드시 현재 `wbs.md`를 다시 읽고 Feature 체크박스(`[x]`/`[ ]`) 상태를 반영한다.
+- 단독 실행이라면 검토 범위와 함께 `확정 이슈 없음`을 대화에 출력한다.
+- `/sd-dev`를 호출하지 않고 종료한다.
 
-## Step 3: 완료 후 행동
+### 확정 이슈가 있는 경우
 
-1. 대화에 출력파일(`review.md`) 파일 경로를 표시한다.
-2. `/sd-dev` 스킬을 호출하여 수정 개발을 시작한다.
+1. `review.md` 등 파일 산출물을 만들지 않는다.
+2. 확정 이슈 목록을 대화에 요약한다.
+3. 아래 정보를 포함해 `/sd-dev` 스킬을 즉시 호출한다.
+   - 리뷰 대상 경로
+   - 요구사항 원천 또는 WBS/Feature 문서 경로
+   - 확정 이슈 목록: 요약, 위치, 카테고리, Severity, 검증 근거, 개선 방향
+   - 사용자 결정사항과 제외된 이슈가 있으면 그 사유
+4. `/sd-review` 실행은 `/sd-dev` 호출 시점에 종료한다.

package/claude/skills/sd-review/merge-source.py

@@ -0,0 +1,66 @@
+#!/usr/bin/env python3
+from __future__ import annotations
+
+import sys
+from pathlib import Path
+
+
+def collect_source_files(dir_path: Path) -> list[Path]:
+    files: list[Path] = []
+
+    src_dir = dir_path / "src"
+    if src_dir.is_dir():
+        files.extend(path for path in src_dir.rglob("*.ts") if path.is_file())
+
+    scss_dir = dir_path / "scss"
+    if scss_dir.is_dir():
+        files.extend(path for path in scss_dir.rglob("*.scss") if path.is_file())
+
+    return sorted(files, key=lambda path: path.as_posix())
+
+
+def write_merged_source(files: list[Path], output_path: Path) -> None:
+    output_path.parent.mkdir(parents=True, exist_ok=True)
+
+    with output_path.open("w", encoding="utf-8", newline="\n") as output:
+        for file_path in files:
+            output.write(f"=== {file_path.as_posix()} ===\n")
+            text = file_path.read_text(encoding="utf-8")
+            output.write(text)
+            if not text.endswith("\n"):
+                output.write("\n")
+            output.write("\n")
+
+
+def print_usage() -> None:
+    print(
+        "Usage: merge-source.py <output-file> --dir <dir-path> | --files <file1> <file2> ...",
+        file=sys.stderr,
+    )
+
+
+def main(argv: list[str]) -> int:
+    if len(argv) < 3:
+        print_usage()
+        return 1
+
+    output_path = Path(argv[1])
+    mode = argv[2]
+
+    if mode == "--dir":
+        if len(argv) != 4:
+            print("Error: --dir requires a directory path", file=sys.stderr)
+            return 1
+        files = collect_source_files(Path(argv[3]))
+    elif mode == "--files":
+        files = [Path(file_path) for file_path in argv[3:]]
+    else:
+        print("Error: specify --dir or --files", file=sys.stderr)
+        return 1
+
+    write_merged_source(files, output_path)
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main(sys.argv))

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

@@ -1,7 +1,7 @@
 ---
 name: sd-tdd
 description: 구현계획(plan) 기반으로 TDD 개발하는 스킬
-effort: low
+effort: medium
 ---
 
 # sd-tdd: TDD 개발
@@ -143,7 +143,7 @@ Unit Test는 내부 설계를 검증한다. Acceptance와 달리 아래가 허
 
 #### 절차
 
-1. **Unit Test 작성 (Red)** — Acceptance Test와 별개의 도구 호출(Write/Edit)로 작성한다
+1. **Unit Test 작성 (Red)** — Acceptance Test와 역할이 겹치지 않도록, 개별 메서드·경계값·에러 케이스를 별도 테스트로 작성한다
 2. **최소 구현 (Green)** — Unit Test를 통과시키는 최소한의 코드를 작성한다
 3. **Refactor**
   - 방금 작성한 코드 범위에서 중복 제거, 하드코딩 제거(Fake It → 실제 구현), 네이밍 개선, Extract Variable/Method.

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

@@ -35,11 +35,12 @@ USAGE
 FLOWS
   진입점                             개발 파이프라인
   sd-wbs    프로젝트 → Feature 분해 ─┐
-  sd-review 코드 리뷰 → 리포트 생성  ├→ sd-plan → sd-tdd
-  sd-debug  에러 → 근본 원인 분석    │  │        │
+  sd-review 코드 리뷰 → 수정 개발 루프 ├→ sd-plan → sd-tdd
   (없음)    바로 개발 시작          ─┘  └────────┘
                                         sd-dev (순차 실행)
 
+  sd-debug  버그/에러 → 원인 분석 보고 (분석 종착, 후속은 사용자 지시)
+
 SKILLS
   개발
     sd-dev              Feature 전체 개발 (wbs → plan → TDD → check → review)
@@ -49,9 +50,9 @@ SKILLS
 
   품질
     sd-check            typecheck / lint / test 실행 및 에러 수정
-    sd-review           로직 버그, 보안, 성능, 설계 이슈 리뷰
+    sd-review           로직 버그, 보안, 성능, 설계 이슈 리뷰 및 수정 개발 연결
     sd-refactor         구조·설계·아키텍처 리팩토링 분석 리포트
-    sd-debug            버그/에러 근본 원인 분석
+    sd-debug            버그/에러 근본 원인 분석 및 보고
 
   Git
     sd-commit           전체 변경사항 단일 커밋 생성
@@ -65,10 +66,6 @@ SKILLS
   도구
     sd-prompt           스킬/프롬프트 파일 생성·개선
     sd-outlook          Outlook 메일 검색/다운로드
-
-  기타
-    my-apk-decompile    APK 디컴파일 및 소스 분석
-    playwright-cli      브라우저 자동화 및 Playwright 테스트
 ````
 
 ## Step 3: 스킬 실행