@simplysm/sd-claude 14.0.47 → 14.0.48

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은 스킬/프롬프트가 큰 틀에서 작동하는지 보는 **스모크 테스트**이다. 세부 지시를 하나하나 검증하지 않으므로, 가볍고 빠르게 돈다.
-
-### 시나리오 구성 원칙
-
-- **시나리오**: 최소 성공 시나리오 1~2개 및 회귀 테스트 시나리오
-- **happy-path 중심**: 대표적 성공 케이스 1개는 프롬프트 작성 전에 먼저 작성한다. 실사용에서 실패가 관찰되면 회귀 테스트로 추가한다
-- **사전 조건 최소화**: 긴 파일 세팅·복잡한 디렉토리 구성 요구 지양
-- **빠른 실행**: 수분 내 종료되는 단순 입력으로 구성한다
-
-### Eval 유형
-
-| Eval 유형       | 설명                      | 판정 방식             |
-|---------------|-------------------------|-------------------|
-| **행동 Eval**   | 이 입력에서 출력이 충족해야 할 체크리스트 | 객관적 항목 + LLM 판단   |
-| **안티패턴 Eval** | 출력에 나타나면 안 되는 것들        | 행동/결과 확인 + LLM 판단 |
-
-### 체크리스트 작성 원칙
-
-Judge의 정확도는 체크리스트의 품질에 달려있다. 다음 원칙을 따른다:
-
-#### 1) 산출물 중심 — 과정이 아닌 결과를 본다
-
-체크리스트는 **스킬/프롬프트가 만들어낸 산출물이 목적을 달성했는가**를 본다. 중간 과정·도구 사용·질문 여부는 체크하지 않는다.
-
-```
-(X) "불명확한 부분에 대해 사용자에게 질문했다"          — 프로세스
-(X) "Read 도구로 파일을 읽었다"                       — 도구 사용
-(X) "FAIL 원인을 분석하고 개선안을 제시했다"            — 프로세스
-
-(O) "Impact Mapping 트리(Goal→Actor→Impact→Deliverable)가 산출되었다"
-(O) "모든 Feature가 Goal까지 역추적 가능하다"
-(O) "SKILL.md에 프론트매터(name, description)가 포함되었다"
-```
-
-#### 2) 상황 의존 금지 — 구조·구현 세부에 종속되지 않는다
-
-SKILL.md의 Step 구조·도구명·파일 형식 같은 구현 세부에 종속된 항목은 배제한다. 구조가 바뀌면 체크도 깨지기 때문이다.
-
-```
-(X) "Eval 파일이 프롬프트보다 먼저 작성되었다"           — Step 순서에 종속
-(X) "격리된 workspace(.tmp/)에서 claude -p가 실행되었다"  — 실행 환경 세부
-(O) "신규 스킬 요청에 대해 SKILL.md가 생성되었다"        — 스킬 목적 자체
-```
-
-#### 3) 객관적 기준 — 주관적 표현을 제거한다
-
-```
-(X) "프롬프트 내용이 좋은가"
-(O) "모호한 표현('적절한', '필요시', '경우에 따라' 등)이 없는가"
-```
-
-#### 4) 단일 기준 — 하나의 항목은 하나만 평가한다
-
-```
-(X) "파일을 읽고 올바른 분석을 출력했다"
-(O) "분석 결과가 사실에 부합한다"
-```
-
-### 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" 원칙에 따라 파일을 분리한다.
-
-## 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                         | 연산                 |
-|-------------------------------|--------------------|
-| **중복 지시** — 같은 내용이 다른 표현으로 반복 | 통합                 |
-| **잔재 지시** — 이전 개선 루프에서 남은 것   | 삭제                 |
-| **장황한 표현**                    | 의미 유지하며 압축         |
-| **용어 불일치** — 같은 개념을 다른 단어로 지칭 | 통일                 |
-| **상충 지시** — 서로 모순/충돌          | 우선순위 결정 후 통합 또는 삭제 |
-| **구조 산만** — 관련 지시가 흩어져 있음     | 재배치                |
-
-발견된 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될때까지 반복한다.

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