@simplysm/sd-claude 13.0.78 → 13.0.80

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

@@ -1,191 +1,166 @@
 ---
 name: sd-readme
-description: "Sync README.md with source code (explicit invocation only)"
-argument-hint: "<package-name or path> (optional - omit to update all)"
-model: sonnet
+description: "README 문서 생성", "sd-readme" 등을 요청할 때 사용.
 ---
 
-# sd-readme
+# SD Readme — 모노레포 패키지 README 문서 생성기
 
-Sync package README.md with current source code by comparing exports against documentation.
+모노레포의 각 패키지에 대해 README.md 문서를 자동 생성한다. 패키지 규모에 따라 단일 README.md 또는 README.md + docs/*.md 구조로 점진적 공개(Progressive Disclosure) 원칙을 적용한다.
 
-## Purpose
+ARGUMENTS: 패키지명 (선택). 지정하면 해당 패키지만 처리, 미지정 시 전체 패키지 병렬 처리.
 
-README.md is the **sole API documentation source for Claude Code**. When Claude Code works in a consumer app using `@simplysm/*` packages, it reads README.md from `node_modules/` to understand the library API. Claude Code does NOT read JSDoc from source files.
+## 작업 방법
 
-**Therefore: every exported symbol must be documented in README.**
+```mermaid
+flowchart TD
+    A[인자 파싱] --> B{패키지명 지정?}
+    B -- Yes --> C[README.md 생성]
+    B -- No --> D[public 패키지 목록 수집]
+    D --> E[패키지별 Agent 병렬 실행]
+    E -- 각 Agent --> C
+```
 
-## Modes
+### A. 인자 파싱
 
-- **Single package** (`$ARGUMENTS` = package name or path): Update one package's README
-- **Batch** (`$ARGUMENTS` empty): Discover and update all packages in parallel
+스킬 호출 시 전달된 ARGUMENTS에서 패키지명을 추출하라.
 
-## README Writing Rules
+- **패키지명 지정됨** → `packages/` 하위에서 해당 디렉토리를 찾아 바로 **C. README.md 생성**으로 이동.
+- **패키지명 미지정** → **D. public 패키지 목록 수집**으로 이동.
 
-- Written in **English**
-- All code examples must include **import paths**: `import { ... } from "@simplysm/..."`
-- **Every export** from `index.ts` must be documented — including those with `@internal` JSDoc
-- No changelog, version history, or "recently updated" sections
-- Section organization follows `index.ts` `#region` structure
-- Heading levels: `##` for major sections, `###` for sub-sections
+### C. README.md 생성
 
-### Standard Structure
+대상 패키지 하나에 대해 아래를 수행하라.
 
-```markdown
-# @simplysm/{package-name}
+#### C-1. package.json 분석
 
-{One-line description}
+`packages/<name>/package.json`을 읽어라:
 
-## Installation
+1. `name` 및 `description`을 확인하라.
+2. `"private": true`이면 해당 패키지를 **건너뛰어라**.
+3. 패키지 진입점 소스코드가 무엇인지 확인하라.
 
-## Main Modules
+#### C-2. 소스 코드 분석
 
-### {Category matching index.ts #region}
+1. 진입점 파일 및 export를 재귀적으로 모두 읽어, 모든 public API를 수집하라.
+2. JSDoc 주석이 있으면 각 항목의 설명으로 활용하라.
 
-- Description + code examples per export
+#### C-3. 문서 구조 결정 및 생성
 
-## Types
+소스 코드의 규모와 논리적 카테고리 수를 보고, 아래 두 가지 중 적절한 구조를 **자율적으로** 판단하라:
 
-## Dependencies (only when peer deps exist)
-```
+- **단일 README.md**: 패키지가 작고 API가 적어 카테고리 분류가 불필요한 경우
+- **README.md + docs/*.md**: 패키지가 크거나 논리적 카테고리가 여러 개인 경우
 
-### docs/ Subfolder Rules
+기존 README.md 또는 docs/가 있으면 기존 내용을 기반으로 **변경된 부분만 수정**하라. 기존 문서가 없으면 새로 생성하라.
+구조가 변경되는 경우(B→A) 불필요해진 `docs/` 디렉토리를 삭제하라.
+**영어**로 작성하라.
 
-When README exceeds ~500 lines, split detailed documentation into `docs/`:
+#### C-4. package.json files 필드 관리
 
-- README.md becomes an **overview/index** with links: `[functionName](docs/category.md#anchor)`
-- docs/ files contain detailed descriptions, full code examples, parameter tables
-- File organization follows index.ts `#region` (e.g., `docs/types.md`, `docs/utils.md`)
+`docs/` 디렉토리 생성·삭제 시 `package.json`의 `files` 배열을 함께 업데이트하라:
 
-When README is under ~500 lines, keep everything inline.
+- **구조 B 적용 시**: `files`에 `"docs"` 항목이 없으면 추가하라.
+- **구조 A 적용 시**: `files`에 `"docs"` 항목이 있으면 제거하라.
 
-**If docs/ already exists, maintain and update it. Do not remove an existing docs/ structure.**
+---
 
-## Single Package Mode
+##### 구조 A: 단일 README.md (소규모 패키지)
+
+`packages/<name>/README.md` 파일을 생성하라:
+
+```markdown
+# <package-name from package.json>
 
-### Step 1: Resolve Path
+> <description from package.json>
 
-`$ARGUMENTS` may be a package name or path (e.g., `core-common`, `packages/core-common`).
-If not starting with `packages/`, prepend it.
+<패키지의 주요 기능과 목적에 대한 상세 설명을 영어로 작성>
 
-### Step 2: Build Export Map (Source of Truth)
+## API Reference
 
-1. Read `<pkg-path>/src/index.ts` — get all exports and their `#region` grouping
-2. For each exported module, read the source file to extract:
-   - Function signatures (params, return type, overloads)
-   - Class public API (constructor, methods, properties)
-   - Type/interface definitions
-   - Default values, options objects
+### <exportedName>
 
-### Step 3: Build Documentation Map
+```typescript
+<export 시그니처 코드>
+```
 
-Read `<pkg-path>/README.md` (if exists). If docs/ exists, read those files too.
-Map each documented item to its current documentation content.
+<해당 API에 대한 설명>
 
-### Step 4: Diff and Report
+---
 
-Compare export map (Step 2) against documentation map (Step 3):
+(... 모든 exported 항목에 대해 반복 ...)
 
-| Status      | Meaning                              |
-| ----------- | ------------------------------------ |
-| **ADDED**   | Exported in source but not in README |
-| **REMOVED** | In README but no longer exported     |
-| **CHANGED** | Both exist but API signature differs |
-| **OK**      | Documentation matches source         |
+## Usage Examples
 
-**Report to user before editing:**
+```typescript
+import { ... } from "<package-name>";
 
+// 주요 사용 예제 코드
+```
 ```
-ADDED (3):
-  - strToCamelCase (from utils/str.ts)
-  - objGetChainValueByDepth (from utils/obj.ts)
-  - ZipArchiveProgress type (from zip/sd-zip.ts)
 
-REMOVED (1):
-  - oldFunction (no longer exported)
+---
 
-CHANGED (2):
-  - objMerge: added `deep` parameter
-  - Set.toggle: added `addOrDel` optional parameter
+##### 구조 B: README.md + docs/*.md (대규모 패키지)
 
-OK: 45 items unchanged
-```
+**README.md** — `packages/<name>/README.md` 파일을 생성하라:
+
+```markdown
+# <package-name from package.json>
 
-**Wait for user confirmation before proceeding to edit.**
+> <description from package.json>
 
-### Step 5: Apply Updates
+<패키지의 주요 기능과 목적에 대한 상세 설명을 영어로 작성>
 
-- **ADDED**: Write documentation matching existing style. Place in the section matching the item's `#region` in index.ts. Include description + code example with import path.
-- **REMOVED**: Delete the documentation entry.
-- **CHANGED**: Update existing entry to match current API. Preserve code examples if still valid.
-- **OK**: Do not touch.
+## Documentation
 
-**If README uses docs/ links**: update the corresponding docs/ file, not just README.
+| Category | Description |
+|----------|-------------|
+| [<Category1>](docs/<category1>.md) | <카테고리 설명 및 주요 항목 나열> |
+| [<Category2>](docs/<category2>.md) | <카테고리 설명 및 주요 항목 나열> |
+| ... | ... |
+```
+
+**docs/*.md** — 각 카테고리별로 `packages/<name>/docs/<category>.md` 파일을 생성하라:
 
-### Step 6: Size Check
+```markdown
+# <Category Name>
 
-After updates, if README exceeds ~500 lines and no docs/ exists:
-suggest splitting to the user (do not auto-split without confirmation).
+## <exportedName>
 
-## Batch Mode
+```typescript
+<export 시그니처 코드>
+```
+
+<해당 API에 대한 설명>
+
+---
 
-When `$ARGUMENTS` is empty:
+(... 이 카테고리의 모든 exported 항목에 대해 반복 ...)
 
-1. Discover all packages: Glob `packages/*/package.json`
-2. Launch **parallel subagents** (`subagent_type: "general-purpose"`, `model: "sonnet"`) — one per package + one for project root:
+## Usage Examples
 
-**Per-package subagent prompt template:**
+```typescript
+import { ... } from "<package-name>";
 
+// 이 카테고리의 주요 사용 예제 코드
 ```
-Update README.md for package {pkg-name} at {pkg-path}.
-
-PURPOSE: README.md is the sole API documentation source for Claude Code.
-Every exported symbol must be documented. Claude Code does NOT read JSDoc.
-
-STEPS:
-1. Read {pkg-path}/src/index.ts — get all exports and #region grouping.
-2. For each export, read the source file for signatures, classes, types.
-3. Read {pkg-path}/README.md (and docs/ if exists).
-4. Compare exports vs documentation:
-   - ADDED (in source, not in README): add documentation with description + code example.
-     Include import path: import { X } from "@simplysm/{pkg-name}"
-   - REMOVED (in README, not in source): delete documentation.
-   - CHANGED (both exist, API differs): update to match current API.
-   - OK: don't touch.
-5. Section organization follows index.ts #region structure.
-6. Write in English. No changelog sections.
-7. If README doesn't exist, create with standard structure:
-   # @simplysm/{pkg-name}
-   {description from package.json}
-   ## Installation
-   ## Main Modules (sections per #region)
-   ## Types
-8. If docs/ subfolder exists, update those files too.
-9. Report: list of ADDED/REMOVED/CHANGED items.
 ```
 
-**Project root subagent prompt:**
+카테고리명과 분류는 소스 코드의 디렉토리 구조, 기능적 유사성 등을 고려하여 자율적으로 결정하라.
+
+---
+
+### D. public 패키지 목록 수집
+
+`packages/*/package.json`을 Glob으로 탐색하되, `private: true`인 패키지는 제외하라.
+
+---
+
+### E. 패키지별 Agent 병렬 실행
 
+남은 각 패키지에 대해 Agent 도구를 사용하여 **병렬로** 다음 프롬프트를 전달하라:
 ```
-Update the project root README.md at {project-root}/README.md.
-Read CLAUDE.md for project context.
-Compare current README against project structure and packages.
-Edit only sections that are outdated. Write in English.
-Report what was changed.
+/sd-readme <패키지명>
 ```
 
-3. Collect all results. Report summary: which READMEs were updated, which had no changes.
-
-## Common Mistakes
-
-| Mistake                               | Fix                                                                 |
-| ------------------------------------- | ------------------------------------------------------------------- |
-| Skipping exports with @internal JSDoc | Document ALL exports — Claude Code doesn't read JSDoc               |
-| Rewriting OK sections                 | Only touch ADDED/REMOVED/CHANGED items                              |
-| Ignoring existing docs/ structure     | If docs/ exists, update those files too                             |
-| Arbitrary section reorganization      | Follow index.ts `#region` structure                                 |
-| Missing import paths in examples      | Always: `import { X } from "@simplysm/..."`                         |
-| Writing in non-English languages      | README must be in English                                           |
-| Adding changelog sections             | Never add version history                                           |
-| Editing before reporting diff         | Always report ADDED/REMOVED/CHANGED and wait for confirmation       |
-| Destroying docs/ link format          | If README uses `[name](docs/file.md#anchor)`, preserve that pattern |
+모든 subagent가 완료되면 종료.

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

@@ -1,182 +1,65 @@
 ---
 name: sd-review
-description: "Use when the user explicitly requests code review, refactoring analysis, or structural improvement. Covers correctness, safety, API design, conventions, complexity, duplication, and code structure. Explicit invocation only."
+description: "버그 리뷰", "bug review", "sd-review", "코드 리뷰", "버그 찾기" 등을 요청할 때 사용. 지정한 경로의 코드에서 잠재적 버그를 분석한 뒤 계획 수립을 거쳐 수정한다.
 ---
 
-# sd-review
+# SD Review — 잠재적 버그 탐지
 
-## Overview
+지정한 경로의 코드를 읽고 잠재적 버그를 분석한 뒤, `/sd-plan` 프로세스로 계획을 수립하고 실행한다.
 
-Comprehensive code analysis combining **defect review** (correctness, safety, API, conventions) and **refactoring analysis** (structure, simplification). Uses **sd-explore** to minimize redundant file reads, then dispatches reviewers with pre-filtered context.
+ARGUMENTS: 대상 경로 (필수). 레포 내 임의 경로를 지정한다.
 
-**Analysis only — no code modifications.**
-
-## Principles
-
-- **Breaking changes are irrelevant**: Reviewers must NOT dismiss findings because the fix would cause a breaking change.
-
-## Usage
-
-- `/sd-review packages/solid` — full review (all perspectives)
-- `/sd-review packages/solid focus on bugs` — selective review
-- `/sd-review packages/solid focus on refactoring` — structural analysis only
-- `/sd-review` — if no argument, ask the user for the target path
-
-## Target Selection
-
-- With argument: review source code at the given path
-- Without argument: ask the user for the target path
-
-**Important:** Review ALL source files under the target path. Do not use git status or git diff to limit scope.
-
-## Reviewer Perspectives
-
-| Reviewer | Prompt Template | Tag | Perspective |
-|----------|----------------|-----|-------------|
-| **Code Reviewer** | `code-reviewer-prompt.md` | `[CORRECTNESS]` | Correctness & Safety |
-| **API Reviewer** | `api-reviewer-prompt.md` | `[API]` | Usability & DX |
-| **Convention Checker** | `convention-checker-prompt.md` | *(all files)* | Project rules — Grep-based |
-| **Refactoring Analyzer** | `refactoring-analyzer-prompt.md` | `[REFACTOR]` | Structure & Simplification |
-
-## Reviewer Selection
-
-By default, run **all 4 reviewers**. If the user specifies a focus, select relevant reviewer(s):
-
-| User says | Run |
-|-----------|-----|
-| "bugs", "security", "safety", "architecture", "dependencies" | Code Reviewer |
-| "API", "naming", "types", "DX" | API Reviewer |
-| "conventions", "rules", "patterns" | Convention Checker |
-| "simplify", "complexity", "duplication", "structure", "module" | Refactoring Analyzer |
-| "defects", "correctness" | Code + API + Convention |
-| "refactoring", "refactor", "maintainability" | Refactoring Analyzer |
-| (no specific focus) | All 4 |
-
-## Workflow
-
-### Step 1: Prepare Context
-
-Read these files:
-- `CLAUDE.md` — project overview
-- `.claude/rules/sd-refs-linker.md` — reference guide
-- Target's `package.json` — version (v12/v13)
-
-Based on version and target, read all applicable reference files (e.g., `sd-code-conventions.md`, `sd-solid.md`).
-
-Keep the collected conventions in memory — they will be inlined into each reviewer's prompt in Step 3.
-
-### Step 2: Explore (via sd-explore)
+---
 
-Follow the **sd-explore** workflow to read all source files under the target.
+## Step 1: 인자 확인
 
-**sd-explore input:**
+1. ARGUMENTS에서 대상 경로를 추출하라.
+2. 경로가 없으면 "대상 경로를 지정해 주세요. 예: `/sd-review packages/my-pkg`"라고 안내하고 종료하라.
 
-- **Target path**: the review target directory
-- **Name**: `review`
-- **File patterns**: `**/*.ts`, `**/*.tsx` (exclude `node_modules`, `dist`)
-- **Analysis instructions**:
+## Step 2: 버그 분석 (수정 금지)
 
-"For each file:
-1. Write a 1-2 line summary of what it does
-2. Tag files that need deep review (~30-50% of files; a file can have multiple tags)
+대상 경로의 코드를 읽고 아래 5가지 관점에서 잠재적 버그를 찾아라.
+코드를 절대 수정하지 마라. 발견 항목 목록만 정리하여 출력하라.
 
-Tag criteria:
-- [CORRECTNESS] — Unguarded null/! assertions, async races, DOM manipulation (SSR risks), resource lifecycle gaps, swallowed exceptions, mutable state for sync
-- [API] — Public exports, complex type signatures/generics/overloads, props/options interfaces, naming inconsistency
-- [REFACTOR] — File > 300 lines or function > 50 lines, deep nesting (> 3 levels), similar patterns across files, mixed abstraction levels, mixed responsibilities
+**분석 관점:**
+1. **로직/정확성** — 잘못된 조건, off-by-one, 잘못된 연산자, 의도와 다른 분기
+2. **Null/Undefined 안전성** — 누락된 null 체크, optional chaining 미사용, 타입 단언 오용
+3. **에러 처리** — 삼켜진 에러, 누락된 catch, 부적절한 에러 전파
+4. **엣지 케이스** — 빈 배열/문자열, 경계값, 동시성/race condition, 누락된 await
+5. **리소스 관리** — 닫히지 않은 연결, 이벤트 리스너 누수, 메모리 릭 패턴
 
-Output format:
+각 항목은 다음 형식으로 작성하라:
 ```
-# Explore: [directory names]
-
-## File Summaries
-- `path/to/file.ts` — Brief description
-
-## Tagged Files
-### CORRECTNESS
-- `path/to/file.ts:42` — Suspected issue description
-### API
-- `path/to/file.ts` — Why this needs API review
-### REFACTOR
-- `path/to/file.ts` — Structural concern
+- **파일경로:라인** — 문제 설명 — 개선 방안
 ```
 
-Files not listed under Tagged Files are considered clean. Do NOT add tags in File Summaries — Tagged Files is the single source of truth."
-
-### Step 3: Dispatch Reviewers (Parallel)
+발견 항목이 없으면 "잠재적 버그가 발견되지 않았습니다."라고 안내하고 종료하라.
 
-Read each reviewer's prompt template. Replace:
-- `[CONVENTIONS]` → the conventions text collected in Step 1 (inline, not a file path)
-- `[EXPLORE_FILES]` → comma-separated list of explore output file paths
+## Step 3: sd-plan으로 계획 수립
 
-Dispatch selected reviewers in parallel.
+Step 2에서 도출된 발견 항목 목록을 작업 설명으로 하여, Skill 도구로 `sd-plan`을 호출하라. args에 아래를 전달하라:
 
-### Step 4: Verify & Deduplicate
-
-This is the **orchestrator-level** verification. Reviewers already self-verify, but findings can still be invalid or overlap.
-
-**MANDATORY: Read actual code for EVERY finding.** For each finding, you MUST `Read` the file at the referenced location before deciding keep/drop. Do NOT rely on reviewer descriptions alone — verify against the actual code. A finding that was not verified by reading the source code CANNOT pass this step.
-
-**Deduplication**: If multiple reviewers flag the same code location, keep the finding under the most specific reviewer:
-- Convention violation + correctness concern → Convention Checker owns it
-- API issue + structural concern → API Reviewer owns it
-- When unclear, keep the one with stronger evidence
-
-**For defect findings (Code, API, Convention):**
-
-Read the code, then drop if: self-contradicted, type-only (no runtime trigger), out of scope, duplicate, bikeshedding, severity inflated, already handled, intentional pattern, misread, tradeoff-negative.
-
-**For refactoring findings:**
-
-Read the code at both/all referenced locations, then check:
-
-- **Scope**: structural issue? within target? not a duplicate?
-- **Duplication reality**: count the actual shared lines (not the reviewer's estimate). < 30 lines → drop. Behavioral differences between the "duplicated" code → drop. Intentional Input/Normalized pattern → drop.
-- **Separation benefit**: < ~150 lines AND tightly coupled → drop. Single cohesive domain → drop. Not independently reusable → drop.
-- **By design**: established pattern used consistently → drop.
-- **Tradeoff-negative**: introduces more complexity than it removes → drop.
+```
+아래는 **LLM이 분석하여 제안한** 잠재적 버그 수정안이다.
+수정안은 사용자가 명시적으로 요청한 수정이 아니므로, 불명확한 것으로 취급하라.
 
-### Step 5: Report
+## 대상
+<대상 경로>
 
-Present **both** invalid and valid findings:
+## LLM 제안 수정안
+불명확한 수정안을 사용자에게 질문할 때, 아래 내용을 **반드시 먼저** 제시하여 사용자가 맥락을 파악할 수 있도록 하라.
 
 ```
-## Review: <target-path>
-
-### Invalid Findings
-[grouped by rejection reason — brief, one line each]
-
-### Valid Findings
-[full details for each verified finding]
+수정안:
+- 파일경로:라인:
+- 문제 설명:
+- 현재 코드: (해당 부분 코드 발췌)
+- 개선 방안:
 ```
 
-If no valid findings, report that and end here.
-
-**If valid findings exist, you MUST proceed to Step 6. Do NOT ask the user whether to apply findings directly.**
-
-### Step 6: Brainstorm Handoff
-
-Invoke **sd-brainstorm** with all valid findings as context:
-_
-"Design fixes for the following review findings.
-
-**For each finding, you MUST:**
-1. Review it thoroughly — examine the code, understand the context, assess the real impact
-2. If any aspect is unclear or ambiguous, ask the user (one question at a time, per brainstorm rules)
-3. If a finding has low cost-benefit (adds complexity for marginal gain, pure style preference, scope too small), drop it. After triage, briefly list all dropped findings with one-line reasons (no user confirmation needed).
-4. For findings worth fixing, explore approaches and design solutions
-
-Findings that survive your triage become the design scope. Apply your normal brainstorm process (gap review → approaches → design presentation) to the surviving findings as a group.
-
-<include all valid findings with their reviewer tag, file:line, problem description, and current code snippet>"
-
-sd-brainstorm then owns the full cycle: triage (with user input as needed) → design.
+<Step 2에서 도출된 발견 항목 목록 전체>
+```
 
-## Common Mistakes
+## Step 4: 계획 실행
 
-| Mistake | Fix |
-|---------|-----|
-| Using git diff to limit scope | Review ALL source files under target |
-| Skipping verification | Always verify against actual code |
-| Running all reviewers for focused requests | Match selection to user's request |
-| Building per-reviewer files from explore results | Reviewers read explore files directly — no intermediate step |
+sd-plan이 완료되어 확정된 계획서가 나오면, 그 계획서에 따라 코드를 수정하라.

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

@@ -0,0 +1,59 @@
+---
+name: sd-simplify
+description: "코드 단순화", "simplify", "sd-simplify", "코드 정제" 등을 요청할 때 사용. 지정한 경로의 코드를 분석 후 계획 수립을 거쳐 수정한다.
+---
+
+# SD Simplify — 경로 지정 코드 단순화
+
+지정한 경로의 코드를 내장 `/simplify`로 분석한 뒤, `/sd-plan` 프로세스로 계획을 수립하고 실행한다.
+
+ARGUMENTS: 대상 경로 (필수). 레포 내 임의 경로를 지정한다.
+
+---
+
+## Step 1: 인자 확인
+
+1. ARGUMENTS에서 대상 경로를 추출하라.
+2. 경로가 없으면 "대상 경로를 지정해 주세요. 예: `/sd-simplify packages/my-pkg`"라고 안내하고 종료하라.
+
+## Step 2: simplify 분석 (수정 금지)
+
+Skill 도구로 `simplify`를 호출하라. args에 아래 지침을 전달하라:
+
+```
+<대상 경로> 경로의 현재 코드베이스를 대상으로 리뷰하라. (최근 변경 코드가 아님)
+단, 코드를 절대 수정하지 마라. 수정할 점 목록만 정리하여 출력하라.
+각 항목은 다음 형식으로 작성하라:
+- **파일경로:라인** — 문제 설명 — 개선 방안
+```
+
+`<대상 경로>` 부분은 Step 1에서 추출한 실제 경로로 치환하라.
+
+## Step 3: sd-plan으로 계획 수립
+
+Step 2에서 도출된 수정할 점 목록을 작업 설명으로 하여, Skill 도구로 `sd-plan`을 호출하라. args에 아래를 전달하라:
+
+```
+아래는 **LLM이 분석하여 제안한** 코드 개선안이다.
+개선안은 사용자가 명시적으로 요청한 수정이 아니므로, 불명확한 것으로 취급하라.
+
+## 대상
+<대상 경로>
+
+## LLM 제안 개선안
+불명확한 개선안을 사용자에게 질문할 때, 아래 내용을 **반드시 먼저** 제시하여 사용자가 맥락을 파악할 수 있도록 하라.
+
+```
+개선안:
+- 파일경로:라인:
+- 문제 설명:
+- 현재 코드: (해당 부분 코드 발췌)
+- 개선 방안:
+```
+
+<Step 2에서 도출된 수정할 점 목록 전체>
+```
+
+## Step 4: 계획 실행
+
+sd-plan이 완료되어 확정된 계획서가 나오면, 그 계획서에 따라 코드를 수정하라.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "13.0.78",
+  "version": "13.0.80",
   "description": "Simplysm Claude Code CLI — asset installer",
   "author": "simplysm",
   "license": "Apache-2.0",
@@ -17,7 +17,8 @@
     "src",
     "tests",
     "scripts",
-    "claude"
+    "claude",
+    "docs"
   ],
   "sideEffects": false,
   "dependencies": {