@simplysm/sd-claude 14.0.46 → 14.0.48

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-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 설계 완료 후, 개발을 위한 다음 단계를 안내한다.
 

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

@@ -1,178 +1,180 @@
----
-name: sd-prompt
-description: 스킬/프롬프트 파일의 작성·개선을 위한 EDD 스킬. "스킬 만들어줘", "룰 만들어줘", "프롬프트 만들어줘", "스킬 개선", "프롬프트 개선", "Eval 실행", "스킬 테스트" 등을 요청할 때 사용한다.
----
-
-# sd-prompt: Eval-Driven Prompt Development
-
-프롬프트 파일이란 룰(.claude/rules/*.md), 시스템 프롬프트, 커스텀 지시 등 모든 .md 프롬프트를 포함한다.
-
-## 산출물 파일 구조
-
-```
-룰인 경우:
-  .claude/rules/{name}.md             ← 룰 프롬프트 (산출물)
-  .claude/evals/{name}.md             ← 룰의 Eval 시나리오
-
-나머지 경우 (스킬, 프롬프트 등):
-  대상 파일 옆에 {대상파일명}.eval.md 로 생성
-  예시:
-    .claude/skills/{name}/SKILL.md    → .claude/skills/{name}/SKILL.eval.md
-    {경로}/{name}.md                  → {경로}/{name}.eval.md
-```
-
-## Step 1: 의도 정의 (Intent)
-
-프롬프트 작성 전에 다음을 파악한다:
-- **유형**: 스킬(특정 명령으로 트리거) vs 프롬프트(항상/조건부 적용)
-- **트리거 조건**: 어떤 발화/상황에서 발동하는가 (스킬인 경우)
-- **입력**: 무엇을 받는가
-- **출력**: 무엇을 내놓는가
-
-@.claude/rules/sd-clarify.md 지침에 따라 명확화한다.
-
-## Step 2: Eval 시나리오 정의
-
-프롬프트 작성 전에 성공여부를 판단하기 위한 Eval문서를 먼저 작성한다.
-
-### Eval 유형
-
-| Eval 유형       | 설명                      | 판정 방식             |
-|---------------|-------------------------|-------------------|
-| **행동 Eval**   | 이 입력에서 출력이 충족해야 할 체크리스트 | 객관적 항목 + LLM 판단   |
-| **안티패턴 Eval** | 출력에 나타나면 안 되는 것들        | 행동/결과 확인 + LLM 판단 |
-
-### 체크리스트 작성 원칙
-
-Judge의 정확도는 체크리스트의 품질에 달려있다. 다음 원칙을 따른다:
-
-#### 1) 행동/결과 중심 — 도구명을 사용하지 않는다
-
-특정 도구에 의존하면 환경에 따라 판정이 달라진다. "무엇을 했는가"를 기술한다:
-특히 AskUserQuestion의 경우 Eval환경에서는 질문하지 않고 답을 스스로 도출하므로, 이에 유의한다.
-```
-(X) "불명확한 부분에 대해 AskUserQuestion 도구를 호출했다"
-(O) "불명확한 부분에 대한 선택을 제시했다."
-
-(X) "Read 도구로 파일을 읽었다"
-(O) "파일을 읽었다."
-
-(X) "Glob으로 탐색했다"
-(O) "기존 스킬 목록이 출력에 반영되어 있다"
-```
-
-#### 2) 객관적 기준 — 주관적 표현을 제거한다
-
-```
-(X) "프롬프트 내용이 좋은가"
-(O) "모호한 표현('적절한', '필요시', '경우에 따라' 등)이 없는가"
-```
-
-#### 3) 단일 기준 — 하나의 항목은 하나만 평가한다
-
-```
-(X) "파일을 읽고 올바른 분석을 출력했다"
-(O) "해당 파일을 읽었다."
-(O) "분석 결과가 사실에 부합한다"
-```
-
-#### 4) 프로세스 중심 — 추론 결과가 아닌 규칙 적용 여부를 평가한다
-
-LLM이 특정 형태의 결과를 출력했는지가 아니라, 프로세스/규칙을 따랐는지를 기준으로 작성한다:
-
-```
-(X) "기존 스킬/룰 목록이 출력에 포함되었다"  — 특정 출력 형태를 기대
-(O) "기존 스킬/룰과의 충돌·중복 여부를 확인했다" — 규칙 적용 여부를 평가
-
-(X) "3개의 개선안이 출력에 포함되었다"       — 추론 결과의 수량을 기대
-(O) "FAIL 원인을 분석하고 개선안을 제시했다"  — 프로세스 수행 여부를 평가
-```
-
-### Eval 파일 형식
-
-#### 입력 작성 원칙
-
-- **스킬:** **MUST** 반드시 실제 호출 방식인 `/{skill-name}`(슬래시 커맨드)을 입력으로 사용한다.
-- **프롬프트:** 프롬프트가 적용되어야 하는 상황의 자연어 발화를 입력으로 사용한다.
-
-```markdown
-# Eval: {skill-or-prompt-name}
-
-## 행동 Eval
-
-### 시나리오 1: {이름}
-
-- 입력: "/{skill-name} (스킬입력)" (스킬)
-- 체크리스트:
-  - [ ] {객관적 판정 기준 1}
-  - [ ] {객관적 판정 기준 2}
-  - [ ] {객관적 판정 기준 3}
-
-### 시나리오 2: {이름}
-
-- 입력: "{자연어 발화}" (프롬프트)
-- 체크리스트:
-  - [ ] {객관적 판정 기준 1}
-  - [ ] {객관적 판정 기준 2}
-
-## 안티패턴 Eval
-
-- [ ] {하면 안 되는 행동 1}
-- [ ] {하면 안 되는 행동 2}
-```
-
-## Step 3: 프롬프트 작성
-
-### 스킬인 경우: SKILL.md 구조
-
-`.claude/skills/sd-prompt/references/skill-guide.md`를 읽고 구조 가이드에 따라 작성한다.
-
-### 프롬프트인 경우: .md 구조
-
-프론트매터가 필요하지 않으며, 자유양식으로 작성
-
-### 품질 원칙
-
-- **금지에는 대안을 함께 제시한다** — "`Buffer` 사용 금지"만으로는 불충분. "`Buffer` 금지 — `Uint8Array`를 사용한다"로 작성한다
-- **강한 규칙에 키워드를 구분한다** — `MUST`, `NEVER`, `ALWAYS`, `CRITICAL`, `IMPORTANT`, `required`, `prohibited`. IMPORTANT/CRITICAL은 진짜 중요한 규칙에만 사용한다.
-- **모호한 표현을 제거한다** — "적절하게", "필요시", "경우에 따라" 등은 LLM이 추측하게 만든다. 구체적인 조건과 행동으로 바꾸거나 AskUserQuestion을 활용한다.
-- **간결하게 유지한다** — SKILL.md는 200줄 이하를 목표로 한다. 200줄이 넘을 경우 "Progressive Disclosure" 원칙에 따라 파일을 분리한다.
-- **과적합을 방지한다** — 특정 Eval 시나리오에만 맞추지 말고, 일반적으로 통하는 표현으로 작성한다.
-
-## Step 4: Eval 실행 & 판정
-
-### 실행 절차
-
-`.claude/skills/sd-prompt/references/eval-runner.md`를 읽고 절차에 따라 Eval을 실행한다.
-
-### 개선 루프
-
-FAIL이 1개라도 있으면 다음 단계로 진행할 수 없다. 이유를 불문하고 수정 없이 다음 단계로 넘어가는 것은 금지한다.
-Judge 보고서의 개선 제안을:
-1. `.claude/rules/sd-options.md`를 읽고 사용자에게 질문한다.
-   - FAIL 판정이유 및 해당하는 부분의 실제 출력을 포함해야함
-2. 승인된 제안을 작성 원칙에 따라 수정한다.
-3. 수정 후 workspace를 재구성하여 Eval을 재실행한다. (Eval만 수정된 경우 복사하고, Judge만 재수행)
-
-## Step 5: 프롬프트 리팩터링 (Refactor)
-
-전체 Eval PASS 후, 개선 루프에서 누적된 패치를 정리하여 최소한의 프롬프트를 찾는다.
-
-### Prompt Smell 탐지
-
-| Smell                         | 연산                 |
-|-------------------------------|--------------------|
-| **중복 지시** — 같은 내용이 다른 표현으로 반복 | 통합                 |
-| **투기적 지시** — 관찰된 실패 없이 추가된 것  | 삭제                 |
-| **고아 지시** — Eval이 없는 지시       | 삭제 또는 Eval 추가      |
-| **잔재 지시** — 이전 개선 루프에서 남은 것   | 삭제                 |
-| **장황한 표현**                    | 의미 유지하며 압축         |
-| **용어 불일치** — 같은 개념을 다른 단어로 지칭 | 통일                 |
-| **상충 지시** — 서로 모순/충돌          | 우선순위 결정 후 통합 또는 삭제 |
-| **구조 산만** — 관련 지시가 흩어져 있음     | 재배치                |
-
-발견된 Prompt Smell에 대해 `.claude/rules/sd-clarify.md` 지침에 따라 진행여부와 방법을 명확화하여 수정한다.
-
-### Regression Guard
-
-리팩터링 후 Eval을 재실행한다. FAIL 시 **개선 루프**로 수정한다. Eval 전체가 PASS될때까지 반복한다.
+---
+name: sd-prompt
+description: 스킬/프롬프트 파일의 작성·개선을 위한 EDD 스킬. "스킬 만들어줘", "룰 만들어줘", "프롬프트 만들어줘", "스킬 개선", "프롬프트 개선", "Eval 실행", "스킬 테스트" 등을 요청할 때 사용한다.
+---
+
+# sd-prompt: Eval-Driven Prompt Development
+
+프롬프트 파일이란 룰(.claude/rules/\*.md), 시스템 프롬프트, 커스텀 지시 등 모든 .md 프롬프트를 포함한다.
+
+## 작업 추적
+
+Step 1~5는 장기 프로세스이다. 스킬 시작 시점에 각 Step을 `TaskCreate`로 등록한다. Step 진입 시 `TaskUpdate`로 `in_progress`, 완료 시 `completed`로 갱신한다. 개선 루프(Step 4)·Regression Guard(Step 5)로 이전 Step에 재진입할 때도 해당 Task를 다시 `in_progress`로 되돌려 상태를 반영한다.
+
+## 산출물 파일 구조
+
+```
+룰인 경우:
+  .claude/rules/{name}.md             ← 룰 프롬프트 (산출물)
+  .claude/evals/{name}.md             ← 룰의 Eval 시나리오
+
+나머지 경우 (스킬, 프롬프트 등):
+  대상 파일 옆에 {대상파일명}.eval.md 로 생성
+  예시:
+    .claude/skills/{name}/SKILL.md    → .claude/skills/{name}/SKILL.eval.md
+    {경로}/{name}.md                  → {경로}/{name}.eval.md
+```
+
+## Step 1: 의도 정의 (Intent)
+
+프롬프트 작성 전에 다음을 파악한다:
+
+- **유형**: 스킬(특정 명령으로 트리거) vs 프롬프트(항상/조건부 적용)
+- **트리거 조건**: 어떤 발화/상황에서 발동하는가 (스킬인 경우)
+- **입력**: 무엇을 받는가
+- **출력**: 무엇을 내놓는가
+
+`/sd-inner-clarify` 스킬을 호출하여 명확화한다.
+
+## Step 2: Eval 시나리오 정의
+
+### Eval 유형
+
+| Eval 유형         | 설명                                      | 판정 방식                 |
+| ----------------- | ----------------------------------------- | ------------------------- |
+| **행동 Eval**     | 이 입력에서 출력이 충족해야 할 체크리스트 | 객관적 항목 + LLM 판단    |
+| **안티패턴 Eval** | 출력에 나타나면 안 되는 것들              | 행동/결과 확인 + LLM 판단 |
+
+### 체크리스트 작성 원칙
+
+Judge의 정확도는 체크리스트의 품질에 달려있다. 다음 원칙을 따른다:
+
+- **CRITICAL**: 체크리스트의 모든 항목은 사용자의 명시적 요청 및 답변에서 도출되어야 한다.
+- 객관적 기준으로 작성한다.
+- 하나의 항목은 하나만 평가한다.
+- Judge를 통해 도출할 수 있는 내용만 작성한다.
+- **조건부 행동을 체크리스트에 넣지 않는다** — 입력·상태에 따라 발생할 수도, 안 할 수도 있는 행동은 체크 항목으로 부적합하다. 해당 입력에서 **반드시 발생하는 행동**만 넣는다.
+
+#### Judge 관찰 가능 소스
+
+Judge는 아래 **두 가지만** 볼 수 있다. 체크리스트의 모든 항목은 이 소스에서 PASS/FAIL을 판정할 수 있어야 한다.
+
+| 소스               | 설명                                               | 판정 가능 예시                                          |
+| ------------------ | -------------------------------------------------- | ------------------------------------------------------- |
+| **workspace 파일** | 스킬 실행 후 workspace에 생성·수정된 파일          | 파일 존재 여부, 파일 내 특정 문자열·구조·섹션 포함 여부 |
+| **텍스트 출력**    | `run-output.json`에 기록된 assistant의 텍스트 출력 | 출력에 특정 문구 포함/미포함 여부, 출력 구조            |
+
+**Judge가 볼 수 없는 것:** 도구 호출 여부/순서, 내부 추론, 파일을 "읽었는지" 여부. 이런 것은 체크 항목으로 넣지 않는다.
+
+#### 자가검증
+
+각 체크 항목을 작성한 후, "Judge가 workspace 파일 또는 텍스트 출력만 보고 이 항목의 PASS/FAIL을 판정할 수 있는가?"를 자문한다. "아니오"이면 재작성하거나 삭제한다.
+
+### Eval 파일 형식
+
+#### 입력 작성 원칙
+
+- **스킬:** 반드시(MUST) 실제 호출 방식인 `/{skill-name}`(슬래시 커맨드)을 입력으로 사용한다.
+- **프롬프트:** 프롬프트가 적용되어야 하는 상황의 자연어 발화를 입력으로 사용한다.
+
+```markdown
+# Eval: {skill-or-prompt-name}
+
+## 행동 Eval
+
+### 시나리오 1: {이름}
+
+- 입력: "/{skill-name} (스킬입력)" (스킬)
+- 체크리스트:
+  - [ ] {객관적 판정 기준 1}
+  - [ ] {객관적 판정 기준 2}
+
+### 시나리오 2: {이름}
+
+- 입력: "{자연어 발화}" (프롬프트)
+- 체크리스트:
+  - [ ] {객관적 판정 기준 1}
+  - [ ] {객관적 판정 기준 2}
+
+## 안티패턴 Eval
+
+- [ ] {하면 안 되는 행동 1}
+- [ ] {하면 안 되는 행동 2}
+```
+
+## Step 3: 프롬프트 작성
+
+### 스킬인 경우: SKILL.md 구조
+
+`.claude/skills/sd-prompt/references/skill-guide.md`를 읽고 구조 가이드에 따라 작성한다.
+
+### 프롬프트인 경우: .md 구조
+
+프론트매터가 필요하지 않으며, 자유양식으로 작성
+
+### 품질 원칙
+
+- **금지에는 대안을 함께 제시한다** — "`Buffer` 사용 금지"만으로는 불충분. "`Buffer` 금지 — `Uint8Array`를 사용한다"로 작성한다
+- **강한 규칙에 키워드를 구분한다** — `반드시(MUST)`, `절대(NEVER)`, `항상(ALWAYS)`, `CRITICAL`, `IMPORTANT`. IMPORTANT/CRITICAL은 진짜 중요한 규칙에만 사용한다.
+- **모호한 표현을 제거한다** — "적절하게", "필요시", "경우에 따라" 등은 LLM이 추측하게 만든다. 구체적인 조건과 행동으로 바꾸거나 AskUserQuestion을 활용한다.
+- **간결하게 유지한다** — SKILL.md는 200줄 이하를 목표로 한다. 200줄이 넘을 경우 "Progressive Disclosure" 원칙에 따라 파일을 분리한다.
+
+## Step 4: Eval 실행 & 판정
+
+### 실행 절차
+
+`.claude/skills/sd-prompt/references/eval-runner.md`를 읽고 절차에 따라 Eval을 실행한다.
+
+### 개선 루프
+
+FAIL이 1개라도 있으면 다음 단계로 진행할 수 없다. 이유를 불문하고 수정 없이 다음 단계로 넘어가는 것은 금지한다.
+Judge 보고서의 개선 제안에 대해:
+
+1. @.claude/rules/sd-options.md 를 읽고 사용자에게 질문한다.
+   - FAIL 판정이유 및 해당하는 부분의 실제 출력을 포함해야한다.
+2. 승인된 제안에 따라 작성 원칙에 맞추어 수정한다.
+3. 수정 후 workspace를 재구성하여 Eval을 재실행한다. (Eval만 수정된 경우, eval을 복사하고, Judge만 재수행)
+
+## Step 5: 프롬프트 리팩터링 (Refactor)
+
+전체 Eval PASS 후, 개선 루프에서 누적된 패치를 정리하여 정돈된 프롬프트를 만든다.
+
+### Prompt Smell 탐지
+
+각 Smell은 아래 **탐지 규칙**에 해당할 때만 리포트한다. **예외 조건**에 해당하면 Smell로 치지 않는다. 리포트 시 **원문 라인 인용**(`파일경로:라인`)을 반드시 포함한다 — 근거를 댈 수 없으면 리포트 금지.
+
+#### 중복 지시
+- 탐지: 동일 지시(동사+목적어 수준)가 2곳 이상에 등장
+- 예외: 양쪽 모두 `CRITICAL`/`MUST`/`절대`/`반드시` 등 강조 키워드가 붙어 있고, 서로 다른 Step·섹션 경계에서 **의도적 강조**로 읽히는 경우
+- 연산: 통합
+
+#### 잔재 지시
+- 탐지: 현재 흐름에서 더 이상 참조·호출되지 않는 지시
+- 예외: 후속 Step이나 다른 참조 문서에서 전제로 인용되는 지시
+- 연산: 삭제
+
+#### 장황한 표현
+- 탐지: 의미 단위가 중복 수식·군더더기로 채워진 문장 (예: "처음부터 끝까지 빠짐없이 전부 다")
+- 예외: 법·규칙 문언처럼 정확한 범위·경계를 명시해야 하는 지시
+- 연산: 의미 유지하며 압축
+
+#### 용어 불일치
+- 탐지: 같은 개념이 2개 이상의 단어로 지칭됨
+- 예외: 최초 정의에서 동의어를 명시 병기한 뒤 일관 사용하는 경우
+- 연산: 통일 (주 용어 선정 후 전면 치환)
+
+#### 상충 지시
+- 탐지: 두 지시가 동일 조건에서 서로 다른 행동을 요구
+- 예외: 상위·하위 관계나 우선순위가 명시되어 충돌이 해소된 경우
+- 연산: 우선순위 결정 후 통합 또는 삭제
+
+#### 구조 산만
+- 탐지: 동일 주제의 지시가 3곳 이상에 흩어져 있음
+- 예외: 각 Step·섹션에서 **국소적으로만** 필요한 지시여서 공통 추출이 오히려 독립성을 해치는 경우
+- 연산: 재배치 (공통 섹션으로 추출하거나 한 Step 안으로 모음)
+
+발견된 Prompt Smell에 대해 `/sd-inner-clarify` 스킬을 호출하여 진행여부와 방법을 명확화하여 수정한다.
+
+### Regression Guard
+
+리팩터링 후 Eval을 재실행한다. FAIL 시 **개선 루프**로 수정한다. Eval 전체가 PASS될때까지 반복한다.