@simplysm/sd-claude 13.0.51 → 13.0.53

package/claude/hooks/sd-notify.py

@@ -0,0 +1,17 @@
+#!/usr/bin/env python3
+import json, sys, os, subprocess
+
+data = json.load(sys.stdin)
+
+dir_name = os.path.basename(data.get("cwd", ""))
+
+ps_cmd = (
+    "Add-Type -AssemblyName System.Windows.Forms; "
+    "$notify = New-Object System.Windows.Forms.NotifyIcon; "
+    "$notify.Icon = [System.Drawing.SystemIcons]::Information; "
+    "$notify.Visible = $true; "
+    f"$notify.ShowBalloonTip(3000, 'Claude Code', '[{dir_name}] 작업 완료', "
+    "[System.Windows.Forms.ToolTipIcon]::Info); "
+    "Start-Sleep -Milliseconds 3500"
+)
+subprocess.run(["powershell.exe", "-Command", ps_cmd])

package/claude/rules/sd-directories.md

@@ -1,7 +1,7 @@
 # Directory Reference
 
 - `.cache/`: Build cache (`eslint.cache`, `typecheck-{env}.tsbuildinfo`, `dts.tsbuildinfo`). Reset: delete `.cache/`
-- `.playwright-mcp/`: Playwright MCP output directory
-  - Screenshots/snapshots must always be saved to the `.playwright-mcp/` directory
-  - When calling `browser_take_screenshot`, always prefix filename with `.playwright-mcp/` (e.g., `.playwright-mcp/screenshot.png`)
+- `.tmp/playwright/`: Playwright MCP output directory
+  - Screenshots/snapshots must always be saved to the `.tmp/playwright/` directory
+  - When calling `browser_take_screenshot`, always prefix filename with `.tmp/playwright/` (e.g., `.tmp/playwright/screenshot.png`)
   - `PLAYWRIGHT_OUTPUT_DIR` only applies to auto-generated filenames; explicitly specified filenames are resolved relative to cwd

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

@@ -39,13 +39,11 @@ Start by understanding the current project context, then ask questions one at a
 - Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
 - Commit the design document to git
 
-**Next Step:**
-
-Display in the **system's configured language**:
+**STOP here.** Report the result to the user in the **system's configured language**:
 
 **"Design complete and saved to `docs/plans/<filename>.md`. Next step: `/sd-plan` to create the implementation plan."**
 
-Do NOT auto-proceed. Wait for the user's explicit instruction.
+Do NOT invoke `/sd-plan` or any other skill. Do NOT auto-proceed. Wait for the user's explicit instruction.
 
 ## Key Principles
 

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

@@ -62,17 +62,17 @@ Replace `[path]` with user's argument, or OMIT if no argument (defaults to full
 **Output format:**
 ```
 ====== TYPECHECK: PASS ======
-[last few lines]
 
-====== LINT: FAIL ======
-[full error output]
+====== LINT: FAIL → .tmp/sd-check/lint.log ======
 
 ====== TEST: PASS (47 tests) ======
-[last few lines]
 
 ====== SUMMARY: 1/3 FAILED (lint) ======
 ```
 
+- Failed checks write full output to `.tmp/sd-check/{name}.log`
+- Use the **Read tool** to read log files for error details
+
 - **ENV-CHECK FAIL**: Environment prerequisites missing. Report to user and STOP.
 - **SUMMARY: ALL PASSED**: Complete (see Completion Criteria).
 - **SUMMARY: N/3 FAILED**: Proceed to Step 2.
@@ -82,7 +82,7 @@ Replace `[path]` with user's argument, or OMIT if no argument (defaults to full
 1. **Analyze by priority:** Typecheck → Lint → Test
    - Typecheck errors may cause lint/test errors (cascade)
 
-2. **Read failing files** to identify root cause
+2. **Read log files** (`.tmp/sd-check/{name}.log`) to see full error output, then **read failing source files** to identify root cause
 
 3. **Fix with Edit:**
    - **Typecheck:** Fix type issues

package/claude/skills/sd-check/run-checks.mjs

@@ -1,4 +1,4 @@
-import { readFileSync, existsSync } from "fs";
+import { readFileSync, existsSync, mkdirSync, writeFileSync } from "fs";
 import { resolve } from "path";
 import { spawn } from "child_process";
 
@@ -48,7 +48,7 @@ if (errors.length > 0) {
 // Phase 2: Run 3 checks in parallel
 // ══════════════════════════════════════════
 
-const TAIL_LINES = 15;
+const logDir = resolve(root, ".tmp/sd-check");
 
 function runCommand(name, cmd, args) {
   return new Promise((res) => {
@@ -69,12 +69,6 @@ function runCommand(name, cmd, args) {
   });
 }
 
-function tail(text, n) {
-  const lines = text.trimEnd().split("\n");
-  if (lines.length <= n) return text.trimEnd();
-  return "...\n" + lines.slice(-n).join("\n");
-}
-
 function extractTestCount(output) {
   const match =
     output.match(/(\d+)\s+tests?\s+passed/i) ??
@@ -96,6 +90,7 @@ const results = await Promise.all(checks.map((c) => runCommand(c.name, c.cmd, c.
 // ══════════════════════════════════════════
 
 const failed = [];
+mkdirSync(logDir, { recursive: true });
 
 for (const r of results) {
   const passed = r.code === 0;
@@ -106,12 +101,12 @@ for (const r of results) {
     if (count) label = `PASS (${count} tests)`;
   }
 
-  console.log(`\n${"=".repeat(6)} ${r.name}: ${label} ${"=".repeat(6)}`);
-
   if (passed) {
-    console.log(tail(r.output, TAIL_LINES));
+    console.log(`\n${"=".repeat(6)} ${r.name}: ${label} ${"=".repeat(6)}`);
   } else {
-    console.log(r.output.trimEnd());
+    const logFile = resolve(logDir, `${r.name.toLowerCase()}.log`);
+    writeFileSync(logFile, r.output, "utf8");
+    console.log(`\n${"=".repeat(6)} ${r.name}: ${label} → ${logFile} ${"=".repeat(6)}`);
     failed.push(r.name.toLowerCase());
   }
 }

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

@@ -4,129 +4,102 @@ description: Use when you have a spec or requirements for a multi-step task, bef
 model: opus
 ---
 
-# Writing Plans
+# Turning Designs Into Implementation Plans
 
 ## Overview
 
-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.
-
-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.
-
-**Announce at start:** "I'm using the sd-plan skill to create the implementation plan."
+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.
 
 **Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`
 
-## Clarification Phase
+## The Process
 
-**Before writing the plan**, read the design doc and explore the codebase. Then identify implementation decisions the design didn't specify.
+**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 the user about:**
-- Core behavior choices (state management approach, error handling strategy, validation UX)
-- User-facing behavior not specified (what the user sees on error, how navigation works)
-- Architectural choices with multiple valid options (which pattern, which abstraction level)
+**Ask about:**
+- Conflicts with existing codebase patterns discovered while exploring
+- Implementation choices the design didn't specify (which pattern, which abstraction level)
+- Ambiguous behavior uncovered while designing tests or file structure
 
 **Don't ask — just decide:**
 - Internal details covered by project conventions (file naming, export patterns)
-- Pure YAGNI decisions (features not mentioned = don't add)
+- YAGNI decisions (not mentioned = don't add)
 - Implementation details with only one reasonable option
 
-**Format:** Present all discovered gaps as a single numbered list with your recommended option for each. Wait for user confirmation before writing the plan.
-
-```
-Before writing the plan, I found these implementation decisions not covered in the design:
-
-1. **[Topic]**: [The gap]. I'd recommend [option A] because [reason]. Alternatively, [option B].
-2. **[Topic]**: [The gap]. I'd recommend [option] because [reason].
-...
-
-Should I proceed with these recommendations, or would you like to change any?
-```
-
-If no gaps are found, skip this phase and proceed directly to writing the plan.
+**Writing the plan:**
+- Break into independent tasks
+- Include exact file paths, complete code, exact commands with expected output
+- Never write "add validation" — write the actual validation code
 
-## Bite-Sized Task Granularity
+## Plan Document Format
 
-**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 Header
-
-**Every plan MUST start with this header:**
+**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 describing what this builds]
+**Goal:** [One sentence]
 
-**Architecture:** [2-3 sentences about approach]
+**Architecture:** [2-3 sentences]
 
 **Tech Stack:** [Key technologies/libraries]
 
 ---
 ```
 
-## Task Structure
+**Each task (TDD steps):**
 
-```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/tests/file.spec.ts`
+- Test: `exact/path/to/test.spec.ts`
 
 **Step 1: Write the failing test**
 
 ```typescript
 test("specific behavior", () => {
-  const result = functionUnderTest(input);
+  const result = fn(input);
   expect(result).toBe(expected);
 });
 ```
 
 **Step 2: Run test to verify it fails**
 
-Run: `pnpm vitest exact/path/to/tests/file.spec.ts --run`
-Expected: FAIL with "functionUnderTest is not defined"
+Run: `pnpm vitest exact/path/to/test.spec.ts --project=node`
+Expected: FAIL with "fn is not defined"
 
 **Step 3: Write minimal implementation**
 
 ```typescript
-function functionUnderTest(input: InputType): OutputType {
+export function fn(input: string): string {
   return expected;
 }
 ```
 
 **Step 4: Run test to verify it passes**
 
-Run: `pnpm vitest exact/path/to/tests/file.spec.ts --run`
+Run: `pnpm vitest exact/path/to/test.spec.ts --project=node`
 Expected: PASS
 
 **Step 5: Commit**
 
 ```bash
-git add exact/path/to/tests/file.spec.ts exact/path/to/file.ts
+git add exact/path/to/file.ts exact/path/to/test.spec.ts
 git commit -m "feat: add specific feature"
 ```
-```
+````
 
-## Remember
-- Exact file paths always
-- Complete code in plan (not "add validation")
-- Exact commands with expected output
-- DRY, YAGNI, TDD, frequent commits
+## After the Plan
 
-## Execution Handoff
-
-After saving the plan, present the following workflow paths in the **system's configured language**.
-
-Before presenting, check git status for uncommitted changes. If there are any, append the `⚠️` warning line.
+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:
@@ -153,20 +126,22 @@ You can start from any step or skip steps as needed.
 ⚠️ You have uncommitted changes. To use Path A, run `/sd-commit all` first.
 ```
 
-- The `⚠️` line is only shown when uncommitted changes exist. Omit it when working tree is clean.
-- **Recommend one** based on the plan's scope:
-  - Path A: new features, multi-file changes, architectural changes
-  - Path B: small bug fixes, single-file changes, minor adjustments
-  - Briefly explain why (1 sentence)
+- 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:** 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. **Each `/sd-*` step MUST be invoked via the Skill tool** (e.g., `Skill("sd-worktree", "add <name>")`, `Skill("sd-plan-dev")`, `Skill("sd-check")`, `Skill("sd-commit")`, `Skill("sd-worktree", "merge")`, `Skill("sd-worktree", "clean")`). Do NOT execute the underlying git/shell commands directly — always delegate to the skill.
+**Yolo mode:** Execute all steps sequentially.
+- Each `/sd-*` step MUST be invoked via the Skill tool
+- NEVER execute underlying commands (git, pnpm, etc.) directly, even if you know what the skill does internally
+- If a step fails, stop and report — do not attempt manual recovery
+
+**Yolo sd-check:** NEVER check only modified packages. Trace reverse dependencies and include all affected paths.
 
-**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
 
-- **REQUIRED SUB-SKILL:** Use sd-plan-dev
-- Fresh fork per task + two-stage review (spec compliance → code quality)
+- **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)

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

@@ -33,6 +33,8 @@ All execution uses `Task(general-purpose)` for parallel execution.
 
 Independent tasks run as **parallel Task calls in a single message**. Within each task agent, spec and quality reviews also run as **parallel sub-Task calls**.
 
+**CRITICAL: Do NOT use `run_in_background: true`** — achieve parallelism by making multiple Task calls in a single message (foreground parallel). This ensures the orchestrator waits for all tasks to complete before proceeding to the next batch, and prevents Stop hooks from firing prematurely.
+
 ## The Process
 
 ```dot
@@ -257,6 +259,7 @@ This catches cross-task integration issues early — especially when the next ba
 - Accept "close enough" on spec compliance
 - Skip review loops (issue found → fix → re-review)
 - Skip batch integration checks between batches
+- Use `run_in_background: true` on Task calls (use foreground parallel instead)
 
 **If task agent returns questions:**
 - Answer clearly and completely
@@ -275,11 +278,6 @@ This catches cross-task integration issues early — especially when the next ba
 - Escalate to user with specific error details before proceeding
 - Do NOT re-launch on potentially partially-modified files without inspection
 
-## After Completion
-
-When all tasks and final review are done, if the current working directory is inside a worktree (`.worktrees/`), guide the user to:
-- `/sd-worktree merge` — Merge the worktree branch back into main
-
 ## Integration
 
 **Related skills:**

package/dist/commands/install.js

@@ -129,7 +129,7 @@ function setupMcpConfig(projectRoot) {
       command: "node",
       args: [sdClaudeBin, "npx", "@playwright/mcp@latest", "--headless"],
       env: {
-        PLAYWRIGHT_OUTPUT_DIR: ".playwright-mcp"
+        PLAYWRIGHT_OUTPUT_DIR: ".tmp/playwright"
       }
     };
     changed = true;

package/package.json

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

package/src/commands/install.ts

@@ -189,7 +189,7 @@ function setupMcpConfig(projectRoot: string): void {
       command: "node",
       args: [sdClaudeBin, "npx", "@playwright/mcp@latest", "--headless"],
       env: {
-        PLAYWRIGHT_OUTPUT_DIR: ".playwright-mcp",
+        PLAYWRIGHT_OUTPUT_DIR: ".tmp/playwright",
       },
     };
     changed = true;