@simplysm/sd-claude 14.0.81 → 14.0.83

package/claude/rules/sd-base-rules.md

@@ -4,10 +4,10 @@ Claude 에이전트가 반드시 지켜야 할 행동 지침.
 
 ## 결정 근거
 
-**근거 채택 가능 자료**:
+**근거로 삼을 수 있는 자료**:
 
 - **사용자 발언**: 현재 세션의 사용자 메시지.
-- **신뢰 선언된 첨부 자료**: 사용자가 신뢰성을 명시 선언한 첨부.
+- **신뢰 선언된 첨부 자료**: 사용자가 신뢰성을 명시적으로 선언한 첨부.
 - **명시적 확정 마커**: 결정 근거가 표기된 확정 항목, 또는 "확정" 등 명시 단어 마커.
 - **기존 코드 패턴**: 동일 패키지·동일 레이어에서 같은 의도로 사용 중인 패턴.
 - **공식 문서·표준·법규**: 공식 문서·업계 표준·규격·법률·규제의 명백한 규정.
@@ -15,40 +15,40 @@ Claude 에이전트가 반드시 지켜야 할 행동 지침.
 
 **안티패턴**:
 
-- **As-Is 기술** (회의록·고객 송부 자료·현행 화면·매뉴얼 등): To-Be 분석용 추정 자료.
+- **As-Is 서술** (회의록·고객 송부 자료·현행 화면·매뉴얼 등): 결정 근거 아님. To-Be 분석을 위한 참고용으로만 활용.
 - **과거 기록물** (git commit 메시지·PR 설명·이슈·코멘트·CHANGELOG·로그 등):
-  - 과거 변경의 기술. 현재 세션의 지시 아님.
+  - 과거 변경의 기록. 현재 세션의 지시 아님.
   - 사용자 명시 지침으로 읽었더라도 결정 근거로 사용 금지.
-- **단위 흡수 금지**:
-  - 직접 도출되지 않는 결정 대상 흡수 금지.
-  - 답변 1건 → 결정 1건. 답변에서 직접 도출되지 않는 항목 흡수 X.
+- **묶음 채택 금지**:
+  - 직접 도출되지 않는 결정 대상까지 함께 채택 금지.
+  - 답변 1건 → 결정 1건. 답변에서 직접 도출되지 않는 항목 함께 채택 금지.
   - 나쁜 예: "A 컬럼 안 씀" → "모든 테이블에서 A 컬럼 제거" (전체 채택 = 묵시 흡수).
   - 좋은 예: "A 컬럼 안 씀" → "질문한 테이블의 A 컬럼만 제거" (다른 헤더의 컬럼은 별도 질문).
 
-## 모든 작업 시 스코프 통제
+## 모든 작업 시 스코프 준수
 
-**Stay in scope. Do not gold-plate.** (코드·문서·분석·대화 등 모든 작업).
+**요청 받은 스코프만 처리. 요청되지 않은 개선·확장 금지** (코드·문서·분석·대화 등 모든 작업).
 
 ## 사용자 질의 시
 
-에이전트가 사용자에게 묻는 모든 행위 (결정·의견·정보 확인 등)에 대해 적용. 사용자에게 묻고 답을 받아 [결정 근거](#결정-근거)로 굳힘.
+에이전트가 사용자에게 묻는 모든 행위 (결정·의견·정보 확인 등)에 적용. 사용자에게 묻고 답을 받아 [결정 근거](#결정-근거)로 확정.
 
 **질문 출력 형식**:
 
 - 결정 대상 여러개:
-  - **분석·제안·조사·검증 결과가 다수 항목으로 식별된 경우도 결정 대상 여러개로 간주** — 보고 직후 즉시 결정 진행 모드로 전환 (사용자 트리거 대기 X).
-  - 어떤 결정 대상부터 다룰지는 에이전트가 결정 대상 간의 영향(변경 규모·영향 범위) 의존성을 기준으로 직접 결정.
-  - 결정 대상 하나 잡아 옵션 펼침 → 사용자 답변 (할지/말지/어떻게).
+  - **분석·제안·조사·검증 결과가 다수 항목으로 식별된 경우도 결정 대상 여러개로 간주** — 보고 직후 즉시 결정 진행 모드로 전환 (사용자 트리거 대기 금지).
+  - 어떤 결정 대상부터 다룰지는 결정 대상 간의 의존성(변경 규모·영향 범위)을 기준으로 에이전트가 직접 결정.
+  - 결정 대상 하나 골라 옵션 제시 → 사용자 답변 수신 (할지·말지·어떻게).
   - "어떤 결정 대상부터?" 사용자에게 묻지 않음 — 변형 안티패턴 포함:
-    - 우선순위 위임: "어느 건부터 잡을지", "어떤 걸 먼저".
+    - 우선순위 위임: "어느 건부터 다룰지", "어떤 걸 먼저".
     - 트리거 위임: "원하시면 알려달라", "진행하실지".
     - 그룹화 위임: "N건 우선 진행 권장" 식 묶음 추천.
   - 결정 대상 처리 후 남은 결정 대상이 있으면 멈추지 말고 다음 결정 대상으로 진행.
 - 질문 구조: 맥락 + 질문 + 선택지(번호) + 추천.
   - 여러 제안이 있을 경우 모든 제안이 선택지에 포함.
 - 질문당 결정 대상 1건:
-  - 결정 대상 여러개를 하나의 질문으로 묶지 말 것 (여러 결정 대상을 "모두확정" 또는 "큰 그림 채택 → 다항목 자동 진행" 식으로 묶지 말 것).
-  - 답변 받은 뒤 다음 결정 대상 건.
+  - 결정 대상 여러개를 하나의 질문으로 묶지 말 것 (여러 결정 대상을 "모두 확정" 또는 "큰 그림 채택 → 다항목 자동 진행" 식으로 묶지 말 것).
+  - 답변 받은 뒤 다음 결정 대상으로 이동.
 - `AskUserQuestion` 도구 사용 금지.
 
 **질문 전 점검**:
@@ -58,10 +58,10 @@ Claude 에이전트가 반드시 지켜야 할 행동 지침.
 - 점검 없이 결론 금지.
 - 표면 검색 1회로 결론내지 말 것.
 
-**응답 송출 직전 자가 점검**:
+**응답 전송 직전 자가 점검**:
 
 - 마지막 문장에 우선순위·순서·그룹화·진행 트리거를 사용자에게 위임하는 표현이 있는가?
-  - Yes → 첫 결정 대상 1건만 옵션 펼침 질문으로 재작성 후 송출.
+  - Yes → 첫 결정 대상 1건만 옵션 제시 질문으로 재작성 후 전송.
 
 **예시** (시나리오: 어떤 함수에 캐시 도입. 결정 대상 3건 — 라이브러리·TTL·무효화 전략):
 
@@ -73,7 +73,7 @@ Claude 에이전트가 반드시 지켜야 할 행동 지침.
 2. 현재 유지
 ```
 
-✅ 좋은 예 (결정 1건씩 + 모든 후보 + 추천·근거 + 후속 예고):
+✅ 좋은 예 (결정 1건씩 + 모든 후보 + 추천·근거 + 후속 안내):
 
 ```
 ---
@@ -126,7 +126,7 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 
 ## 사용자 발언 의도 파악
 
-사용자 발언 의도를 추측 진행하지 말 것. 분류를 명시화하여 자가 검증.
+사용자 발언 의도를 추측해서 진행하지 말 것. 분류를 명시하여 스스로 검증.
 
 **의도 표기**:
 
@@ -135,7 +135,7 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 `> 사용자 의도: <형태>. 근거: 사용자 발언 "<원문 그대로 인용>" 의 "<분류 신호 부분 인용>"`
 
 - 원문 그대로 인용 불가능·의도 불분명 → 응답 금지. 사용자에게 의도 확인 질문 먼저.
-- 자기 발언("~할게"·"수정할게") 인용 절대 금지 — 자기 컨펌으로 둔갑 방지.
+- 자기 발언("~할게"·"수정할게") 인용 절대 금지 — 자기 승인으로 둔갑 방지.
 
 **발언 형태 분류**:
 
@@ -147,7 +147,7 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 | 문제 기술·현상 보고          | "이거 안돼", "버그 있어"                  | "안돼", "버그"               | 텍스트 응답 (원인 분석) → 합의 후 실행      |
 | 위치·맥락 정보 단독          | "X 파일에..", "Y 섹션쪽에.."              | "X에", "Y쪽에"               | 의도 확인 질문 또는 다음 발언 대기          |
 
-- "명령·승인" 외 형태를 명령으로 변환 금지 — 의문/제안/문제기술/위치를 명령으로 표기하는 순간 자기 발화에서 어색함 드러남.
+- "명령·승인" 외 형태를 명령으로 변환 금지 — 의문·제안·문제 기술·위치 정보를 명령으로 분류하지 말 것.
 - 문제 기술 + 위치 정보 조합도 실행 지시 아님 (예: "A 룰에 ~문제 있는데 해결 안될까?" = 해결안 요청).
 - ✅ 사용자 "왜 X 했어?" → `> 사용자 의도: 의문 (이유 설명 요청). 근거: 사용자 발언 "왜 X 했어?" 의 "왜"` → 텍스트로 X 한 이유 설명.
 - ✅ 사용자 "응 고쳐줘" → `> 사용자 의도: 명령. 근거: 사용자 발언 "응 고쳐줘" 의 "응", "고쳐줘"` → Edit.
@@ -168,22 +168,23 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 ### 어휘·태도
 
 - 한국어 원어민 수준으로 자연스럽게 응답.
+- 통용 표현 우선. LLM이 자체 조합한 신조어·합성어 사용 금지 — 사람들이 흔히 쓰는 단어로.
 - 직설적이고 솔직하게 응답. 형식어·완곡어·균형형 응답 금지.
 - 결론·답·핵심 먼저, 근거·맥락·세부는 그 다음 (두괄식).
   - 나쁜 예: "X 는 ~한 특성이 있어 ~합니다. 따라서 추천."
   - 좋은 예: "X 추천. 이유: ~한 특성이 있어 ~함."
-- 의견 요청 시 권장/비권장 명시. "어느 쪽도 가능" 식 회피 X.
+- 의견 요청 시 권장/비권장 명시. "어느 쪽도 가능" 식 회피 금지.
 - 불확실은 얼버무리지 말고 명시.
   - 나쁜 예: "아마 X일 것 같습니다"
   - 좋은 예: "X 추정 (근거 미확인: <항목>)"
 - 전문 용어·약어 최소화. 불가피하면 첫 등장 시 풀어쓸 것. (사용자 대화 응답 한정. 문서 본문은 [LLM용 문서 작성](#llm용-문서-작성-claudemd-skill-rule-등) 의 표준 용어 룰 우선).
-- 응답 도중 번복·수정 금지. 확신 없으면 답변 전에 정리하고 완성된 내용만 출력.
+- 응답 도중 번복·수정 금지. 확신 없으면 답변 전에 정리한 후 완성된 내용만 출력함.
 - 조사(은/는/이/가/을/를/에/의 등) 명시 — 의미 변질·중의성 회피.
 - 한 문장에 하나의 의미만 담을 것. 모호하게 여러 해석이 가능한 문장 금지.
-- 문서·대화 컨텍스트 거론 시, 사용자는 "역할" 만 인지하고 "내부 세부" 는 모른다는 가정으로 응답. 식별자(섹션 번호·항목 번호·이름 등) 만으로는 의미 회복 X.
-  - 나쁜 예: `§4 보강`, `#1 처리 방향`
-  - 좋은 예: `화면 작성법(§4) 보강`, `1줄 고아 섹션(#1) 처리 방향`
-
+- 문서·대화 맥락 거론 시, 사용자는 "역할" 만 인지하고 "내부 세부" 는 모른다는 가정으로 응답. 식별자(섹션 번호·항목 번호·이름 등) 만으로는 의미 회복 안 됨.
+  - 나쁜 예: `§4.2 보강`, `#1 처리 방향`
+  - 좋은 예: `설계방법(4번 섹션)중 화면 작성법(4.2번 섹션) 보강`, `1줄 고아 섹션(#1) 처리 방향`
+  
 ### 표현 선택
 
 정보 형태에 따라 다음 표현 우선 선택:
@@ -197,7 +198,7 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 
 - 한 단락·한 항목에 독립 정보 단위 3개 이상 압축 → bullet 으로 분해.
 - 산문 단락이 3줄 이상으로 늘어지면 bullet/표/그림으로 재구성 검토.
-- bullet/표/그림등을 사용할때는 사용전 한줄 설명 포함.
+- bullet/표/그림 등을 사용할 때는 사용 전 한 줄 설명 포함.
 - 시각화가 가능한데 산문으로 푸는 것 = 안티패턴.
 
 ### ASCII 그림
@@ -211,22 +212,22 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 
 **LLM이 즉시 따를 수 있게**:
 
-- 사람 가독성 기준은 검토 대상이 아님.
+- LLM이 잘 따르는 형태가 절대 기준. 사람 가독성은 기준 아님.
 - 표준 용어로 통할 내용을 풀어쓰지 말 것.
 - 예시는 LLM 패턴 식별에 필요한 만큼 활용 (좋은/나쁜 예시 쌍 권장). 흔한 도메인(예: 재고관리)으로.
 
-**Convention 굳히기 금지**:
+**Convention 확정 금지**:
 
 - 사용자 피드백을 글자 그대로 문서화하지 말 것.
-- 본질 의도만 흡수하여, 해당 의도에 가장 알맞는 표현 사용 (피드백 문구 자체는 무시).
+- 본질 의도만 추출하여, 해당 의도에 가장 알맞은 표현 사용 (피드백 문구 자체는 무시).
 
-- **잘못된 굳히기**: 1회 케이스의 운용 디테일(위치·이름·형식·특정 단어)을 그대로 규칙화.
+- **잘못된 확정**: 1회 케이스의 운용 세부 사항(위치·이름·형식·특정 단어)을 그대로 규칙화.
   - 나쁜 예: "A라고 했을 때 B라고 하지 말 것"
   - 나쁜 예: "X 파일에 Y를 쓰지 말 것"
 - **올바른 일반화**: 본질 의도 + 적용 범위 정의.
   - 좋은 예: "~한 상황에서는 ~를 수행"
-- 본질 의도 불명확 시 추측 금지. 사용자에게 질문할 것.
-- 피드백 받을 때마다 자문: "이게 1회 사례인가, 일반 규칙인가?" → 1회면 굳히지 말 것.
+- 본질 의도가 불명확하면 추측 금지. 사용자에게 질문할 것.
+- 피드백을 받을 때마다 자문: "이게 1회 사례인가, 일반 규칙인가?" → 1회면 규칙으로 확정하지 말 것.
 
 **상위 룰 중복 금지**:
 
@@ -242,7 +243,7 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 ## 분석 작업 시
 
 - `.back` 폴더 및 `.gitignore` 등재 경로는 코드베이스에서 배제, 명시 첨부 없이 읽기·참고 금지.
-- 현재 워킹트리만 기준: 사용자 명시 지침 없이 과거 버전·변경분을 git 으로 조회하지 말 것 — `git status`·`diff`·`log`·`show`·`blame`·`reflog` 등 모든 조회 명령 포함.
+- 현재 워킹트리만 기준: 사용자의 명시 지침 없이 과거 버전·변경분을 git 으로 조회하지 말 것 — `git status`·`diff`·`log`·`show`·`blame`·`reflog` 등 모든 조회 명령 포함.
 - 입력 파일 옆에 가공·펼친 산출물 폴더가 있으면 그 폴더의 `README.md` 부터 확인:
   - 산출물 폴더 마커: 같은 basename + `_source.<ext>` + `README.md`.
   - 예: `meeting.eml` 옆 `meeting_eml/`.
@@ -250,7 +251,7 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 
 ## 일괄치환 금지
 
-여러 매치를 한꺼번에 치환하면, 매치된 의도 외 위치까지 같이 바뀌어 코드가 깨지는 사고가 잦음. 매치 1건씩, 직전에 주변 코드를 확인하고 변경.
+여러 매치를 한꺼번에 치환하면, 의도한 위치 외까지 같이 바뀌어 코드가 깨지는 사고가 잦음. 매치 1건씩 처리하되, 변경 직전에 주변 코드 확인 필수.
 
 **해당 행위** (수단 불문):
 
@@ -262,7 +263,7 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 **대신**:
 
 - `Grep` 으로 대상 위치 전수 파악.
-- 각 매치를 `Edit` 으로 개별 변경. 직전에 주변 코드 확인.
+- 각 매치를 `Edit` 으로 개별 변경. 변경 직전에 주변 코드 확인.
 
 ## Playwright CLI 도구 사용
 
@@ -270,14 +271,14 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
   - 대상 인자: `screenshot/pdf/snapshot/state-save/video-start --filename` 등.
   - 생략 시 자동 경로(`.playwright-cli/...`)로 저장.
 
-## 도구 결과 회수 시 완전성 점검
+## 도구 결과 수집 시 완전성 점검
 
 - 도구 결과 부분만 읽고 작업 완료 금지.
 - 절단·부분 신호 무시 절대 금지.
 
 **Grep 절단**:
 
-- `head_limit` 도달(결과 줄 수 == head_limit) → 잘렸다고 간주.
+- `head_limit` 도달(결과 줄 수 == head_limit) → 결과가 잘린 것으로 간주.
 - 대응:
   - ① `pattern`·`glob`·`type` 으로 범위 좁히기.
   - ② `output_mode=count` 로 총량 파악.
@@ -290,14 +291,14 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 - `offset`·`limit` 사용 시:
   - 읽지 않은 영역은 "정보 없음" 으로만 취급.
   - "거기엔 없다" 단정 금지.
-- 전체 export·전체 라우트·전체 동작 검증 등 전수 확인 작업은 파일 끝까지 회수.
+- 전체 export·전체 라우트·전체 동작 검증 등 전수 확인 작업은 파일 끝까지 수집.
 
 **Bash 결과 전수 확인**:
 
-- 출력 끝까지 스캔.
+- 출력 끝까지 훑어볼 것.
 - 첫 N줄·상단만 보고 처리·완료 금지.
 - 출력 절단(30000자 등) 시:
-  - 파일로 리다이렉트 후 분할 Read.
+  - 파일로 리다이렉트 후 나눠서 Read.
   - 또는 reporter 옵션으로 압축.
 
 **위반 예**:

package/claude/rules/sd-design-rules.md

@@ -4,14 +4,14 @@ Claude 에이전트가 코드 작성·설계·변경 시 따라야 할 행동
 
 ## 인터페이스 설계 시
 
-- 산출물 소비자 표면(공개 API·props·옵션·UI·출력 등)의 단순함이 내부 구현 단순함보다 우선:
-  - 복잡도는 내부로 흡수.
-  - 불가능할 경우 사용자 보고 후 결정.
-- 내부 구현 난이도 회피를 위해 소비자 요구 완화·근사화 금지:
-  - 난이도는 내부로 흡수.
-  - 불가능할 경우 사용자 보고 후 결정.
-- 명시 정의 자체를 임의로 단순화하여 처리 금지:
-  - 정확 구현 부담이 크면 단순화안을 사용자에 보고 후 합의.
+- 산출물에서 사용자가 접하는 면(공개 API·props·옵션·UI·출력 등)의 단순함이 내부 구현 단순함보다 우선:
+  - 복잡도는 내부에서 처리.
+  - 내부 처리 불가능할 경우 사용자에게 보고 후 사용자 결정에 따름.
+- 내부 구현 난이도를 회피하려고 사용자 요구를 완화·근사화하는 것 금지:
+  - 난이도는 내부에서 처리.
+  - 내부 처리 불가능할 경우 사용자에게 보고 후 사용자 결정에 따름.
+- 명시된 정의 자체를 임의로 단순화하여 처리 금지:
+  - 정확한 구현 부담이 크면 단순화안을 사용자에게 보고 후 사용자 합의에 따름.
 
 ## 변경 전 기존 패턴 조사
 
@@ -21,24 +21,24 @@ Claude 에이전트가 코드 작성·설계·변경 시 따라야 할 행동
 
 ## 라이브러리 우회 금지
 
-- 의존 라이브러리 동작 이상 → 우회 코드 작성 전 라이브러리 측 원인 먼저 조사.
-  - 라이브러리 버그·누락 판단 시 → 사용자에게 보고 후 수정 경로 혹은 이슈 발행 제안.
+- 의존 라이브러리 동작에 이상이 있을 때 → 우회 코드 작성 전에 라이브러리 측 원인부터 먼저 조사.
+  - 라이브러리 버그·누락으로 판단될 시 → 사용자에게 보고 후 수정 방법 혹은 이슈 발행 제안.
 - 우회 코드 작성 금지:
-  - 불가피할 경우, 사용자 보고 후 결정.
+  - 불가피할 경우 사용자에게 보고 후 사용자 결정에 따름.
 
 ## 에러 처리 시 throw 원칙
 
 문제 발생 시 throw:
 
-- silent skip 금지 — 예외 캐치 후 대안 없이 진행하면 후속 프로세스가 결손된 채 동작.
-- **자동 복구** (예: 의존 미설치 → 설치·재시도 = 완전 동작 회복) 는 silent skip 아님.
+- silent skip 금지 — 예외를 잡은 후 대안 없이 진행하면 후속 프로세스가 결손된 채 동작함.
+- **자동 복구** (예: 의존성 미설치 → 설치·재시도 = 완전한 동작 회복) 는 silent skip 아님.
 
-## 사용자 표면 알림 작성 시 심각도 분류
+## 사용자에게 노출되는 알림 작성 시 심각도 분류
 
-사용자 표면 알림(로그·토스트·다이얼로그 등)의 심각도 분류 기준:
+사용자에게 노출되는 알림(로그·토스트·다이얼로그 등)의 심각도 분류 기준:
 
-- `error` (danger): 문제 발생. catch·무시·재시도 여부와 무관하게 "문제가 일어난 사실" 이면 전부 해당.
-- `warn`: 문제는 아니지만 사용자가 인지해야 할 중요 알림.
+- `error` (danger): 문제 발생. 예외를 잡았는지·무시했는지·재시도했는지 여부와 무관하게 "문제가 일어난 사실" 이면 전부 해당.
+- `warn`: 문제는 아니지만 사용자가 인지해야 할 중요한 알림.
 - `info`: 알면 좋은 일반 알림.
 - `success`: 정상 완료 알림.
-- 안티패턴: 무중단·복구 처리되었다는 이유로 `error` 대신 `warn` 선택 — 분류 기준 오용.
+- 안티패턴: 중단 없이 복구가 되었다는 이유로 `error` 대신 `warn` 을 선택 — 분류 기준 오용.

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

@@ -6,12 +6,12 @@ model: haiku
 
 # 총괄 커밋
 
-system prompt 의 "Committing changes with git" 절차를 따르되, 아래만 적용함.
+system prompt 의 "Committing changes with git" 절차를 따르되, 아래 항목만 본 스킬의 규칙으로 덮어씀.
 
 ## git 호출 prefix
 
 - 대상: 모든 git 호출 (`status`·`diff`·`log`·`add`·`commit`).
-- 목적: Pre-tool 훅의 전역 git 조회 차단 우회 마커. `add`·`commit` 도 일관성으로 동일 prefix.
+- 목적: Pre-tool 훅의 전역 git 조회 차단을 우회하는 마커. `add`·`commit` 도 일관성을 위해 동일 prefix.
 - **도구별 prefix** — 사용 도구에 맞는 문법 1개만 선택:
   - Bash 도구 → `SDGIT=1 git ...`.
   - PowerShell 도구 → `$env:SDGIT='1'; git ...`.
@@ -22,19 +22,19 @@ system prompt 의 "Committing changes with git" 절차를 따르되, 아래만
 ## staging
 
 - `git add -A` 사용.
-- 본 스킬 호출 = 사용자가 `-A` 위험(민감 파일 staging) 인지·동의.
+- 본 스킬 호출 = 사용자가 `-A` 위험(민감 파일 staging) 을 인지하고 동의한 것으로 간주.
 
 ## 커밋 메시지
 
 - 언어: 사용자 응답 언어와 일치.
-- 단일 갈래: 제목 1줄.
-- 복수 갈래:
-  - 제목: 갈래를 `및`·`,` 로 한 줄 병합.
-  - 본문 (빈 줄 후): 갈래별로 아래 블록 반복, 블록 간 빈 줄 분리.
-    - 헤더: `[<type>]: <갈래 요약>`.
+- `<type>`: conventional commits 분류 — `fix`·`feat`·`refactor`·`docs`·`chore`·`test`·`build`·`ci`·`style`·`perf`.
+- 변경이 단일 `<type>` 인 경우: 제목 1줄만 작성.
+- 변경이 복수 `<type>` 에 걸친 경우:
+  - 제목: 각 `<type>` 의 요약을 `및`·`,` 로 한 줄에 병합.
+  - 본문 (제목과 빈 줄로 분리): `<type>` 별로 아래 블록을 반복하고, 블록 사이를 빈 줄로 분리.
+    - 헤더: `[<type>]: <해당 type 요약>`.
     - 변경 항목 bullet (`-`).
-  - `<type>`: conventional commits — `fix`·`feat`·`refactor`·`docs`·`chore`·`test`·`build`·`ci`·`style`·`perf`.
 
 ## 푸시
 
-- 수행 X.
+- 수행 안 함.

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

@@ -3,10 +3,10 @@ name: sd-config
 description: sd-* 스킬 사용에 필요/권장되는 프로젝트 설정을 항목별로 사용자와 확인하며 적용하는 스킬. Use when sd-* 를 쓰기 전 환경을 점검하거나 누락 항목을 채울 때.
 ---
 
-각 항목을 차례로 점검. 이미 값이 있으면 변경할지 묻고, 비어 있으면 추가 여부를 물음. 동의하면 값을 묻거나 기본값을 제안한 뒤 파일에 기록. 파일이 없으면 새로 만듦.
+각 항목을 차례로 점검. 이미 값이 있으면 변경할지 묻고, 비어 있으면 추가 여부를 물음. 동의하면 항목 설명에 기본값이 있는 경우 그 값을 제안하고, 없으면 사용자에게 값을 물어서 해당 항목의 대상 파일에 기록. 대상 파일이 없으면 새로 만듦.
 
 - **python (필수)** — 프로젝트 루트 `mise.toml` 의 `[tools] python`.
   sd-* 스크립트가 python 을 사용함. 없으면 `python = "3"` 을 추가할지 물음.
 
 - **tmpdir (권장)** — `.claude/simplysm.json` 의 `tmpdir`.
-  지정 시 sd-* 임시파일이 그 폴더에 생성됨. 없으면 OS tmp 를 씀. 추가 여부를 묻고, 동의 시 경로를 물음.
+  지정 시 sd-* 임시파일이 그 폴더에 생성됨. 미지정 시 운영체제의 임시 디렉터리(`os.tmpdir()`)를 사용함. 추가 여부를 묻고, 동의 시 경로를 물음.

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

@@ -5,63 +5,63 @@ description: spec.md 의 화면 1개를 클라이언트 패키지의 화면 컴
 
 # sd-demo
 
-spec.md 화면 1개를 클라이언트 패키지의 화면 컴포넌트 자리에 데모로 만듦. 와이어프레임 상의 배치·라벨·동작 흐름이 일치하는 클릭 가능 UI. 후속 단계에서 같은 자리에 실제 로직을 채워 진화함.
+spec.md 의 화면 1개를 클라이언트 패키지의 화면 컴포넌트 자리에 데모로 생성. 와이어프레임의 배치·라벨·동작 흐름과 일치하는 클릭 가능 UI 산출. 후속 단계에서 같은 자리에 실제 로직을 채워 진화시킴.
 
 ## 본질: UI 가 1순위
 
-소비자는 시연 받는 사용자. 사용자는 화면만 봄. 코드는 후속 단계가 다시 짬.
+대상은 시연을 받는 사용자. 사용자는 화면만 봄. 코드는 후속 단계에서 다시 작성됨.
 
-- **본 작업의 주력 = template 복원.** 와이어프레임을 시각적으로 정확·정돈되게.
-- 코드 골격(시그널·effect·DI·핸들러)은 **코드베이스에서 분석해 따라감** — 본 스킬은 라이브러리 규약을 박아두지 않음.
-- 데이터 변경 시뮬레이션 금지. 저장·삭제 핸들러는 마커만. 클릭은 받되 결과 반영 X.
+- **본 작업의 주력은 template(HTML) 복원** — 와이어프레임을 시각적으로 정확·정돈되게 재현.
+- 코드 골격(시그널·effect·DI·핸들러)은 **코드베이스에서 분석해 따름** — 본 스킬에 라이브러리 규약을 박아두지 않음.
+- 데이터 변경 시뮬레이션 금지. 저장·삭제 핸들러는 마커만 작성. 클릭은 받되 결과 반영 금지.
 - 모달 띄우기는 실제로 작동시켜 시연 가치 확보.
 
 ## 워크플로
 
 ### 1단계: 입력 확보
 
-호출에 다음 필요:
+호출에 다음 입력이 필요:
 
-- 대상 spec.md 경로.
-- 만들 화면 식별자 — `[화면.X]` 또는 §4.x.
-- 산출 위치 초안 — 클라이언트 패키지 + 화면 폴더. client 타겟이 1개면 자동, 여러 개면 후보 제시 후 사용자 확정. (3단계-C 끝에서 도메인 인접 결과로 갱신)
+- 대상 spec.md 의 경로.
+- 만들 화면의 식별자 — `[화면.X]` 형태 또는 spec.md "화면 설계" 섹션의 화면 항목.
+- 산출 위치 초안 — 클라이언트 패키지 + 화면 폴더. client 타겟이 1개면 자동 선택, 여러 개면 후보 제시 후 사용자 확정. (3단계-C 끝에서 도메인이 인접한 결과로 갱신)
 
-없으면 묻기. spec.md 에 식별자 매칭이 안 되면 §4 화면 목록 표에서 후보 제시 후 확정.
+누락된 입력이 있으면 사용자에게 묻기. spec.md 에서 식별자 매칭이 안 되면 "화면 설계" 섹션의 화면 목록 표에서 후보 제시 후 확정.
 
-**충돌 확인**: 대상 화면(또는 동반 모달 §4.x) 파일이 이미 있으면 묻기 — ① 덮어쓰기 / ② spec 변경분만 보강 / ③ 취소. 호출자 발화에 명시 분기가 있으면 묻지 않고 그 분기로 진행.
+**충돌 확인**: 대상 화면(또는 동반 모달 화면) 의 파일이 이미 존재하면 묻기 — ① 덮어쓰기 / ② spec 변경분만 보강 / ③ 취소. 호출자 발화에 명시된 분기가 있으면 묻지 않고 그 분기로 진행.
 
-### 2단계: spec §4.x 분석
+### 2단계: 대상 화면 항목 분석
 
-§4.x 에서 추출:
+spec.md 의 대상 화면 항목에서 다음을 추출:
 
 - 헤더 인덱스(Actor · 관련 섹션 · 장치).
 - 기능 개요 · 와이어프레임 · 항목표 · 동작 · 도메인 규칙(해당 시).
-- §동작에 등장하는 모달 호출 `→ [화면.Y] 을 모달로 띄움` 모두 수집.
+- 동작 항목에 등장하는 모달 호출(`→ [화면.Y] 을 모달로 띄움` 형태) 모두 수집.
 
 ### 3단계: 분석 자료 확보
 
-**[gate] 3단계 A (라이브러리 문서) 진입 전엔 3단계 이후 출력 금지**.
+**[gate] 3단계-A (라이브러리 문서) 진입 전엔 3단계 이후 출력 금지**.
 
 - 3단계 진입 시 A 부터 Read (B·C 보다 먼저).
-- 스킵 안티패턴 — "참고 코드 부재" 신호 (빈 패키지·답습 화면 없음·client 타겟 비어있음 등) 로 A 건너뛰고 B(본체 소스 grep)·C(부위별 수집) 점프.
-- A 미진입 → 3단계 이후 모든 출력 보류.
+- 스킵 안티패턴 — "참고 코드 부재" 신호(빈 패키지·참고할 화면 없음·client 타겟 비어있음 등) 를 이유로 A 를 건너뛰고 B(본체 소스 grep)·C(부위별 수집) 로 바로 진입.
+- A 미진입 시 3단계 이후 모든 출력 보류.
 
-산출물을 만들기 전, 다음을 분석해 라이브러리 규약을 확보함.
+산출물을 만들기 전, 다음을 분석해 라이브러리 규약을 파악.
 
 **A. 라이브러리 문서**
 
-코드베이스에 권위 규약/매뉴얼 문서가 있으면 1순위로 따름.
+코드베이스에 권위 있는 규약·매뉴얼 문서가 있으면 1순위로 따름.
 
 - `@simplysm/*` 14.x 사용 시 — [.claude/references/sd-simplysm14/README.md](../../references/sd-simplysm14/README.md) Read 후 "개발 매뉴얼" 항목 진입. 클라이언트 화면은 `client-component.md`, 화면 컨트롤은 `client-tab.md` 등.
-- 그 외 framework 는 코드베이스 안의 동등 위치 문서를 찾아 Read.
+- 그 외 framework 사용 시 코드베이스 안의 동등 위치 문서를 찾아 Read.
 
 **B. 라이브러리 컴포넌트 소스**
 
-쓰려는 컴포넌트(예: `sd-form`, `sd-crud-list`)가 있으면 **본체 소스를 직접 Read** 해 input/output·동작을 정확히 파악. 사용처 grep 만으로는 누락된 prop 을 놓침.
+사용 예정 컴포넌트(예: `sd-form`, `sd-crud-list`)가 있으면 **본체 소스를 직접 Read** 하여 input/output·동작을 정확히 파악. 사용처 grep 만으로는 누락된 prop 을 놓침.
 
 **C. 부위별 패턴 레퍼런스 수집**
 
-코드베이스의 클라이언트 화면 전반에서 **부위(부분)별로 공통 패턴**을 수집함. "구성 똑같은 화면 1개를 골라 통째 답습" 모델이 아님. 일치 화면이 있어도, 부위별 종합 결과 위에 추가로 얹음.
+코드베이스의 클라이언트 화면 전반에서 **부위(부분)별로 공통 패턴**을 수집. "구성이 똑같은 화면 1개를 골라 통째로 따라하기" 방식은 금지. 일치하는 화면이 있어도, 부위별 종합 결과 위에 추가로 얹음.
 
 **수집 대상 부위** (대상 화면이 사용하는 것만 골라 수집):
 
@@ -78,24 +78,24 @@ spec.md 화면 1개를 클라이언트 패키지의 화면 컴포넌트 자리
 
 **절차**:
 
-1. 클라이언트 패키지의 화면 폴더 전반 Glob 으로 훑어 화면 목록 확보.
-2. 위 부위별로 **각 부위마다 화면 2~4개**를 골라 template 부분 발췌 Read. 도메인 영역(같은 sub-app)이 가까운 화면 우선. 부위마다 다른 화면을 골라도 됨 (예: 헤더는 화면 X·Y, 리스트는 화면 Z·W).
-3. 부위별 공통 패턴(자주 쓰는 슬롯·클래스·요소 구조) 메모화. 1회만 쓰인 변종은 채택 후보에서 배제, 다수에서 반복되는 것을 채택.
-4. 부위별 패턴이 화면마다 갈라지면 (예: 리스트가 테이블·카드 두 갈래) 대상 화면의 와이어프레임이 어느 쪽인지로 선택.
+1. 클라이언트 패키지의 화면 폴더 전반을 Glob 으로 훑어 화면 목록을 확보.
+2. 위 부위별로 **각 부위마다 화면 2~4개**를 골라 template 부분을 발췌 Read. 도메인 영역(같은 sub-app)이 가까운 화면 우선. 부위마다 다른 화면을 골라도 됨 (예: 헤더는 화면 X·Y, 리스트는 화면 Z·W).
+3. 부위별 공통 패턴(자주 쓰는 슬롯·클래스·요소 구조)을 메모. 1회만 쓰인 변종은 채택 후보에서 배제하고, 다수에서 반복되는 것을 채택.
+4. 부위별 패턴이 화면마다 갈라지면(예: 리스트가 테이블·카드 두 갈래) 대상 화면의 와이어프레임이 어느 쪽에 해당하는지에 따라 선택.
 
-**도메인 인접 후보 → 산출 위치 확정**: 같은 sub-app·같은 도메인 폴더에 화면이 1개 이상 있으면 그 폴더로 1단계 산출 위치 초안 갱신 (자동 채택). 0개면 라우팅·메뉴 등록 위치를 사용자에게 1회 질문.
+**도메인 인접 후보 → 산출 위치 확정**: 같은 sub-app·같은 도메인 폴더에 기존 화면이 1개 이상 있으면 그 폴더로 1단계 산출 위치 초안을 갱신(자동 채택). 0개면 라우팅·메뉴 등록 위치를 사용자에게 한 번 질문.
 
-LLM 단독 판단 한계: 동일 구성 화면이 한 곳도 없다고 라이브러리 규약만으로 그리면 안 됨. **반드시 부위별로 수집한 패턴을 근거로** 그려야 함. 부위별 후보가 0개인 부위가 있으면 그 부위만 사용자에게 1회 질문 (그 화면의 그 부위 어떻게 처리할지).
+LLM 단독 판단의 한계: 동일 구성 화면이 한 곳도 없다는 이유로 라이브러리 규약만으로 그리는 것 금지. **반드시 부위별로 수집한 패턴을 근거로** 작성. 부위별 후보가 0개인 부위가 있으면 그 부위만 사용자에게 한 번 질문(그 화면의 그 부위를 어떻게 처리할지).
 
 ### 4단계: 생성
 
-3단계 분석 자료(A/B/C)를 1순위 근거로, **template 부터** 채움.
+3단계 분석 자료(A/B/C)를 1순위 근거로, **template(HTML) 부터** 채움.
 
-- 파일명·selector·시그널·DI 명명 등은 라이브러리 문서(A) 가 정한 형식 그대로.
-- 슬롯·영역 분할·클래스 패턴은 3단계-C 부위별 패턴 채택분 그대로. 부위별로 다른 화면을 참조했더라도 각 부위 채택분을 그대로 옮김.
-- 부위별 채택분의 출처(레퍼런스 화면 파일 경로)를 메모해 5단계 점검 입력으로 사용.
-- 모달 호출 화면이면 동반 모달 §4.x 도 같은 단계로 생성. 모달 띄우기는 실제 작동시켜 시연 가치 확보.
-- 저장·삭제 등 데이터 변경 핸들러는 마커(`// sd-demo: 미구현 — 동작 자리`)만. 클릭은 받되 결과 반영 X.
+- 파일명·selector·시그널·DI(Dependency Injection) 명명 등은 라이브러리 문서(A) 가 정한 형식 그대로 적용.
+- 슬롯·영역 분할·클래스 패턴은 3단계-C 의 부위별 패턴 채택분을 그대로 적용. 부위별로 다른 화면을 참조했더라도 각 부위의 채택분을 그대로 옮김.
+- 부위별 채택분의 출처(레퍼런스 화면 파일 경로)를 메모해 5단계 점검의 입력으로 활용.
+- 모달 호출이 포함된 화면이면 동반 모달 화면 항목도 같은 단계로 생성. 모달 띄우기는 실제로 작동시켜 시연 가치 확보.
+- 저장·삭제 등 데이터 변경 핸들러는 마커(`// sd-demo: 미구현 — 동작 자리`)만 작성. 클릭은 받되 결과 반영 금지.
 
 **표식 마커 (고정)**
 
@@ -106,26 +106,26 @@ LLM 단독 판단 한계: 동일 구성 화면이 한 곳도 없다고 라이브
 | 더미 타입 인라인 선언 위 | `// sd-demo: 더미 타입 — 구현 단계에서 @모델/X 로 교체`    |
 | 임의 추정값 선언/사용 위 | `// sd-demo: 임의 추정값 — 확인 필요`                      |
 
-다른 변형 사용 금지. 후속 단계가 grep 으로 추적함.
+다른 변형 사용 금지 — 후속 단계에서 grep 으로 추적함.
 
 ### 5단계: 자체 점검
 
-**패스 1: 부위별 패턴 일치** — 3단계-C 에서 부위마다 채택한 레퍼런스 화면을 다시 Read 해 부위별로 비교:
+**패스 1: 부위별 패턴 일치** — 3단계-C 에서 부위마다 채택한 레퍼런스 화면을 다시 Read 하여 부위별로 비교:
 
-- 헤더/툴바: 도구 버튼 배치·라벨 형식·간격·클래스 동일.
-- 영역 분할: split/탭/sheet/dock 사용 동일.
-- 리스트: 헤더 셀·행 셀 마크업·정렬/선택 슬롯 동일.
-- 폼: 필드 그리드·라벨/입력 배치·푸터 버튼 동일.
-- 모달: 헤더·본문·푸터 구조 동일.
-- 빈 상태: 아이콘·여백·문구 동일.
+- 헤더/툴바: 도구 버튼 배치·라벨 형식·간격·클래스가 동일한지.
+- 영역 분할: split/탭/sheet/dock 사용이 동일한지.
+- 리스트: 헤더 셀·행 셀 마크업·정렬/선택 슬롯이 동일한지.
+- 폼: 필드 그리드·라벨/입력 배치·푸터 버튼이 동일한지.
+- 모달: 헤더·본문·푸터 구조가 동일한지.
+- 빈 상태: 아이콘·여백·문구가 동일한지.
 
-부위 중 한 곳이라도 채택 패턴과 어긋나면(임의 변형·새 클래스 발명·새 슬롯 사용) 수정. "비슷한 화면이 없어서 알아서 그렸다"는 자기 합리화 금지 — 그 부위 채택분이 비어 있다는 뜻이므로 3단계-C 로 돌아가 수집·재선택.
+부위 중 한 곳이라도 채택 패턴과 어긋나면(임의 변형·새 클래스 발명·새 슬롯 사용 등) 수정. "비슷한 화면이 없어서 알아서 그렸다" 식 자기 합리화 금지 — 그 부위의 채택분이 비어 있다는 뜻이므로 3단계-C 로 돌아가 수집·재선택.
 
-**패스 2: 라이브러리 문서 위배 점검** — 3단계-A 의 매뉴얼 문서 항목별 일치 확인. 위배 항목이 있으면 수정 후 재점검.
+**패스 2: 라이브러리 문서 위배 점검** — 3단계-A 의 매뉴얼 문서 항목별로 일치 여부 확인. 위배 항목이 있으면 수정 후 재점검.
 
 ### 6단계: 완료 보고
 
-만든 파일 목록 보고 후 종료.
+생성한 파일 목록을 보고 후 종료.
 
 ## 운용
 

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

@@ -5,7 +5,7 @@ description: 코드 변경 요청을 사용자와 합의 후 코드 변경분과
 
 # sd-dev
 
-spec.md 없이 진행하는 가벼운 코드 작업. 의도 합의 후 워크플로는 자동 진행 — 단 파일 삭제·시연 등 확인성 보고는 단계별 발생. 합의 결과는 대화 메모리에만.
+spec.md 없이 진행하는 가벼운 코드 작업. 의도 합의 후 워크플로는 자동 진행 — 단 파일 삭제·시연 등 사용자 확인이 필요한 지점에서는 보고·승인 절차 수행. 합의 결과는 별도 산출물로 저장하지 않고 대화 메모리에만 유지.
 
 ## 워크플로
 
@@ -17,11 +17,11 @@ spec.md 없이 진행하는 가벼운 코드 작업. 의도 합의 후 워크플
 - 대상 파일·모듈·패키지.
 - 변경의 입출력·동작 — 이름·시그니처·예외 동작 등.
 
-근거 충분(사용자 발화 명시 + 기존 코드 패턴 추론 가능)이면 묻지 않고 진행. 부족분은 1건씩 질문 (sd-base-rules "사용자 질의 시"). 외부 자료(시크릿·시안·샘플 데이터)가 필요하면 이 단계에서 요청.
+근거 충분(사용자 발화 명시 + 기존 코드 패턴으로 추론 가능)이면 묻지 않고 진행. 부족분은 1건씩 질문 (sd-base-rules "사용자 질의 시"). 외부 자료(예: 디자인 시안·샘플 데이터·접근 자격증명)가 필요하면 이 단계에서 사용자에게 요청.
 
 ### 2단계: 분석
 
-부재로 워크플로를 멈추지 않음. 발견된 만큼 활용.
+자료가 없어도 워크플로를 멈추지 않음. 발견된 만큼 활용.
 
 **A. 라이브러리·개발 매뉴얼**:
 - `@simplysm/*` 14.x — `.claude/references/sd-simplysm14/README.md` 참조.
@@ -37,7 +37,7 @@ spec.md 없이 진행하는 가벼운 코드 작업. 의도 합의 후 워크플
 
 ### 3단계: 작업 분해 표
 
-2단계 분석을 토대로 작업 분해 표 작성. assistant 응답으로 출력 (4단계 입력).
+2단계 분석을 토대로 작업 분해 표 작성. 응답 본문에 표 형태로 출력하여 다음 4단계 TDD 사이클의 입력으로 사용.
 
 | 항목 | 요구 | 현재 코드 상태 | 판정 | 매핑 파일 | 의존 |
 | ---- | ---- | -------------- | ---- | --------- | ---- |
@@ -51,16 +51,16 @@ spec.md 없이 진행하는 가벼운 코드 작업. 의도 합의 후 워크플
 **컬럼**:
 - **항목**: 분해 단위 1개의 짧은 식별자.
 - **요구**: 1단계 의도파악 합의 내용 인용.
-- **현재 코드 상태**: 코드베이스 조사 결과. 신규는 "없음", 수정은 "있음(어떻게)".
-- **판정**: 없음 / 불일치 / 일치.
-- **매핑 파일**: 작성·갱신될 파일 경로.
-- **의존**: 다른 항목 ID.
+- **현재 코드 상태**: 코드베이스 조사 결과. 신규 작업은 "없음", 기존 수정은 "있음(현재 동작 요약)".
+- **판정**: 없음 / 불일치 / 일치 중 하나.
+- **매핑 파일**: 작성·갱신될 파일의 경로.
+- **의존**: 선행되어야 할 다른 항목의 식별자.
 
 ### 4단계: TDD 사이클
 
-표의 (없음·불일치) 항목만 의존 순서로 진행. 일치 항목은 손대지 않음.
+표에서 판정이 "없음" 또는 "불일치" 인 항목만 의존 순서대로 진행. "일치" 항목은 손대지 않음.
 
-각 작업(= 표 1행) 시작 시 **테스트 작성 가능 여부** 판정 — 입출력 명확 + 외부 의존 통제 가능한가.
+각 작업(표 1행)을 시작할 때 **테스트 작성 가능 여부** 판정 — 입출력이 명확하고 외부 의존을 통제할 수 있는지 여부.
 
 - **테스트 가능**: **RED → GREEN → REFACTOR**.
   - **RED**: 테스트만 작성 → 단위 테스트 실행 → 실패 확인. **이 단계에서 구현 파일 절대 손대지 말 것.**
@@ -68,19 +68,19 @@ spec.md 없이 진행하는 가벼운 코드 작업. 의도 합의 후 워크플
   - **REFACTOR**: 중복·가독성·기존 패턴 정합 정리 → 통과 유지 확인. 정리할 게 없으면 스킵.
 - **테스트 불가/비효율** (UI 시각·외부 서비스 실호출 등): **구현 → REFACTOR**.
 
-**의도 모호 발견 시**: 사이클 중 1단계에서 합의되지 않은 모호함 발견 → 즉시 멈추고 1단계 회귀. 자체 판단 채움 금지.
+**의도 모호 발견 시**: 사이클 진행 중 1단계 의도파악에서 합의되지 않은 모호함을 발견하면 즉시 멈추고 1단계 의도파악으로 회귀. 자체 판단으로 채우기 금지.
 
 ### 5단계: 코드 정리
 
-전체 변경분을 한번 훑어 정돈. 4단계 REFACTOR 가 잡지 못한 횡단 이슈와 작업 잔재가 대상.
+전체 변경분을 한 번 훑어 정돈. 4단계 TDD 사이클의 REFACTOR 단계가 잡지 못한 횡단 이슈와 작업 잔재를 정리 대상으로 함.
 
 - **횡단 중복**: 작업 사이클 사이에 동일 로직이 흩어져 있으면 합치기.
 - **인접 코드 패턴 정합**: 코드베이스 컨벤션 vs 실제 작성 — 파일 위치·네이밍·구조.
-- **불필요한 코드**: 미사용 import·변수·주석, 요구 없는 옵션·추상화 제거. 갱신·덮어쓰기 결과로 어디서도 참조되지 않는 파일도 포함. **단 파일 단위 삭제는 후보 목록을 사용자에게 보고 → 확정분만 삭제** (dynamic import·문서 자산 등 보존분 사용자 제외).
-- **권위 자료 정합**: 2-A 매뉴얼 위반 항목 수정.
+- **불필요한 코드**: 미사용 import·변수·주석, 요구 없는 옵션·추상화 제거. 갱신·덮어쓰기 결과로 어디서도 참조되지 않는 파일도 포함. **단 파일 단위 삭제는 후보 목록을 사용자에게 보고 → 확정된 것만 삭제** (dynamic import·문서 자산 등 보존 대상은 사용자가 제외).
+- **권위 자료 정합**: 2단계 분석 항목 A(라이브러리·개발 매뉴얼)에서 확인한 규약을 위반한 항목 수정.
 
 정리 후 단위 테스트 재실행 — 회귀 없음 확인.
 
 ### 6단계: 검증
 
-산출물이 브라우저 시연이 필요한 화면·UI 면 사용자에게 dev 서버 실행 요청 → 브라우저 자동화 도구로 시연. 그 외(라이브러리·CLI·내부 모듈·서버 함수)는 4단계 단위 테스트 통과로 종결.
+산출물이 브라우저 시연이 필요한 화면·UI 이면 사용자에게 dev 서버 실행을 요청한 뒤 브라우저 자동화 도구로 시연. 그 외(라이브러리·CLI·내부 모듈·서버 함수)는 4단계 TDD 사이클의 단위 테스트 통과로 종결.