@simplysm/sd-claude 13.0.75 → 13.0.77

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-skill/writing-guide.md

@@ -4,17 +4,13 @@
 
 ## Flowchart Usage
 
-```dot
-digraph when_flowchart {
-    "Need to show information?" [shape=diamond];
-    "Decision where I might go wrong?" [shape=diamond];
-    "Use markdown" [shape=box];
-    "Small inline flowchart" [shape=box];
-
-    "Need to show information?" -> "Decision where I might go wrong?" [label="yes"];
-    "Decision where I might go wrong?" -> "Small inline flowchart" [label="yes"];
-    "Decision where I might go wrong?" -> "Use markdown" [label="no"];
-}
+Use Mermaid (`flowchart`) when there are decision branches or non-obvious process flows.
+
+```mermaid
+flowchart TD
+    A{"Need to show information?"} -->|yes| B{"Decision where I might go wrong?"}
+    B -->|yes| C[Small inline flowchart]
+    B -->|no| D[Use markdown]
 ```
 
 **Use flowcharts ONLY for:**

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

@@ -50,26 +50,21 @@ Implement fresh from tests. Period.
 
 ## Red-Green-Refactor
 
-```dot
-digraph tdd_cycle {
-    rankdir=LR;
-    red [label="RED\nWrite failing test", shape=box, style=filled, fillcolor="#ffcccc"];
-    verify_red [label="Verify fails\ncorrectly", shape=diamond];
-    green [label="GREEN\nMinimal code", shape=box, style=filled, fillcolor="#ccffcc"];
-    verify_green [label="Verify passes\nAll green", shape=diamond];
-    refactor [label="REFACTOR\nClean up", shape=box, style=filled, fillcolor="#ccccff"];
-    next [label="Next", shape=ellipse];
-
-    red -> verify_red;
-    verify_red -> green [label="yes"];
-    verify_red -> red [label="wrong\nfailure"];
-    green -> verify_green;
-    verify_green -> refactor [label="yes"];
-    verify_green -> green [label="no"];
-    refactor -> verify_green [label="stay\ngreen"];
-    verify_green -> next;
-    next -> red;
-}
+```mermaid
+flowchart LR
+    A["RED<br>Write failing test"]:::red --> B{"Verify fails<br>correctly"}
+    B -->|yes| C["GREEN<br>Minimal code"]:::green
+    B -->|"wrong failure"| A
+    C --> D{"Verify passes<br>All green"}
+    D -->|yes| E["REFACTOR<br>Clean up"]:::blue
+    D -->|no| C
+    E -->|"stay green"| D
+    D --> F(["Next"])
+    F --> A
+
+    classDef red fill:#ffcccc
+    classDef green fill:#ccffcc
+    classDef blue fill:#ccccff
 ```
 
 ### RED - Write Failing Test

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, 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,34 @@ 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                                    |
 
 ## 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, 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**: 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/claude/skills/sd-worktree/SKILL.md

@@ -6,128 +6,73 @@ model: haiku
 
 # sd-worktree
 
-## CRITICAL SAFETY RULES — MERGE & STASH
-
-**These rules are ABSOLUTE. No exceptions. Applies to ALL modes (yolo, normal, plan, etc.).**
-
-1. **NEVER run `git stash drop`, `git stash pop`, or `git stash clear`.**
-   - If you stashed something, ONLY use `git stash apply` (which keeps the stash intact).
-   - If stash is no longer needed, ASK the user before dropping it.
-
-2. **If `merge` fails or produces conflicts → STOP IMMEDIATELY and show this message:**
-   ```
-   ⚠️ A problem occurred during merge.
-   Please proceed with the merge manually.
-   (Error details: <print error/conflict info as-is>)
-   ```
-   - Show this message in the system's configured language.
-   - Do NOT attempt to resolve conflicts yourself.
-   - Do NOT run `git merge --abort` without asking.
-   - Do NOT proceed to `clean` after a failed merge.
-   - Do NOT retry or work around the error.
-   - Just show the message above and STOP. Do nothing else.
-
-3. **If `rebase` fails or produces conflicts → STOP IMMEDIATELY and show this message:**
-   ```
-   ⚠️ A problem occurred during rebase.
-   Please proceed with the rebase manually.
-   (Error details: <print error/conflict info as-is>)
-   ```
-   - Show this message in the system's configured language.
-   - Same rules as merge. Do NOT auto-resolve. Just show the message and STOP.
-
-4. **NEVER run destructive git commands during worktree workflows:**
-   - `git reset --hard`, `git checkout -- .`, `git restore .`, `git clean -f`
-   - `git branch -D` (force delete) — only `-d` (safe delete) is allowed
-   - `git stash drop`, `git stash pop`, `git stash clear`
-
-5. **Before ANY merge/rebase, verify:**
-   - Both main and worktree have NO uncommitted changes (`git status --porcelain`)
-   - If uncommitted changes exist → ask the user (do NOT auto-stash)
-
-6. **After merge completes, verify success before proceeding:**
-   - Check `git status` — if merge conflicts exist, STOP and report
-   - Do NOT proceed to `clean` until merge is confirmed successful
-
-**Violation of these rules causes IRREVERSIBLE DATA LOSS.**
-
-## Overview
-
-Create, merge, and clean up git worktrees under `.worktrees/`. Uses the current branch of the main working tree as the source branch.
-
-**Important**: Claude Code's working directory (cd) shifts between main and worktree, so always verify the cd location before and after each command.
-
-## 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
-
-## Commands
-
-### add — Create a worktree
-
-Take a work description from args, determine a kebab-case name, then run:
-
-```bash
-# Run from main
-node .claude/skills/sd-worktree/sd-worktree.mjs add <name>
-cd .worktrees/<name>   # Move into the worktree
+Branch-isolated workflow using git worktrees.
+
+## Flow
+
+```mermaid
+flowchart TD
+    START([sd-worktree invoked]) --> ADD
+
+    subgraph ADD [add]
+        A1["git worktree add .worktrees/NAME -b NAME"]
+        A1 -->|fail| HALT
+        A1 -->|ok| A2[detect package manager]
+        A2 --> A3["pm install (cwd: .worktrees/NAME)"]
+        A3 -->|fail| HALT
+        A3 -->|ok| A4["cd .worktrees/NAME"]
+    end
+
+    A4 --> WORK["work + commit inside worktree"]
+    WORK --> MERGE
+
+    subgraph MERGE [merge]
+        M0["cd PROJECT_ROOT"]
+        M0 --> M1["git merge NAME --no-ff (cwd: PROJECT_ROOT)"]
+        M1 -->|fail| HALT
+        M1 -->|ok| M2[merge complete]
+    end
+
+    M2 --> CLEAN
+
+    subgraph CLEAN [clean]
+        C1{"cwd inside worktree?"}
+        C1 -->|yes| HALT
+        C1 -->|no| C2["rm -rf .worktrees/NAME (bash)"]
+        C2 --> C3["git worktree prune"]
+        C3 --> C4["git branch -d NAME"]
+        C4 -->|fail| HALT
+        C4 -->|ok| C5[done]
+    end
+
+    HALT([HALT - AskUserQuestion])
 ```
 
-- All subsequent work should be done inside the worktree
-
-### rebase — Rebase onto main branch
+## Rules
 
-```bash
-# Can be run from inside the worktree
-node .claude/skills/sd-worktree/sd-worktree.mjs rebase [name]
-```
-
-- Rebases the worktree branch onto the latest commit of the main branch
-- Errors if uncommitted changes exist → commit or stash first
-- Use when you want a clean history before merging
-- **If rebase fails or conflicts → STOP. Report to user. Do NOT auto-resolve.**
+### HALT
 
-### merge — Merge into main branch
+When any step reaches **fail** or **HALT**:
 
-```bash
-# Can be run from inside the worktree (script sets cwd to main)
-node .claude/skills/sd-worktree/sd-worktree.mjs merge [name]
-```
+1. Show the error message to the user as-is
+2. Ask the user how to proceed via `AskUserQuestion`
+3. Do **nothing** until the user responds
 
-- Merges the worktree branch into the main working tree's current branch with `--no-ff`
-- Errors if uncommitted changes exist → commit or stash first
-- After merge, always `cd <project-root>` (required for subsequent clean)
+Manual git merge, git stash, git reset, git clean, or **any workaround is forbidden**. Yolo mode does NOT override HALT.
 
-**MERGE SAFETY PROTOCOL:**
-1. Before merge: check BOTH main and worktree for uncommitted changes
-2. If the script exits with non-zero → show "Please proceed with the merge manually." message (in system language) and STOP.
-3. After merge: run `git status` in main to confirm no conflicts
-4. If conflicts or errors → show "Please proceed with the merge manually." message (in system language) and STOP.
-5. Only proceed to `clean` after confirming merge was fully successful
+### Worktree location
 
-### clean — Remove worktree and delete branch
+All worktrees MUST be created under **`.worktrees/`** (project root).
 
-```bash
-# Must cd to main first (worktree directory will be deleted)
-cd <project-root>
-node .claude/skills/sd-worktree/sd-worktree.mjs clean <name>
-```
+### Package manager detection
 
-- Runs `git worktree remove` + `git branch -d`
-- Script blocks execution if run from inside the worktree → must cd to main first
+| File | PM |
+|---|---|
+| `pnpm-lock.yaml` | pnpm |
+| `yarn.lock` | yarn |
+| `package-lock.json` | npm |
+| `bun.lockb` / `bun.lock` | bun |
 
-## Full Workflow Example
+### clean: use rm -rf
 
-```
-(main: 13.x)  → /sd-worktree add modal-migration
-               → cd .worktrees/modal-migration
-(worktree)    → ... work ...
-(worktree)    → /sd-worktree rebase          # (optional) rebase onto latest main
-(worktree)    → /sd-worktree merge
-(worktree)    → cd <project-root>
-(main: 13.x)  → /sd-worktree clean modal-migration
-```
+`git worktree remove` almost always fails on Windows due to file locks. Use `rm -rf` (bash) + `git worktree prune` instead.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "13.0.75",
+  "version": "13.0.77",
   "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