@simplysm/sd-claude 14.0.47 → 14.0.48

package/claude/skills/sd-doc-extract/extract.py

@@ -44,6 +44,13 @@ def extract_recursive(file_path: Path, out_dir: Path):
             "context": img.get("context", ""),
         })
 
+    # Save pre-named slide images (PPTX screenshots)
+    saved_slides = []
+    for s in result.get("slide_images", []):
+        slide_path = out_dir / s["filename"]
+        slide_path.write_bytes(s["data"])
+        saved_slides.append({"filename": s["filename"], "size": len(s["data"])})
+
     # Save embedded/attached files and recurse
     prefix = "attachment" if result.get("metadata", {}).get("email_headers") else "embedded"
     saved_embedded = []
@@ -68,12 +75,13 @@ def extract_recursive(file_path: Path, out_dir: Path):
         saved_embedded.append(entry)
 
     # Generate {stem}.md index in parent of out_dir
-    _generate_index_md(out_dir, file_path, result, saved_images, saved_embedded)
+    _generate_index_md(out_dir, file_path, result, saved_images, saved_embedded, saved_slides)
 
 
 
 def _generate_index_md(out_dir: Path, file_path: Path, result: dict,
-                       saved_images: list, saved_embedded: list):
+                       saved_images: list, saved_embedded: list,
+                       saved_slides: list | None = None):
     """Generate {stem}.md in parent of out_dir, summarizing extraction results.
 
     Images and embedded files are placed inline via [IMG:N]/[EMB:N] placeholders
@@ -120,7 +128,8 @@ def _generate_index_md(out_dir: Path, file_path: Path, result: dict,
             referenced_imgs.add(idx)
             if 1 <= idx <= len(saved_images):
                 img = saved_images[idx - 1]
-                return f"![{img['filename']}]({rel_prefix}/{img['filename']})"
+                alt = img.get('context', '') or img['filename']
+                return f"![{alt}]({rel_prefix}/{img['filename']})"
             return m.group(0)
 
         def replace_emb(m):
@@ -136,8 +145,18 @@ def _generate_index_md(out_dir: Path, file_path: Path, result: dict,
                     return f"> embedded: [{name}]({rel_prefix}/{name})"
             return m.group(0)
 
+        slides_list = saved_slides or []
+
+        def replace_slide(m):
+            idx = int(m.group(1))
+            if 1 <= idx <= len(slides_list):
+                fname = slides_list[idx - 1]["filename"]
+                return f"![{fname}]({rel_prefix}/{fname})"
+            return m.group(0)
+
         text = re.sub(r'\[IMG:(\d+)\]', replace_img, text)
         text = re.sub(r'\[EMB:(\d+)\]', replace_emb, text)
+        text = re.sub(r'\[SLIDE:(\d+)\]', replace_slide, text)
 
         if len(text) > 10000:
             body_path = out_dir / "body.txt"

package/claude/skills/sd-inner-clarify/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: sd-inner-clarify
+description: (내부 전용) 명확성 분류·근거 탐색·재분류·명확화 질문 프로세스. sd-plan, sd-wbs, sd-tdd, sd-refactor, sd-prompt, sd-inner-debug 등에서 호출된다. 직접 호출하지 않는다.
+---
+
+# sd-inner-clarify: 명확화 프로세스
+
+정보의 명확성 판단 및 불명확한 정보를 명확화 하고자 할 때 적용한다.
+파악한 정보를 확실성 수준별로 분류하고, 불명확한 항목은 사용자에게 질문하여 해소한다.
+
+## Step 1: 명확성 분류 (1차)
+
+정보의 명확성을 다음 기준으로 분류한다.
+
+- **VERIFIED**: 사용자가 직접 말했거나 문서/코드에 명시된 것
+- **INFERRED**
+  - **High**: 타겟 코드베이스에서 동일 패턴을 확인했거나 공식 문서에 근거가 있는 추론
+  - **Medium**: 일반적 도메인 관행이나 유사 사례에 기반한 추론. 마이그레이션 원본, 이전 버전, 외부 프로젝트의 패턴은 "유사 사례"에 해당
+  - **Low**: 약한 유추나 제한적 근거에 기반한 추론
+- **ASSUMED**: 추측에 해당
+
+## Step 2: 근거 탐색 (질문 전 필수)
+
+**CRITICAL: Medium/Low/ASSUMED로 분류된 모든 항목은 사용자에게 질문하기 전에 반드시 근거를 탐색한다.**
+
+근거는 **현재 컨텍스트 안에 이미 존재할 가능성이 가장 높다**. 질문하기 전에 두 단계로 확인한다.
+
+### 2-1. 컨텍스트 회수 (먼저 시도)
+
+지금까지 누적된 맥락 전체에서 근거를 찾는다. 새 tool 호출 전에 수행한다.
+
+- **사용자 메시지** — 현재/이전 턴의 지시, 인용, 예시, 제약
+- **호출자에게서 받은 인자** — 이 스킬을 부른 상위 스킬(sd-plan/sd-wbs 등)이 전달한 정보
+- **이미 읽은 tool 결과** — 직전 Read/Grep/Glob/WebFetch 출력, 첨부된 문서 내용
+- **세션 내 이미 생성된 산출물** — spec, plan, 직전 단계 보고 등
+
+### 2-2. 타겟 탐색 (회수로 부족할 때)
+
+컨텍스트에 없으면 탐색한다. 항목의 성격에 맞는 소스를 고른다(순서 고정 아님).
+
+- **타겟 코드베이스** — Grep/Read/Glob으로 동일/유사 패턴
+- **참조 문서** — `.claude/references/**`, CLAUDE.md 등 프로젝트 문서
+- **사용자가 제공한 원본 자료** — 첨부 문서·파일·경로를 끝까지 확인 (키워드 검색만으로 종결 금지)
+- **공식 문서** — 외부 라이브러리/프레임워크 (필요 시)
+
+### 실패 시그널 (Step 3 진입 전 자가 검증)
+
+각 Medium/Low/ASSUMED 항목마다 다음 중 하나를 **한 줄로** 댈 수 있어야 한다.
+
+- 찾음: `{파일/문서}:{라인/페이지/섹션}` + 인용·요약
+- 못 찾음: 어디를 봤는지(회수한 맥락 + 탐색한 소스) 명시
+
+둘 다 못 대면 탐색이 부족한 것이다. 다시 수행한다. "어차피 모를 것"이라는 판단으로 건너뛰는 것은 **금지(NEVER)**.
+
+## Step 3: 재분류
+
+탐색 결과를 바탕으로 각 항목을 재분류한다.
+
+- 탐색으로 근거 확인됨 → **VERIFIED** 또는 **INFERRED High**로 승격 → 질문 제외
+- 탐색했으나 근거 없음 → 기존 분류 유지 → 질문 대상
+
+## Step 4: 재분류 보고 (필수)
+
+재분류 결과를 **표 형태로 사용자에게 출력**한다. Step 5 질문 전에 반드시 수행한다.
+
+| 항목 | 1차 분류 | 탐색 위치 | 근거(인용/요약) | 재분류 |
+|------|---------|----------|----------------|--------|
+| (정보 항목) | ASSUMED | 원본.docx p.3 / foo.ts:42 | "..." 또는 요약 | VERIFIED |
+
+- **탐색 위치**는 파일경로:라인번호, 문서명:페이지/섹션 등 구체적으로 명시한다.
+- **근거 없음**으로 남은 항목은 "탐색했으나 근거 없음"을 명시한다.
+- 보고 직후, 질문 대상이 남아 있으면 Step 5로 진행한다.
+
+## Step 5: 명확화 질문
+
+재분류 후에도 **INFERRED Medium/Low** 또는 **ASSUMED**로 남은 항목은 **MUST** `.claude/rules/sd-options.md`의 지침에 따라 사용자에게 질문한다.
+
+- VERIFIED와 INFERRED High는 명확한 것으로 본다.

package/claude/skills/sd-inner-debug/SKILL.md

@@ -62,7 +62,7 @@ description: (내부 전용) 근본 원인 분석(ACH) 로직. sd-debug, sd-chec
 - **위치** — 에러 발생 파일:라인 또는 관련 기능/화면
 - **재현 절차** — 문제가 발생하는 구체적 조작 순서
 
-@.claude/rules/sd-clarify.md 지침에 따라 명확화한다.
+`/sd-inner-clarify` 스킬을 호출하여 명확화한다.
 
 ## Step 2: 근본 원인 추적 (ACH)
 

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

@@ -33,6 +33,19 @@ description: (내부 전용) 코드 리뷰 분석 로직. sd-review, sd-dev 등
 
 아래 관점별 체크리스트로 이슈를 식별한다.
 
+#### 요구사항 대비 (SPEC) — 요구사항 원천이 제공된 경우에만
+
+요구사항 원천이 있으면 이를 기준으로 코드와 대조한다. 원천은 형식을 가리지 않는다:
+
+검증 항목:
+
+- 요구사항 미구현: 원천에 명시된 동작·규칙이 실제 코드에 반영되지 않음
+- 요구사항 위반: 원천의 규칙·결정과 다르게 구현
+- 경계 초과(스코프 크립): 원천에 "제외"/"다루지 않음"으로 명시된 항목이 구현됨
+- 진행 상태 불일치(체크박스·상태표가 있는 경우): 문서상 완료인데 산출물 없음 또는 그 반대
+
+근거 태그: `[근거: 사용자 요청 "..."]`, `[근거: 이메일 {제목}]`, `[근거: wbs Feature X.Y 경계]`, `[근거: Feature X.Y Scenario "..."]`, `[근거: 설계 결정 D2]` 등 출처 형식에 맞춰 명시
+
 #### 로직 버그 (LOGIC)
 
 실행은 되지만 결과가 틀린 이슈:

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

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

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

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

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

@@ -63,7 +63,7 @@ Question 도출 기법 — Feature 성격에 맞게 **하나 이상** 선택하
 
 ### 2-3. 명확화
 
-@.claude/rules/sd-clarify.md 지침에 따라 범위, Question, 기타 불명확한 부분을 명확화한다.
+`/sd-inner-clarify` 스킬을 호출하여 범위, Question, 기타 불명확한 부분을 명확화한다.
 답변에 따라 Rule/Example/Question을 갱신하며, 모든 Question이 해소될 때까지 **MUST** 반복한다. (추가 Question 발생 가능)
 - **나쁜 예:** "예약 기능 포함이 결정됨 → 예약 세부규칙(대기열 정책, 미대출 시 자동취소 기간)도 확정" — 기능 포함 여부와 세부 수치/규칙은 별개다. 세부사항은 별도로 분류·질문한다.
 
@@ -85,37 +85,67 @@ Feature: {번호} {이름}
       Given / When / Then
 ```
 
-## Step 4: 구현계획
+## Step 4: 기준 코드 탐색
 
-### 코드베이스 탐색
+**CRITICAL: 코드가 source of truth이다.** 구현계획 작성 전에 반드시 이 단계를 완료한다.
 
-**CRITICAL: 코드가 source of truth이다.** 문서가 아닌 실제 코드를 기준으로 파악한다.
+### 4-1. 유사 기능 탐색
 
+코드베이스에서 이 Feature와 **가장 유사한 기존 기능**을 찾는다. 유사 기능이란 동일한 도메인, 비슷한 CRUD 패턴, 유사한 UI 흐름 등을 공유하는 기능이다.
+
+탐색 대상:
 - 관련 엔티티/모델 구조
 - 기존 API 엔드포인트 및 패턴
-- 사용 중인 프레임워크와 아키텍처 패턴
+- UI 컴포넌트 구조, **레이아웃·생김새 (HTML 골격, CSS 클래스 네이밍, 컨트롤 배치, 스타일 토큰)**, 라우팅
 - 기존 시스템 연동 방식
-- 성능/보안 제약
 - 관련 테스트 구조
 - 관련 의존성과 설정
 
+### 4-2. 패턴 문서화
+
+탐색 결과를 **기준 코드** 섹션으로 정리한다. **CRITICAL: 모든 항목에 `파일경로:라인번호`를 인용한다.** 인용 없는 항목은 작성하지 않는다.
+
+```markdown
+### 기준 코드
+(이 Feature 구현 시 따라야 할 기존 코드 패턴)
+
+#### 유사 기능: {기능명}
+- 엔티티: `src/models/xxx.ts:15` — {구조 요약}
+- API: `src/services/xxx-service.ts:42` — {패턴 요약}
+- UI: `src/views/xxx.component.ts:10` — {구조 요약}
+- 테스트: `tests/xxx.spec.ts:5` — {패턴 요약}
+
+#### 프로젝트 컨벤션
+- 네이밍 (파일·클래스·함수·변수): {관찰된 패턴} [근거: `파일경로:라인번호`]
+- 디렉토리 구조 / 파일 배치: {관찰된 패턴} [근거: `파일경로:라인번호`]
+- 에러 처리: {관찰된 패턴} [근거: `파일경로:라인번호`]
+- 검증: {관찰된 패턴} [근거: `파일경로:라인번호`]
+- 의존성 주입·import 패턴: {관찰된 패턴} [근거: `파일경로:라인번호`]
+- 테스트 구조·헬퍼 사용: {관찰된 패턴} [근거: `파일경로:라인번호`]
+- UI 구조·레이아웃·컴포넌트 생김새 (HTML 골격, CSS 클래스 네이밍, 컨트롤 배치, 스타일 토큰): {관찰된 패턴} [근거: `파일경로:라인번호`]
+```
+
+유사 기능을 찾을 수 없으면, 그 사실을 명시하고 프로젝트의 일반적 컨벤션(네이밍, 디렉토리 구조 등)만 기록한다.
+
+## Step 5: 구현계획
+
 ### Tech Design Doc
 
-기존 코드베이스의 패턴/컨벤션을 따른다. 새 기술/패턴 도입 시 대안 검토에서 비교.
+**CRITICAL: 기준 코드(Step 4)의 패턴을 따른다.** 기준 코드와 다른 패턴을 사용하려면 반드시 대안 검토에서 기존 패턴과 비교하고 사용자 확인을 받는다.
 
-각 항목에 `[근거: ...]` 태그로 출처를 명시한다.
+각 항목에 `[근거: ...]` 태그로 출처를 명시한다. 코드 인용 시 `파일경로:라인번호`를 포함한다.
 
 ```markdown
 ### 배경
-(이 Feature를 구현하는 기술적 맥락. 기존 코드의 관련 구조 간단히 언급)
+(이 Feature를 구현하는 기술적 맥락. 기준 코드의 관련 구조 인용)
 ### 목표
 - 기술적 목표 [근거: Rule "..."]
 ### 비목표
 - 의도적 제외 항목 [근거: wbs 경계 "..."]
 ### 설계
-- API, 엔티티, 검증 규칙, UI 구조 등 [근거: Rule "..." 처리를 위해]
+- API, 엔티티, 검증 규칙, UI 구조 등 [근거: Rule "..." 처리를 위해, 기준 코드 `파일경로:라인번호` 패턴 준수]
 ### 대안 검토
-(고려했으나 선택하지 않은 접근 방식과 그 이유)
+(고려했으나 선택하지 않은 접근 방식과 그 이유. 기존 패턴과 다른 방식을 제안할 경우 필수)
 ```
 
 ### Vertical Slicing
@@ -126,17 +156,17 @@ Gherkin Scenarios를 구현 단위(Slice)로 분할한다.
 - Slice 간 의존 관계로 순서 결정
 
 ```markdown
-#### Slice 1: (제목)
+#### [ ] Slice 1: (제목)
 - **구현 내용:** (요약)
 - **Scenarios:** ...
 
-#### Slice 2: (제목)
+#### [ ] Slice 2: (제목)
 - **의존:** Slice 1
 - **구현 내용:** (요약)
 - **Scenarios:** ...
 ```
 
-## Step 5: Feature 문서 생성
+## Step 6: Feature 문서 생성
 
 - **위치:** wbs 문서가 있는 디렉토리
 - **파일명:** `{Feature번호}-{Feature이름 영문번역}.md` (kebab-case, 특수문자 제거)
@@ -148,6 +178,9 @@ Gherkin Scenarios를 구현 단위(Slice)로 분할한다.
 - WBS: [{wbs 파일명}]({wbs 문서 상대경로})
 {수집한 구체적 정보}
 
+## 기준 코드
+{Step 4에서 작성한 기준 코드 섹션}
+
 ### 설계 결정
 | # | 결정사항 | 선택 | 근거 |
 
@@ -158,7 +191,7 @@ Gherkin Scenarios를 구현 단위(Slice)로 분할한다.
 {Tech Design + Slicing}
 ```
 
-## Step 6: 정보 유실 방지 검증
+## Step 7: 정보 유실 방지 검증
 
 문서 작성 후, 대화에서 수집한 모든 구체적 정보가 문서에 기록되었는지 검증한다.
 
@@ -166,14 +199,14 @@ Gherkin Scenarios를 구현 단위(Slice)로 분할한다.
 - 언급된 참조 파일/문서 경로가 확인 목적과 함께 기록되었는가?
 - 누락 발견 시 문서에 반영한 뒤 저장한다.
 
-## Step 7: 역방향 피드백
+## Step 8: 역방향 피드백
 
 wbs 문서에 변경/발견 사항을 반드시 반영한다. 누락/불일치 수정을 생략하지 않는다.
 - 범위 축소/확대, 경계 재조정, 설계 결정 요약, Feature 간 범위 이관 등
 문서 간 정합성을 유지하고 변경 사유를 명확히 작성한다.
 역방향 피드백의 목적은, 새로운 세션에서 다른 작업을 수행할때 이 세션의 결정사항을 잊지 않고 이어서 하기 위함이다.
 
-## Step 8: 다음 단계 안내
+## Step 9: 다음 단계 안내
 
 Feature 설계 완료 후, 개발을 위한 다음 단계를 안내한다.