@simplysm/sd-claude 13.0.62 → 13.0.64

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,38 @@ 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.**
+
+1. Silently check ALL of these categories for unanswered questions:
+   - **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
+2. If ANY new question emerges → ask it, then **restart from step 1**
+3. Only when zero questions remain across ALL categories → proceed to exploring approaches.
+
+**Rules:**
+- Each loop must seriously re-examine all categories, not just skim.
+- Looping only once is suspicious — double-check.
+- 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 +56,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-plan/SKILL.md

@@ -4,153 +4,103 @@ description: Use when you have a spec or requirements for a multi-step task, bef
 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.
+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.
 
-**Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`
-
-## The Process
-
-**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
-
-**Ask about anything you're not 100% confident about.** Examples:
-
-- 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.
-
-**Yolo mode:** Execute all steps sequentially.
+## Remember
+- Exact file paths always
+- Complete code in plan (not "add validation")
+- Exact commands with expected output
+- DRY, YAGNI, TDD, frequent commits
 
-- 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
+## Execution Handoff
 
-**Yolo sd-check:** NEVER check only modified packages. Trace reverse dependencies and include all affected paths.
+After saving the plan:
 
-## 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.64",
   "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