@simplysm/sd-claude 13.0.85 → 13.0.87

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

@@ -0,0 +1,149 @@
+---
+name: sd-use
+description: 사용자의 요청을 분석하여 적절한 sd-* 스킬을 자동으로 매칭하고 즉시 실행.
+argument-hint: "<요청 내용> | --help"
+---
+
+# sd-use: 자동 스킬 라우터
+
+사용자가 어떤 스킬을 써야할지 모를 때, 요청을 분석하여 적절한 sd-* 계열 스킬을 자동으로 매칭하고 즉시 실행한다.
+
+## 1. 인자 파싱
+
+`$ARGUMENTS`에서 사용자 요청 텍스트를 추출한다.
+- `$ARGUMENTS`가 `--help`이면 바로 **5. 도움말 출력** 단계로 이동한다
+- `$ARGUMENTS`가 비어있으면 현재 대화 맥락에서 요청을 파악한다
+- 대화 맥락도 없으면 AskUserQuestion으로 요청 내용을 질문한다
+
+## 2. 스킬 매칭
+
+사용자 요청의 의도를 분석하여 아래 sd-* 스킬 중 가장 적합한 스킬을 판단한다. sd-use 자신은 매칭 대상에서 제외한다.
+
+| 스킬 | 설명 | 키워드 힌트 |
+|------|------|------------|
+| sd-debug | 문제(버그, 에러, 비정상 동작)의 근본 원인을 분석하고 해결책을 제시 | 버그, 에러, 오류, 안됨, 무한루프, 크래시, 실패, 문제 |
+| sd-document | 문서 파일(.docx/.xlsx/.pptx/.pdf)을 읽어 분석하거나 새 문서를 생성 | .docx, .xlsx, .pptx, .pdf, 문서 읽기, 문서 생성, 보고서, 엑셀 |
+| sd-email-analyze | 이메일 파일(.eml/.msg)을 분석하여 헤더, 본문, 첨부파일을 추출 | .eml, .msg, 이메일, 메일 분석 |
+| sd-init | 프로젝트 설정 파일을 분석하여 CLAUDE.md를 자동 생성 | CLAUDE.md, 프로젝트 초기화, init |
+| sd-plan | 요구분석서 또는 리뷰 결과를 기반으로 TDD 방식의 구현계획서를 작성 | 구현계획, plan, 계획 수립, spec 기반 |
+| sd-plan-dev | 구현계획서를 기반으로 TDD 방식의 실제 구현을 수행 | 구현 실행, plan-dev, 계획 실행, TDD 실행 |
+| sd-readme | LLM 인덱싱용 README.md 및 docs/ 생성 | README, 문서화, 패키지 문서 |
+| sd-audit | 코드베이스를 여러 관점에서 병렬로 점검하고 승인된 결과를 문서로 저장 | 점검, 감사, 개선점, 문제점 |
+| sd-spec | 사용자 요청과 코드베이스를 분석하여 요구분석서를 작성 | 요구분석, 요구사항, spec, 기능 정의 |
+| sd-check | typecheck, lint(fix), 단위test를 순차 수행하고 에러를 자동 수정 | 품질 검사, check, typecheck, lint, 코드 검사, 자동 수정 |
+| sd-test | 테스트 대상에 대해 작업 유형별 TDD 테스트를 독립 수행 | 테스트, 테스트 작성, 유닛 테스트 |
+| sd-commit | 변경사항을 분석하여 [type] scope 형식의 커밋 메시지를 생성하고 커밋 | 커밋, commit, 변경사항 저장, git commit |
+
+키워드 힌트는 참고용이며, 최종 판단은 요청의 전체 맥락과 의도를 기준으로 한다.
+
+### 매칭 결과 분기
+
+**단일 스킬이 명확히 매칭되는 경우:**
+- 바로 3단계(스킬 실행)로 진행한다
+
+**복수 스킬이 후보인 경우 (판단 어려움):**
+- 후보 스킬들의 설명을 텍스트로 먼저 출력한다
+- AskUserQuestion으로 후보 목록을 제시하여 사용자에게 선택을 요청한다
+- 사용자가 선택한 스킬로 3단계를 진행한다
+
+**매칭 스킬이 없는 경우:**
+- "적합한 스킬을 찾을 수 없습니다."를 출력한 뒤 위 테이블의 스킬 목록을 안내하고 종료한다
+
+## 3. 스킬 안내 출력
+
+스킬을 실행하기 전에 다음 형식으로 안내를 출력한다:
+
+```
+> **`/sd-{매칭된 스킬명}`** — {스킬 설명}
+>
+> 유사 스킬: `/sd-{유사1}` (차이점), `/sd-{유사2}` (차이점)
+>
+> 다음부터는 `/sd-{매칭된 스킬명} {인자}`로 직접 호출할 수 있습니다.
+```
+
+- 유사 스킬은 위 테이블에서 매칭 스킬과 혼동될 수 있는 스킬 1~2개를 선택한다
+- 각 유사 스킬에 매칭 스킬과의 차이점을 간결히 설명한다
+- 유사 스킬이 없으면 해당 줄을 생략한다
+
+## 4. 스킬 실행
+
+사용자 요청 전체를 인자로 하여 Skill tool로 매칭된 스킬을 호출한다.
+
+## 5. 도움말 출력
+
+`--help` 인자가 주어졌을 때 아래 내용을 그대로 출력하고 종료한다:
+
+````
+## sd-* 스킬 프로세스 다이어그램
+
+### 메인 개발 파이프라인
+
+```
+  /sd-spec          /sd-audit          /sd-debug
+  (요구분석)         (코드점검)          (버그분석)
+      |                 |                  |
+      v                 v                  v
+   spec.md          audit.md           debug.md
+      |                 |                  |
+      +------------ ---+------------------+
+                   v
+               /sd-plan
+             (구현계획 작성)
+                   |
+                   v
+               plan.md
+                   |
+                   v
+             /sd-plan-dev
+          (TDD 방식 구현 수행)
+                   |
+                   v
+            코드 + 테스트
+```
+
+### 독립 스킬
+
+```
+/sd-check ─────────> typecheck + lint(fix) + test 순차 실행 + 자동 수정
+
+/sd-test ──────────> 테스트 작성 + 실행 (RED > GREEN > Refactor)
+
+/sd-readme ────────> README.md + docs/ 생성
+
+/sd-init ──────────> CLAUDE.md 자동 생성
+
+/sd-document ──────> .docx/.xlsx/.pptx/.pdf 읽기/쓰기
+
+/sd-commit ────────> 변경사항 분석 + [type] scope 커밋 메시지 생성 + 커밋
+
+/sd-email-analyze ─> .eml/.msg 분석 > 첨부파일 추출
+                         |
+                         v
+                     /sd-document (문서 첨부파일)
+```
+
+### 라우터
+
+```
+/sd-use ──> 사용자 자연어 요청을 분석하여 위 모든 sd-* 스킬로 자동 매칭
+```
+
+### 스킬 목록
+
+| 스킬 | 설명 | 사용 예시 |
+|------|------|----------|
+| `/sd-spec` | 요구분석서 작성 | `/sd-spec 로그인 기능 추가` |
+| `/sd-audit` | 병렬 코드 점검 | `/sd-audit packages/core-common` |
+| `/sd-debug` | 버그 원인 분석 | `/sd-debug 로그인 시 500 에러 발생` |
+| `/sd-plan` | TDD 구현계획 작성 | `/sd-plan .tasks/.../spec.md` |
+| `/sd-plan-dev` | 구현계획 기반 구현 | `/sd-plan-dev .tasks/.../plan.md` |
+| `/sd-check` | 코드 품질 검사 + 자동 수정 | `/sd-check packages/core-common` |
+| `/sd-test` | 독립 TDD 테스트 | `/sd-test packages/core-common/src/utils.ts` |
+| `/sd-readme` | README.md 생성 | `/sd-readme packages/core-common` |
+| `/sd-init` | CLAUDE.md 생성 | `/sd-init` |
+| `/sd-commit` | 커밋 메시지 생성 + 커밋 | `/sd-commit` |
+| `/sd-document` | 문서 읽기/쓰기 | `/sd-document report.xlsx` |
+| `/sd-email-analyze` | 이메일 분석 | `/sd-email-analyze mail.eml` |
+| `/sd-use` | 자동 스킬 매칭 | `/sd-use 로그인 버그 좀 봐줘` |
+| `/sd-use --help` | 이 가이드 표시 | `/sd-use --help` |
+````

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "13.0.85",
+  "version": "13.0.87",
   "description": "Simplysm Claude Code asset installer",
   "author": "simplysm",
   "license": "Apache-2.0",

package/claude/rules/sd-simplysm-usage.md

@@ -1,7 +0,0 @@
-# @simplysm Package Documentation
-
-When you need detailed API information, usage examples, or component props for `@simplysm/*` packages,
-read the corresponding package's README.md.
-
-1. Read the package's README.md: `packages/{package-name}/README.md`
-2. If the README.md contains a `docs/` index (Documentation table), read only the relevant category's `docs/*.md` files as needed

package/claude/skills/sd-api-review/SKILL.md

@@ -1,85 +0,0 @@
----
-name: sd-api-review
-description: Used when requesting "API review", "api-review", "sd-api-review", "API improvement", "public API review", "API intuitiveness", etc.
----
-
-# SD API Review — Public API Intuitiveness Review and Improvement
-
-Extracts the public API from the specified path (package/folder/file), compares it against relevant standards and similar libraries to derive intuitiveness improvements, then establishes an implementation plan via the `/sd-plan` process. Breaking changes are permitted, and user intuitiveness is the top priority.
-
-ARGUMENTS: Target path (required). Example: `/sd-api-review packages/my-pkg`
-
----
-
-## Step 1: Validate Arguments
-
-1. Extract the **target path** from ARGUMENTS. If no path is provided, display "Please specify a target path. Example: `/sd-api-review packages/my-pkg`" and terminate.
-
-## Step 2: Extract Public API
-
-Collect the public API of the target.
-- **Folder/file target**: Directly analyze exports from the given path
-- **Depth**: Exported symbols (classes, functions, interfaces, types, constants) + public methods/properties of exported classes
-
-If there are no exports, display "The target has no exported API." and terminate.
-
-## Step 3: Comparative Analysis and Improvement Derivation
-
-### 3-1. Determine Comparison Targets
-
-- Analyze package metadata and code contents to infer the domain, then automatically select multiple widely-used libraries in that domain.
-- Automatically include relevant standards (HTML, WAI-ARIA, Web API, TC39, JavaScript, CSS, etc.) based on the domain.
-
-### 3-2. External API Research
-
-Use WebSearch and WebFetch to research the following two axes with **equal weight**.
-Compare at the **category/pattern level** (do not search for each individual symbol).
-
-1. **Standards**: Research naming, attributes, and patterns from official specifications of domain-related standards.
-2. **Libraries**: Research APIs from official documentation of the selected libraries.
-
-### 3-3. Derive Improvements
-
-Compare the API catalog from Step 2 against external APIs to derive improvements. Review from the perspectives of naming, structure, consistency, patterns, usability, and type quality.
-
-Precautions:
-- Breaking changes are not a concern. They are fully permitted.
-- When input/output/purpose differs or behavior differs, proposals may be incorrect — this must always be recognized. (A common mistake)
-
-Each improvement must include the following:
-- **Current**: Current API state (code example)
-- **Proposed**: Improved API (code example)
-- **Reasons to change**: Rationale for the change (including standard/library comparisons)
-- **Reasons not to change**: Rationale for maintaining the current state
-
-## Step 4: Establish Implementation Plan via sd-plan
-
-Using the improvements derived in Step 3 as the task description, invoke `sd-plan` via the Skill tool. Pass the following in args:
-
-```
-The following are API improvements **proposed by LLM analysis**.
-Since the improvements are not explicitly requested modifications by the user, treat them as unclear.
-
-## Target
-<target path>
-
-## LLM-Proposed Improvements — Comparative Analysis Table
-When asking the user about unclear improvements, **always present** the following content first so the user can understand the context.
-
-```
-Improvement:
-- Current:
-- Proposed:
-- Reasons to change:
-- Reasons not to change:
-```
-
-## Required Considerations for Implementation
-1. Breaking changes are not a concern. They are fully permitted.
-2. Use Grep to search for usages of the changed API across the entire monorepo and update them together.
-3. Do not leave deprecated wrappers (clean break).
-```
-
-## Step 5: Execute the Plan
-
-Once sd-plan is complete and a finalized plan is produced, modify the code according to that plan.

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

@@ -1,72 +0,0 @@
----
-name: sd-review
-description: Used when requesting "bug review", "sd-review", "code review", "find bugs", etc. Analyzes code at the specified path for potential bugs, then creates a plan and applies fixes.
----
-
-# SD Review — Potential Bug Detection
-
-Reads the code at the specified path, analyzes it for potential bugs, then creates and executes a plan via the `/sd-plan` process.
-
-ARGUMENTS: Target path (required). Specify any path within the repo.
-
----
-
-## Step 1: Validate Arguments
-
-1. Extract the target path from ARGUMENTS.
-2. If no path is provided, display "Please specify a target path. Example: `/sd-review packages/my-pkg`" and stop.
-
-## Step 2: Bug Analysis (Do Not Modify Code)
-
-Read the code at the target path and search for potential bugs from the following 5 perspectives.
-Do not modify the code under any circumstances. Only compile and output a list of findings.
-
-**Analysis Perspectives:**
-1. **Logic/Correctness** — Incorrect conditions, off-by-one errors, wrong operators, unintended branching
-2. **Null/Undefined Safety** — Missing null checks, unused optional chaining, misuse of type assertions
-3. **Error Handling** — Swallowed errors, missing catch blocks, improper error propagation
-4. **Edge Cases** — Empty arrays/strings, boundary values, concurrency/race conditions, missing await
-5. **Resource Management** — Unclosed connections, event listener leaks, memory leak patterns
-
-Write each finding in the following format:
-```
-- **filepath:line**
-  - Current code: (excerpt of the relevant code)
-  - Problem description:
-  - Suggested fix:
-  - Reasons to fix: Rationale for applying the fix
-  - Reasons not to fix: Rationale for keeping the current code
-```
-
-If no findings are discovered, display "No potential bugs were found." and stop.
-
-## Step 3: Create Plan via sd-plan
-
-Using the list of findings from Step 2 as the task description, invoke `sd-plan` via the Skill tool. Pass the following as args:
-
-```
-The following are potential bug fixes **analyzed and suggested by the LLM**.
-Since these fixes were not explicitly requested by the user, treat them as uncertain.
-
-## Target
-<target path>
-
-## LLM-Suggested Fixes
-When asking the user about uncertain fixes, **always present** the following information first so the user can understand the context.
-
-```
-Fix:
-- Filepath:line:
-- Current code: (excerpt of the relevant code)
-- Problem description:
-- Suggested fix:
-- Reasons to fix:
-- Reasons not to fix:
-```
-
-<Full list of findings from Step 2>
-```
-
-## Step 4: Execute Plan
-
-Once sd-plan completes and produces a finalized plan, apply the code modifications according to that plan.

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

@@ -1,66 +0,0 @@
----
-name: sd-simplify
-description: Used when requesting "code simplification", "simplify", "sd-simplify", "code refinement", etc. Analyzes code at a specified path, creates a plan, and applies modifications.
----
-
-# SD Simplify — Path-Specific Code Simplification
-
-Analyzes code at a specified path using the built-in `/simplify`, then creates and executes a plan via the `/sd-plan` process.
-
-ARGUMENTS: Target path (required). Specify any path within the repository.
-
----
-
-## Step 1: Validate Arguments
-
-1. Extract the target path from ARGUMENTS.
-2. If no path is provided, display the message "Please specify a target path. Example: `/sd-simplify packages/my-pkg`" and stop.
-
-## Step 2: simplify Analysis (Do Not Modify)
-
-Invoke `simplify` using the Skill tool. Pass the following instructions as args:
-
-```
-Review the current codebase at the <target path> path. (Not recently changed code)
-Do NOT modify any code. Only compile and output a list of items to fix.
-Write each item in the following format:
-- **file-path:line**
-  - Current code: (excerpt of the relevant code)
-  - Problem description:
-  - Suggested improvement:
-  - Reasons to change: Rationale for applying the improvement
-  - Reasons not to change: Rationale for keeping the current code
-```
-
-Replace the `<target path>` placeholder with the actual path extracted in Step 1.
-
-## Step 3: Create a Plan with sd-plan
-
-Using the list of items to fix from Step 2 as the task description, invoke `sd-plan` using the Skill tool. Pass the following as args:
-
-```
-The following are code improvement suggestions **proposed by an LLM analysis**.
-Since these suggestions were not explicitly requested by the user, treat them as unclear.
-
-## Target
-<target path>
-
-## LLM-Suggested Improvements
-When asking the user about unclear suggestions, **always present** the following details first so the user can understand the context.
-
-```
-Suggestion:
-- File path:line:
-- Current code: (excerpt of the relevant code)
-- Problem description:
-- Suggested improvement:
-- Reasons to change:
-- Reasons not to change:
-```
-
-<Full list of items to fix from Step 2>
-```
-
-## Step 4: Execute the Plan
-
-Once sd-plan completes and a finalized plan is produced, modify the code according to that plan.