@simplysm/sd-claude 13.0.62 → 13.0.65

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

@@ -0,0 +1,40 @@
+# Claude Code Rules
+
+## Language
+
+Respond in the **system's configured language** (set via Claude Code's language setting).
+
+- Technical terms, code identifiers (variable names, function names, etc.), and library names should remain as-is
+- Show English error messages and logs in their original form, but provide explanations in the system language
+
+## Missing References
+
+If a referenced file or document cannot be found, **stop immediately and ask the user for the correct path.**
+
+- Do NOT skip or proceed on your own judgment.
+- Responses like "I couldn't find the file, so I'll skip it" are strictly prohibited.
+- Always confirm with the user before proceeding.
+
+## Scope of Work
+
+**Do only what is explicitly asked.** Never perform work that was not requested.
+
+### Questions vs. Code Requests — CRITICAL
+
+- **If the user asks a question** (e.g., "이건 왜 이래?", "이거 뭐야?", "어떻게 동작해?") → **answer with text only**. Do NOT edit, write, or create any files.
+- **If the user discusses, explains, or shares opinions** → **respond with text only**. Do NOT touch any files.
+- **Only edit/write/create files when the user explicitly requests code changes** (e.g., "수정해줘", "만들어줘", "변경해줘", "추가해줘", "고쳐줘").
+- Reading files to answer a question is fine. **Modifying files to answer a question is prohibited.**
+
+### General Rules
+
+- When the user says "ask", "request", or "confirm" → **ask the user**. Do NOT decide or create it yourself.
+- Do NOT add features, refactoring, improvements, or documentation beyond the requested scope.
+- When in doubt, **ask first** before proceeding.
+- Responses like "I'll create it myself" or "I'll add that as well" are strictly prohibited.
+
+## Bug Workarounds
+
+### AskUserQuestion UI Clipping
+
+Before calling `AskUserQuestion`, output **2 blank lines** (`\n\n`) so the preceding text is not clipped in the UI.

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

@@ -15,21 +15,62 @@ Start by understanding the current project context, then ask questions one at a
 ## The Process
 
 **Understanding the idea:**
-
 - Check out the current project state first (files, docs, recent commits)
 - Ask questions one at a time to refine the idea
 - Prefer multiple choice questions when possible, but open-ended is fine too
 - Only one question per message - if a topic needs more exploration, break it into multiple questions
 - Focus on understanding: purpose, constraints, success criteria
 
-**Exploring approaches:**
+**Gap review loop:**
+
+When you think you've asked enough, **STOP and run a gap review before moving on.**
+
+Tell the user you're running a gap review, then check ALL categories. For each ✅, you MUST **cite specific evidence** (which Q&A, code reference, or explicit user requirement). "I already know" is not evidence.
+
+| Category | Check for... |
+|----------|-------------|
+| Scope | What's in? What's explicitly out? |
+| User flows | All inputs, outputs, feedback, navigation |
+| Edge cases | Empty states, errors, limits, concurrency, undo |
+| Data | Shape, validation, persistence, migration, relationships |
+| Integration | How does this connect to existing code/systems? |
+| Non-functional | Performance, accessibility, security, i18n |
+| Assumptions | Anything you assumed but never confirmed |
+
+Output format — cite evidence for each:
+- `✅ Scope — [Q2: user confirmed X / code at file:line / requirement doc says Y]`
+- `❓ Edge cases — gap: [what's missing]`
 
+If evidence is vague ("obvious", "I already know", "common sense") → mark as ❓, not ✅.
+
+- If ANY ❓ exists → ask about it. After the user answers, **run the full checklist again from scratch**.
+- Only when ALL categories show ✅ with cited evidence → proceed to exploring approaches.
+
+**All-✅ on first run is PROHIBITED — not "suspicious", prohibited.**
+If your first gap review shows all ✅:
+1. You are rubber-stamping. Prior investigation ≠ complete design exploration.
+2. Pick the 2 weakest categories (thinnest evidence).
+3. Write one concrete unasked question per category.
+4. Ask those questions, then re-run the full checklist from scratch.
+
+| Excuse | Reality |
+|--------|---------|
+| "Requirements are already clear" | Clear requirements ≠ complete design. Edge cases, error states, integration points still need exploration. |
+| "I already investigated the code" | Code investigation reveals what IS. Design exploration asks what SHOULD BE. Different activities. |
+| "It's just a bug fix" | Bug fixes have edge cases: error states, concurrent access, timing changes, consumer compatibility. |
+| "User is frustrated/in a hurry" | Rushing causes exactly the mistakes brainstorming prevents. Slow down. |
+
+**Rules:**
+- You MUST show the checklist to the user every time you run it. No silent/internal-only checks.
+- Each run must re-examine ALL categories from zero — do not carry over previous results.
+- When in doubt, ask. One extra question costs less than a flawed design.
+
+**Exploring approaches:**
 - Propose 2-3 different approaches with trade-offs
 - Present options conversationally with your recommendation and reasoning
 - Lead with your recommended option and explain why
 
 **Presenting the design:**
-
 - Once you believe you understand what you're building, present the design
 - Break it into sections of 200-300 words
 - Ask after each section whether it looks right so far
@@ -39,15 +80,56 @@ Start by understanding the current project context, then ask questions one at a
 ## After the Design
 
 **Documentation:**
-
 - Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
 - Commit the design document to git
 
-**STOP here.** Report the result to the user in the **system's configured language**:
+**Next Steps Guide:**
+
+Present the following two workflow paths so the user can see the full process and choose.
+Display the guide in the **user's configured language** (follow the language settings from CLAUDE.md or system instructions).
+
+Before presenting, check git status for uncommitted changes. If there are any uncommitted changes (staged, unstaged, or untracked files), append the warning line (shown below) at the end of the guide block.
+
+```
+Design complete! Here's how to proceed:
+
+--- Path A: With branch isolation (recommended for features/large changes) ---
+
+1. /sd-worktree add <name>  — Create a worktree branch
+2. /sd-plan                 — Break into detailed tasks
+3. /sd-plan-dev             — Execute tasks in parallel (includes TDD + review)
+4. /sd-check                — Verify (modified + dependents)
+5. /sd-commit               — Commit
+6. /sd-worktree merge       — Merge back to main
+7. /sd-worktree clean       — Remove worktree
+
+--- Path B: Direct on current branch (quick fixes/small changes) ---
+
+1. /sd-plan                 — Break into detailed tasks
+2. /sd-plan-dev             — Execute tasks in parallel (includes TDD + review)
+3. /sd-check                — Verify (modified + dependents)
+4. /sd-commit               — Commit
+
+You can start from any step or skip steps as needed.
+
+💡 "Path A: yolo" or "Path B: yolo" to auto-run all steps
+
+⚠️ You have uncommitted changes. To use Path A, run `/sd-commit all` first.
+```
 
-**"Design complete and saved to `docs/plans/<filename>.md`. Next step: `/sd-plan` to create the implementation plan."**
+- The last `⚠️` line is only shown when uncommitted changes exist. Omit it when working tree is clean.
 
-Do NOT invoke `/sd-plan` or any other skill. Do NOT auto-proceed. Wait for the user's explicit instruction.
+- After presenting both paths, **recommend one** based on the design's scope:
+   - Path A recommended: new features, multi-file changes, architectural changes, anything that benefits from isolation
+   - Path B recommended: small bug fixes, single-file changes, config tweaks, minor adjustments
+   - Briefly explain why (1 sentence)
+- Do NOT auto-proceed to any step. Present the overview with recommendation and wait for the user's choice.
+- **Yolo mode**: If the user responds with "Path A: yolo" or "Path B: yolo" (or similar intent like "A yolo", "B 자동"), execute all steps of the chosen path sequentially without stopping between steps.
+- **Yolo sd-check — include dependents**: NEVER check only modified packages. Also check all packages that depend on them:
+   1. Identify modified packages from `git diff --name-only`
+   2. Trace reverse dependencies (packages that import from modified packages) using `package.json` or project dependency graph
+   3. Include integration/e2e tests that cover the modified packages
+   4. Run `/sd-check` with all affected paths, or `/sd-check` without path (whole project) when changes are widespread
 
 ## Key Principles
 

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

@@ -10,12 +10,12 @@ model: haiku
 
 ## Overview
 
-Stages and commits changes using Conventional Commits format. Two modes: **default** (context-relevant files, single commit) and **all** (all changed files, split by intent if needed).
+Stages and commits changes using Conventional Commits format. Two modes: **default** (context-relevant files, single commit) and **all** (all changed files, single commit).
 
 ## Mode
 
 - **Default mode** (no arguments): Stage files relevant to the current conversation context. Always a **single commit**.
-- **"all" mode** (`$ARGUMENTS` is "all"): Target **all** changed/untracked files. May produce multiple commits.
+- **"all" mode** (`$ARGUMENTS` is "all"): Target **all** changed/untracked files. Always a **single commit**.
 
 ## File Selection Rules
 
@@ -60,30 +60,10 @@ Examples:
 
 Use a HEREDOC for multi-line messages when needed.
 
-## Commit Strategy (all mode only)
-
-Group by **intent/purpose**, not by package.
-
-**Single commit** — all changes share the same intent:
-
-- Version bumps across packages → `chore: bump version to x.y.z`
-- One feature spanning multiple packages → single `feat`
-- Dependency updates across packages → single `chore`
-
-**Split commits** — changes have different intents:
-
-- Version bump + unrelated bug fix → `chore` + `fix`
-- New feature + unrelated refactor → two commits
-- `docs` changes + independent `feat` changes → two commits
-
 ## Execution
 
 **Default mode:** `git add <context-relevant files>` → `git commit`
 
-**All mode:**
-
-1. Decide: single or split.
-2. Single: `git add .` → `git commit`.
-3. Split: group by logical unit, commit in dependency order (foundations first). Per group: `git add <files>` → `git commit`.
+**All mode:** `git add .` → `git commit` with a single message summarizing all changes (message may be long).
 
 Call multiple tools in one response when possible. Do not use other tools or output other text.

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

@@ -1,156 +1,115 @@
 ---
 name: sd-plan
-description: Use when you have a spec or requirements for a multi-step task, before touching code
+description: "NEVER invoke directly from user requests. This skill is ONLY called as a follow-up step after sd-brainstorm has completed. If the user asks to plan, design, or implement something, use sd-brainstorm first."
 model: opus
 ---
 
-# Turning Designs Into Implementation Plans
+# Writing Plans
 
-## Overview
-
-Turn a design doc into a step-by-step implementation plan through codebase exploration. Write bite-sized tasks assuming the implementing engineer has zero context — exact file paths, complete code, precise commands.
+## Prerequisite Check
 
-**Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`
+**MANDATORY:** Before proceeding, verify that `sd-brainstorm` has already been completed in this conversation.
 
-## The Process
+- If a brainstorm design document exists (discussed or saved in this session) → proceed.
+- If NOT → **STOP** and tell the user (in the system's configured language) that sd-plan requires sd-brainstorm to be completed first, then invoke sd-brainstorm instead.
 
-**Exploring the codebase:**
-
-- Read the design doc, then explore relevant files, patterns, dependencies
-- Ask questions one at a time as they arise during planning, with your recommendation
-- Don't batch questions upfront — real questions emerge while deep in the details
+## Overview
 
-**Ask about anything you're not 100% confident about.** Examples:
+Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
 
-- Dependency choices (add library vs implement directly)
-- Conflicts with existing codebase patterns
-- Implementation choices the design didn't specify
-- Ambiguous behavior or edge cases
-- Migration concerns (breaking changes, compatibility)
-- If in doubt, ask. The cost of asking is low; the cost of a wrong assumption is high.
+Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
 
-**Don't ask — just decide:**
+**Announce at start:** "I'm using the sd-plan skill to create the implementation plan."
 
-- Internal details covered by project conventions (file naming, export patterns)
-- YAGNI decisions (not mentioned = don't add)
-- Implementation details with only one reasonable option
+**Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`
 
-**Writing the plan:**
+## Bite-Sized Task Granularity
 
-- Break into independent tasks
-- Include exact file paths, complete code, exact commands with expected output
-- Never write "add validation" — write the actual validation code
+**Each step is one action (2-5 minutes):**
+- "Write the failing test" - step
+- "Run it to make sure it fails" - step
+- "Implement the minimal code to make the test pass" - step
+- "Run the tests and make sure they pass" - step
+- "Commit" - step
 
-## Plan Document Format
+## Plan Document Header
 
-**Header:**
+**Every plan MUST start with this header:**
 
 ```markdown
 # [Feature Name] Implementation Plan
 
 > **For Claude:** REQUIRED SUB-SKILL: Use sd-plan-dev to implement this plan task-by-task.
 
-**Goal:** [One sentence]
+**Goal:** [One sentence describing what this builds]
 
-**Architecture:** [2-3 sentences]
+**Architecture:** [2-3 sentences about approach]
 
 **Tech Stack:** [Key technologies/libraries]
 
 ---
 ```
 
-**Each task (TDD steps):**
+## Task Structure
 
-````markdown
+```markdown
 ### Task N: [Component Name]
 
 **Files:**
-
 - Create: `exact/path/to/file.ts`
 - Modify: `exact/path/to/existing.ts:123-145`
-- Test: `exact/path/to/test.spec.ts`
+- Test: `exact/path/to/tests/file.spec.ts`
 
 **Step 1: Write the failing test**
 
 ```typescript
 test("specific behavior", () => {
-  const result = fn(input);
+  const result = functionUnderTest(input);
   expect(result).toBe(expected);
 });
 ```
 
 **Step 2: Run test to verify it fails**
 
-Run: `npx vitest exact/path/to/test.spec.ts --project=node`
-Expected: FAIL with "fn is not defined"
+Run: `pnpm vitest exact/path/to/tests/file.spec.ts --run`
+Expected: FAIL with "functionUnderTest is not defined"
 
 **Step 3: Write minimal implementation**
 
 ```typescript
-export function fn(input: string): string {
+function functionUnderTest(input: InputType): OutputType {
   return expected;
 }
 ```
 
 **Step 4: Run test to verify it passes**
 
-Run: `npx vitest exact/path/to/test.spec.ts --project=node`
+Run: `pnpm vitest exact/path/to/tests/file.spec.ts --run`
 Expected: PASS
 
 **Step 5: Commit**
 
 ```bash
-git add exact/path/to/file.ts exact/path/to/test.spec.ts
+git add exact/path/to/tests/file.spec.ts exact/path/to/file.ts
 git commit -m "feat: add specific feature"
 ```
-````
-
-## After the Plan
-
-Save the plan, then present workflow paths. Check git status first. Display in the **system's configured language**:
-
-```
-Plan complete! Here's how to proceed:
-
---- Path A: With branch isolation (recommended for features/large changes) ---
-
-1. /sd-worktree add <name>  — Create a worktree branch
-2. /sd-plan-dev             — Execute tasks in parallel (includes TDD + review)
-3. /sd-check                — Verify (modified + dependents)
-4. /sd-commit               — Commit
-5. /sd-worktree merge       — Merge back to main
-6. /sd-worktree clean       — Remove worktree
-
---- Path B: Direct on current branch (quick fixes/small changes) ---
-
-1. /sd-plan-dev             — Execute tasks in parallel (includes TDD + review)
-2. /sd-check                — Verify (modified + dependents)
-3. /sd-commit               — Commit
-
-You can start from any step or skip steps as needed.
-
-💡 "Path A: yolo" or "Path B: yolo" to auto-run all steps
-
-⚠️ You have uncommitted changes. To use Path A, run `/sd-commit all` first.
 ```
 
-- The `⚠️` line only when uncommitted changes exist
-- **Recommend one** based on scope (1 sentence why)
-- Do NOT auto-proceed. Wait for user's choice.
+## Remember
+- Exact file paths always
+- Complete code in plan (not "add validation")
+- Exact commands with expected output
+- DRY, YAGNI, TDD, frequent commits
 
-**Yolo mode:** Execute all steps sequentially.
+## Execution Handoff
 
-- Each `/sd-*` step MUST be invoked via the Skill tool
-- NEVER execute underlying commands (git, npm, etc.) directly, even if you know what the skill does internally
-- If a step fails, stop and report — do not attempt manual recovery
+After saving the plan, **commit the plan document to git** before proceeding.
 
-**Yolo sd-check:** NEVER check only modified packages. Trace reverse dependencies and include all affected paths.
+Then:
 
-## Key Principles
+- If in **yolo mode** (user chose "yolo" from sd-brainstorm): Immediately proceed to sd-plan-dev without asking. No confirmation needed.
+- Otherwise: Display this message **in the system's configured language** (detect from the language setting and translate accordingly):
+  **"Plan complete and saved to `docs/plans/<filename>.md`. Ready to execute with sd-plan-dev?"**
 
-- **One question at a time** — Ask inline during planning, not batched upfront
-- **Exact everything** — File paths, complete code, commands with expected output
-- **Bite-sized steps** — Each step is one action (2-5 minutes)
-- **TDD always** — Test first, implement second, commit third
-- **DRY, YAGNI** — No unnecessary features, no repetition
-- **REQUIRED SUB-SKILL:** sd-plan-dev (fresh fork per task + two-stage review)
+- **REQUIRED SUB-SKILL:** Use sd-plan-dev
+- Fresh fork per task + two-stage review (spec compliance → code quality)

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

@@ -27,7 +27,7 @@ Analyze user request from ARGUMENTS, select the best matching sd-\* skill or age
 | `sd-plan`            | Multi-step task with spec/requirements — **planning before code**                    |
 | `sd-plan-dev`        | Already have a plan — **executing implementation plan**                              |
 | `sd-explore`         | Deep codebase analysis — tracing execution paths, architecture, dependencies         |
-| `sd-review`          | Comprehensive code review of a package or path                                       |
+| `sd-review`          | **Large-scale** comprehensive review of an entire package or broad path — use only when user explicitly requests full/deep/comprehensive review |
 | `sd-check`           | Verify code — typecheck, lint, tests                                                 |
 | `sd-commit`          | Create a git commit                                                                  |
 | `sd-readme`          | Update a package README.md                                                           |
@@ -40,15 +40,16 @@ Analyze user request from ARGUMENTS, select the best matching sd-\* skill or age
 
 | Agent                | When to select                                                    |
 | -------------------- | ----------------------------------------------------------------- |
-| `sd-code-reviewer`   | Focused review for bugs, security vulnerabilities, quality issues |
+| `sd-code-reviewer`   | Quick/focused review — specific files, recent changes, bugs, security, quality issues. **Default choice for most review requests** |
 | `sd-code-simplifier` | Simplify, clean up, improve code readability                      |
 | `sd-api-reviewer`    | Review library public API for DX quality                          |
 
 ## Selection Rules
 
 1. Select **exactly one** skill or agent — the most specific match wins
-2. If nothing matches, use **default LLM behavior** and handle the request directly
-3. Pass ARGUMENTS through as the skill/agent's input
+2. **Review requests**: Default to `sd-code-reviewer` agent. Only use `sd-review` skill when the user explicitly asks for a full/comprehensive/deep review of an entire package
+3. If nothing matches, use **default LLM behavior** and handle the request directly
+4. Pass ARGUMENTS through as the skill/agent's input
 
 ## Report Format
 

package/claude/skills/sd-worktree/sd-worktree.mjs

@@ -18,6 +18,18 @@ const mainWorktree = getOutput("git worktree list --porcelain")
   .split("\n")[0]
   .replace("worktree ", "");
 
+function detectPackageManager() {
+  if (existsSync(resolve(mainWorktree, "pnpm-lock.yaml"))) return "pnpm";
+  if (existsSync(resolve(mainWorktree, "yarn.lock"))) return "yarn";
+  if (existsSync(resolve(mainWorktree, "package-lock.json"))) return "npm";
+  if (
+    existsSync(resolve(mainWorktree, "bun.lockb")) ||
+    existsSync(resolve(mainWorktree, "bun.lock"))
+  )
+    return "bun";
+  return "npm";
+}
+
 function detectWorktreeName() {
   const cwd = process.cwd();
   const worktreesDir = resolve(mainWorktree, ".worktrees");
@@ -46,8 +58,9 @@ switch (cmd) {
     const branch = getMainBranch();
     console.log(`Creating worktree: .worktrees/${name} (from ${branch})`);
     run(`git worktree add "${worktreePath}" -b "${name}"`);
-    console.log("Installing dependencies...");
-    run("npm install", { cwd: worktreePath });
+    const pm = detectPackageManager();
+    console.log(`Installing dependencies (${pm})...`);
+    run(`${pm} install`, { cwd: worktreePath });
     console.log(`\nReady: ${worktreePath}`);
     break;
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "13.0.62",
+  "version": "13.0.65",
   "description": "Simplysm Claude Code CLI — asset installer and cross-platform npx wrapper",
   "author": "김석래",
   "license": "Apache-2.0",

package/claude/rules/sd-language.md

@@ -1,6 +0,0 @@
-# Language
-
-Respond in the **system's configured language** (set via Claude Code's language setting).
-
-- Technical terms, code identifiers (variable names, function names, etc.), and library names should remain as-is
-- Show English error messages and logs in their original form, but provide explanations in the system language