@simplysm/sd-claude 13.0.83 → 13.0.85

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

@@ -1,12 +1,18 @@
-## 요청 수행 규칙
+## Request Handling Rules
 
-- 사용자가 명시적으로 수정을 요청하지 않은 경우, 코드를 절대 수정하지 않는다. (질문등에 대해 자의적 판단 금지)
+- Never modify code unless the user explicitly requests changes. (No autonomous decisions in response to questions, etc.)
 
-## 코드 작성 규칙
+## Code Writing Rules
 
-- YAGNI 원칙 준수
+- Follow the YAGNI principle.
 
-## Playwright 규칙
+## Playwright Rules
 
-- Playwright의 모든 output(스크린샷, PDF, 다운로드 등)은 `.tmp/playwright/` 디렉토리에 저장한다.
+- All Playwright output (screenshots, PDFs, downloads, etc.) must be saved to the `.tmp/playwright/` directory.
+- When using Playwright MCP tools with a `filename` parameter, always prefix the filename with `.tmp/playwright/` (e.g., `filename: ".tmp/playwright/my-screenshot.png"`).
+- Never pass a bare filename without the `.tmp/playwright/` path prefix.
+
+## Documentation Rules for LLMs
+
+- Write in English. (including code comments)
 

package/claude/rules/sd-library-issue.md

@@ -0,0 +1,7 @@
+# Simplysm Library Issue Reporting
+
+Source code for `@simplysm/*` packages can be found in `node_modules/@simplysm/`. If debugging reveals the root cause is in the simplysm library itself, generate a GitHub issue-formatted text (title, reproduction steps, expected behavior, actual behavior) and display it to the user.
+
+**Report facts only — do not suggest fixes or include code location hints. Do not auto-submit the issue — only display the text.**
+
+The issue body must NEVER include internal analysis of library code (class names, variable names, style properties, inheritance chains, etc.). Only describe user-observable symptoms.

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

@@ -1,7 +1,7 @@
-# @simplysm 패키지 문서
+# @simplysm Package Documentation
 
-`@simplysm/*` 패키지의 API 상세 정보, 사용 예시, 컴포넌트 props 등이 필요할 때,
-해당 패키지의 README.md를 읽는다.
+When you need detailed API information, usage examples, or component props for `@simplysm/*` packages,
+read the corresponding package's README.md.
 
-1. 패키지의 README.md를 읽기: `packages/{package-name}/README.md`
-2. README.md에 `docs/` 인덱스(Documentation 테이블)가 있으면, 필요한 카테고리의 `docs/*.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/sd-statusline.py

@@ -218,8 +218,11 @@ def main():
     model = format_model(model_id) if model_id else "?"
 
     # Extract context %
-    ctx_pct = stdin_data.get("context_window", {}).get("used_percentage")
-    ctx_str = f"{ctx_pct}%" if ctx_pct is not None else "?"
+    ctx_window = stdin_data.get("context_window")
+    if ctx_window is not None:
+        ctx_str = f"{ctx_window.get('used_percentage') or 0}%"
+    else:
+        ctx_str = "?"
 
     # Read cached usage data
     cache = read_cache()

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

@@ -1,89 +1,85 @@
 ---
 name: sd-api-review
-description: "API 리뷰", "api-review", "sd-api-review", "API 개선", "공개 API 검토", "API 직관성" 등을 요청할 때 사용.
+description: Used when requesting "API review", "api-review", "sd-api-review", "API improvement", "public API review", "API intuitiveness", etc.
 ---
 
-# SD API Review — Public API 직관성 리뷰 및 개선
+# SD API Review — Public API Intuitiveness Review and Improvement
 
-지정한 경로(패키지/폴더/파일)의 public API를 추출하고, 관련 표준 및 유사 라이브러리와 비교하여 직관성 개선안을 도출한 뒤, `/sd-plan` 프로세스로 계획을 수립하여 구현한다. Breaking change를 허용하며 사용자 직관성을 최우선으로 한다.
+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: 대상 경로 (필수). 예: `/sd-api-review packages/my-pkg`
+ARGUMENTS: Target path (required). Example: `/sd-api-review packages/my-pkg`
 
 ---
 
-## Step 1: 인자 확인
+## Step 1: Validate Arguments
 
-1. ARGUMENTS에서 **대상 경로**를 추출하라. 경로가 없으면 "대상 경로를 지정해 주세요. 예: `/sd-api-review packages/my-pkg`"라고 안내하고 종료하라.
+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: Public API 추출
+## Step 2: Extract Public API
 
-대상의 public API를 수집하라.
-- **폴더/파일 대상**: 해당 경로의 export를 직접 분석
-- **깊이**: export된 심볼(클래스, 함수, 인터페이스, 타입, 상수) + export된 클래스의 public 메서드/프로퍼티
+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
 
-export가 없으면 "대상에 export된 API가 없습니다."라고 안내하고 종료하라.
+If there are no exports, display "The target has no exported API." and terminate.
 
-## Step 3: 비교 분석 및 개선안 도출
+## Step 3: Comparative Analysis and Improvement Derivation
 
-### 3-1. 비교 대상 결정
+### 3-1. Determine Comparison Targets
 
-- 패키지 메타데이터와 코드 내용을 분석하여 도메인을 추론하고, 해당 도메인에서 가장 널리 사용되는 다수의 라이브러리 자동 선정하라.
-- 관련 표준(HTML, WAI-ARIA, Web API, TC39, Javascript, CSS 등)도 도메인에 따라 자동으로 포함하라.
+- 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. 외부 API 조사
+### 3-2. External API Research
 
-WebSearch와 WebFetch를 사용하여 아래 두 축을 **동등한 비중**으로 조사하라.
-**카테고리/패턴 단위**로 비교하라 (개별 심볼마다 검색하지 않음).
+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. **표준**: 도메인 관련 표준의 공식 사양에서 네이밍, 속성, 패턴을 조사하라.
-2. **라이브러리**: 선정된 라이브러리들의 공식 문서에서 API를 조사하라.
+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. 개선안 도출
+### 3-3. Derive Improvements
 
-Step 2의 API 카탈로그와 외부 API를 비교하여 개선점을 도출하라. 네이밍, 구조, 일관성, 패턴, 사용 편의성, 타입 품질 관점에서 검토하라.
+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.
 
-주의사항:
-- Breaking change는 고려대상이 아니다. 완전히 허용된다.
-- input/output/목적이 다를경우 동작이 다른경우, 제안이 잘못될 수 있음을 반드시 인지해야함. (자주하는 실수)
+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)
 
-각 개선안은 아래를 포함하라:
-- **현재**: 현재 API 상태 (코드 예시)
-- **제안**: 개선된 API (코드 예시)
-- **전환이유**: 변경해야 하는 근거 (표준/라이브러리 비교 포함)
-- **비전환이유**: 현재 상태를 유지해도 되는 근거
+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: sd-plan으로 구현 계획 수립
+## Step 4: Establish Implementation Plan via sd-plan
 
-Step 3에서 도출된 개선안을 작업 설명으로 하여, Skill 도구로 `sd-plan`을 호출하라. args에 아래를 전달하라:
+Using the improvements derived in Step 3 as the task description, invoke `sd-plan` via the Skill tool. Pass the following in args:
 
 ```
-아래는 **LLM이 분석하여 제안한** API 개선안이다.
-개선안은 사용자가 명시적으로 요청한 수정이 아니므로, 불명확한 것으로 취급하라.
+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 제안 개선안 — 비교 분석 표
-불명확한 개선안을 사용자에게 질문할 때, 아래 내용을 **반드시 먼저** 제시하여 사용자가 맥락을 파악할 수 있도록 하라.
+## 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:
 ```
 
-## 구현 시 필수 고려사항
-1. Breaking change는 고려 대상이 아니다. 완전히 허용된다.
-2. 모노레포 전체에서 변경된 API의 사용처를 Grep으로 검색하여 함께 수정하라.
-3. deprecated 래퍼를 남기지 않는다 (clean break).
+## 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: 계획 실행
+## Step 5: Execute the Plan
 
-sd-plan이 완료되어 확정된 계획서가 나오면, 그 계획서에 따라 코드를 수정하라.
-
-## Step 6: README 업데이트 추천
-
-코드 수정이 발생한 경우, 사용자에게 `/sd-readme` 수행을 추천하라.
+Once sd-plan is complete and a finalized plan is produced, modify the code according to that plan.

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

@@ -1,69 +1,73 @@
 ---
 name: sd-check
-description: "체크", "check", "sd-check", "타입체크+린트+테스트", "전체 검사" 등을 요청할 때 사용.
+description: Used when requesting "check", "sd-check", "typecheck+lint+test", "full check", etc.
 ---
 
-# SD Check — 자동 검사 및 오류 수정 루프
+# SD Check — Automated Check and Error Fix Loop
 
-패키지 매니저를 감지하고 check 스크립트를 실행하여 결과를 확인한 뒤, 코드 오류가 있으면 sd-debug로 근본 원인을 분석·수정하고 재검사하는 과정을 오류가 없을 때까지 반복한다.
+Detects the package manager, runs the check script, reviews the results, and if there are code errors, invokes sd-debug to analyze the root cause, applies fixes, and re-runs the check. This loop repeats until all errors are resolved.
 
-ARGUMENTS: 타겟 경로 (선택, 복수 가능). 미지정 시 대화 컨텍스트에서 파악하며, 특정 타겟이 없거나 "전체/all"이면 타겟 없이 실행.
+ARGUMENTS: Target paths (optional, multiple allowed). If not specified, determined from the conversation context. If no specific target exists or "all" is specified, run without targets.
 
 ---
 
-## Step 1: 준비 (PM 감지 + 스크립트 확인 + 타겟 결정)
+## Step 1: Preparation (PM Detection + Script Verification + Target Resolution)
 
-1. **PM 감지**: 프로젝트 루트의 락 파일로 판별하라.
-   - `pnpm-lock.yaml` 존재 → `pnpm`
-   - `yarn.lock` 존재 → `yarn`
-   - `package-lock.json` 존재 → `npm`
-   - 모두 없으면 → `npm` (기본값)
-2. **스크립트 확인**: `package.json`의 `scripts.check` 존재 여부를 확인하라. 없으면 `"check 스크립트가 package.json에 정의되어 있지 않습니다."` 안내 후 **종료**.
-3. **타겟 결정**: 아래 우선순위로 결정하라.
-   1. ARGUMENTS에 명시된 타겟
-   2. 현재 대화 컨텍스트에서 파악 (사용자가 특정 패키지 작업 중인 경우)
-   3. 위 둘 모두 해당 없거나 "전체/all" → 타겟 없이 실행 (전체)
+1. **PM Detection**: Determine the package manager from the lock file in the project root.
+   - `pnpm-lock.yaml` exists → `pnpm`
+   - `yarn.lock` exists → `yarn`
+   - `package-lock.json` exists → `npm`
+   - None found → `npm` (default)
+2. **Script Verification**: Check whether `scripts.check` exists in `package.json`. If not, inform the user with `"The check script is not defined in package.json."` and **stop**.
+3. **Target Resolution**: Determine targets in the following priority order.
+   1. Targets explicitly specified in ARGUMENTS
+   2. Inferred from the current conversation context (e.g., user is working on a specific package)
+   3. If neither applies or "all" is specified → run without targets (full check)
 
-## Step 2: 검사 실행
+## Step 2: Run Check
 
 1. `mkdir -p .tmp/check` (Bash)
-2. Bash로 아래 명령을 실행하라:
+2. Run the following command via Bash:
    ```
-   $PM check [targets...] > .tmp/check/{yyMMddHHmmss}.txt 2>&1; echo "EXIT_CODE:$?" >> .tmp/check/{yyMMddHHmmss}.txt
+   TS=$(date +%y%m%d%H%M%S); $PM check [targets...] > .tmp/check/${TS}.txt 2>&1; echo "EXIT_CODE:$?" >> .tmp/check/${TS}.txt
    ```
-   - `$PM` = Step 1에서 감지한 패키지 매니저
-   - `{yyMMddHHmmss}` = 연월일시분초
-   - 타겟이 있으면 명령에 포함, 없으면 생략
-3. Read 도구로 결과 파일(`.tmp/check/{yyMMddHHmmss}.txt`)을 읽어라.
+   - `$PM` = the package manager detected in Step 1
+   - `$TS` = timestamp variable (e.g., `260312143025`)
+   - Include targets in the command if present; omit otherwise
+3. Read the result file (`.tmp/check/${TS}.txt`) using the Read tool.
 
-## Step 3: 결과 분석
+## Step 3: Analyze Results
 
-결과 파일 내용을 읽고 아래 세 가지 중 하나로 분류하라:
+Read the result file content and classify it into one of the following three categories:
 
-- **성공**: 오류 없이 모든 검사를 통과한 경우 → **Step 5(완료)**로 이동
-- **환경 오류**: 코드 문제가 아닌 환경/인프라 문제로 판단되는 경우 (예: 의존성 미설치, 메모리 부족, 명령어 없음, 네트워크 문제 등) → 사용자에게 해당 오류 내용을 보여주고 **즉시 종료**. 코드 수정을 시도하지 않는다.
-- **코드 오류**: 소스 코드의 타입 에러, 린트 위반, 테스트 실패 등으로 판단되는 경우 → **Step 4**로 이동
+- **Success**: All checks passed without errors → proceed to **Step 5 (Completion)**
+- **Environment Error**: The issue is an environment/infrastructure problem rather than a code problem (e.g., missing dependencies, out of memory, command not found, network issues, etc.) → show the error details to the user and **stop immediately**. Do not attempt code fixes.
+- **Code Error**: The issue is a source code problem such as type errors, lint violations, or test failures → proceed to **Step 4**
 
-> 위 분류는 하드코딩된 패턴 매칭이 아닌, 결과 내용을 읽고 자유롭게 판단한다.
+> The classification above should be determined by reading and interpreting the result content freely, not by hardcoded pattern matching.
 
-**반복 제한**: 현재 반복 횟수가 5회를 초과하면, 잔여 오류를 사용자에게 보고하고 `"5회 반복 후에도 오류가 남아 있습니다. 남은 오류를 확인해 주세요."` 안내 후 **종료**.
+**Iteration Limit**: If the current iteration count exceeds 5, report the remaining errors to the user, inform them with `"Errors remain after 5 iterations. Please review the remaining errors."`, and **stop**.
 
-## Step 4: 오류 분석 및 수정 (sd-debug 활용)
+## Step 4: Error Analysis and Fix (Using sd-debug)
 
-Skill 도구로 `sd-debug`를 호출하라. args에 아래 내용을 전달하라:
+Invoke `sd-debug` via the Skill tool. Pass the following content as args:
 
 ```
-아래 check 결과의 코드 오류를 분석하라.
-**중요: Step 2(코드베이스 심층 분석) 완료 후 Step 3~5를 건너뛰고, 분석 결과를 바탕으로 바로 코드를 수정하라. 진단 보고서 출력, 사용자 확인, sd-plan 호출 없이 즉시 수정한다.**
-
-<.tmp/check/{yyMMddHHmmss}.txt 의 오류 내용을 여기에 포함>
+Analyze the code errors from the check results below.
+**Important workflow instructions:**
+1. Perform Steps 1-2 thoroughly — gather problem information and conduct in-depth codebase analysis to identify the root cause. Do NOT skip or rush these steps.
+2. Output the diagnostic report from Step 3, but skip the user confirmation (do not call AskUserQuestion).
+3. Skip Steps 4-5 (do not invoke sd-plan).
+4. Based on the analysis results and diagnostic report, apply fixes directly.
+
+<Include the error content from the check result file here>
 ```
 
-sd-debug 완료 후 → **Step 2**로 복귀 (새로운 txt로 재검사)
+After sd-debug completes → return to **Step 2** (re-run check with a new txt file)
 
-## Step 5: 완료 보고
+## Step 5: Completion Report
 
-모든 검사 통과 시 아래를 출력하라:
-- 총 반복 횟수
-- 각 반복에서 수정한 내용 요약
-- 형식: `"✔ 체크 완료: {N}회 만에 모든 검사를 통과했습니다."` + 수정 내역 bullet list
+When all checks pass, output the following:
+- Total number of iterations
+- Summary of fixes made in each iteration
+- Format: `"Check complete: all checks passed after {N} iteration(s)."` + bullet list of fix details

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

@@ -1,63 +1,63 @@
 ---
 name: sd-commit
-description: "커밋", "commit", "sd-commit" 등을 요청할 때 사용.
+description: Used when requesting "commit", "sd-commit", etc.
 ---
 
-# SD Commit — 변경사항 분석 후 커밋
+# SD Commit — Analyze Changes and Commit
 
-변경사항을 스테이징하고, 변경 내용을 분석하여 커밋 메시지를 생성한 뒤 커밋한다.
+Stage changes, analyze the diff to generate a commit message, and commit.
 
-ARGUMENTS: `all` (선택). 지정하면 모든 변경사항 대상, 미지정 시 대화 내 수정 파일만 대상.
+ARGUMENTS: `all` (optional). If specified, target all changes; if omitted, target only files modified during the current conversation.
 
 ---
 
-## Step 1: 인자 파싱 및 스테이징
+## Step 1: Parse Arguments and Stage
 
-ARGUMENTS에서 `all` 여부를 확인하라.
+Check whether `all` is present in ARGUMENTS.
 
-- **`all`**: 워킹 트리의 모든 변경사항(수정, 삭제, 신규)을 스테이징하라.
-- **`all`이 아니거나 인자 없음**: 현재 대화에서 Edit 또는 Write 도구로 수정하거나 생성한 파일들만 스테이징하라. 대화 컨텍스트를 되돌아보며 해당 파일 목록을 추출하라.
+- **`all`**: Stage all changes in the working tree (modified, deleted, and new files).
+- **Not `all` or no arguments**: Stage only files that were modified or created via the Edit or Write tools during the current conversation. Review the conversation context and extract the list of those files.
 
-## Step 2: 변경사항 확인
+## Step 2: Check for Changes
 
-스테이징된 변경사항이 없으면 "커밋할 변경사항이 없습니다."라고 안내하고 **종료**하라.
+If there are no staged changes, inform the user "No changes to commit." and **stop**.
 
-## Step 3: 커밋 메시지 생성 및 커밋
+## Step 3: Generate Commit Message and Commit
 
-스테이징된 diff를 분석하여 아래 규칙에 따라 커밋 메시지를 생성하고 커밋하라.
+Analyze the staged diff and generate a commit message according to the rules below, then commit.
 
-### 커밋 메시지 규칙
+### Commit Message Rules
 
-- **Conventional Commits** 형식: prefix + 설명
-  - prefix 예: `feat`, `fix`, `refactor`, `chore`, `docs`, `style`, `test`, `perf`, `ci`, `build`
-- **subject** (첫 줄): 변경 요약. 70자 이내.
-- **body**: 빈 줄 후 주요 변경 내용을 나열. 여러 주제의 변경이 섞여 있으면 주제별로 `[prefix]` 태그를 붙여 그룹화하라.
-- 마지막에 `Co-Authored-By: Claude <noreply@anthropic.com>` 포함.
+- **Conventional Commits** format: prefix + description
+  - prefix examples: `feat`, `fix`, `refactor`, `chore`, `docs`, `style`, `test`, `perf`, `ci`, `build`
+- **subject** (first line): Summary of changes. 70 characters or fewer.
+- **body**: After a blank line, list the key changes. If changes span multiple topics, group them with `[prefix]` tags per topic.
+- Include `Co-Authored-By: Claude <noreply@anthropic.com>` at the end.
 
-단일 주제 예시:
+Single-topic example:
 ```
-feat: 사용자 인증 로직 추가
+feat: Add user authentication logic
 
-- AuthService에 JWT 토큰 검증 로직 구현
-- 로그인 페이지에 폼 유효성 검사 추가
+- Implement JWT token verification in AuthService
+- Add form validation to the login page
 
 Co-Authored-By: Claude <noreply@anthropic.com>
 ```
 
-여러 주제 예시:
+Multi-topic example:
 ```
-chore: 인증 기능 추가 및 결제 오류 수정
+chore: Add authentication feature and fix payment error
 
-[feat] 사용자 인증
-- AuthService에 JWT 토큰 검증 로직 구현
-- 로그인 페이지에 폼 유효성 검사 추가
+[feat] User authentication
+- Implement JWT token verification in AuthService
+- Add form validation to the login page
 
-[fix] 결제 모듈
-- 결제 실패 시 재시도 로직 수정
+[fix] Payment module
+- Fix retry logic on payment failure
 
 Co-Authored-By: Claude <noreply@anthropic.com>
 ```
 
-## Step 4: 결과 출력
+## Step 4: Output Result
 
-커밋 완료 후 커밋 메시지 전문을 사용자에게 보여줘라.
+After the commit is complete, show the full commit message to the user.