@simplysm/sd-claude 13.0.83 → 13.0.85

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,165 @@
 ---
 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.
+
+## MANDATORY RULE — ONE QUESTION PER AskUserQuestion CALL
+
+**Every AskUserQuestion call MUST have exactly 1 item in the `questions` array. NEVER bundle 2+ questions.**
+
+WRONG — bundling multiple questions:
+```
+questions: [
+  { question: "Which API style?" ... },
+  { question: "Which styling approach?" ... },
+  { question: "What default value?" ... }
+]
+```
+
+RIGHT — one question per call, sequential:
+```
+// Call 1
+questions: [{ question: "Which API style?" ... }]
+// Wait for answer → apply → re-extract unclear items
+// Call 2
+questions: [{ question: "Which styling approach?" ... }]
+// Wait for answer → apply → re-extract unclear items
+// Call 3
+questions: [{ question: "What default value?" ... }]
+```
+
+**Violating this rule makes the output unusable. There is NO exception.**
 
 ---
 
-## 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. Draft Creation
+
+Draft the plan. **Every implementation item MUST be structured as 3 sub-steps: RED → Implement → GREEN.** NEVER skip or merge these sub-steps regardless of task simplicity.
 
-### 2-1. 초안 작성
+Classify the task first, then apply the matching TDD approach:
 
-계획서 초안을 작성하라. 반드시 TDD원칙에 따라 작성하라:
-- 코드 작업이면 → 테스트 코드 먼저 작성
-- 비코드 작업이면 → 자체 검증 체크리스트 먼저 정의
-- 코드 작업이지만 프로젝트 자체에 테스트환경 자체가 구축되어있지 않다면 → CLI, dry-run등의 검증방법 제시
+**If code + test env exists:**
+1. **RED** — Write a failing test file, run it → confirm FAIL
+2. **Implement** — Write the minimum code to pass
+3. **GREEN** — Run the test → confirm PASS
 
-### 2-2. 명확화 사이클
+**If code + no test env:**
+1. **RED** — Define a CLI/dry-run command, run it → confirm FAIL
+2. **Implement** — Write the minimum code to pass
+3. **GREEN** — Run the same command → confirm PASS
 
-아래를 **불명확 항목이 0개가 될 때까지** 반복하라:
+**If non-code (config, docs, prompts, SKILL.md, etc.):**
+Prompt/config files cannot be unit-tested. Use **Agent behavioral simulation**: launch an Agent that reads the file and naturally follows its instructions with a sample task. **Do NOT tell the Agent what behavior you are testing** (this biases the result and invalidates the test).
+1. **RED** — `git stash` your changes → launch Agent with a sample task against the **original** file → confirm the Agent's output shows the **problematic** behavior (FAIL)
+2. **Implement** — `git stash pop` to restore changes, then apply your edits
+3. **GREEN** — launch same Agent with the same task against the **modified** file → confirm the Agent's output shows the **desired** behavior (PASS). If FAIL → fix implementation → re-run GREEN until PASS.
 
-1. **추출**: 계획서를 아래 "불명확 판단 기준" 12개 항목에 전부 대조하여 불명확 항목을 나열하라.
-2. **의존성 분석**: 항목 간 의존 관계를 파악하라. ("A가 정해져야 B를 질문 가능" → B는 A에 의존)
-3. **질문**: 의존 대상이 없는 항목들을 AskUserQuestion 도구 **하나당 단 하나의 질문**만 하라. 각 질문에 2~5개 선택지를 제시하라.
-   - `한건의 설명제시 -> AskUserQuestion` 반복
-4. **반영**: 답변을 모두 반영하여 계획서를 업데이트하고, 1번으로 돌아가라.
+### 2-2. Clarification Cycle
 
-불명확 항목 0개 → **Step 2.5 최종 검증**으로 이동.
+**This is a single-item loop. Each iteration handles exactly ONE unclear item, then restarts from scratch.**
 
-### 불명확 판단 기준
+1. **Extract**: Compare the plan against all 12 "Ambiguity Criteria" below → enumerate unclear items.
+   - 0 unclear items → **STOP this loop. Go to Step 2.5.**
+2. **Dependency analysis**: Identify dependencies. ("A must be decided before B" → B depends on A)
+3. **Ask exactly ONE question**: Pick the single most important item with no unresolved dependencies.
+   a. Present a brief explanation of why this item is unclear.
+   b. Call AskUserQuestion with `questions` array containing **exactly 1 item**. Include 2-5 options.
+   c. **STOP and WAIT** for the user's answer. Do NOT plan, prepare, or output anything about the next question.
+4. **Apply**: Incorporate the answer into the plan.
+5. **RESTART from step 1** — re-extract ALL unclear items from scratch. The previous answer may have resolved multiple items or created new ones. Never assume the remaining questions are still valid.
 
-> **핵심 원칙**: 사용자가 명시하지 않았고, 코드베이스에서 확인되지 않은 것은 **모두 추측/가정으로 간주**하여 불명확 항목으로 취급하라. Claude가 자신있게 작성했더라도 출처가 불분명하면 불명확이다.
+**NEVER ask 2+ questions before restarting the loop. NEVER plan ahead for "the next question". Each loop iteration = 1 Extract + 1 Question + 1 Answer.**
 
-아래 12개 항목을 **매 검토 시 전부** 대조하라. "해당 없음"이라고 넘기려면 구체적 근거(사용자 발언 또는 코드베이스 확인)가 있어야 한다.
+### Ambiguity Criteria
 
-1. **사용자 미명시 가정**: 사용자가 말하지 않았는데 Claude가 채워넣은 결정사항
-2. **구체성 부족**: HOW 없이 "적절히 처리", "필요에 따라" 등의 표현
-3. **범위 모호**: IN/OUT 스코프가 정의되지 않음
-4. **미지정 동작**: 에러, 유효하지 않은 입력, 기본값 등이 지정되지 않음
-5. **알 수 없는 제약조건**: 성능, 호환성, 플랫폼 요구사항이 불분명
-6. **누락된 엣지케이스**: 경계 조건, 동시성, 빈 상태 등
-7. **모호한 파일/함수 참조**: 구체적 경로 없이 "관련 파일을 수정" 등
-8. **불명확한 순서/의존성**: 단계 간 선후 관계 미명시
-9. **추측 표현**: "아마", "~일 수 있음", "TBD", "???" 등
-10. **통합 세부사항 누락**: API 계약, 데이터 형식, 인터페이스 미정의
-11. **실패/롤백 전략 부재**: 실패 시 대응 방안 없음
-12. **검증 방법 미정의**: 구현 단계에 대응하는 검증 방법이 없음
+> **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.
+>
+> **Exception — implementation details are NOT unclear items**: Technical decisions about HOW to achieve the goal (code placement, internal structure, naming conventions, file organization, etc.) are Claude's engineering judgment. Only user-facing requirements (WHAT behavior the user wants) should be classified as unclear. If the user did not specify it and it is purely a technical approach decision, Claude decides — do NOT ask the user.
+
+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. **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. Follow the TDD approach defined in Step 2-1 for the task type. **Do NOT proceed to the next item until the current item reaches GREEN.**
+
+### TDD Execution Rules
+
+**RED and GREEN must be actually executed. NEVER skip or substitute them.**
+
+- "User already confirmed the issue" is NOT a valid RED. Run the test yourself.
+- "Needs a separate session to verify" is NOT a valid GREEN. Run the test yourself.
+- If GREEN fails → fix the implementation → re-run GREEN. Repeat until it passes.
 
-사용자가 구현을 승인하면, 계획서에 따라 구현하라. 구현이 완료되면 아래 안내를 출력하라:
+Once all items are complete, output the following guidance. Include only the items whose conditions are met, numbered sequentially:
 
-- **코드 수정이 포함된 경우**:
-  ```
-  구현이 완료되었습니다. 다음 단계를 순서대로 실행하는 것을 권장합니다:
-  1. /sd-check — 타입체크 + 린트 + 테스트 검사 및 자동 수정
-  2. /sd-simplify — 변경된 코드 단순화 리뷰
-  3. /sd-commit — 변경사항 커밋
-  ```
+| Condition | Recommendation |
+|-----------|----------------|
+| Code changes exist | `/sd-check` — Type check + lint + test inspection and auto-fix |
+| Code changes exist | `/sd-simplify` — Simplification review of changed code |
+| Public API changed (exports, public methods/properties, component props, etc.) | `/sd-readme` — Update README documentation |
+| Always | `/sd-commit` — Commit changes |
 
-- **코드 수정이 없는 경우** (설정, 문서 등):
-  ```
-  구현이 완료되었습니다. 커밋하려면 /sd-commit 을 실행하세요.
-  ```
+Example (all conditions met):
+```
+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-readme — Update README documentation
+4. /sd-commit — Commit changes
+```