@simplysm/sd-claude 14.0.82 → 14.0.84

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

@@ -5,7 +5,7 @@ description: spec.md 의 단위(§4.x 화면 / §5.x 자동 처리 / §6.x 횡
 
 # sd-impl
 
-spec.md 단위(§4.x 화면 / §5.x 자동 처리 / §6.x 횡단 처리) 1개를 현재 코드베이스 상태와 비교해 빠지거나 어긋난 부분만큼 풀 구현함. 데모 골격이 있으면 보존. 끝에 사용자 시연으로 회귀를 잡음.
+spec.md 단위(§4.x 화면 / §5.x 자동 처리 / §6.x 횡단 처리) 1개를 현재 코드베이스 상태와 비교해 빠지거나 어긋난 부분만큼 풀 구현. 데모 골격이 있으면 보존. 끝에 사용자 시연으로 회귀 점검.
 
 호출 시나리오 2종 — 동일 워크플로:
 
@@ -16,8 +16,8 @@ spec.md 단위(§4.x 화면 / §5.x 자동 처리 / §6.x 횡단 처리) 1개를
 
 워크플로 전 단계 적용:
 
-- **임의 채움 금지**: spec 본문에 명시 없거나 모호한 분기를 발견하면 즉시 멈추고 사용자에게 질문. 자체 판단으로 채우지 않음.
-- **사용자 보고 어휘**: 사용자 보고에 코드 식별자(변수명·SQL 함수명·타입 키워드 등) 노출 금지. 도메인 어휘로 풀어 보고.
+- **임의 채움 금지**: spec 본문에 명시가 없거나 모호한 분기를 발견하면 즉시 멈추고 사용자에게 질문. 자체 판단으로 채우지 않음.
+- **사용자 보고 어휘**: 사용자에게 보고하는 본문에 코드 식별자(변수명·SQL 함수명·타입 키워드 등) 노출 금지. 도메인 어휘로 풀어 보고.
 
 ## 워크플로
 
@@ -26,32 +26,32 @@ spec.md 단위(§4.x 화면 / §5.x 자동 처리 / §6.x 횡단 처리) 1개를
 - 대상 spec.md 경로.
 - 구현할 단위 식별자 — `§4.x` (화면) / `§5.x` (자동 처리) / `§6.x` (횡단 처리).
 
-없으면 묻기. spec.md 에 식별자 매칭이 안 되면 §4 화면 목록 표 / §5 자동 처리 / §6 횡단 처리 헤더 목록에서 후보 제시 후 확정.
+없으면 묻기. spec.md 에서 식별자 매칭이 안 되면 §4 화면 목록 표 / §5 자동 처리 / §6 횡단 처리 헤더 목록에서 후보를 제시 후 확정.
 
 ### 2단계: 외부 입력 점검
 
-작업 대상 §4.x/§5.x/§6.x 와 그가 참조하는 §5/§6/§7/§8/§9 항목 점검:
+작업 대상 §4.x/§5.x/§6.x 와 작업 대상이 참조하는 §5/§6/§7/§8/§9 항목을 점검:
 
-- **헤더 `[OPEN: 날짜]` 섹션**: 본문이 재분석 포인터일 뿐 임의안 부재 → "spec 수정 절차" 적용.
-- **본문 인라인 `[OPEN]`**: 결정 근거 있으면 결정. 없으면 1건씩 질문 → 답변 후 "spec 수정 절차" 적용.
+- **헤더 `[OPEN: 날짜]` 섹션**: 본문이 재분석 포인터일 뿐 초안 부재 → "spec 수정 절차" 적용.
+- **본문 인라인 `[OPEN]`**: 결정 근거가 있으면 결정. 없으면 1건씩 질문 → 답변 후 "spec 수정 절차" 적용.
 - **사용자 제공 예정 자료**: spec 본문에 사용자 회신 대기로 적힌 자료. 사용자 회신 후 진행.
-- **묵시적 모호**: 명시 마커 없지만 spec 본문이 분기·정의·정의식·경계 케이스를 다루지 않는 부분. 4단계 분해 중 발견 가능성 높음. 발견 시 본 단계로 회귀.
+- **묵시적 모호**: 명시 마커는 없지만 spec 본문이 분기·정의·정의식·경계 케이스를 다루지 않는 부분. 4단계 분해 중 발견 가능성 높음. 발견 시 본 단계로 회귀.
 
 #### spec 수정 절차
 
 spec 본문 수정이 필요한 경우(인라인 `[OPEN]` 해소·헤더 `[OPEN]` 해소·구조 변경·6단계 (b)(d) 분류 처리 등) 메인 LLM 이 직접 처리:
 
-1. **sd-spec SKILL.md Read** — 룰 인지 (임의안 작성 사이클·헤더 마커 형식·관련 섹션·의존 식별 룰).
-2. **임의안 → "맞나요?" → 확정 → spec.md Edit** (sd-spec 사이클 적용).
-3. **의존 식별** — 수정된 § 항목이 의존인 §4.x/§5.x/§6.x 탐색 (sd-spec "의존 식별" 룰). 본 작업 단위 본인은 제외 (작업 중).
+1. **sd-spec SKILL.md Read** — 룰 인지 (초안 작성 사이클·헤더 마커 형식·관련 섹션·의존 식별 룰).
+2. **초안 → "맞나요?" → 확정 → spec.md Edit** (sd-spec 사이클 적용).
+3. **의존 식별** — 수정된 § 항목을 의존으로 가진 §4.x/§5.x/§6.x 탐색 (sd-spec "의존 식별" 룰). 본 작업 단위 자신은 제외 (작업 중).
 4. **마커 제거** — 의존 §4.x/§5.x/§6.x 헤더의 `, 구현: YYYY-MM-DD` 부분만 제거 (이전 구현 무효화).
-   - 영향 단위 번호 매겨 사용자에게 모아 "맞나요?" — 전체 동의 → 일괄 제거 / 일부 유지 지목 → 지목 항목 마커 유지.
+   - 영향 단위에 번호를 매겨 사용자에게 모아서 "맞나요?" 질문 — 전체 동의 → 일괄 제거 / 일부 유지 지목 → 지목 항목 마커 유지.
 
-본 작업 단위(§4.x/§5.x/§6.x 본인) 의 헤더 `[확정]` 은 9단계에서 `[확정, 구현]` 으로 확장.
+본 작업 단위(§4.x/§5.x/§6.x 자신)의 헤더 `[확정]` 은 9단계에서 `[확정, 구현]` 으로 확장.
 
 ### 3단계: 보조 자료 수집 (있다면 활용)
 
-부재로 워크플로를 멈추지 않음. framework 처방은 본 SKILL.md 본문에 박지 않음 — 코드베이스 매뉴얼·기준 단위·테스트 환경을 발견되면 따르고, 부재 시 framework 자체 표준(Angular CLI 기본 구조·esbuild 기본 옵션 등) 채움 가능. 도메인 결정·분기·계산식 등 spec 결정 사항은 본질 "임의 채움 금지" 적용.
+부재로 워크플로를 멈추지 않음. framework 별 세부 지침은 본 SKILL.md 본문에 명시하지 않음 — 코드베이스 매뉴얼·기준 단위·테스트 환경이 발견되면 따르고, 부재 시 framework 자체 표준(Angular CLI 기본 구조·esbuild 기본 옵션 등)으로 채워도 됨. 도메인 결정·분기·계산식 등 spec 결정 사항은 본질 "임의 채움 금지" 적용.
 
 #### A. 라이브러리·개발 매뉴얼
 
@@ -60,7 +60,7 @@ spec 본문 수정이 필요한 경우(인라인 `[OPEN]` 해소·헤더 `[OPEN]
 
 #### B. 기준 단위 + 계층별 보강
 
-풀 구현은 다층 흐름이 한 줄로 가야 일관성이 유지됨. 답습 단위 1개를 통째 답습하는 모델이 아니라, 기준 단위 1개를 잡고 비어있거나 부적합한 계층만 다른 단위에서 보강함.
+풀 구현은 다층 흐름이 한 줄로 가야 일관성이 유지됨. 기존 단위 1개를 통째로 따라가는 방식이 아니라, 기준 단위 1개를 잡고 비어있거나 부적합한 계층만 다른 단위에서 보강.
 
 **4계층**:
 
@@ -73,29 +73,29 @@ spec 본문 수정이 필요한 경우(인라인 `[OPEN]` 해소·헤더 `[OPEN]
 
 **기준 단위 선정** (같은 종류 §4.x↔§4.x, §5.x↔§5.x, §6.x↔§6.x 안에서):
 
-1. 도메인 인접 풀구현 단위 후보 탐색 (인접 도메인 정의는 sd-spec §4 화면 목록 분류·코드베이스 구조 등 자유 도출).
-2. 1개 → 자동 채택. 2개 이상 → 후보 목록 제시 후 사용자 1회 질문. 0개 → 같은 종류 전 범위로 확장 후 동일 규칙.
+1. 도메인이 인접한 풀구현 단위 후보 탐색 (인접 도메인 정의는 sd-spec §4 화면 목록 분류·코드베이스 구조 등에서 자유 도출).
+2. 후보가 1개 → 자동 채택. 2개 이상 → 후보 목록 제시 후 사용자에게 1회 질문. 0개 → 같은 종류 전 범위로 확장 후 동일 규칙 적용.
 3. 전 범위에도 0개 → 기준 단위 없이 매뉴얼(A) + framework 자체 표준.
 
-**계층별 보강**: 기준 단위의 4계층 각각을 평가:
+**계층별 보강**: 기준 단위의 4계층 각각을 다음과 같이 평가:
 
 | 평가     | 의미                              | 처리                                      |
 | -------- | --------------------------------- | ----------------------------------------- |
-| 비어있음 | 해당 계층 파일이 기준 단위에 없음 | 같은 종류 다른 단위에서 그 계층 패턴 답습 |
-| 부적합   | 있지만 spec 요구와 어긋남         | 같은 종류 다른 단위에서 그 계층 패턴 답습 |
-| 적합     | 그대로 답습                       | 변경 없이 사용                            |
+| 비어있음 | 해당 계층 파일이 기준 단위에 없음 | 같은 종류 다른 단위에서 그 계층 패턴 차용 |
+| 부적합   | 있지만 spec 요구와 어긋남         | 같은 종류 다른 단위에서 그 계층 패턴 차용 |
+| 적합     | 그대로 따름                       | 변경 없이 사용                            |
 
-비어있음·부적합 계층은 2회 이상 반복된 패턴 자동 채택. 1회만 쓰인 변종은 배제. 다수 패턴이 갈리면 사용자 1회 질문.
+비어있음·부적합 계층은 같은 종류 다른 단위에서 2회 이상 반복된 패턴을 자동 채택. 1회만 쓰인 변종은 배제. 여러 패턴이 갈리면 사용자에게 1회 질문.
 
-**읽기**: 기준 단위의 적합 계층 파일 + 보강 출처 파일을 모두 읽기. 7단계 정합 점검 입력.
+**읽기**: 기준 단위의 적합 계층 파일 + 보강 출처 파일을 모두 읽기. 7단계 정합 점검의 입력.
 
 #### C. 테스트 환경
 
-단위 테스트 프로젝트 구분·실행 명령·mocking 패턴·dev 서버 실행 명령 파악. 부재 시 framework 자체 표준 조합.
+단위 테스트 프로젝트 구분·실행 명령·mocking 패턴·dev 서버 실행 명령을 파악. 부재 시 framework 자체 표준으로 조합.
 
 ### 4단계: spec 분해 표
 
-대상 §4.x/§5.x/§6.x 와 참조 §5/§6/§7/§8/§9 본문을 **항목 단위까지 분해**해 표 작성. 표는 assistant 응답으로 출력 (이후 5·6단계 입력). 일치 항목은 손대지 않음(차이만 작업).
+대상 §4.x/§5.x/§6.x 와 참조 §5/§6/§7/§8/§9 본문을 **항목 단위까지 분해**하여 표 작성. 표는 assistant 응답으로 출력 (이후 5·6단계의 입력). 일치 항목은 손대지 않음(차이만 작업).
 
 **예시** (재고관리 도메인, 박스 입고 화면 §4.1 일부):
 
@@ -116,22 +116,22 @@ spec 본문 수정이 필요한 경우(인라인 `[OPEN]` 해소·헤더 `[OPEN]
 
 - **항목 ID**: 1, 2 ... (이후 의존 컬럼 참조용. 형식 자유).
 - **spec 인용**: spec.md § 위치 + 본문 문구.
-- **현재 코드 상태**: 코드베이스 조사 결과 사실. 신규 = "없음", 갱신 = "있음(어떻게)". 조사는 워킹트리 파일 Read·Grep·Glob 만. 갱신 호출도 동일.
+- **현재 코드 상태**: 코드베이스 조사 결과 사실. 신규 호출 = "없음", 갱신 호출 = "있음(어떻게)". 조사는 워킹트리 파일을 Read·Grep·Glob 로만 수행. 갱신 호출도 동일.
 - **판정**: 없음 / 불일치 / 일치.
 - **매핑 파일**: 이 항목이 작성·갱신될 파일 경로.
 - **의존**: 다른 항목 ID.
 
-분해 중 spec 본문이 정의·정의식·분기·경계 케이스를 다루지 않거나 모순되는 부분 발견 → 2단계 회귀("spec 수정 절차" 적용).
+분해 중 spec 본문이 정의·정의식·분기·경계 케이스를 다루지 않거나 모순되는 부분을 발견 → 2단계로 회귀("spec 수정 절차" 적용).
 
 표 작성 완료 후 5단계 진입.
 
 ### 5단계: 작업 사이클
 
-표의 (없음·불일치) 항목만 의존 순서로 진행 (차이만 작업). 일치 항목은 손대지 않음.
+표의 (없음·불일치) 판정 항목만 의존 순서로 진행 (차이만 작업). 일치 항목은 손대지 않음.
 
-**데모 골격 보존**: 작업 대상 매핑 파일이 데모 골격(sd-demo 산출물)이면 골격 구조 유지하며 차이만 보강.
+**데모 골격 보존**: 작업 대상 매핑 파일이 데모 골격(sd-demo 산출물)이면 골격 구조를 유지하며 차이만 보강.
 
-각 항목 시작 시 **테스트 작성 가능 여부** 판정 (3-C 의 테스트 환경 이용):
+각 항목 시작 시 **테스트 작성 가능 여부**를 판정 (3-C 의 테스트 환경 이용):
 
 | 분류               | 적용 대상                                     | 사이클                 |
 | ------------------ | --------------------------------------------- | ---------------------- |
@@ -140,22 +140,22 @@ spec 본문 수정이 필요한 경우(인라인 `[OPEN]` 해소·헤더 `[OPEN]
 
 **사이클 단계 정의**:
 
-- **RED**: 테스트만 작성 → 러너 실행 → 실패 확인. **구현 파일 손대지 않음.**
-- **GREEN**: 테스트 통과하는 **최소** 구현 → 러너 통과 확인.
-- **REFACTOR**: 중복·가독성·기존 패턴 정합 정리 → 러너 통과 유지. 정리할 게 없으면 스킵.
+- **RED**: 테스트만 작성 → 러너 실행 → 실패 확인. **구현 파일은 손대지 않음.**
+- **GREEN**: 테스트를 통과하는 **최소** 구현 → 러너 통과 확인.
+- **REFACTOR**: 중복·가독성·기존 패턴 정합 정리 → 러너 통과 유지. 정리할 것이 없으면 스킵.
 
-작업 사이클 중 spec 미정의·모호 분기 만나면 2단계 회귀.
+작업 사이클 중 spec 미정의·모호 분기를 만나면 2단계로 회귀.
 
 ### 6단계: spec 대조 (subagent 위탁)
 
-5단계 모든 항목 완료 후, 별도 subagent 에 위탁해 spec ↔ 현재 코드 전체를 독립 대조. 같은 LLM 셀프 검증의 표면 훑기 편향 제거.
+5단계의 모든 항목 완료 후, 별도 subagent 에 위탁해 spec ↔ 현재 코드 전체를 독립 대조. 같은 LLM 의 자체 검증에서 발생하는 표면적 확인 편향을 제거하는 목적.
 
-**대조는 단위 전체 대상.** 신규/갱신 무관, "이번 변경분만" 스코프 제한 없음.
+**대조는 작업 단위 전체를 대상으로 함.** 신규·갱신 호출 무관, "이번 변경분만" 식 스코프 제한 없음.
 
 #### subagent 호출
 
 - 도구: `Agent`.
-- `subagent_type`: `general-purpose` (추론·도메인 어휘 풀어 보고 필요해 read-only 에이전트 X).
+- `subagent_type`: `general-purpose` (추론·도메인 어휘 풀어 보고 필요해 read-only 에이전트 사용 안 함).
 - `description`: `sd-impl spec 대조`.
 - `prompt`: 아래 입력 패키지 (그대로 복사 후 `<…>` 부분만 채움).
 
@@ -181,9 +181,9 @@ sd-impl 의 spec ↔ 코드 독립 대조를 수행해줘.
 
 **작업**:
 
-1. spec.md 의 §<단위> 본문 + 참조 §5/§6/§7/§8/§9 항목을 다시 읽는다.
-2. 현재 구현 파일을 모두 읽는다.
-3. spec ↔ 코드를 항목 단위로 1:1 대조 (단위 전체 대상. "이번 변경분만" 스코프 제한 없음).
+1. spec.md 의 §<단위> 본문 + 참조 §5/§6/§7/§8/§9 항목을 다시 읽기.
+2. 현재 구현 파일을 모두 읽기.
+3. spec ↔ 코드를 항목 단위로 1:1 대조 (단위 전체 대상. "이번 변경분만" 식 스코프 제한 없음).
 4. 차이 발견 시 아래 3분류로 보고:
 
    - (a) **코드 위반**: spec 명확한데 코드가 빠뜨림·다름.
@@ -204,20 +204,20 @@ sd-impl 의 spec ↔ 코드 독립 대조를 수행해줘.
 
 **제약**:
 
-- 보고 본문에 코드 식별자(변수명·SQL 함수명·타입 키워드 등) 노출 금지. 모두 도메인 어휘로 풀 것.
-- "코드가 spec 위반" 으로 단정 금지. 3분류 중 어디인지 명시.
-- spec 본문에 인용 가능한 문구가 없으면 (b)(d) 후보.
+- 보고 본문에 코드 식별자(변수명·SQL 함수명·타입 키워드 등) 노출 금지. 모두 도메인 어휘로 풀어 쓸 것.
+- "코드가 spec 위반" 으로 단정 금지. 3분류 중 어디에 해당하는지 명시.
+- spec 본문에 인용할 수 있는 문구가 없으면 (b)(d) 후보로 처리.
 
 **산출**: 위 3분류 보고 목록 또는 `차이 없음, 검증 통과`.
 ````
 
 #### 결과 처리
 
-subagent 출력을 받은 후 분류별 처리:
+subagent 출력을 받은 후 분류별로 처리:
 
-- **(a) 코드 위반**: 5단계 사이클 재진입. 코드 수정.
+- **(a) 코드 위반**: 5단계 사이클로 재진입하여 코드 수정.
 - **(b) spec 내부 모순**: 사용자에게 1건씩 보고 (모순 양쪽 인용 + 어느 쪽이 합리적인지 의견) → 처리 방향 묻기 (spec 수정 / 코드 정정) → spec 수정 시 2단계 "spec 수정 절차" 적용.
-- **(d) spec 미정의 + 코드 임의 채움**: 사용자에게 1건씩 질문 → 결정 받기 → 2단계 "spec 수정 절차" (인라인 결정 반영) → 5단계 사이클 재진입.
+- **(d) spec 미정의 + 코드 임의 채움**: 사용자에게 1건씩 질문 → 결정 수령 → 2단계 "spec 수정 절차" 로 인라인 결정 반영 → 5단계 사이클 재진입.
 
 (b)(d) 모두 한꺼번에 묶음 보고 금지. 1건씩 합의.
 
@@ -225,37 +225,37 @@ subagent 출력을 받은 후 분류별 처리:
 
 ### 7단계: 코드 정리
 
-spec 에 없는 기능·옵션·추상화 추가 금지(YAGNI).
+spec 에 없는 기능·옵션·추상화 추가 금지 (YAGNI 원칙: 필요해질 때까지 만들지 않음).
 
-- **횡단 중복**: 작업 사이클 사이 흩어진 동일 로직 합치기.
-- **계층별 정합 점검**: 3-B 의 기준 단위 + 보강 출처 파일을 다시 Read 해 4계층별로 실제 작성분과 비교. 한 계층이라도 채택 패턴과 어긋나면(임의 변형·새 발명) 수정.
+- **횡단 중복**: 작업 사이클 사이에 흩어진 동일 로직 합치기.
+- **계층별 정합 점검**: 3-B 의 기준 단위 + 보강 출처 파일을 다시 Read 하여 4계층별로 실제 작성분과 비교. 한 계층이라도 채택 패턴과 어긋나면(임의 변형·새 발명) 수정.
   - 도메인 모델: 필드·타입·제약·네이밍 패턴 일치.
   - 데이터 접근: 함수 시그니처·쿼리 패턴·에러 처리 일치.
   - 본체: 컴포넌트·트리거·처리 단계·핸들러·의존성 패턴 일치.
   - 테스트: 러너·assertion·mock 패턴 일치.
-- **불필요한 코드**: 미사용 import·변수·주석, 요구 없는 옵션·추상화 제거. 작업 결과로 어디서도 참조되지 않는 파일도 포함 (검사 범위는 전체 워크스페이스). **단 파일 단위 삭제는 후보 목록을 사용자에게 보고 → 확정분만 삭제** (dynamic import·마이그레이션·문서 자산 등 보존분 사용자 제외).
-- **매뉴얼 권위 규약**: 3-A Read 한 매뉴얼 위반 항목 수정.
+- **불필요한 코드**: 미사용 import·변수·주석, 요구가 없는 옵션·추상화 제거. 작업 결과로 어디서도 참조되지 않는 파일도 포함 (검사 범위는 전체 워크스페이스). **단 파일 단위 삭제는 후보 목록을 사용자에게 보고 → 확정분만 삭제** (dynamic import·마이그레이션·문서 자산 등 보존 대상은 사용자가 제외 지시).
+- **매뉴얼 권위 규약**: 3-A 에서 Read 한 매뉴얼 위반 항목 수정.
 
-정리 후 단위 테스트 재실행 — 회귀 없음 확인.
+정리 후 단위 테스트 재실행하여 회귀 없음을 확인.
 
 ### 8단계: 시연 검증
 
 사용자에게 요청: "**dev 서버**를 실행하고 접속 주소를 알려달라."
 
-**dev 서버·외부 프로세스 자체 실행 금지**: assistant 가 직접 `ng serve`·`npm run dev`·`vite`·`pnpm dev` 등으로 dev 서버를 띄우지 않음. 사용자가 띄워 주소를 회신할 때까지 대기. 사용자가 본 단계 스킵을 지시하거나 시연 불가 환경이 명시되면 본 단계 스킵 후 9단계.
+**dev 서버·외부 프로세스 자체 실행 금지**: assistant 가 직접 `ng serve`·`npm run dev`·`vite`·`pnpm dev` 등으로 dev 서버를 띄우지 않음. 사용자가 띄워 주소를 회신할 때까지 대기. 사용자가 본 단계의 스킵을 지시하거나 시연 불가 환경이 명시되면 본 단계 스킵 후 9단계 진입.
 
-주소 회신 후 `playwright-cli` 로 §4.x/§5.x/§6.x 동작 시나리오 직접 시연:
+주소 회신 후 `playwright-cli` 로 §4.x/§5.x/§6.x 동작 시나리오를 직접 시연:
 
-- 기능 개요·동작 사용자 흐름 1회씩 수행.
-- 화면 항목·와이어프레임 위치와 실제 렌더 비교.
+- 기능 개요·동작의 사용자 흐름을 1회씩 수행.
+- 화면 항목·와이어프레임 위치와 실제 렌더 결과를 비교.
 - §5.x (자동 처리) 는 트리거 발생 → 결과 확인.
 - §6.x (횡단 처리) 는 부수효과 트리거 동작 발동 → 결과·기록 확인.
 
-회귀 발견 시 5단계 회귀 → 수정 → 재시연.
+회귀 발견 시 5단계로 회귀 → 수정 → 재시연.
 
 ### 9단계: 완료 보고
 
-- 대상 spec.md 의 해당 §4.x / §5.x / §6.x 헤더 `[확정: YYYY-MM-DD]` 를 `[확정: YYYY-MM-DD, 구현: YYYY-MM-DD]` 로 확장. 이미 `, 구현: …` 가 들어있으면 그 날짜만 갱신. 날짜 = Bash `date +%Y-%m-%d`.
-- 만들거나 갱신한 파일 목록 보고 (마커 부착한 spec.md 포함).
+- 대상 spec.md 의 해당 §4.x / §5.x / §6.x 헤더 `[확정: YYYY-MM-DD]` 를 `[확정: YYYY-MM-DD, 구현: YYYY-MM-DD]` 로 확장. 이미 `, 구현: …` 가 들어있으면 그 날짜만 갱신. 날짜는 PowerShell `Get-Date -Format "yyyy-MM-dd"` 로 취득.
+- 만들거나 갱신한 파일 목록 보고 (마커를 부착한 spec.md 포함).
 - 본 세션에서 2단계·6단계 "spec 수정 절차" 로 의존 §4.x/§5.x/§6.x 마커가 제거된 항목이 있으면 영향 단위 목록 보고 (재구현 필요 알림). 없으면 생략.
-- 시연에서 사용자 확인 끝나면 종료.
+- 시연에서 사용자 확인이 끝나면 종료.

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

@@ -11,7 +11,7 @@ description: 산출물(코드·문서 등) 을 적용 룰 기준으로 검증해
 
 2. **작업 도메인 명시** — 대상이 어떤 도메인의 산출물인가 식별 (예: LLM 문서 / 사람 문서 / UI / 코드).
 
-3. **적용 룰 인용** — 도메인의 적용 룰 인용 (sd-base-rules·sd-design-rules·도메인별 룰 등). 룰 항목 직접 표기.
+3. **적용 룰 인용** — 도메인의 적용 룰 인용 (sd-base-rules·sd-design-rules·스킬·도메인별 룰 등). 룰 항목 직접 표기.
 
 4. **룰 부합 검증** — 대상이 인용 룰에 부합하는가 점검. 위반 항목 식별.
 
@@ -20,14 +20,14 @@ description: 산출물(코드·문서 등) 을 적용 룰 기준으로 검증해
    | 판정 | 기준 |
    | --- | --- |
    | `[자동]` 화이트리스트 | 오타·맞춤법·띄어쓰기·조사 오용·들여쓰기/줄바꿈 통일·trailing whitespace·중복 제거 등 형식 정리 |
-   | `[자동]` 의미·범위 변동 없음 | 변경 전후 의미·적용 범위가 동일함이 명백한 표현 정리 |
-   | 결정 대상 | 위 자동 분기 어디에도 해당하지 않는 모든 항목 (의미·적용 범위 변동 가능성이 조금이라도 있음) |
+   | `[자동]` 의미·범위 변동 없음 | 변경 전후의 의미·적용 범위가 동일함이 명백한 표현 정리 |
+   | 결정 대상 | 위 `[자동]` 판정 두 종류 어디에도 해당하지 않는 모든 항목 (의미·적용 범위가 변동될 가능성이 조금이라도 있음) |
 
-6. **자동 적용 실행** — `자동 적용` 분류 항목을 즉시 변경.
+6. **자동 적용 실행** — `[자동]` 판정 항목을 즉시 변경.
 
-7. **보고** — 모든 발견 사항 나열. 자동 적용 항목과 결정 대상을 분리 표기.
-   - 각 항목 필수 필드: 제목, 적용 룰 (출처 인용), 판정.
-   - 자동 적용 항목: `[자동]` 마커 (변경 완료).
-   - 결정 대상: 마커 없음.
+7. **보고** — 모든 발견 사항을 나열. `[자동]` 판정 항목과 결정 대상 항목을 분리 표기.
+   - 각 항목의 필수 필드: 제목, 적용 룰 (출처 인용), 판정.
+   - `[자동]` 판정 항목: `[자동]` 마커 표기 (변경 완료).
+   - 결정 대상 항목: 마커 없음.
 
-8. **결정 진행 모드 전환** — 결정 대상이 1건 이상이면 sd-base-rules 결정 진행 모드로 전환 (사용자 트리거 대기 X). 0건이면 종료.
+8. **결정 진행 모드 전환** — 결정 대상이 1건 이상이면 `sd-base-rules.md` 의 "사용자 질의 시" 섹션이 정의한 결정 진행 모드로 전환 (사용자 트리거 대기 금지). 0건이면 종료.

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

@@ -5,9 +5,9 @@ description: 사용자가 정의한 작업 도메인을 SKILL.md + (필요 시)
 
 # 스킬 작성
 
-워크플로 = 아래 § 1~5 순서. 처음부터 끝까지 읽으며 그대로 수행.
+워크플로 = 아래 "1단계 ~ 5단계" 순서로 처음부터 끝까지 읽으며 그대로 수행.
 
-사용자 질문 시점 = § 1 의도 합의 + § 2 case `input` 발화 선택. § 2~5 의 그 외는 § 1 합의 기반 자동 진행, 부족 발견 시 § 1 회귀.
+사용자에게 질문하는 시점 = 1단계(의도 정의)의 의도 합의 + 2단계(Eval 케이스 정의)의 case `input` 발화 선택. 2~5단계의 그 외 작업은 1단계 합의를 기반으로 자동 진행, 부족 발견 시 1단계로 회귀.
 
 ## 1단계. 의도 정의
 
@@ -15,7 +15,7 @@ description: 사용자가 정의한 작업 도메인을 SKILL.md + (필요 시)
 
 - 스킬 목적은? (한 줄 동사형) + 커버 유즈케이스는?
 - 주요 사용자 입력 시나리오는? (호출 트리거 발화 형태)
-- 핵심 산출물은? (생성·수정 대상 파일·디렉토리 형태) — § 2 rubric 형식 검증 근거
+- 핵심 산출물은? (생성·수정 대상 파일·디렉토리 형태) — 2단계(Eval 케이스 정의)의 rubric 형식 검증 근거
 - 실행 스크립트 필요 / 지침만으로 충분?
 - 함께 포함할 참고 자료?
 
@@ -25,23 +25,23 @@ description: 사용자가 정의한 작업 도메인을 SKILL.md + (필요 시)
 
 ### 자동답변 환경
 
-Eval 실행 시 사용자 응답 불가. 대상 스킬은 입력 필요 시점마다 **스스로 답변**하며 끝까지 진행 (대화 흐름·산출물 형식 검증용). 케이스 설계는 이 제약 전제.
+Eval(자동 평가) 실행 시 사용자 응답 불가. 대상 스킬은 입력 필요 시점마다 **스스로 답변**하며 끝까지 진행 (대화 흐름·산출물 형식 검증용). 케이스 설계는 이 제약을 전제로 함.
 
-- `input` = 1턴 사용자 발화. 후속 응답 가정 X.
-- rubric = 자체 답변 가능 영역만 검증: 산출물 존재/형식/구조·흐름 진행 여부·frontmatter 키 등. *"사용자가 X 를 골랐을 때 Y 가 나오는가"* 처럼 특정 사용자 응답 값 의존 항목 금지 (자체 답변값은 매번 다름).
-- **사용자 응답 발생 자체 의존 rubric 금지**: 대상 스킬이 "사용자 질문"·"OPEN 처리/대기"·"임의 채움 금지" 룰 보유해도, 룰 발현 자체는 Eval 검증 불가. 자동답변 환경은 사용자 답변 즉시 생성·진행 → "사용자 질문/대기" 흐름 본질적으로 미발생.
+- `input` = 1턴 사용자 발화. 후속 응답 가정 안 함.
+- rubric(채점 항목) = 자체 답변 가능 영역만 검증: 산출물 존재 여부·형식·구조, 흐름 진행 여부, frontmatter 키 존재 여부 등. *"사용자가 X 를 골랐을 때 Y 가 나오는가"* 처럼 특정 사용자 응답 값에 의존하는 항목 금지 (자체 답변값은 매번 달라짐).
+- **사용자 응답 발생 자체에 의존하는 rubric 금지**: 대상 스킬이 "사용자 질문"·"OPEN 처리/대기"·"임의 채움 금지" 룰을 보유해도, 룰 발현 자체는 Eval 검증 불가. 자동답변 환경은 사용자 답변을 즉시 생성·진행 → "사용자 질문/대기" 흐름 본질적으로 발생하지 않음.
   - ❌ `"사용자에게 질문하거나 OPEN 처리하는 흐름이 등장하는가"` (자체 답변으로 채운 뒤 진행 = 위반 아니라 환경 정상 동작).
   - ❌ `"임의 채움 흔적이 없는가"` (자체 답변 자체가 "임의 채움" 으로 보임).
   - 대응: 케이스 재설계 또는 `input` 본문에 룰 강조 명시 (예: "모호 발견 시 보류 마커만 산출물에 박고 종료").
-- fixture = 자체 답변 미차단되게 구성. 외부 시크릿·실시간 API 없이 진행 가능한 초기 상태로.
+- fixture = 자체 답변이 차단되지 않게 구성. 외부 시크릿·실시간 API 없이 진행 가능한 초기 상태로.
 
 ### 근거 제약
 
-Eval 입력/rubric 의 근거 = **§ 1 에서 합의된 의도뿐**. 이전 버전 동작·대화 메모리의 옛 컨텍스트, **타 스킬의 `evals/golden.jsonl` rubric** 인용 금지.
+Eval 입력 및 rubric 의 근거 = **1단계(의도 정의)에서 합의된 의도뿐**. 이전 버전 동작·대화 메모리의 옛 맥락, **타 스킬의 `evals/golden.jsonl` rubric** 인용 금지.
 
-- 합의된 의도에 없는 동작 → 입력·rubric 둘 다 등장 X.
-- "이전 버전과 다르게 X 하는가" negative rubric 금지. 현재 의도상 X 요구 → `"X 하는가"` 로 직접 검증.
-- **타 스킬 rubric 답습 금지**: 비슷한 도메인 스킬이라도 rubric 은 본 스킬 § 1 에서 합의된 의도에서 직접 도출. 타 스킬 rubric 을 참고용으로 열어보는 것도 X (복제 유혹 차단).
+- 합의된 의도에 없는 동작은 입력·rubric 둘 다 등장 금지.
+- "이전 버전과 다르게 X 하는가" 형태의 부정형(negative) rubric 금지. 현재 의도상 X 가 요구되면 `"X 하는가"` 로 직접 검증.
+- **타 스킬 rubric 답습 금지**: 비슷한 도메인의 스킬이라도 rubric 은 본 스킬의 1단계에서 합의된 의도에서 직접 도출. 타 스킬 rubric 을 참고용으로 열어보는 것도 금지 (복제 유혹 차단).
 
 ### 골든 케이스
 
@@ -52,22 +52,22 @@ Eval 입력/rubric 의 근거 = **§ 1 에서 합의된 의도뿐**. 이전 버
 ```
 
 - `id`: 케이스 식별자.
-- `input`: 평가 대상 스킬에 전달할 사용자 입력. § 1 시나리오 기반으로 LLM 이 발화 후보 제시 → 사용자 선택.
+- `input`: 평가 대상 스킬에 전달할 사용자 입력. 1단계의 시나리오를 기반으로 LLM 이 발화 후보를 제시한 뒤 사용자가 선택.
 - `rubric`: PASS/FAIL 판정 항목 목록.
-- `fixture`: 케이스 시작 시점 샌드박스 초기 상태 디렉토리 이름.
+- `fixture`: 케이스 시작 시점의 샌드박스 초기 상태 디렉토리 이름.
 
-**케이스 크기**: 한 케이스 작업량이 단일 실행 컨텍스트 소진 정도로 크면 X. Eval = 흐름·산출물 형식 검증 목적 → 풀 구현·대량 분석 요구 input 회피, 최소 시연 수준으로 좁힘. 본질이 큰 풀구현 스킬은 input 의 평가 환경 단서로 rubric 검증에 불필요한 워크플로 단계를 명시 스킵.
+**케이스 크기**: 한 케이스의 작업량이 단일 실행 컨텍스트를 소진할 정도로 크면 안 됨. Eval 목적 = 흐름·산출물 형식 검증 → 풀 구현·대량 분석을 요구하는 input 은 회피하고 최소 시연 수준으로 좁힘. 본질이 큰 풀 구현 스킬의 경우, input 에 평가 환경임을 알리는 단서를 포함해 rubric 검증에 불필요한 워크플로 단계를 명시적으로 건너뛰게 함.
 
 ### Rubric 작성
 
-각 항목 = **PASS/FAIL 판정 가능한 명확한 검증 항목**. 추상 표현 → judge 판단 흔들림 → 회피.
+각 항목은 **PASS/FAIL 판정이 가능한 검증 항목**으로 작성. 추상 표현은 judge(채점 에이전트) 판단이 흔들리므로 회피.
 
 **모호 부사·형용사 회피** ("잘"·"적절히"·"합리적으로"·"명확히" → 기준이 사람마다 다름):
 
 - ❌ `"한국어 지원이 잘 되었는가?"` ("잘" 모호).
 - ✅ `"본문에 한국어 응답 강제 지시가 명시적 문장으로 들어갔는가?"`.
 
-**형식 검증 선호** (의미보다 형식·존재 여부 → judge 흔들림 ↓):
+**형식 검증 선호** (의미보다 형식·존재 여부 기준으로 작성하면 judge 흔들림이 줄어듦):
 
 - ❌ `"description 이 트리거 조건을 명확히 표현하는가?"`.
 - ✅ `"description 끝에 'Use when ~' 형식 문장이 포함되었는가?"`.
@@ -77,36 +77,36 @@ Eval 입력/rubric 의 근거 = **§ 1 에서 합의된 의도뿐**. 이전 버
 - ✅ `"기존 .claude/skills/review/SKILL.md 파일이 손실되지 않고 보존되었는가?"`.
 - ✅ `"SKILL.md frontmatter 에 name·description 키 모두 존재하는가?"`.
 
-**명세 어휘 매칭 금지**: 명세 특정 단어를 rubric 에 그대로 박아 정확 매칭 요구 X. LLM 응답은 동의어·다른 표현으로 동일 본질 전달 → 어휘 정확 매칭 = 본질-무관 FAIL 양산. rubric 은 본질(형식·구조·존재 여부)만 검증.
+**명세 어휘 매칭 금지**: 명세의 특정 단어를 rubric 에 그대로 박아 정확 매칭을 요구하지 말 것. LLM 응답은 동의어·다른 표현으로 동일 본질을 전달하므로, 어휘 정확 매칭은 본질과 무관한 FAIL 을 양산함. rubric 은 본질(형식·구조·존재 여부)만 검증.
 
 - ❌ `"분해 표 첫 컬럼이 '항목' 인가"` (LLM 이 'ID'·'식별자' 로 출력해도 본질 동일).
 - ✅ `"분해 표가 마크다운 표 형식으로 출력되고 컬럼 6개 모두 존재하는가"`.
 
-**도구명 매칭 금지**: "events 에 특정 도구(Glob/Grep/Read 등) 호출이 있는가" 는 그 도구 사용 자체가 본질일 때만. 본질이 "탐색·조사·읽기" 등 행위면 동등 효과의 다른 도구(Bash 의 ls/find/dir/cat 등) 도 PASS.
+**도구명 매칭 금지**: "events(에이전트 이벤트 시퀀스)에 특정 도구(Glob/Grep/Read 등) 호출이 있는가" 형태의 rubric 은 그 도구 사용 자체가 본질일 때만 사용. 본질이 "탐색·조사·읽기" 등 행위라면 동등한 효과를 내는 다른 도구(Bash 의 ls/find/dir/cat 등)도 PASS 로 인정.
 
 - ❌ `"events 에 Glob 또는 Grep 호출이 1회 이상 있는가"` (Bash ls/find 로 동등 효과인데 FAIL).
 - ✅ `"events 에 코드베이스 탐색 흔적(Glob·Grep 호출 또는 Bash 의 ls/find/dir 등 동등 명령) 이 1회 이상 있는가"`.
 
 ### Fixtures
 
-`evals/fixtures/<name>/` = 케이스 시작 시점 샌드박스 초기 상태. 케이스 실행 시 통째로 샌드박스 복사.
+`evals/fixtures/<name>/` 디렉토리는 케이스 시작 시점의 샌드박스 초기 상태. 케이스 실행 시 샌드박스로 통째로 복사됨.
 
-- **빈 워크스페이스**: 디렉토리만 (`.gitkeep` 등 자리 표시).
-- **기존 스킬 수정 케이스**: 그 스킬의 SKILL.md + 관련 파일 미리 배치.
+- **빈 워크스페이스**: 디렉토리만 둠 (`.gitkeep` 등으로 자리 표시).
+- **기존 스킬 수정 케이스**: 그 스킬의 SKILL.md 및 관련 파일을 미리 배치.
 
-예: `with-existing-review/.claude/skills/review/SKILL.md` — 케이스 시작 시 review 스킬 기존 존재 상태.
+예: `with-existing-review/.claude/skills/review/SKILL.md` — 케이스 시작 시 review 스킬이 이미 존재하는 상태.
 
 ### 케이스 커버리지
 
-골든 셋이 단순 PASS 외 다음 분기 커버 시 회귀 감지 강화:
+골든 셋이 단순 PASS 외에 다음 분기를 커버하면 회귀 감지가 강화됨:
 
-- 신규 작성 / 기존 수정 각각.
+- 신규 작성 케이스와 기존 수정 케이스 각각.
 - 워크플로 주요 분기점 (예: 스크립트 필요/불필요, 참조 파일 분리 필요/불필요).
-- 과거 실패 패턴 — FAIL 케이스 reason 분석 후 재발 방지용 추가.
+- 과거 실패 패턴 — FAIL 케이스의 reason(실패 사유)을 분석한 뒤 재발 방지용으로 추가.
 
 ## 3단계. 스킬 작성
 
-간결·명확한 SKILL.md + 별도 참고 파일 (필요 시) + 유틸리티 스크립트 (필요 시).
+간결·명확한 SKILL.md 와 별도 참고 파일(필요 시), 유틸리티 스크립트(필요 시)로 구성.
 
 ### 디렉토리 구조
 
@@ -138,9 +138,9 @@ description: 기능 설명. Use when [활용상황]
 
 본문은 다음 "본문 작성 원칙" 따름.
 
-### description
+### description (frontmatter 의 description 필드)
 
-에이전트의 라우팅 진입점. 에이전트가 description 으로 사용자 요청에 맞는 스킬 호출.
+에이전트의 라우팅 진입점. 에이전트가 description 을 보고 사용자 요청에 맞는 스킬을 호출함.
 
 **전달 정보**:
 
@@ -150,47 +150,47 @@ description: 기능 설명. Use when [활용상황]
 
 **형식**:
 
-- 최대 200자, 한 줄.
-- 3인칭.
-- 첫 문장: 입력 → 산출물(또는 효과). 내부 처리 단계 금지.
-- 두 번째 문장: "Use when [활용상황]".
+- 최대 200자, 한 줄로 작성.
+- 3인칭으로 작성.
+- 첫 문장: 입력에서 산출물(또는 효과)로의 변환을 기술. 내부 처리 단계 기술 금지.
+- 두 번째 문장: "Use when [활용상황]" 형식.
 
-**금지**: 내부 단계·알고리즘·사용 도구·로직 흐름 → SKILL.md 본문 워크플로의 몫. description 은 외부 관찰 경계(입력·산출물·트리거)만 노출.
+**금지**: 내부 단계·알고리즘·사용 도구·로직 흐름은 SKILL.md 본문 워크플로의 몫. description 은 외부에서 관찰 가능한 경계(입력·산출물·트리거)만 노출.
 
 ### 본문 작성 원칙
 
-YAGNI — § 2 케이스가 통과되는 최소 본문만. 케이스가 검증하지 않는 절·예시·옵션 추가 X.
+YAGNI(You Aren't Gonna Need It) 원칙 — 2단계 케이스가 통과되는 최소 본문만 작성. 케이스가 검증하지 않는 절·예시·옵션 추가 금지.
 
-- **워크플로 단위 어휘 통일**: "사이클" (반복형) 또는 "단계" (순차형) 중 선택해 본문 전체 일관.
-- **본문 어휘 일관**: 같은 개념은 같은 단어로. 동의어 혼용 X.
-- **자가검증 게이트** (해당 시): 출력 직전 자문 항목을 본문에 명시 — 스킬 고유 형식·근거·단순화 차단 점검.
-- **모범 예시 인용** (해당 시): 형식 따라야 할 산출물 있으면 `references/example-X.md` 보관 + 본문에서 한 줄 참조.
-- **도구명 박기 금지**: 본문에 Glob·Grep 등 도구명 직접 박지 X. "코드베이스 탐색"·"파일 읽기" 등 동등 행위 표현 (§ 2 rubric "도구명 매칭 금지" 와 일관).
+- **워크플로 단위 어휘 통일**: "사이클"(반복형) 또는 "단계"(순차형) 중 하나를 선택해 본문 전체에서 일관 사용.
+- **본문 어휘 일관**: 같은 개념은 같은 단어로 표기. 동의어 혼용 금지.
+- **스스로 검증 게이트**(해당 시): 출력 직전 자문 항목을 본문에 명시하여 스킬 고유의 형식·근거·단순화 차단을 점검.
+- **모범 예시 인용**(해당 시): 형식을 따라야 할 산출물이 있으면 `references/example-X.md` 에 보관하고 본문에서 한 줄로 참조.
+- **도구명 박기 금지**: 본문에 Glob·Grep 등 도구명을 직접 박지 않음. "코드베이스 탐색"·"파일 읽기" 등 동등한 행위 표현으로 작성 (2단계 rubric 의 "도구명 매칭 금지" 와 일관).
 
 ### 스크립트 추가 기준
 
-다음 시 유틸리티 스크립트 추가:
+다음 조건에 해당하면 유틸리티 스크립트 추가:
 
-- 동작이 결정론(deterministic)적 (validation·formatting).
-- 코드 생성이 매번 동일.
-- 에러 명시 처리 필요.
+- 동작이 결정론적(deterministic)인 경우 (validation·formatting 등).
+- 코드 생성 결과가 매번 동일한 경우.
+- 에러를 명시적으로 처리해야 하는 경우.
 
-스크립트 → 토큰 절약 + 안정성 개선.
+스크립트는 토큰 절약과 안정성 개선에 기여.
 
 **작성 원칙**:
 
 - Python(`.py`) 으로 작성.
-- 내부 에러 처리 X. 에러 즉시 throw.
+- 내부 에러 처리 금지. 에러는 즉시 throw.
 
 ### 파일 분리 기준
 
-다음 시 별도 파일 분리:
+다음 조건에 해당하면 별도 파일로 분리:
 
-- SKILL.md 분량이 에이전트가 한 자리에서 워크플로 흐름 인식 어려울 만큼 누적.
-- 명백히 다른 도메인.
-- 거의 안 쓰는 고급 기능.
+- SKILL.md 분량이 에이전트가 한 자리에서 워크플로 흐름을 인식하기 어려울 만큼 누적된 경우.
+- 명백히 다른 도메인을 다루는 경우.
+- 거의 사용되지 않는 고급 기능인 경우.
 
-**참조 깊이 한 단계**: SKILL.md → `references/X.md` 까지만. references 파일 안에서 또 다른 파일 참조 X.
+**참조 깊이 한 단계 제한**: SKILL.md 에서 `references/X.md` 까지만 참조 허용. references 파일 안에서 또 다른 파일을 참조하는 것 금지.
 
 ## 4단계. Eval 실행
 
@@ -198,48 +198,48 @@ YAGNI — § 2 케이스가 통과되는 최소 본문만. 케이스가 검증
 
 `python .claude/skills/sd-skill/scripts/run_eval.py <대상-스킬-이름>`.
 
-대상 스킬에 `evals/golden.jsonl` + `evals/fixtures/<fixture-name>/` 필요.
+대상 스킬에 `evals/golden.jsonl` 과 `evals/fixtures/<fixture-name>/` 가 모두 존재해야 함.
 
 ### 동작
 
-케이스마다:
+케이스마다 다음 순서로 실행:
 
-1. 격리 작업 공간 준비 (`.claude/` 복사 + fixture 오버레이).
-2. 대상 스킬 실행. `EVAL_MODE_PREFIX` 가 사용자 입력 앞에 붙어, 대상 스킬이 입력 필요 시점마다 스스로 답변하며 끝까지 진행하도록 지시. 자체 답변은 사용자 명시 발언과 동등 취급 (다이얼로그 기반 스킬도 평가 가능, 단 자체 답변이라 흐름·형식 검증용).
-3. 에이전트 동작 기록 + 종료 시점 파일 트리 수집.
-4. 별도 평가 에이전트가 rubric 항목별 PASS/FAIL 채점 → 모두 PASS 시 케이스 PASS.
+1. 격리 작업 공간 준비 (`.claude/` 복사 후 fixture 오버레이).
+2. 대상 스킬 실행. `EVAL_MODE_PREFIX`(자동 평가 모드 안내 문구)가 사용자 입력 앞에 붙어, 대상 스킬이 입력 필요 시점마다 스스로 답변하며 끝까지 진행하도록 지시. 자체 답변은 사용자의 명시적 발언과 동등하게 취급됨 (다이얼로그 기반 스킬도 평가 가능. 단, 자체 답변이므로 흐름·형식 검증용으로 한정).
+3. 에이전트 동작 기록 및 종료 시점의 파일 트리 수집.
+4. 별도의 평가 에이전트가 rubric 항목별로 PASS/FAIL 을 채점하고, 모든 항목이 PASS 일 때 케이스 PASS 로 판정.
 
 ### 출력 구조
 
-stdout: summary JSON.
+stdout 으로 summary JSON 출력. 포함 필드는 다음과 같음.
 
 - `run_id`, `results_dir`.
-- `summary`: total / pass / fail / error.
-- `cases[]`: 케이스별 verdict + 결과 dir 경로.
+- `summary`: total / pass / fail / error 카운트.
+- `cases[]`: 케이스별 verdict(판정 결과)와 결과 디렉토리 경로.
 
 각 케이스 결과 파일 (`results_dir/cases/<id>/`):
 
-- `judge_output.json` — rubric 항목별 PASS/FAIL + reason.
+- `judge_output.json` — rubric 항목별 PASS/FAIL 판정과 reason(사유).
 - `events.json` — 에이전트 이벤트 시퀀스.
-- `tree.json` — 샌드박스 종료 시 파일 트리.
+- `tree.json` — 샌드박스 종료 시점의 파일 트리.
 
 ## 5단계. 개선 및 리뷰
 
 ### FAIL 처리
 
-- 보고: 전체 PASS/FAIL 카운트 + FAIL 케이스 목록.
-- FAIL reason 분석:
-  - 결과 파일 (`judge_output.json`·`events.json`·`tree.json`) 읽기.
-  - 스킬/Eval 어느 쪽 문제인지 판단:
-    - **스킬 측**: 본문 명세대로 동작해도 FAIL → 명세 빈/모호 → 본문 보강.
-    - **Eval 측**: 본문 명세 만족하는데 rubric 이 본질 외(어휘 매칭·도구명 매칭 등) 으로 FAIL → rubric 수정 (§ 2 rubric 안티패턴 인용).
-    - **모호 시**: 사용자 질문.
-- 수정 → 같은 골든 셋 전체 § 4 재실행.
-- **수렴 한도**: 같은 케이스 3회 연속 FAIL 시 진행 중단 + 사용자 보고 (무한 루프 방지).
-- 새 실패 패턴은 골든 셋에 케이스 추가.
+- 보고: 전체 PASS/FAIL 카운트와 FAIL 케이스 목록.
+- FAIL reason(실패 사유) 분석:
+  - 결과 파일(`judge_output.json`·`events.json`·`tree.json`) 읽기.
+  - 스킬 본문과 Eval rubric 중 어느 쪽 문제인지 판단:
+    - **스킬 측 문제**: 본문 명세대로 동작했는데도 FAIL → 명세가 비어있거나 모호함 → 본문 보강.
+    - **Eval 측 문제**: 본문 명세를 만족했는데 rubric 이 본질 외 요소(어휘 매칭·도구명 매칭 등)로 FAIL → rubric 수정 (2단계 rubric 안티패턴 참조).
+    - **모호한 경우**: 사용자에게 질문.
+- 수정 후 같은 골든 셋 전체로 4단계 재실행.
+- **수렴 한도**: 같은 케이스가 3회 연속 FAIL 시 진행 중단하고 사용자에게 보고 (무한 루프 방지).
+- 새로운 실패 패턴은 골든 셋에 케이스로 추가.
 
 ### 리뷰
 
-PASS 후 sd-review 호출. 적용 룰: sd-base-rules + § 3 본문 작성 원칙·파일 분리 기준.
+전 케이스 PASS 후 sd-review 호출. 적용 룰: sd-base-rules 와 3단계의 "본문 작성 원칙"·"파일 분리 기준".
 
-수정 시 § 4 재실행.
+리뷰 결과로 수정 발생 시 4단계 재실행.

package/claude/skills/sd-skill/evals/fixtures/existing-skill/.claude/skills/todo-format/SKILL.md

@@ -7,7 +7,7 @@ description: 자유 형식 할일 텍스트를 마크다운 표로 변환한다.
 
 ## 1단계. 입력 파싱
 
-자유 형식 할일 라인 분해.
+자유 형식 할일을 줄 단위로 분해.
 
 ## 2단계. 표 출력