@simplysm/sd-claude 13.0.40 → 13.0.42

package/claude/rules/sd-code-conventions.md

@@ -0,0 +1,34 @@
+# Code Conventions
+
+## Generic Type Parameters
+
+- Always use descriptive names — single-letter `T` alone is not allowed
+- Use `T` prefix + descriptive name: `TItem`, `TData`, `TResult`, `TKey`, `TValue`, `TAuthInfo`
+
+## Prototype Extensions
+
+Importing `@simplysm/core-common` adds extension methods to Array, Map, Set:
+- `Array`: `single()`, `filterExists()`, `groupBy()`, `orderBy()`, etc.
+- `Map`: `getOrCreate()`, `update()`
+- `Set`: `adds()`, `toggle()`
+
+Before using extension methods: Verify actual existence in `@simplysm/core-common` extensions (check README or source). Do not guess methods that don't exist.
+
+## Function Naming Conventions
+
+- Do not use `Async` suffix on function names — Async is the default
+- When both sync and async versions exist, use `Sync` suffix on the sync function
+
+```typescript
+// Good
+async function readFile() { ... }      // Async (default)
+function readFileSync() { ... }        // Sync version
+
+// Bad
+async function readFileAsync() { ... } // Async suffix prohibited
+```
+
+## JSDoc Convention
+
+- Not enforced — omit when code is self-explanatory
+- When written, use Korean

package/claude/rules/sd-directories.md

@@ -0,0 +1,7 @@
+# Directory Reference
+
+- `.cache/`: Build cache (`eslint.cache`, `typecheck-{env}.tsbuildinfo`, `dts.tsbuildinfo`). Reset: delete `.cache/`
+- `.playwright-mcp/`: Playwright MCP output directory
+  - Screenshots/snapshots must always be saved to the `.playwright-mcp/` directory
+  - When calling `browser_take_screenshot`, always prefix filename with `.playwright-mcp/` (e.g., `.playwright-mcp/screenshot.png`)
+  - `PLAYWRIGHT_OUTPUT_DIR` only applies to auto-generated filenames; explicitly specified filenames are resolved relative to cwd

package/claude/rules/sd-language.md

@@ -4,4 +4,3 @@ Respond in the **system's configured language** (set via Claude Code's language
 
 - Technical terms, code identifiers (variable names, function names, etc.), and library names should remain as-is
 - Show English error messages and logs in their original form, but provide explanations in the system language
-- Files in `.claude/` folder and each package's `README.md` are written in English for consistent documentation

package/claude/rules/sd-workflow-rules.md

@@ -1,3 +1,18 @@
 # Workflow Rules
 
 - **No auto-proceeding after skill completion**: When the user explicitly invokes a skill, report the result and **stop** once the skill finishes. Do not guess the next step and proceed arbitrarily. Wait for explicit user instructions if further work is needed.
+
+## Problem-Solving Principles
+
+- **Root cause first**: When encountering errors or unexpected behavior, always investigate the root cause before attempting a fix. Do not apply workarounds, hacks, or surface-level patches.
+- **No band-aid fixes**: Avoid techniques like suppressing errors, adding defensive checks to hide symptoms, or bypassing validation. These mask the real problem and create technical debt.
+- **Consider refactoring**: If the root cause reveals a design flaw or structural issue, propose a refactoring approach rather than working around it. A proper fix — even if larger in scope — is better than a fragile workaround.
+- **Trace the full chain**: Follow the error or issue through the entire call chain (caller -> callee -> dependencies) to understand why it happens, not just where it happens.
+- **When uncertain, ask**: If the root cause is unclear or the fix requires significant changes, discuss with the user before proceeding. Present findings and options rather than silently applying a quick fix.
+
+## Pre-coding Checklist
+
+- Before creating new files: Glob/Read similar existing files to check structure and patterns
+- Before modifying functions/classes: Read the file to understand existing code style
+- When unsure about API/method usage: Check signatures in source code
+- **If confidence is low, ask the user instead of writing code**

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

@@ -1,7 +1,7 @@
 ---
 name: sd-skill
 description: Use when creating new skills, editing existing skills, or verifying skills work before deployment
-model: sonnet
+model: opus
 ---
 
 # Writing Skills
@@ -401,6 +401,15 @@ Different skill types need different test approaches:
 - Variation scenarios: Do they handle edge cases?
 - Missing information tests: Do instructions have gaps?
 
+**How to test:** Give a subagent a problem the technique solves, WITHOUT the skill. Observe what approach they use naturally. Then give the SAME problem WITH the skill and verify they apply the technique correctly.
+
+```
+Example: Testing a "condition-based-waiting" skill
+1. Ask subagent: "Fix this flaky test that uses setTimeout(500)"
+2. WITHOUT skill: Agent increases timeout to 2000ms (wrong approach)
+3. WITH skill: Agent replaces with polling/condition check (correct)
+```
+
 **Success criteria:** Agent successfully applies technique to new scenario
 
 ### Pattern Skills (mental models)
@@ -437,6 +446,7 @@ Different skill types need different test approaches:
 | "I'm confident it's good" | Overconfidence guarantees issues. Test anyway. |
 | "Academic review is enough" | Reading ≠ using. Test application scenarios. |
 | "No time to test" | Deploying untested skill wastes more time fixing it later. |
+| "I already know the baseline failures" | You know what YOU think the failures are. Run a subagent to see what ACTUALLY happens. Knowledge ≠ observation. |
 
 **All of these mean: Test before deploying. No exceptions.**
 
@@ -527,6 +537,8 @@ Run pressure scenario with subagent WITHOUT the skill. Document exact behavior:
 
 This is "watch the test fail" - you must see what agents naturally do before writing the skill.
 
+**You MUST actually run a subagent.** Do not substitute your own knowledge of "what agents would probably do." Your prediction of baseline behavior ≠ observed baseline behavior. Run the subagent, read the output, document what actually happened.
+
 ### GREEN: Write Minimal Skill
 
 Write skill that addresses those specific rationalizations. Don't add extra content for hypothetical cases.

package/package.json

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

package/claude/rules/sd-naming-conventions.md

@@ -1,13 +0,0 @@
-# Function Naming Conventions
-
-- Do not use `Async` suffix on function names — Async is the default
-- When both sync and async versions exist, use `Sync` suffix on the sync function
-
-```typescript
-// Good
-async function readFile() { ... }      // Async (default)
-function readFileSync() { ... }        // Sync version
-
-// Bad
-async function readFileAsync() { ... } // Async suffix prohibited
-```