@simplysm/sd-claude 14.0.81 → 14.0.83

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

@@ -1,18 +1,18 @@
 ---
 name: sd-docs
-description: `@simplysm/*` 라이브러리 패키지의 API 문서를 `.claude/references/sd-simplysm14/apis/<패키지명>/` 자리에 사용 트리거 기준으로 산출·갱신. Use when 라이브러리 API 문서를 새로 작성하거나 코드 변경을 반영해 갱신할 때.
+description: `@simplysm/*` 라이브러리 패키지의 API 문서를 `.claude/references/sd-simplysm14/apis/<패키지명>/` 위치에 사용 트리거 기준으로 작성·갱신. Use when 라이브러리 API 문서를 새로 작성하거나 코드 변경을 반영해 갱신할 때.
 effort: "low"
 ---
 
 # sd-docs
 
-`@simplysm/*` 라이브러리 패키지의 API 문서를 코드 진실에 맞춰 산출·갱신함. 메인 에이전트가 패키지 목록 추출과 상위 README 인덱스 갱신을 담당하고, 패키지별 산출은 subagent 1개씩 병렬 위임함.
+`@simplysm/*` 라이브러리 패키지의 API 문서를 코드를 근거로 작성·갱신. 메인 에이전트가 패키지 목록 추출과 상위 README 인덱스 갱신을 담당하고, 패키지별 문서 작성은 패키지 1개당 subagent 1개를 호출해 병렬 위임.
 
-## 산출 자리
+## 산출물 위치
 
 - `.claude/references/sd-simplysm14/apis/<패키지명>/README.md` — 패키지당 1개, 필수.
-- `.claude/references/sd-simplysm14/apis/<패키지명>/<군명>.md` — 사용 트리거 군이 본질적으로 커서 README 한 장에 풀어쓰면 다른 컨텍스트 정보까지 끌려나오는 경우에만 분할 산출.
-- `.claude/references/sd-simplysm14/README.md` 의 "패키지 인덱스" 섹션 — 메인이 자동 갱신.
+- `.claude/references/sd-simplysm14/apis/<패키지명>/<군명>.md` — 사용 트리거 군이 커서 README 한 장에 풀어쓰면 같은 README 의 다른 군 정보까지 함께 읽혀 부담이 커지는 경우에만 분할 산출.
+- `.claude/references/sd-simplysm14/README.md` 의 "패키지 인덱스" 섹션 — 메인 에이전트가 갱신.
 
 ## 워크플로
 
@@ -25,7 +25,7 @@ effort: "low"
 
 ### 2. 패키지별 subagent 병렬 호출
 
-`public 리스트` 의 패키지 수만큼 `general-purpose` subagent 호출을 **단일 메시지 안에서 병렬**로 보냄. 각 호출 프롬프트는 [references/subagent-prompt.md](references/subagent-prompt.md) 의 양식을 그대로 사용하고, `<PACKAGE_NAME>` 과 `<PACKAGE_DIR>` 만 치환함.
+`public 리스트` 의 패키지 수만큼 `general-purpose` subagent 호출을 **단일 메시지 안에서 병렬**로 보냄. 각 호출 프롬프트는 [references/subagent-prompt.md](references/subagent-prompt.md) 양식의 "프롬프트" 마커 아래 본문을 그대로 사용하고, `<PACKAGE_NAME>` 과 `<PACKAGE_DIR>` 만 치환.
 
 각 subagent 의 산출 (풀 재작성 모드 — 기존 파일 참고 없이 처음부터 작성):
 
@@ -33,7 +33,7 @@ effort: "low"
 - 필요 시 `apis/<패키지명>/<군명>.md` 재작성. 코드에서 사라진 군의 파일은 삭제.
 - 결과 보고 1단락 (산출 파일 목록, 분할 발생 여부, 한 줄 트리거 요약).
 
-**범위 한정**: subagent 는 `apis/<패키지명>/` 자리만 다룸. 상위 `.claude/references/sd-simplysm14/README.md` 는 건드리지 않음 (메인 에이전트가 §3 에서 처리).
+**범위 한정**: subagent 는 `apis/<패키지명>/` 위치만 다룸. 상위 `.claude/references/sd-simplysm14/README.md` 는 건드리지 않음 (다음 단계의 "패키지 인덱스 섹션 갱신" 에서 메인 에이전트가 처리).
 
 ### 3. 상위 README 의 "패키지 인덱스" 섹션 갱신 (파일 보존 + 섹션 내 항목만 갱신)
 

package/claude/skills/sd-docs/references/subagent-prompt.md

@@ -1,52 +1,52 @@
 # subagent 호출 프롬프트 (sd-docs)
 
-메인 에이전트가 패키지 1개당 1번씩 `general-purpose` subagent 를 호출할 때 쓰는 프롬프트 양식이다. `<PACKAGE_NAME>` 과 `<PACKAGE_DIR>` 만 치환한다.
+메인 에이전트가 패키지 1개당 1번씩 `general-purpose` subagent 를 호출할 때 쓰는 프롬프트 양식. `<PACKAGE_NAME>` 과 `<PACKAGE_DIR>` 자리만 치환.
 
 ---
 
 ## 프롬프트 (이 마커 아래 전부를 그대로 subagent 에 전달)
 
-너는 `<PACKAGE_NAME>` 패키지(소스 위치: `<PACKAGE_DIR>/src/`)의 API 문서를 작성·갱신하는 subagent 다. 산출 자리는 `.claude/references/sd-simplysm14/apis/<PACKAGE_NAME 의 패키지명 부분>/` 이다(예: `@simplysm/foo` → `apis/foo/`). 아래 규칙을 따라 끝까지 진행한다.
+너는 `<PACKAGE_NAME>` 패키지(소스 위치: `<PACKAGE_DIR>/src/`)의 API 문서를 작성·갱신하는 subagent. 산출 자리는 `.claude/references/sd-simplysm14/apis/<PACKAGE_NAME 의 `@simplysm/` 접두사를 제외한 짧은 이름>/` (예: `@simplysm/foo` → `apis/foo/`). 아래 규칙을 끝까지 따름.
 
 ### 1. 입력 분석
 
-다음만 진실 근거로 사용한다 — 외부 자료·과거 git 기록·다른 패키지 사용처는 보지 않는다.
+다음만 진실 근거로 사용 — 외부 자료·과거 git 기록·다른 패키지의 사용처는 참조 금지.
 
 - `<PACKAGE_DIR>/src/index.ts` 의 export — **entry 시작점**. 여기서 노출된 심볼만 문서 대상.
 - 위 entry 가 재노출하는 각 심볼의 정의 파일(타입 시그니처 + 본문).
-- 위 정의 파일 또는 동일 패키지 안 파일의 JSDoc 주석.
-- `tests/` 디렉토리 중 해당 패키지를 import 해 검증하는 테스트 코드(있을 경우만).
+- 위 정의 파일 또는 동일 패키지 안의 다른 파일에 달린 JSDoc 주석.
+- `tests/` 디렉토리 중 해당 패키지를 import 해 검증하는 테스트 코드 (존재할 경우에만).
 
-타입 시그니처에서 직접 드러나지 않는 사용 패턴이 필요하면 위 4개 소스 안에서만 추론한다.
+타입 시그니처에서 직접 드러나지 않는 사용 패턴을 보강해야 하면 위 4개 소스 안에서만 추론.
 
 ### 2. 사용 트리거 군 분류
 
-entry 의 export 심볼들을 "한 작업 컨텍스트에서 함께 참조될 군"으로 묶는다. 예: 에러 처리 군, 값 타입 군, 큐/이벤트 군. 분류 기준은 폴더 구조나 심볼 종류가 아니라 **사용 시점**(언제 같이 읽힐 것인가)이다.
+entry 의 export 심볼들을 "한 작업 컨텍스트에서 함께 참조될 군"으로 묶음. 예: 에러 처리 군, 값 타입 군, 큐/이벤트 군. 분류 기준은 폴더 구조나 심볼 종류가 아니라 **사용 시점**(언제 같이 읽힐 것인가) 기준.
 
-군이 모호하거나 작아 트리거가 1~2개뿐인 심볼은 별도 군 만들지 말고 README 의 공통 인라인 항목에 둔다.
+군이 모호하거나 작아 트리거가 1~2개뿐인 심볼은 별도 군을 만들지 말고 README 의 공통 인라인 섹션에 배치.
 
 ### 3. 산출 단위 판정
 
-기본은 `README.md` 1장. 다음 조건을 **모두** 만족하는 군만 별도 `<군명>.md` 로 분할한다.
+기본은 `README.md` 1장. 다음 조건을 **모두** 만족하는 군만 별도 `<군명>.md` 로 분할.
 
-- 그 군의 사용법·주의사항을 README 에 풀어쓰면, 다른 컨텍스트 정보까지 같이 끌려나와 다른 작업 시점에서 읽는 부담이 커진다.
-- 그 군 단독으로 사용 예·시그니처·주의 8줄 이상 필요하다.
+- 해당 군의 사용법·주의사항을 README 에 풀어쓰면, 무관한 다른 컨텍스트 정보까지 같이 끌려나와 다른 작업 시점에서 읽기 부담이 커지는 경우.
+- 해당 군 단독으로 사용 예·시그니처·주의가 합쳐 8줄 이상 필요한 경우.
 
-위를 만족하지 않으면 README 안에 머무른다.
+위 조건을 만족하지 않으면 README 안에 유지.
 
 ### 4. 풀 재작성 모드 (범위: `apis/<패키지명>/` 자리만)
 
-- 기존 `apis/<패키지명>/README.md` 와 분할 `<군명>.md` 가 있어도 **참고하지 않고 처음부터 작성**한다. 코드 + 본 프롬프트 형식 룰(§5·§6·§7) 만을 진실 근거로 삼는다.
-- 기존 파일 내용·표현 보존 시도 금지. 룰 변경(예: 식별자 풀이 의무) 이 자동 반영되도록 매 호출마다 패키지별 산출물(README + 분할 `<군명>.md`)을 다시 만든다.
-- 결과적으로 코드가 안 바뀐 패키지도 표현이 달라질 수 있다 — 정상.
-- 코드에서 사라진 군의 분할 파일은 삭제한다.
-- **범위 밖**: 상위 `.claude/references/sd-simplysm14/README.md` 는 절대 건드리지 않는다 (메인 에이전트가 인덱스 섹션 항목만 갱신, subagent 와 무관).
+- 기존 `apis/<패키지명>/README.md` 와 분할 `<군명>.md` 가 있어도 **참고하지 않고 처음부터 작성**. 코드 + 본 프롬프트의 형식 룰(아래 README 형식 섹션·분할 .md 형식 섹션·작성 원칙 섹션) 만을 진실 근거로 삼음.
+- 기존 파일 내용·표현 보존 시도 금지. 룰 변경(예: 식별자 풀이 의무) 이 자동 반영되도록 매 호출마다 패키지별 산출물(README + 분할 `<군명>.md`) 을 다시 작성.
+- 결과적으로 코드가 변경되지 않은 패키지도 표현이 달라질 수 있음 — 정상.
+- 코드에서 사라진 군의 분할 파일은 삭제.
+- **범위 밖**: 상위 `.claude/references/sd-simplysm14/README.md` 는 건드리지 말 것 (메인 에이전트가 인덱스 섹션 항목만 갱신, subagent 와 무관).
 
 ### 5. README.md 형식
 
-각 패키지의 `apis/<패키지명>/README.md` 는 다음 구조를 따른다.
+각 패키지의 `apis/<패키지명>/README.md` 는 다음 구조를 따름.
 
-H1 은 `# @simplysm/<short-name>` 형식으로 고정한다 (예: `# @simplysm/foo`).
+H1 은 `# @simplysm/<short-name>` 형식으로 고정 (예: `# @simplysm/foo`).
 
 ```markdown
 # @simplysm/<short-name>
@@ -60,9 +60,9 @@ H1 은 `# @simplysm/<short-name>` 형식으로 고정한다 (예: `# @simplysm/f
 
 ## <인라인 군 이름 1>
 
-각 심볼별 짧은 시그니처 + 옵션/prop/필드/enum literal 1줄 풀이 + 즉시 사용 가능한 사용법. 본질적으로 큰 군이라 분할된 경우 이 섹션은 없고, 위 인덱스에서 `자세히:` 링크로 안내한다.
+각 심볼별로 짧은 시그니처 + 옵션·prop·필드·enum literal(열거형 리터럴 값) 1줄 풀이 + 즉시 사용 가능한 사용법을 작성. 본질적으로 큰 군이라 분할된 경우 이 섹션은 두지 않고, 위 인덱스에서 `자세히:` 링크로 안내.
 
-**식별자 풀이 의무**: 시그니처에 나오는 옵션·prop·필드·enum literal 각각에 1줄 풀이를 단다. 풀이 = `<무엇을 함>` + (enum/boolean 이면) `<값별 동작 차이>` + `<언제 쓰는지 단서 1조각>`. 이름만 나열은 금지.
+**식별자 풀이 의무**: 시그니처에 나오는 옵션·prop·필드·enum literal 각각에 1줄 풀이 부착. 풀이 구성 = `<무엇을 함>` + (enum/boolean 인 경우) `<값별 동작 차이>` + `<언제 쓰는지 단서 1조각>`. 이름만 나열하는 형식 금지.
 
 예 (나쁨/좋음):
 
@@ -83,9 +83,9 @@ inputs: selectMode, autoSelect: "click"|"focus", useAutoSort, focusMode: "row"|"
 
 ### 6. 분할 .md 형식
 
-`<군명>.md` 는 다음 구조.
+`<군명>.md` 는 다음 구조를 따름.
 
-분할 `.md` 의 H1 도 동일 형식 + 군명을 붙인다: `# @simplysm/<short-name> — <군명>`.
+분할 `.md` 의 H1 도 동일 형식 + 군명을 붙임: `# @simplysm/<short-name> — <군명>`.
 
 ```markdown
 # @simplysm/<short-name> — <군명>
@@ -94,7 +94,7 @@ inputs: selectMode, autoSelect: "click"|"focus", useAutoSort, focusMode: "row"|"
 
 ## <심볼>
 
-시그니처, 옵션/prop/필드/enum literal 1줄 풀이(위 §5 "식별자 풀이 의무" 동일 적용), 사용 예, 주의사항.
+시그니처, 옵션·prop·필드·enum literal 1줄 풀이(위 README 형식 섹션의 "식별자 풀이 의무" 와 동일 적용), 사용 예, 주의사항.
 
 ## <심볼>
 ...
@@ -102,17 +102,17 @@ inputs: selectMode, autoSelect: "click"|"focus", useAutoSort, focusMode: "row"|"
 
 ### 7. 작성 원칙
 
-- 산출물 소비자는 Claude 에이전트다. 사람 가독성보다 에이전트가 즉시 따를 수 있는 간결·명확성이 우선.
-- **코드 본문에 드러난 동작은 JSDoc 없어도 적는다**. 옵션·prop·필드·enum literal 의 동작을 본문(분기·기본값·사용처)에서 추론해 풀이. 단, 본문에서 확인 불가한 외부 추측·미검증 동작은 금지.
-- **식별자만 나열 금지** — 위 §5·§6 "식별자 풀이 의무" 강제. 이름 콤마 나열로 끝내지 않는다. 자명해 보여도 enum literal 의 값별 동작, boolean 의 토글 효과, 함수형 prop 의 호출 시점은 반드시 풀이.
-- 사용 예는 실제 호출 코드 형태로 1~3줄, 군마다 1개 정도.
+- 산출물의 소비자는 Claude 에이전트. 사람 가독성보다 에이전트가 즉시 따를 수 있는 간결·명확성이 우선.
+- **코드 본문에 드러난 동작은 JSDoc 이 없어도 기재**. 옵션·prop·필드·enum literal 의 동작을 본문(분기·기본값·사용처) 에서 추론해 풀이. 단, 본문에서 확인 불가한 외부 추측·미검증 동작은 기재 금지.
+- **식별자만 나열 금지** — 위 README 형식 섹션·분할 .md 형식 섹션의 "식별자 풀이 의무" 강제. 이름을 콤마로 나열하고 끝내지 말 것. 자명해 보여도 enum literal 의 값별 동작, boolean 의 토글 효과, 함수형 prop 의 호출 시점은 반드시 풀이.
+- 사용 예는 실제 호출 코드 형태로 1~3줄 분량, 군마다 1개 가량.
 - 분량을 늘리기 위한 부연·중복·꾸밈 금지. 단, 식별자 풀이는 "분량 늘리기" 가 아니라 필수 정보로 취급 — 풀이 생략을 통한 분량 절약 금지.
 
 ### 8. 산출 보고
 
-작성/갱신을 마치면 호출자(메인)에게 다음을 1단락으로 보고한다.
+작성·갱신을 마치면 호출자(메인 에이전트) 에게 다음 항목을 1단락으로 보고.
 
-- 신규 작성인지 갱신인지.
-- 산출/갱신한 파일 목록(README 외 분할 .md 포함).
-- 패키지 한 줄 트리거 요약(메인이 상위 README 인덱스에 쓸 문장).
-- 삭제한 파일(있다면).
+- 신규 작성인지 갱신인지 구분.
+- 산출·갱신한 파일 목록 (README 와 분할 `.md` 모두 포함).
+- 패키지의 한 줄 트리거 요약 (메인 에이전트가 상위 README 인덱스에 옮겨 적을 문장).
+- 삭제한 파일이 있으면 그 목록.

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]` 로 확장. 이미 `, 구현: …` 가 들어있으면 그 날짜만 갱신. 날짜는 Bash `date +%Y-%m-%d` 로 취득.
+- 만들거나 갱신한 파일 목록 보고 (마커를 부착한 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건이면 종료.