@simplysm/sd-claude 13.0.60 → 13.0.61

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

@@ -9,16 +9,16 @@ You are helping debug a test failure. The test has been failing intermittently f
 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');
+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
+  await new Promise((r) => setTimeout(r, 5000)); // Already increased twice
 
-  const welcome = await page.textContent('.welcome');
-  expect(welcome).toBe('Welcome, testuser!');
+  const welcome = await page.textContent(".welcome");
+  expect(welcome).toBe("Welcome, testuser!");
 });
 ```
 
@@ -40,6 +40,7 @@ at test/login.spec.ts:12:3
 ## 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"
@@ -53,6 +54,7 @@ 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?

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

@@ -15,6 +15,7 @@ Facilitate balanced, evidence-based technical discussions by researching industr
 ### 1. Understand the Question
 
 Ask ONE question to understand the user's motivation:
+
 - What problem triggered this question?
 - What constraints matter most?
 
@@ -23,11 +24,13 @@ Ask ONE question to understand the user's motivation:
 **MANDATORY before forming any opinion:**
 
 **Project research** (Read/Grep tools):
+
 - Read the actual source code related to the question
 - Check CLAUDE.md for project conventions
 - Find similar patterns in the codebase
 
 **Industry research** (WebSearch tool):
+
 - Search for current community consensus and trends
 - Check relevant specifications (TC39, W3C, RFCs)
 - Find recent benchmarks, migration case studies, or survey data
@@ -38,6 +41,7 @@ Ask ONE question to understand the user's motivation:
 Present each option as if you were **advocating FOR it**. Equal depth, equal effort.
 
 For each option:
+
 - **Industry support**: Libraries, standards, and projects that use this approach (with sources)
 - **Technical advantages**: Concrete benefits with evidence
 - **When this wins**: Specific scenarios where this is clearly better
@@ -52,12 +56,12 @@ For each option:
 
 Provide a decision matrix — NOT a single recommendation:
 
-| Criteria | Option A | Option B |
-|----------|----------|----------|
-| Industry alignment | ... | ... |
-| Project consistency | ... | ... |
-| Migration cost | ... | ... |
-| Long-term trend | ... | ... |
+| Criteria            | Option A | Option B |
+| ------------------- | -------- | -------- |
+| Industry alignment  | ...      | ...      |
+| Project consistency | ...      | ...      |
+| Migration cost      | ...      | ...      |
+| Long-term trend     | ...      | ...      |
 
 Then ask: "Which criteria matter most to you?"
 
@@ -79,10 +83,10 @@ Then ask: "Which criteria matter most to you?"
 
 ## Common Mistakes
 
-| Mistake | Fix |
-|---------|-----|
-| Jump to recommendation | Research first, present balanced options |
-| "Industry standard is X" without sources | WebSearch for actual data and citations |
-| Ignoring project context | Read codebase patterns before discussing |
-| Monologue instead of discussion | Ask about user's priorities and constraints |
-| Treating "modern" as "better" | Evaluate on actual trade-offs, not trends |
+| Mistake                                  | Fix                                         |
+| ---------------------------------------- | ------------------------------------------- |
+| Jump to recommendation                   | Research first, present balanced options    |
+| "Industry standard is X" without sources | WebSearch for actual data and citations     |
+| Ignoring project context                 | Read codebase patterns before discussing    |
+| Monologue instead of discussion          | Ask about user's priorities and constraints |
+| Treating "modern" as "better"            | Evaluate on actual trade-offs, not trends   |

package/claude/skills/sd-eml-analyze/SKILL.md

@@ -26,19 +26,20 @@ First run auto-installs: `pdfminer.six`, `python-pptx`, `openpyxl`.
 ## Output Format
 
 Markdown report with sections:
+
 1. **Mail info table**: Subject, From, To, Cc, Date, attachment count
 2. **Body text**: Plain text (HTML stripped if no plain text)
 3. **Attachment analysis**: Summary table + extracted text per file
 
 ## Supported Attachments
 
-| Format | Method |
-|--------|--------|
-| PDF | pdfminer.six text extraction |
-| XLSX/XLS | openpyxl cell data as markdown table |
-| PPTX | python-pptx slide text + tables + notes |
-| Text files (.txt, .csv, .json, .xml, .html, .md) | UTF-8/CP949 decode |
-| Images | Filename and size only |
+| Format                                           | Method                                  |
+| ------------------------------------------------ | --------------------------------------- |
+| PDF                                              | pdfminer.six text extraction            |
+| XLSX/XLS                                         | openpyxl cell data as markdown table    |
+| PPTX                                             | python-pptx slide text + tables + notes |
+| Text files (.txt, .csv, .json, .xml, .html, .md) | UTF-8/CP949 decode                      |
+| Images                                           | Filename and size only                  |
 
 ## Common Mistakes
 

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

@@ -14,6 +14,7 @@ You are an expert code analyst specializing in tracing and understanding feature
 ## Target Selection
 
 **When invoked with `$ARGUMENTS`:**
+
 - If path is provided → **Immediately start analysis** (don't ask clarifying questions)
 - If path is a package directory → Trace all major features, architecture, and patterns
 - If path is a single file → Trace its role, dependencies, and usage
@@ -25,6 +26,7 @@ You are an expert code analyst specializing in tracing and understanding feature
 Provide a complete understanding of how the target code works by tracing its implementation from entry points to data storage, through all abstraction layers. **Analysis only — no code modifications.**
 
 When analyzing a package/directory, cover:
+
 - Overall architecture and design patterns
 - Major features and entry points
 - Key abstractions and interfaces

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

@@ -15,11 +15,13 @@ Turn a design doc into a step-by-step implementation plan through codebase explo
 ## The Process
 
 **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 about anything you're not 100% confident about.** Examples:
+
 - Dependency choices (add library vs implement directly)
 - Conflicts with existing codebase patterns
 - Implementation choices the design didn't specify
@@ -28,11 +30,13 @@ Turn a design doc into a step-by-step implementation plan through codebase explo
 - If in doubt, ask. The cost of asking is low; the cost of a wrong assumption is high.
 
 **Don't ask — just decide:**
+
 - Internal details covered by project conventions (file naming, export patterns)
 - YAGNI decisions (not mentioned = don't add)
 - Implementation details with only one reasonable option
 
 **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
@@ -61,6 +65,7 @@ Turn a design doc into a step-by-step implementation plan through codebase explo
 ### Task N: [Component Name]
 
 **Files:**
+
 - Create: `exact/path/to/file.ts`
 - Modify: `exact/path/to/existing.ts:123-145`
 - Test: `exact/path/to/test.spec.ts`
@@ -76,7 +81,7 @@ test("specific behavior", () => {
 
 **Step 2: Run test to verify it fails**
 
-Run: `pnpm vitest exact/path/to/test.spec.ts --project=node`
+Run: `npx vitest exact/path/to/test.spec.ts --project=node`
 Expected: FAIL with "fn is not defined"
 
 **Step 3: Write minimal implementation**
@@ -89,7 +94,7 @@ export function fn(input: string): string {
 
 **Step 4: Run test to verify it passes**
 
-Run: `pnpm vitest exact/path/to/test.spec.ts --project=node`
+Run: `npx vitest exact/path/to/test.spec.ts --project=node`
 Expected: PASS
 
 **Step 5: Commit**
@@ -134,8 +139,9 @@ You can start from any step or skip steps as needed.
 - Do NOT auto-proceed. Wait for user's choice.
 
 **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
+- NEVER execute underlying commands (git, npm, 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.

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

@@ -240,8 +240,8 @@ Done!
 Between batches, run targeted verification on affected packages before starting the next batch:
 
 ```bash
-pnpm typecheck [affected packages]
-pnpm lint [affected packages]
+npm run typecheck [affected packages]
+npm run lint [affected packages]
 ```
 
 This catches cross-task integration issues early — especially when the next batch depends on the current batch's output. Do NOT skip this even if individual task reviews passed.
@@ -249,6 +249,7 @@ This catches cross-task integration issues early — especially when the next ba
 ## Red Flags
 
 **Never:**
+
 - Start implementation on main/master without explicit user consent
 - Skip reviews (spec compliance OR code quality)
 - Proceed with unfixed issues
@@ -262,16 +263,19 @@ This catches cross-task integration issues early — especially when the next ba
 - Use `run_in_background: true` on Task calls (use foreground parallel instead)
 
 **If task agent returns questions:**
+
 - Answer clearly and completely
 - Re-launch that agent with answers included
 - Other parallel agents continue unaffected
 
 **If reviewers find issues:**
+
 - Task agent fixes all issues from both reviewers at once
 - Re-review only the failed aspects (parallel sub-Tasks)
 - Repeat until both approved
 
 **If task agent fails or times out:**
+
 - Do NOT silently proceed — the affected files may be in an indeterminate state
 - Check if other tasks in the same batch depend on the failed task's output
 - Independent tasks' results still stand
@@ -281,6 +285,7 @@ This catches cross-task integration issues early — especially when the next ba
 ## Integration
 
 **Related skills:**
+
 - **sd-plan** — creates the plan this skill executes
 - **sd-tdd** — task agents follow TDD
 - **sd-worktree** — branch isolation for worktree-based workflows

package/claude/skills/sd-plan-dev/code-quality-reviewer-prompt.md

@@ -14,7 +14,9 @@ You are reviewing code quality for a completed implementation.
 
 Use git diff to review only what changed:
 ```
+
 git diff [BASE_SHA]..[HEAD_SHA]
+
 ```
 BASE_SHA: [commit before task started]
 HEAD_SHA: [implementer's commit SHA from report]

package/claude/skills/sd-plan-dev/final-review-prompt.md

@@ -38,8 +38,8 @@ Individual tasks already passed spec and quality reviews. Focus on cross-task in
 ### Verification
 
 Run and report results:
-- `pnpm typecheck [affected packages]`
-- `pnpm lint [affected packages]`
+- `npm run typecheck [affected packages]`
+- `npm run lint [affected packages]`
 
 ### Report
 

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

@@ -39,7 +39,9 @@ README.md is the **sole API documentation source for Claude Code**. When Claude
 ## Installation
 
 ## Main Modules
+
 ### {Category matching index.ts #region}
+
 - Description + code examples per export
 
 ## Types
@@ -50,6 +52,7 @@ README.md is the **sole API documentation source for Claude Code**. When Claude
 ### docs/ Subfolder Rules
 
 When README exceeds ~500 lines, split detailed documentation into `docs/`:
+
 - README.md becomes an **overview/index** with links: `[functionName](docs/category.md#anchor)`
 - docs/ files contain detailed descriptions, full code examples, parameter tables
 - File organization follows index.ts `#region` (e.g., `docs/types.md`, `docs/utils.md`)
@@ -83,14 +86,15 @@ Map each documented item to its current documentation content.
 
 Compare export map (Step 2) against documentation map (Step 3):
 
-| Status | Meaning |
-|--------|---------|
-| **ADDED** | Exported in source but not in README |
-| **REMOVED** | In README but no longer exported |
+| Status      | Meaning                              |
+| ----------- | ------------------------------------ |
+| **ADDED**   | Exported in source but not in README |
+| **REMOVED** | In README but no longer exported     |
 | **CHANGED** | Both exist but API signature differs |
-| **OK** | Documentation matches source |
+| **OK**      | Documentation matches source         |
 
 **Report to user before editing:**
+
 ```
 ADDED (3):
   - strToCamelCase (from utils/str.ts)
@@ -131,6 +135,7 @@ When `$ARGUMENTS` is empty:
 2. Launch **parallel subagents** (`subagent_type: "general-purpose"`, `model: "sonnet"`) — one per package + one for project root:
 
 **Per-package subagent prompt template:**
+
 ```
 Update README.md for package {pkg-name} at {pkg-path}.
 
@@ -160,6 +165,7 @@ STEPS:
 ```
 
 **Project root subagent prompt:**
+
 ```
 Update the project root README.md at {project-root}/README.md.
 Read CLAUDE.md for project context.
@@ -172,14 +178,14 @@ Report what was changed.
 
 ## Common Mistakes
 
-| Mistake | Fix |
-|---------|-----|
-| Skipping exports with @internal JSDoc | Document ALL exports — Claude Code doesn't read JSDoc |
-| Rewriting OK sections | Only touch ADDED/REMOVED/CHANGED items |
-| Ignoring existing docs/ structure | If docs/ exists, update those files too |
-| Arbitrary section reorganization | Follow index.ts `#region` structure |
-| Missing import paths in examples | Always: `import { X } from "@simplysm/..."` |
-| Writing in Korean | README must be in English |
-| Adding changelog sections | Never add version history |
-| Editing before reporting diff | Always report ADDED/REMOVED/CHANGED and wait for confirmation |
-| Destroying docs/ link format | If README uses `[name](docs/file.md#anchor)`, preserve that pattern |
+| Mistake                               | Fix                                                                 |
+| ------------------------------------- | ------------------------------------------------------------------- |
+| Skipping exports with @internal JSDoc | Document ALL exports — Claude Code doesn't read JSDoc               |
+| Rewriting OK sections                 | Only touch ADDED/REMOVED/CHANGED items                              |
+| Ignoring existing docs/ structure     | If docs/ exists, update those files too                             |
+| Arbitrary section reorganization      | Follow index.ts `#region` structure                                 |
+| Missing import paths in examples      | Always: `import { X } from "@simplysm/..."`                         |
+| Writing in Korean                     | README must be in English                                           |
+| Adding changelog sections             | Never add version history                                           |
+| Editing before reporting diff         | Always report ADDED/REMOVED/CHANGED and wait for confirmation       |
+| Destroying docs/ link format          | If README uses `[name](docs/file.md#anchor)`, preserve that pattern |

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

@@ -23,6 +23,7 @@ Analyzes code via the `sd-explore` skill, then runs up to 4 subagents in paralle
 - When onboarding to unfamiliar code and want a quality overview
 
 **When NOT to use:**
+
 - Single-file or trivial changes (typo, config tweak)
 - When you need code modifications (sd-review is analysis-only)
 
@@ -37,12 +38,12 @@ Analyzes code via the `sd-explore` skill, then runs up to 4 subagents in paralle
 
 Run subagents in parallel via the Task tool:
 
-| Agent Type               | Role | Condition |
-|--------------------------|------|-----------|
-| `sd-code-reviewer`       | Bugs, security, logic errors, convention issues | Always |
-| `sd-code-simplifier`     | Complexity, duplication, readability issues | Always |
-| `sd-api-reviewer`        | DX/usability, naming, type hints | Always |
-| `sd-security-reviewer`   | ORM SQL injection, input validation vulnerabilities | When target path contains ORM queries or service endpoints |
+| Agent Type             | Role                                                | Condition                                                  |
+| ---------------------- | --------------------------------------------------- | ---------------------------------------------------------- |
+| `sd-code-reviewer`     | Bugs, security, logic errors, convention issues     | Always                                                     |
+| `sd-code-simplifier`   | Complexity, duplication, readability issues         | Always                                                     |
+| `sd-api-reviewer`      | DX/usability, naming, type hints                    | Always                                                     |
+| `sd-security-reviewer` | ORM SQL injection, input validation vulnerabilities | When target path contains ORM queries or service endpoints |
 
 ## Workflow
 
@@ -69,7 +70,7 @@ Run subagents **in parallel** via the Task tool. Include the sd-explore analysis
 - **sd-code-reviewer**: Based on the analysis, find bugs, security vulnerabilities, logic errors, and convention issues. Each finding must include **file:line** and **evidence**.
 - **sd-code-simplifier**: Based on the analysis, find unnecessary complexity, code duplication, and readability issues. Each finding must include **file:line** and **evidence**. **No code modifications.**
 - **sd-api-reviewer**: Based on the analysis, review API intuitiveness, naming consistency, type hints, error messages, and configuration complexity. Each finding must include **file:line** and **evidence**.
-- **sd-security-reviewer** *(conditional)*: If the sd-explore analysis reveals ORM queries (`orm-common`, `orm-node`, query builders, `expr.eq`, `.where()`, `.result()`) or service endpoints (`ServiceServer`, RPC handlers), also dispatch this agent. Based on the analysis, find SQL injection risks, missing input validation, and unvalidated user input reaching ORM queries. Each finding must include **file:line** and **evidence**.
+- **sd-security-reviewer** _(conditional)_: If the sd-explore analysis reveals ORM queries (`orm-common`, `orm-node`, query builders, `expr.eq`, `.where()`, `.result()`) or service endpoints (`ServiceServer`, RPC handlers), also dispatch this agent. Based on the analysis, find SQL injection risks, missing input validation, and unvalidated user input reaching ORM queries. Each finding must include **file:line** and **evidence**.
 
 ### Step 3: Verify Issues
 
@@ -86,15 +87,15 @@ Compile only **verified findings** into a comprehensive report.
 
 ### Report Structure
 
-| Section | Priority | Source |
-|---------|----------|--------|
-| **Architecture Summary** | — | sd-explore analysis |
-| **Critical Issues** | P0 | Bugs, security vulnerabilities |
-| **Security Issues** | P0 | SQL injection, input validation (when sd-security-reviewer ran) |
-| **Quality Issues** | P1 | Logic errors, missing error handling, performance |
-| **DX/Usability Issues** | P2 | API intuitiveness, naming, type hints |
-| **Simplification Opportunities** | P3 | Complexity removal, duplicate code, abstractions |
-| **Convention Issues** | P4 | Project convention mismatches |
+| Section                          | Priority | Source                                                          |
+| -------------------------------- | -------- | --------------------------------------------------------------- |
+| **Architecture Summary**         | —        | sd-explore analysis                                             |
+| **Critical Issues**              | P0       | Bugs, security vulnerabilities                                  |
+| **Security Issues**              | P0       | SQL injection, input validation (when sd-security-reviewer ran) |
+| **Quality Issues**               | P1       | Logic errors, missing error handling, performance               |
+| **DX/Usability Issues**          | P2       | API intuitiveness, naming, type hints                           |
+| **Simplification Opportunities** | P3       | Complexity removal, duplicate code, abstractions                |
+| **Convention Issues**            | P4       | Project convention mismatches                                   |
 
 Each issue includes **file:line**, **description**, and **suggestion**.
 
@@ -102,11 +103,11 @@ Optionally include an **Invalid Findings Summary** appendix showing which findin
 
 ## Common Mistakes
 
-| Mistake | Fix |
-|---------|-----|
-| Using git diff to limit review scope | Review ALL source files under target path |
-| Skipping verification step | Always verify subagent findings against actual code |
-| Reporting unverified issues | Only include verified findings in final report |
+| Mistake                              | Fix                                                 |
+| ------------------------------------ | --------------------------------------------------- |
+| Using git diff to limit review scope | Review ALL source files under target path           |
+| Skipping verification step           | Always verify subagent findings against actual code |
+| Reporting unverified issues          | Only include verified findings in final report      |
 
 ## Completion Criteria