@simplysm/sd-claude 13.0.83 → 13.0.84

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

@@ -1,102 +1,102 @@
 ---
 name: sd-init
-description: "초기화", "init", "sd-init", "CLAUDE.md 생성" 등을 요청할 때 사용.
+description: Used when requesting "initialize", "init", "sd-init", "generate CLAUDE.md", etc.
 ---
 
-# SD Init — CLAUDE.md 자동 생성
+# SD Init — Auto-generate CLAUDE.md
 
-프로젝트를 분석하여 CLAUDE.md를 자동 생성한다. 기존 파일이 있으면 덮어쓴다.
+Analyze the project and auto-generate CLAUDE.md. Overwrite if the file already exists.
 
 ---
 
-## Step 1: 패키지 매니저 감지
+## Step 1: Detect Package Manager
 
-프로젝트 루트의 lock 파일로 PM을 판별하라:
+Determine the PM from the lock file in the project root:
 
 1. `pnpm-lock.yaml` → pnpm
 2. `yarn.lock` → yarn
-3. 그외 → npm
+3. Otherwise → npm
 
-## Step 2: 스크립트 분석
+## Step 2: Analyze Scripts
 
-`package.json`의 `scripts`를 읽고, 각 스크립트가 호출하는 CLI 도구에 대해 Bash로 `--help`등의 도움말 보기를 실행하여 사용 가능한 인자와 플래그를 파악하라.
+Read the `scripts` in `package.json`, and for each CLI tool invoked by a script, run `--help` or similar help commands via Bash to identify available arguments and flags.
 
-파악한 정보를 바탕으로 스크립트를 카테고리별(개발, 빌드, 테스트, 린트 등)로 그룹화하고, 각 스크립트의 기본 사용법과 주요 플래그 예시를 정리하라.
+Based on the gathered information, group scripts by category (development, build, test, lint, etc.), and organize the basic usage and key flag examples for each script.
 
-## Step 3: 코딩 규칙 분석
+## Step 3: Analyze Coding Rules
 
-프로젝트 루트에서 아래 설정 파일들을 찾아 읽어라 (존재하는 것만):
+Find and read the following config files from the project root (only those that exist):
 
-- ESLint: `eslint.config.*`, `.eslintrc.*`, `packages/*/eslint.*` 등
+- ESLint: `eslint.config.*`, `.eslintrc.*`, `packages/*/eslint.*`, etc.
 - Prettier: `.prettierrc*`, `prettier.config.*`
 - EditorConfig: `.editorconfig`
-- TypeScript: `tsconfig.json` (루트)의 `compilerOptions` 중 `strict`, `noImplicitAny` 등 코드 스타일에 영향을 주는 옵션
+- TypeScript: `compilerOptions` in the root `tsconfig.json` that affect code style, such as `strict`, `noImplicitAny`, etc.
 - Stylelint: `.stylelintrc*`, `stylelint.config.*`
 
-Claude가 규칙과 반대로 수정하기를 제안할 정도의 자주 실수할 내용들만 대폭 간결하게 정리하라.
+Summarize only the frequently violated rules that Claude is likely to suggest incorrectly — keep it highly concise.
 
-## Step 4: CLAUDE.md 생성
+## Step 4: Generate CLAUDE.md
 
-아래 정보를 종합하여 프로젝트 루트에 `CLAUDE.md`를 작성하라:
+Combine the information above and write `CLAUDE.md` in the project root:
 
-- **프로젝트 정보**: `package.json`의 `name`, `description`
-- **PM**: Step 1에서 감지한 패키지 매니저
-- **모노레포 구조**: `workspaces` 필드 또는 `pnpm-workspace.yaml`이 있으면 워크스페이스 경로를 간단히 기술
-- **기술스택**: `dependencies`/`devDependencies`에서 주요 기술(프레임워크, 번들러, 테스트 도구 등)을 파악하여 아주 간단히 기술
-- **명령어**: Step 2에서 정리한 스크립트 사용법
-- **코딩 규칙**: Step 3에서 분석한 규칙 중 Claude가 지켜야 할 것들. `## 코딩 규칙` 섹션으로 작성
+- **Project info**: `name` and `description` from `package.json`
+- **PM**: Package manager detected in Step 1
+- **Monorepo structure**: If a `workspaces` field or `pnpm-workspace.yaml` exists, briefly describe the workspace paths
+- **Tech stack**: Identify key technologies (frameworks, bundlers, test tools, etc.) from `dependencies`/`devDependencies` and describe them very briefly
+- **Commands**: Script usage organized in Step 2
+- **Coding rules**: Rules from Step 3 that Claude should follow. Write as a `## Coding Rules` section
 
-### 참고 예시
+### Reference Example
 
-아래는 잘 작성된 CLAUDE.md의 예시다. 형식을 그대로 복사하지 말고, 프로젝트 특성에 맞게 유연하게 작성하라.
+Below is an example of a well-written CLAUDE.md. Do not copy the format verbatim — adapt it flexibly to the project's characteristics.
 
 ```markdown
 # Simplysm
 
-pnpm 모노레포. 패키지 경로: `packages/*`, 테스트: `tests/*`
+pnpm monorepo. Package paths: `packages/*`, tests: `tests/*`
 
-## 명령어
+## Commands
 
-모든 명령어는 내부적으로 `pnpm sd-cli <명령>`을 실행한다. 모든 명령에 `--debug` 플래그 사용 가능.
-`[targets..]`를 지정하지 않으면 `sd.config.ts`에 정의된 전체 패키지 대상으로 실행된다.
-타겟은 패키지 경로로 지정한다 (예: `packages/core-common`, `tests/orm`).
+All commands internally run `pnpm sd-cli <command>`. The `--debug` flag is available for all commands.
+If `[targets..]` is not specified, all packages defined in `sd.config.ts` are targeted.
+Targets are specified by package path (e.g., `packages/core-common`, `tests/orm`).
 
-### 개발
+### Development
 
 ​```bash
-pnpm dev [targets..]                     # client+server 패키지 개발 모드 실행
-pnpm dev packages/solid-demo             # 특정 패키지만 dev 모드
-pnpm dev -o key=value                    # sd.config.ts에 옵션 전달
+pnpm dev [targets..]                     # Run client+server packages in dev mode
+pnpm dev packages/solid-demo             # Dev mode for a specific package only
+pnpm dev -o key=value                    # Pass options to sd.config.ts
 
-pnpm watch [targets..]                   # 라이브러리 패키지 빌드 워치 모드
-pnpm watch packages/core-common          # 특정 패키지만 워치
+pnpm watch [targets..]                   # Watch mode for library package builds
+pnpm watch packages/core-common          # Watch a specific package only
 ​```
 
-### 빌드 & 배포
+### Build & Deploy
 
 ​```bash
-pnpm build [targets..]                   # 프로덕션 빌드
-pnpm build packages/solid                # 특정 패키지만 빌드
+pnpm build [targets..]                   # Production build
+pnpm build packages/solid                # Build a specific package only
 
-pnpm pub [targets..]                     # 빌드 후 배포 (npm/sftp)
-pnpm pub --no-build                      # 빌드 생략하고 배포만
-pnpm pub --dry-run                       # 실제 배포 없이 시뮬레이션
+pnpm pub [targets..]                     # Build then deploy (npm/sftp)
+pnpm pub --no-build                      # Deploy only, skip build
+pnpm pub --dry-run                       # Simulate without actual deployment
 ​```
 
-### 코드 품질 검사
+### Code Quality Checks
 
 ​```bash
-pnpm typecheck [targets..]               # TypeScript 타입 체크
-pnpm lint [targets..]                    # ESLint + Stylelint 실행
-pnpm lint:fix [targets..]               # 린트 자동 수정 (--fix)
-pnpm check [targets..]                   # 전체 검사 (typecheck + lint + test 병렬)
-pnpm vitest [targets..]                  # vitest 워치 모드
-pnpm vitest run [targets..]              # 테스트 1회 실행
+pnpm typecheck [targets..]               # TypeScript type check
+pnpm lint [targets..]                    # Run ESLint + Stylelint
+pnpm lint:fix [targets..]               # Auto-fix lint issues (--fix)
+pnpm check [targets..]                   # Full check (typecheck + lint + test in parallel)
+pnpm vitest [targets..]                  # vitest watch mode
+pnpm vitest run [targets..]              # Run tests once
 ​```
 
-## 아키텍처
+## Architecture
 
-의존 방향: 위 → 아래. `core-common`은 내부 의존 없는 leaf 패키지.
+Dependency direction: top → bottom. `core-common` is a leaf package with no internal dependencies.
 
 ​```
 Apps:     solid-demo (client) / solid-demo-server (server)
@@ -108,26 +108,26 @@ Tools:    sd-cli, lint, excel, storage, sd-claude, mcp-playwright
 ​```
 
 
-## 통합 테스트
+## Integration Tests
 
-`tests/` 폴더에 위치. `pnpm vitest run tests/orm` 등으로 실행.
+Located in the `tests/` folder. Run with `pnpm vitest run tests/orm`, etc.
 
-- `tests/orm` — DB 커넥션, DbContext, 이스케이프 테스트 (MySQL, PostgreSQL, MSSQL). Docker 필요.
-- `tests/service` — 서비스 클라이언트-서버 통신 테스트.
+- `tests/orm` — DB connection, DbContext, escape tests (MySQL, PostgreSQL, MSSQL). Requires Docker.
+- `tests/service` — Service client-server communication tests.
 
-## 코딩 규칙
+## Coding Rules
 
-- `import type` 필수 (`verbatimModuleSyntax`), `#private` 금지 → `private` 사용                                                                             
-- `console.*` 금지, `if (str)` 금지 → `str !== ""` 명시 비교 (nullable boolean/object는 허용)                                                               
-- `Buffer` 금지 → `Uint8Array`, `events` 금지 → `@simplysm/core-common`의 `EventEmitter`                                                                    
-- SolidJS: props 구조 분해 금지, `.map()` 대신 `<For>`, `className` 대신 `class`                                                                            
-- Prettier: 100자, 2칸 스페이스, 세미콜론, trailing comma, LF
+- `import type` required (`verbatimModuleSyntax`), `#private` forbidden → use `private` keyword
+- `console.*` forbidden, `if (str)` forbidden → use explicit comparison `str !== ""` (nullable boolean/object allowed)
+- `Buffer` forbidden → `Uint8Array`, `events` forbidden → `EventEmitter` from `@simplysm/core-common`
+- SolidJS: no props destructuring, use `<For>` instead of `.map()`, use `class` instead of `className`
+- Prettier: 100 chars, 2-space indent, semicolons, trailing comma, LF
 ```
 
-## Step 5: 완료 안내
+## Step 5: Completion Notice
 
-생성이 완료되면 아래를 출력하라:
+When generation is complete, output the following:
 
 ```
-CLAUDE.md가 생성되었습니다. 커밋하려면 /sd-commit 을 실행하세요.
+CLAUDE.md has been generated. Run /sd-commit to commit.
 ```

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

@@ -1,104 +1,104 @@
 ---
 name: sd-plan
-description: 이 스킬은 사용자가 "계획 세워줘", "plan 만들어", "sd-plan", "구현 계획", "작업 계획" 등을 요청할 때 사용한다.
+description: This skill is used when the user requests "make a plan", "create a plan", "sd-plan", "implementation plan", "work plan", etc.
 ---
 
-# SD Plan — 명확한 계획서 생성
+# SD Plan — Clear Plan Generation
 
-사용자의 작업 요청을 받아 초기 계획서를 생성한 뒤, 불명확한 부분을 반복적으로 검토하고 질문하여 완벽히 명확한 계획서를 만든다.
+Receives a task request from the user, generates an initial plan, then iteratively reviews and asks questions about unclear parts to produce a perfectly clear plan.
 
 ---
 
-## Step 1: 입력 확인
+## Step 1: Input Verification
 
-- 작업 설명을 아래 우선순위로 확보하라:
-  1. **작업 요청**: 사용자가 스킬 호출 시 함께 전달한 작업 설명
-  2. **현재 대화**: 작업 요청이 없으면 현재 대화 컨텍스트에서 작업 내용을 파악
-  3. **AskUserQuestion**: 위 둘로도 파악이 안 되면 "어떤 작업에 대한 계획서를 만들까요? 작업 내용을 설명해 주세요."라고 질문
-- 충분한 작업 설명을 확보한 후 Step 2로 진행하라.
+- Obtain the task description in the following priority order:
+  1. **Task request**: The task description provided by the user when invoking the skill
+  2. **Current conversation**: If no task request is provided, determine the task from the current conversation context
+  3. **AskUserQuestion**: If neither of the above is sufficient, ask "What task should I create a plan for? Please describe the task."
+- Proceed to Step 2 after obtaining a sufficient task description.
 
 ---
 
-## Step 2: 계획서 생성 + 명확화 반복
+## Step 2: Plan Generation + Clarification Loop
 
-### 2-1. 초안 작성
+### 2-1. Draft Creation
 
-계획서 초안을 작성하라. 반드시 TDD원칙에 따라 작성하라:
-- 코드 작업이면 → 테스트 코드 먼저 작성
-- 비코드 작업이면 → 자체 검증 체크리스트 먼저 정의
-- 코드 작업이지만 프로젝트 자체에 테스트환경 자체가 구축되어있지 않다면 → CLI, dry-run등의 검증방법 제시
+Draft the plan. Always follow TDD principles:
+- For code tasks → Write test code first
+- For non-code tasks → Define a self-verification checklist first
+- For code tasks where the project has no test environment set up → Propose verification methods such as CLI or dry-run
 
-### 2-2. 명확화 사이클
+### 2-2. Clarification Cycle
 
-아래를 **불명확 항목이 0개가 될 때까지** 반복하라:
+Repeat the following **until there are 0 unclear items**:
 
-1. **추출**: 계획서를 아래 "불명확 판단 기준" 12개 항목에 전부 대조하여 불명확 항목을 나열하라.
-2. **의존성 분석**: 항목 간 의존 관계를 파악하라. ("A가 정해져야 B를 질문 가능" → B는 A에 의존)
-3. **질문**: 의존 대상이 없는 항목들을 AskUserQuestion 도구 **하나당 단 하나의 질문**만 하라. 각 질문에 2~5개 선택지를 제시하라.
-   - `한건의 설명제시 -> AskUserQuestion` 반복
-4. **반영**: 답변을 모두 반영하여 계획서를 업데이트하고, 1번으로 돌아가라.
+1. **Extract**: Compare the plan against all 12 "Ambiguity Criteria" listed below and enumerate all unclear items.
+2. **Dependency analysis**: Identify dependencies between items. ("A must be decided before B can be asked" → B depends on A)
+3. **Ask**: For items with no dependencies, use AskUserQuestion with **exactly one question per tool call**. Provide 2-5 options for each question.
+   - For each item, repeat "present one explanation -> AskUserQuestion"
+4. **Apply**: Incorporate all answers to update the plan, then return to step 1.
 
-불명확 항목 0개 → **Step 2.5 최종 검증**으로 이동.
+0 unclear items → Move to **Step 2.5 Final Verification**.
 
-### 불명확 판단 기준
+### Ambiguity Criteria
 
-> **핵심 원칙**: 사용자가 명시하지 않았고, 코드베이스에서 확인되지 않은 것은 **모두 추측/가정으로 간주**하여 불명확 항목으로 취급하라. Claude가 자신있게 작성했더라도 출처가 불분명하면 불명확이다.
+> **Core principle**: Anything not explicitly stated by the user and not confirmed in the codebase is **treated as speculation/assumption** and classified as an unclear item. Even if Claude wrote it confidently, it is unclear if the source is unverified.
 
-아래 12개 항목을 **매 검토 시 전부** 대조하라. "해당 없음"이라고 넘기려면 구체적 근거(사용자 발언 또는 코드베이스 확인)가 있어야 한다.
+Compare against all 12 items below **during every review**. To skip an item as "not applicable", there must be concrete evidence (user statement or codebase confirmation).
 
-1. **사용자 미명시 가정**: 사용자가 말하지 않았는데 Claude가 채워넣은 결정사항
-2. **구체성 부족**: HOW 없이 "적절히 처리", "필요에 따라" 등의 표현
-3. **범위 모호**: IN/OUT 스코프가 정의되지 않음
-4. **미지정 동작**: 에러, 유효하지 않은 입력, 기본값 등이 지정되지 않음
-5. **알 수 없는 제약조건**: 성능, 호환성, 플랫폼 요구사항이 불분명
-6. **누락된 엣지케이스**: 경계 조건, 동시성, 빈 상태 등
-7. **모호한 파일/함수 참조**: 구체적 경로 없이 "관련 파일을 수정" 등
-8. **불명확한 순서/의존성**: 단계 간 선후 관계 미명시
-9. **추측 표현**: "아마", "~일 수 있음", "TBD", "???" 등
-10. **통합 세부사항 누락**: API 계약, 데이터 형식, 인터페이스 미정의
-11. **실패/롤백 전략 부재**: 실패 시 대응 방안 없음
-12. **검증 방법 미정의**: 구현 단계에 대응하는 검증 방법이 없음
+1. **Unstated user assumptions**: Decisions filled in by Claude that the user did not specify
+2. **Lack of specificity**: Expressions like "handle appropriately", "as needed" without explaining HOW
+3. **Ambiguous scope**: IN/OUT scope is not defined
+4. **Unspecified behavior**: Errors, invalid inputs, default values, etc. are not specified
+5. **Unknown constraints**: Performance, compatibility, or platform requirements are unclear
+6. **Missing edge cases**: Boundary conditions, concurrency, empty states, etc.
+7. **Vague file/function references**: "Modify related files" without specific paths
+8. **Unclear ordering/dependencies**: Precedence between steps is not specified
+9. **Speculative expressions**: "Probably", "might be", "TBD", "???", etc.
+10. **Missing integration details**: API contracts, data formats, interfaces are undefined
+11. **No failure/rollback strategy**: No response plan for failures
+12. **Undefined verification methods**: No verification method corresponding to an implementation step
 
 ---
 
-## Step 2.5: 최종 검증 (불명확 없음 선언 전 필수)
+## Step 2.5: Final Verification (Required Before Declaring No Ambiguities)
 
-"불명확 없음"을 선언하기 **직전에 반드시** 아래를 수행하라:
+**Immediately before** declaring "no ambiguities", you must perform the following:
 
-1. 계획서의 **모든 단계를 처음부터 끝까지** 다시 읽으며, 위 12개 기준을 한 번 더 전수 대조하라.
-2. 특히 다음을 집중 확인하라:
-   - Claude가 스스로 결정한 부분 중 사용자 확인을 받지 않은 것이 있는가?
-   - "~한다", "~로 처리한다" 등 단정적으로 쓴 부분의 근거가 사용자 발언 또는 코드베이스에 있는가?
-   - 구체적 파일 경로, 함수명, 데이터 구조가 빠진 곳은 없는가?
-3. 이 검증에서 **하나라도** 불명확 항목이 발견되면 Step 2의 질문 사이클로 돌아가라.
-4. 진짜로 없으면 → Step 3으로 이동.
+1. Re-read **every step of the plan from beginning to end**, comparing against the 12 criteria one more time.
+2. Pay special attention to the following:
+   - Are there any parts that Claude decided on its own without user confirmation?
+   - Do all definitive statements (e.g., "will do X", "will handle as Y") have supporting evidence from user statements or the codebase?
+   - Are there any places missing specific file paths, function names, or data structures?
+3. If **even one** unclear item is found during this verification, return to the question cycle in Step 2.
+4. If truly none remain → Move to Step 3.
 
 ---
 
-## Step 3: 최종 출력
+## Step 3: Final Output
 
-모든 불명확 항목이 해소되었으면 완성된 계획서를 사용자에게 제시하고, AskUserQuestion으로 구현 승인을 요청하라.
+Once all unclear items have been resolved, present the completed plan to the user and request implementation approval via AskUserQuestion.
 
-사용자가 승인하면 `.tmp/plans/{yyMMddHHmmss}_{topic}.md`에 계획서를 Write하라.
-- 파일명 예시: `260311143052_progress-컴포넌트-추가.md`
-- `yyMMddHHmmss`: 연월일시분초 (예: 260311143052)
-- `{topic}`: 작업 내용 기반 짧은 케밥케이스 (예: progress-컴포넌트-추가)
+If the user approves, Write the plan to `.tmp/plans/${TS}_{topic}.md`.
+- Generate the timestamp first: `TS=$(date +%y%m%d%H%M%S)`
+- Filename example: `260311143052_add-progress-component.md`
+- `{topic}`: Short kebab-case based on the task content (e.g., add-progress-component)
 
 ---
 
-## Step 4: 구현 완료 후 안내
+## Step 4: Post-Implementation Guidance
 
-사용자가 구현을 승인하면, 계획서에 따라 구현하라. 구현이 완료되면 아래 안내를 출력하라:
+If the user approves implementation, implement according to the plan. Once implementation is complete, output the following guidance:
 
-- **코드 수정이 포함된 경우**:
+- **If code changes are included**:
   ```
-  구현이 완료되었습니다. 다음 단계를 순서대로 실행하는 것을 권장합니다:
-  1. /sd-check — 타입체크 + 린트 + 테스트 검사 및 자동 수정
-  2. /sd-simplify — 변경된 코드 단순화 리뷰
-  3. /sd-commit — 변경사항 커밋
+  Implementation is complete. It is recommended to run the following steps in order:
+  1. /sd-check — Type check + lint + test inspection and auto-fix
+  2. /sd-simplify — Simplification review of changed code
+  3. /sd-commit — Commit changes
   ```
 
-- **코드 수정이 없는 경우** (설정, 문서 등):
+- **If no code changes are involved** (configuration, documentation, etc.):
   ```
-  구현이 완료되었습니다. 커밋하려면 /sd-commit 을 실행하세요.
+  Implementation is complete. Run /sd-commit to commit the changes.
   ```

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

@@ -1,126 +1,126 @@
 ---
 name: sd-readme
-description: "README 문서 생성", "sd-readme" 등을 요청할 때 사용.
+description: Used when requesting "README documentation generation", "sd-readme", etc.
 ---
 
-# SD Readme — 모노레포 패키지 README 문서 생성기
+# SD Readme — Monorepo Package README Documentation Generator
 
-모노레포의 각 패키지에 대해 README.md 문서를 자동 생성한다. 패키지 규모에 따라 단일 README.md 또는 README.md + docs/*.md 구조로 점진적 공개(Progressive Disclosure) 원칙을 적용한다.
+Automatically generates README.md documentation for each package in the monorepo. Applies Progressive Disclosure principles by choosing either a single README.md or a README.md + docs/*.md structure depending on the package size.
 
-ARGUMENTS: 패키지명 (선택). 지정하면 해당 패키지만 처리, 미지정 시 전체 패키지 병렬 처리.
+ARGUMENTS: Package name (optional). If specified, only that package is processed; if omitted, all packages are processed in parallel.
 
-## 작업 방법
+## Workflow
 
 ```mermaid
 flowchart TD
-    A[인자 파싱] --> B{패키지명 지정?}
-    B -- Yes --> C[README.md 생성]
-    B -- No --> D[public 패키지 목록 수집]
-    D --> E[패키지별 Agent 병렬 실행]
-    E -- 각 Agent --> C
+    A[Parse arguments] --> B{Package name specified?}
+    B -- Yes --> C[Generate README.md]
+    B -- No --> D[Collect public package list]
+    D --> E[Run Agent per package in parallel]
+    E -- Each Agent --> C
 ```
 
-### A. 인자 파싱
+### A. Parse Arguments
 
-스킬 호출 시 전달된 ARGUMENTS에서 패키지명을 추출하라.
+Extract the package name from the ARGUMENTS passed when invoking the skill.
 
-- **패키지명 지정됨** → `packages/` 하위에서 해당 디렉토리를 찾아 바로 **C. README.md 생성**으로 이동.
-- **패키지명 미지정** → **D. public 패키지 목록 수집**으로 이동.
+- **Package name specified** → Find the corresponding directory under `packages/` and proceed directly to **C. Generate README.md**.
+- **Package name not specified** → Proceed to **D. Collect public package list**.
 
-### C. README.md 생성
+### C. Generate README.md
 
-대상 패키지 하나에 대해 아래를 수행하라.
+Perform the following for a single target package.
 
-#### C-1. package.json 분석
+#### C-1. Analyze package.json
 
-`packages/<name>/package.json`을 읽어라:
+Read `packages/<name>/package.json`:
 
-1. `name` 및 `description`을 확인하라.
-2. `"private": true`이면 해당 패키지를 **건너뛰어라**.
-3. 패키지 진입점 소스코드가 무엇인지 확인하라.
+1. Check the `name` and `description` fields.
+2. If `"private": true`, **skip** this package.
+3. Identify the package entry point source code.
 
-#### C-2. 소스 코드 분석
+#### C-2. Analyze Source Code
 
-1. 진입점 파일 및 export를 재귀적으로 모두 읽어, 모든 public API를 수집하라.
-2. JSDoc 주석이 있으면 각 항목의 설명으로 활용하라.
+1. Recursively read the entry point file and all exports to collect every public API.
+2. If JSDoc comments exist, use them as descriptions for each item.
 
-#### C-3. 문서 구조 결정 및 생성
+#### C-3. Determine Document Structure and Generate
 
-소스 코드의 규모와 논리적 카테고리 수를 보고, 아래 두 가지 중 적절한 구조를 **자율적으로** 판단하라:
+Examine the source code size and the number of logical categories, then **autonomously** decide which of the two structures below is appropriate:
 
-- **단일 README.md**: 패키지가 작고 API가 적어 카테고리 분류가 불필요한 경우
-- **README.md + docs/*.md**: 패키지가 크거나 논리적 카테고리가 여러 개인 경우
+- **Single README.md**: When the package is small, has few APIs, and category classification is unnecessary
+- **README.md + docs/*.md**: When the package is large or has multiple logical categories
 
-기존 README.md 또는 docs/가 있으면 기존 내용을 기반으로 **변경된 부분만 수정**하라. 기존 문서가 없으면 새로 생성하라.
-구조가 변경되는 경우(B→A) 불필요해진 `docs/` 디렉토리를 삭제하라.
-**영어**로 작성하라.
+If an existing README.md or docs/ directory exists, **modify only the changed parts** based on the existing content. If no existing documentation exists, create it from scratch.
+If the structure changes (B to A), delete the now-unnecessary `docs/` directory.
+Write in **English**.
 
-#### C-4. package.json files 필드 관리
+#### C-4. Manage package.json files Field
 
-`docs/` 디렉토리 생성·삭제 시 `package.json`의 `files` 배열을 함께 업데이트하라:
+When creating or deleting the `docs/` directory, update the `files` array in `package.json` accordingly:
 
-- **구조 B 적용 시**: `files`에 `"docs"` 항목이 없으면 추가하라.
-- **구조 A 적용 시**: `files`에 `"docs"` 항목이 있으면 제거하라.
+- **When applying Structure B**: If the `files` array does not contain `"docs"`, add it.
+- **When applying Structure A**: If the `files` array contains `"docs"`, remove it.
 
 ---
 
-##### 구조 A: 단일 README.md (소규모 패키지)
+##### Structure A: Single README.md (Small Packages)
 
-`packages/<name>/README.md` 파일을 생성하라:
+Create the `packages/<name>/README.md` file:
 
 ```markdown
 # <package-name from package.json>
 
 > <description from package.json>
 
-<패키지의 주요 기능과 목적에 대한 상세 설명을 영어로 작성>
+<Write a detailed description of the package's main features and purpose in English>
 
 ## API Reference
 
 ### <exportedName>
 
 ```typescript
-<export 시그니처 코드>
+<export signature code>
 ```
 
-<해당 API에 대한 설명>
+<Description of this API>
 
 ---
 
-(... 모든 exported 항목에 대해 반복 ...)
+(... Repeat for all exported items ...)
 
 ## Usage Examples
 
 ```typescript
 import { ... } from "<package-name>";
 
-// 주요 사용 예제 코드
+// Main usage example code
 ```
 ```
 
 ---
 
-##### 구조 B: README.md + docs/*.md (대규모 패키지)
+##### Structure B: README.md + docs/*.md (Large Packages)
 
-**README.md** — `packages/<name>/README.md` 파일을 생성하라:
+**README.md** — Create the `packages/<name>/README.md` file:
 
 ```markdown
 # <package-name from package.json>
 
 > <description from package.json>
 
-<패키지의 주요 기능과 목적에 대한 상세 설명을 영어로 작성>
+<Write a detailed description of the package's main features and purpose in English>
 
 ## Documentation
 
 | Category | Description |
 |----------|-------------|
-| [<Category1>](docs/<category1>.md) | <카테고리 설명 및 주요 항목 나열> |
-| [<Category2>](docs/<category2>.md) | <카테고리 설명 및 주요 항목 나열> |
+| [<Category1>](docs/<category1>.md) | <Category description and list of key items> |
+| [<Category2>](docs/<category2>.md) | <Category description and list of key items> |
 | ... | ... |
 ```
 
-**docs/*.md** — 각 카테고리별로 `packages/<name>/docs/<category>.md` 파일을 생성하라:
+**docs/*.md** — Create a `packages/<name>/docs/<category>.md` file for each category:
 
 ```markdown
 # <Category Name>
@@ -128,39 +128,39 @@ import { ... } from "<package-name>";
 ## <exportedName>
 
 ```typescript
-<export 시그니처 코드>
+<export signature code>
 ```
 
-<해당 API에 대한 설명>
+<Description of this API>
 
 ---
 
-(... 이 카테고리의 모든 exported 항목에 대해 반복 ...)
+(... Repeat for all exported items in this category ...)
 
 ## Usage Examples
 
 ```typescript
 import { ... } from "<package-name>";
 
-// 이 카테고리의 주요 사용 예제 코드
+// Main usage example code for this category
 ```
 ```
 
-카테고리명과 분류는 소스 코드의 디렉토리 구조, 기능적 유사성 등을 고려하여 자율적으로 결정하라.
+Determine category names and classifications autonomously, considering the source code directory structure, functional similarity, etc.
 
 ---
 
-### D. public 패키지 목록 수집
+### D. Collect Public Package List
 
-`packages/*/package.json`을 Glob으로 탐색하되, `private: true`인 패키지는 제외하라.
+Use Glob to search `packages/*/package.json`, excluding packages with `private: true`.
 
 ---
 
-### E. 패키지별 Agent 병렬 실행
+### E. Run Agent Per Package in Parallel
 
-남은 각 패키지에 대해 Agent 도구를 사용하여 **병렬로** 다음 프롬프트를 전달하라:
+For each remaining package, use the Agent tool to pass the following prompt **in parallel**:
 ```
-/sd-readme <패키지명>
+/sd-readme <package-name>
 ```
 
-모든 subagent가 완료되면 종료.
+Terminate once all subagents have completed.