@simplysm/sd-claude 14.0.89 → 14.0.90

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

@@ -0,0 +1,58 @@
+---
+name: sd-docs
+description: `@simplysm/*` 라이브러리 패키지의 API 문서를 `.claude/references/sd-simplysm14/apis/<패키지명>/` 위치에 사용 트리거 기준으로 작성·갱신. Use when 라이브러리 API 문서를 새로 작성하거나 코드 변경을 반영해 갱신할 때.
+model: haiku
+---
+
+# sd-docs
+
+`@simplysm/*` 라이브러리 패키지의 API 문서를 코드를 근거로 작성·갱신. 메인 에이전트가 패키지 목록 추출과 상위 README 인덱스 갱신을 담당하고, 패키지별 문서 작성은 패키지 1개당 subagent 1개를 호출해 병렬 위임.
+
+## 산출물 위치
+
+- `.claude/references/sd-simplysm14/apis/<패키지명>/README.md` — 패키지당 1개, 필수.
+- `.claude/references/sd-simplysm14/apis/<패키지명>/<군명>.md` — 사용 트리거 군이 커서 README 한 장에 풀어쓰면 같은 README 의 다른 군 정보까지 함께 읽혀 부담이 커지는 경우에만 분할 산출.
+- `.claude/references/sd-simplysm14/README.md` 의 "패키지 인덱스" 섹션 — 메인 에이전트가 갱신.
+
+## 워크플로
+
+### 1. 패키지 목록 추출
+
+워크스페이스 루트의 `packages/*/package.json` 을 모두 읽어 다음 두 리스트를 만듦.
+
+- **public 리스트**: `private: true` 가 아닌 패키지. 각 항목 = `{ name, dir }`.
+- **private 리스트**: `private: true` 인 패키지. 인덱스에서 제외하기 위해 보관.
+
+### 2. 패키지별 subagent 병렬 호출
+
+`public 리스트` 의 패키지 수만큼 `general-purpose` subagent 호출을 **단일 메시지 안에서 병렬**로 보냄. 각 호출 프롬프트는 [references/subagent-prompt.md](references/subagent-prompt.md) 양식의 "프롬프트" 마커 아래 본문을 그대로 사용하고, `<PACKAGE_NAME>` 과 `<PACKAGE_DIR>` 만 치환.
+
+각 subagent 의 산출 (풀 재작성 모드 — 기존 파일 참고 없이 처음부터 작성):
+
+- `apis/<패키지명>/README.md` 재작성.
+- 필요 시 `apis/<패키지명>/<군명>.md` 재작성. 코드에서 사라진 군의 파일은 삭제.
+- 결과 보고 1단락 (산출 파일 목록, 분할 발생 여부, 한 줄 트리거 요약).
+
+**범위 한정**: subagent 는 `apis/<패키지명>/` 위치만 다룸. 상위 `.claude/references/sd-simplysm14/README.md` 는 건드리지 않음 (다음 단계의 "패키지 인덱스 섹션 갱신" 에서 메인 에이전트가 처리).
+
+### 3. 상위 README 의 "패키지 인덱스" 섹션 갱신 (파일 보존 + 섹션 내 항목만 갱신)
+
+`.claude/references/sd-simplysm14/README.md` 는 **풀 재작성 대상 아님**. 파일 본문·다른 섹션은 그대로 보존, "패키지 인덱스" 섹션의 항목 리스트만 재구성함.
+
+모든 subagent 완료 후:
+
+- **갱신 대상**: "패키지 인덱스" 섹션 본문(항목 리스트)만.
+- **건드리지 않음**: 섹션 머리(`## 패키지 인덱스`), 다른 모든 섹션, 파일 상단/하단 텍스트.
+- **항목 형식**: `- **<패키지명>** — <한 줄 트리거 요약>. 자세히: [apis/<패키지명>/README.md](./apis/<패키지명>/README.md)`.
+- **순서**: 패키지명 알파벳순.
+- **포함**: `public 리스트` 만.
+- **제외**: `private 리스트` 의 패키지, 코드베이스에 더 이상 존재하지 않는 패키지.
+
+### 4. 사용자 보고
+
+다음 항목을 짧게 정리해 출력함.
+
+- 재작성된 패키지 목록 (= `public 리스트` 전체. 풀 재작성 모드 — 매번 모든 패키지 산출).
+- 분할 발생(`<군명>.md` 가 생긴) 패키지 목록.
+- 삭제된 분할 파일 (코드에서 사라진 군, 있다면).
+- 인덱스에서 제거된 항목 (있다면).

package/claude/{workflows/sd-docs.rules.md → skills/sd-docs/references/subagent-prompt.md}

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

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

@@ -33,17 +33,20 @@ spec.md 단위(§4.x 화면 / §5.x 자동 처리 / §6.x 공통·기반 기능)
 
 작업 대상 §4.x/§5.x/§6.x 와 작업 대상이 참조하는 §5/§6/§7/§8/§9 항목을 점검:
 
-- **헤더 미확정(마커 없음) 섹션**: 사용자 미검토 상태 → 그대로 구현하지 않음. 해당 § 을 사용자에게 제시·검토 요청 → 확정/수정 후 `[확정]` 으로 승격 → 진행. 단 본문이 초안 없이 재분석 방법뿐이면 "spec 수정 절차" 적용.
+- **헤더 `[OPEN: 날짜]` 섹션**: 본문이 재분석 포인터일 뿐 초안 부재 → "spec 수정 절차" 적용.
 - **본문 인라인 `[OPEN]`**: 결정 근거가 있으면 결정. 없으면 1건씩 질문 → 답변 후 "spec 수정 절차" 적용.
 - **사용자 제공 예정 자료**: spec 본문에 사용자 회신 대기로 적힌 자료. 사용자 회신 후 진행.
 - **묵시적 모호**: 명시 마커는 없지만 spec 본문이 분기·정의·정의식·경계 케이스를 다루지 않는 부분. 4단계 분해 중 발견 가능성 높음. 발견 시 본 단계로 회귀.
 
 #### spec 수정 절차
 
-spec 본문 수정이 필요한 경우(인라인 `[OPEN]` 해소·미확정 섹션 확정·구조 변경·6단계 (b)(d) 분류 처리 등) 메인 LLM 이 직접 처리:
+spec 본문 수정이 필요한 경우(인라인 `[OPEN]` 해소·헤더 `[OPEN]` 해소·구조 변경·6단계 (b)(d) 분류 처리 등) 메인 LLM 이 직접 처리:
 
-1. **sd-spec SKILL.md Read** — 룰 인지.
-2. **재분석/검토 → 확정 → spec.md Edit** — sd-spec 의 "확정 섹션 수정·구현 무효화" 룰 적용. `[확정]` 산출이므로 합의(행동 규칙) 후 헤더 `[확정: 날짜]` 부착. 수정으로 무효화되는 구현 §4.x/§5.x/§6.x (본 작업 단위 자신은 제외 — 작업 중) 의 `, 구현: …` 마커 제거를 합의 내용에 함께 올림.
+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단계에서 `[확정, 구현]` 으로 확장.