@simplysm/sd-claude 13.0.60 → 13.0.61

package/claude/skills/sd-check/test-scenarios.md

@@ -3,23 +3,28 @@
 ## Scenario 1: Basic Application - Full Project Check (Time Pressure)
 
 **Setup:**
+
 - Simulated project with typecheck, lint, test configured
 - No existing errors
 
 **Pressure:**
+
 - Time constraint: "Need results quickly for deployment"
 
 **Agent Prompt:**
+
 ```
 I need to verify the entire simplysm project before deployment. Can you run all checks? We need to deploy soon, so please be fast.
 ```
 
 **Expected Baseline Failures (without skill):**
+
 - May run checks sequentially instead of parallel (slower)
 - May skip environment pre-checks
 - May not use haiku model (more expensive)
 
 **Success Criteria (with skill):**
+
 - Runs environment pre-checks first
 - Launches 3 haiku agents in parallel
 - Reports results correctly
@@ -29,24 +34,29 @@ I need to verify the entire simplysm project before deployment. Can you run all
 ## Scenario 2: Variation - Specific Path Check (Complex Path)
 
 **Setup:**
+
 - Project with multiple packages
 - Target path: `packages/solid-demo`
 
 **Pressure:**
+
 - Complex path with potential typos
 - User expects path to be handled correctly
 
 **Agent Prompt:**
+
 ```
 Can you verify just the packages/solid-demo directory? I only changed files there.
 ```
 
 **Expected Baseline Failures:**
+
 - May forget to pass path argument to commands
 - May run full project check instead
 - May incorrectly format path in commands
 
 **Success Criteria:**
+
 - Correctly passes `packages/solid-demo` to all 3 commands
 - Only reports errors from that path
 
@@ -55,23 +65,28 @@ Can you verify just the packages/solid-demo directory? I only changed files ther
 ## Scenario 3: Edge Case - Typecheck Errors (Fix Priority)
 
 **Setup:**
+
 - Simulated project with typecheck errors that cascade to lint/test
 
 **Pressure:**
+
 - Multiple failing checks (frustration)
 - Desire to "just make it work"
 
 **Agent Prompt:**
+
 ```
 Please verify the project. (Note: project has typecheck errors that cause lint and test failures)
 ```
 
 **Expected Baseline Failures:**
+
 - May fix lint or test errors first (wrong priority)
 - May not understand cascade relationship
 - May fix all errors simultaneously without priority
 
 **Success Criteria:**
+
 - Fixes typecheck errors first
 - Recognizes cascade relationship
 - Re-verifies after each fix round
@@ -81,24 +96,29 @@ Please verify the project. (Note: project has typecheck errors that cause lint a
 ## Scenario 4: Edge Case - Repeated Failures (Loop Exit)
 
 **Setup:**
+
 - Simulated project with obscure test failure
 - Root cause is unclear
 
 **Pressure:**
+
 - Repeated verification failures (fatigue)
 - Temptation to give up or skip
 
 **Agent Prompt:**
+
 ```
 Verify the project. (Note: test failures persist after 2-3 fix attempts)
 ```
 
 **Expected Baseline Failures:**
+
 - May keep trying same fix repeatedly (infinite loop)
 - May skip re-verification to "save time"
 - May not recommend sd-debug
 
 **Success Criteria:**
+
 - After 2-3 failed attempts, recommends `/sd-debug`
 - Does not enter infinite loop
 - Always re-verifies after fixes
@@ -108,21 +128,26 @@ Verify the project. (Note: test failures persist after 2-3 fix attempts)
 ## Scenario 5: Missing Information Test - No Path Argument
 
 **Setup:**
+
 - Standard project setup
 
 **Pressure:**
+
 - Ambiguous user request
 
 **Agent Prompt:**
+
 ```
 Run sd-check.
 ```
 
 **Expected Baseline Failures:**
+
 - May ask user for path (skill should default to full project)
 - May incorrectly assume a path
 
 **Success Criteria:**
+
 - Runs on entire project (no path argument)
 - Does not ask user for clarification
 
@@ -131,21 +156,26 @@ Run sd-check.
 ## Scenario 6: Missing Information Test - Invalid Environment
 
 **Setup:**
-- Project missing pnpm-lock.yaml or vitest.config.ts
+
+- Project missing `check` script in package.json
 
 **Pressure:**
+
 - User expects check to work
 
 **Agent Prompt:**
+
 ```
 Please run sd-check on the project.
 ```
 
 **Expected Baseline Failures:**
+
 - May proceed without environment checks
 - May report confusing errors from missing dependencies
 
 **Success Criteria:**
+
 - Runs environment pre-checks
 - Stops with clear error message if environment invalid
 - Reports which specific check failed
@@ -155,17 +185,20 @@ Please run sd-check on the project.
 ## Testing Methodology
 
 ### RED Phase (Current)
+
 1. Run each scenario WITHOUT sd-check skill loaded
 2. Document exact agent behavior verbatim
 3. Record rationalizations used
 4. Identify patterns in failures
 
 ### GREEN Phase
+
 1. Write skill addressing specific baseline failures
 2. Run same scenarios WITH skill
 3. Verify compliance
 
 ### REFACTOR Phase
+
 1. Identify new rationalizations from GREEN testing
 2. Add explicit counters
 3. Build rationalization table

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

@@ -20,10 +20,12 @@ Stages and commits changes using Conventional Commits format. Two modes: **defau
 ## File Selection Rules
 
 **NEVER arbitrarily exclude files.** The ONLY valid reason to exclude a file is:
+
 - It is in `.gitignore`
 - It is completely unrelated to the conversation context (default mode only)
 
 **Do NOT exclude files based on:**
+
 - File type or extension (e.g., `.styles.ts`, `.config.ts`)
 - Folder name or path (e.g., `node_modules` is handled by `.gitignore`)
 - Personal judgment about importance or "cleanliness"
@@ -44,13 +46,14 @@ Stages and commits changes using Conventional Commits format. Two modes: **defau
 type(scope): short description
 ```
 
-| Field | Values |
-|-------|--------|
-| `type` | `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `build`, `style`, `perf` |
-| `scope` | package name or area (e.g., `solid`, `core-common`, `orm-node`) |
-| `description` | imperative, lowercase, no period at end |
+| Field         | Values                                                                       |
+| ------------- | ---------------------------------------------------------------------------- |
+| `type`        | `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `build`, `style`, `perf` |
+| `scope`       | package name or area (e.g., `solid`, `core-common`, `orm-node`)              |
+| `description` | imperative, lowercase, no period at end                                      |
 
 Examples:
+
 - `feat(solid): add Select component`
 - `fix(orm-node): handle null values in bulk insert`
 - `docs: update README with new API examples`
@@ -62,11 +65,13 @@ Use a HEREDOC for multi-line messages when needed.
 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
@@ -76,6 +81,7 @@ Group by **intent/purpose**, not by package.
 **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`.

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

@@ -24,6 +24,7 @@ If you haven't completed Phase 1, you cannot propose fixes.
 ## When to Use
 
 Use for ANY technical issue:
+
 - Test failures
 - Bugs in production
 - Unexpected behavior
@@ -32,6 +33,7 @@ Use for ANY technical issue:
 - Integration issues
 
 **Use this ESPECIALLY when:**
+
 - Under time pressure (emergencies make guessing tempting)
 - "Just one quick fix" seems obvious
 - You've already tried multiple fixes
@@ -39,6 +41,7 @@ Use for ANY technical issue:
 - You don't fully understand the issue
 
 **Don't skip when:**
+
 - Issue seems simple (simple bugs have root causes too)
 - You're in a hurry (rushing guarantees rework)
 - Manager wants it fixed NOW (systematic is faster than thrashing)
@@ -75,6 +78,7 @@ You MUST complete each phase before proceeding to the next.
    **WHEN system has multiple components (CI → build → signing, API → service → database):**
 
    **BEFORE proposing fixes, add diagnostic instrumentation:**
+
    ```
    For EACH component boundary:
      - Log what data enters component
@@ -88,6 +92,7 @@ You MUST complete each phase before proceeding to the next.
    ```
 
    **Example (multi-layer system):**
+
    ```bash
    # Layer 1: Workflow
    echo "=== Secrets available in workflow: ==="
@@ -216,6 +221,7 @@ You MUST complete each phase before proceeding to the next.
 ## Red Flags - STOP and Follow Process
 
 If you catch yourself thinking:
+
 - "Quick fix for now, investigate later"
 - "Just try changing X and see if it works"
 - "Add multiple changes, run tests"
@@ -236,6 +242,7 @@ If you catch yourself thinking:
 ## User Signals You're Doing It Wrong
 
 **Watch for these redirections:**
+
 - "Is that not happening?" - You assumed without verifying
 - "Will it show us...?" - You should have added evidence gathering
 - "Stop guessing" - You're proposing fixes without understanding
@@ -246,26 +253,26 @@ If you catch yourself thinking:
 
 ## Common Rationalizations
 
-| Excuse | Reality |
-|--------|---------|
-| "Issue is simple, don't need process" | Simple issues have root causes too. Process is fast for simple bugs. |
-| "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check thrashing. |
-| "Just try this first, then investigate" | First fix sets the pattern. Do it right from the start. |
-| "I'll write test after confirming fix works" | Untested fixes don't stick. Test first proves it. |
-| "Multiple fixes at once saves time" | Can't isolate what worked. Causes new bugs. |
-| "Reference too long, I'll adapt the pattern" | Partial understanding guarantees bugs. Read it completely. |
-| "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause. |
-| "Let me check git diff to see what changed" | Diff shows WHAT changed, not WHY it's broken. Read the code as-is. |
-| "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. Question pattern, don't fix again. |
+| Excuse                                       | Reality                                                                 |
+| -------------------------------------------- | ----------------------------------------------------------------------- |
+| "Issue is simple, don't need process"        | Simple issues have root causes too. Process is fast for simple bugs.    |
+| "Emergency, no time for process"             | Systematic debugging is FASTER than guess-and-check thrashing.          |
+| "Just try this first, then investigate"      | First fix sets the pattern. Do it right from the start.                 |
+| "I'll write test after confirming fix works" | Untested fixes don't stick. Test first proves it.                       |
+| "Multiple fixes at once saves time"          | Can't isolate what worked. Causes new bugs.                             |
+| "Reference too long, I'll adapt the pattern" | Partial understanding guarantees bugs. Read it completely.              |
+| "I see the problem, let me fix it"           | Seeing symptoms ≠ understanding root cause.                             |
+| "Let me check git diff to see what changed"  | Diff shows WHAT changed, not WHY it's broken. Read the code as-is.      |
+| "One more fix attempt" (after 2+ failures)   | 3+ failures = architectural problem. Question pattern, don't fix again. |
 
 ## Quick Reference
 
-| Phase | Key Activities | Success Criteria |
-|-------|---------------|------------------|
-| **1. Root Cause** | Read errors, reproduce, read source code, gather evidence | Understand WHAT and WHY |
-| **2. Pattern** | Find working examples, compare | Identify differences |
-| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |
-| **4. Implementation** | Create test, fix, verify | Bug resolved, tests pass |
+| Phase                 | Key Activities                                            | Success Criteria            |
+| --------------------- | --------------------------------------------------------- | --------------------------- |
+| **1. Root Cause**     | Read errors, reproduce, read source code, gather evidence | Understand WHAT and WHY     |
+| **2. Pattern**        | Find working examples, compare                            | Identify differences        |
+| **3. Hypothesis**     | Form theory, test minimally                               | Confirmed or new hypothesis |
+| **4. Implementation** | Create test, fix, verify                                  | Bug resolved, tests pass    |
 
 ## When Process Reveals "No Root Cause"
 
@@ -287,12 +294,14 @@ These techniques are part of systematic debugging and available in this director
 - **`condition-based-waiting.md`** - Replace arbitrary timeouts with condition polling
 
 **Related skills:**
+
 - **sd-tdd** - For creating failing test case (Phase 4, Step 1)
 - **sd-check** - Verify fix worked before claiming success
 
 ## Real-World Impact
 
 From debugging sessions:
+
 - Systematic approach: 15-30 minutes to fix
 - Random fixes approach: 2-3 hours of thrashing
 - First-time fix rate: 95% vs 40%

package/claude/skills/sd-debug/condition-based-waiting.md

@@ -22,12 +22,14 @@ digraph when_to_use {
 ```
 
 **Use when:**
+
 - Tests have arbitrary delays (`setTimeout`, `sleep`, `time.sleep()`)
 - Tests are flaky (pass sometimes, fail under load)
 - Tests timeout when run in parallel
 - Waiting for async operations to complete
 
 **Don't use when:**
+
 - Testing actual timing behavior (debounce, throttle intervals)
 - Always document WHY if using arbitrary timeout
 
@@ -35,7 +37,7 @@ digraph when_to_use {
 
 ```typescript
 // ❌ BEFORE: Guessing at timing
-await new Promise(r => setTimeout(r, 50));
+await new Promise((r) => setTimeout(r, 50));
 const result = getResult();
 expect(result).toBeDefined();
 
@@ -47,22 +49,23 @@ expect(result).toBeDefined();
 
 ## Quick Patterns
 
-| Scenario | Pattern |
-|----------|---------|
-| Wait for event | `waitFor(() => events.find(e => e.type === 'DONE'))` |
-| Wait for state | `waitFor(() => machine.state === 'ready')` |
-| Wait for count | `waitFor(() => items.length >= 5)` |
-| Wait for file | `waitFor(() => fs.existsSync(path))` |
-| Complex condition | `waitFor(() => obj.ready && obj.value > 10)` |
+| Scenario          | Pattern                                              |
+| ----------------- | ---------------------------------------------------- |
+| Wait for event    | `waitFor(() => events.find(e => e.type === 'DONE'))` |
+| Wait for state    | `waitFor(() => machine.state === 'ready')`           |
+| Wait for count    | `waitFor(() => items.length >= 5)`                   |
+| Wait for file     | `waitFor(() => fs.existsSync(path))`                 |
+| Complex condition | `waitFor(() => obj.ready && obj.value > 10)`         |
 
 ## Implementation
 
 Generic polling function:
+
 ```typescript
 async function waitFor<T>(
   condition: () => T | undefined | null | false,
   description: string,
-  timeoutMs = 5000
+  timeoutMs = 5000,
 ): Promise<T> {
   const startTime = Date.now();
 
@@ -74,7 +77,7 @@ async function waitFor<T>(
       throw new Error(`Timeout waiting for ${description} after ${timeoutMs}ms`);
     }
 
-    await new Promise(r => setTimeout(r, 10)); // Poll every 10ms
+    await new Promise((r) => setTimeout(r, 10)); // Poll every 10ms
   }
 }
 ```
@@ -96,12 +99,13 @@ See `condition-based-waiting-example.ts` in this directory for complete implemen
 
 ```typescript
 // Tool ticks every 100ms - need 2 ticks to verify partial output
-await waitForEvent(manager, 'TOOL_STARTED'); // First: wait for condition
-await new Promise(r => setTimeout(r, 200));   // Then: wait for timed behavior
+await waitForEvent(manager, "TOOL_STARTED"); // First: wait for condition
+await new Promise((r) => setTimeout(r, 200)); // Then: wait for timed behavior
 // 200ms = 2 ticks at 100ms intervals - documented and justified
 ```
 
 **Requirements:**
+
 1. First wait for triggering condition
 2. Based on known timing (not guessing)
 3. Comment explaining WHY
@@ -109,6 +113,7 @@ await new Promise(r => setTimeout(r, 200));   // Then: wait for timed behavior
 ## Real-World Impact
 
 From debugging session (2025-10-03):
+
 - Fixed 15 flaky tests across 3 files
 - Pass rate: 60% → 100%
 - Execution time: 40% faster

package/claude/skills/sd-debug/defense-in-depth.md

@@ -12,6 +12,7 @@ Single validation: "We fixed the bug"
 Multiple layers: "We made the bug impossible"
 
 Different layers catch different cases:
+
 - Entry validation catches most bugs
 - Business logic catches edge cases
 - Environment guards prevent context-specific dangers
@@ -20,12 +21,13 @@ Different layers catch different cases:
 ## The Four Layers
 
 ### Layer 1: Entry Point Validation
+
 **Purpose:** Reject obviously invalid input at API boundary
 
 ```typescript
 function createProject(name: string, workingDirectory: string) {
-  if (!workingDirectory || workingDirectory.trim() === '') {
-    throw new Error('workingDirectory cannot be empty');
+  if (!workingDirectory || workingDirectory.trim() === "") {
+    throw new Error("workingDirectory cannot be empty");
   }
   if (!existsSync(workingDirectory)) {
     throw new Error(`workingDirectory does not exist: ${workingDirectory}`);
@@ -38,31 +40,31 @@ function createProject(name: string, workingDirectory: string) {
 ```
 
 ### Layer 2: Business Logic Validation
+
 **Purpose:** Ensure data makes sense for this operation
 
 ```typescript
 function initializeWorkspace(projectDir: string, sessionId: string) {
   if (!projectDir) {
-    throw new Error('projectDir required for workspace initialization');
+    throw new Error("projectDir required for workspace initialization");
   }
   // ... proceed
 }
 ```
 
 ### Layer 3: Environment Guards
+
 **Purpose:** Prevent dangerous operations in specific contexts
 
 ```typescript
 async function gitInit(directory: string) {
   // In tests, refuse git init outside temp directories
-  if (process.env.NODE_ENV === 'test') {
+  if (process.env.NODE_ENV === "test") {
     const normalized = normalize(resolve(directory));
     const tmpDir = normalize(resolve(tmpdir()));
 
     if (!normalized.startsWith(tmpDir)) {
-      throw new Error(
-        `Refusing git init outside temp dir during tests: ${directory}`
-      );
+      throw new Error(`Refusing git init outside temp dir during tests: ${directory}`);
     }
   }
   // ... proceed
@@ -70,12 +72,13 @@ async function gitInit(directory: string) {
 ```
 
 ### Layer 4: Debug Instrumentation
+
 **Purpose:** Capture context for forensics
 
 ```typescript
 async function gitInit(directory: string) {
   const stack = new Error().stack;
-  logger.debug('About to git init', {
+  logger.debug("About to git init", {
     directory,
     cwd: process.cwd(),
     stack,
@@ -98,12 +101,14 @@ When you find a bug:
 Bug: Empty `projectDir` caused `git init` in source code
 
 **Data flow:**
+
 1. Test setup → empty string
 2. `Project.create(name, '')`
 3. `WorkspaceManager.createWorkspace('')`
 4. `git init` runs in `process.cwd()`
 
 **Four layers added:**
+
 - Layer 1: `Project.create()` validates not empty/exists/writable
 - Layer 2: `WorkspaceManager` validates projectDir not empty
 - Layer 3: `WorktreeManager` refuses git init outside tmpdir in tests
@@ -114,6 +119,7 @@ Bug: Empty `projectDir` caused `git init` in source code
 ## Key Insight
 
 All four layers were necessary. During testing, each layer caught bugs the others missed:
+
 - Different code paths bypassed entry validation
 - Mocks bypassed business logic checks
 - Edge cases on different platforms needed environment guards

package/claude/skills/sd-debug/root-cause-tracing.md

@@ -24,6 +24,7 @@ digraph when_to_use {
 ```
 
 **Use when:**
+
 - Error happens deep in execution (not at entry point)
 - Stack trace shows long call chain
 - Unclear where invalid data originated
@@ -32,17 +33,21 @@ digraph when_to_use {
 ## The Tracing Process
 
 ### 1. Observe the Symptom
+
 ```
 Error: git init failed in /Users/jesse/project/packages/core
 ```
 
 ### 2. Find Immediate Cause
+
 **What code directly causes this?**
+
 ```typescript
-await execFileAsync('git', ['init'], { cwd: projectDir });
+await execFileAsync("git", ["init"], { cwd: projectDir });
 ```
 
 ### 3. Ask: What Called This?
+
 ```typescript
 WorktreeManager.createSessionWorktree(projectDir, sessionId)
   → called by Session.initializeWorkspace()
@@ -51,16 +56,20 @@ WorktreeManager.createSessionWorktree(projectDir, sessionId)
 ```
 
 ### 4. Keep Tracing Up
+
 **What value was passed?**
+
 - `projectDir = ''` (empty string!)
 - Empty string as `cwd` resolves to `process.cwd()`
 - That's the source code directory!
 
 ### 5. Find Original Trigger
+
 **Where did empty string come from?**
+
 ```typescript
 const context = setupCoreTest(); // Returns { tempDir: '' }
-Project.create('name', context.tempDir); // Accessed before beforeEach!
+Project.create("name", context.tempDir); // Accessed before beforeEach!
 ```
 
 ## Adding Stack Traces
@@ -71,25 +80,27 @@ When you can't trace manually, add instrumentation:
 // Before the problematic operation
 async function gitInit(directory: string) {
   const stack = new Error().stack;
-  console.error('DEBUG git init:', {
+  console.error("DEBUG git init:", {
     directory,
     cwd: process.cwd(),
     nodeEnv: process.env.NODE_ENV,
     stack,
   });
 
-  await execFileAsync('git', ['init'], { cwd: directory });
+  await execFileAsync("git", ["init"], { cwd: directory });
 }
 ```
 
 **Critical:** Use `console.error()` in tests (not logger - may not show)
 
 **Run and capture:**
+
 ```bash
 npm test 2>&1 | grep 'DEBUG git init'
 ```
 
 **Analyze stack traces:**
+
 - Look for test file names
 - Find the line number triggering the call
 - Identify the pattern (same test? same parameter?)
@@ -111,6 +122,7 @@ Runs tests one-by-one, stops at first polluter. See script for usage.
 **Symptom:** `.git` created in `packages/core/` (source code)
 
 **Trace chain:**
+
 1. `git init` runs in `process.cwd()` ← empty cwd parameter
 2. WorktreeManager called with empty projectDir
 3. Session.create() passed empty string
@@ -122,6 +134,7 @@ Runs tests one-by-one, stops at first polluter. See script for usage.
 **Fix:** Made tempDir a getter that throws if accessed before beforeEach
 
 **Also added defense-in-depth:**
+
 - Layer 1: Project.create() validates directory
 - Layer 2: WorkspaceManager validates not empty
 - Layer 3: NODE_ENV guard refuses git init outside tmpdir
@@ -163,6 +176,7 @@ digraph principle {
 ## Real-World Impact
 
 From debugging session (2025-10-03):
+
 - Found root cause through 5-level trace
 - Fixed at source (getter validation)
 - Added 4 layers of defense