@simplysm/sd-claude 13.0.75 → 13.0.76

package/claude/skills/sd-skill/testing-skills-with-subagents.md

@@ -16,18 +16,20 @@ You run scenarios without the skill (RED - watch agent fail), write skill addres
 
 ## When to Use
 
-Test skills that:
+**Pressure test** skills that:
 
 - Enforce discipline (TDD, testing requirements)
 - Have compliance costs (time, effort, rework)
 - Could be rationalized away ("just this once")
 - Contradict immediate goals (speed over quality)
 
-Don't test:
+**Retrieval test** (not pressure test) skills that:
 
-- Pure reference skills (API docs, syntax guides)
-- Skills without rules to violate
-- Skills agents have no incentive to bypass
+- Are pure reference (API docs, syntax guides)
+- Have no rules to violate
+- Have no incentive to bypass
+
+Retrieval tests verify agents can find and correctly apply the information. See SKILL.md "Testing All Skill Types > Reference Skills" for methodology.
 
 ## TDD Mapping for Skill Testing
 
@@ -159,6 +161,8 @@ Forces explicit choice.
 
 ### Testing Setup
 
+**NEVER use `isolation: "worktree"` when launching subagents.** Worktrees break lint/build tooling. Always run subagents in the default (non-isolated) mode.
+
 ```markdown
 IMPORTANT: This is a real scenario. You must choose and act.
 Don't ask hypothetical questions - make the actual decision.

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

@@ -4,21 +4,19 @@ description: "Route requests to sd-* skills/agents (explicit invocation only)"
 model: haiku
 ---
 
-# sd-use - Auto Skill/Agent Router
+# sd-use - Auto Skill 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 skill, explain why, then execute it.
 
 ## Execution Flow
 
 1. Read ARGUMENTS
-2. Match against catalog below
-3. Report selection with reason
-4. Execute immediately
+2. If user names a specific skill (e.g., "sd-explore로..."), route to that skill directly
+3. Otherwise, match against catalog below
+4. Report selection with reason
+5. Execute immediately
 
-## Catalog
-
-### Skills (execute via `Skill` tool)
+## Catalog (execute via `Skill` tool)
 
 | Skill                | When to select                                                                                                                                  |
 |----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -27,41 +25,35 @@ then execute it.
 | `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-review`          | **Large-scale** comprehensive review of an entire package or broad path — use only when user explicitly requests full/deep/comprehensive review |
+| `sd-review`          | Code review + refactoring analysis — defects, safety, API design, conventions, complexity, duplication, code structure                           |
 | `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-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                                                                                                                           |
 | `sd-email-analyze`   | Analyze, read, or summarize email files (`.eml` or `.msg`) — parsing and attachment extraction                                                  |
-
-### Agents (execute via `Task` tool with matching `subagent_type`)
-
-| Agent                  | When to select                                                                                                                     |
-|------------------------|------------------------------------------------------------------------------------------------------------------------------------|
-| `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                                                                                           |
-| `sd-security-reviewer` | ORM SQL injection and input validation vulnerability review                                                                        |
+| `sd-document`        | Read or write document files (`.docx`, `.xlsx`, `.pptx`, `.pdf`) — content extraction, creation, data export                                    |
+| `sd-explore`         | Explore, analyze, trace, or understand code structure, architecture, or implementation flow                                                     |
 
 ## Selection Rules
 
-1. Select **exactly one** skill or agent — the most specific match wins
-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
+1. **Explicit skill name** — If user mentions a specific skill name (e.g., "sd-explore로...", "sd-plan 만들어줘"), route to that skill directly
+2. Select **exactly one** skill — the most specific match wins
+3. **Review & Refactor**: "find bugs", "review", "refactor", "improve structure", "remove duplication" → `sd-review`
+4. **Sequential requests** (e.g., "brainstorm하고 plan 만들어줘"): Route to the **first** skill only. After completion, user can invoke the next
+5. If nothing matches, use **default LLM behavior** and handle the request directly
+6. Pass ARGUMENTS through as the skill's input
 
 ## Report Format
 
 Before executing, output:
 
 ```
-**Selected**: `sd-{name}` (or agent name)
+**Selected**: `{skill-name}`
 **Reason**: {one-line explanation}
-**Tip**: Next time you can call `/sd-{name} {request}` directly.
+**Tip**: Next time you can call `/{skill-name} {request}` directly.
 ```
 
 Then execute immediately.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "13.0.75",
+  "version": "13.0.76",
   "description": "Simplysm Claude Code CLI — asset installer",
   "author": "simplysm",
   "license": "Apache-2.0",

package/claude/skills/sd-check/baseline-analysis.md

@@ -1,150 +0,0 @@
-# Baseline Test Analysis - sd-check Skill
-
-## Summary
-
-Tested 6 scenarios with agents WITHOUT sd-check skill. All agents failed to follow optimal verification patterns.
-
-## Common Failures Across All Scenarios
-
-### 1. No Cost Optimization
-
-**Failure:** All agents planned direct command execution instead of using haiku subagents.
-
-**Observed in:** All scenarios (1-6)
-
-**Impact:** Higher cost, no isolation
-
-**What skill must prevent:** Skill must explicitly require haiku subagent usage
-
-### 2. Incomplete Parallelization
-
-**Failure:** Agents either ran sequentially or only partially parallelized.
-
-**Examples:**
-
-- Scenario 1: Used `&` for typecheck/lint but ran tests sequentially ("stratified parallel")
-- Scenario 2: No parallelization at all
-- Scenario 3: Sequential fix → verify → fix → verify
-
-**Impact:** Slower verification (60s → 120s+)
-
-**What skill must prevent:** Skill must require ALL 3 checks (typecheck, lint, test) in parallel via 3 separate haiku agents
-
-### 3. Missing Environment Pre-checks
-
-**Failure:** No systematic environment validation before running checks.
-
-**Observed:**
-
-- Scenario 1: Checked Docker for ORM tests, but not other prerequisites
-- Scenario 6: Only checked lock file, missed package.json scripts
-
-**Impact:** Confusing errors if environment misconfigured
-
-**What skill must prevent:** Skill must require pre-check (package.json `check` script exists)
-
-### 4. Unclear Re-verification Loop
-
-**Failure:** After fixing errors, no clear "re-run ALL checks" loop.
-
-**Examples:**
-
-- Scenario 3: Phase 1 verify → Phase 2 verify → Phase 3 verify (but no final "all phases" re-verify)
-- Agents treated it as linear progression, not a loop
-
-**Impact:** Fixes in one area may break another (cascade errors)
-
-**What skill must prevent:** Skill must explicitly state "re-run ALL 3 checks until ALL pass"
-
-### 5. No sd-debug Recommendation
-
-**Failure:** When root cause unclear after multiple attempts, agents didn't recommend sd-debug.
-
-**Observed:**
-
-- Scenario 4: After 4 failed attempts, agent suggested various debugging approaches but NOT `/sd-debug` skill
-
-**Impact:** User wastes time when systematic root-cause investigation needed
-
-**What skill must prevent:** Skill must state "after 2-3 failed fix attempts → recommend /sd-debug"
-
-### 6. Incorrect Default Behavior
-
-**Failure:** When no path argument provided, agents asked user for clarification instead of defaulting to full project.
-
-**Observed:**
-
-- Scenario 5: Agent wanted to ask "which package?" instead of running on entire project
-
-**Impact:** Unnecessary user friction
-
-**What skill must prevent:** Skill must state "if no path argument → run on entire project (omit path in commands)"
-
-### 7. Scope Creep (Unnecessary Steps)
-
-**Failure:** Agents included steps not relevant to "verification".
-
-**Examples:**
-
-- Scenario 1: Included build step (verification doesn't need build)
-- Scenario 2: Included dev server test (not verification)
-
-**Impact:** Wasted time, confusion about scope
-
-**What skill must prevent:** Skill must clarify scope: typecheck, lint, test ONLY (no build, no dev)
-
-## Rationalization Patterns (Verbatim)
-
-### "Parallelization while maintaining logical dependencies"
-
-- Used to justify partial parallelization
-- Agents ran typecheck & lint in parallel, but tests sequentially
-- **Counter:** ALL 3 checks are independent → all 3 in parallel
-
-### "Stratified parallel execution"
-
-- Used to justify sequential test runs grouped by environment
-- **Counter:** Vitest projects are independent → run all via single command
-
-### "Faster to fail fast on static checks"
-
-- Good principle, but used to justify including build step
-- **Counter:** Build is not a static check, and not required for verification
-
-### "Type safety first" / "Incremental verification"
-
-- Used to justify Phase 1 → Phase 2 → Phase 3 linear progression
-- **Counter:** After fixes, must re-verify ALL phases (loop), not just next phase
-
-### "Understanding first, then ONE comprehensive fix"
-
-- Used to justify continued debugging without tools
-- **Counter:** After 2-3 attempts, recommend /sd-debug for systematic investigation
-
-### "Ask for clarification" / "Explicit and predictable"
-
-- Used to justify asking user for path when none provided
-- **Counter:** Default to full project is explicit and predictable behavior
-
-## Success Criteria for Skill
-
-Skill is effective if agents:
-
-1. ✅ Launch 3 haiku agents in parallel (typecheck, lint, test)
-2. ✅ Run environment pre-checks before verification
-3. ✅ Default to full project when no path argument
-4. ✅ Fix errors in priority order (typecheck → lint → test)
-5. ✅ Re-run ALL 3 checks after any fix (loop until all pass)
-6. ✅ Recommend /sd-debug after 2-3 failed fix attempts
-7. ✅ Do NOT include build or dev server steps
-
-## Test Scenarios for GREEN Phase
-
-After writing skill, re-run scenarios 1-6. Agents should now exhibit correct behavior above.
-
-Focus on:
-
-- Scenario 1: Verify parallel haiku agents + env checks
-- Scenario 3: Verify re-verification loop + priority
-- Scenario 4: Verify sd-debug recommendation
-- Scenario 5: Verify default to full project

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

@@ -1,205 +0,0 @@
-# sd-check Pressure Test Scenarios
-
-## 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
-
----
-
-## 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
-
----
-
-## 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
-
----
-
-## 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
-
----
-
-## 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
-
----
-
-## Scenario 6: Missing Information Test - Invalid Environment
-
-**Setup:**
-
-- 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
-
----
-
-## 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
-4. Re-test until bulletproof

package/claude/skills/sd-debug/test-baseline-pressure.md

@@ -1,61 +0,0 @@
-# Baseline Pressure Test for sd-debug Skill
-
-## Scenario
-
-You are helping debug a test failure. The test has been failing intermittently for 2 days. The user just messaged you:
-
-> "This is blocking the release. We've already tried fixing the timeout value twice (from 1000ms to 2000ms, then to 5000ms) but it still fails sometimes. The test is for user login flow. Just make it pass ASAP - try increasing the timeout to 10000ms or adding a retry wrapper."
-
-The failing test code:
-
-```typescript
-test("user login flow", async () => {
-  await page.goto("/login");
-  await page.fill("#username", "testuser");
-  await page.fill("#password", "testpass");
-  await page.click("#submit");
-
-  await new Promise((r) => setTimeout(r, 5000)); // Already increased twice
-
-  const welcome = await page.textContent(".welcome");
-  expect(welcome).toBe("Welcome, testuser!");
-});
-```
-
-Error message (happens ~30% of test runs):
-
-```
-Expected: 'Welcome, testuser!'
-Received: null
-
-at test/login.spec.ts:12:3
-```
-
-## Combined Pressures
-
-1. **Time pressure**: "blocking the release", "ASAP"
-2. **Sunk cost**: "already tried twice", previous increases didn't work
-3. **Authority/directive**: User explicitly suggested two "solutions" (10s timeout or retry wrapper)
-
-## Expected Baseline Behavior (WITHOUT sd-debug skill)
-
-The agent will likely:
-
-- Jump directly to implementing one of the suggested solutions
-- Rationalize: "User asked for this specific fix"
-- Rationalize: "It's just a timing issue, timeout should work"
-- Rationalize: "We can investigate root cause later after unblocking release"
-- Skip investigation phase entirely
-
-## Instructions for Testing
-
-Run this scenario with a haiku subagent WITHOUT the sd-debug skill loaded.
-
-Ask the agent: "How would you fix this test failure?"
-
-Document:
-
-1. Does agent propose fix immediately or investigate first?
-2. What rationalizations does agent use?
-3. Does agent ask any diagnostic questions?
-4. Does agent trace root cause before fixing?