@simplysm/sd-claude 13.0.60 → 13.0.61

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

@@ -18,12 +18,14 @@ Write the test first. Watch it fail. Write minimal code to pass.
 ## When to Use
 
 **Always:**
+
 - New features
 - Bug fixes
 - Refactoring
 - Behavior changes
 
 **Exceptions (ask your human partner):**
+
 - Throwaway prototypes
 - Generated code
 - Configuration files
@@ -39,6 +41,7 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 Write code before the test? Delete it. Start over.
 
 **No exceptions:**
+
 - Don't keep it as "reference"
 - Don't "adapt" it while writing tests
 - Don't look at it
@@ -84,12 +87,13 @@ test('retries failed operations 3 times', async () => {
     return 'success';
   };
 
-  const result = await retryOperation(operation);
+const result = await retryOperation(operation);
 
-  expect(result).toBe('success');
-  expect(attempts).toBe(3);
+expect(result).toBe('success');
+expect(attempts).toBe(3);
 });
-```
+
+````
 Clear name, tests real behavior, one thing
 </Good>
 
@@ -103,11 +107,13 @@ test('retry works', async () => {
   await retryOperation(mock);
   expect(mock).toHaveBeenCalledTimes(3);
 });
-```
+````
+
 Vague name, tests mock not code
 </Bad>
 
 **Requirements:**
+
 - One behavior
 - Clear name
 - Real code (no mocks unless unavoidable)
@@ -117,10 +123,11 @@ Vague name, tests mock not code
 **MANDATORY. Never skip.**
 
 ```bash
-pnpm vitest path/to/test.spec.ts --run
+npx vitest path/to/test.spec.ts --run
 ```
 
 Confirm:
+
 - Test fails (not errors)
 - Failure message is expected
 - Fails because feature missing (not typos)
@@ -172,10 +179,11 @@ Don't add features, refactor other code, or "improve" beyond the test.
 **MANDATORY.**
 
 ```bash
-pnpm vitest path/to/test.spec.ts --run
+npx vitest path/to/test.spec.ts --run
 ```
 
 Confirm:
+
 - Test passes
 - Other tests still pass
 - Output pristine (no errors, warnings)
@@ -187,6 +195,7 @@ Confirm:
 ### REFACTOR - Clean Up
 
 After green only:
+
 - Remove duplication
 - Improve names
 - Extract helpers
@@ -199,17 +208,18 @@ Next failing test for next feature.
 
 ## Good Tests
 
-| Quality | Good | Bad |
-|---------|------|-----|
-| **Minimal** | One thing. "and" in name? Split it. | `test('validates email and domain and whitespace')` |
-| **Clear** | Name describes behavior | `test('test1')` |
-| **Shows intent** | Demonstrates desired API | Obscures what code should do |
+| Quality          | Good                                | Bad                                                 |
+| ---------------- | ----------------------------------- | --------------------------------------------------- |
+| **Minimal**      | One thing. "and" in name? Split it. | `test('validates email and domain and whitespace')` |
+| **Clear**        | Name describes behavior             | `test('test1')`                                     |
+| **Shows intent** | Demonstrates desired API            | Obscures what code should do                        |
 
 ## Why Order Matters
 
 **"I'll write tests after to verify it works"**
 
 Tests written after code pass immediately. Passing immediately proves nothing:
+
 - Might test wrong thing
 - Might test implementation, not behavior
 - Might miss edge cases you forgot
@@ -220,6 +230,7 @@ Test-first forces you to see the test fail, proving it actually tests something.
 **"I already manually tested all the edge cases"**
 
 Manual testing is ad-hoc. You think you tested everything but:
+
 - No record of what you tested
 - Can't re-run when code changes
 - Easy to forget cases under pressure
@@ -230,6 +241,7 @@ Automated tests are systematic. They run the same way every time.
 **"Deleting X hours of work is wasteful"**
 
 Sunk cost fallacy. The time is already gone. Your choice now:
+
 - Delete and rewrite with TDD (X more hours, high confidence)
 - Keep it and add tests after (30 min, low confidence, likely bugs)
 
@@ -238,6 +250,7 @@ The "waste" is keeping code you can't trust. Working code without real tests is
 **"TDD is dogmatic, being pragmatic means adapting"**
 
 TDD IS pragmatic:
+
 - Finds bugs before commit (faster than debugging after)
 - Prevents regressions (tests catch breaks immediately)
 - Documents behavior (tests show how to use code)
@@ -257,19 +270,19 @@ Tests-first force edge case discovery before implementing. Tests-after verify yo
 
 ## Common Rationalizations
 
-| Excuse | Reality |
-|--------|---------|
-| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
-| "I'll test after" | Tests passing immediately prove nothing. |
-| "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
-| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
-| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is technical debt. |
-| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
-| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
-| "Test hard = design unclear" | Listen to test. Hard to test = hard to use. |
-| "TDD will slow me down" | TDD faster than debugging. Pragmatic = test-first. |
-| "Manual test faster" | Manual doesn't prove edge cases. You'll re-test every change. |
-| "Existing code has no tests" | You're improving it. Add tests for existing code. |
+| Excuse                                 | Reality                                                                 |
+| -------------------------------------- | ----------------------------------------------------------------------- |
+| "Too simple to test"                   | Simple code breaks. Test takes 30 seconds.                              |
+| "I'll test after"                      | Tests passing immediately prove nothing.                                |
+| "Tests after achieve same goals"       | Tests-after = "what does this do?" Tests-first = "what should this do?" |
+| "Already manually tested"              | Ad-hoc ≠ systematic. No record, can't re-run.                           |
+| "Deleting X hours is wasteful"         | Sunk cost fallacy. Keeping unverified code is technical debt.           |
+| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete.             |
+| "Need to explore first"                | Fine. Throw away exploration, start with TDD.                           |
+| "Test hard = design unclear"           | Listen to test. Hard to test = hard to use.                             |
+| "TDD will slow me down"                | TDD faster than debugging. Pragmatic = test-first.                      |
+| "Manual test faster"                   | Manual doesn't prove edge cases. You'll re-test every change.           |
+| "Existing code has no tests"           | You're improving it. Add tests for existing code.                       |
 
 ## Red Flags - STOP and Start Over
 
@@ -294,32 +307,36 @@ Tests-first force edge case discovery before implementing. Tests-after verify yo
 **Bug:** Empty email accepted
 
 **RED**
+
 ```typescript
-test('rejects empty email', async () => {
-  const result = await submitForm({ email: '' });
-  expect(result.error).toBe('Email required');
+test("rejects empty email", async () => {
+  const result = await submitForm({ email: "" });
+  expect(result.error).toBe("Email required");
 });
 ```
 
 **Verify RED**
+
 ```bash
-$ pnpm vitest path/to/test.spec.ts --run
+$ npx vitest path/to/test.spec.ts --run
 FAIL: expected 'Email required', got undefined
 ```
 
 **GREEN**
+
 ```typescript
 function submitForm(data: FormData) {
   if (!data.email?.trim()) {
-    return { error: 'Email required' };
+    return { error: "Email required" };
   }
   // ...
 }
 ```
 
 **Verify GREEN**
+
 ```bash
-$ pnpm vitest path/to/test.spec.ts --run
+$ npx vitest path/to/test.spec.ts --run
 PASS
 ```
 
@@ -343,12 +360,12 @@ Can't check all boxes? You skipped TDD. Start over.
 
 ## When Stuck
 
-| Problem | Solution |
-|---------|----------|
+| Problem                | Solution                                                             |
+| ---------------------- | -------------------------------------------------------------------- |
 | Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |
-| Test too complicated | Design too complicated. Simplify interface. |
-| Must mock everything | Code too coupled. Use dependency injection. |
-| Test setup huge | Extract helpers. Still complex? Simplify design. |
+| Test too complicated   | Design too complicated. Simplify interface.                          |
+| Must mock everything   | Code too coupled. Use dependency injection.                          |
+| Test setup huge        | Extract helpers. Still complex? Simplify design.                     |
 
 ## Debugging Integration
 
@@ -359,6 +376,7 @@ Never fix bugs without a test.
 ## Testing Anti-Patterns
 
 When adding mocks or test utilities, read testing-anti-patterns.md to avoid common pitfalls:
+
 - Testing mock behavior instead of real behavior
 - Adding test-only methods to production classes
 - Mocking without understanding dependencies

package/claude/skills/sd-tdd/testing-anti-patterns.md

@@ -21,6 +21,7 @@ Tests must verify real behavior, not mock behavior. Mocks are a means to isolate
 ## Anti-Pattern 1: Testing Mock Behavior
 
 **The violation:**
+
 ```typescript
 // ❌ BAD: Testing that the mock exists
 test('renders sidebar', () => {
@@ -30,6 +31,7 @@ test('renders sidebar', () => {
 ```
 
 **Why this is wrong:**
+
 - You're verifying the mock works, not that the component works
 - Test passes when mock is present, fails when it's not
 - Tells you nothing about real behavior
@@ -37,6 +39,7 @@ test('renders sidebar', () => {
 **your human partner's correction:** "Are we testing the behavior of a mock?"
 
 **The fix:**
+
 ```typescript
 // ✅ GOOD: Test real component or don't mock it
 test('renders sidebar', () => {
@@ -63,10 +66,12 @@ BEFORE asserting on any mock element:
 ## Anti-Pattern 2: Test-Only Methods in Production
 
 **The violation:**
+
 ```typescript
 // ❌ BAD: destroy() only used in tests
 class Session {
-  async destroy() {  // Looks like production API!
+  async destroy() {
+    // Looks like production API!
     await this._workspaceManager?.destroyWorkspace(this.id);
     // ... cleanup
   }
@@ -77,12 +82,14 @@ afterEach(() => session.destroy());
 ```
 
 **Why this is wrong:**
+
 - Production class polluted with test-only code
 - Dangerous if accidentally called in production
 - Violates YAGNI and separation of concerns
 - Confuses object lifecycle with entity lifecycle
 
 **The fix:**
+
 ```typescript
 // ✅ GOOD: Test utilities handle test cleanup
 // Session has no destroy() - it's stateless in production
@@ -118,33 +125,36 @@ BEFORE adding any method to production class:
 ## Anti-Pattern 3: Mocking Without Understanding
 
 **The violation:**
+
 ```typescript
 // ❌ BAD: Mock breaks test logic
-test('detects duplicate server', () => {
+test("detects duplicate server", () => {
   // Mock prevents config write that test depends on!
-  vi.mock('ToolCatalog', () => ({
-    discoverAndCacheTools: vi.fn().mockResolvedValue(undefined)
+  vi.mock("ToolCatalog", () => ({
+    discoverAndCacheTools: vi.fn().mockResolvedValue(undefined),
   }));
 
   await addServer(config);
-  await addServer(config);  // Should throw - but won't!
+  await addServer(config); // Should throw - but won't!
 });
 ```
 
 **Why this is wrong:**
+
 - Mocked method had side effect test depended on (writing config)
 - Over-mocking to "be safe" breaks actual behavior
 - Test passes for wrong reason or fails mysteriously
 
 **The fix:**
+
 ```typescript
 // ✅ GOOD: Mock at correct level
-test('detects duplicate server', () => {
+test("detects duplicate server", () => {
   // Mock the slow part, preserve behavior test needs
-  vi.mock('MCPServerManager'); // Just mock slow server startup
+  vi.mock("MCPServerManager"); // Just mock slow server startup
 
-  await addServer(config);  // Config written
-  await addServer(config);  // Duplicate detected ✓
+  await addServer(config); // Config written
+  await addServer(config); // Duplicate detected ✓
 });
 ```
 
@@ -177,11 +187,12 @@ BEFORE mocking any method:
 ## Anti-Pattern 4: Incomplete Mocks
 
 **The violation:**
+
 ```typescript
 // ❌ BAD: Partial mock - only fields you think you need
 const mockResponse = {
-  status: 'success',
-  data: { userId: '123', name: 'Alice' }
+  status: "success",
+  data: { userId: "123", name: "Alice" },
   // Missing: metadata that downstream code uses
 };
 
@@ -189,6 +200,7 @@ const mockResponse = {
 ```
 
 **Why this is wrong:**
+
 - **Partial mocks hide structural assumptions** - You only mocked fields you know about
 - **Downstream code may depend on fields you didn't include** - Silent failures
 - **Tests pass but integration fails** - Mock incomplete, real API complete
@@ -197,12 +209,13 @@ const mockResponse = {
 **The Iron Rule:** Mock the COMPLETE data structure as it exists in reality, not just fields your immediate test uses.
 
 **The fix:**
+
 ```typescript
 // ✅ GOOD: Mirror real API completeness
 const mockResponse = {
-  status: 'success',
-  data: { userId: '123', name: 'Alice' },
-  metadata: { requestId: 'req-789', timestamp: 1234567890 }
+  status: "success",
+  data: { userId: "123", name: "Alice" },
+  metadata: { requestId: "req-789", timestamp: 1234567890 },
   // All fields real API returns
 };
 ```
@@ -228,6 +241,7 @@ BEFORE creating mock responses:
 ## Anti-Pattern 5: Integration Tests as Afterthought
 
 **The violation:**
+
 ```
 ✅ Implementation complete
 ❌ No tests written
@@ -235,11 +249,13 @@ BEFORE creating mock responses:
 ```
 
 **Why this is wrong:**
+
 - Testing is part of implementation, not optional follow-up
 - TDD would have caught this
 - Can't claim complete without tests
 
 **The fix:**
+
 ```
 TDD cycle:
 1. Write failing test
@@ -251,6 +267,7 @@ TDD cycle:
 ## When Mocks Become Too Complex
 
 **Warning signs:**
+
 - Mock setup longer than test logic
 - Mocking everything to make test pass
 - Mocks missing methods real components have
@@ -263,6 +280,7 @@ TDD cycle:
 ## TDD Prevents These Anti-Patterns
 
 **Why TDD helps:**
+
 1. **Write test first** → Forces you to think about what you're actually testing
 2. **Watch it fail** → Confirms test tests real behavior, not mocks
 3. **Minimal implementation** → No test-only methods creep in
@@ -272,14 +290,14 @@ TDD cycle:
 
 ## Quick Reference
 
-| Anti-Pattern | Fix |
-|--------------|-----|
-| Assert on mock elements | Test real component or unmock it |
-| Test-only methods in production | Move to test utilities |
-| Mock without understanding | Understand dependencies first, mock minimally |
-| Incomplete mocks | Mirror real API completely |
-| Tests as afterthought | TDD - tests first |
-| Over-complex mocks | Consider integration tests |
+| Anti-Pattern                    | Fix                                           |
+| ------------------------------- | --------------------------------------------- |
+| Assert on mock elements         | Test real component or unmock it              |
+| Test-only methods in production | Move to test utilities                        |
+| Mock without understanding      | Understand dependencies first, mock minimally |
+| Incomplete mocks                | Mirror real API completely                    |
+| Tests as afterthought           | TDD - tests first                             |
+| Over-complex mocks              | Consider integration tests                    |
 
 ## Red Flags
 

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

@@ -6,7 +6,7 @@ model: haiku
 
 # sd-use - Auto Skill/Agent Router
 
-Analyze user request from ARGUMENTS, select the best matching sd-* skill or agent, explain why, then execute it.
+Analyze user request from ARGUMENTS, select the best matching sd-\* skill or agent, explain why, then execute it.
 
 ## Execution Flow
 
@@ -19,30 +19,30 @@ Analyze user request from ARGUMENTS, select the best matching sd-* skill or agen
 
 ### Skills (execute via `Skill` tool)
 
-| Skill | When to select |
-|-------|----------------|
-| `sd-brainstorm` | New feature, component, or behavior change — **creative work before implementation** |
-| `sd-debug` | Bug, test failure, unexpected behavior — **systematic root cause investigation** |
-| `sd-tdd` | Implementing a feature or fixing a bug — **before writing code** |
-| `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-check` | Verify code — typecheck, lint, tests |
-| `sd-commit` | Create a git commit |
-| `sd-readme` | Update a package README.md |
-| `sd-discuss` | Evaluate code design decisions against industry standards and project conventions |
-| `sd-api-name-review` | Review public API naming consistency |
-| `sd-worktree` | Start new work in branch isolation |
-| `sd-skill` | Create or edit skills |
+| Skill                | When to select                                                                       |
+| -------------------- | ------------------------------------------------------------------------------------ |
+| `sd-brainstorm`      | New feature, component, or behavior change — **creative work before implementation** |
+| `sd-debug`           | Bug, test failure, unexpected behavior — **systematic root cause investigation**     |
+| `sd-tdd`             | Implementing a feature or fixing a bug — **before writing code**                     |
+| `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-check`           | Verify code — typecheck, lint, tests                                                 |
+| `sd-commit`          | Create a git commit                                                                  |
+| `sd-readme`          | Update a package README.md                                                           |
+| `sd-discuss`         | Evaluate code design decisions against industry standards and project conventions    |
+| `sd-api-name-review` | Review public API naming consistency                                                 |
+| `sd-worktree`        | Start new work in branch isolation                                                   |
+| `sd-skill`           | Create or edit skills                                                                |
 
 ### Agents (execute via `Task` tool with matching `subagent_type`)
 
-| Agent | When to select |
-|-------|----------------|
-| `sd-code-reviewer` | Focused review for bugs, security vulnerabilities, quality issues |
-| `sd-code-simplifier` | Simplify, clean up, improve code readability |
-| `sd-api-reviewer` | Review library public API for DX quality |
+| Agent                | When to select                                                    |
+| -------------------- | ----------------------------------------------------------------- |
+| `sd-code-reviewer`   | Focused review for bugs, security vulnerabilities, quality issues |
+| `sd-code-simplifier` | Simplify, clean up, improve code readability                      |
+| `sd-api-reviewer`    | Review library public API for DX quality                          |
 
 ## Selection Rules
 

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

@@ -15,6 +15,7 @@ Create, merge, and clean up git worktrees under `.worktrees/`. Uses the current
 ## Target Worktree Resolution
 
 For all commands, the target worktree name is resolved in this order:
+
 1. Explicitly provided in args → use as-is
 2. Current cd is inside `.worktrees/<name>/` → use that `<name>` (auto-detected)
 3. Neither applies → ask the user

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

@@ -47,7 +47,7 @@ switch (cmd) {
     console.log(`Creating worktree: .worktrees/${name} (from ${branch})`);
     run(`git worktree add "${worktreePath}" -b "${name}"`);
     console.log("Installing dependencies...");
-    run("pnpm install", { cwd: worktreePath });
+    run("npm install", { cwd: worktreePath });
     console.log(`\nReady: ${worktreePath}`);
     break;
   }

package/package.json

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

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

@@ -1,54 +0,0 @@
-import { readFileSync, existsSync } from "fs";
-import { resolve } from "path";
-import { spawn } from "child_process";
-
-const root = resolve(import.meta.dirname, "../../..");
-
-// ══════════════════════════════════════════
-// Phase 1: Environment Pre-check
-// ══════════════════════════════════════════
-
-const errors = [];
-
-const pkgPath = resolve(root, "package.json");
-if (!existsSync(pkgPath)) {
-  errors.push("package.json not found");
-} else {
-  const pkg = JSON.parse(readFileSync(pkgPath, "utf8"));
-  const major = parseInt(pkg.version?.split(".")[0], 10);
-  if (Number.isNaN(major) || major < 13) {
-    errors.push(`This skill requires simplysm v13+. Current: ${pkg.version}`);
-  }
-  if (!pkg.scripts?.check) {
-    errors.push("'check' script not defined in package.json");
-  }
-}
-
-for (const f of ["pnpm-workspace.yaml", "pnpm-lock.yaml"]) {
-  if (!existsSync(resolve(root, f))) {
-    errors.push(`${f} not found`);
-  }
-}
-
-if (!existsSync(resolve(root, "vitest.config.ts"))) {
-  errors.push("vitest.config.ts not found");
-}
-
-if (errors.length > 0) {
-  console.log("ENV-CHECK FAIL");
-  for (const e of errors) console.log(`- ${e}`);
-  process.exit(1);
-}
-
-console.log("ENV-CHECK OK");
-
-// ══════════════════════════════════════════
-// Phase 2: Delegate to pnpm check
-// ══════════════════════════════════════════
-
-const args = ["check", ...process.argv.slice(2)];
-const child = spawn("pnpm", args, { cwd: root, shell: true, stdio: "inherit" });
-
-child.on("close", (code) => {
-  process.exit(code ?? 1);
-});