@simplysm/sd-claude 14.0.49 → 14.0.51

package/claude/skills/sd-claude-docs/references/package-claudemd.md

@@ -1,120 +0,0 @@
-# 패키지별 CLAUDE.md 생성 지침
-
-이 문서는 모노레포의 개별 패키지에 대한 CLAUDE.md를 생성하는 subagent를 위한 지침이다.
-
-## 병합 규칙
-
-`{패키지 경로}/CLAUDE.md`가 이미 존재하면, 먼저 Read로 읽어 기존 섹션을 파악한다. 새 콘텐츠 생성 후 아래 규칙으로 병합한다:
-1. 동일 주제의 기존 섹션 → 새 콘텐츠로 대체
-2. 대응 섹션이 없는 기존 섹션 → 그대로 보존
-3. 기존 섹션의 위치를 유지하고, 새 섹션은 마지막 기존 섹션 뒤에 추가
-
-기존 파일이 없으면 병합을 건너뛴다.
-
-## 최상단 안내 문구 (필수)
-
-CLAUDE.md의 **제목(`# CLAUDE.md`) 바로 아래**, 모든 본문 섹션보다 앞에 아래 인용 블록을 삽입한다. 이미 존재하면 갱신하지 않고 그대로 둔다.
-
-```markdown
-> 이 패키지의 사용법 및 지침은 [README.md](./README.md) 및 [docs/](./docs/)를 참조한다.
-```
-
-예외: 해당 패키지가 `private: true`여서 README.md / docs/가 생성되지 않는 경우 이 문구를 삽입하지 않는다.
-
-## 분석 대상
-
-1. `package.json` — 이름, 설명, dependencies
-2. `tsconfig.json` — 패키지 고유 컴파일러 옵션
-3. `src/` 디렉토리 구조 — Glob으로 파일 목록 확인 후 트리 구조 파악
-4. 소스 코드 — 주요 파일을 Read하여 반복되는 패턴(클래스 구조, 함수 시그니처, 데코레이터 사용 등) 식별
-5. 테스트 디렉토리 — 존재하면 테스트 패턴과 규칙 분석
-
-## 포함할 섹션
-
-- **Package Overview**: 패키지명, 한 줄 설명, 소스 파일 수
-- **Architecture**: `src/` 하위 디렉토리 구조를 트리로 표현, 각 디렉토리의 역할 설명
-- **Key Patterns**: 소스 코드에서 반복되는 패턴을 코드 예시와 함께 기술. 패턴이 여러 개면 하위 섹션(`###`)으로 분리
-- **Testing**: 테스트 디렉토리가 있으면 테스트 구조, 패턴, 규칙 기술. 없으면 섹션 생략
-- 그 외 패키지 고유 정보 (예: 스타일링, 컴파일러 설정 등)
-
-## 제외할 내용 (루트 CLAUDE.md에만 포함)
-
-- 명령어 (pnpm scripts)
-- 프로젝트 전체 코딩 규칙 (lint, prettier 등)
-- 패키지 매니저 정보
-- 프로젝트 전체 기술 스택
-- 루트와 동일한 컴파일러/빌드 설정 — 패키지에만 고유한 설정만 기술한다
-
-## 형식
-
-CLAUDE.md는 반드시 대화언어로 작성한다. 모호한 표현("적절히", "필요에 따라", "상황에 따라")을 사용하지 않는다.
-
-## 참고 예시
-
-아래는 패키지별 CLAUDE.md의 **구조와 스타일** 참고 예시다. 실제 내용은 대상 패키지에 맞게 작성한다.
-
-````markdown
-# CLAUDE.md
-
-> 이 패키지의 사용법 및 지침은 [README.md](./README.md) 및 [docs/](./docs/)를 참조한다.
-
-This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
-
-## Package Overview
-
-`@scope/package-name` - 한 줄 설명. 42 TypeScript source files across core and utilities.
-
-## Architecture
-
-```
-src/
-├── core/         ← 핵심 로직: services(5), models(3)
-├── utils/        ← 유틸리티 함수
-└── index.ts      ← public API re-exports
-```
-
-### Bootstrap
-
-`initialize()` (`core/init.ts`)이 기반을 설정:
-- 설정 로드
-- 서비스 등록
-
-## Key Patterns
-
-### Service Structure
-
-모든 서비스가 따르는 공통 패턴:
-
-```typescript
-@Injectable()
-export class FooService {
-  private readonly config = inject(ConfigProvider);
-
-  async execute(input: FooInput): Promise<FooOutput> {
-    // ...
-  }
-}
-```
-
-### Utility Functions
-
-`src/utils/`의 순수 함수들. 사이드 이펙트 없음:
-
-- `transformX()` — X 데이터 변환
-- `validateY()` — Y 유효성 검증
-
-## Testing
-
-**프레임워크**: Vitest
-
-테스트 디렉토리가 src 구조를 미러링: `tests/core/`, `tests/utils/`
-
-```typescript
-describe("FooService", () => {
-  it("should ...", () => {
-    const svc = new FooService(mockConfig);
-    expect(svc.execute(input)).resolves.toEqual(expected);
-  });
-});
-```
-````

package/claude/skills/sd-claude-docs/references/package-doc-gen.md

@@ -1,252 +0,0 @@
-# 패키지 문서 생성 프로세스
-
-이 문서는 단일 패키지에 대한 소비자용 `README.md` 및 `docs/` 문서 생성 프로세스를 기술한다.
-subagent가 패키지 경로를 전달받아 아래 순서대로 수행한다. 출력 경로는 항상 해당 **패키지 루트**(`{패키지 경로}/README.md`, `{패키지 경로}/docs/*.md`)이다.
-
-## Step 2: 엔트리포인트 & Export 체인 추적
-
-### Step 2-1: 엔트리포인트 찾기
-
-`package.json`의 `main` 또는 `exports` 필드에서 엔트리포인트 경로를 읽는다.
-`dist/` 경로이면 `src/`로 변환하고 확장자를 소스 확장자(`.ts`, `.tsx`)로 변환한다.
-
-```
-main: "./dist/index.js" → src/index.ts (또는 src/index.tsx)
-```
-
-엔트리포인트 파일이 존재하지 않으면 사용자에게 알리고 해당 패키지를 건너뛴다.
-
-### Step 2-2: Export 체인 재귀 추적
-
-엔트리포인트 파일을 Read 도구로 읽고, 아래 패턴을 추적한다:
-
-| 패턴 | 처리 |
-|------|------|
-| `export * from "./path"` | 해당 파일을 재귀적으로 읽어 모든 export를 수집 |
-| `export * as name from "./path"` | namespace export로 기록하고, 해당 파일의 export를 수집 |
-| `export { A, B } from "./path"` | 명시된 항목만 수집 |
-| `export class/function/type/interface/const/enum` | 직접 export로 기록 |
-| `import "./path"` (side-effect import) | 부수효과 모듈로 기록 (prototype extension 등) |
-
-추적 시 상대 경로를 실제 파일 경로로 변환한다. 확장자가 생략된 경우 `.ts`, `.tsx`, `/index.ts`, `/index.tsx` 순서로 탐색한다.
-
-### Step 2-3: 카테고리 수집
-
-엔트리포인트 파일의 `//#region {name}` ~ `//#endregion` 주석을 파싱하여 카테고리를 수집한다.
-region 주석이 없으면, re-export되는 파일의 디렉토리 구조를 카테고리로 사용한다.
-
-### Step 2-4: API 정보 수집
-
-추적된 각 소스 파일을 Read 도구로 읽어, export된 항목의 정보를 수집한다:
-
-- **이름**: export 식별자
-- **종류**: class, function, type, interface, const, enum
-- **시그니처**: 타입 파라미터, 매개변수, 반환 타입
-- **JSDoc**: `/** ... */` 주석이 있으면 설명으로 활용
-- **카테고리**: 2-3에서 수집한 region 또는 디렉토리 기반
-
-파일 수가 많으면(20개 이상) Agent 도구로 파일 그룹별 병렬 분석을 수행한다.
-
-## Step 2B: 스타일 에셋 분석
-
-`package.json`에 `style` 필드가 있거나, `files` 배열에 `"scss"`가 포함되어 있으면 이 단계를 수행한다. 둘 다 해당하지 않으면 건너뛴다.
-
-### Step 2B-1: SCSS 파일 탐색
-
-`scss/` 디렉토리의 엔트리포인트(`scss/styles.scss` 등)부터 `@use`/`@forward` 체인을 따라가며 모든 SCSS 파일을 수집한다.
-
-### Step 2B-2: 스타일 API 수집
-
-수집된 SCSS 파일을 Read 도구로 읽어, 아래 항목을 추출한다:
-
-| 항목 | 추출 대상 | 예시 |
-|------|-----------|------|
-| CSS 클래스 | 최상위 선택자로 정의된 클래스 (컴포넌트 내부 중첩 제외) | `.flex-row`, `.flex-fill` |
-| CSS 커스텀 프로퍼티 | `:root` 또는 테마 클래스에서 선언된 `--*` 변수 | `--color-primary`, `--font-size` |
-| 테마 | `.sd-theme-*` 등 테마 전환 클래스와 해당 클래스가 오버라이드하는 변수 목록 | `.sd-theme-dark` |
-| 공개 mixin/function | `@mixin`, `@function` 중 `_`로 시작하지 않는 것 (사용자가 `@use`로 호출 가능) | `@mixin flex-direction($dir)` |
-
-각 항목은 카테고리 "Styling"으로 분류하고, 하위 분류(Classes, CSS Custom Properties, Themes, Mixins)로 나눈다.
-
-## Step 3: 분량 판단 & 문서 구조 결정
-
-수집된 API 항목 수와 카테고리 수로 문서 구조를 결정한다. Step 2B에서 수집된 스타일 항목도 카테고리·항목 수에 포함한다.
-
-| 조건 | 문서 구조 |
-|------|-----------|
-| 카테고리 3개 이하 **그리고** API 항목 30개 이하 | README.md 단독 |
-| 위 조건에 해당하지 않음 | README.md (개요+목차) + docs/ (카테고리별 분할) |
-
-## Step 4: 문서 생성
-
-### 작성 원칙
-
-- **기존 문서가 없으면** Step 2 분석 결과로 신규 작성한다. **있으면** `docs/` 하위 모든 파일(서브디렉토리 포함)을 읽어 분석 결과를 기준으로 정합성을 맞춘다.
-- **대화언어로 작성**한다
-- **소스에서 읽은 내용만** 문서화한다 — 시그니처는 직접 복사하고, 존재하지 않는 파라미터·반환 타입·동작을 만들어내지 않는다
-- **기존 문서의 시그니처를 신뢰하지 않는다** — 기존 README.md/docs/**/*.md의 코드블록(시그니처·멤버 이름·타입·required 여부 등)을 그대로 재사용하지 않는다. 반드시 소스 파일을 Read하여 확인한 내용만 작성한다.
-- **소스 코드와 무관한 내용(사용 가이드, 주의사항, 규칙 등)은 보존하는 것이 원칙이되, 현재 소스와 상충하면(없어진 API 언급, 옛 동작 기준 설명, 더 이상 유효하지 않은 규칙 등) 소스 기준으로 수정한다.**
-- **모든 export를 빠짐없이 문서화한다** — Step 2에서 수집한 export 목록의 모든 항목이 문서에 포함되어야 한다. "덜 중요하다"는 이유로 생략하지 않는다
-- **interface/type은 필드별 설명 테이블을 포함한다** — 시그니처만 나열하지 않고, 각 필드의 타입과 설명을 테이블로 작성한다. 소스에 필드가 있는 interface를 빈 `{}`로 표시하는 것은 금지한다 — 필드가 많더라도 모든 필드를 테이블로 나열한다
-- **union type은 discriminant와 각 variant를 설명한다** — discriminated union인 경우, 어떤 필드로 분기되는지와 각 variant를 나열한다
-
-### Step 4-1: README.md 생성
-
-출력 경로: `{패키지 경로}/README.md`
-
-```markdown
-# {package-name}
-
-{package.json의 description. 없으면 엔트리포인트의 export 구조에서 추론하여 한 줄 요약}
-
-## Installation
-
-\`\`\`bash
-npm install {package-name}
-\`\`\`
-
-## API Overview
-
-{README.md 단독인 경우: 카테고리별로 API 전체 나열 — 4-2 형식과 동일}
-{docs/ 분할인 경우: 카테고리별 요약 테이블 + docs/ 링크}
-
-### {Category Name}
-
-| API | Type | Description |
-|-----|------|-------------|
-| `FunctionName` | function | {JSDoc 첫 줄 또는 시그니처 기반 요약} |
-| `ClassName` | class | {요약} |
-
-{docs/ 분할인 경우 각 카테고리 끝에:}
-→ See [docs/{category}.md](./docs/{category}.md) for details.
-
-{Step 2B에서 스타일 항목이 수집된 경우:}
-### Styling
-
-| API | Type | Description |
-|-----|------|-------------|
-| `.flex-row` | CSS class | {설명} |
-| `--color-primary` | CSS custom property | {설명} |
-| `.sd-theme-dark` | theme class | {설명} |
-
-{docs/ 분할인 경우:}
-→ See [docs/styling.md](./docs/styling.md) for details.
-
-## Usage Examples
-
-{주요 API 1~3개에 대한 사용 예제. 소스 코드의 JSDoc @example이 있으면 활용.
-없으면 시그니처를 기반으로 최소한의 사용 예제를 작성.}
-```
-
-### Step 4-2: docs/*.md 생성 (분할 대상 패키지만)
-
-카테고리별로 `{패키지 경로}/docs/{category}.md`를 생성한다. 파일명은 카테고리를 영어 kebab-case로 변환한다.
-
-```markdown
-# {Category Name}
-
-## `ExportName`
-
-{JSDoc 설명. 없으면 시그니처에서 추론한 한 줄 설명.}
-
-\`\`\`typescript
-{export 시그니처 — 소스에서 직접 복사}
-\`\`\`
-
-{class인 경우: public 메서드/프로퍼티 목록}
-{function인 경우: 파라미터 + 반환 타입 설명}
-{interface인 경우: 필드별 설명 테이블}
-
-| Field | Type | Description |
-|-------|------|-------------|
-| `fieldName` | `type` | {필드 설명} |
-
-{union type인 경우: discriminant 필드와 각 variant 나열}
-```
-
-#### Styling 카테고리 문서 형식 (docs/styling.md)
-
-Step 2B에서 스타일 항목이 수집된 경우, `{출력 경로}/docs/styling.md`를 아래 형식으로 생성한다:
-
-```markdown
-# Styling
-
-## CSS Classes
-
-| Class | Description |
-|-------|-------------|
-| `.flex-row` | {설명} |
-| `.flex-fill` | {설명} |
-
-## CSS Custom Properties
-
-| Property | Default | Description |
-|----------|---------|-------------|
-| `--color-primary` | `#...` | {설명} |
-
-## Themes
-
-### `.sd-theme-dark`
-
-{테마 설명. 오버라이드하는 변수 목록.}
-
-## Mixins / Functions
-
-| Name | Signature | Description |
-|------|-----------|-------------|
-| `flex-direction` | `@mixin flex-direction($dir)` | {설명} |
-```
-
-### Step 4-4: 완전성 및 정확성 검증
-
-문서 작업 후, Step 2에서 수집한 export 목록과 `docs/` 하위 모든 파일(서브디렉토리 포함) 및 README.md를 대조한다.
-
-#### 완전성 검증
-
-1. export 목록의 각 항목이 README.md 또는 `docs/` 하위 어느 파일(서브디렉토리 포함)에 존재하는지 확인한다
-2. 누락된 항목이 있으면 해당 API를 문서에 추가한다
-3. 문서에 있는 심볼 참조 중 **현재 export에 없는 것**(제거·이름 변경된 API)은 소스 기준으로 수정하거나 제거한다
-
-#### 정확성 검증
-
-문서의 각 API 항목에 대해, 해당 소스 파일을 Read로 다시 읽어 아래 항목을 대조한다:
-
-| 검증 항목 | 확인 내용 |
-|-----------|-----------|
-| 클래스/함수명 | 제네릭 파라미터 포함 일치 여부 |
-| 멤버 이름 | input/output/model/signal/computed/method 이름 일치 여부 |
-| 멤버 종류 | `input()` vs `model()` vs `output()` vs `signal()` 등 구분 정확성 |
-| 타입 | 파라미터 타입, 반환 타입 일치 여부 |
-| required 여부 | `input()` vs `input.required()` 구분 정확성 |
-| 기본값 | 기본값이 있는 경우 정확한 값 |
-
-불일치가 발견되면 **소스 코드를 기준으로** 문서를 수정한다.
-
-파일 수가 많으면(20개 이상) Agent 도구로 파일 그룹별 병렬 검증을 수행한다.
-
-#### 검증 결과 표시
-
-```
-완전성 검증: 52/52 API 문서화됨
-정확성 검증: 52/52 API 시그니처 일치
-```
-
-불일치가 있는 경우:
-
-```
-완전성 검증: 52/52 API 문서화됨
-정확성 검증: 50/52 API 시그니처 일치
-불일치: SdPermissionTable (items→permissions, value→permRecord), SdBarcode (value: required→optional)
-→ 소스 기준으로 문서를 수정합니다.
-```
-
-### Step 4-5: package.json `files` 배열 동기화
-
-생성된 `docs/`가 npm publish에 포함되도록 `{패키지 경로}/package.json`의 `files` 배열을 점검한다.
-
-1. `package.json`에 `files` 필드가 없으면 이 단계를 건너뛴다 (npm이 기본으로 전체 파일을 포함).
-2. `files` 필드가 있으면 아래 규칙으로 동기화한다:
-   - 이번 실행 후 `{패키지 경로}/docs/`가 존재하면, `files` 배열에 `"docs"`가 **없을 때 추가**한다.
-   - 이번 실행 후 `{패키지 경로}/docs/`가 존재하지 않으면(분량 축소로 단독 구조로 전환되었거나 Step 3 판단으로 `docs/`를 생성하지 않은 경우), `files` 배열에 `"docs"`가 **있을 때 제거**한다.
-3. `README.md`는 npm이 `files` 선언과 무관하게 항상 포함하므로 `files`에 추가할 필요가 없다.
-